Úvod do softwarového inženýrství IUS 2009/2010 p.1/40

Transkript

1 Úvod do softwarového inženýrství IUS 2009/ přednáška Ing. Radek Kočí, Ph.D. Ing. Bohuslav Křena, Ph.D. Úvod do softwarového inženýrství IUS 2009/2010 p.1/40

2 Dekompozice složitých problémů rozdělení (dekompozice) složitějšího problému na jednodušší (lehčí zvládnutí problému) rozhraní podsystémů Problem Úvod do softwarového inženýrství IUS 2009/2010 p.2/40

3 Dekompozice složitých problémů Přináší lépe zvládnutelné podsystémy soustředění pozornosti na jeden podsystém prezentovatelnost dílčího problému bez rušivých vlivů podsystémy se mohou vyvíjet nezávisle skutečně velké systémy se bez dekompozice nedají zvládnout Zvýšená pozornost koordinace tvorby rozhraní integrace a testování podsystémů Úvod do softwarového inženýrství IUS 2009/2010 p.3/40

4 Proces vývoje softwaru Proces, ve kterém se potřeby uživatele transformují na požadavky na SW, požadavky na SW se transformují na návrh, návrh se implementuje, implementace se testuje a nakonec předá uživateli. SW proces definuje kdo dělá co a kdy jak dosáhnout požadovaného cíle Úvod do softwarového inženýrství IUS 2009/2010 p.4/40

5 Životní cyklus softwaru Činnosti spojené s vývojem softwaru analýza a specifikace požadavků (8 %), architektonický a podrobný návrh (7 %), implementace (12 %), integrace (např. se stávající částí SW) a testování (6 %), provoz a údržba (67 %). Úsilí věnované pečlivé analýze a návrhu se vrátí úsporou nákladů později. Například dokud by dvakrát větší úsilí věnované analýze a návrhu znamenalo polovinu nákladů při provozu a údržbě, pak celkově ušetříme 18 % nákladů: specifikace požadavků: +8 % architektonický a podrobný návrh: +7 % provoz a údržba: -33 % Na analýze a návrhu se nevyplatí šetřit! Úvod do softwarového inženýrství IUS 2009/2010 p.5/40

6 Životní cyklus softwaru Existuje mnoho přístupů k vývoji softwaru. Podstaty těchto přístupů jsou vyjádřeny v modelech životního cyklu softwaru. Model životního cyklu definuje etapy vývoje softwaru, pro každou etapu definuje nutné činnosti, pro každou etapu definuje její vstupy a výstupy. Rozdíly v modelech jsou zejména v definování jednotlivých etap a definování posloupnosti etap. Úvod do softwarového inženýrství IUS 2009/2010 p.6/40

7 Etapy životního cyklu softwaru Analýza a specifikace požadavků transformace neformálních požadavků uživatele do strukturovaného popisu požadavků, zdůraznění požadavků uživatele, ne jak toho docílit (realizovat), provedení studie vhodnosti, identifikace a analýza rizik, získávání, analýza, definování a specifikace požadavků, plánování akceptačního testování. Úvod do softwarového inženýrství IUS 2009/2010 p.7/40

8 Etapy životního cyklu softwaru Architektonický návrh ujasnění koncepce systému, dekompozice systému, definování vztahů mezi částmi systému, specifikace funkcionality a ohraničení podsystémů, plánování testování systému, plánování nasazení systému do provozu, dohoda o postupu nasazování podsystémů, dohoda o plánu zaškolování uživatelů. Úvod do softwarového inženýrství IUS 2009/2010 p.8/40

9 Etapy životního cyklu softwaru Podrobný návrh podrobná specifikace softwarových součástí, specifikace algoritmů realizujících požadované funkce, specifikace rozhraní pro jednotlivé součásti, specifikace logické a fyzické struktury údajů, které zpracovává příslušná součást, specifikace způsobu ošetřování chybových a neočekávaných stavů, plán prací při implementaci součásti, plán testování součásti, návrh testovacích dat, specifikace požadavků na lidské zdroje (odhad trvání a nákladů projektu). Úvod do softwarového inženýrství IUS 2009/2010 p.9/40

10 Etapy životního cyklu softwaru Implementace a testování součástí programová realizace softwarových součástí, vypracování dokumentace k součástem, testování implementovaných součástí, začátek školení budoucích uživatelů. Integrace a testování systému spojení součástí do podsystémů, testování podsystémů, integrace podsystémů do celého systému, testování podsystémů a celého systému oprava nalezených chyb, návraty k etapě implementace. Úvod do softwarového inženýrství IUS 2009/2010 p.10/40

11 Etapy životního cyklu softwaru Akceptační testování a instalace testování systému uživatelem, operace přebírání SW produktu, školení používání systému, nasazení systému. Provoz a údržba zabezpečení provozu softwaru, řešení problémů s nasazením softwaru, řešení problémů s používaním softwaru, opravy, rozšiřování, přizpůsobování softwaru podle požadavků okolí. Úvod do softwarového inženýrství IUS 2009/2010 p.11/40

12 Model životního cyklu softwaru definuje jednotlivé kroky (etapy), které je nutné vykonat, definuje časovou následnost kroků, nedefinuje délku trvání kroků a jejich rozsah, možnost návratu k předcházejícímu kroku, každá etapa musí být dobře definovaná, každá etapa vytváří reálné výstupy, správnost každé etapy lze vyhodnotit. Úvod do softwarového inženýrství IUS 2009/2010 p.12/40

13 Vodopádový model životního cyklu softwaru následující etapa začne až po ukončení předcházející Požadavky Návrh Implementace testování jednotek Testování systému Provoz, údržba Úvod do softwarového inženýrství IUS 2009/2010 p.13/40

14 Vodopádový model Nevýhody reálné projekty většinou nesledují etapy v definovaném pořadí uživatel není schopen předem stanovit (přesně!) všechny požadavky zákazník vidí spustitelnou verzi až v závěrečných fázích projektu odhalení nedostatků příliš pozdě Výhody lepší než neřízený chaotický přístup při stálých požadavcích zaručuje nejlepší strukturu výsledného produktu Úvod do softwarového inženýrství IUS 2009/2010 p.14/40

15 V-model Analýza požadavků plán akceptačních testů Architektonický návrh plán testů systému Podrobný návrh plán testů součástí Testy součástí Akceptační testy Testy systému Implementace V-model je varianta vodopádového modelu s větším důrazem na testování. Úvod do softwarového inženýrství IUS 2009/2010 p.15/40

16 Iterativní modely životního cyklu systém se vyvíjí v iteracích v každé iteraci se vytvoří reálný výsledek náročnější řízení horší výsledná struktura S S N I N I... T T čas Úvod do softwarového inženýrství IUS 2009/2010 p.16/40

17 Iterativní modely životního cyklu Inkrementální modely na základě specifikace celého systému se stanoví ucelené části systému systém se vytváří a předává uživateli po částech Spirálový model kombinace prototypování a analýzy rizik (management) jednotlivé kroky se ve vývoji opakují (na vyšším stupni zvádnuté problematiky) Agilní metodologie např. extrémní programování Rational Unified Process RUP Úvod do softwarového inženýrství IUS 2009/2010 p.17/40

18 Spirálový model Úvod do softwarového inženýrství IUS 2009/2010 p.18/40

19 Rational Unified Process RUP výsledek výzkumu řady velkých firem koordinovaný firmou Rational, využívání existujících komponent, vývoj softwarového produktu iteračním způsobem, verze systému, po každé iteraci spustitelný kód model softwarového systému je vizualizován, UML,... průběžná kontrola kvality produktu, objektivní měření, metriky,... správa požadavků na softwarový systém, umění získávání požadavků od zákazníka řízení změn systému každá změna je přijatelná, všechny změny jsou sledovatelné Úvod do softwarového inženýrství IUS 2009/2010 p.19/40

20 Rational Unified Process RUP Úvod do softwarového inženýrství IUS 2009/2010 p.20/40

21 Problémy s výběrem správného modelu Neexistuje projekt, který by byl řízen přesně podle jednoho z modelů životního cyklu. Uvedené modely jsou pouze konceptuální, žádný projekt se nemůže striktně řídit pravidly jednoho z nich! Většinou není možné na začátku specifikovat celé zadání. Jednotlivé etapy nelze zcela uzavřít v průběhu projektu. Úvod do softwarového inženýrství IUS 2009/2010 p.21/40

22 Aktéři v životním cyklu softwaru Zákazník sponzoruje vývoj SW specifikuje požadavky na SW Dodavatel vyvíjí systém má závazky vůči zákazníkovi komunikuje s uživatelem (testování,... ) Uživatel testuje a používá systém upřesňuje požadavky na SW Úvod do softwarového inženýrství IUS 2009/2010 p.22/40

23 Role v softwarovém týmu analytik návrhář programátor odborník na testování odborník na údržbu auditor, skupina na zabezpečení kvality management podpůrný personál Úvod do softwarového inženýrství IUS 2009/2010 p.23/40

24 Analytik vs. programátor Programátorská profese programátoři navrhují technické řešení systému, implementují, ladí a testují komponenty práce má předem daný cíl mezilidské vztahy nejsou většinou komplikované výsledky práce jsou okamžitě zřejmé. Analytická profese analytici vytvářejí cíle projektu, zpracovávají specifikační dokumenty a jejich odsouhlasení zákazníkem vyžaduje diplomatické vlohy při jednání s lidmi mezilidské vztahy jsou většinou komplikované analytická fáze nemá jasné ohraničení. Úvod do softwarového inženýrství IUS 2009/2010 p.24/40

25 Jak tráví čas programátoři? psaní programů 13% čtení programů a příruček 6% komunikace týkající se práce (konzultace,... ) 42% ostatní (všetně osobních věcí) 39% Úvod do softwarového inženýrství IUS 2009/2010 p.25/40

26 Etapy životního cyklu softwaru analýza a specifikace požadavků návrh implementace testování provoz, údržba Úvod do softwarového inženýrství IUS 2009/2010 p.26/40

27 Etapy životního cyklu softwaru analýza a specifikace požadavků návrh implementace testování provoz, údržba management Úvod do softwarového inženýrství IUS 2009/2010 p.26/40

28 Analýza a specifikace požadavků Cíl: Stanovení služeb, které zákazník požaduje od systému a vymezení podmínek jeho vývoje a provozu. Dobře identifikované požadavky snižují cenu vývoje! Proces tvorby požadavků získávání požadavků (naslouchat) analýza požadavků (přemýšlet) definice požadavků (psát) Požadavky versus řešení více uživatelů stejná podstata požadavku více alternativ řešení stejného požadavku žádné řešení požadavku je nerealizovatelný Úvod do softwarového inženýrství IUS 2009/2010 p.27/40

29 Specifikace požadavků Definice požadavků Specifikace požadavků Specifikace softwaru Požadavky pro zákazníka (neformální, abstraktní) Podrobné požadavky (formální, strukturovaný text) Podrobný popis pro vývojáře Stavy požadavku přijatý akceptovaný zrušený řešený (definovaný, specifikovaný, implementovaný, testovaný) ukončený Úvod do softwarového inženýrství IUS 2009/2010 p.28/40

30 Typy požadavků Funkcionální požadavky např. výpočet mzdy, odvodů,... Požadavky na provoz systému statické např. počet uživatelů,... dynamické např. čas odezvy, počet transakcí na jednotku času,... Požadavky na výsledný systém počítačové vybavení např. HW náročnost (pamět,... ) programové vybavení např. operační systém, programovací jazyky,... vyvíjený software např. efektivnost, spolehlivost, odolnost vůči chybám, přenositelnost, bezpečnost,... Úvod do softwarového inženýrství IUS 2009/2010 p.29/40

31 Typy požadavků Požadavky na vývojový proces dodržování norem odevzdání systému Požadavky na rozhraní software uživatel software jiné součásti systému (HW, SW) Externí požadavky legislativní požadavky (ochrana informací,... ) Úvod do softwarového inženýrství IUS 2009/2010 p.30/40

32 Typy požadavků Požadavky na vývojový proces dodržování norem odevzdání systému Požadavky na rozhraní software uživatel software jiné součásti systému (HW, SW) Externí požadavky legislativní požadavky (ochrana informací,... ) měřitelnost požadavků Úvod do softwarového inženýrství IUS 2009/2010 p.30/40

33 Kroky při specifikaci požadavků Studie vhodnosti odhad, zda je reálné vytvořit systém s danými vlastnostmi za daných podmínek rychlé, levné Analýza požadavků zkoumání současného stavu pozorování, diskuze, prototypování Definování požadavků transformace informací z analýzy do dokumentu pro uživatele / zákazníka Specifikace požadavků soustřed uje se na software, ne na proces jeho tvorby často se vykonává paralelně s architektonickým návrhem Úvod do softwarového inženýrství IUS 2009/2010 p.31/40

34 Metody získávání informací Kvalitní získávání informací o problémové oblasti a požadavcích snižuje riziko vytvoření systému, který nebude vyhovovat požadavkům uživatele. Důležitá je také motivace ze strany zákazníka (uživatele). Různé metody získávání informací interview (orientační, strukturované) dotazníky studium dokumentů pozorování prací u zákazníka přímá účast na pracech zákazníka analýza existujícího softwarového systému Úvod do softwarového inženýrství IUS 2009/2010 p.32/40

35 Vlastnosti specifikace požadavků Specifikace by měla být správná vyvíjený SW by měl splňovat každý požadavek jednoznačná neumožňuje více interpretací úplná obsahuje všechny důležité požadavky a definice reakcí systému na všechny třídy vstupních údajů verifikovatelná existuje proces kontroly, zda SW splňuje požadavek konzistentní požadavek není v rozporu s jinými požadavky sledovatelná původ (smysl) požadavku je jasný modifikovatelná změna požadavku je možná se zachováním struktury a stylu požadavku seřazená podle důležitosti seskupení požadavků do tříd důležitosti požadavky na SW se v čase vyvíjí Úvod do softwarového inženýrství IUS 2009/2010 p.33/40

36 Problémy při specifikaci požadavků Různorodost požadavků různí uživatelé mají různé požadavky a priority kompromis (měnící se) různé požadavky uživatele a zákazníka (objednavatele) špatná predikovatelnost dopadu nového systému na organizaci, kde se nasadí. Chyby, které se neodhalí při specifikaci: 65% z nich se odhalí při návrhu 2% z nich se odhalí při implementaci 30% z nich se odhalí při testování 3% z nich se odhalí v provozu Úvod do softwarového inženýrství IUS 2009/2010 p.34/40

37 Problémy při specifikaci požadavků Přibližný odhad nákladů na opravu chyb ve specifikaci Etapa Náklady (člověko-hodiny) Specifikace 2 Návrh 5 Implementace 15 Akceptační testování 50 Údržba 150 Úvod do softwarového inženýrství IUS 2009/2010 p.35/40

38 Problémy při specifikaci požadavků Komunikace se zákazníkem zákazník není schopen přesně formulovat požadavky terminologie vývojář (analytik) se neorientuje v doménové problematice zákazník se neorientuje v problematice vývoje softwaru vyčleněný člověk od zákazníka; specialista ve vývojovém týmu problém rozhodování, jaké požadavky už nezačleňovat do specifikace Problémy plynou z použití přirozeného jazyka. Vyřazení Používají systém k výpůjčkám knih. Kdo? Deformace, zkreslení Čtenáři si nemohou půjčit další knihu, dokud nevrátí knihy s prošlou výpůjční lhůtou. Když je zaplatí, tak mohou! Zobecnění Každý, kdo si chce vypůjčit knihu, musí mít průkazku. A co výpůjčky mezi knihovnami? Úvod do softwarového inženýrství IUS 2009/2010 p.36/40

39 Několik poznámek ke specifikaci požadavků požadavky pište jasně a jednoznačně bud te konzistentní v používání názvů udržujte specifikaci čitelnou pro zákazníka poznamenejte si datum vytvoření požadavku seřad te požadavky podle priorit ve specifikaci nenavrhujte řešení specifikujte situace, ve kterých se porušuje akceptovatelné chování validujte požadavky používejte více pohledů prototyp snižuje riziko špatného pochopení požadavků slabá specifikace špatný odhad nákladů používejte podpůrné prostředky, ale bud te realističtí Úvod do softwarového inženýrství IUS 2009/2010 p.37/40

40 Myšlenka na závěr... Úlohou analytika je dát zákazníkovi včas a za určenou cenu ne to, co chce, ale to, o čem nikdy ani nesnil, že chce; až když to dostane, zjistí, že je to přesně to, co vlastně celý čas chtěl. Úvod do softwarového inženýrství IUS 2009/2010 p.38/40

41 Studijní koutek Tituly a oslovení Akademické tituly Bc. bakalář (angl. bachelor, lat. baccalaureus) BcA. bakalář umění (lat. baccalaureus artis) Ing. inženýr (angl. engineer = strojník) Ing. Arch. inženýr architekt Mgr. magistr (doslovně učitel) MgA. magistr umění RNDr. doktor přírodních věd (rerum naturalium doctor) MUDr. doktor veškeré medicíny (medicinae universae doctor) JUDr. doktor práv (juris utriusque doctor) MVDr., PhDr., PaedDr., PharmDr., ThDr., ThLic., RSDr.,... = asistent MBA (angl. Master of Business Administration ) navazující studium zaměřené na management Úvod do softwarového inženýrství IUS 2009/2010 p.39/40

42 Studijní koutek Tituly a oslovení Vědecké hodnosti Ph.D. doktor (lat. philosophiae doctor) Th.D. (lat. theologiae doctor) Dr. doktor = učený CSc. kandidát věd (candidatus scientiarum) = odborný asistent DrSc. / DSc. doktor věd (lat. doctor scientiarum) akademik člen akademie věd ČR Pedagogické hodnosti doc. docent prof. profesor Učitelům na střední škole se říká profesor, přestože titul prof. nemají. Čestná hodnost Dr. h. c. doctor honoris causa Úvod do softwarového inženýrství IUS 2009/2010 p.40/40