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

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/55

2 Dnešní téma Implementace a testování Strategie implementace Techniky testování Strategie testování Agilní metodologie Základní principy Srovnání metodologií Extreme programming (XP) Úvod do softwarového inženýrství IUS 2009/2010 p.2/55

3 Implementace softwaru transformace návrhu jednotlivých modulů (návrhových podsystémů) a jejich vzájemných vazeb do programové realizace kritéria posuzování implementace (procesu tvorby programu) srozumitelnost (programu, výstupu programu) čitelnost udržovatelnost efektivnost aplikace (doba odezvy, požadavky na pamět,... ) přenositelnost efektivnost procesu tvorby programu důležitost jasných cílů (všechna kritéria nelze obvykle splnit) Úvod do softwarového inženýrství IUS 2009/2010 p.3/55

4 Implementace softwaru transformace návrhu jednotlivých modulů (návrhových podsystémů) a jejich vzájemných vazeb do programové realizace kritéria posuzování implementace (procesu tvorby programu) srozumitelnost (programu, výstupu programu) čitelnost udržovatelnost efektivnost aplikace (doba odezvy, požadavky na pamět,... ) přenositelnost efektivnost procesu tvorby programu důležitost jasných cílů (všechna kritéria nelze obvykle splnit) Vzpomínáte si ještě, co je to udržovatelnost a přenositelnost? Úvod do softwarového inženýrství IUS 2009/2010 p.3/55

5 Implementace softwaru transformace návrhu jednotlivých modulů (návrhových podsystémů) a jejich vzájemných vazeb do programové realizace kritéria posuzování implementace (procesu tvorby programu) srozumitelnost (programu, výstupu programu) čitelnost udržovatelnost efektivnost aplikace (doba odezvy, požadavky na pamět,... ) přenositelnost efektivnost procesu tvorby programu důležitost jasných cílů (všechna kritéria nelze obvykle splnit) Udržovatelnost úsilí, které je potřeba vynaložit na další vývoj a údržbu softwaru podle měnících se potřeb zákazníka a také v důsledku měnícího se okolí (např. změna legislativy). Přenositelnost úsilí, které je nutné pro přenos softwaru z jedné platformy na jinou. Úvod do softwarového inženýrství IUS 2009/2010 p.3/55

6 Implementace softwaru Podíl implementace na celkovém objemu prací v životním cyklu softwaru se snižuje: zavedením 4GL jazyků vizuálním programováním (zejména v souvislosti s tvorbou GUI) využíváním integrovaných vývojových prostředí využívání pokročilých prostředků trasování a ladění programů generováním aplikací (např. z Rational Rose) vývojem prostředků spolupráce aplikací (middleware) rozšířením a rozvojem OO/AO/komponentního přístupu znovupoužitelností (využití internetu) Úvod do softwarového inženýrství IUS 2009/2010 p.4/55

7 Generace programovacích jazyků první generace programování přímo v binárním kódu druhá generace asemblery, symbolické vyjádření binárních instrukcí (1 ku 1) třetí generace procedurální jazyky jeden příkaz se transformuje do 5-10 instrukcí v binárním kódu čtvrtá generace (4GL) neprocedurální jazyky (definuje se, co je třeba vykonat, ne jak) jeden příkaz se přeloží do cca instrukcí v binárním kódu často méně efektivní realizace kódu nemožnost ovlivnit zabudovaný způsob realizace jednotlivých akcí uživatelské programování, angl. "End-User Programming" např. Microsoft Excel Úvod do softwarového inženýrství IUS 2009/2010 p.5/55

8 Strategie implementace postup, jakým se realizují jednotlivé softwarové součásti a odevzdávají na testování částečná závislost na architektuře a strategii návrhu potřeba inkrementálního (postupného) vývoje strategie implementace zpravidla podmiňuje strategii testování Implementace zdola-nahoru systém je možné předvádět až po jeho úplném dokončení možnost přímého použití odladěných modulů nižších úrovní chyby v logice se identifikují až v etapě integračního testování testování modulů na nižších úrovních: potřeba speciálních modulů (simulace chování/dat vyšších úrovní) testování modulů jednotlivě je jednodušší než testování logiky celého systému Úvod do softwarového inženýrství IUS 2009/2010 p.6/55

9 Strategie implementace Implementace shora-dolů možnost demonstrace systému poměrně brzy včasná identifikace najzávažnějších chyb logika systému se ověřuje několikrát (testování celého systému) testování systému: potřeba simulačních modulů (simulace práce podsystémů) nedá sa použít, pokud se požaduje implementace některých modulů nejnižší úrovně na začátku (např. výstupní sestavy) testování logiky systému je náročnější než testování modulů jednotlivě Úvod do softwarového inženýrství IUS 2009/2010 p.7/55

10 Strategie implementace Implementace shora-dolů možnost demonstrace systému poměrně brzy včasná identifikace najzávažnějších chyb logika systému se ověřuje několikrát (testování celého systému) testování systému: potřeba simulačních modulů (simulace práce podsystémů) nedá sa použít, pokud se požaduje implementace některých modulů nejnižší úrovně na začátku (např. výstupní sestavy) testování logiky systému je náročnější než testování modulů jednotlivě V praxi se požívá kombinace přístupu zdola-nahoru a shora-dolů. Úvod do softwarového inženýrství IUS 2009/2010 p.7/55

11 Implementace shrnutí Programy se nevytvářejí tak, aby se lehce psaly, ale aby se lehce četly a modifikovaly! Úvod do softwarového inženýrství IUS 2009/2010 p.8/55

12 Validace a verifikace programu Zjišt ujeme, zda software odpovídá specifikaci a splňuje požadavky uživatele. verifikace: Vytváříme výrobek správně? (podle požadavků, specifikace,... ) validace: Vytváříme správný výrobek? (Jsou splněny potřeby uživatele? Odpovídá tomu specifikace?) Sledované vlastnosti: správnost spolehlivost efektivnost bezpečnost... Úvod do softwarového inženýrství IUS 2009/2010 p.9/55

13 Validace a verifikace programu Správnost výrobku nepostačuje! Dokonce správnost někdy není nevyhnutelná! Příklad specifikace procedury SORT: Vstupní podmínka A: array(1..n) of integer Výstupní podmínka B: array(1..n) of integer, přičemž B(1) B(2)... B(N) Implementace: procedure SORT begin for i:= 1 to N do B[i] := 0; end Chyba ve specifikaci:... a prvky pole B jsou permutací prvků pole A. Úvod do softwarového inženýrství IUS 2009/2010 p.10/55

14 Cíle verifikace a validace odhalit chyby během vývoje Test, který neodhalí nesprávné chování systému, je neúspěšný. prokázat požadované vlastnosti Dijkstra: "Testování nemůže prokázat, že v programu nejsou chyby. Může pouze ukázat, že tam chyby jsou!" Murphy: "Když může systém spadnout, tak taky spadne, a to v tom nejnevhodnějším okamžiku." Úvod do softwarového inženýrství IUS 2009/2010 p.11/55

15 Typy ověřování statické nevyžaduje běh programu, lze v libovolné etapě vývoje SW dynamické proces odvození vlastností výrobku na základě výsledků použití (běhu) programu s vybranými vstupy statické ověřování specifikace požadavků návrh programy prototyp dynamické ověřování Úvod do softwarového inženýrství IUS 2009/2010 p.12/55

16 Přístupy statického ověřování Prohlídka dokumentu formální (inspection) neformální (walkthrough) je založena na statické prohlídce vytvořených dokumentů (i zdrojových textů programů) Matematická verifikace formální matematický důkaz ověřovaný dokument musí být formálně reprezentovaný (přesná definice sémantiky) Úvod do softwarového inženýrství IUS 2009/2010 p.13/55

17 Přístupy dynamického ověřování (testování) cíl: vybrat takové testovací vstupy, pro které je pravděpodobnost příslušnosti do množiny I ch vysoká Úvod do softwarového inženýrství IUS 2009/2010 p.14/55

18 Množina testovacích vstupů velikost množiny testovacích vstupů musí být přijatelná testovací vstup se vybírá na základě testovacího kritéria testovací kritérium určuje podmínky, které musí splňovat množina testovacích vstupů, např. pokrytí všech příkazů v programu Program Specifikace Aplikování kritéria Množiny testovacích vstupů Kritérium Úvod do softwarového inženýrství IUS 2009/2010 p.15/55

19 Vlastnosti testovacího kritéria spolehlivost: kritérium K je spolehlivé, když všechny množiny testovacích vstupů splňující kritérium K odhalí ty samé chyby nezáleží na tom, která množina testovacích vstupů se vybere, vždy odhalíme ty samé chyby platnost: kritérium K je platné, když pro každou chybu v programu existuje množina testovacích vstupů, která splňuje kritérium K a která odhalí chybu Když je testovací kritérium spolehlivé a platné a množina testovacích vstupů, která splňuje kritérium, neodhalí žádné chyby, tak program neobsahuje chyby. Úvod do softwarového inženýrství IUS 2009/2010 p.16/55

20 Vlastnosti testovacího kritéria spolehlivost: kritérium K je spolehlivé, když všechny množiny testovacích vstupů splňující kritérium K odhalí ty samé chyby nezáleží na tom, která množina testovacích vstupů se vybere, vždy odhalíme ty samé chyby platnost: kritérium K je platné, když pro každou chybu v programu existuje množina testovacích vstupů, která splňuje kritérium K a která odhalí chybu Když je testovací kritérium spolehlivé a platné a množina testovacích vstupů, která splňuje kritérium, neodhalí žádné chyby, tak program neobsahuje chyby. ALE Bylo dokázané, že neexistuje algoritmus, který určí platné kritérium pro libovolný program. Úvod do softwarového inženýrství IUS 2009/2010 p.16/55

21 Proces testování Testovací vstupy Testovací údaje Výsledky Navrhni testovací vstupy Připrav testovací vstupy Proved program Porovnej výsledky Zpráva Úvod do softwarového inženýrství IUS 2009/2010 p.17/55

22 Techniky testování náhodné testování množina testovacích vstupů se vybere náhodně funkcionální testování na základě specifikace programu (vstupy, výstupy) metoda černé skříňky black box, data driven, functional, input/output driven, closed box strukturální testování na základě vnitřní struktury programu metoda bílé skříňky white box, glass box, logic driven, path oriented, open box testování rozhraní na základě znalostí rozhraní mezi moduly a specifikace programu Úvod do softwarového inženýrství IUS 2009/2010 p.18/55

23 Funkcionální testování zjištění zda vstupně-výstupní chování vyhovuje specifikaci např. matematická funkce se specifikuje vstupy a výstupy testovací vstupy se odvozují přímo ze specifikace neuvažuje se vnitřní struktura, logika modulu velká množina testovacích vstupů (problém) úplné funkcionální testování je v praxi nemožné Příklad: ABS(x) vstup (x) výstup Úvod do softwarového inženýrství IUS 2009/2010 p.19/55

24 Třídy ekvivalence vstupů/výstupů každý možný vstup/výstup patří do jedné z tříd ekvivalence, pro které je chování systému identické (vstup-výstup) žádný vstup/výstup nepatří do více tříd ekvivalence pokud se při daném vstupu/výstupu zjistí chyba, tak stejnou chybu je možné odhalit použitím jiného vstupu/výstupu z dané třídy ekvivalence Úvod do softwarového inženýrství IUS 2009/2010 p.20/55

25 Třídy ekvivalence vstupů/výstupů Granularita třídy ekvivalence rozsah hodnota podmnožina Výběr testovacích údajů z třídy ekvivalence průměr, medián třídy ekvivalence hranice třídy ekvivalence (příp. s okolními hodnotami) náhodně (doplnění množiny testovacích vstupů) Příklad: ABS(x) třídy ekvivalence vybrané vstupy/výstupy (x:int) (, 0) ( 32767,32767), ( 16384,16384), ( 1,1),... 0 (0, 0) (0, ) (32768,32768), (16384,16384), (1, 1),... Úvod do softwarového inženýrství IUS 2009/2010 p.21/55

26 Strukturální testování vychází se z vnitřní struktury programu testuje se implementace programu snaha o pokrytí různých struktur programu řízení údaje (data) kritéria: založená na tocích řízení (pokrytí cest, pokrytí rozhodovacích bloků nebo podmínek a pokrytí příkazů) založená na tocích dat mutační testování do programu se úmyslně zavedou chyby kontrolujeme, zda navržené testy tyto chyby odhalí (kvalita testu) Příklad: if x > 0 then y := x else y := -x; Úvod do softwarového inženýrství IUS 2009/2010 p.22/55

27 Strategie testování Testování zdola-nahoru (bottom-up testing) testují se komponenty na nižší úrovni, poté se integrují do komponenty vyšší úrovně a znovu testují vhodné, pokud většina modulů stejné úrovně je připravena Testování shora-dolů (top-down testing) testují se integrované moduly nejvyšší úrovně, poté se testují submoduly problém s připraveností všech modulů (simulace modulů na nižších úrovních) Sendvičové testování (sandwich testing) kombinace strategií bottom-up a top-down testování moduly se rozdělí do dvou skupin logické: řízení a rozhodování, top-down funkční : vykonávání požadovaných funkcí, bottom-up Úvod do softwarového inženýrství IUS 2009/2010 p.23/55

28 Strategie testování Jednofázové testování (big-bang testing) moduly se otestují samostatně a poté se naráz integrují náročná identifikace místa chyby při integraci náročné rozlišení chyb v rozhraní modulů od ostatních chyb Testování porovnáváním (comparison testing, back-to-back testing) více verzí systému na testování prototyp technika programování N-verzí vývoj vysoce spolehlivých systémů vývoj více verzí produktu pro různé platformy stejné výsledky značí, že verze pravděpodobně pracují správně problémy: stejné chyby ve verzích nevyhovující specifikace Úvod do softwarového inženýrství IUS 2009/2010 p.24/55

29 Akceptační testování Testuje se na reálných datech. Testuje se u uživatele. Uživatel určí, zda produkt splňuje zadání. Další změny po akceptaci systému již představují údržbu systému. Vztahuje se na zakázkový software. Úvod do softwarového inženýrství IUS 2009/2010 p.25/55

30 Alfa a Beta testování... pro generické softwarové výrobky, kde není možné provést akceptační testy u každého zákazníka (operační systémy, kompilátory,... ) Alfa testování tam, kde se vyvíjí software testuje uživatel, vývojáři sledují a evidují chyby známé prostředí Beta testování testují uživatelé u sebe neznámé prostředí výsledkem je zpráva uživatele modifikace softwaru předání softwaru k používání Úvod do softwarového inženýrství IUS 2009/2010 p.26/55

31 Téma: Agilní metodologie Úvod do softwarového inženýrství IUS 2009/2010 p.27/55

32 Metodologie disciplinovaný proces nad vývojem softwaru s cílem zajistit tento vývoj více predikovatelný a efektivnější častá kritika "byrokratizace" metodologií příliš mnoho aktivit, které metodologie předepisuje, způsobuje snížení efektivity celého procesu vývoje nová skupina metodologií lightweight methodologies, dnes agile methodologies (agilní metodologie) Úvod do softwarového inženýrství IUS 2009/2010 p.28/55

33 Agilní metodologie snaha o kompromis mezi chaotickým přístupem bez procesů a přístupem s mnoha procesy rozumná velikost souboru procesů k zajištění přiměřeného zisku menší objem dokumentace v každém kroku klíčová část dokumentace je zdrojový kód! základní charakteristiky: adaptivní vs. prediktivní metody (přístupy) people-oriented vs. process-oriented metody (přístupy) Úvod do softwarového inženýrství IUS 2009/2010 p.29/55

34 Základní srovnání metod Adaptivní vs. prediktivní prediktivní metody plánují velké části softwarových procesů velmi detailně pro dlouhý časový úsek adaptivní metody (agilní metodologie) reagují na změny, procesy se v čase vyvíjejí People-oriented vs. process-oriented process-oriented metody definují pevnou posloupnost kroků procesy by měly fungovat za všech okolností (změna týmu,... ) people-oriented metody (agilní metodologie) žádný proces nikdy nevytváří dovednosti (znalosti) vývojového týmu úlohou procesu je podpora práce vývojového týmu Úvod do softwarového inženýrství IUS 2009/2010 p.30/55

35 Predikovatelnost procesu vývoje existují projekty, kde máme na začátku poměrně jasnou představu projekty vyžadující mnoho procedur, času, velké týmy a stabilní požadavky projekty NASA,... dobrá predikovatelnost procesu vývoje existují projekty, kde máme na začátku poměrně jasnou představu ale s časem se mění okolní podmínky a tedy i požadavky business projekty,... horší predikovatelnost procesu vývoje existují projekty, kde máme na začátku poměrně mlhavou představu business projekty,... špatná predikovatelnost procesu vývoje Úvod do softwarového inženýrství IUS 2009/2010 p.31/55

36 Predikovatelnost procesu vývoje Problém většiny projektů je, že se požadavky neustále mění. Je tedy predikovatelnost nemožná? Úvod do softwarového inženýrství IUS 2009/2010 p.32/55

37 Predikovatelnost procesu vývoje Přístupy k řešení requirements engineering před tvorbou softwaru získat plně srozumitelný obraz požadavků schválený (podepsaný) zákazníkem definování procedur limitujících změny požadavků po schválení klade vysoké nároky na proces specifikace požadavků a preciznost jejich vyjádření fixní požadavky jejich vytvoření stojí příliš mnoho energie a času adaptivní metody... Úvod do softwarového inženýrství IUS 2009/2010 p.32/55

38 Řízení adaptivních procesů Iterativní vývoj inkrementální spirálový... Každá iterace zahrnuje analýzu požadavků návrh (úpravy návrhu) implementaci testování analýzu rizik Otázka délky iterace týdny měsíce... Úvod do softwarového inženýrství IUS 2009/2010 p.33/55

39 Řízení adaptivních procesů Plánování procesů v první iteraci se vždy provádí plánování procesů, a to na základě zkušeností či dostupných metodik tento plán se během iterací vyvíjí (zpřesňuje) podle reálného stavu Úvod do softwarového inženýrství IUS 2009/2010 p.34/55

40 Process-oriented methods striktně definované procesy lidé jsou zdroje, které jsou dostupné v několika rolích analytik manažer programátor tester... podstatná je role, nikoliv individualita lidí není důležité jaké analytiky máte, ale kolik jich máte člověk je jednoduše nahraditelná komponenta vývojového procesu za standardní prostředek komunikace se považuje dokumentace Úvod do softwarového inženýrství IUS 2009/2010 p.35/55

41 Process-oriented methods striktně definované procesy lidé jsou zdroje, které jsou dostupné v několika rolích analytik manažer programátor tester... podstatná je role, nikoliv individualita lidí není důležité jaké analytiky máte, ale kolik jich máte člověk je jednoduše nahraditelná komponenta vývojového procesu za standardní prostředek komunikace se považuje dokumentace Teze: člověk vykonávající práci není ten, kdo může nejlépe určit, jak tuto práci nejlépe udělat Úvod do softwarového inženýrství IUS 2009/2010 p.35/55

42 People-oriented methods Design and programming are human activities; forget that and all is lost. Bjarne Stroustrup, 1991 lidé mají problémy fungovat konzistentně v průběhu času pokud člověk dostane každý den stejný úkol, vytvoří podobné výsledky, ale nikdy ne stejné schopnost pracovního nasazení/soustředění se mění den ze dne, z místa na místo (někteří pracují lépe v noci) lidé jsou komunikující bytosti fyzická blízkost gestikulace, hlasový projev, intonace otázky a odpovědi v reálném čase Úvod do softwarového inženýrství IUS 2009/2010 p.36/55

43 People-oriented methods Design and programming are human activities; forget that and all is lost. Bjarne Stroustrup, 1991 lidé mají problémy fungovat konzistentně v průběhu času pokud člověk dostane každý den stejný úkol, vytvoří podobné výsledky, ale nikdy ne stejné schopnost pracovního nasazení/soustředění se mění den ze dne, z místa na místo (někteří pracují lépe v noci) lidé jsou komunikující bytosti fyzická blízkost gestikulace, hlasový projev, intonace otázky a odpovědi v reálném čase Teze: člověk je kompetentní profesionál schopný rozhodovat všechny technické otázky své práce. Úvod do softwarového inženýrství IUS 2009/2010 p.36/55

44 Efektivnost komunikace efektivnost komunikace whiteboard telefon mail dokument forma komunikace Úvod do softwarového inženýrství IUS 2009/2010 p.37/55

45 Agilní metodologie Základní teze Jediná cesta, jak prověřit správnost navrženého systému, je co nejrychleji jej vyvinout, předložit zákazníkovi a na základě zpětné vazby upravovat. Člen týmu je schopen rozhodovat technické otázky své práce. Rozumná velikost souboru procesů. Klasické pravidlo Implementujeme pro dnešek, navrhujeme pro zítřek. Úvod do softwarového inženýrství IUS 2009/2010 p.38/55

46 Agilní metodologie Základní teze Jediná cesta, jak prověřit správnost navrženého systému, je co nejrychleji jej vyvinout, předložit zákazníkovi a na základě zpětné vazby upravovat. Člen týmu je schopen rozhodovat technické otázky své práce. Rozumná velikost souboru procesů. Klasické pravidlo Implementujeme pro dnešek, navrhujeme pro zítřek. Upravené pravidlo Implementujeme pro dnešek, navrhujeme pro úspěšnou implementaci. Úvod do softwarového inženýrství IUS 2009/2010 p.38/55

47 Agilní metodologie Agilní metodologie Extreme programming (XP) Crystal Scrum Feature Driven Development Dynamic System Development Method (DSDM)... Úvod do softwarového inženýrství IUS 2009/2010 p.39/55

48 Extrémní programování (XP) Kořeny XP Kent Beck: Extreme Programming Explained: Embrace Change Kent Beck, Ward Cunningham 80. léta Smalltalk 90. léta získávání zkušeností v různých projektech, rozšiřování idejí agilního přístupu Úvod do softwarového inženýrství IUS 2009/2010 p.40/55

49 Charakteristické prvky XP Komunikace programátoři, zákazníci a manažeři musí spolu komunikovat XP využívá takové techniky, které komunikaci vyžadují (testování, párové programování, odhady úkolů) člen týmu, který udržuje komunikační toky, pomáhá programátorům s technickými dovednostmi, komunikuje s manažery na vyšších úrovních Úvod do softwarového inženýrství IUS 2009/2010 p.41/55

50 Charakteristické prvky XP Komunikace programátoři, zákazníci a manažeři musí spolu komunikovat XP využívá takové techniky, které komunikaci vyžadují (testování, párové programování, odhady úkolů) člen týmu, který udržuje komunikační toky, pomáhá programátorům s technickými dovednostmi, komunikuje s manažery na vyšších úrovních Zpětná vazba "Zeptej se systému", "Už máš napsaný test?" snaha mít co nejdříve nejdůležitější části systému, nejlépe přímo v provozu zpětná vazba by měla být rychlá přehnaný optimismus se léčí zpětnou vazbou člen týmu, který sleduje metriky, srovnává je s očekávaným stavem (nutnost malé režie) Úvod do softwarového inženýrství IUS 2009/2010 p.41/55

51 Charakteristické prvky XP Jednoduchost "Co je nejjednodušší věc, která by ještě fungovala?" je dobré udržovat si přehled o tom, co bude nicméně je nutné soustředit se na to, co je potřeba právě ted jednoduché věci je třeba vytvářet jednoduše úspora času na opravdu složité věci v případě potřeby není problém jednoduché věci rozšířit Úvod do softwarového inženýrství IUS 2009/2010 p.42/55

52 Charakteristické prvky XP Jednoduchost "Co je nejjednodušší věc, která by ještě fungovala?" je dobré udržovat si přehled o tom, co bude nicméně je nutné soustředit se na to, co je potřeba právě ted jednoduché věci je třeba vytvářet jednoduše úspora času na opravdu složité věci v případě potřeby není problém jednoduché věci rozšířit Odvaha nebát se provést zásadní změny (např. i za cenu dočasného snížení úspěšnosti testů a tedy zvýšeného úsilí) nebát se zahodit naprogramovaný kód nebát se zkusit neznámé (když nevíš, že to nejde, může se to podařit) Úvod do softwarového inženýrství IUS 2009/2010 p.42/55

53 Základní techniky XP Přírůstkové (malé) změny návrh a implementace se mění v čase jen pozvolna uvolňování malých verzí systému (nejpodstatnější požadavky, postupně vylepšované a doplňované) Úvod do softwarového inženýrství IUS 2009/2010 p.43/55

54 Základní techniky XP Přírůstkové (malé) změny návrh a implementace se mění v čase jen pozvolna uvolňování malých verzí systému (nejpodstatnější požadavky, postupně vylepšované a doplňované) Testování "Co nelze otestovat, to neexistuje." ke každé funkci píšeme testy (mnohdy testujeme dříve, než programujeme) zautomatizovaný systém testů integrace a integrační testování Úvod do softwarového inženýrství IUS 2009/2010 p.43/55

55 Základní techniky XP Párové programování jednu věc programují vždy 2 programátoři (ale pouze 1 skutečně píše) ten, kdo píše, se soustřed uje na nejlepší způsob implementace problému druhý se soustřed uje na problém z globálnějšího pohledu bude to fungovat, jaké další testy, možnost zjednodušení,... páry jsou dynamické Úvod do softwarového inženýrství IUS 2009/2010 p.44/55

56 Základní techniky XP Párové programování jednu věc programují vždy 2 programátoři (ale pouze 1 skutečně píše) ten, kdo píše, se soustřed uje na nejlepší způsob implementace problému druhý se soustřed uje na problém z globálnějšího pohledu bude to fungovat, jaké další testy, možnost zjednodušení,... páry jsou dynamické Refaktorizace úprava stávajícího programu zjednodušení, zefektivnění návrhu odstranění (úprava) nepotřebných částí změna architektury (pravidlo přírůstkové změny) při refaktorizaci se nemění funkcionalita! Úvod do softwarového inženýrství IUS 2009/2010 p.44/55

57 Základní techniky XP Metriky důležitá součást určení kvality softwarových procesů např. poměr plánovaného času a skutečného času přiměřený počet metrik (3 4) pokud přestane metrika plnit svůj účel nahradit jinou např. metrika testů funkcionality se blíží 100% nahradit jinou s menší úspěšností existují pravidla udávající kdy a jak často by se měly jednotlivé techniky používat Úvod do softwarového inženýrství IUS 2009/2010 p.45/55

58 Proces vývoje v XP Iterace 1 4 týdny nezbytným výsledkem je sada testů funkcionality v první iteraci základy architektury výsledkem je základní funkční systém v dalších iteracích rozšiřování základní verze hledání odchylek od plánu (čas, testování,... ) v případě odchylek změna plánu nebo změna procesu Úvod do softwarového inženýrství IUS 2009/2010 p.46/55

59 Proces vývoje v XP Správný návrh se vyznačuje všechny testy fungují, neobsahuje duplicitní logiku, má co nejmenší počet tříd a metod, programátor zná všechny záměry návrhu. Motivace vývojářů lidé lépe pracují, pokud je práce baví jídlo, hračky, vybavení pracoviště,... Úvod do softwarového inženýrství IUS 2009/2010 p.47/55

60 Je RUP agilní metodou? Úvod do softwarového inženýrství IUS 2009/2010 p.48/55

61 Je RUP agilní metodou? Základní charakteristika základní vyjadřovací prostředek je UML pracuje v iteracích definuje obsah každé iterace definuje pracovní rámec (framework) Použití RUP klasický heavyweight proces agilní proces Úvod do softwarového inženýrství IUS 2009/2010 p.48/55

62 Je RUP agilní metodou? Craig Larman "light RUP" měsíční iterace první 3 dny iterace využití UML pro přiblížení návrhu pro danou iteraci dx proces minimální RUP proces považuje UML za jeden z možných pomocných prostředků Úvod do softwarového inženýrství IUS 2009/2010 p.49/55

63 Principy agilních metodologií shrnutí Iterativní a inkrementální vývoj krátké iterace nové funkce (funkcionalita) se dodávají často zákazník má pocit, že se něco děje, má možnost rychle modifikovat funkcionalitu / požadavky Princip jednoduchosti "Implementujeme pro dnešek, navrhujeme pro zítřek." {problém predikovatelnosti} zvyšování funkcionality (nákladů) na základě spekulace "Do systému vložíme to, co potřebujeme, když to potřebujeme." Osobní komunikace v týmu zásadní problém každé skupiny je komunikace komunikace jako jedna z forem vývoje softwaru používají se takové techniky, které komunikaci vyžadují párové programování, refaktorizace, časté schůzky se zákazníkem,... Úvod do softwarového inženýrství IUS 2009/2010 p.50/55

64 Principy agilních metodologií shrnutí Zákazník je členem vývojového týmu zákazník komunikuje s vývojovým týmem zákazník se spolupodílí na návrhu systému, na testech,... Průběžné automatizované testování časté změny systému vyžadují časté ověřování správnosti testy by měly být automatizované testy by měly být napsány před implementací Dokumentace význam formálních dokumentů je snižován základní dokumentace je zdrojový kód (klade se na něj největší důraz) uživatelský manuál (ne příliš rozsáhlý) Úvod do softwarového inženýrství IUS 2009/2010 p.51/55

65 Prediktivní či agilní metodologii? Kdy použít agilní metodologii? neurčité nebo měnící se požadavky odpovědní a dobře motivovaní vývojáři zákazník, který je ochoten zapojit se do vývoje Kdy použít prediktivní metodologii? velký vývojový tým (více jak 100 lidí) pevný rozsah projektu Výběr metodologie ovšem závisí na mnoha dalších aspektech... Úvod do softwarového inženýrství IUS 2009/2010 p.52/55

66 Poznatky z praxe Přístupy lidí vývoj podle předpisů můžeme říci, že neúspěch není naše chyba lidé preferují konzervativní přístup a neúspěch než riskovat úspěch s odlišnou metodou každá nová technika návrhu vypadá příliš složitě na použití návrhové týmy ignorují nástroje a techniky, které nemají rádi lidé pracují (učí se) dobře podle příkladů Metodologie většina metodologií může být vytvořena (použita) tak, aby pracovala v nějakém projektu libovolná metodologie může vést nějaký projekt k neúspěchu úspěšné týmy používají inkrementální vývoj "heavy" procesy bývají úspěšné "light" procesy jsou častěji úspěšné, úspěch je připisován právě "lightness" použité metodologie Úvod do softwarového inženýrství IUS 2009/2010 p.53/55

67 SW inženýr a metodologie Co musí umět dobrý SW inženýr? vybrat vhodnou metodologii nebo na základě metodologií vytvořit scénář vývoje softwaru tak, aby projekt úspěšně dosáhl stanoveného cíle, stanovit cíle splnitelné v daném prostředí cena termín dokončení funkčnost kvalita a to s ohledem na vývojový tým, který má k dispozici. Úvod do softwarového inženýrství IUS 2009/2010 p.54/55

68 Další reference Václav Kadlec. Agilní programování: Metodiky efektivního vývoje softwaru. Craig Larman. Agile and iterative development: a manager s guide. Scott W. Ambler. Agile database techniques: effective strategies for the agile software developer. Mike Cohn. Agile estimating and planning. Kent Beck. Extreme Programming Explained: Embrace Change. Alistair Cockburn. Agile Software Development: The Cooperative Game. Alistair Cockburn. Crystal Clear: A Human-Powered Methodology for Small Teams. Ken Schwaber, Mike Beedle. Agile Software Development with SCRUM. Úvod do softwarového inženýrství IUS 2009/2010 p.55/55