Srovnávací analýza metodik vývoje software

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb Vladimír Popelka Srovnávací analýza metodik vývoje software Bakalářská práce 2009

2 Zadání bakalářské práce

3 Prohlášení Prohlašuji, že jsem bakalářskou práci na téma Srovnávací analýza metodik vývoje software vypracoval samostatně. Všechny zdroje použité při zpracování této bakalářské práce uvádím v přiloženém seznamu použité literatury. V Praze dne Vladimír Popelka

4 Poděkování Rád bych věnoval své poděkování paní PhDr. Heleně Kučerové za odborné vedení, ochotu, připomínky a cenné rady při zpracování tématu bakalářské práce. Dále děkuji panu Ing. Josefu Gabrielovi, zaměstnanci společnosti Unicorn a.s., za odborné konzultace.

5 Obsah 1. Úvod Cíl práce Klíčová slova Hypotéza Metodologie práce Zdůvodnění výběru tématu práce Představení společnosti UNICORN Rizika spojená s návrhem a realizací software Problémy při vývoji software Základní příčiny problémů Příčiny výskytu chyb Eliminace problémů vývoje software Porovnání metodik vývoje software Agilní a rigorózní metodiky Charakteristika směrů vývoje software Tabulka porovnání rigorózních a agilních metodik Porovnání a rozdíly směrů vývoje software Manifest agilního vývoje software Výběr metodik pro porovnání Metodika RUP zástupce rigorózního vývoje Výběr agilních metodik Základní popis zvolených metodik Metodika Rational Unified Process Extrémní programování (XP) Feature Driven Development (FDD) Test Driven Development Výběr vhodné metodiky pro projekt Charakteristika projektu Formulace problému Vymezení problému Stanovení kritérií pro porovnání Kritéria klasifikace metodik

6 4.2.2 Popis kritérií pro porovnání metodik Metodiky podle stanovených kritérií Analýza číselného hodnocení kritérií Stanovení vah pro kritéria Výběr vhodné metodiky podle optimalizační metody Řešení problému pomocí metody TOPSIS Návrh vhodné metodiky pro projekt Testovací strategie Testovací cyklus Kategorizace testů podle metodiky RUP Klasifikace testů podle viditelnosti kódu Klasifikace testů podle dimenze času Klasifikace testů podle dimenze typů testů Návrh testovací strategie Závěr Zhodnocení dosažení cílů Vyhodnocení cílů Vyhodnocení hypotézy práce Závěrečné shrnutí práce Vyhodnocení porovnání metodik software Vyhodnocení návrhu testovací strategie Seznamy a přílohy Seznam použité literatury Seznam obrázků Seznam tabulek Přílohy

7 Abstrakt Srovnávací analýza metodik vývoje software Tématem této bakalářské práce jsou metodiky vývoje software. Úkolem je stanovit rizika spojená s návrhem a realizací software, vymezit problémy a jejich příčiny při vývoji software. Hlavním cílem bakalářské práce je porovnání metodik pro vývoj software. V rámci této bakalářské práce byla porovnána metodika RUP (Rational Unified Process), jako zástupce rigorózního vývoje, s metodikami XP, TDD, FDD, jako zástupci agilního vývoje. Porovnání bylo realizováno pomocí vícekriteriální optimalizační metody TOPSIS. Vybrané metodiky byly porovnány se zaměřením na oblast testování. Na základě specifikace požadavků projektu byla zvolena vhodná metodika pro vývoj software. Pro vhodnou metodiku byla navrhnuta testovací strategie pro pokrytí systému testy, zahrnující testovací cyklus a klasifikaci testů. 7

8 Abstract The comparative analysis of software development methodologies This bachelor work deals with different methodologies of software development. It aspires to define risks connected with design and realization of software and to depict problems encountered during software development as well as their causes. The main aim of my bachelor work is to compare different methodologies of software development. I tried to compare the RUP methodology (Rational Unified Process), as a representative of rigorous development, with XP, TDD and FDD methodologies, as representatives of agile development. Comparison was carried out by the multicriterion optimalization method TOPSIS. Chosen methodologies were compared with focus on software-testing issues. In accordance with specification of project requirements the suitable software development methodics was chosen. For this suitable methodology the test strategy for coverage of system with tests, including the testing cycle and tests classification, was designed. 8

9 1. ÚVOD 1. Úvod 1.1 Cíl práce Hlavním cílem bakalářské práce je porovnání metodik pro vývoj software se zaměřením na oblast testování. V rámci této bakalářské práce budu porovnávat metodiku RUP (Rational Unified Process), jako zástupce rigorózních metodik, s metodikami XP, TDD, FDD, jako zástupci agilního vývoje. Porovnání bude realizováno pomocí vícekriteriální optimalizační metody TOPSIS. Dalším úkolem je stanovit rizika spojená s návrhem a realizací software, vymezit problémy a jejich příčiny při vývoji software. Na základě specifikace požadavků projektu zvolím vhodnou metodiku pro vývoj software. Pro vhodnou metodiku navrhnu testovací strategii pro pokrytí systému testy, zahrnující testovací cyklus a klasifikaci testů. 1.2 Klíčová slova metodiky vývoje software agilní a rigorózní metodiky Rational Unified Process testování software testovací strategie TOPSIS 1.3 Hypotéza Hlavním předpokladem této práce je, že na základě porovnání metodik vývoje software zaměřeného na problematiku testování a na základě jasně definovaných požadavků na projekt bude pro řízení softwarového projektu zvolena metodika RUP. Tato metodika patří v současné době k jedné z nejlépe popsaných. Lze tedy očekávat, že její použití bude mít pozitivní vliv na efektivnější řízení vývojového procesu. 9

10 1. ÚVOD 1.4 Metodologie práce V úvodu práce jsem se soustředil na nejčastější problémy při vývoji software. Moje zkoumání bylo založeno na studiu odborné literatury. Rovněž jsem postupoval podle praktických zkušeností z projektu vývoje software, uplatnil jsem tedy metodu pozorování. V návaznosti na problémy jsem se zaměřil na jejich řešení pomocí metodik. Na základě kritérií jsem porovnal nejprve dva směry vývoje software, rigorózní a agilní metodiky, a poté metodiku RUP a vybrané zástupce agilního vývoje. Výběr metodiky vývoje software jsem prováděl na základě zadání projektu. Volba požadavků nevycházela z žádného skutečného projektu. Porovnání metodik bylo prezentováno na modelové situaci. Pro výběr metodiky jsem použil optimalizační metodu manažerského rozhodování TOPSIS. Nejprve jsem stanovil kritéria, následně jim přiřadil váhy, pak jsem provedl výpočet, jehož výsledkem byla jedna optimální metodika. Klíčovou metodou při porovnávání a výběru metodiky bylo kvalitativní srovnání metodik vývoje software, při němž jsem použil matematické metody. Pro vybranou metodiku jsem zpracoval návrh testovací strategie, kde jsem se zaměřil na testovací cyklus a rozdělení typů testů do kategorií. Při stanovení testovací strategie jsem využil metodu klasifikační analýzy. Nejprve pro každou fázi testovacího cyklu jsem definoval činnosti, které se v ní budou vykonávat, a následně každému aspektu testování jsem přidělil jednotlivé typy testů. Na závěr jsem navrhl testovací strategii, která obsahovala seznam kroků a pravidel, podle kterých se má řídit úspěšné testování. V závěru jsem provedl vyhodnocení zjištěných výsledků. 1.5 Zdůvodnění výběru tématu práce V rámci této bakalářské práce jsem se zaměřil na porovnání metodik vývoje software. Hlavním záměrem práce je porovnání metodiky RUP (Rational Unified Process), jako představitele rigorózních metodik, s vybranými zástupci agilního vývoje. Hlavním důvodem tohoto rozhodnutí byla myšlenka, zda-li metodika RUP představuje vhodné řešení pro řízení projektu a vývoj software. Zúčastnil jsem se projektu pro společnost Unicorn, kde jsem působil v roli test analytika v rámci zajišťování kvality softwarového produktu informačního systému firmy Unicorn. Rovněž mám zkušenost z projektu v oblasti bankovnictví. Na obou těchto projektech byla vždy aplikována metodika RUP. 10

11 1. ÚVOD Volbu vhodné metodiky pro vývoj software a řízení projektu považuji za klíčovou. Proto si myslím, že porovnání metodik vývoje software podle nejrůznějších aspektů a hledisek představuje první krok pro volbu vhodné metodiky a nejdůležitější krok pro efektivní průběh celého projektu. 1.6 Představení společnosti UNICORN UNICORN je největší česká společnost poskytující komplexní služby v oblasti informačních systémů a informačních a komunikačních technologií. [12] Společnost Unicorn byla založena v roce 1990 a využívá více než 17 let zkušeností. Unicorn zajišťuje efektivní řešení a služby zejména v oblastech: projekce, konstrukce, integrace a provozu informačních systémů, dodávky software, konzultací a školení. Pro své zákazníky poskytuje společnost Unicorn služby zaměřené na všechna odvětví průmyslu, pokrývá důležité obchodní a technologické oblasti trhu, zejména pak oblast bankovnictví, financí, telekomunikací, informačních technologií a energetiky. [12] 11

12 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE 2. Rizika spojená s návrhem a realizací software Základním cílem každé firmy bez ohledu, zda-li působí v oblasti bankovnictví, pojišťovnictví, telekomunikací, informačních a komunikačních technologií anebo v dalších segmentech trhu, je uspět v podmínkách tržního hospodářství a otevřené konkurence. Klíčem k úspěchu je v současné době pružně reagovat na změny trhu, přizpůsobit nabídku potřebám zákazníka, schopnost inovovat, prohlubovat vzdělání a neustále se zdokonalovat. Cílem firmy je proniknout na nové trhy a poskytnout svým zákazníkům konkurenční výhodu a přidanou hodnotu v podobě kvality služeb. Schopnost obstát v konkurenci, která se může díky dynamickému charakteru trhu a také vlivem expanze informačních technologií vynořit odkudkoliv, záleží hlavně na efektivním a strategickém řízení firemních procesů. Vzájemnou součinnost a propojenost podnikových procesů, ať už se jedná o řízení lidských zdrojů, strategické rozhodování a plánování, efektivní řízení firemních informací nebo optimalizaci znalostních toků, výrazně usnadňuje informační systém. Kvalitní softwarový produkt je dnes nezbytným řešením jak pro velké organizace, tak i pro malé firmy. Vývoj informačního systému však není jednoduchou záležitostí. Při jeho vývoji dochází k mnoha problémům. Detailnímu rozboru rizik a problémů spojených s návrhem a realizací software se bude věnovat celá tato kapitola. 2.1 Problémy při vývoji software Vývoj software vyžaduje improvizaci, náročné přemýšlení, tvůrčího ducha. Výsledkem práce softwarového inženýrství jsou nehmotné informace, tedy zcela odlišný typ zboží než v uvedených oblastech trhu. Tato skutečnost je základem většiny problémů. Závažné problémy při vývoji software popisuje obrázek (obr.2.1). [6, s. 9] 12

13 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE Obr.2.1. Problémy při vývoji software [6, s. 15] Asi nejčastějším problémem při vývoji software je zpoždění proti stanovenému plánu. Pokud je pevně stanovený termín dokončení a navíc je vázaný na další událost, pak každé zpoždění je kritické. Za problém, který se projeví v pozdních fázích vývoje, je považována nedostatečná výkonnost. Systém špatně funguje pod zátěží, častým jevem jsou výpadky a zpomalení systému. Zátěž výrazně přesahuje limity, které byly odhadovány během vývoje. Aplikace má výkonnostní limit, který lze překročit jen výjimečně. Zjištění nedostatečné výkonnosti během ostrého provozu znamená velký problém, kterému lze předcházet testováním výkonnosti v rámci celého vývojového cyklu. [6, s ] Za další problém bývá označována vysoká chybovost neboli častý výskyt chyb. Chyby se vyskytují téměř vždy. V případě zanedbání testování se při každém zásahu do stávajícího kódu může množství chyb navyšovat. Odladění chyby v hotovém programu je velmi náročné, eliminace chyb může znamenat zpoždění projektu. Zde platí obecné pravidlo, že později objevená závažná chyba značně ovlivňuje růst nákladů. V případě, že je nutné program upravit a k dispozici není dostatečně podrobná dokumentace nebo kód je uveden bez komentáře, každá změna je nesmírně náročná. Pokud se program mnohokrát upravuje, rozšiřuje a zdokonaluje, stává se jeho údržba a správa obtížnou. V tomto případě se jeví jako lepší řešení naplánovat kompletně novou verzi aplikace. [6, s ] Pokud program nesplňuje požadované funkční požadavky, jedná se o další závažný problém, který úzce souvisí se špatnou nebo nedostatečnou vzájemnou komunikací 13

14 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE mezi zadavatelem a řešitelem nebo v rámci vývojového týmu. Komunikační překážky mezi programátory a testery bývají také často umocněny i nepřesnostmi v terminologii. Jestliže se návrh řešení nesetkává s očekáváním koncového uživatele např. z hlediska složitého uživatelského rozhraní, můžeme tuto skutečnost klasifikovat jako další nedostatek. Příliš nepřehledné nebo nepochopitelné uživatelské rozhraní znamená další rizikový faktor. [6, s ] Dalšími problémy, které do jisté míry navazují a doplňují již dříve uvedené, jsou nekoordinovaná součinnost týmu, neslučitelnost jednotlivých programovým modulů a nejasně definované požadavky mezi zákazníkem a řešitelskou firmou. [6, s ; 9] 2.2 Základní příčiny problémů Po provedení analýzy neúspěšného projektu se pro daný problém téměř vždy vyskytne více vzájemně souvisejících příčin, které ho způsobují. Hranice mezi úspěchem a neúspěchem softwarového projektu bývá velmi úzká. [6, s.18] Většina z projektů se řadí mezi tyto dva extrémní stavy. Pokud se vyskytnou problémy obvykle se je podaří překonat za cenu např. zpoždění nebo vynechání plánovaných funkčností programu. Hlavní příčiny, proč softwarové projekty selhávají ukazuje obrázek (obr.2.2). [6, s ; 9] Obr.2.2. Základní příčiny problémů [6, s. 18] Špatné projektové řízení může vést k nesprávné koordinaci týmu, v případě návaznosti práce musí jeden člen týmu čekat na výsledek druhého kolegy. Manažer projektu musí provést objektivnější odhad posloupnosti činností. Tato příčina má společný jmenovatel a pokrývá všechny zde uvedené příčiny. Za nejrozšířenější příčinu problémů softwarového vývoje se považuje podcenění náročnosti projektu. Manažer 14

15 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE projektu neodhadne všechny rizika spojená s projektem a zvolí nevhodný způsob řízení a plánování např. bez ohledu na velikost a rozsah projektu. Jinou významnou příčinou problémů bývá nedostatečné testování. Programátoři snižují důležitost testů, zákazníci význam zkušebního provozu. Jestliže se projekt dostane do skluzu, testy se zkracují a testeři mají časově omezené podmínky pro vyhledávání chyb. [6, s ] Další významné a časté příčiny problémů softwarových projektů jsou špatně definované zadání, nedostatečná analýza požadavků, nekontinuální a nekonzistentní projektový plán. Manažer projektu se nesmí dopustit chyby podcenění projektu a musí si uvědomit všechna rizika, která mohou nastat. Nesprávné rozložení činností v jednotlivých fázích projektu může způsobit např. podcenění analýzy a brzké psaní samotného kódu a programování aplikace. Každý požadovaný aspekt zvyšuje složitost projektu, prodlužuje dobu vývoje, komplikuje budoucí úpravy a snižuje výkon v reálném provozu. Mnoho požadavků a náročné zadání vedou k přílišné složitosti projektu, která je další příčinou problému. Špatná kvalita programového kódu způsobuje mnoho problémů ve fázi testování, nasazení a údržby. Kód je nepřehledný, nesrozumitelný, nejasně okomentovaný a příliš chybový. [6, s ] 2.3 Příčiny výskytu chyb Pokud se v průběhu některé fáze projektu anebo v již dokončené a otestované aplikaci objeví neobvykle mnoho chyb, nastala situace, kdy je velmi pravděpodobný neúspěch softwarového projektu. Vysoká chybovost ve většině případů znamená selhání projektů. Nenalezené chyby mohou způsobit velkou finanční ztrátu. [6, s ] Mezi nejčastější příčiny, které způsobují velké množství chyb a následné selhání projektu patří : [6, s ] Špatná komunikace Dokončení v termínu za každou cenu Nové technologie Nedostatečná zkušenost, znalosti a kvalifikace Nedostatečná (neúplná) definice požadavků Složitost projektu 15

16 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE Chce-li řešitelská firma zabránit velkému výskytu chyb a snížit riziko neúspěchu projektu, musí nutně předejít případným překážkám při komunikaci a vyhnout se nedorozumění. Jestliže zadavatel projektu zapomene zmínit některé požadavky ve specifikaci třeba z důvodu, že je považuje ve svém oboru za samozřejmé, jedná se o jasný příklad špatné komunikace mezi zadavatelem a řešitelem software. Naopak tvůrce, ať už analytik anebo programátor, může mít tendenci zjednodušovat problémy klienta a zaměřit se na technické otázky. Existuje-li hrozba nedodržení termínu, nesmí se stát první obětí testování. Některé nevyřešené funkčnosti systému, které se nestihnou dokončit, se mohou přesunout do následující verze systému. Při snaze o dodržení termínu za každou cenu a dokončení software včas se tvůrci mohou dopustit velkého počtu chyb. Řešením může být posílení týmu nebo zjednodušení požadavků. [6, s ] Používání zcela nové technologie může také způsobit mnoho problémů. První verze nové technologie nemusí být kompatibilní s použitým hardwarem nebo softwarem, v případě nastání potíží není jednoduché najít zkušeného odborníka, který se v technologické novince dokonale vyzná. Proto je prozíravější se nevyzkoušené technologii vyhnout, zejména u velkých projektů. I když je hrozba nefungující technologie minimální, pokud nastane, jedná se o závažné chyby, závažnější než chyby nalezené v programu. Podcenění definice požadavků na systém může mít za následek neustálou změnu požadavků v průběhu nebo dokonce ve finální fázi projektu. Rovněž zkreslení nebo nepochopení požadavků analytikem může vést k chybám. [6, s ] Malá zkušenost, nedostatečná kvalifikace anebo nerovnoměrné rozložení znalostí jednotlivých členů vývojového týmu může znamenat snížení produktivity a výkonu práce při řešení úkolů. Za klíčový se považuje výběr jednotlivých členů týmu. Důležité je stavět týmy vyvážené a nepodceňovat rozdíly znalostí mezi vývojáři. Pro úspěšné dokončení úkolu musí být v týmu dostatek zkušených a schopných vývojářů. Dobrou volbou může být i zapojení nováčka, zvláště pokud se jedná o projekt menšího rozsahu. Častou příčinou selhání projektu je přílišná složitost projektu. Odhad náročnosti projektu musí být reálný stejně jako odhad času, který je nutný na jeho realizaci. Součástí projektového plánu musí být i rezervy na nepředvídatelné události. Někdy je výhodnější zaměřit se na primární aspekty aplikace a doplňky řešit v další verzi programu. [6, s ] 16

17 2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE 2.4 Eliminace problémů vývoje software Cílem vývojového procesu software je snížení výskytu problémů. Problémy, které jsou spojené s návrhem a realizací software se snaží eliminovat metodiky vývoje software. Metodika je tvořena obecně uznávanými postupy a návody, které popisují činnosti při návrhu, vývoji, nasazování software, řízení projektu atd. Cílem metodiky je formalizovat postupy, definovat zodpovědnosti a pravidla komunikace. [3, s. 173] Metodika tedy vymezuje pravidla a kompetence, kdo má provádět jaké činnosti a jakým způsobem během vývoje. Přispívá k efektivní organizaci práce na projektu. Definuje postup řešení jeho priority, zabývá se plánováním, dokumentací a všemi aspekty celého procesu tvorby software. [2, s ; 3, s. 173] V praxi se zcela jistě nenajde softwarový projekt, který by probíhal hladce podle přesně definované metodiky vývoje. Členové vývojového procesu se nikdy nesetkají s podrobnou specifikací dokonale vystihující požadavky zákazníka, nebo s dokonale propracovanou analýzou a návrhem architektury. Proces implementace a testování nikdy nebude bezproblémový. Použití vhodné metodiky pro vývoj software však výrazně přispívá k efektivnějšímu průběhu celého vývojového procesu. Proto její výběr podle požadavků na zadání projektu má klíčový význam pro úspěch celého projektu. Podrobnému popisu metodik vývoje software a porovnání dvou směrů softwarového inženýrství je věnována následující kapitola. 17

18 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE 3. Porovnání metodik vývoje software 3.1 Agilní a rigorózní metodiky Charakteristika směrů vývoje software Softwarové inženýrství přineslo za dobu své existence celou řadu metodik a životních cyklů. V současné době existují dva hlavní směry v metodickém přístupu vývoje software, jedná se o rigorózní a agilní metodiky. Rigorózní metodiky podrobně a přesně popisují jednotlivé procesy vývoje software, definují posloupnost činností, obsahují objemné dokumentace a jsou založeny na sériovém (vodopádovém) vývoji. Zpětnou vazbu mezi fázemi se snaží získat prostřednictvím řízení změn. Rigorózní metodiky umožňují popsat, plánovat a řídit procesy při návrhu a realizaci IS/ICT (informačních systémů a technologií). Některé rigorózní metodiky jsou realizovány iterativním způsobem tzn., že při vývoji jsou opakovaně prováděny jednotlivé fáze anebo inkrementálním způsobem tzn., že systém je vyvíjen v přírůstcích. V následujícím přehledu jsou uvedeny jen nejznámější zástupce rigorózních metodik. [2, s. 29 ; 5, s. 53] 1) Vodopádový model životního cyklu 2) Spirálový model životního cyklu 3) Unified Process (= Metodika Unified Software Development Process) 4) Rational Unified Process 5) Enterprise Unified Process Vývoj software patří mezi dynamicky se měnící odvětví. Změny přicházejí nejen ze strany konkurence a softwarového trhu, ale také nastávají vlivem rostoucího množství, kvality a dostupnosti nových vývojových prostředí a nástrojů. Právě již zmíněný dynamický vývoj vede k přehodnocení popřípadě změnám ve způsobu vedení vývoje software. Tradiční rigorózní přístup se zaměřuje na důkladnou podrobnou analýzu a propracovaný návrh. Některé rigorózní metodiky postupně přestávají naplňovat očekávání a přestávají být použitelné. V současnosti se však začali postupně prosazovat metodiky zaměřené na co nejrychlejší vývoj software a reakci na měnící se požadavky a 18

19 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE zadání. K tradičnímu vývoji se v posledním desetiletí objevil nový proud vývoje, jehož principy jsou poměrně odlišné. [5, s ; 2, s ] Agilní metodiky umožňují vytvořit řešení velmi rychle a pružně je přizpůsobovat měnícím se požadavkům, nesnaží se potlačovat změny, ale naopak jich využívají. Agilní metodiky jsou v rozporu s osvědčenými klasickými postupy softwarového inženýrství, vycházejí totiž z přesvědčení, že správná cesta upřednostňuje rychlý vývoj a následné úpravy změn na základě zpětné vazby od koncového uživatele. Ukazují dosavadním postupům novou cestu a boří některé představy vývoje software, které byly dosud považovány za nedotknutelné. Snaží se řešit požadavky na rychlý a flexibilní vývoj aplikací. [5, s ] Následující přehled představuje jen nejznámější zástupce agilního vývoje. Výčet obsahuje konkrétní metodiky, které vycházejí z agilního manifestu. [5, s. 123 ; 2, s. 44] 1) Adaptive Software Development Adaptivní vývoj software 2) Feature-Driven Development Vlastnostmi řízený vývoj 3) Lean Development 4) Extreme Programming Extrémní programování 5) SCRUM Development Process 6) Crystal metodiky 7) Test-Driven Development Testy řízený vývoj 8) Dynamic System Development Method DSDM Tabulka porovnání rigorózních a agilních metodik Hlavní rozdíly mezi oběma směry vývoje přibližuje tabulka porovnání rigorózních a agilních metodik (Tab.3.1), která je uspořádána podle vybraných hledisek porovnání. 19

20 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE 1. Proces vývoje software 2. Změny a požadavky 3. Zapojení zákazníka na řízení projektu Rigorózní metodiky Přesně a podrobně definovaný proces, lze ho opakovat. Minimalizace změn (sběr požadavků předem a plánování předem), změny jsou součástí řízení změn. Bez zásahu. Nedůvěra v zákazníka - Po podpisu smlouvy a vymezení dokumentu specifikace požadavků v počáteční fázi, zákazníka zajímá až konečné řešení. Agilní metodiky Empirický proces, není možné ho opakovat, ale vyžaduje adaptaci. Akceptace změn (přírůstkové shromažďování požadavků, plánování pro iteraci) přehodnocení požadavků, snaha o umožnění změn (v závislosti na nových znalostech). Participace a spolupráce - Zákazník se aktivně zapojuje do celého projektu, může měnit priority funkcí při každé iteraci. 4. Kvalita Více zaměřeny na kvalitu vlastních procesů, než na výsledek pro zákazníka. Zaměření na priority zákazníka, na užitnou hodnotu pro zákazníka, tedy na výslednou kvalitu produktu. 5. Způsob a rozsah řešení 6. Rozložení teamového know-how Podrobný popis procesů a činností, složité řešení. Při vývoji obsaženy všechny funkce, snaha o zabudování budoucích požadavků. Každý člen týmu má přiřazeny činnosti, v rámci role, kterou zastává. Požadavek na specializaci zaměstnanců. Převládá písemná forma komunikace (dokumentace). Eliminace nepotřebných činností, jednoduché řešení. Při vývoji zahrnuty jen potřebné funkce, snaha o minimalizaci, žádné začlenění budoucích požadavků. Sdílení znalostí v týmu, spolupráce (kooperace) a aktivní komunikace v rámci týmu, společné řešení problémů, řízení a integrace znalostních toků. 7. Lidský faktor Pohled na lidi jako na sekundární faktor, procesy doplňovány rozsáhlou dokumentací. Jedinci jsou nahraditelní. Lidé jako primární a klíčový faktor úspěchu projektu. Využití schopností a dovedností jedinců (individualit), důraz na znalosti, kvalifikaci. 8. Způsob vývoje Vodopádový životní cyklus, iterativní s dlouhými iteracemi. Přírůstkový (inkrementální) vývoj s velmi krátkými iteracemi. Tab.3.1. Porovnání agilních a rigorózních metodik [2, s ; 7] 20

21 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Porovnání a rozdíly směrů vývoje software Množina požadavků na funkcionalitu je jednoznačně stanovena na začátku vývoje. Prioritou tradičního přístupu vývoje zůstává tedy naplnění funkčnosti, přičemž potřebné náklady na projekt stejně jako čas nutný k jeho dokončení se jen odhadují, nikoliv přesně stanovují. Formulace požadavků na funkcionalitu zůstává fixní, variabilní jsou zdroje a čas. Metodiky agilního vývoje naopak přesně vymezují konečný termín dokončení pro realizaci projektu a nejvyšší možné zdroje na začátku projektu. Předmětem změn se stávají jednotlivé funkčnosti aplikace. Požadavky na funkcionalitu se přizpůsobují v průběhu vývoje, zatímco čas a zdroje zůstávají neměnné. [5, s. 119] Agilní metodiky jsou využívány na projektech, kde se zadání často mění nebo není přesně specifikováno. Právě z důvodu častých změn je nutné průběžné a opakované ověřování správnosti zdrojového kódu. Automatizované testování by mělo předcházet implementaci. Silný důraz je kladen na psaní programového kódu, které začíná ihned po vymezení cílu projektu a tvorbě testů. Agilní přístupy kladou důraz na komunikaci mezi procesy (např. párové programování), proto jsou chyby a problémy dříve odhaleny. Nové funkčnosti jsou implementovány poměrně v krátkých dodávkách, proto je iterativní a inkrementální způsob vývoje spojen s velmi krátkými iteracemi. Zákazník má možnost monitorovat a upravovat průběžné konfigurace. Obsahují podstatně menší objem dokumentů, jejich dokumentace není tak rozsáhlá jako u rigorózních metodik. [5, s ] Manifest agilního vývoje software Agilní metodiky prosazují rychlý vývoj a následnou reakci na změny. Trend směřuje k agilnímu vývoji, protože vznikl jako reakce na nedostatky tradičního rigorózního přístupu a zdůrazňuje efektivitu vývojového procesu. Manifest agilního vývoje popisuje následující text. [2, s. 43] Odhalili jsme lepší způsob vývoje software, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Z tohoto pohledu dáváme přednost: individualitám a komunikaci před procesy a nástroji, provozuschopnému software před obsažnou dokumentací, spolupráci se zákazníkem před sjednáváním kontraktu, reakci na změnu před plněním plánu. [2, s. 43] 21

22 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Manifest agilního vývoje vyplývá ze dvou základních myšlenek: [5, s. 120] 1) Efektivnější je přijmout změnu než se jí bránit. 2) Nepředvídatelné události určitě nastanou, proto je změna jedinou jistotou. Manifest deklaruje základní principy agilního vývoje, které jsou shrnuty do následujících řádek. Vítané jsou velmi krátké iterace a zkrácení cyklu dodávky fungujícího software. Preferují se jednoduché postupy vývojového procesu. Na začátku projektu se definují hrubé požadavky pro návrh architektury, přičemž v průběhu projektu je možná jejich úprava na základě přání zákazníka, nebo-li zákazník je aktivním členem týmu. [2, s ; 5, s ] Vítané jsou změny, dokonce i pozdních fázích projektu, neboť můžou znamenat konkurenční výhodu. Zadavatel musí mít z konečného řešení software užitek a přidanou hodnotu. Změnové požadavky promítnuté ve zdrojovém kódu jsou chápány jako přirozené a jen zdůrazňují kvalitu návrhu. O úspěchu projektu rozhodují lidé s knowhow a potřebnou motivací. Proto dlouhodobé přetěžování členů týmu vede k poklesu produktivity práce. Pochopení problému se nejlépe dosáhne pomocí přímé komunikace, nikoliv studiem dokumentace. [2, s ; 5, s ] 3.2 Výběr metodik pro porovnání Metodika RUP zástupce rigorózního vývoje Mezi nejznámější zástupce rigorózních metodik patří vodopádový a spirálový životní cyklus, metodika UP (Unified Process), RUP (Rational Unified Process), EUP (Enterprise Unified Process). Metodika RUP vychází z metodiky UP, jedná se vlastně o její nejrozšířenější a nejúspěšnější variantu. Princip metodik je podobný, rozdíly spočívají v hloubce propracování a v detailech. Zatímco UP je bezplatně dostupná, RUP je komerčním produktem firmy Rational. Metodika UP je otevřený standard, který může použít kdokoliv pro vývoj aplikací. Na rozdíl od metodiky RUP však nepopisuje do hloubky všechny procesy a aktivity, postrádá smysl pro detailní propracování a nemá k dispozici doplňkové nástroje. Metodika EUP zase představuje rozšíření metodiky RUP zejména ve dvou směrech rozšíření na úroveň celé organizace a rozšíření o provoz, údržbu a odstranění produktu z používání. EUP je víceméně doplnění metodiky RUP. [1, s. 56 ; 2, s. 39 ; 5, s ] 22

23 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Spirálový model představuje sekvenci cyklů. Jedná se o přístup řízený riziky, postup vývoje závisí na opakované a kvalitně provedené analýze rizik a problémů. Vodopádový model definuje sekvenční pojetí jednotlivých fází, to znamená, že nelze provádět více fází najednou, po skončení jedné fáze je zahájena následující. Striktní posloupnost kroků a fází má za následek zpoždění projektu, nedostatečné testování, které není průběžné a neschopnost přizpůsobit nové požadavky během vývoje. Vodopádový model však nedostatečně vystihuje požadavky dnešní doby, proto se podle něj vyvíjí stále méně projektů, a to hlavně z důvodu komplikovanosti, nepružnosti a neschopnosti reagovat na změny. [5, s ; 7, s ] Výběr agilních metodik Při výběru agilních metodik pro vzájemné porovnávání s metodikou RUP bude postupováno podle následujících bodů. Metodiky popsané v dostatečné šíři a rozsahu. Metodiky dostupné v česky vydané literatuře. Metodiky odpovídající požadavkům na specifikaci a zadání projektu. Známější a více používanější zástupce agilního vývoje [5, s. 123] Metodiky zaměřené na problematiku testování. Oblast agilních metodik je velmi rozmanitá, konkrétních zástupců existuje velké množství, proto výčet agilních metodik není zcela jistě úplný. Pro výběr metodik do porovnání byly zvoleny rozšířenější a používanější metodiky a hlavně metodiky, které v dostatečné míře popisují problematiku testování software. Většina z agilních metodik se zaměřuje na jiný problematický aspekt, nedostatek tradičního vývoje, nepopisují komplexně všechny fáze, metody a posloupnost kroků. Některé agilní metodiky jsou zaměřeny procesně, projektově, nástrojově, jiné zdůrazňují technické řešení, další se orientují na lidský faktor. Některé z agilních metodik jsou spíše určeny pro krátkodobý a rychlý vývoj. Jako další hledisko výběru je považováno, že některé z metodik nebyly popsány v plné šíři a v dostatečném rozsahu v české literatuře. Proto jsou v práci uvedeny pouze metodiky dostatečně popsané. Uvedeným bodům nejvíce odpovídají agilní metodika Extrémní programování, Feature-Driven Development a Test-Driven Development. Ostatní metodiky nepopisují 23

24 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE proces testování v uspokojivé míře. Zabývají se především jedním aspektem vývoje, neobsahují dostatečně nadefinované fáze a posloupnost kroků vývoje není rovnoměrná. Z tohoto důvodu nebyly zařazeny metodiky SCRUM a Lean Development do užšího porovnání. Metodiky Crystal, DSDM a ADS jsou vhodnější pro rychlý vývoj hlavně pro internetové aplikace. Při výběru byly hodnoceny i principy dalších agilních metodik. Jejich krátký popis byl zařazen do následujících řádků. Z popisu jsou patrné důvody jejich nezařazení do užšího porovnání. [2, s ] Lean Development vychází z výrobních odvětví, má těsné vazby na podnikovou strategii, definuje pravidla a principy, jejichž dodržování slibuje efektivnější vývoj software. Metodika Scrum je zaměřená na řízení projektu, procesy při vývoji software považuje za empirické. Produktivitu a pružnost vývoje zvyšuje pomocí přístupu k organizaci práce v týmu. Monitoruje iterace (sprinty), vývojové epizody, používá praktiky jako jsou denní porady (Scrum meeting). Metodika DSDM zavádí kategorizaci třídění požadavků na základě priorit a také pojem timebox, čili fixní časový interval pro realizaci požadavků. Základní technikou při realizaci je prototypování. ADS popisuje mezníky, konkrétní body a meziprodukty, je označována za proces vzájemného ovlivňování účastníků vývoje, což je hlavní přínos metodiky. ADS je vhodná pro projekty vyznačující se velkými změnami. Metodika Crystal klade důraz především na lidský faktor projektu. Představuje skupinu metodik se stejnými hodnotami a principy, odlišující se díky použitým technikám a nástrojům. 24

25 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE 3.3 Základní popis zvolených metodik Metodika Rational Unified Process Obr.3.1. Metodika RUP [11] Nejlepší praktiky vývoje metodiky RUP [11] Metodika RUP představuje souhrn šesti základních praktik. Jejich použití má za následek předcházení problémů při vývoji software, zajišťuje efektivnější vývoj, lepší řízení kvality. Nejlepší praktiky vývoje metodiky RUP jsou: [5, s ; 9] Iterativní vývoj Během každé iterace proběhnou v menším nebo větším zastoupení všechny vývojové disciplíny. Iterace spočívá v rozdělení vývoje na části, díky tomu je vývoj software efektivnější, snižuje rizikovost projektu, protože dochází k průběžné detekci rizik. Správa a řízení požadavků požadavky jsou dynamické, mění se v čase. Nedefinuje-li zákazník na začátku projektu všechny požadavky, mohou nové požadavky přicházet i v průběhu vývoje projektu. 25

26 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Vizuální modelování je vhodné ke komunikaci. Slouží k vizuálnímu zachycení problému, k zpřehlednění návrhu. Pro znázornění vztahu mezi objekty se často používá modelovací jazyk UML (Unified Modelling Language). Použití komponentové architektury RUP nabízí šablony, návrhové vzory a architektonické styly. Znovupoužití hotové komponenty představuje výraznou úsporu zdrojů. RUP hledá efektivní cestu návrhu a vývoje. Průběžné zajišťování a ověřování kvality Pozdní odhalení chyby může způsobit výrazné škody, její odstranění může být nákladné. Pokud je problém odhalen např. v návrhu, na jeho řešení se vynaloží méně úsilí a prostředků než např. při implementaci. Proto je dobré odhalit problém co nejdříve, je to méně nákladnější a méně náročnější na čas. Řízení změn - RUP je připraven na výskyt změn a na jejich správu a integraci do vývojového procesu. Fáze metodiky RUP [2, s ] RUP je organizován podle časového hlediska do čtyř fází. Fáze zahájení (Inception) Přípravná fáze (Elaboration) Konstrukční fáze (Construction) Fáze předání - transitní (Transition) Ve fázi zahájení se stanovuje rozsah projektu, probíhá návrh předběžné architektury vývoje a tvorba postupů, definují se priority. V rámci incepce se zjišťují celkové náklady a nutné zdroje, definují se potencionální rizika, odhaduje se potřebný čas na projekt a probíhá příprava prostředí projektu. Po dohodě se zadavatelem probíhá vymezení, sběr a analýza základních požadavků. [3, s ; 11] V přípravné fázi nebo také ve fázi projektování se definuje ověření návrhu, předvedení a odsouhlasení architektury. Probíhá návrh stabilního modelu architektury daného systému, vytváří se jeden nebo více prototypů. Při odsouhlasení se musí dokázat, že daná architektura je schopná zvládnout požadavky. Během elaborace se vytváří plán pro následující iteraci a částečná analýza rizik. [3, s ; 11] Konstrukční fáze se zaměřuje hlavně na implementaci. Cílem je dokončení návrhu, kompletuje se analýza a design. Provádí se vytvoření, otestování a dodání první funkční verze systému. V rámci realizace probíhá samotný vývoj software, průběžné testování 26

27 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE systému a vyhodnocování kvality. V průběhu konstrukce je evidentní snaha o paralelní vývoj vybraných Use Case (případů užití). Kontroluje se komplexnost systému a náklady na splnění požadavků. [3, s ; 11] Tranzitní fáze znamená předání finální verze systému koncovým uživatelům. Nasazení produktu u zákazníka je spojeno s jeho podporou. Předávání produktu uživatelům zahrnuje dodání produktu i školení uživatelů, podporu a údržbu až do okamžiku spokojenosti uživatele. Kompletní systém je dodáván s dokumentací a manuály. Provádí se beta testování a drobné úpravy v systému, dále instalace, konfigurace a ladění chyb. [3, s ; 11] Obr.3.2. Disciplíny metodiky RUP Disciplíny metodiky RUP [11] Obsah metodiky RUP je organizován do disciplín (Obr.3.2). Metodika RUP popisuje disciplínu jako sadu aktivit se společným zájmem. [2, s ; 3, s ] Tvorba podnikového modelu - pro znázornění podnikových procesů se používá jazyk UML (business modelování), zajištění komunikace se zadavatelem, zjišťujeme jeho požadavky a potřeby. Správa požadavků - systematický přístup ke tvorbě požadavků na systém, definuje se rozsah a objem požadavků. Analýza a návrh propojují požadavky na systém s jeho implementací, členění systému na komponenty. Implementace - převedení návrhu modelu do spustitelné podoby, vývoj systému, vytváření programu. 27

28 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Testování - průběžné testování a kontrola v každé fázi, cílem testování je ověřit funkčnost systému. Nasazení - zavedení výsledného produktu u klienta do provozu (instalace, konfigurace). Řízení projektu, řízení změn a konfigurace, správa prostředí Cílem metodiky RUP je vytvořit software vysoké kvality bez velkých problémů. RUP definuje kvalitu jako přidanou hodnotu z hlediska zadavatele. Proto má pro ověřování kvality nadefinovanou dimenzi kvality FURPS. Typy testů FURPS by měly zajišťovat kvalitu systému a výrazně snížit výskyt defektů (chyb) hlavně z hlediska funkčnosti, použitelnosti, spolehlivosti, výkonu a podporovatelnosti aplikace. RUP rovněž definuje klíčové body tzv. mezníky (milníky), které slouží pro zhodnocení stavu projektu na konci jednotlivé fáze cyklu. [9 ; 5, s ] Extrémní programování (XP) Základní charakteristika a popis XP XP patří mezi nejrozšířenější metodiku agilního vývoje, přestože její historie je velmi krátká, její vznik se datuje do roku XP představuje relativně účinný, flexibilní a předvídatelný postup vývoje software, využívá velmi rozumný přístup a realistický způsob myšlení, avšak jejich používání dotahuje do extrémů. XP vymezuje určitou šíři, v jejímž rozmezí se pohybuje zadání. Šíře zadání specifikuje množinu funkcí, které zadavatel vyžaduje. Jasně definuje, které funkce jsou pro zákazníka klíčové a které jsou méně důležité. XP vychází primárně z principu jednoduchosti základní funkčnosti, ostatní změny, budou-li potřeba, řeší někdy v budoucnu. Klíčem k úspěchu je zabývat se tím, co je důležité nyní, a nikoliv předpokládanou budoucností, která se pravděpodobně nevyhnutelně změní. [5, s ; 13] Testování je jednou z nejdůležitějších metod pro realizaci zpětné vazby v XP. Až výsledky testování určí, zda-li všechny funkce a moduly projdou anebo se prokáže nutnost oprav a modifikací. Testování v XP probíhá na několika úrovních. Programátoři píší testy pro ověřování aplikační logiky, zákazníci píší testy funkcionality pro jednotlivé moduly. XP deklaruje, že pravděpodobnost úspěšného dokončení projektu je závislá na množství napsaných testů, intenzitě pátrání po chybách a na různorodosti 28

29 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE ověřování zpětné vazby. V případě výskytu problému, nalezení kritické chyby XP zdůrazňuje chybu opravit za každou cenu, i kdyby to znamenalo ztrátu podstatné části zdrojového kódu nebo přepracování celého dosavadního návrhu a architektury. [5, s ; 13] Praktiky a pravidla XP XP dodává nejjednodušší možné verze, které jsou schopné provozu, verze dodává po velmi krátkých iteracích. Architektura (metafora) může být chápána jako abstrakce, která umožní uživateli sjednotit sdílený pohled na systém. Systém je neustále sestavován a integrován, vždy po dokončení nějakého nového úkolu. XP doporučuje dodržování systémové metafory tzn. konzistentní pojmenovávání tříd a metod. Pojmenování objektů je důležité pro porozumění celkového návrhu a znovupoužitelnost kódu. [5, s ] Pro kontrolu zdrojového kódu je využívána technika párového programování. Kód je psán dvěma programátory u jednoho počítače. Úprava zdrojového kódu bez změny jeho funkčnosti se provádí pomocí techniky refaktorování. Refaktorování výrazně zlepšuje čitelnost kódu, odstraní duplicity, usnadňuje budoucí údržbu a rozšiřování systému. Průběžné testování zahrnuje hlavně testování modulů (unit testing), dále testování funkcionality, testování v produkci zákazníkem a v rozsáhlejších projektech i testování integrace. [5, s ] Všechny informace jsou uchovány ve formě zdrojového kódu, XP nepodporuje žádné dokumentace, naopak podporuje standardy pro psaní zdrojového kódu. Kódování je totiž první činnost v počátečních stádiích vývoje, proto je nutná čitelnost, strukturovanost a srozumitelnost kódu. Pro XP je charakteristické společné vlastnictví kódu, kdy každé části rozumí jeden expert. [5, s ] Životní cyklus projektu vyvíjeného pomocí XP: XP nedefinuje posloupnost fází projektu, ale zvláštní postup určený k plánování projektu, k rozhodování o náplni iterací a vývojových fází. XP nedodává žádné dokumentace, nepopisuje žádné milníky nebo kontrolní body během celého životního cyklu, protože upřednostňuje přímou komunikaci nad zdrojovým textem. [5, s ] 29

30 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Základní činnosti XP: Obr.3.3. Základní činnosti XP Testování probíhá před kódováním, nejprve se programuje test modulu, každý modul musí projít automatizovanými testy, poté proběhne integrace modulu. Pomocí automatizovaných testů provádí vývojáři refaktorizaci. Neustálé testování umožňuje snížit čas dodání aplikace. Psaní zdrojového kódu nastane po napsání testů. Po implementaci modulu dojde k nasazení. Návrh představuje strukturu, jak uspořádat logiku v systému. Změna v jedné části systému, nevyžaduje změny v dalších subsystémech. Komunikace zákazníka jako zadavatele a programátora jako řešitele je nutnou podmínkou. [5, s ] Základní činnosti XP: Plánování Specifikace činnosti šíře zadání, hrubý plán, plán verze Návrh refactoring, metafora - znovupoužitelnost kódu, princip jednoduchosti základních funkčností Kódování (psaní zdrojového kódu) Testování párové programování, společné vlastnictví kódu, integrace změn kódu, tvorba kódu pro unit testy, tvorba zdrojového kódu, standardy kódu unit testy, akceptační testy Tab.3.2. Základní činnosti XP 30

31 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE XP se rovněž zaměřuje na práci s lidmi. Význam motivace lidí a složení vývojového týmu je důležitý v případě, že se zjistí nějaký nedostatek nebo chyba a nelze pokračovat dále, napsaný zdrojový kód se musí vyhodit a vývoj se musí vrátit zpět a začít znovu. To, že vývoj XP směřuje zpět, je poměrně častým jevem. XP je postavené na myšlence, že ztráta hotové části kódu není selhání. Pokud současná architektura nevyhovuje, bez otálení se přepracuje i za cenu zahození zdrojového kódu. [5, s ] Mezi výhody vývoje pomocí XP patří široká možnost úprav a přímočarý postup k cíli. Problémy a obtíže jsou při praktické realizaci, hlavně na začátku, kdy si vývojový tým na metodiku teprve zvyká. [5, s ] Feature Driven Development (FDD) Základní charakteristika a popis FDD Metodika FDD klade silný důraz na disciplínu modelování, která se tak stává důležitou složkou celého procesu. Jedná se o vývoj řízený užitnými vlastnostmi, tedy výsledkem funkčnosti, hodnotným pro zákazníka, který lze měřit, popsat a realizovat v rámci iterace. Během iterace se provádí návrh a realizace jednotlivých užitných vlastností. FDD nepřeceňuje význam procesů při vývoji, přesto je podporuje, což je u agilních metodik neobvyklé. [5, s ] FDD se snaží eliminovat množství nejistoty a zmatku při vývoji, zaměřuje se na dodávku kvalitní aplikace, soustředí se tedy na maximalizaci výsledného produktu. Metodika vychází z krátkých iterací. Důležitým znakem FDD je průběžné dodávání mezivýsledků a nových verzí produktu zákazníkovi. Zákazník se tak pomocí průběžné kontroly a hodnocení nových funkčních přírůstků může ujistit, že vývoj postupuje správným směrem. [5, s ] Vývojové fáze v metodice FDD Životní cyklus FDD definuje pět klíčových procesů. Návaznost jednotlivých kroků je následující. [5, s ] 1. vytvoření celkového modelu 2. vytvoření seznamu vlastností 3. plánování 4. návrh 5. implementace 31

32 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Obr.3.4. Vývojové fáze v metodice FDD [5, s. 183] Vývoj podle metodiky FDD začíná vytvořením globálního modelu. Na začátku se stanoví cíl a zaměření projektu, požadavky na systém a prostředí pro nasazení systému. Jako první krok při objektově orientovaném vývoji se může využít notace UML. Pro modelování objektů z reálného světa se používá vysoká míra abstrakce. Na základě fáze celkového modelu, funkční specifikace nebo případů užití se systém musí úzce vymezit a definovat základní množinu vlastností. Proto se vytvoří podrobný seznam vlastností, kde jsou vlastnosti klasifikovány podle preference a rozdělovány do skupin podle vzájemné souvislosti a logiky. Nikdy nelze vytvořit konečný seznam. [5, s ] Plán pro další vývoj obsahuje neměnné datum ukončení vývoje, ostatní mezníky mohou být posouvány např. datum ukončení pro jednotlivé skupiny vlastností. Plán rovněž stanovuje na základě priorit, v jakém pořadí budou vlastnosti implementovány. Návrh podle vlastností definuje třídy, které danou vlastnost pokrývají. Výběr jedné nebo více konkrétních vlastností z dané skupiny probíhá podle důležitosti a vzájemných závislostí mezi vlastnostmi. Návrh se zaměřuje na tvorbu diagramu posloupnosti a vyladění objektového modelu pro danou vlastnost. Vypracuje se podrobný plán pro implementaci vlastností. [5, s ] Hlavní činnost ve fázi implementace se soustředí na realizaci podle vlastností. Za implementaci třídy je zodpovědný její vlastník. Vlastník vytváří metody a navrhuje testovací případy pro třídu. Proces testování, inspekce napsaného kódu a testování jednotek probíhá v rámci fáze implementace. Po ověření funkčnosti třídy, tzn. po dokončení všech testů včetně testů modelů tzv. unit testů, následuje umístění třídy do systému pro správu tříd (repozitoře tříd). Poté je vlastnost integrována do verze aplikace. Vlastník třídy může být členem více týmů, jejichž složení se průběžně mění. 32

33 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE Předpokládá se existence více týmů vývojářů pracujících paralelně. Otestované, fungující třídy a metody se implementují pro danou vlastnost. Výsledkem je dokončená vlastnost. [5, s ] Ale dokončená vlastnost může způsobit určité změny v celkové architektuře systému, proto je po implementaci možné provést nutné modifikace v první fázi tvorby globálního modelu. Průběh fází probíhá postupně od první do páté fáze, přičemž fáze návrhu a implementace mohou proběhnout několikrát, jsou iterativně opakovány. Poté se celý cyklus fází opakuje od začátku. [5, s ] Hlavní aspekty vývoje FDD Metodika FDD se do určité míry odlišuje od ostatních metodik především tím, že přichází s několika novými principy a přínosy. FDD umožňuje vývoj podle vlastností. Mezi hlavní znaky FDD patří rovněž vlastnictví tříd a sestavení týmu podle vlastností. [5, s ] Test Driven Development Základní charakteristika a popis TDD Při každém procesu vývoje software je fáze testování nezastupitelná, protože testování je jedna z nejdůležitějších složek v oblasti zajišťování kvality. Existuje ale jedna metodika, která proces testování povyšuje nad ostatní kroky při vývoji, metodika, která klade důraz na testování a označila ho za základ celého vývojového procesu. Tuto myšlenku prosazuje Test-Driven Development. Český ekvivalent pro TDD je programování řízené testy. [5, s ] TDD vyžaduje pro každou funkčnost nejprve napsání testu a až poté napsání kódu. Poté co je testovací kód dokončen, následuje programování samotné funkčnosti. Implementujeme přesně takové množství kódu, kolik dokáže projít testem. [5, s. 198] Nikdy méně, ani více. Když je hotový zdrojový kód, který projde testem, nastává fáze úprav, zefektivnění a zjednodušení zdrojového kódu a kódu testu. Úprava zdrojového kódu bez změny funkčnosti se nazývá refaktorizace. [5, s ] První aktivita v rámci TDD je napsání testu. TDD, ale prohlašuje, že je nutné vytvořit takový test, který selže, jinak nelze implementovat funkci. Implementace je dokončena až pokud funkce projde tímto testem. TDD napravuje chyby dokud jsou ještě 33

34 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE aktuální, eliminuje je v místě jejich výskytu, nebo-li předchází jejich vzniku. [5, s ] TDD není příliš procesně zaměřená. Používání TDD vyžaduje velké nároky na lidský přístup a znalosti, ať už na vedení projektu anebo na programátory, neboť vývojáři se musí vypořádat s psaním testů pro kód, který neexistuje. [5, s. 211] Životní cyklus metodiky TDD Obr.3.5. Životní cyklus metodiky TDD Životní cyklus metodiky TDD se skládá ze tří fází, nejprve probíhá testování, pak implementace a nakonec návrh. Tento způsob vývoje software zcela vylučuje fázi hledání chyb, protože chyby jsou odhaleny již při průchodu testovacím scénářem. Metodika TDD představuje netradiční postup ve vývojovém procesu, kdy testování předchází implementaci. Dodržování takovéto posloupnosti kroků má za následek kompletně otestovanou aplikaci podle všech aspektů kvality. [5, s ] Průběžné ověřování probíhá na úrovni programového kódu, kdy vývojáři zjišťují jeho kvalitu a spolehlivost. Nicméně kromě jednotkových (unit) testů musí být provedeny ještě další typy testů, největší důraz TDD klade na testování uživatelského rozhraní pomocí akceptačních testů a testování integrace. Tyto druhy testu nelze provádět v plné míře automaticky pomocí testovacích nástrojů, ale musí být prováděny také manuálně. Pro podporu testování potřebuje metodika TDD použít nějaký podpůrný nástroj. Velmi užívaným je rodina nástrojů xunit např. nástroj JUnit. [5, s ] 34

35 3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE TDD se příliš nezabývá formálními záležitostmi jako tvorbou různých specifikací a dokumentací. Testovací případy v přehledné formě mohou doplňovat technické dokumentace nebo se stát součástí funkční specifikace, ale v žádném případě dokumentaci nesmí zastupovat jako kompletní a dostačující řešení. Čím vyšší existuje riziko selhání projektu, tím intenzivnější a důslednější testování musí být. Pokud systém dosáhne 100% pokrytí kódu testovacími případy, každá řádka zdrojového kódu projde testy. [5, s ] Lze proto říci, že výsledky metodiky TDD (pokud jde o otestovanost výsledné aplikace) jsou lepší něž v případě aplikací vyvíjených tradičními metodikami a testovaných tradičními technikami. [5, s. 202] 35

36 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT 4. Výběr vhodné metodiky pro projekt 4.1 Charakteristika projektu Formulace problému Bankovní instituce požaduje vytvoření programového řešení bankovního produktu. Jedná se o vytvoření nové verze účetního systému rozšiřující dosavadní systém o nové funkčnosti. Jeho nejdůležitější inovací v nové verzi bude účtování on-line. Základním cílem je implementace změnových požadavků a nových funkčností do stávající, již zavedené verze systému. Úkolem je vytvoření funkční aplikace zprostředkující zpracování účtování jak během účetního dne tak během účetní uzávěrky. Programové řešení nové verze musí splňovat funkční požadavky: V rámci zpracování účtování během účetní uzávěrky: kapitalizace úroků účtování automatických převodů rušení a zakládání účtů aktualizace databázových tabulek a registrů a zálohování stavu účetního dne V rámci zpracování účtování během účetního dne: obraty platebního styku finanční transakce mezi účty vedenými v jiných bankách a v pobočkách transakce on-line účtování trvalé příkazy Po vyhotovení programového řešení nové verze bankovního produktu požaduje zadavatel rovněž zajištění kvality softwarového řešení jeho otestováním. Pro ověření kvality softwarového produktu jsou nastaveny akceptační kritéria pro počet defektů a jejich severitu. Testování bude ověřovat funkčnost softwarového produktu podle návrhu a správnost implementace požadavků. Případné defekty v kvalitě softwaru budou zdokumentovány. 36

37 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT Podle výsledků výběrového řízení na základě rozhodnutí managementu byla zakázka přidělena externí softwarové firmě. Softwarová firma bude zajišťovat služby pro bankovní instituci formou team-leasingového projektu. Management softwarové firmy je postaven před problém, kdy se musí rozhodnout na základě porovnání pro vhodnou metodiku vývoje software. K dispozici má čtyři metodiky a šest kritérií, podle kterých se bude rozhodovat pro jednu z metodik. Pro výběr použije optimalizační metodu minimalizace vzdálenosti od ideální alternativy, metodu TOPSIS (Technique for order preference by similarity ideal solution) Vymezení problému Bankovní instituce jako zadavatel definovala softwarové firmě jako řešiteli následující požadavky na vývoj řešení softwarového produktu. Pro implementaci systému zadavatel preferuje objektově-orientovaný vývoj. Požadavky na funkcionalitu jsou primární. Jakékoliv změny funkcionality zjištěné během vývoje je možno zapracovat, některé méně prioritní změnové požadavky se mohou vyřešit v další verzi. Dodávka do produkce je plánována na přesně stanovený termín. Zadavatel povoluje možnost posunutí termínu dokončení projektu a jeho nasazení na produkci, ale jen v případě potíží při implementaci primárních změnových požadavků. Náklady na projekt jsou vyčleněny ve stanoveném rozmezí, počítá se s finanční rezervou nepřesahující 10% nákladů na projekt. Velikost projektového týmu je stanovena, rozšíření nebo doplnění týmu se nepředpokládá, ani pokud nastanou problémy při vývojovém procesu. Pro případ dalšího rozšíření systému je nutná přehledná dokumentace. Na další verzi systému může pracovat jiná firma, proto zadavatel požaduje dokumentaci. Zadavatel požaduje po řešiteli otestovat výslednou aplikaci. Testování by mělo zajišťovat kvalitu systému. Kvalitu aplikace zadavatel po řešiteli požaduje v následujícím rozsahu. Aplikace musí splňovat v první řadě zajištění funkčnosti, použitelnosti a spolehlivosti, dále stabilitu a výkon. Zároveň aplikace musí mít jednoduché uživatelské rozhraní na ovládání a grafickou podporu komponent. V neposlední řadě aplikace musí pokrývat potencionální rozšiřitelnost a flexibilitu systému, a také kompatibilitu (slučitelnost) verzí. Cílem zadavatele je získat aplikaci, která bude odpovídat funkčním požadavkům ve specifikaci. Bude dodána ve stanovený termín a s přesně vymezenými náklady. 37

38 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT 4.2 Stanovení kritérií pro porovnání Kritéria klasifikace metodik Asi nejzávažnější překážkou při vyhledávání vhodné metodiky pro určitý projekt je neexistence jednotné klasifikace metodik, která by definovala způsob porovnání a následného výběru. Tento nedostatek má příčinu v různorodosti jednotlivých projektů. Projekty se mohou lišit např. velikostí týmu, znalostmi a schopnostmi jedinců v rámci týmu, postavením na trhu, dále podle využití produktu, nebo doméně projektu, jinými slovy pro jaký účel je software vyvíjen. Protože každý projekt je jedinečný, vyžaduje použití různé metodiky. Právě zmíněné odlišnosti, jsou příčinnou pro využití různých metodik podle požadavků na projekt. [2, s. 19] Pro porovnání metodik pro vývoj software pomocí optimalizační metodiky TOPSIS jsou zde využita některá kritéria klasifikace metodik a jejich hodnoty, tak jak je vymezila Alena Buchalcevová v knize s názvem Metodiky vývoje a údržby informačních systémů. Z této práce bylo pro třídění metodik využito kritérium typ řešení [2, s. 28] a přístup k řešení [2, s. 28] a do jisté míry i kritérium váha metodiky [2, s. 28], které bylo přetransformováno do podoby míra složitosti. V rámci této bakalářské práce byla stanovena další kritéria se zaměřením na proces testování. [2, s ; 2, s. 27] Doména vyvíjeného software vymezuje určitou oblast zaměření, účel nebo předmět využití software a zároveň představuje určitou skupinu podnikových procesů. Kritérium doména nebylo zařazeno do porovnání hlavně z důvodu jasného využití software definovaného ve formulaci problému (viz kapitola 4.1.1) a také z důvodu obecné použitelnosti metodik pro různé druhy vyvíjeného software. Metodiky zařazené do konečné fáze porovnání, jsou všeobecně aplikovatelné pro různé typy informačních systémů, čili jen těžce by se mezi nimi stanovovaly rozdíly a odlišnosti. Doménou vyvíjeného software může být např. plánování podnikových zdrojů (ERP), manažerské informační systémy (MIS). [2, s ] 38

39 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT Popis kritérií pro porovnání metodik Pro každé kritérium je připojen krátký popis, kde je charakterizován jeho význam a přiblíženy hodnoty kritéria. Seznam kritérií a jejich hodnoty jsou uvedeny v tabulce (Tab.4.1). Kritérium číslo 1: Typ řešení Při vývoji software se nemusí vždy jednat o vývoj nového řešení od začátku, ale může se provádět např. rozšíření, integrace stávajícího informačního systému anebo jen inovace funkčnosti zavedeného. [2, s. 24] Kritérium číslo 2: Přístup k řešení [2, s. 27] Využívá se hlavně při vývoji nového anebo při rozšíření stávajícího systému. Jeho význam klade důraz na hlavní fáze vývoje analýzu, návrh a implementaci. Přístupy se často kombinují tzn. přístup k řešení je jiný ve fázi analýzy a jiný ve fázi implementace. Hodnoty kritéria přístup k řešení jsou: Objektově-orientovaný pomocí objektů a tříd, využívá dědičnost, polymorfismus a zapouzdření Strukturovaný volání funkcí a procedur RAD (Rapid application development) rychlý vývoj aplikací Kritérium číslo 3: Míra složitosti metodiky Zahrnuje počet, návaznost, rozsah a hloubku fází vývojového procesu. Hodnotí míru podrobnosti, definuje propracovanost a obsáhlost, stanovuje počet kontrolních prvků, jejich propojenost a také velikost týmu. [2, s ] Kritérium číslo 4: Zaměření testování (typ testů) Popisuje na jaké typy a fáze testů (viz kapitola 5.2) se metodika zaměřuje. Jaké typy testů má metodika nadefinované, obsáhlé a které podporuje. Která metodika je nejlépe popsaná z hlediska testování? Kritérium číslo 5: Rozsah (a hloubka) testování Toto kritérium pomáhá nalézt odpověď na otázku, v jaké fázi vývoje se začíná testovat? 39

40 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT Kritérium číslo 6: Zaměření metodiky na fázi vývoje Každá metodika se do jisté míry vymezuje oproti ostatním. Přichází s nějakou novinkou, věnuje pozornost určitému aspektu vývojového cyklu. Toto kritérium popisuje na jakou fázi popř. fáze klade metodika největší důraz. Kritérium Vymezení Hodnota / významu kritéria 1. Typ řešení [2, s. 28] a) nové řešení, b) rozšíření stávajícího, c) integrace řešení, d) inovace [2, s. 28] 2. Přístup k řešení [2, s. 28] a) objektově-orientovaný, b) strukturovaný, c) RAD rychlý vývoj aplikací [2, s. 28] 3. Míra složitosti metodiky (propracovanost, obsáhlost) a) velmi náročná na složitost b) složitá metodika b) střední náročnost c) jednoduchá metodika [2, s ] 4. Zaměření testování (typ testů) a) Základní typy testů: white box a black box b) Fáze testu: unit testy, testy integrace, smoke testy funkční testování, uživatelsko akceptační testy c) ostatní typy testů 5. Rozsah (a hloubka) testování a) testování na začátku vývoje (v počáteční fázi) před implementací b) průběžné testování v každé fázi po každé iteraci během celého vývoje c) testování na konci vývoje před implementací d) testování na konci vývoje v rámci fáze implementace 6. Zaměření metodiky na fázi vývoje a) vyzdvihuje (klade důraz na) jednotlivou fázi : požadavky, návrh, implementace, testování atd. b) rovnoměrné rozložení fází Tab.4.1. Seznam kritérií a jejich hodnot 40

41 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT 4.3 Metodiky podle stanovených kritérií V následující tabulkové části je zpracován základní popis metodik podle stanovených kritérií. Pro jednotlivé metodiky byla každému kritériu porovnání přiřazena hodnota kritéria a číselné ohodnocení kritéria podle formulace zadání a vymezení projektu. Každá tabulka obsahuje kritérium, jeho hodnotu, která co nejvíce vystihuje metodiku, a číselné hodnocení jednotlivých kritérií pro uvedené metodiky vývoje. Jednotlivé metodiky byly vzájemně porovnány na základě kritérií. Každá metodika byla číselně ohodnocena podle požadavků na projekt. Jednotlivá kritéria jsou ohodnocena podle hodnotící stupnice od 1 do 10. Minimální hodnota 1 znamená, že metodika nevyhovuje požadavkům na projekt. Maximální hodnota 10 znamená, že metodika nejlépe vyhovuje požadavkům na projekt. RUP - Rational Unified Process Kritérium Hodnota kritéria Hodnocení 1. Typ řešení spíše nové řešení (rozšíření zavedeného) 4 2. Přístup k řešení objektově-orientovaná ve všech fázích 7 3. Míra složitosti metodiky velmi náročná na složitost 8 4. Zaměření testování (typ testů) black box testy, funkční testování, definuje FURPS 5. Rozsah (a hloubka) testování průběžné testování v každé fázi (po každé iteraci během celého vývoje) Zaměření metodiky na fázi vývoje rovnoměrné rozložení fází 8 Tab.4.2. Hodnoty kritérií a jejich hodnocení metodiky RUP 41

42 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT XP Extrémní programování Kritérium Hodnota kritéria Hodnocení 1. Typ řešení rozšíření stávajícího, integrace zavedeného 6 2. Přístup k řešení strukturovaný, RAD 3 3. Míra složitosti metodiky jednoduchá metodika 3 4. Zaměření testování (typ testů) White box testování, unit testy, testy integrace, UAT (viz kapitola 5.2) 6 5. Rozsah (a hloubka) testování testování na konci vývoje před implementací 6 6. Zaměření metodiky na fázi vývoje Kódování (implementace) 6 Tab.4.3. Hodnoty kritérií a jejich hodnocení metodiky XP FDD Feature-Driven Development (vlastnostmi řízený vývoj) Kritérium Hodnota kritéria Hodnocení 1. Typ řešení nové řešení 4 2. Přístup k řešení objektově-orientovaná ve všech fázích 8 3. Míra složitosti metodiky střední náročnost 6 4. Zaměření testování (typ testů) nedefinováno 3 5. Rozsah (a hloubka) testování testování na konci vývoje v rámci fáze implementace 4 6. Zaměření metodiky na fázi vývoje Požadavky seznam vlastností 5 Tab.4.4. Hodnoty kritérií a jejich hodnocení metodiky FDD 42

43 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT TDD Test-Driven Development (testy řízený vývoj) Kritérium Hodnota kritéria Hodnocení 1. Typ řešení rozšíření stávajícího, integrace zavedeného 6 2. Přístup k řešení strukturovaný, RAD 3 3. Míra složitosti metodiky jednoduchá metodika 3 4. Zaměření testování (typ testů) white box testování, unit testy, testy integrace (viz kapitola 5.2) 5. Rozsah (a hloubka) testování na začátku vývoje v počáteční fázi před implementací Zaměření metodiky na fázi vývoje testování 9 Tab.4.5. Hodnoty kritérií a jejich hodnocení metodiky TDD 4.4 Analýza číselného hodnocení kritérií V následující kapitole byla provedena interpretace tabulkové části. Provedená analýza vyjadřuje porovnání metodik podle kritérií. Hlavním cílem je vysvětlení a zdůvodnění číselného vyjádření hodnot kritérií pro každou metodiku podle zadání projektu. Kritérium typ řešení Pro toto kritérium je nejvíce žádoucí metodika rozšiřující stávající systém o nové funkčnosti popř. o implementaci změnových požadavků již zavedených funkčností. Toto kritérium podle požadavků na projekt nejlépe splňují metodiky TDD a XP, proto byly číselně ohodnoceny jako lépe vyhovující pro realizaci projektu. Metodiky RUP a FDD byly spíše navrhnuty pro vývoj nového řešení informačního systému, nikoliv pro jeho změny či inovace. 43

44 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT Kritérium přístup k řešení V rámci definování požadavků na vývoj řešení softwarového produktu zadavatel požaduje objektově-orientovaný vývoj. Požadavkům pro toto kritérium nejvíce vyhovují metodiky RUP a FDD, které využívají právě objektově orientovaný vývoj. Zatímco metodika RUP využívá objektově orientovaný vývoj ve fázi analýzy a řízení požadavků, metodika FDD ve fázi tvorby modelu. Pro vizuální modelování objektů z reálného světa se využívá vysoká míra abstrakce a notace UML. Metodiky XP a TDD využívají strukturovaný vývoj, který je založený na volání procedur a funkcí. V rámci tohoto vývoje se uplatňuje technika pro úpravu kódu založená na odstranění duplicit a zavedení standardů pro čitelnost a strukturovanost zdrojového kódu. Pro tento vývoj je charakteristická znovupoužitelnost kódu. Metodiky XP a TDD jsou podle požadavků na projekt nevyhovující. Kritérium míra složitosti metodiky Přestože v případě metodiky XP činí ztráta části napsaného zdrojového kódu nebo přepracování návrhu architektury vývoj výrazně složitý, jedná se stejně jako v případě TDD o velmi jednoduchou metodiku. TDD není příliš zatížená procesy, ale je náročnější na znalosti a lidský faktor. Změny v návrhu dokončené vlastnosti, podle které je řízen vývoj metodiky FDD, má za následek opakování průběhu některých fází vývoje. Z hlediska návaznosti fází je pak FDD klasifikována jako středně pokročilá. Z hlediska hloubky a rozsahu je velmi náročná na složitost metodika RUP. Lze ji označit za nejpropracovanější a nejobsáhlejší z uvedených metodik. Složení a velikost týmu je totiž definována rolemi. Obsah metodiky RUP je uspořádán do disciplín. Pro efektivnější vývoj software se využívá šesti základních praktik vývoje. Metodika RUP je klasifikována jako nejsložitější a označena nejvyšší číselnou hodnotou. Pro zadání projektu je však žádoucí jednoduchá metodika. Z tohoto důvodu má optimalizační metoda TOPSIS toto kritérium nastaveno jako minimalizační. Kritérium zaměření testování Základní rozdíl je v přístupu k testování. Zatímco metodika RUP je založena na black box testování, metodiky TDD a XP provádějí white box testování. V rámci zajišťování kvality produktu metodiky TDD a XP provádějí testy jednotlivých modulů (unit testy), akceptační testy uživatelského rozhraní, testy integrity a funkcionality. Metodika RUP má nadefinovanou bohatou sadu testů FURPS vyjadřující jednotlivé 44

45 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT aspekty kvality: funkcionalitu, použitelnost, spolehlivost, výkon a podporovatelnost. Pro otestování každého aspektu kvality je k dispozici několik typů testů. Z uvedeného vyplývá, že metodika RUP je z hlediska rozsahu typů testů nejvhodnější pro otestování aplikace navrhované pro projekt. Kritérium rozsah testování Toto kritérium je zaměřeno na fázi vývoje, přesněji na okamžik, kdy se aplikace začíná testovat. Metodika RUP definuje průběžné testování nejen v každé fázi vývoje, ale i během každé iterace. Proces testování je tedy do jisté míry zastoupen v každé iteraci. Metodika TDD klade velký důraz na testování do takové míry, že ho pokládá za základ celého vývoje, nicméně se mu nevěnuje po celý jeho průběh, ale pouze na jeho začátku. Testování v rámci TDD probíhá na začátku vývoje před implementací, nejprve probíhá napsání testu a až poté napsání kódu. Metodika XP stanovuje testování na konec vývoje před fázi implementace. Nejdříve probíhá vytváření testů, následně samotné testování a až poté dochází k psaní zdrojového kódu. Metodika FDD stanovuje proces testování pouze v rámci fáze implementace a až na konci celého vývoje. Z tohoto důvodu je pro zadání projektu v porovnání s ostatními metodikami nejméně vyhovující. Hodnocení kvality softwarového produktu je primárně založeno na nedokončenosti, protože nelze vždy otestovat všechny aspekty software. Na testování klade zadavatel projektu velký důraz hlavně z hlediska funkčnosti produktu, proto je žádoucí, aby testování bylo zastoupené v každé fázi vývoje. Tento požadavek nejlépe splňuje metodika RUP. Kritérium zaměření metodiky na fázi vývoje Zatímco metodika RUP definuje rovnoměrné rozložení všech fází, ostatní porovnávané metodiky se vždy více zaměřují na jeden aspekt vývoje a vyzdvihují jednu fázi vývoje nad ostatní. Metodika FDD se zabývá procesem modelování a zpracování vlastností, podle kterých je řízen vývoj. Metodika XP staví tvorbu zdrojového kódu nad ostatní fáze při vývojovém procesu. Metodika TDD vyzdvihuje disciplínu testování nad ostatní kroky a považuje ji za základ vývoje software. Vzhledem k požadavkům na zadání tomuto kritériu nejlépe vyhovují metodiky RUP a TDD. 45

46 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT 4.5 Stanovení vah pro kritéria Pro jednotlivá kritéria 1 až 6 jsou stanoveny následující váhy (Tab.4.6). Kritéria popisující testování byla nastavena na vyšší číselnou hodnotu. Kritérium Váha 0,06 0,12 0,10 0,28 0,24 0,20 Tab.4.6. Stanovení vah pro kritéria Vyčíslení jednotlivých kritérií pro uvedené metodiky vývoje ukazuje tabulka (Tab.4.7). Kritérium míra složitosti je vymezeno jako minimalizační z důvodu zadání projektu. Kritérium max max min max max max RUP XP FDD TDD Tab.4.7. Kriteriální matice metody TOPSIS Na základě číselného ohodnocení jednotlivých kritérií a stanovených vah pro každé kritérium bude provedena optimalizační metoda TOPSIS. Podle výsledků metody TOPSIS bude rozhodnuto pro výběr jedné metodiky. Nejvhodnější metodika bude navržena pro realizaci softwaru. 46

47 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT 4.6 Výběr vhodné metodiky podle optimalizační metody Řešení problému pomocí metody TOPSIS [4, s ] Všechny výpočty optimalizační metody TOPSIS jsou uvedeny v příloze (viz kapitola 7.4). Teoretický postup řešení problému pomocí manažerské metody rozhodování TOPSIS je rozdělen do šesti kroků. 1. krok: Stanovení kriteriální matice Y=(y i j ) Nejprve upravíme kriteriální matici (Tab.7.1) na tvar, kdy všechna kritéria budou maximalizační. Pro minimalizační kritéria určíme nejhorší maximální hodnoty. Uděláme rozdíl mezi maximálními (nejhoršími) hodnotami a hodnotami kriteriální matice. Od maximální hodnoty každého minimalizačního kritéria odečteme hodnoty kritéria pro danou alternativu. 2. krok: Získaná upravená matice (Tab.7.2) Všechna kritéria jsou zde již maximalizační. Tabulka (Tab.7.3) ukazuje rovněž upravenou matici, která slouží jako mezivýpočet pro získání normalizované kriteriální matice. Obsahuje hodnoty předchozí upravené matice umocněné na druhou y 2 i j, dále jejich sumu (součet) y 2 i j a následně odmocninu y 2 i j. 3. krok: Vytvořená normalizovaná kriteriální matice R (Tab.7.4) R i j podle vztahu : R i j = y i j / y 2 i j 4. krok: Vytvořená vážená kriteriální matice W (Tab.7.5) Každý sloupec matice R se vynásobí odpovídající vahou ve formě řádkového vektoru vah. Kriteriální váhy byly stanoveny managementem firmy. v 1 r 11 v 2 r v 1 r 21 v 2 r W =.... Obr.4.1. Vážená kriteriální matice 47

48 4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT Vytvoříme řádkové vektory pro obě alternativy jak bazální D, tak ideální H. Řádkový vektor H obsahuje maximální hodnoty pro každé kritérium f1 až f6 vážené kriteriální matice W a analogicky vektor D obsahuje minimální hodnoty. 5. krok: Výpočet vzdáleností variant od ideální alternativy (Tab.7.6) a (Tab.7.7) Provede se výpočet podle vztahu pro všechna i: d i + = j (w i j - H j ) 2 d i - = j (w i j - D j ) 2 6. krok: Relativní ukazatel vzdálenosti (Tab.7.8) Vypočte se relativní ukazatel vzdálenosti alternativ od bazální alternativy podle vztahu pro všechna i, čili pro všechny alternativy. c i = d - + i / (d i + d - i ) Varianty se uspořádají podle klesajících hodnot c i. Jako nejlepší se vybere ta alternativa, která se umístila na prvním místě (má největší hodnotu c i ). 4.7 Návrh vhodné metodiky pro projekt Největší hodnotu relativního ukazatele vzdálenosti (Tab.7.9) má metodika RUP. Podle výsledků optimalizační metody TOPSIS vyplývá, že nejvhodnější metodikou pro řízení modelového softwarového projektu je metodika RUP. Výsledek porovnání metodik pomocí optimalizační metody TOPSIS výrazně závisí na volbě kritérií a stanovení vah pro jednotlivá kritéria. Porovnání metodik bylo zaměřené na problematiku testování, z toho důvodu byly přiděleny vyšší hodnoty vahám, které se nejvíce zabývají testováním. 48

49 5. TESTOVACÍ STRATEGIE 5. Testovací strategie Testovaní je nejdůležitější proces zajišťování kvality software. Proto je důležité tento proces organizovat, plánovat a řídit. Tento úkol se snaží vyřešit testovací strategie. Strategie testování stanovuje postup, podle kterého bude testovací tým provádět ověřování a kontrolu funkčnosti software. Popisuje časový plán testů, definuje sledování výsledků testování z hlediska chybovosti a rovněž vymezuje rizikové oblasti testování. Na základě výsledků optimalizační metody je testovací strategie určena metodice RUP. 5.1 Testovací cyklus Cyklus testování metodiky RUP je založen na iterativním vývoji. V následující tabulce (Tab.5.1) je stručně popsáno jaké činnosti probíhají a jaké dokumenty jsou vytvářeny v jednotlivých fázích testovacího cyklu. Fáze testovacího cyklu (kompetentní role) Plánování testů (Test manager) Návrh testů (Test architect) Vytváření testů (Test designer & tester ) Vykonávání testů (Tester) Vyhodnocení testů (Test manager) Sledování defektů Činnosti Definice testovacího rozsahu Plánování zdrojů a cílů testování Identifikace rizik Definice typů testů Příprava manuálních a automatizovaných testů Definice testovacích dat Zhodnocení testů Dokumenty Rozsah testů (Test scope) Testovací plán Testovací požadavky Strategie testů Definice prostředí Testovací případy Testovací scénáře Test report Testovací výsledky Seznamy chyb Závěrečné shrnutí Test protokol Defect report Tab.5.1. Fáze testovacího cyklu [10] 49

50 5. TESTOVACÍ STRATEGIE Z hlediska role mohou disciplínu testování provádět tester, test designer, test architect, a test manager. Následující obrázek (obr.5.1) ukazuje jaké aktivity má daná role vykonávat a za jaké dokumenty je jednotlivá role zodpovědná. Obr.5.1. Testovací cyklus [10] 50

51 5. TESTOVACÍ STRATEGIE Testovací cyklus představuje posloupnost činností, které na sebe navazují a do jisté míry se vzájemně překrývají a doplňují. Výstupy z jedné fáze představují přímé vstupy do následující fáze. Posloupnost jednotlivých kroků testování je vysvětlena pomocí životního cyklu testování. Pro každou fázi životního cyklu je uveden její popis pro přiblížení činností a postupů, které se v ní odehrávají. 1) Plánování testů V první fázi testovacího cyklu probíhá definice projektu, vymezuje se testovací plán, stanovují se testovací požadavky. Výsledkem je pak definování rozsahu testů, který specifikuje činnosti testování. Testovací plán popisuje proces dosažení cílů, soustředí se na rozsah a zaměření testů, zahrnuje časový rozvrh jednotlivých aktivit a termíny dodávek. Testovací požadavky přibližují chování testované aplikace a potřebné testovací zdroje. Testovací požadavky popisují návrh uživatelského rozhraní, průběh konfigurace a instalace, specifikují potřebný výkon aplikace, hraniční podmínky, neboli objem testování. [7, s ; 10] 2) Návrh testů Ve fázi návrhu dochází k upřesnění cílů a milníků testování, je nadefinováno testovací prostředí. Výsledkem návrhu je strategie testů, která upřesňuje sadu požadavků na chování a přesně stanovuje jaké typy testů budou prováděny. V rámci strategie testů se rovněž stanovují testovací techniky, nástroje a kritéria pro dokončení testů. Konečná verze strategie testů musí být následně schválena zákazníkem. [7, s ; 10] 3) Vytváření testů [7, s ; 10] V této etapě testovacího cyklu je proveden detailní popis jednotlivých testovacích případů a skriptů, je definována struktura testovacích dat. Výsledkem jsou testovací scénáře, podle kterých probíhá testování. S popisy testovacích scénářů je průběžně seznamován zákazník. V případě, že testovací plán zahrnuje použití automatizovaných testů, pak jsou v této fázi připravovány procedury a skripty pro automatizované provádění testů. Fáze návrh testů a vytváření testů lze pojmenovat jednotně jako příprava testů. 51

52 5. TESTOVACÍ STRATEGIE Testovací případ (test case) je seznam kroků vycházející z konkrétních funkčností, které se musí vykonat. Testovací data jsou konkrétní data potřebná pro provádění testů. (např. uživatelské účty, data pro zadávání do systému, připravené xml zprávy atd.) Testovací skript (test script) Testovací script se skládá z konkrétních testovacích případů, testovacích dat a jasně definovaného očekávaného výsledku testování. Testovací scénář (Test suit) je komplexní test napříč systémem. Obsahuje sadu testovacích skriptů, které jsou definované v přesném pořadí. Testovací scénář ověřuje průchod systémem. Obr.5.2. Testovací scénář 4) Vykonávání testů Během etapy vykonávání testů jsou prováděny testy podle předem připravených testovacích scénářů, testy jsou vykonávány průběžně v každé iteraci. Výsledky testů jsou zaznamenávány ve formě dokumentů - defekt report a záznam o provedení testů. [7, s ; 10] 5) Vyhodnocení testů Během vyhodnocování testů dochází k analýze výsledků testů a určení, zda byly splněny testovací požadavky a kritéria definovaná během plánování. Každé vykonání testů je vyhodnocováno, jsou popsány nalezené defekty ve formě hlášení problému. Na konci testů se provádí závěrečné shrnutí. Závěrečná zpráva o výsledcích testování obsahuje stručné zhodnocení testů a vyhodnocení výsledků testování. Za vyhodnocení testů je odpovědný test manager. Výstupem je testovací protokol, který přesně popisuje průběh testů, seznam otestovaných funkčností, výsledky testů doplňuje o seznam nalezených chyb. [7, s ; 10] 52