43

Úvod do softwarového inženýrství IUS 2010/2011 1. pˇrednáška Ing. Radek Koˇc´ı, Ph.D. Ing. Bohuslav Kˇrena, Ph.D.

´ ´ inˇzen´yrstv´ı IUS 2010/2011 – p.1/43 Uvod do softwaroveho

ˇ – Prˇedna´ sˇ ky Organizace prˇedmetu

• • • •

D105 + D0207 1BIA + 2BIA + 2BIB úterý 16:00 – 17:50

D105 + D0207 1BIB + 2BIA + 2BIB pátek 10:00 – 11:50

Ing. Bohuslav Kˇrena, Ph.D.

Ing. Radek Koˇcí, Ph.D.

V úterý 28. záˇrí 2010 pˇrednáška není (státní svátek). V rámci pˇrednášek je vyhrazeno 10 minut pro studijní koutek. Konzultace: fóra v IS FIT, e-mail, osobneˇ ˇ Dekujeme prof. M. Bielikové za poskytnutí puvodních ˚ pˇrednášek.

´ ´ inˇzen´yrstv´ı IUS 2010/2011 – p.2/43 Uvod do softwaroveho

ˇ – Projekty Organizace prˇedmetu Projekty (35 bodu): ˚ 1. absolvování e-learningového kurzu (5 bodu) ˚ 2. dokumentace k projektu z IZP (10 bodu) ˚

registrace v IS FIT

3. model informaˇcního systému (20 bodu) ˚

registrace v IS FIT

Konzultace a hodnocení:

• 1. projekt: tým doktorandu˚ pod vedením Bc. Petry Nastulczykové • 2. projekt: tým doktorandu˚ pod vedením doc. RNDr. Jitky Kreslíkové, CSc. a Ing. Aleše Smrˇcky

• 3. projekt: Ing. Jan Fiedor, Ing. Vendula Hrubá, Ing. Ondˇrej Lengál a Ing. Petr Müller

´ ´ inˇzen´yrstv´ı IUS 2010/2011 – p.3/43 Uvod do softwaroveho

ˇ – Projekty Organizace prˇedmetu Podmínky zápoˇctu (nutné splnit všechny):

• minimálneˇ 1 bod z 1. projektu (absolvování e-learningového kurzu), • minimálneˇ 8 bodu˚ ze 3. projektu, • minimálneˇ 17 bodu˚ ze všech projektu. ˚ Další poznámky:

• • • • • •

ˇ Pro uznání lonských bodu˚ z projektu˚ se do 3. 10. pˇrihlaste v IS FIT. Vzorové ˇrešení 3. projektu bude prezentováno na pˇrednáškách. Za odevzdání 3. projektu týden pˇred termínem 2 prémiové body. Pozdní odevzdání 3. projektu není tolerováno. ˇ Projekty se vypracovávají samostatne! Cviˇcení ani laboratoˇre v IUS nejsou.

´ ´ inˇzen´yrstv´ı IUS 2010/2011 – p.4/43 Uvod do softwaroveho

ˇ – Hodnocen´ı Organizace prˇedmetu • Projekty: 35 bodu˚ • Zkouška: 65 bodu˚ • Celkem: 100 bodu˚ • Pro pˇristoupení ke zkoušce je nutný zápoˇcet. • Zkouška má 3 termíny (pouze pˇri 4F lze jít k dalšímu). • Stupnice ECTS (European Credit Transfer System): Bodu˚ 90 - 100 80 - 89 70 - 79 60 - 69 50 - 59 0 - 49

⇒ ⇒ ⇒ ⇒ ⇒ ⇒

Klasifikace A B C D E F

ˇ Císeln eˇ 1 1,5 2 2,5 3 4

Slovneˇ výborneˇ velmi dobˇre dobˇre uspokojiveˇ dostateˇcneˇ nevyhovující

´ ´ inˇzen´yrstv´ı IUS 2010/2011 – p.5/43 Uvod do softwaroveho

ˇ – Zkousˇ ka Organizace prˇedmetu • Studium je investice do vzdelání, ˇ která má vysokou návratnost. lepší pozice s vyšším platem

• Pˇredevším na Vás je, jak bude investice 3-5 let života úspešná. ˇ FIT ˇ ˇ nabízí v praxi vysoce cenené vzdelání, ale nemuže ˚ ho studentum ˚ vnutit proti jejich vuli. ˚ Snaží se ale chránit své dobré jméno a atraktivitu svých absolventu˚ na trhu práce.

• Zkouškou se zjišt’uje komplexní zvládnutí látky vymezené v dokumentaci ˇ prezentované ve výuce na úrovni odpovídající absolvované pˇredmetu cˇ ásti studia a schopnosti získané poznatky samostatneˇ a tvurˇ ˚ cím ˇ 12, Odst. 3) ˇ VUT, Cl. zpusobem ˚ aplikovat. (SZR

• Pro získání bodu˚ ze zkoušky je nutné zkoušku vypracovat tak, ˇ aby byla hodnocena nejméneˇ 30 body. V opacném pˇrípadeˇ bude zkouška hodnocena 0 body.

• Nezkoumejte, jak projít studiem s co nejmenším úsilím, ale sami se snažte nauˇcit co nejvíc. Ovlivní to celou Vaši profesní kariéru!

´ ´ inˇzen´yrstv´ı IUS 2010/2011 – p.6/43 Uvod do softwaroveho

Histogram hodnocen´ı 2009

´ ´ inˇzen´yrstv´ı IUS 2010/2011 – p.7/43 Uvod do softwaroveho

ˇ – Komunikace Organizace prˇedmetu • Informaˇcní systém fakulty (IS FIT) ◦ termíny a jejich hodnocení ◦ diskuzní fóra ◦ slidy k pˇrednáškám ◦ https://wis.fit.vutbr.cz/FIT/ • Webová stránka pˇredmetu ˇ ◦ plán pˇrednášek ◦ zadání 3. projektu ◦ odkazy na literaturu a další studijní materiály ◦ https://www.fit.vutbr.cz/study/courses/IUS/private/

´ ´ inˇzen´yrstv´ı IUS 2010/2011 – p.8/43 Uvod do softwaroveho

ˇ C´ıle prˇedmetu • získat základní pˇrehled v oblasti tvorby rozsáhlých softwarových systému, ˚ • seznámit se s procesem tvorby softwaru a s etapami jeho životního cyklu, • nauˇcit se používat základní modely UML.

´ ´ inˇzen´yrstv´ı IUS 2010/2011 – p.9/43 Uvod do softwaroveho

Co je to softwarove´ inˇzen´yrstv´ı?

? ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.10/43

Co je to softwarove´ inˇzen´yrstv´ı? • systematický pˇrístup k vývoji, nasazení a údržbeˇ softwaru The application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software. (IEEE Standard Computer Dictionary, 1990)

• inženýrská disciplína zabývající se praktickými problémy vývoje rozsáhlých softwarových systému˚ (Vondrák, 2002)

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.10/43

Co je to softwarove´ inˇzen´yrstv´ı? • systematický pˇrístup k vývoji, nasazení a údržbeˇ softwaru The application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software. (IEEE Standard Computer Dictionary, 1990)

• inženýrská disciplína zabývající se praktickými problémy vývoje rozsáhlých softwarových systému˚ (Vondrák, 2002)

!

softwarové inženýrství 6= programování

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.10/43

Procˇ softwarove´ inˇzen´yrstv´ı? • Software je všude okolo nás. • Je nutné zlepšovat vlastnosti SW, hlavneˇ jeho spolehlivost, bezpeˇcnost a použitelnost.

• Je potˇreba zvyšovat produktivitu vývoje SW.

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.11/43

´ Historie SW inˇzen´yrstv´ı – 60. leta • problémy pˇri vývoji vetších ˇ programu˚ • zavedení pojmu˚ softwarové inženýrství a softwarová krize na konferencích v letech 1968-1969

• SW krize se projevovala (a stále projevuje) ◦ neúnosným prodlužováním a prodražováním projektu˚ ◦ nízkou kvalitou výsledných produktu˚ ◦ problematickou údržbou a inovacemi ◦ špatnou produktivitou práce programátoru˚ ◦ ˇrada projektu˚ konˇcila neúspechem ˇ • Hledání jednoduchého a úˇcinného ˇrešení na existující problémy vedlo ke strukturovanému programování, jehož zaˇcátek je spojován s cˇ lánkem pana Dijkstry o používání pˇríkazu GOTO.

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.12/43

Kvalita • Kvalita je souhrn vlastností a charakteristik výrobku, procesu nebo služby, které ukazují jeho schopnost splnit urˇcené nebo odvozené potˇreby. (ISO 8402)

• Kvalita není definovaná jako absolutní míra, ale jako stupenˇ splnení ˇ požadavku cˇ i potˇreb.

• Kvalita je ◦ míra stupneˇ dokonalosti (Oxfordský slovník) ◦ splnení ˇ požadavku˚ (Crosby) ◦ vhodnost k danému úˇcelu (ISO 9001) ◦ schopnost produktu nebo služby plnit dané potˇreby (BS 4778) • Pokud bude cílem vyvinout nespolehlivý software, pak cˇ ím méneˇ bude ˇ tento software spolehlivý, tím bude kvalitnejší.

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.13/43

Kvalita v´yrobku • cˇ as • cena • splnení ˇ požadavku˚

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.14/43

(Ne)usp ´ eˇ sˇ nost SW projektu˚ (Standish Group Report, USA, 1995) Pˇrekroˇcení nákadu˚ o méneˇ než 20 % 21 - 50 % 51 - 100 % 101 - 200 % 201 - 400 % více než 400 % Pˇrekroˇcení cˇ asu o méneˇ než 20 % 21 - 50 % 51 - 100 % 101 - 200 % 201 - 400 % více než 400 %

Projektu˚ 15,5 % 31,5 % 29,6 % 10,2 % 8,8 % 4,4 %

Projektu˚ 13,9 % 18,3 % 20,0 % 35,5 % 11,2 % 1,1 % ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.15/43

(Ne)usp ´ eˇ sˇ nost SW projektu˚ (Standish Group Report, USA, 1995) Výsledná funkˇcnost méneˇ než 25 % 25 - 49 % 50 - 74 % 75 - 99 % 100 %

Projektu˚ 4,6 % 27,2 % 21,8 % 39,1 % 7,3 %

ˇ Prum ˚ erný SW projekt tedy v porovnání s puvodním ˚ plánem:

• stál o 89 % více, • trval 2,22 krát déle a • poskytuje pouze 61 % funkˇcnosti. ˇ ˇ r 7 krát horší, než se puvodn Prum ˚ erný projekt byl tedy témeˇ ˚ eˇ plánovalo!

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.16/43

´ Historie SW inˇzen´yrstv´ı – 70. leta • výzkum dobrých programovacích praktik ◦ zdurazn ˇ lidského faktoru pˇri programování ˚ ení ◦ návrh shora-dolu˚ (postupné zjemnování ˇ a modulární programování) ◦ podpora ˇrízení tvorby softwaru ◦ technika programování v týmech (pravidlo vedoucího programátora) ◦ zavedení pojmu abstraktní datový typ • metodologie ◦ strukturovaná analýza a návrh ◦ datoveˇ a procesneˇ orientované metody ◦ vnímání životního cyklu tvorby softwaru ◦ nárust ˚ významu a duležitosti ˚ etap specifikace a návrhu • snahy o zabezpeˇcení kvality ◦ vývoj procedur zameˇ ˇ rených na systematické testování ◦ zavedení pojmu formální správnost programu • využití formálních transformací specifikace do programu

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.17/43

´ Historie SW inˇzen´yrstv´ı – 80. leta • využívání vývojových (programovacích) prostˇredí • snaha o poˇcítaˇcovou podporu jednotlivých metod vývoj CASE prostˇredku˚

• pokraˇcující vývoj funkcionálního, logického i imperativního programování • rozvoj dalších programových paradigmat ˇ napˇr. objektove-orientované programování

• vývoj formálních metod specifikace a návrhu vetších ˇ programu˚ • pokroky v oblasti paralelního programování • zvýšení významu etapy nasazení a údržby softwaru vývoj systému˚ na podporu údržby verzí softwarových objektu˚ a ˇrízení konfigurací SW systému˚

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.18/43

´ Historie SW inˇzen´yrstv´ı – 90. leta • rozšíˇrení prototypování • vývoj softwaru založený na znovupoužitelnosti (angl. reusability ) a komponentách

• rozvoj objektove-orientovaného ˇ programování, rozšíˇrení jazyka Java • pozornost se venuje ˇ OO specifikacím a návrhu ⇒ schémata a vzory (napˇr. návrhové vzory)

• aplikace technik znalostních systému˚ a umelé ˇ inteligence do softwarového inženýrství

• sledování kvality softwarového procesu a softwaru použitím metrik • vývoj open source software • snahy o efektivní využití Internetu; nové metody, techniky a prostˇredky ˇ spolupráce; pozornost se venuje tvorbeˇ distribuovaného SW a metodám a technikám distribuové tvorby SW

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.19/43

Historie SW inˇzen´yrstv´ı – V´yvoj jazyku˚ 1954

Fortran

1958

Algol

1967

Lisp

Simula-67

1969 1970

Smalltalk

Pascal

C

Prolog

1980 1983-1986

Smalltalk-80

Object Pascal

C++

Self

1989

CLOS

1995 2000

Common Lisp

Java

C#

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.20/43

Soucˇ asnost SW inˇzen´yrstv´ı • • • • •

zavedení UML (Unified Modelling Language) do praxe rozvoj formálních technik pro analýzu a verifikaci systému˚ duraz ˚ je kladen na podporu zákazníku, ˚ servis, údržbu softwaru, . . . outsourcing rozvoj agilních metodologií ◦ extrémní programování (extreme programming) ◦ SCRUM ◦ ...

• rozvoj metod návrhu založených na modelech ◦ Model Based Design (Development) ◦ Model Driven Architecture – MDA ◦ ...

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.21/43

Hlavn´ı c´ıle SW inˇzen´yrstv´ı • Management projektu ◦ ◦ ◦

ˇrízení životního cyklu projektu dosažení požadovaného výsledku v požadovaném cˇ ase ⇒ efektivní práce s cˇ asem a tedy i s náklady

• Techniky ◦ analýzy ◦ návrhu ◦ programování ◦ testování ◦ ... • Vlastnosti SW inženýra ◦ ◦ ◦ ◦

základní báze znalostí schopnost aplikovat znalosti schopnost vyhledávat nové informace a osvojit si nové znalosti ...

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.22/43

Softwarov´y produkt ˇ • Clenové jedné komunity vytváˇrejí výrobky (software) pro cˇ leny jiné komunity (uživatelé).

• Softwarový produkt je sbírka poˇcítaˇcových programu, ˚ procedur, pravidel a s nimi spojená dokumentace.

• Software zahrnuje napˇr.: požadavky, specifikace, popisy návrhu, zdrojové texty, testovací data, pˇríruˇcky, . . . Proˇc vlastneˇ vytváˇríme software? ˇ • Rešení problému není možné bez použití poˇcítaˇcu. ˚ ˇ poˇcasí, bankomaty pˇredpoved’

• prostˇredek pro používání nových technologií psaní na poˇcítaˇci, návrh souˇcástek

• zlepšení služeb zákazníkum ˚ (informaˇcní systém knihovny) • snížení nákladu˚ (ˇrízení skladu)

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.23/43

Vztah mezi programem a softwarem Program používá autor, v podmínkách, pro které ho vyvinul.

Program – systém

-

3x

3x

3x

?

Program – výrobek muže ˚ používat, opravovat a rozšiˇrovat kdokoliv; otestovaný a s dokumentací

sbírka spolupracujících programu; ˚ dohodnutá rozhraní; dohodnuté prostˇredky

?

3x -

Softwarový systém

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.24/43

Typy softwarov´ych v´yrobku˚ Generické

• Software se prodává libovolnému zájemci (krabicový software). • Musí být velice dukladn ˚ eˇ otestován, protože opravy chyb jsou vzhledem k velkému rozšíˇrení drahé. Zákaznické (na objednávku)

• Software se vytváˇrí na základeˇ požadavku˚ pro konkrétního zákazníka. • Vetšinou ˇ pro specializované aplikace, pro které vhodný generický software neexistuje.

• Cena zákaznického softwaru je výrazneˇ vyšší. • Dveˇ možnosti jeho tvorby: ◦ zadáním zakázky SW firmeˇ ◦ v rámci vlastní firmy

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.25/43

´ produktu – pouˇzit´ı Vlastnosti softwaroveho (Nejedná se o funkcionalitu, ale o ty vlastnosti softwaru, které jsou potˇreba až tehdy, kdy se software zaˇcne používat.)

• Správnost – míra, do jaké software vyhovuje specifikaci. • Spolehlivost – pravdepodobnost, ˇ že software bude v daném cˇ ase vykonávat zamýšlenou funkci.

• Efektivnost – splnení ˇ kritérií na využití zdroju˚ poˇcítaˇcového systému, na cˇ as potˇrebný na realizaci a dalších kritérií spojených se samotným vývojem (napˇr. náklady).

• Použitelnost – úsilí, které je nutné vynaložit na to, aby se dal software používat.

• Bezpecnost ˇ ˇ – míra odolnosti vuˇ ˚ ci neoprávneným zásahum ˚ do systému.

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.26/43

´ produktu – prˇenos Vlastnosti softwaroveho • Pˇrenositelnost – úsilí, které je nutné pro pˇrenos softwaru z jedné platformy na jinou.

• Znovupoužitelnost – míra, do jaké je možné jednotlivé cˇ ásti softwaru znovu použít v dalších aplikacích.

• Interoperabilita – úsilí, které je potˇrebné k zajištení ˇ spolupráce systému s jinými systémy.

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.27/43

´ produktu – zmeny ˇ Vlastnosti softwaroveho • Udržovatelnost – úsilí, které je potˇreba vynaložit na další vývoj a údržbu ˇ ˇ softwaru podle menících se potˇreb zákazníka a také v dusledku ˚ menícího ˇ se okolí (napˇr. zmena legislativy).

• Testovatelnost – úsilí nutné pro testování vlastností softwaru, napˇr. zda ˇ se chová správne.

• Dokumentovanost – míra, do které jsou všechna rozhodnutí pˇri vývoji ˇ všech etap vývoje. zdokumentována a kontinuita dokumentace v prub ˚ ehu

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.28/43

´ Problemy prˇi v´yvoji softwaru Podstatné, vnitˇrní, nevyhnutelné problémy:

• Složitost – žádné dveˇ cˇ ásti nejsou stejné; složitost je zdrojem dalších problému˚ jako napˇr. komunikace v týmech; je nároˇcné pochopit všechny možné stavy systému; problémy s úpravami a rozšíˇreními, . . .

• Pˇrizpusobivost ˇ zmení, ˇ ˇ by se pˇrizpusobit ˚ – když se neco mel ˚ software a ne naopak.

• Nestálost – mení ˇ se okolí a mení ˇ se i software (nejde o nahrazení ˇ eˇ používaný software; software novým); pˇribývají požadavky na úspešn pˇrežívá hardwarové prostˇredky.

• Neviditelnost – neexistuje pˇrijatelný zpusob ˚ reprezentace softwarového výrobku, který by pokryl všechny aspekty; dokonce ani nejsme schopni urˇcit, co v dané reprezentaci chybí. Syndrom 90% hotovo: Pˇri posuzování hotové cˇ ásti se nevychází z hotového, ale z odpracovaného (napˇr. podle plánu).

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.29/43

´ Problemy prˇi v´yvoji softwaru Problémy, které se nemusí projevit vždy:

• specifikace požadavku˚ ◦ problematická komunikace s uživatelem ◦ nejasná a neúplná formulace požadavku˚ spojená s neucelenou ◦ ◦ ◦ ◦ ◦

pˇredstavou uživatele o výsledném softwarovém systému nejednoznaˇcnost spojená s cˇ astou specifikací požadavku˚ v pˇrirozeném jazyce nestálost, rozporuplnost požadavku˚ pˇrirozená neúplnost a nepˇresnost pˇri specifikaci velkých softwarových systému˚ nedostatek znalostí z analyzované oblasti a z toho vyplývající problémy s plánováním projektu problémy s testováním a validací požadavku˚

• náchylnost softwaru k chybám ◦ Hodneˇ chyb se projeví až pˇri provozu (a ne pˇri vývoji). ◦ Odstranování ˇ chyb vede k návratu v etapách vývoje softwaru. ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.30/43

´ Problemy prˇi v´yvoji softwaru Další problémy, které se nemusí projevit vždy:

• práce v týmu ◦ problémy s organizací práce na velkých softwarových projektech ◦ problémy s plánováním procesu tvorby softwaru ◦ Komunikaˇcní problémy jsou jedním z hlavních zdroju˚ chyb v programech. ◦ extrémní odchylky v produktiviteˇ mezi jednotlivými programátory, až 1:20

• nízká znovupoužitelnost pˇri tvorbeˇ softwaru ◦ V procesu tvorby softwaru je málo standardu˚ a vetšinou ˇ se software tvoˇrí od zaˇcátku. S každým programem se vymýšlí už vymyšlené. ◦ Málo produktu˚ se sestavuje z už existujících souˇcástí.

• problém míry ◦ Metody použitelné na ˇrešení malých problému˚ se nedají pˇrizpusobit ˚ na ˇrešení velkých (složitých) problému. ˚

• software nelze vyrábet ˇ ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.31/43

´ Problemy prˇi v´yvoji softwaru A ješteˇ další problémy, které se nemusí projevit vždy:

• tvorba dokumentace ◦ Tvorba dokumentace je podobná tvorbeˇ vlastního programu. ◦ enormní rozsah dokumentace co do kvantity i rozmanitosti Napˇr. ve velkých vojenských softwarových projektech pˇripadalo 400 anglických slov na každý pˇríkaz v programovacím jazyce Ada. ◦ problémy s udržováním aktuálnosti dokumentace vzhledem ke ˇ zmenám softwaru ◦ problémy s konzistencí a úplností dokumentace

• zpusob ˚ stárnutí softwaru ◦ Pˇridávání nových funkcí ve spojení s cˇ astými opravami chyb vede k postupné degradaci struktury a k snižování spolehlivosti softwarových systému. ˚ ◦ Software se fyzicky neopotˇrebuje.

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.32/43

Typicka´ chybova´ krˇivka hardwaru

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.33/43

Typicka´ chybova´ krˇivka softwaru

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.34/43

Typicka´ chybova´ krˇivka softwaru

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.34/43

Typicka´ chybova´ krˇivka softwaru

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.34/43

Prˇ´ıcˇ iny zastaven´ı softwarov´ych projektu˚ . . . podle analýzy víc jak 350 firem a 8000 aplikací:

• • • • • • • • •

neúplnost nebo nejasnost požadavku˚ (13,1 %) nedostatek zájmu a podpory ze strany uživatele (12,4 %) nedostatek zdroju, ˚ tj. podhodnocený rozpoˇcet a krátké termíny (10,6 %) nerealistické oˇcekávání (9,9 %) ˇ malá podpora od vedení dodavatele nebo odberatele (9,3 %) ˇ zmena požadavku˚ a specifikace (8,7 %) nedostateˇcné plánování (8,1 %) vyvíjený systém už není potˇreba (7,5 %) ...

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.35/43

Katastrofy zpusoben e´ chybou SW ˚ • 1996: Pˇreteˇcení pˇri konverzi 64 b. cˇ ísla v plovoucí ˇrádové cˇ árce na 16 b. celé cˇ íslo se znaménkem reprezentující vertikální rychlost vedlo 40 s po startu k autodestrukci rakety Ariane 5.

• 1985-1987: V dusledku ˇ hardwarové zábrany proti ˚ odstranení ˇ nadmernému ozáˇrení pˇri vývoji lékaˇrského pˇrístroje Therac-25 a SW ˇ eˇ ozáˇreno 6 pacientu˚ (3 na následky zemˇreli). Varující chyb bylo nadmern ˇ je zejména pˇrístup výrobce, který pˇri prvních pˇrípadech nadmerného ˇ ozáˇrení místo nápravy tvrdil, že k nemu nemuže ˚ dojít.

• Další informace jsou napˇr. na URL: http://en.wikipedia.org/wiki/Computer_bug http://www5.in.tum.de/˜huckle/bugse.html

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.36/43

ˇ SW projektu˚ Duleˇ ˚ zite´ faktory pro usp ´ ech • • • • • • • •

zájem, zapojení uživatelu˚ podpora vedení zákazníka jasneˇ definované požadavky dobré plánování realistické oˇcekávání správná dekompozice úlohy ˇ kompetentnost zúˇcastnených ...

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.37/43

´ postrˇehu˚ Freda Brookse Par • Pˇridáním dalších pracovníku˚ do zpoždeného ˇ projektu se tento projekt ješteˇ více zpozdí.

• Napsání pˇrekladaˇce Algolu zabere 6 mesíc ˇ u˚ nezávisle na tom, kolik ho vytváˇrí programátoru. ˚

• Efekt (syndrom) druhého sytému – pˇri návrhu druhé verze systému hrozí rizika: ◦ pˇríliš složitý a neefektivní systém ˇ Systém není dokonalý, když k nemu nelze nic pˇridat, ˇ nelze nic odstranit. ale tehdy, když z neho

◦ nepoužití nových technologií

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.38/43

Studijn´ı koutek • • • •

ˇ by vám pomoci s orientací pˇri studiu. Mel ˇ vyhrazeno posledních 10 minut pˇrednášky. Je pro nej Zde uvedené informace se nezkoušejí. ˇ na to, co vás zajímá. Mužete ˚ posílat námety

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.39/43

Vysoke´ ucˇ en´ı technicke´ v Brneˇ • Historie ◦ 1849 – nemecko-ˇ ˇ ceské technické uˇcilišteˇ ˇ ◦ 1899 – Ceská vysoká škola technická v Brneˇ ◦ 1956 – Vysoké uˇcení technické v Brneˇ • Vedení ◦ Nejvyšším pˇredstavitelem vysoké školy je rektor. ◦ 51. rektorem VUT v Brneˇ je prof. Ing. Karel Rais, CSc., MBA • Fakulty ◦ Fakulta stavební - FAST ◦ Fakulta strojního inženýrství - FSI ◦ Fakulta elektrotechniky a komunikaˇcních technologií - FEKT ◦ Fakulta informacních ˇ technologií - FIT ◦ Fakulta architektury - FA ◦ Fakulta výtvarných umení ˇ - FAVU ◦ Fakulta podnikatelská - FP ◦ Fakulta chemická - FCH ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.40/43

Fakulta informacˇ n´ıch technologi´ı • Historie ◦ 1964 – Ústav informatiky a výpoˇcetní techniky na FE (pozdeji ˇ FEI) ◦ 2002 – Fakulta informaˇcních technologií (FIT) • Vedení ◦ Nejvyšším pˇredstavitelem fakulty je dekan. ˇ ◦ 1. dekanem ˇ FIT byl (2002-2008) prof. Ing. Tomáš Hruška, CSc. ◦ 2. dekanem ˇ FIT je doc. Ing. Jaroslav Zendulka, CSc. ◦ Studijním poradcem je Ing. Miloš Eysselt, CSc. ◦ Prodekanem ˇ ˇ pro vzdelávací cˇ innost v bakaláˇrském studiu je Ing. Bohuslav Kˇrena, Ph.D. ˇ v magisterském studiu je Ing. Richard Ruži ˚ cka, Ph.D.

• Ústavy ◦ Ústav inteligentních systému˚ ◦ Ústav informaˇcních systému˚ ◦ Ústav poˇcítaˇcových systému˚ ◦ Ústav poˇcítaˇcové grafiky a multimédií ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.41/43

´ FIT Akademick´y senat Akademický senát FIT VUT v Brneˇ

• • • •

ˇ vnitˇrní pˇredpisy VUT v Brne, ˇ schvaluje pˇredpisy FIT, které doplnují ˇ volí dekana a schvaluje rozpoˇcet FIT, je volen akademickou obcí FIT (a tedy i studenty), je složen ze dvou komor: ◦ komora akademických pracovníku˚ (8 cˇ lenu) ˚ ◦ studentská komora (4 + 1 cˇ len)

• http://www.fit.vutbr.cz/FIT/AS Vnitˇrní pˇredpisy FIT, které se nejvíce dotýkají studentu: ˚

• • • •

ˇ ˇ ˇ ˇ Smernice dekana doplnující studijní a zkušební ˇrád VUT v Brne, ˇ ˇ ˇ ˇ Smernice dekana doplnující stipendijní ˇrád VUT v Brne, Disciplinární ˇrád pro studenty FIT. http://www.fit.vutbr.cz/info/predpisy

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.42/43

´ VUT v Brneˇ Akademick´y senat • • • •

schvaluje pˇredpisy platné pro celou školu, ˇ volí rektora a schvaluje rozpoˇcet VUT v Brne, je volen akademickou obcí celé školy, je složen ze dvou komor: ◦ komora akademických pracovníku˚ ◦ studentská komora

• FIT zastupují 2 zamestnanci ˇ a 1 student. Vnitˇrní pˇredpisy, které se nejvíce dotýkají studentu: ˚

• Studijní a zkušební ˇrád VUT v Brne, ˇ • Stipendijní ˇrád VUT v Brne, ˇ • http://www.fit.vutbr.cz/info/predpisy

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2010/2011 – p.43/43