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

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

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

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

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.

Obsah 1. Úvod..........................................................................................................................9 1.1 Cíl práce............................................................................................................9 1.2 Klíčová slova ....................................................................................................9 1.3 Hypotéza...........................................................................................................9 1.4 Metodologie práce ..........................................................................................10 1.5 Zdůvodnění výběru tématu práce ...................................................................10 1.6 Představení společnosti UNICORN ...............................................................11 2. Rizika spojená s návrhem a realizací software ..................................................12 2.1 Problémy při vývoji software .........................................................................12 2.2 Základní příčiny problémů .............................................................................14 2.3 Příčiny výskytu chyb ......................................................................................15 2.4 Eliminace problémů vývoje software .............................................................17 3. Porovnání metodik vývoje software ....................................................................18 3.1 Agilní a rigorózní metodiky ...........................................................................18 3.1.1 Charakteristika směrů vývoje software...............................................18 3.1.2 Tabulka porovnání rigorózních a agilních metodik............................19 3.1.3 Porovnání a rozdíly směrů vývoje software .......................................21 3.1.4 Manifest agilního vývoje software .....................................................21 3.2 Výběr metodik pro porovnání.........................................................................22 3.2.1 Metodika RUP – zástupce rigorózního vývoje ...................................22 3.2.2 Výběr agilních metodik ......................................................................23 3.3 Základní popis zvolených metodik.................................................................25 3.3.1 Metodika Rational Unified Process ....................................................25 3.3.2 Extrémní programování (XP) .............................................................28 3.3.3 Feature Driven Development (FDD) ..................................................31 3.3.4 Test Driven Development...................................................................33 4. Výběr vhodné metodiky pro projekt...................................................................36 4.1 Charakteristika projektu .................................................................................36 4.1.1 Formulace problému ...........................................................................36 4.1.2 Vymezení problému............................................................................37 4.2 Stanovení kritérií pro porovnání.....................................................................38 4.2.1 Kritéria klasifikace metodik ...............................................................38

5

4.2.2 Popis kritérií pro porovnání metodik ..................................................39 4.3 Metodiky podle stanovených kritérií..............................................................41 4.4 Analýza číselného hodnocení kritérií .............................................................43 4.5 Stanovení vah pro kritéria...............................................................................46 4.6 Výběr vhodné metodiky podle optimalizační metody....................................47 4.6.1 Řešení problému pomocí metody TOPSIS.........................................47 4.7 Návrh vhodné metodiky pro projekt...............................................................48 5. Testovací strategie.................................................................................................49 5.1 Testovací cyklus .............................................................................................49 5.2 Kategorizace testů podle metodiky RUP........................................................53 5.2.1 Klasifikace testů podle viditelnosti kódu............................................53 5.2.2 Klasifikace testů podle dimenze času .................................................54 5.2.3 Klasifikace testů podle dimenze typů testů ........................................55 5.3 Návrh testovací strategie ................................................................................56 6. Závěr ......................................................................................................................60 6.1 Zhodnocení dosažení cílů ...............................................................................60 6.1.1 Vyhodnocení cílů................................................................................60 6.1.2 Vyhodnocení hypotézy práce..............................................................60 6.2 Závěrečné shrnutí práce..................................................................................60 6.2.1 Vyhodnocení porovnání metodik software.........................................60 6.2.2 Vyhodnocení návrhu testovací strategie .............................................62 7. Seznamy a přílohy .................................................................................................63 7.1 Seznam použité literatury ...............................................................................63 7.2 Seznam obrázků..............................................................................................65 7.3 Seznam tabulek...............................................................................................65 7.4 Přílohy ............................................................................................................66

6

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

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

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

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

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

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


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. 15-18] 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. 15-18] 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

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. 15-18] 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. 15-18 ; 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. 18 – 22 ; 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

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. 18 - 22] 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. 18 - 22]

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. 129 - 135] Mezi nejčastější příčiny, které způsobují velké množství chyb a následné selhání projektu patří : [6, s. 129 - 135] •

Š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

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. 129 - 135] 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. 129 - 135] 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. 129 - 135]

16


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. 12 – 13 ; 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

3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE

3. Porovnání metodik vývoje software 3.1 Agilní a rigorózní metodiky 3.1.1

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

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. 111 - 118 ; 2, s. 43 - 62] 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. 111 - 123] 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

3.1.2

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


Rigorózní metodiky

Agilní metodiky

1. Proces

Přesně a podrobně definovaný

Empirický proces, není možné ho

vývoje

proces, lze ho opakovat.

opakovat, ale vyžaduje adaptaci.

2. Změny a

Minimalizace změn (sběr požadavků

Akceptace změn (přírůstkové

požadavky

předem a plánování předem), změny

shromažďování požadavků,

jsou součástí řízení změn.

plánování pro iteraci) přehodnocení

software

požadavků, snaha o umožnění změn (v závislosti na nových znalostech). 3. Zapojení

Bez zásahu. Nedůvěra v zákazníka -

Participace a spolupráce -

zákazníka na

Po podpisu smlouvy a vymezení

Zákazník se aktivně zapojuje do

řízení projektu

dokumentu specifikace požadavků

celého projektu, může měnit priority

v počáteční fázi, zákazníka zajímá až

funkcí při každé iteraci.

konečné řešení. 4. Kvalita

Více zaměřeny na kvalitu vlastních

Zaměření na priority zákazníka, na

procesů, než na výsledek pro

užitnou hodnotu pro zákazníka, tedy

zákazníka.

na výslednou kvalitu produktu.

5. Způsob a

Podrobný popis procesů a činností,

Eliminace nepotřebných činností,

rozsah řešení

složité řešení.

jednoduché řešení.

Při vývoji obsaženy všechny funkce,

Při vývoji zahrnuty jen potřebné

snaha o zabudování budoucích

funkce, snaha o minimalizaci, žádné

požadavků.

začlenění budoucích požadavků.

6. Rozložení

Každý člen týmu má přiřazeny

Sdílení znalostí v týmu, spolupráce

teamového

činnosti, v rámci role, kterou zastává.

(kooperace) a aktivní komunikace

know-how

Požadavek na specializaci

v rámci týmu, společné řešení

zaměstnanců. Převládá písemná

problémů, řízení a integrace

forma komunikace (dokumentace).

znalostních toků.

7. Lidský faktor Pohled na lidi jako na sekundární

Lidé jako primární a klíčový faktor

faktor, procesy doplňovány rozsáhlou

úspěchu projektu. Využití schopností

dokumentací. Jedinci jsou

a dovedností jedinců (individualit),

nahraditelní.

důraz na znalosti, kvalifikaci.

8. Způsob

Vodopádový životní cyklus, iterativní

Přírůstkový (inkrementální) vývoj

vývoje

s dlouhými iteracemi.

s velmi krátkými iteracemi.

Tab.3.1. – Porovnání agilních a rigorózních metodik [2, s. 62 - 64 ; 7] 20

3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE 3.1.3

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. 119 - 120]

3.1.4

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

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. 43 - 44 ; 5, s. 120 - 123] 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. 43 - 44 ; 5, s. 120 - 123]

3.2 Výběr metodik pro porovnání 3.2.1

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. 105 - 110]

22

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. 55 - 77 ; 7, s. 29 - 32]

3.2.2

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

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. 43 - 62]

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


3.3 Základní popis zvolených metodik 3.3.1

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. 79 – 88 ; 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


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. 36 - 38] 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. 88 – 92 ; 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. 88 – 92 ; 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

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. 88 – 92 ; 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. 88 – 92 ; 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. 36 - 38 ; 3, s. 182 - 183]

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


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. 93 - 94]

3.3.2

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 1999. 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. 125 - 131 ; 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

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. 125 - 131 ; 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. 132 - 135] 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. 132 - 135] 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. 132 - 135]

Ž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

[5, s. 135 - 145]

29

komunikaci

nad

zdrojovým

textem.

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. 135 - 145]

Základní činnosti XP:

Specifikace činnosti

Plánování

šíř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í

párové programování, společné vlastnictví kódu, integrace změn

(psaní zdrojového kódu)

kódu, tvorba kódu pro unit testy, tvorba zdrojového kódu, standardy kódu

Testování

unit testy, akceptační testy

Tab.3.2. – Základní činnosti XP

30

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. 135 - 145] 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. 135 - 145]

3.3.3

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. 177 - 182] 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. 177 - 182]

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. 182 - 195] 1. vytvoření celkového modelu 2. vytvoření seznamu vlastností 3. plánování 4. návrh 5. implementace 31


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. 182 - 191] 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. 182 - 191] 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

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. 182 - 191] 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. 182 - 191]

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. 191 - 195]

3.3.4

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. 197 - 198] 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. 197 - 198] 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

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. 197 - 198] 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. 210 - 211] 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. 202 - 203]

34

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. 202 - 203] „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

4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT

4. Výběr vhodné metodiky pro projekt 4.1 Charakteristika projektu 4.1.1

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

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).

4.1.2

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


4.2 Stanovení kritérií pro porovnání 4.2.1

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. 23 - 24 ; 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. 24 - 26]

38

4. VÝBĚR VHODNÉ METODIKY PRO PROJEKT 4.2.2

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. 23 - 24]

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

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

a) velmi náročná na složitost b) složitá metodika

(propracovanost, obsáhlost)

b) střední náročnost c) jednoduchá metodika [2, s. 23 - 24]

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

a) vyzdvihuje (klade důraz na) jednotlivou fázi : požadavky,

vývoje

návrh, implementace, testování atd. b) rovnoměrné rozložení fází

Tab.4.1. – Seznam kritérií a jejich hodnot

40


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í

4

zavedeného) 2. Přístup k řešení

objektově-orientovaná ve všech fázích

7


velmi náročná na složitost

8


black box testy, funkční testování,

9

definuje FURPS 5. Rozsah (a hloubka) testování

průběžné testování v každé fázi (po

8

každé iteraci během celého vývoje) 6. Zaměření metodiky na fázi

rovnoměrné rozložení fází

8

vývoje

Tab.4.2. – Hodnoty kritérií a jejich hodnocení metodiky RUP

41


XP – Extrémní programování Kritérium

Hodnota kritéria

Hodnocení

1. Typ řešení

rozšíření stávajícího, integrace

6

zavedeného 2. Přístup k řešení

strukturovaný, RAD

3


jednoduchá metodika

3

4. Zaměření testování (typ

White box testování, unit testy, testy

6

testů)

integrace, UAT (viz kapitola 5.2)


testování na konci vývoje před

6

implementací 6. Zaměření metodiky na fázi

Kódování (implementace)

6

vývoje

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


střední náročnost

6


nedefinováno

3


testování na konci vývoje v rámci fáze

4

implementace 6. Zaměření metodiky na fázi

Požadavky – seznam vlastností

5

vývoje

Tab.4.4. – Hodnoty kritérií a jejich hodnocení metodiky FDD

42


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

6

zavedeného 2. Přístup k řešení

strukturovaný, RAD

3


jednoduchá metodika

3


white box testování, unit testy, testy

7

integrace (viz kapitola 5.2) 5. Rozsah (a hloubka) testování

na začátku vývoje v počáteční fázi před

7

implementací 6. Zaměření metodiky na fázi

testování

9

vývoje

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

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

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


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

1

2

3

4

5

6

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

1

2

3

4

5

6

max

max

min

max

max

max

RUP

4

7

8

9

8

8

XP

6

3

3

6

6

6

FDD

4

8

6

3

4

5

TDD

6

3

3

7

7

9

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


4.6 Výběr vhodné metodiky podle optimalizační metody 4.6.1

Řešení problému pomocí metody TOPSIS [4, s. 92 - 96]

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 y2 2

odmocninu √ ∑ y

ij

i j

, dále jejich sumu (součet) ∑ y2

i j

a následně

.

3. krok: Vytvořená normalizovaná kriteriální matice R (Tab.7.4) R i j podle vztahu : R i j = y i j / √ ∑ y2 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.

W=

v1 r11 v1 r21 . .

v2 r12 v2 r22 . .

... ...

Obr.4.1. – Vážená kriteriální matice

47

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

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

Dokumenty

Činnosti (kompetentní role) Plánování testů

Definice testovacího rozsahu

Rozsah testů (Test scope)

(Test manager)

Plánování zdrojů a cílů

Testovací plán

testování

Testovací požadavky

Identifikace rizik Návrh testů

Definice typů testů

(Test architect)

Strategie testů Definice prostředí

Vytváření testů

Příprava manuálních a

Testovací případy

(Test designer & tester )

automatizovaných testů

Testovací scénáře

Definice testovacích dat Vykonávání testů

Test report

(Tester)

Testovací výsledky Seznamy chyb

Vyhodnocení testů

Zhodnocení testů

Závěrečné shrnutí

(Test manager)

Test protokol

Sledování defektů

Defect report

Tab.5.1. – Fáze testovacího cyklu [10] 49

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

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. 211 – 234 ; 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. 211 – 234 ; 10]

3) Vytváření testů [7, s. 211 – 234 ; 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

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. 211 – 234 ; 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. 211 – 234 ; 10]

52

5. TESTOVACÍ STRATEGIE 6) Sledování defektů Na závěr testovacího cyklu probíhá proces sledování defektů, kde se jednotlivé defekty a uživatelské problémy zaznamenávají a označují za otevřené defekty, což umožní jejich vyřešení. Pro sledování nalezených defektů jsou vytvořeny procedury a nástroje, které slouží pro jejich záznam a pro průběžné sledování způsobu a stavu jejich řešení. Každý záznam defektu je sledován až do jeho rozřešení. [7, s. 211 – 234 ; 10]

5.2 Kategorizace testů podle metodiky RUP V rámci návrhu testovací strategie je podstatné stanovit, nejen jaké fáze bude proces testování zahrnovat, ale i jaké typy testů se při ověřování funkčnosti software využijí. Cílem je otestovat aplikaci takovým způsobem, aby byla co nejvíce pokryta jednotlivými testy. Jejich zastoupení při testování záleží na druhu testované funkčnosti. Obecně lze ale říci, že čím větší zastoupení jednotlivých typů testů při ověřování funkčnosti software, tím lepší výsledky se při testování dosáhnou. Čím více bude aplikace pokryta testy, tím existuje větší pravděpodobnost, že se při testování odhalí větší počet chyb. Proto je v práci navrhnuta kategorizace testů, nejprve podle obecně známých jmenovatelů tzn. podle viditelnosti kódu a dimenze času. U klasifikace podle dimenze typu testů jsou každému rozměru kvality podle metodiky RUP přiděleny jednotlivé typy testů. Rozdělení do skupin podle rozměrů kvality, tak jak je definuje RUP, se může vzájemně překrývat, jinými slovy, některé testy je možné zařadit i do jiné skupiny. V následující podkapitole je uveden popis jednotlivých testů. [10]

5.2.1

Klasifikace testů podle viditelnosti kódu

Základní rozdělení testů charakterizuje dva přístupy testování. Při black-box testing (testování černé skříňky) nás zajímá systém jako celek, v závislosti na vstupu řídíme výstup. Nezajímá nás kód, ani iterace, které se odehrávají uvnitř systému. Při white-box testing (testování bílé skříňky) nás zajímají iterace a procesy uvnitř systému. Tester má přístup ke zdrojovému kódu. Někdy se toto rozdělení označuje jako klasifikace podle viditelnosti kódu. [7, s. 47 - 50]

53

5. TESTOVACÍ STRATEGIE 5.2.2

Klasifikace testů podle dimenze času [9 ; 10]

Během vývoje software je nutné neustále ověřovat, zda nedochází k odchylce od zadání. Testování je do jisté míry zastoupeno v každé fázi životního cyklu metodiky RUP. Proces testování při vývoji software je rozdělen mezi vývojový a testovací tým. Rozdělení testů podle dimenze času na fáze testů, není jen záležitostí metodiky RUP, ale platí obecně i pro ostatní metodiky. Z časového hlediska lze testy rozdělit do jednotlivých fází. Jednotlivé testy probíhají v určitém pořadí a navazují na sebe. •

Unit testy (testy nových funkčností) jsou prováděny na straně vývojového týmu. Po dokončení unity (UC - use casu) se testuje kontrola kódu a požadovaná funkčnost příslušného UC.

•

Integrační testy (Build testy) ověřují, zda-li lze integrovat unity dodané vývojovým týmem, tj. vytvořit funkční build.

•

Smoke testy ověřují stabilitu systému. Slouží pro zajištění proveditelnosti následného hloubkového systémového testu. Testy jsou aplikovány na nejčastěji využívaných nebo nejkritičtějších funkčností systému.

•

Systémové testy (SIT) zahrnují hloubkový test systému, při kterém se zpravidla vykonávají téměř všechny typy testů: testy funkcionality a integrace (komunikace s okolními systémy) nebo kontroly přenášených dat.

•

Uživatelské akceptační testy (UAT) jsou zaměřeny na testování standardního provozu systému. Zaměřují se na ověřování funkčností z pohledu chování konkrétní role v systému a na otestování podpory procesů a pracovních postupů rolí. Testy provádí koncoví uživatelé.

Velmi důležitou vlastností systémových testů jsou zpětné regresní testy. Regresní testy

ověřují

kromě

nově

přidaných

funkčností

také

všechny

funkčnosti

implementované v předchozích iteracích. Regresní testy tedy ověřují funkčnosti, které se nezměnily.

54

5. TESTOVACÍ STRATEGIE 5.2.3

Klasifikace testů podle dimenze typů testů [9 ; 10]

Základní dělení typů testů výhradně podle metodiky RUP odpovídá základním rozměrům kvality FURPS: •

Functionality (Funkcionalita)

•

Useability (Použitelnost)

•

Reliability (Spolehlivost)

•

Performance (Výkon)

•

Supportability (Podporovatelnost)

Každý uvedený aspekt kvality podle metodiky RUP lze rozdělit na další podskupiny testů.

1) Testy funkcionality •

Funkční testy: Testy zaměřené na zajištění funkčních požadavků. Testy ověřují, zda-li jsou poskytovány funkčnosti uvedené v návrhu systému.

•

Security testy: Testy zaměřené na ověřování přístupových práv pro zajištění dostupnosti dat.

•

Volume testy: Testy ověřují schopnost práce databáze s velkým objemem dat. Testy stability a zachování všech funkčností systému při zvýšeném provozu databáze.

2) Testy použitelnosti •

Testy uživatelského rozhraní, testy dokumentace, testy on-line nápovědy atd.

3) Testy spolehlivosti •

Integritní testy (testy integrity systému): Testy zaměřené na hodnocení robustnosti sytému (odolnosti proti selhání) po datové i funkční stránce.

•

Strukturní testy: Testy

zaměřené na hodnocení správnosti systému

vzhledem k návrhu. Testy jsou často prováděny u webových rozhraní. •

Stresové testování: Jedná se o provozování software při nestandardních podmínkách například s menším množstvím paměti, s malým diskovým prostorem nebo s pomalým procesorem. Při tomto druhu testu se omezuje provoz na úplné minimum. [7; s. 74 - 75]

55

5. TESTOVACÍ STRATEGIE 4) Testy výkonnosti •

Výkonnostní testy: Testy jsou založeny na vyhledávání výkonnostně slabých míst systému.

•

Contention testy: Testy současného přístupu více uživatelů k sdíleným prostředkům při zachování funkčnosti systému. Kromě současného připojení více uživatelů se využívá praktika posílání velkého množství požadavků.

•

Zátěžové testy: Tyto testy sledují stav, chování a výkon systému pod vysokou zátěží. Aplikaci dopřejeme maximální podmínky pro provoz tak, aby software pracoval s největšími datovými soubory a s velkým počtem periferií (tiskárny a komunikační porty). Zátěžové testování je opak stresového testování. [7; s. 74 - 75]

5) Testy podporovatelnosti •

Konfigurační

testy:

Testy

ověřují

funkčnost

systému

na

jiných

konfiguracích, než jaké jsou nastavené v testovacím prostředí. •

Instalační testy: Testy ověřují stav instalace na různých konfiguracích software popř. hardware. Testuje se kompletnost a aktualizace instalace.

Žádné z těchto skupin klasifikace testů neodpovídají statické a dynamické testy hlavně z důvodu, že se nejedná o typ testu, ale o způsob provedení testu.

5.3 Návrh testovací strategie Porovnání a výběr metodik vývoje software podle zadání projektu dopadlo úspěšně pro metodiku RUP. Proto je navrhnutá testovací strategie v souladu s principy metodiky RUP. Nejedná se o návrh univerzální testovací strategie, kterou může využít jakákoliv metodika, jedná se o vytvoření strategie testů podle metodiky RUP, nicméně lze říci, že některé body návrhu jsou použitelné i pro ostatní metodiky (TDD, FDD a XP). Rozhodující je ověřit funkčnost aplikace podle všech aspektů kvality. Právě otestovat software podle všech aspektů kvality, neboli pokrytí systému testy, je základním cílem procesu testování. Veškeré úsilí práce testera směřuje k odhalení chyby ve funkčnosti aplikace. Návrh testovací strategie je rozdělen do devíti bodů. Pro splnění vymezených cílů by měli v dostatečné míře proběhnout všechny tyto činnosti.

56

5. TESTOVACÍ STRATEGIE Testovací strategie metodiky RUP

1. Postup testování podle životního cyklu Při testování je nutné se řídit podle posloupnosti kroků životního cyklu testování (obr.5.1) tak, aby výstup jedné fáze životního cyklu znamenal vstup do následující fáze.

2. Návaznost typů testů podle fáze testů Posloupnost jednotlivých testů by měla kopírovat strukturu fáze testů (viz kapitola 5.2.2). V rámci funkčního testování budou probíhat i některé další typy testů - FURPS, které definuje metodika RUP a které jsou nutné pro otestování aplikace tak, aby aplikace mohla být použitelná pro svůj účel.

3. Testování zastoupené v každé iteraci Testování by mělo probíhat v menším nebo větším zastoupení během každé iterace. Testování by mělo probíhat v několika kolech, a to z důvodu otestování klíčových funkčností systému, každá iterace bude samostatně vyhodnocena a reportována. Výsledky testování se musí zaznamenat a zdokumentovat do testovacího protokolu.

4. Testovací techniky Použitím testovacích technik lze dosáhnout rychlejšího odhalení chyby. Využívají se techniky ekvivalenční analýzy, průzkumné testování nebo testování podle scénářů. Provádění testů by mělo probíhat podle připravených testovacích případů a scénářů pro každou iteraci.

5. Zpětné regresní testování Každá úprava zdrojového kódu, každá změna funkčnosti musí být řádně otestována. Po nasazení nové verze systému se musí provádět regresní testy. Některé chyby se několikrát opakují, proto se zamýšlené testy mohou provádět nikoliv jen jednou, ale opakovaně, vícekrát.

57

5. TESTOVACÍ STRATEGIE 6. Kombinace manuálního a automatického testování Ověřování správnosti funkcí složitého systému je časově náročné a představuje velmi mnoho práce. Pro zvýšení efektivity práce existuje řešení. Při testování lze uplatnit automatizované nástroje, které otestují testovací scénáře. Nicméně spoléhat pouze na automatizaci není dostačující, protože lidská intuice není lehce nahraditelná. Ideální řešení je kombinace klasického ručního testování a automatického, přičemž pro automatizaci je nezbytný pečlivý výběr testovacích případů. I když automatizované testy proběhnou bez nalezené chyby, to ještě neznamená, že otestovaný software je bezchybný. Nicméně kombinace manuálního (ručního) testování společně s nástroji pro automatizaci testů snižuje pravděpodobnost neodhalených chyb v softwaru. [7, s. 185 - 186]

7. Hlášení chyby Nalezené chyby je nutné popsat a zaznamenat ve formě hlášení o chybě (defect reportu). U každé chyby je potřeba přesně popsat všechny položky defect reportu tak, aby se vyloučilo případné nedorozumění s vývojářem. Hlášení chyby zahrnuje unikátní identifikátor a stav chyby, stručný popis chyby, verze systému, ve které byla chyba nalezena, kdo ji zaevidoval, komu je přidělena k opravě, komentáře k chybě a přílohy. Chyba musí být nejprve přesně, jasně a výstižně popsána, přičemž její popis se musí opírat o fakta a vyhovovat terminologii prostředí.

8. Stanovení priority a severity chyby Stanovení priority a severity chyby výrazně napomáhá k efektivitě jejího řešení, tedy k opravě funkčnosti. Každá chyba musí mít nastavenu závažnost (severitu). Pro označení závažnosti chyby se používá stupnice A-C, případně ještě stupeň Z, který značí změnové požadavky. Chyba označená severitou A, značí největší závažnost, chyba je kritická, zatímco chyba se stupněm severity C má nejnižší závažnost. Priorita určuje důležitost, které chyby je potřeba opravit jako první a které je možné odložit. [7; s. 241 - 242]

58

5. TESTOVACÍ STRATEGIE 9. Oprava chyby podle životního cyklu chyby Po nalezení chyby se musí provést její oprava. Náprava chyby už není záležitostí testování, nicméně po nápravě chyby následuje re-test. Chyba se po svém odhalení může nacházet v několika stavech. Životní cyklus chyby sleduje stav chyb od jejich nalezení po jejich vyřešení. Životní cyklus chyby tedy představuje posloupnost několika stavů chyby: nová (new), přijatá (assigned), opravená (resolved), upevněná (fixed), otestovaná (verified), znovu otevřená (reopened), uzavřená (closed). [7; s. 242 - 245]

Obr.5.3. – Životní cyklus chyby [10]

59

6. ZÁVĚR

6. Závěr 6.1 Zhodnocení dosažení cílů 6.1.1

Vyhodnocení cílů

V této bakalářské práci jsem porovnal metodiky pro vývoj software. Na základě tohoto porovnání zaměřeného na problematiku testování a definice požadavků na projekt jsem zvolil vhodnou metodiku pro vývoj software. Pro vybranou metodiku jsem navrhl testovací strategii.

6.1.2

Vyhodnocení hypotézy práce

Jak jsem již v úvodu práce uvedl, základní hypotézou bakalářské práce bylo tvrzení, že pro řízení softwarového projektu 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 zvolena metodika Rational Unified Process (RUP). V této fázi práce mohu vyhodnotit tento předpoklad a prohlásit, že tato hypotéza byla potvrzena. Použitím metodiky RUP lze tedy pro zamýšlený projekt dosáhnout efektivnějšího využití vývojového procesu, než-li by tomu bylo v případě použití metodiky Extrémního programování (XP), Test Driven Development (TDD) nebo Feature Driven Development (FDD).

6.2 Závěrečné shrnutí práce 6.2.1

Vyhodnocení porovnání metodik software

V úvodu práce jsem vyjmenoval základní problémy spojené s návrhem a realizací software, naznačil jsem jejich pravděpodobné příčiny. Myslím si, že eliminace uvedených problémů a jejich příčin by měla vést k efektivnějšímu vývoji software. Při porovnání rigorózních a agilních metodik jsem se snažil zaměřit na hlavní odlišnosti a rozdíly směrů vývoje. Jako zástupce z řad agilního vývoje jsem do závěrečné fáze porovnání s metodikou RUP zařadil metodiky TDD, XP a FDD. Důvodem mého rozhodnutí bylo především jejich zaměření na problematiku testování. Při výběru jsem

60

6. ZÁVĚR rovněž zohlednil metodiky, které nejvíce odpovídají zadání projektu, a také dostatečně popsané metodiky. Z výsledků optimalizační metody TOPSIS vyplývá, že vhodnou metodikou vývoje software pro řízení modelového projektu je metodika RUP. V následujících řádcích uvádím důvody, proč se metodika RUP pravděpodobně stala nejvhodnější variantou a připojuji zdůvodnění výběru metodiky RUP pro projekt. Metodika RUP nevyzdvihuje pouze jednu fázi vývoje, ale zaměřuje se na rovnoměrné rozložení všech fází. Definuje průběžné testování během celého vývoje. V každé iteraci je disciplína testování do jisté míry zastoupena. To je velkou výhodou oproti ostatním agilním metodikám, které mají nadefinovaný rozsah testů pouze v určité části vývoje. U všech porovnávaných agilních metodik vidím jeden společný jmenovatel. Největší důraz je vždy kladen pouze na jednu činnost. Přesněji řečeno porovnávané agilní metodiky nemají jednotlivé činnosti během vývojového cyklu rovnoměrně zastoupené tak jako metodika RUP, která se jednotlivým aktivitám věnuje stejnoměrně. Agilní metodiky XP, TDD, FDD se více zaměřují na jeden aspekt vývoje. Právě zaměření na jeden aspekt procesu vývoje „na úkor dalších“ je asi jedním z největších nedostatků, na který jsem při porovnávání přišel. Metodika TDD staví proces testování nad ostatní kroky při vývoji a označila ho za základ celého vývojového procesu. Extrémní programování se nejvíce věnuje kódování. Metodika FDD klade silný důraz na disciplínu modelování. Výhodou metodiky RUP je dokumentace vývojového procesu, což je důležité pro případné rozšíření systému. Další přednost metodiky RUP oproti ostatním shledávám hlavně v bohatém rozsahu sady testů. Metodika RUP má definované aspekty kvality FURPS. Žádná z porovnávaných metodik nemá tak bohatou sadu testů jako právě metodika RUP. Na závěr bych chtěl doplnit, že výsledek porovnání metodik byl výrazně ovlivněn stanovením vah a kritérií porovnání a také zadáním požadavků na projekt. Nezodpovězenou otázkou tak zůstává, do jaké míry ovlivní formulace požadavků volbu metodiky pro daný projekt.

61

6. ZÁVĚR 6.2.2

Vyhodnocení návrhu testovací strategie

Cílem testovací strategie, kterou jsem navrhl, je pokrytí systému testy. Cílem samotného testování pak musí být vysoká úspěšnost provedených testů, velký počet nalezených chyb a také minimum neprovedených testů. Za hlavní úkol testovací strategie považuji definici rozsahu testů, tedy omezení obrovské množiny možných testů na efektivní množství tak, aby se počet nenalezených chyb snížil na minimum. Testovací strategie by měla pokrývat optimální množství testů, které přispěje k efektivitě procesu testování. Proto jsem do návrhu zahrnul kategorizaci testů. Pokud se v rámci testování využijí různé druhy testů zvyšuje se pravděpodobnost nalezení většího množství chyb. Cílem je, aby aplikace dosáhla určitého stupně dokonalosti, nebo-li zajištění kvality. Do návrhu testovací strategie jsem rovněž zařadil testovací cyklus. Myslím si, že pro efektivní proces testování je nutné, aby byla při testování dodržena posloupnost jednotlivých fází. Důležité je, aby každá fáze testovacího cyklu byla do jisté míry zastoupena. Právě testovací cyklus může být aplikovatelný i pro ostatní agilní porovnávané metodiky. Do návrhu testovací strategie jsem rovněž zařadil následující podstatné kroky a pravidla: kombinaci automatického a manuálního testování, zpětné regresní testování a testování podle scénářů. V rámci návrhu testovací strategie uvádím následující myšlenky, které jsem zjistil při zpracování tématu. Za klíčové v procesu testování považuji nalezení velkého počtu chyb v aplikaci. Zároveň shledávám jako podstatný fakt okamžik nalezení chyby. Chyby odhalené v pozdních fázích jsou riskantní a ohrožují úspěšnost projektu. Domnívám se, že žádný program nelze otestovat komplexně. Vždy se najdou některé oblasti software, které zůstanou neotestovány. Není možné, že výsledný produkt bude dokonalý, protože nelze otestovat každý aspekt software a nalézt všechny chyby. Cílem zůstává, aby procentuální úspěšnost pokrytí systému testy byla co největší. Jsem přesvědčený, že testovací strategie pro metodiku RUP, kterou jsem v této práci vypracoval, by měla přispět k naplnění cílů celého procesu testování. Při návrhu testovací strategie jsem se zaměřil především na klíčové otázky problematiky testování, které jsem získal v rámci dosavadních pracovních zkušeností v oboru.

62

7. SEZNAMY A PŘÍLOHY

7. Seznamy a přílohy 7.1 Seznam použité literatury [1] ARLOW, Jim, NEUSTADT, Ila. UML 2 a unifikovaný proces vývoje aplikací : Objektově orientovaná analýza a návrh prakticky. Brno : Computer Press, 2007. 568 s. ISBN 978-80-251-1503-9.

[2] BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. Praha : Grada Publishing, 2004. 164 s. ISBN 80-247-1075-7.

[3] BUCHALCEVOVÁ, Alena, STANOVSKÁ, Iva, ŠIMŮNEK, Milan. Základy softwarového inženýrství : základní témata. 1. vyd. Praha : Oeconomica, 2002. 198 s. ISBN 80-245-0346-8.

[4] FIALA, Petr. Modely a metody rozhodování. 2. přeprac. vyd. Praha : Oeconomica, 2008. 292 s. ISBN 978-80-245-1345-4.

[5] KADLEC, Václav. Agilní programování : Metodiky efektivního vývoje softwaru. Brno : Computer Press, 2004. 280 s. ISBN 80-251-0342-0.

[6] PALETA, Petr. Co programátory ve škole neučí : aneb Softwarové inženýrství v reálné praxi. Brno : Computer Press, 2003. 360 s. ISBN 80-251-0073-1.

[7] PATTON, Ron. Testování softwaru. Praha : Computer Press, 2002. 328 s. ISBN 807226-636-5.

[8] BUCHALCEVOVÁ, Alena. Metodiky budování IS/ICT. Praha : Vysoká škola ekonomická, Katedra informačních technologií. 2004. [dokument ve formátu pdf]. Dostupný z WWW: .

7. SEZNAMY A PŘÍLOHY [9] Rational Software - IBM Software Group. Essentials of Rational Unified Process. Materiály školení Test Hatchery. Unicorn Education.

[10] Rational Software. Principles of Software Testing for Testers. 2002. Materiály školení Test Hatchery. Unicorn Education.

[11] Objektová analýza, návrh a programování. Praha: Vysoká škola ekonomická, Fakulta informatiky a statistiky. Luboš Pavlíček (správce webu). Poslední aktualizace 21.6.2005. Dostupný z WWW: .

[12] Profil společnosti [online]. Praha : Unicorn, c2008 [cit. 2008-08-11]. Dostupný z WWW: .

[13] HOUSER, Pavel. Rychle, levně, kvalitně? [online]. Computerworld, 2002 [cit. 2008-08-11].

Dostupný z

WWW:

0DD84C87BE22BCB6C1256D1E003A3DE7?OpenDocument>.

Související zdroje MCCARTHY, Jim. Softwarové projekty. Brno : Computer Press, 2000. 206 s. ISBN 8072261940.

ROSENAU, Milton D. Řízení projektů . Brno : Computer Press , 2007. 344 s. ISBN 978-80-251-1506-0.

SCHWALBE, Kathy. Řízení projektů v IT : Kompletní průvodce. Brno : Computer Press, 2007. 720 s. ISBN 978-80-251-1526-8.

THIBODEAU, Patrick. Chyby v softwaru zatím nejsou minulostí. Computerworld [online]. 11.3.2004. Dostupný z WWW: .

64


7.2 Seznam obrázků Obr.2.1. – Problémy při vývoji software ........................................................................13 Obr.2.2. – Základní příčiny problémů.............................................................................14 Obr.3.1. – Metodika RUP ...............................................................................................25 Obr.3.2. – Disciplíny metodiky RUP ..............................................................................27 Obr.3.3. – Základní činnosti XP......................................................................................30 Obr.3.4. – Vývojové fáze v metodice FDD ....................................................................32 Obr.3.5. – Životní cyklus metodiky TDD .......................................................................34 Obr.4.1. – Vážená kriteriální matice ...............................................................................47 Obr.5.1. – Testovací cyklus.............................................................................................50 Obr.5.2. – Testovací scénář.............................................................................................52 Obr.5.3. – Životní cyklus chyby......................................................................................59

7.3 Seznam tabulek Tab.3.1. – Porovnání agilních a rigorózních metodik.....................................................20 Tab.3.2. – Základní činnosti XP......................................................................................30 Tab.4.1. – Seznam kritérií a jejich hodnot ......................................................................40 Tab.4.2. – Hodnoty kritérií a jejich hodnocení metodiky RUP ......................................41 Tab.4.3. – Hodnoty kritérií a jejich hodnocení metodiky XP .........................................42 Tab.4.4. – Hodnoty kritérií a jejich hodnocení metodiky FDD ......................................42 Tab.4.5. – Hodnoty kritérií a jejich hodnocení metodiky TDD ......................................43 Tab.4.6. – Stanovení vah pro kritéria..............................................................................46 Tab.4.7. – Kriteriální matice metody TOPSIS................................................................46 Tab.5.1. – Fáze testovacího cyklu...................................................................................49 Tab.7.1. – Kriteriální matice ...........................................................................................66 Tab.7.2. – Upravená matice č.1.......................................................................................66 Tab.7.3. – Upravená matice č.2.......................................................................................66 Tab.7.4. – Normalizovaná matice ...................................................................................66 Tab.7.5. – Vážená matice................................................................................................67 Tab.7.6. – Vzdálenost variant od ideální alternativy Di + ..............................................67 Tab.7.7. – Vzdáleností variant od ideální alternativy Di - ..............................................67 Tab.7.8. – Relativní ukazatel vzdálenosti .......................................................................67 Tab.7.9. – Výsledky optimalizační metody TOPSIS ......................................................67

65


7.4 Přílohy Metoda TOPSIS - výpočty

Tab.7.1. – Kriteriální matice 1

2

3

4

5

6

max

max

min

max

max

max

RUP

4

7

8

9

8

8

XP

6

3

3

6

6

6

FDD

4

8

6

3

4

5

TDD

6

3

3

7

7

9

Tab.7.2. – Upravená matice č.1. 1

2

3

4

5

6

max

max

max

max

max

max

RUP

4

7

0

9

8

8

XP

6

3

5

6

6

6

FDD

4

8

2

3

4

5

TDD

6

3

5

7

7

9

Tab.7.3. – Upravená matice č.2. 1

2

3

4

5

6

max

max

max

max

max

max

RUP

16

49

0

81

64

64

XP

36

9

25

36

36

36

FDD

16

64

4

9

16

25

TDD

36

9

25

49

49

81

Suma

104

131

54

175

165

206

Odmocnina

10,198039

11,4455231 7,34846923 13,2287566 12,8452326 14,3527001

Tab.7.4. – Normalizovaná matice 1

2

3

4

5

6

max

max

max

max

max

max

RUP

0,39223227 0,61159284

XP

0,58834841 0,26211122 0,68041382 0,45355737 0,46709937 0,41803981

FDD

0,39223227 0,69896325 0,27216553 0,22677868 0,31139958 0,34836651

TDD

0,58834841 0,26211122 0,68041382 0,52915026 0,54494926 0,62705971

0

66

0,68033605 0,62279916 0,55738641

7. SEZNAMY A PŘÍLOHY Tab.7.5. – Vážená matice váhy

0,06

0,12

0,1

0,28

0,24

0,2

1

2

3

4

5

6

max

max

max

max

max

max

0

0,19049409

0,1494718

0,11147728

RUP

0,02353394 0,07339114

XP

0,0353009

FDD

0,02353394 0,08387559 0,02721655 0,06349803

TDD

0,0353009

0,03145335 0,06804138 0,12699606 0,11210385 0,08360796 0,0747359

0,0696733

0,03145335 0,06804138 0,14816207 0,13078782 0,12541194

H

0,035

0,084

0,068

0,19

0,149

0,125

D

0,024

0,031

0

0,063

0,075

0,07

Tab.7.6. – Vzdálenost variant od ideální alternativy Di + 1

2

3

4

5

6

max

max

max

max

max

max

RUP

0

0

0,005

0

0

0

XP

0

0,003

0

0,004

0,001

0,002

FDD

0

0

0,002

0,016

0,006

0,003

TDD

0

0,003

0

0,002

0

0

Tab.7.7. – Vzdáleností variant od ideální alternativy Di 1

2

3

4

5

6

max

max

max

max

max

max

RUP

0

0,002

0

0,016

0,006

0,002

XP

0

0

0,005

0,004

0,001

0

FDD

0

0,003

0,001

0

0

0

TDD

0

0

0,005

0,007

0,003

0,003

Tab.7.8. – Relativní ukazatel vzdálenosti Suma Di +

Di +

Suma Di -

Di -

Ci

RUP

0,00507

0,07121931

0,02522

0,15880745

0,69

XP

0,00992

0,09961942

0,01039

0,10193444

0,506

FDD

0,02663

0,16317285

0,00349

0,05906634

0,266

TDD

0,00489

0,06992269

0,01818

0,13485068

0,659

Tab.7.9. – Výsledky optimalizační metody TOPSIS Metodiky

Výsledky

Pořadí

RUP

0,69

1

XP

0,506

3

FDD

0,266

4

TDD

0,659

2

67

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

Recommend Documents