Úvod do softwarového inženýrství IUS 2009/2010 2. pˇrednáška Ing. Radek Koˇc´ı, Ph.D. Ing. Bohuslav Kˇrena, Ph.D.
´ ´ inˇzen´yrstv´ı IUS 2009/2010 – p.1/40 Uvod do softwaroveho
´ u˚ Dekompozice sloˇzit´ych problem • rozdelení ˇ ˇ (dekompozice) složitejšího problému na jednodušší (lehˇcí zvládnutí problému)
• rozhraní podsystému˚
Problem
1
2
3
4
1
2
3
4
´ ´ inˇzen´yrstv´ı IUS 2009/2010 – p.2/40 Uvod do softwaroveho
´ u˚ Dekompozice sloˇzit´ych problem Pˇrináší
• • • • •
lépe zvládnutelné podsystémy ˇ pozornosti na jeden podsystém soustˇredení prezentovatelnost dílˇcího problému bez rušivých vlivu˚ podsystémy se mohou vyvíjet nezávisle ˇ eˇ velké systémy se bez dekompozice nedají zvládnout skutecn
Zvýšená pozornost
• koordinace tvorby rozhraní • integrace a testování podsystému˚
´ ´ inˇzen´yrstv´ı IUS 2009/2010 – p.3/40 Uvod do softwaroveho
Proces v´yvoje softwaru Proces, ve kterém
• • • • •
se potˇreby 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ˇredá uživateli.
SW proces definuje
• • • •
kdo ˇ co delá a kdy ⇒ jak dosáhnout požadovaného cíle
´ ´ inˇzen´yrstv´ı IUS 2009/2010 – p.4/40 Uvod do softwaroveho
ˇ Zivotn´ ı cyklus softwaru ˇ Cinnosti spojené s vývojem softwaru
• • • • •
analýza a specifikace požadavku˚ (8 %), architektonický a podrobný návrh (7 %), implementace (12 %), integrace (napˇr. se stávající cˇ ástí SW) a testování (6 %), provoz a údržba (67 %).
ˇ ˇ Úsilí venované peˇclivé analýze a návrhu se vrátí úsporou nákladu˚ pozdeji. ˇ úsilí venované ˇ Napˇríklad dokud by dvakrát vetší analýze a návrhu znamenalo ˇ pak celkoveˇ ušetˇríme 18 % nákladu: ˚ polovinu nákladu˚ pˇri provozu a údržbe,
• specifikace požadavku: ˚ +8 % • architektonický a podrobný návrh: +7 % • provoz a údržba: -33 % Na analýze a návrhu se nevyplatí šetˇrit! ´ ´ inˇzen´yrstv´ı IUS 2009/2010 – p.5/40 Uvod do softwaroveho
ˇ Zivotn´ ı cyklus softwaru ˇ Existuje mnoho pˇrístupu˚ k vývoji softwaru. Podstaty techto pˇrístupu˚ jsou vyjádˇreny v modelech životního cyklu softwaru. Model životního cyklu
• definuje etapy vývoje softwaru, • pro každou etapu definuje nutné cˇ 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.
´ ´ inˇzen´yrstv´ı IUS 2009/2010 – p.6/40 Uvod do softwaroveho
Etapy zˇ ivotn´ıho cyklu softwaru Analýza a specifikace požadavku˚
• transformace neformálních požadavku˚ uživatele do strukturovaného popisu požadavku, ˚ ˇ požadavku˚ uživatele, ne jak toho docílit (realizovat), zdurazn ˚ ení provedení studie vhodnosti, identifikace a analýza rizik, získávání, analýza, definování a specifikace požadavku, ˚ plánování akceptaˇcního testování.
Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2008 For Evaluation Only.
• • • •
´ ´ inˇzen´yrstv´ı IUS 2009/2010 – p.7/40 Uvod do softwaroveho
Etapy zˇ ivotn´ıho cyklu softwaru Architektonický návrh ˇ koncepce systému, ujasnení dekompozice systému, definování vztahu˚ mezi cˇ ástmi systému, specifikace funkcionality a ohraniˇcení podsystému, ˚ plánování testování systému, plánování nasazení systému do provozu, dohoda o postupu nasazování podsystému, ˚ dohoda o plánu zaškolování uživatelu. ˚
Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2008 For Evaluation Only.
• • • • • •
´ ´ inˇzen´yrstv´ı IUS 2009/2010 – p.8/40 Uvod do softwaroveho
Etapy zˇ ivotn´ıho cyklu softwaru Podrobný návrh
• • • •
podrobná specifikace softwarových souˇcástí,
• • • •
specifikace zpusobu ˚ ošetˇrování chybových a neoˇcekávaných stavu, ˚
specifikace algoritmu˚ realizujících požadované funkce, specifikace rozhraní pro jednotlivé souˇcásti,
plán prací pˇri implementaci souˇcásti, plán testování souˇcásti, návrh testovacích dat, specifikace požadavku˚ na lidské zdroje (odhad trvání a nákladu˚ projektu).
Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2008 For Evaluation Only.
specifikace logické a fyzické struktury údaju, ˚ které zpracovává pˇríslušná souˇcást,
´ ´ inˇzen´yrstv´ı IUS 2009/2010 – p.9/40 Uvod do softwaroveho
Etapy zˇ ivotn´ıho cyklu softwaru ˇ Implementace a testování soucástí
• • • •
programová realizace softwarových souˇcástí, vypracování dokumentace k souˇcástem, testování implementovaných souˇcástí, zaˇcátek školení budoucích uživatelu. ˚
• • • •
spojení souˇcástí do podsystému, ˚ testování podsystému, ˚ integrace podsystému˚ do celého systému, testování podsystému˚ a celého systému oprava nalezených chyb, návraty k etapeˇ implementace.
Edited by Foxit Reader Copyright(C) by Foxit Software Company,2005-2008 For Evaluation Only.
Integrace a testování systému
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.10/40
Etapy zˇ ivotn´ıho cyklu softwaru ˇ testování a instalace Akceptacní
• testování systému uživatelem, • operace pˇrebírání SW produktu, • školení používání systému, nasazení systému. Provoz a údržba
• • • •
zabezpeˇcení provozu softwaru, ˇrešení problému˚ s nasazením softwaru, ˇrešení problému˚ s používaním softwaru, opravy, rozšiˇrování, pˇrizpusobování ˚ softwaru podle požadavku˚ okolí.
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.11/40
Model zˇ ivotn´ıho cyklu softwaru • • • • • • •
definuje jednotlivé kroky (etapy), které je nutné vykonat, definuje cˇ asovou následnost kroku, ˚ nedefinuje délku trvání kroku˚ a jejich rozsah, možnost návratu k pˇredcházejícímu kroku, každá etapa musí být dobˇre definovaná, každá etapa vytváˇrí reálné výstupy, správnost každé etapy lze vyhodnotit.
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.12/40
´ Vodopadov´ y model zˇ ivotn´ıho cyklu softwaru • následující etapa zaˇcne až po ukonˇcení pˇredcházející
Požadavky
6
? Návrh
6
? Implementace testování jednotek
6
? Testování systému
6
? Provoz, údržba
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.13/40
´ Vodopadov´ y model Nevýhody
• reálné projekty vetšinou ˇ nesledují etapy v definovaném poˇradí • uživatel není schopen pˇredem stanovit (pˇresne!) ˇ všechny požadavky • zákazník vidí spustitelnou verzi až v závereˇ ˇ cných fázích projektu ⇒ odhalení nedostatku˚ pˇríliš pozdeˇ Výhody
• lepší než neˇrízený chaotický pˇrístup • pˇri stálých požadavcích zaruˇcuje nejlepší strukturu výsledného produktu
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.14/40
V-model Analýza požadavku˚ plán akceptaˇcních testu˚
ˇ testy Akceptacní
@ R @
Architektonický návrh plán testu˚ systému
Testy systému
@ R @ Podrobný návrh plán testu˚ souˇcástí
@
ˇ Testy soucástí
R @
Implementace
ˇ V-model je varianta vodopádového modelu s vetším durazem ˚ na testování. ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.15/40
Iterativn´ı modely zˇ ivotn´ıho cyklu • • • •
systém se vyvíjí v iteracích v každé iteraci se vytvoˇrí reálný výsledek ˇ ˇrízení nároˇcnejší horší výsledná struktura
-
S
-
S
?
?
N
N
?
...
?
I
I
? T
? T
-
cˇ as ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.16/40
Iterativn´ı modely zˇ ivotn´ıho cyklu Inkrementální modely
• na základeˇ specifikace celého systému se stanoví ucelené cˇ ásti systému • systém se vytváˇrí a pˇredává uživateli po cˇ á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ˇr. extrémní programování Rational Unified Process – RUP
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.17/40
´ y model Spiralov´
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.18/40
Rational Unified Process – RUP • výsledek výzkumu ˇrady velkých firem koordinovaný firmou Rational, • využívání existujících komponent, • vývoj softwarového produktu iteraˇcním zpusobem, ˚ ◦ verze systému, po každé iteraci spustitelný kód • model softwarového systému je vizualizován, ◦ UML, . . . • prub ˇ ˚ ežná kontrola kvality produktu, ◦ objektivní meˇ ˇ rení, metriky, . . . • správa požadavku˚ na softwarový systém, ◦ umení ˇ získávání požadavku˚ od zákazníka • ˇrízení zmen ˇ systému ◦ každá zmena ˇ ˇ jsou sledovatelné je pˇrijatelná, všechny zmeny
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.19/40
Rational Unified Process – RUP
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.20/40
´ ˇ ´ eho ´ modelu Problemy s v´yberem spravn • Neexistuje projekt, který by byl ˇrízen pˇresneˇ podle jednoho z modelu˚ životního cyklu.
• Uvedené modely jsou pouze konceptuální, žádný projekt se nemuže ˚ striktneˇ ˇrídit pravidly jednoho z nich!
• Vetšinou ˇ není možné na zaˇcátku specifikovat celé zadání. • Jednotlivé etapy nelze zcela uzavˇrít v prub ˇ ˚ ehu projektu.
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.21/40
Akte´ rˇi v zˇ ivotn´ım cyklu softwaru Zákazník
• sponzoruje vývoj SW • specifikuje požadavky na SW Dodavatel
• vyvíjí systém • má závazky vuˇ ˚ ci zákazníkovi • komunikuje s uživatelem (testování, . . . ) Uživatel
• testuje a používá systém • upˇresnuje ˇ požadavky na SW
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.22/40
´ t´ymu Role v softwarovem • • • • • • • •
analytik návrháˇr programátor odborník na testování odborník na údržbu auditor, skupina na zabezpeˇcení kvality management podpurný ˚ personál
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.23/40
´ Analytik vs. programator Programátorská profese
• programátoˇri navrhují technické ˇrešení systému, implementují, ladí a testují komponenty
• práce má pˇredem daný cíl • mezilidské vztahy nejsou vetšinou ˇ komplikované • výsledky práce jsou okamžiteˇ zˇrejmé. Analytická profese
• analytici vytváˇrejí cíle projektu, zpracovávají specifikaˇcní dokumenty a jejich odsouhlasení zákazníkem
• vyžaduje diplomatické vlohy pˇri jednání s lidmi • mezilidské vztahy jsou vetšinou ˇ komplikované • analytická fáze nemá jasné ohraniˇcení.
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.24/40
´ ı cˇ as programato ´ rˇi? Jak trav´ psaní programu˚ cˇ tení programu˚ a pˇríruˇcek komunikace týkající se práce (konzultace, . . . ) ˇ ostatní (všetneˇ osobních vecí)
13% 6% 42% 39%
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.25/40
Etapy zˇ ivotn´ıho cyklu softwaru • • • • •
analýza a specifikace požadavku˚ návrh implementace testování provoz, údržba
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.26/40
Etapy zˇ ivotn´ıho cyklu softwaru • • • • •
analýza a specifikace požadavku˚ návrh implementace testování provoz, údržba
management
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.26/40
Anal´yza a specifikace poˇzadavku˚ Cíl: Stanovení služeb, které zákazník požaduje od systému a vymezení podmínek jeho vývoje a provozu. Dobˇre identifikované požadavky snižují cenu vývoje! Proces tvorby požadavku˚
• získávání požadavku˚ (naslouchat) • analýza požadavku˚ (pˇremýšlet) • definice požadavku˚ (psát) Požadavky versus ˇrešení
• více uživatelu˚ ⇒ stejná podstata požadavku • více alternativ ˇrešení stejného požadavku • žádné ˇrešení požadavku ⇒ je nerealizovatelný
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.27/40
Specifikace poˇzadavku˚ Definice požadavku˚
? Specifikace požadavku˚
Požadavky pro zákazníka (neformální, abstraktní) Podrobné požadavky (formální, strukturovaný text)
? Specifikace softwaru
Podrobný popis pro vývojáˇre
Stavy požadavku
• • • • •
pˇrijatý akceptovaný zrušený ˇrešený (definovaný, specifikovaný, implementovaný, testovaný) ukonˇcený ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.28/40
Typy poˇzadavku˚ Funkcionální požadavky
• napˇr. výpoˇcet mzdy, odvodu, ˚ ... Požadavky na provoz systému
• statické – napˇr. poˇcet uživatelu, ˚ ... • dynamické – napˇr. cˇ as odezvy, poˇcet transakcí na jednotku cˇ asu, . . . Požadavky na výsledný systém
• poˇcítaˇcové vybavení – napˇr. HW nároˇcnost (pamet’, ˇ ...) • programové vybavení – napˇr. operaˇcní systém, programovací jazyky, . . . • vyvíjený software – napˇr. efektivnost, spolehlivost, odolnost vuˇ ˚ ci chybám, pˇrenositelnost, bezpeˇcnost, . . .
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.29/40
Typy poˇzadavku˚ Požadavky na vývojový proces
• dodržování norem • odevzdání systému Požadavky na rozhraní
• software → uživatel • software → jiné souˇcásti systému (HW, SW) Externí požadavky
• legislativní požadavky (ochrana informací, . . . )
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.30/40
Typy poˇzadavku˚ Požadavky na vývojový proces
• dodržování norem • odevzdání systému Požadavky na rozhraní
• software → uživatel • software → jiné souˇcásti systému (HW, SW) Externí požadavky
• legislativní požadavky (ochrana informací, . . . )
ˇ ritelnost požadavku˚ meˇ
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.30/40
Kroky prˇi specifikaci poˇzadavku˚ Studie vhodnosti
• odhad, zda je reálné vytvoˇrit systém s danými vlastnostmi za daných podmínek
• rychlé, levné Analýza požadavku˚
• zkoumání souˇcasného stavu • pozorování, diskuze, prototypování Definování požadavku˚
• transformace informací z analýzy do dokumentu pro uživatele / zákazníka Specifikace požadavku˚
• soustˇred’uje se na software, ne na proces jeho tvorby • cˇ asto se vykonává paralelneˇ s architektonickým návrhem
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.31/40
´ an´ ´ ı informac´ı Metody z´ıskav Kvalitní získávání informací o problémové oblasti a požadavcích snižuje riziko vytvoˇrení systému, který nebude vyhovovat požadavkum ˚ uživatele. Duležitá ˚ je také motivace ze strany zákazníka (uživatele). Ruzné ˚ metody získávání informací
• • • • • •
interview (orientaˇcní, strukturované) dotazníky studium dokumentu˚ pozorování prací u zákazníka pˇrímá úˇcast na pracech zákazníka analýza existujícího softwarového systému
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.32/40
Vlastnosti specifikace poˇzadavku˚ ˇ být Specifikace by mela
• správná ⇒ vyvíjený SW by mel ˇ splnovat ˇ každý požadavek • jednoznaˇcná ⇒ neumožnuje ˇ více interpretací • úplná ⇒ obsahuje všechny duležité ˚ požadavky a definice reakcí systému na všechny tˇrídy vstupních údaju˚
• • • •
ˇ verifikovatelná ⇒ existuje proces kontroly, zda SW splnuje požadavek konzistentní ⇒ požadavek není v rozporu s jinými požadavky sledovatelná ⇒ puvod ˚ (smysl) požadavku je jasný ˇ modifikovatelná ⇒ zmena požadavku je možná se zachováním struktury a stylu požadavku
• seˇrazená podle duležitosti ˚ ⇒ seskupení požadavku˚ do tˇríd duležitosti ˚
požadavky na SW se v cˇ ase vyvíjí ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.33/40
´ Problemy prˇi specifikaci poˇzadavku˚ Ruznorodost ˚ požadavku˚
• ruzní ˇ ˚ uživatelé mají ruzné ˚ požadavky a priority ⇒ kompromis (menící se) • ruzné ˚ 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ˇri specifikaci:
• • • •
65% z nich se odhalí pˇri návrhu 2% z nich se odhalí pˇri implementaci 30% z nich se odhalí pˇri testování 3% z nich se odhalí v provozu
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.34/40
´ Problemy prˇi specifikaci poˇzadavku˚ Pˇribližný odhad nákladu˚ na opravu chyb ve specifikaci Etapa Specifikace Návrh Implementace Akceptaˇcní testování Údržba
ˇ Náklady (ˇcloveko-hodiny) 2 5 15 50 150
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.35/40
´ Problemy prˇi specifikaci poˇzadavku˚ Komunikace se zákazníkem
• zákazník není schopen pˇresneˇ formulovat požadavky • terminologie ◦ vývojáˇr (analytik) se neorientuje v doménové problematice ◦ zákazník se neorientuje v problematice vývoje softwaru ◦ ⇒ vyˇclenený ˇ cˇ lovek ˇ od zákazníka; specialista ve vývojovém týmu • problém rozhodování, jaké požadavky už nezaˇclenovat ˇ do specifikace Problémy plynou z použití pˇrirozeného jazyka.
• Vyˇrazení – Používají systém k výpujˇ ˚ ckám knih. Kdo? ˇ • Deformace, zkreslení – Ctenᡠri si nemohou pujˇ ˚ cit další knihu, dokud nevrátí knihy s prošlou výpujˇ ˚ cní lhutou. ˚ Když je zaplatí, tak mohou!
• Zobecnení ˇ – Každý, kdo si chce vypujˇ ˚ cit knihu, musí mít prukazku. ˚ A co výpujˇ ˚ cky mezi knihovnami? ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.36/40
ˇ ´ Nekolik poznamek ke specifikaci poˇzadavku˚ • požadavky pište jasneˇ a jednoznaˇcneˇ • bud’te konzistentní v používání názvu˚ • udržujte specifikaci citelnou ˇ pro zákazníka • poznamenejte si datum vytvoˇrení požadavku • seˇrad’te požadavky podle priorit • • • •
ve specifikaci nenavrhujte rˇešení specifikujte situace, ve kterých se porušuje akceptovatelné chování validujte požadavky používejte více pohledu˚
• prototyp snižuje riziko špatného pochopení požadavku˚ • slabá specifikace ⇒ špatný odhad nákladu˚ • používejte podpurné ˚ prostˇredky, ale bud’te realistiˇctí
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.37/40
´ er ˇ ... Mysˇ lenka na zav
Úlohou analytika je dát zákazníkovi vˇcas a za urˇcenou cenu ne to, co chce, ale to, o cˇ em nikdy ani nesnil, že chce; až když to dostane, zjistí, že ˇ je to pˇresneˇ to, co vlastneˇ celý cˇ as chtel.
´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.38/40
Studijn´ı koutek – Tituly a osloven´ı Akademické tituly
• Bc. – bakaláˇr (angl. bachelor, lat. baccalaureus) ˇ (lat. baccalaureus artis) BcA. – bakaláˇr umení
• Ing. – inženýr (angl. engineer = strojník) Ing. Arch. – inženýr architekt Mgr. – magistr (doslovneˇ uˇcitel) ˇ MgA. – magistr umení
• RNDr. – doktor pˇrírodních ved ˇ (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 ) ˇ rené na management navazující studium zameˇ ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.39/40
Studijn´ı koutek – Tituly a osloven´ı ˇ Vedecké hodnosti
• Ph.D. – doktor (lat. philosophiae doctor ) Th.D. – (lat. theologiae doctor ) Dr. – doktor = uˇcený ˇ (candidatus scientiarum) CSc. – kandidát ved =⇒ odborný asistent
• DrSc. / DSc. – doktor ved ˇ (lat. doctor scientiarum) ˇ • akademik – cˇ len akademie ved ˇ CR Pedagogické hodnosti
• doc. – docent • prof. – profesor Uˇcitelum ˚ na stˇrední škole se ˇríká profesor, pˇrestože titul prof. nemají. ˇ Cestná hodnost
• Dr. h. c. – doctor honoris causa ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.40/40
