55

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

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

´ Dnesˇ n´ı tema Implementace a testování

• Strategie implementace • Techniky testování • Strategie testování Agilní metodologie

• Základní principy • Srovnání metodologií • Extreme programming (XP)

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

Implementace softwaru • transformace návrhu jednotlivých modulu˚ (návrhových podsystému) ˚ a jejich vzájemných vazeb do programové realizace

• kritéria posuzování implementace (procesu tvorby programu) ◦ srozumitelnost (programu, výstupu programu) ◦ cˇ itelnost ◦ udržovatelnost ◦ efektivnost aplikace (doba odezvy, požadavky na pamet’, ˇ ...) ◦ pˇrenositelnost ◦ efektivnost procesu tvorby programu • duležitost ˚ jasných cílu˚ (všechna kritéria nelze obvykle splnit)

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

Implementace softwaru • transformace návrhu jednotlivých modulu˚ (návrhových podsystému) ˚ a jejich vzájemných vazeb do programové realizace

• kritéria posuzování implementace (procesu tvorby programu) ◦ srozumitelnost (programu, výstupu programu) ◦ cˇ itelnost ◦ udržovatelnost ◦ efektivnost aplikace (doba odezvy, požadavky na pamet’, ˇ ...) ◦ pˇrenositelnost ◦ efektivnost procesu tvorby programu • duležitost ˚ jasných cílu˚ (všechna kritéria nelze obvykle splnit)

ˇ co je to udržovatelnost a pˇrenositelnost? Vzpomínáte si ješte,

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

Implementace softwaru • transformace návrhu jednotlivých modulu˚ (návrhových podsystému) ˚ a jejich vzájemných vazeb do programové realizace

• kritéria posuzování implementace (procesu tvorby programu) ◦ srozumitelnost (programu, výstupu programu) ◦ cˇ itelnost ◦ udržovatelnost ◦ efektivnost aplikace (doba odezvy, požadavky na pamet’, ˇ ...) ◦ pˇrenositelnost ◦ efektivnost procesu tvorby programu • duležitost ˚ jasných cílu˚ (všechna kritéria nelze obvykle splnit) • 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).

• Pˇrenositelnost – úsilí, které je nutné pro pˇrenos softwaru z jedné platformy na jinou. ´ ´ inˇzen´yrstv´ı IUS 2009/2010 – p.3/55 Uvod do softwaroveho

Implementace softwaru Podíl implementace na celkovém objemu prací v životním cyklu softwaru se snižuje:

• • • • • • • •

zavedením 4GL jazyku˚ vizuálním programováním (zejména v souvislosti s tvorbou GUI) využíváním integrovaných vývojových prostˇredí ˇ programu˚ využívání pokroˇcilých prostˇredku˚ trasování a ladení generováním aplikací (napˇr. z Rational Rose) vývojem prostˇredku˚ spolupráce aplikací (middleware) rozšíˇrením a rozvojem OO/AO/komponentního pˇrístupu znovupoužitelností (využití internetu)

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

Generace programovac´ıch jazyku˚ • první generace ◦ programování pˇrímo v binárním kódu • druhá generace ◦ asemblery, symbolické vyjádˇrení binárních instrukcí (1 ku 1) • tˇretí generace ◦ procedurální jazyky ◦ jeden pˇríkaz se transformuje do 5-10 instrukcí v binárním kódu • ctvrtá ˇ generace (4GL) ◦ neprocedurální jazyky (definuje se, co je tˇreba vykonat, ne jak) ◦ jeden pˇríkaz se pˇreloží do cca 30-50 instrukcí v binárním kódu ◦ cˇ asto méneˇ efektivní realizace kódu ◦ nemožnost ovlivnit zabudovaný zpusob ˚ realizace jednotlivých akcí ◦ uživatelské programování, angl. "End-User Programming" napˇr. Microsoft Excel

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

Strategie implementace • postup, jakým se realizují jednotlivé softwarové souˇcásti a odevzdávají na testování

• cˇ ásteˇcná závislost na architektuˇre a strategii návrhu • potˇreba inkrementálního (postupného) vývoje • strategie implementace zpravidla podminuje ˇ strategii testování Implementace zdola-nahoru

• • • •

ˇ až po jeho úplném dokonˇcení systém je možné pˇredvádet ˇ možnost pˇrímého použití odladených modulu˚ nižších úrovní chyby v logice se identifikují až v etapeˇ integraˇcního testování testování modulu˚ na nižších úrovních: potˇreba speciálních modulu˚ (simulace chování/dat vyšších úrovní)

• testování modulu˚ jednotliveˇ je jednodušší než testování logiky celého systému

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

Strategie implementace Implementace shora-dolu˚

• • • •

ˇ eˇ brzy možnost demonstrace systému pomern ˇ vˇcasná identifikace najzávažnejších chyb ˇ ruje nekolikrát ˇ logika systému se oveˇ (testování celého systému) testování systému: potˇreba simulaˇcních modulu˚ (simulace práce podsystému) ˚

• nedá sa použít, pokud se požaduje implementace nekterých ˇ modulu˚ nejnižší úrovneˇ na zaˇcátku (napˇr. výstupní sestavy)

• testování logiky systému je nároˇcnejší ˇ než testování modulu˚ jednotliveˇ

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

Strategie implementace Implementace shora-dolu˚

• • • •

ˇ eˇ brzy možnost demonstrace systému pomern ˇ vˇcasná identifikace najzávažnejších chyb ˇ ruje nekolikrát ˇ logika systému se oveˇ (testování celého systému) testování systému: potˇreba simulaˇcních modulu˚ (simulace práce podsystému) ˚

• nedá sa použít, pokud se požaduje implementace nekterých ˇ modulu˚ nejnižší úrovneˇ na zaˇcátku (napˇr. výstupní sestavy)

• testování logiky systému je nároˇcnejší ˇ než testování modulu˚ jednotliveˇ

V praxi se požívá kombinace pˇrístupu zdola-nahoru a shora-dolu. ˚

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

Implementace – shrnut´ı

Programy se nevytváˇrejí tak, aby se lehce psaly, ale aby se lehce cˇ etly a modifikovaly!

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

Validace a verifikace programu ˇ Zjišt’ujeme, zda software odpovídá specifikaci a splnuje požadavky uživatele.

• verifikace: Vytváˇríme výrobek správne? ˇ (podle požadavku, ˚ specifikace, . . . )

• validace: Vytváˇríme správný výrobek? ˇ potˇreby uživatele? Odpovídá tomu specifikace?) (Jsou splneny Sledované vlastnosti:

• • • • •

správnost spolehlivost efektivnost bezpeˇcnost ...

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

Validace a verifikace programu ˇ Správnost výrobku nepostacuje! ˇ Dokonce správnost nekdy není nevyhnutelná! Pˇríklad specifikace procedury SORT:

• Vstupní podmínka A: array(1..N) of integer • Výstupní podmínka B: array(1..N) of integer, pˇriˇcemž 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í prvku˚ pole A. ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.10/55

C´ıle verifikace a validace • odhalit chyby behem ˇ vývoje ˇ Test, který neodhalí nesprávné chování systému, je neúspešný.

• prokázat požadované vlastnosti

Dijkstra: "Testování nemuže ˚ prokázat, že v programu nejsou chyby. Muže ˚ pouze ukázat, že tam chyby jsou!"

Murphy: "Když muže ˚ systém ’spadnout’, tak taky spadne, ˇ a to v tom nejnevhodnejším okamžiku."

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

´ ı Typy oveˇ rˇovan´ • statické – nevyžaduje beh ˇ programu, lze v libovolné etapeˇ vývoje SW • dynamické – proces odvození vlastností výrobku na základeˇ výsledku˚ ˇ použití (behu) programu s vybranými vstupy

ˇ rování statické oveˇ

?

?

specifikace požadavku˚

návrh

? programy

6 ? prototyp



ˇ rování dynamické oveˇ

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

´ oveˇ rˇovan´ ´ ı Prˇ´ıstupy statickeho Prohlídka dokumentu

• formální (inspection) • neformální (walkthrough) • je založena na statické prohlídce vytvoˇrených dokumentu˚ (i zdrojových textu˚ programu) ˚ Matematická verifikace

• formální matematický dukaz ˚ • oveˇ ˇ rovaný dokument musí být formálneˇ reprezentovaný (pˇresná definice sémantiky)

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

´ oveˇ rˇovan´ ´ ı (testovan´ ´ ı) Prˇ´ıstupy dynamickeho • cíl: vybrat takové testovací vstupy, pro které je pravdepodobnost ˇ pˇríslušnosti do množiny Ich vysoká

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

Mnoˇzina testovac´ıch vstupu˚ • velikost množiny testovacích vstupu˚ musí být pˇrijatelná • testovací vstup se vybírá na základeˇ testovacího kritéria • testovací kritérium urˇcuje podmínky, které musí splnovat ˇ množina testovacích vstupu, ˚ napˇr. pokrytí všech pˇríkazu˚ v programu

Program

-

Specifikace

-

Kritérium

-

Aplikování kritéria

- Množiny testovacích vstupu˚

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.15/55

´ Vlastnosti testovac´ıho kriteria • spolehlivost: kritérium K je spolehlivé, když všechny množiny ˇ testovacích vstupu˚ splnující kritérium K odhalí ty samé chyby ⇒ nezáleží na tom, která množina testovacích vstupu˚ 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 vstupu, ˚ která splnuje kritérium K a která odhalí chybu

Když je testovací kritérium spolehlivé a platné a množina ˇ testovacích vstupu, ˚ která splnuje kritérium, neodhalí žádné chyby, tak program neobsahuje chyby.

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

´ Vlastnosti testovac´ıho kriteria • spolehlivost: kritérium K je spolehlivé, když všechny množiny ˇ testovacích vstupu˚ splnující kritérium K odhalí ty samé chyby ⇒ nezáleží na tom, která množina testovacích vstupu˚ 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 vstupu, ˚ která splnuje kritérium K a která odhalí chybu

Když je testovací kritérium spolehlivé a platné a množina ˇ testovacích vstupu, ˚ která splnuje kritérium, neodhalí žádné chyby, tak program neobsahuje chyby. ALE Bylo dokázané, že neexistuje algoritmus, který urˇcí platné kritérium pro libovolný program.

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

´ ı Proces testovan´

Testovací vstupy

6

Testovací údaje

6

6

? Navrhni testovací vstupy

-

Pˇriprav testovací vstupy

Výsledky

? -

Proved’ program

? -

?

Porovnej výsledky

? Zpráva

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

´ ı Techniky testovan´ • náhodné testování ◦ množina testovacích vstupu˚ se vybere náhodneˇ • funkcionální testování ◦ na základeˇ specifikace programu (vstupy, výstupy) ◦ metoda cˇ erné skˇrínky ˇ black box, data driven, functional, input/output driven, closed box

• strukturální testování ◦ na základeˇ vnitˇrní struktury programu ◦ metoda bílé skˇrínky ˇ white box, glass box, logic driven, path oriented, open box

• testování rozhraní ◦ na základeˇ znalostí rozhraní mezi moduly a specifikace programu

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

´ ı testovan´ ´ ı Funkcionaln´ • zjištení ˇ zda vstupne-výstupní ˇ chování vyhovuje specifikaci napˇr. matematická funkce se specifikuje vstupy a výstupy

• testovací vstupy se odvozují pˇrímo ze specifikace • neuvažuje se vnitˇrní struktura, logika modulu ⇒ velká množina testovacích vstupu˚ (problém)

• úplné funkcionální testování je v praxi nemožné Pˇríklad: ABS(x) vstup (x) -5 -2 0 5

výstup 5 2 0 5

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

Trˇ´ıdy ekvivalence vstupu/v´ ˚ ystupu˚ • každý možný vstup/výstup patˇrí do jedné z tˇríd ekvivalence, pro které je chování systému identické (vstup-výstup)

• žádný vstup/výstup nepatˇrí do více tˇríd ekvivalence • pokud se pˇri 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ˇrídy ekvivalence

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

Trˇ´ıdy ekvivalence vstupu/v´ ˚ ystupu˚ Granularita tˇrídy ekvivalence

• rozsah • hodnota • podmnožina ˇ testovacích údaju˚ z tˇrídy ekvivalence Výber

• prum ˇ medián tˇrídy ekvivalence ˚ er, • hranice tˇrídy ekvivalence (pˇríp. s okolními hodnotami) • náhodneˇ (doplnení ˇ množiny testovacích vstupu) ˚ Pˇríklad: ABS(x) tˇrídy ekvivalence (−∞, 0) 0 (0, ∞)

vybrané vstupy/výstupy (x:int) (−32767, 32767), (−16384, 16384), (−1, 1), . . . (0, 0) (32768, 32768), (16384, 16384), (1, 1), . . .

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

´ ı testovan´ ´ ı Strukturaln´ • vychází se z vnitˇrní struktury programu testuje se implementace programu

• snaha o pokrytí ruzných ˚ struktur programu ◦ ˇrízení ◦ údaje (data) • kritéria: ◦ založená na tocích ˇrízení (pokrytí cest, pokrytí rozhodovacích bloku˚ nebo podmínek a pokrytí pˇríkazu) ˚ ◦ založená na tocích dat

• mutaˇcní testování ◦ do programu se úmyslneˇ zavedou chyby ◦ kontrolujeme, zda navržené testy tyto chyby odhalí (kvalita testu) Pˇríklad: if x > 0 then y := x else y := -x; ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.22/55

´ ı Strategie testovan´ Testování zdola-nahoru (bottom-up testing)

• testují se komponenty na nižší úrovni, poté se integrují do komponenty vyšší úrovneˇ a znovu testují

• vhodné, pokud vetšina ˇ modulu˚ stejné úrovneˇ je pˇripravena Testování shora-dolu˚ (top-down testing)

• testují se integrované moduly nejvyšší úrovne, ˇ poté se testují submoduly • problém s pˇripraveností všech modulu˚ (simulace modulu˚ na nižších úrovních) ˇ Sendvicové testování (sandwich testing)

• kombinace strategií bottom-up a top-down testování • moduly se rozdelí ˇ do dvou skupin ◦ logické: ˇrízení a rozhodování, top-down ◦ funkˇcní : vykonávání požadovaných funkcí, bottom-up ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.23/55

´ ı Strategie testovan´ Jednofázové testování (big-bang testing)

• moduly se otestují samostatneˇ a poté se naráz integrují • nároˇcná identifikace místa chyby pˇri integraci • nároˇcné rozlišení chyb v rozhraní modulu˚ 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ému˚ ◦ vývoj více verzí produktu pro ruzné ˚ platformy • stejné výsledky znaˇcí, že verze pravdepodobn ˇ eˇ pracují správneˇ • problémy: ◦ stejné chyby ve verzích ◦ nevyhovující specifikace

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

´ ı Akceptacˇ n´ı testovan´ • • • •

Testuje se na reálných datech. Testuje se u uživatele. ˇ Uživatel urˇcí, zda produkt splnuje zadání. ˇ po akceptaci systému již pˇredstavují údržbu systému. Další zmeny

• Vztahuje se na zakázkový software.

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

´ ı Alfa a Beta testovan´ . . . pro generické softwarové výrobky, kde není možné provést akceptaˇcní testy u každého zákazníka (operaˇcní systémy, kompilátory, . . . ) Alfa testování

• tam, kde se vyvíjí software • testuje uživatel, vývojáˇri sledují a evidují chyby • známé prostˇredí Beta testování

• testují uživatelé u sebe • neznámé prostˇredí • výsledkem je zpráva uživatele ⇒ modifikace softwaru ⇒ pˇredání softwaru k používání

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

´ Tema: Agiln´ı metodologie

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

Metodologie • disciplinovaný proces nad vývojem softwaru s cílem zajistit tento vývoj ˇ více predikovatelný a efektivnejší

• cˇ astá kritika "byrokratizace" metodologií – pˇríliš mnoho aktivit, které metodologie pˇredepisuje, zpusobuje ˚ snížení efektivity celého procesu vývoje

• ⇒ nová skupina metodologií – lightweight methodologies, dnes agile methodologies (agilní metodologie)

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

Agiln´ı metodologie • snaha o kompromis mezi chaotickým pˇrístupem bez procesu˚ a pˇrístupem s mnoha procesy

• rozumná velikost souboru procesu˚ k zajištení ˇ pˇrimeˇ ˇ reného zisku • menší objem dokumentace v každém kroku ⇒ klíˇcová cˇ ást dokumentace je zdrojový kód!

• základní charakteristiky: ◦ adaptivní vs. prediktivní metody (pˇrístupy) ◦ people-oriented vs. process-oriented metody (pˇrístupy)

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

´ ´ ı metod Zakladn´ ı srovnan´ Adaptivní vs. prediktivní

• prediktivní metody ◦ plánují velké cˇ ásti softwarových procesu˚ velmi detailneˇ pro dlouhý cˇ asový úsek

• adaptivní metody (agilní metodologie) ◦ reagují na zmeny, ˇ procesy se v cˇ ase vyvíjejí People-oriented vs. process-oriented

• process-oriented metody ◦ definují pevnou posloupnost kroku˚ ◦ procesy by mely ˇ fungovat za všech okolností (zmena ˇ týmu, . . . ) • people-oriented metody (agilní metodologie) ◦ žádný proces nikdy nevytváˇrí dovednosti (znalosti) vývojového týmu ◦ úlohou procesu je podpora práce vývojového týmu

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.30/55

Predikovatelnost procesu v´yvoje • existují projekty, kde máme na zaˇcátku pomern ˇ eˇ jasnou pˇredstavu ◦ projekty vyžadující mnoho procedur, cˇ asu, velké týmy a stabilní požadavky ◦ projekty NASA, . . . ◦ ⇒ dobrá predikovatelnost procesu vývoje

• existují projekty, kde máme na zaˇcátku pomern ˇ eˇ jasnou pˇredstavu ◦ ale s cˇ asem se mení ˇ okolní podmínky a tedy i požadavky ◦ business projekty, . . . ◦ ⇒ horší predikovatelnost procesu vývoje • existují projekty, kde máme na zaˇcátku pomern ˇ eˇ mlhavou pˇredstavu ◦ business projekty, . . . ◦ ⇒ špatná predikovatelnost procesu vývoje

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.31/55

Predikovatelnost procesu v´yvoje

ˇ Problém vetšiny projektu˚ je, že se požadavky ˇ neustále mení.

Je tedy predikovatelnost nemožná?

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

Predikovatelnost procesu v´yvoje Pˇrístupy k ˇrešení

• requirements engineering ◦ pˇred tvorbou softwaru získat plneˇ srozumitelný obraz požadavku˚ schválený (podepsaný ) zákazníkem ◦ definování procedur limitujících zmeny ˇ požadavku˚ po schválení ◦ klade vysoké nároky na proces specifikace požadavku˚ a preciznost jejich vyjádˇrení

• fixní požadavky ◦ jejich vytvoˇrení stojí pˇríliš mnoho energie a cˇ asu • adaptivní metody • ...

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

ˇ ızen´ı adaptivn´ıch procesu˚ R´ • Iterativní vývoj ◦ inkrementální ◦ spirálový ◦ ... • Každá iterace zahrnuje ◦ analýzu požadavku˚ ◦ návrh (úpravy návrhu) ◦ implementaci ◦ testování ◦ analýzu rizik • Otázka délky iterace ◦ týdny ◦ mesíce ˇ ◦ ... ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.33/55

ˇ ızen´ı adaptivn´ıch procesu˚ R´ Plánování procesu˚

• v první iteraci se vždy provádí plánování procesu, ˚ a to na základeˇ zkušeností cˇ i dostupných metodik

• tento plán se behem ˇ ˇ iterací vyvíjí (zpˇresnuje) podle reálného stavu

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

Process-oriented methods • striktneˇ definované procesy • lidé jsou zdroje, které jsou dostupné v nekolika ˇ rolích ◦ analytik ◦ manažer ◦ programátor ◦ tester ◦ ... • podstatná je role, nikoliv individualita lidí ◦ není duležité ˚ jaké analytiky máte, ale kolik jich máte ◦ cˇ lovek ˇ je jednoduše nahraditelná komponenta vývojového procesu • za standardní prostˇredek komunikace se považuje dokumentace

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

Process-oriented methods • striktneˇ definované procesy • lidé jsou zdroje, které jsou dostupné v nekolika ˇ rolích ◦ analytik ◦ manažer ◦ programátor ◦ tester ◦ ... • podstatná je role, nikoliv individualita lidí ◦ není duležité ˚ jaké analytiky máte, ale kolik jich máte ◦ cˇ lovek ˇ je jednoduše nahraditelná komponenta vývojového procesu • za standardní prostˇredek komunikace se považuje dokumentace

ˇ vykonávající práci není ten, kdo Teze: cˇ lovek ˇ muže ˚ nejlépe urˇcit, jak tuto práci nejlépe udelat ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.35/55

People-oriented methods Design and programming are human activities; forget that and all is lost. Bjarne Stroustrup, 1991

• lidé mají problémy fungovat konzistentneˇ v prub ˇ ˚ ehu cˇ asu ◦ pokud cˇ lovek ˇ dostane každý den stejný úkol, vytvoˇrí podobné výsledky, ale nikdy ne stejné ◦ schopnost pracovního nasazení/soustˇredení ˇ se mení ˇ den ze dne, z ˇ rí pracují lépe v noci) místa na místo (nekteˇ

• lidé jsou komunikující bytosti ◦ fyzická blízkost – gestikulace, hlasový projev, intonace ◦ otázky a odpovedi ˇ v reálném cˇ ase

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

People-oriented methods Design and programming are human activities; forget that and all is lost. Bjarne Stroustrup, 1991

• lidé mají problémy fungovat konzistentneˇ v prub ˇ ˚ ehu cˇ asu ◦ pokud cˇ lovek ˇ dostane každý den stejný úkol, vytvoˇrí podobné výsledky, ale nikdy ne stejné ◦ schopnost pracovního nasazení/soustˇredení ˇ se mení ˇ den ze dne, z ˇ rí pracují lépe v noci) místa na místo (nekteˇ

• lidé jsou komunikující bytosti ◦ fyzická blízkost – gestikulace, hlasový projev, intonace ◦ otázky a odpovedi ˇ v reálném cˇ ase

ˇ je kompetentní profesionál schopný Teze: cˇ lovek rozhodovat všechny technické otázky své práce. ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.36/55

efektivnost komunikace

Efektivnost komunikace

whiteboard

telefon

mail dokument forma komunikace ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.37/55

Agiln´ı metodologie Základní teze

• Jediná cesta, jak proveˇ ˇ rit správnost navrženého systému, je co nejrychleji ˇ jej vyvinout, pˇredložit zákazníkovi a na základeˇ zpetné vazby upravovat. ˇ • Clen týmu je schopen rozhodovat technické otázky své práce. • Rozumná velikost souboru procesu. ˚ Klasické pravidlo

• Implementujeme pro dnešek, navrhujeme pro zítˇrek.

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

Agiln´ı metodologie Základní teze

• Jediná cesta, jak proveˇ ˇ rit správnost navrženého systému, je co nejrychleji ˇ jej vyvinout, pˇredložit zákazníkovi a na základeˇ zpetné vazby upravovat. ˇ • Clen týmu je schopen rozhodovat technické otázky své práce. • Rozumná velikost souboru procesu. ˚ Klasické pravidlo

• Implementujeme pro dnešek, navrhujeme pro zítˇrek. Upravené pravidlo

• Implementujeme pro dnešek, navrhujeme pro úspešnou ˇ implementaci.

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

Agiln´ı metodologie Agilní metodologie

• • • • • •

Extreme programming (XP) Crystal Scrum Feature Driven Development Dynamic System Development Method (DSDM) ...

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

´ ı programovan´ ´ ı (XP) Extremn´ Koˇreny 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 ruzných ˚ projektech, rozšiˇrování idejí agilního pˇrístupu

• http://www.extremeprogramming.org

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.40/55

Charakteristicke´ prvky XP Komunikace

• programátoˇri, zákazníci a manažeˇri musí spolu komunikovat • XP využívá takové techniky, které komunikaci vyžadují (testování, párové programování, odhady úkolu) ˚

• cˇ len týmu, který udržuje komunikaˇcní toky, pomáhá programátorum ˚ s technickými dovednostmi, komunikuje s manažery na vyšších úrovních

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.41/55

Charakteristicke´ prvky XP Komunikace

• programátoˇri, zákazníci a manažeˇri musí spolu komunikovat • XP využívá takové techniky, které komunikaci vyžadují (testování, párové programování, odhady úkolu) ˚

• cˇ len týmu, který udržuje komunikaˇcní toky, pomáhá programátorum ˚ s technickými dovednostmi, komunikuje s manažery na vyšších úrovních ˇ Zpetná vazba

• "Zeptej se systému", "Už máš napsaný test?" • snaha mít co nejdˇríve nejduležit ˇ cˇ ásti systému, ˚ ejší nejlépe pˇrímo v provozu

• zpetná ˇ ˇ být rychlá vazba by mela • pˇrehnaný optimismus se léˇcí zpetnou ˇ vazbou • cˇ len týmu, který sleduje metriky, srovnává je s oˇcekávaným stavem (nutnost malé režie)

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.41/55

Charakteristicke´ prvky XP Jednoduchost

• • • •

ˇ která by ješteˇ fungovala?" "Co je nejjednodušší vec, je dobré udržovat si pˇrehled o tom, co bude nicméneˇ je nutné soustˇredit se na to, co je potˇreba práveˇ ted’ ˇ je tˇreba vytváˇret jednoduše jednoduché veci ˇ ⇒ úspora cˇ asu na opravdu složité veci

• v pˇrípadeˇ potˇreby není problém jednoduché veci ˇ rozšíˇrit

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

Charakteristicke´ prvky XP Jednoduchost

• • • •

ˇ která by ješteˇ fungovala?" "Co je nejjednodušší vec, je dobré udržovat si pˇrehled o tom, co bude nicméneˇ je nutné soustˇredit se na to, co je potˇreba práveˇ ted’ ˇ je tˇreba vytváˇret jednoduše jednoduché veci ˇ ⇒ úspora cˇ asu na opravdu složité veci

• v pˇrípadeˇ potˇreby není problém jednoduché veci ˇ rozšíˇrit Odvaha

• nebát se provést zásadní zmeny ˇ (napˇr. i za cenu doˇcasného snížení ˇ úspešnosti testu˚ a tedy zvýšeného úsilí)

• nebát se zahodit naprogramovaný kód • nebát se zkusit neznámé (když nevíš, že to nejde, muže ˚ se to podaˇrit)

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

´ Zakladn´ ı techniky XP ˇ Pˇrírustkové ˚ (malé) zmeny

• návrh a implementace se mení ˇ v cˇ ase jen pozvolna • uvolnování ˇ ˇ požadavky, postupneˇ malých verzí systému (nejpodstatnejší ˇ vylepšované a doplnované)

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

´ Zakladn´ ı techniky XP ˇ Pˇrírustkové ˚ (malé) zmeny

• návrh a implementace se mení ˇ v cˇ ase jen pozvolna • uvolnování ˇ ˇ požadavky, postupneˇ malých verzí systému (nejpodstatnejší ˇ vylepšované a doplnované) Testování

• "Co nelze otestovat, to neexistuje." • ke každé funkci píšeme testy (mnohdy testujeme dˇríve, než programujeme)

• zautomatizovaný systém testu˚ • integrace a integraˇcní testování

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

´ Zakladn´ ı techniky XP Párové programování

• jednu vec ˇ programují vždy 2 programátoˇri (ale pouze 1 skuteˇcneˇ píše) • ten, kdo píše, se soustˇred’uje na nejlepší zpusob ˚ implementace problému • druhý se soustˇred’uje na problém z globálnejšího ˇ pohledu bude to fungovat, jaké další testy, možnost zjednodušení, . . .

• páry jsou dynamické

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.44/55

´ Zakladn´ ı techniky XP Párové programování

• jednu vec ˇ programují vždy 2 programátoˇri (ale pouze 1 skuteˇcneˇ píše) • ten, kdo píše, se soustˇred’uje na nejlepší zpusob ˚ implementace problému • druhý se soustˇred’uje na problém z globálnejšího ˇ pohledu bude to fungovat, jaké další testy, možnost zjednodušení, . . .

• páry jsou dynamické Refaktorizace

• • • •

ˇ návrhu úprava stávajícího programu – zjednodušení, zefektivnení ˇ (úprava) nepotˇrebných cˇ ástí odstranení ˇ ˇ zmena architektury (pravidlo pˇrírustkové ˚ zmeny) ˇ funkcionalita! pˇri refaktorizaci se nemení

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.44/55

´ Zakladn´ ı techniky XP Metriky

• • • • •

duležitá ˚ souˇcást urˇcení kvality softwarových procesu˚ ˇ plánovaného cˇ asu a skuteˇcného cˇ asu napˇr. pomer ˇ rený poˇcet metrik (3 – 4) pˇrimeˇ pokud pˇrestane metrika plnit svuj ˚ úˇcel ⇒ nahradit jinou napˇr. metrika testu˚ funkcionality se blíží 100% ⇒ nahradit jinou s menší ˇ úspešností

• existují pravidla udávající kdy a jak cˇ asto by se mely ˇ jednotlivé techniky používat

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.45/55

Proces v´yvoje v XP Iterace

• 1 – 4 týdny • nezbytným výsledkem je sada testu˚ funkcionality • v první iteraci ◦ základy architektury ◦ výsledkem je základní funkˇcní systém • v dalších iteracích ◦ rozšiˇrování základní verze ◦ hledání odchylek od plánu (ˇcas, testování, . . . ) ◦ v pˇrípadeˇ odchylek zmena ˇ ˇ plánu nebo zmena procesu

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.46/55

Proces v´yvoje v XP ˇ Správný návrh se vyznacuje

• • • •

všechny testy fungují, neobsahuje duplicitní logiku, má co nejmenší poˇcet tˇríd a metod, ˇ návrhu. programátor zná všechny zámery

Motivace vývojáˇru˚

• lidé lépe pracují, pokud je práce baví • jídlo, hraˇcky, vybavení pracovište, ˇ ...

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.47/55

Je RUP agiln´ı metodou?

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.48/55

Je RUP agiln´ı metodou? Základní charakteristika

• • • •

základní vyjadˇrovací prostˇredek je UML pracuje v iteracích definuje obsah každé iterace definuje pracovní rámec (framework)

Použití RUP

• klasický heavyweight proces • agilní proces

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.48/55

Je RUP agiln´ı metodou? Craig Larman

• "light RUP" • mesíˇ ˇ cní iterace • první 3 dny iterace využití UML pro pˇriblížení návrhu pro danou iteraci dX proces

• minimální RUP proces • považuje UML za jeden z možných pomocných prostˇredku˚

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.49/55

Principy agiln´ıch metodologi´ı – shrnut´ı Iterativní a inkrementální vývoj

• krátké iterace • nové funkce (funkcionalita) se dodávají cˇ asto • zákazník má pocit, že se neco ˇ deje, ˇ má možnost rychle modifikovat funkcionalitu / požadavky Princip jednoduchosti

• "Implementujeme pro dnešek, navrhujeme pro zítˇrek." ⇒ {problém ˚ na základeˇ predikovatelnosti} ⇒ zvyšování funkcionality (nákladu) spekulace

• "Do systému vložíme to, co potˇrebujeme, když to potˇrebujeme." 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, cˇ asté schuzky ˚ se zákazníkem, . . . ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.50/55

Principy agiln´ıch metodologi´ı – shrnut´ı ˇ Zákazník je clenem 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, . . . ˇ Prub ˚ ežné automatizované testování

• cˇ asté zmeny ˇ systému vyžadují cˇ asté oveˇ ˇ rování správnosti • testy by mely ˇ být automatizované • testy by mely ˇ být napsány pˇred implementací Dokumentace

• význam formálních dokumentu˚ je snižován • základní dokumentace je zdrojový kód (klade se na nej ˇ nejvetší ˇ duraz) ˚ • uživatelský manuál (ne pˇríliš rozsáhlý)

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.51/55

Prediktivn´ı cˇ i agiln´ı metodologii? Kdy použít agilní metodologii?

• neurˇcité nebo menící ˇ se požadavky • odpovední ˇ a dobˇre motivovaní vývojáˇri • 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

ˇ metodologie ovšem závisí na mnoha dalších aspektech . . . Výber

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.52/55

Poznatky z praxe Pˇrístupy lidí

• vývoj podle pˇredpisu˚ – mužeme ˇríci, že neúspech ˇ není naše chyba ˚ • lidé preferují konzervativní pˇrístup a neúspech ˇ ˇ s odlišnou metodou než riskovat úspech

• každá nová technika návrhu vypadá pˇríliš složiteˇ na použití • návrhové týmy ignorují nástroje a techniky, které nemají rádi • lidé pracují (uˇcí se) dobˇre podle pˇríkladu˚ Metodologie

• vetšina ˇ metodologií muže ˚ být vytvoˇrena (použita) tak, ˇ aby pracovala v nejakém projektu

• • • •

ˇ ˇ libovolná metodologie muže ˚ vést nejaký projekt k neúspechu ˇ úspešné týmy používají inkrementální vývoj ˇ "heavy" procesy bývají úspešné ˇ úspešné, ˇ ˇ je pˇripisován práveˇ "light" procesy jsou cˇ asteji úspech "lightness" použité metodologie ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.53/55

SW inˇzen´yr a metodologie ˇ dobrý SW inženýr? Co musí umet

• vybrat vhodnou metodologii nebo • na základeˇ metodologií vytvoˇrit scénáˇr vývoje softwaru tak, ˇ eˇ dosáhl stanoveného cíle, aby projekt úspešn

• stanovit cíle splnitelné v daném prostˇredí ◦ cena ◦ termín dokonˇcení ◦ funkˇcnost ◦ kvalita a to s ohledem na vývojový tým, který má k dispozici.

´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.54/55

Dalsˇ ´ı reference • http://www.martinfowler.com/articles/newMethodology.html • http://agilemanifesto.org/ • 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. • • • • •

http://alistair.cockburn.us http://www.controlchaos.com

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. ´ ´ Uvod do softwaroveho inˇzen´yrstv´ı IUS 2009/2010 – p.55/55