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.

5

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

6

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

7

Abstrakt

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

Tématem této bakalářské práce jsou metodiky vývoje software. Úkolem je stanovit

rizika spojená s návrhem a realizací software, vymezit problémy a jejich příčiny při

vývoji software. Hlavním cílem bakalářské práce je porovnání metodik pro vývoj

software. V rámci této bakalářské práce byla porovnána metodika RUP (Rational

Unified Process), jako zástupce rigorózního vývoje, s metodikami XP, TDD, FDD, jako

zástupci agilního vývoje. Porovnání bylo realizováno pomocí vícekriteriální

optimalizační metody TOPSIS. Vybrané metodiky byly porovnány se zaměřením na

oblast testování. Na základě specifikace požadavků projektu byla zvolena vhodná

metodika pro vývoj software. Pro vhodnou metodiku byla navrhnuta testovací strategie

pro pokrytí systému testy, zahrnující testovací cyklus a klasifikaci testů.

8

Abstract

The comparative analysis of software development methodologies

This bachelor work deals with different methodologies of software development. It

aspires to define risks connected with design and realization of software and to depict

problems encountered during software development as well as their causes. The main

aim of my bachelor work is to compare different methodologies of software

development. I tried to compare the RUP methodology (Rational Unified Process), as a

representative of rigorous development, with XP, TDD and FDD methodologies, as

representatives of agile development. Comparison was carried out by the multicriterion

optimalization method TOPSIS. Chosen methodologies were compared with focus on

software-testing issues. In accordance with specification of project requirements the

suitable software development methodics was chosen. For this suitable methodology the

test strategy for coverage of system with tests, including the testing cycle and tests

classification, was designed.

1. ÚVOD

9

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.

1. ÚVOD

10

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.

1. ÚVOD

11

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]

2. RIZIKA SPOJENÁ S NÁVRHEM A REALIZACÍ SOFTWARE

12

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]


13

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í


14

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


15

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


16

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]


17

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.

3. POROVNÁNÍ METODIK VÝVOJE SOFTWARE

18

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


19

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


20

Rigorózní metodiky Agilní metodiky

1. Proces

vývoje

software

Přesně a podrobně definovaný

proces, lze ho opakovat.

Empirický proces, není možné ho

opakovat, ale vyžaduje adaptaci.

2. Změny a

požadavky

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

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

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

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

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

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

požadavků, snaha o umožnění změn

(v závislosti na nových znalostech).

3. Zapojení

zákazníka na

řízení projektu

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

Po podpisu smlouvy a vymezení

dokumentu specifikace požadavků

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

konečné řešení.

Participace a spolupráce -

Zákazník se aktivně zapojuje do

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

funkcí při každé iteraci.

4. Kvalita Více zaměřeny na kvalitu vlastních

procesů, než na výsledek pro

zákazníka.

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

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

na výslednou kvalitu produktu.

5. Způsob a

rozsah řešení

Podrobný popis procesů a činností,

složité řešení.

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

snaha o zabudování budoucích

požadavků.

Eliminace nepotřebných činností,

jednoduché řešení.

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

funkce, snaha o minimalizaci, žádné

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

6. Rozložení

teamového

know-how

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

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

Požadavek na specializaci

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

forma komunikace (dokumentace).

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

(kooperace) a aktivní komunikace

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

problémů, řízení a integrace

znalostních toků.

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

faktor, procesy doplňovány rozsáhlou

dokumentací. Jedinci jsou

nahraditelní.

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

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

a dovedností jedinců (individualit),

důraz na znalosti, kvalifikaci.

8. Způsob

vývoje

Vodopádový životní cyklus, iterativní

s dlouhými iteracemi.

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

s velmi krátkými iteracemi.

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


21

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]


22

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 know-

how 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]


23

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í


24

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.


25

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.


26

� 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í


27

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.


28

� 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


29

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 komunikaci nad zdrojovým textem.

[5, s. 135 - 145]


30

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í

(psaní zdrojového kódu)

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

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

standardy kódu

Testování unit testy, akceptační testy

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


31

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


32

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


33

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ě


34

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]


35

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]

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

36

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.


37

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.


38

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]


39

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?


40

Kritérium číslo 6: Zaměření metodiky na fázi vývoje

Každá metodika se do jisté míry vymezuje oproti ostatním. Přichází

s nějakou novinkou, věnuje pozornost určitému aspektu vývojového cyklu. Toto

kritérium popisuje na jakou fázi popř. fáze klade metodika největší důraz.

Kritérium Vymezení Hodnota / významu kritéria

1. „Typ řešení“ [2, s. 28] a) nové řešení, b) rozšíření stávajícího, c) integrace řešení,

d) inovace [2, s. 28]

2. „Přístup k řešení“ [2, s. 28] a) objektově-orientovaný, b) strukturovaný,

c) RAD – rychlý vývoj aplikací [2, s. 28]

3. Míra složitosti metodiky

(propracovanost, obsáhlost)

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

b) střední náročnost c) jednoduchá metodika [2, s. 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

vývoje

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

návrh, implementace, testování atd.

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

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


41

4.3 Metodiky podle stanovených kritérií

V následující tabulkové části je zpracován základní popis metodik podle

stanovených kritérií. Pro jednotlivé metodiky byla každému kritériu porovnání

přiřazena hodnota kritéria a číselné ohodnocení kritéria podle formulace zadání a

vymezení projektu. Každá tabulka obsahuje kritérium, jeho hodnotu, která co nejvíce

vystihuje metodiku, a číselné hodnocení jednotlivých kritérií pro uvedené metodiky

vývoje.

Jednotlivé metodiky byly vzájemně porovnány na základě kritérií. Každá metodika

byla číselně ohodnocena podle požadavků na projekt. Jednotlivá kritéria jsou

ohodnocena podle hodnotící stupnice od 1 do 10. Minimální hodnota 1 znamená, že

metodika nevyhovuje požadavkům na projekt. Maximální hodnota 10 znamená, že

metodika nejlépe vyhovuje požadavkům na projekt.

RUP - Rational Unified Process

Kritérium Hodnota kritéria Hodnocení

1. Typ řešení spíše nové řešení (rozšíření

zavedeného)

4

2. Přístup k řešení objektově-orientovaná ve všech fázích 7

3. Míra složitosti metodiky velmi náročná na složitost 8

4. Zaměření testování (typ testů) black box testy, funkční testování,

definuje FURPS

9

5. Rozsah (a hloubka) testování průběžné testování v každé fázi (po

každé iteraci během celého vývoje)

8


vývoje

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

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


42

XP – Extrémní programování


1. Typ řešení rozšíření stávajícího, integrace

zavedeného

6

2. Přístup k řešení strukturovaný, RAD 3

3. Míra složitosti metodiky jednoduchá metodika 3

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

testů)

White box testování, unit testy, testy

integrace, UAT (viz kapitola 5.2)

6

5. Rozsah (a hloubka) testování testování na konci vývoje před

implementací

6


vývoje

Kódování (implementace) 6

Tab.4.3. – Hodnoty kritérií a jejich hodnocení metodiky XP

FDD – Feature-Driven Development (vlastnostmi řízený vývoj)


1. Typ řešení nové řešení 4

2. Přístup k řešení objektově-orientovaná ve všech fázích 8

3. Míra složitosti metodiky střední náročnost 6

4. Zaměření testování (typ testů) nedefinováno 3

5. Rozsah (a hloubka) testování testování na konci vývoje v rámci fáze

implementace

4


vývoje

Požadavky – seznam vlastností 5

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


43

TDD – Test-Driven Development (testy řízený vývoj)


1. Typ řešení rozšíření stávajícího, integrace

zavedeného

6

2. Přístup k řešení strukturovaný, RAD 3

3. Míra složitosti metodiky jednoduchá metodika 3

4. Zaměření testování (typ testů) white box testování, unit testy, testy

integrace (viz kapitola 5.2)

7

5. Rozsah (a hloubka) testování na začátku vývoje v počáteční fázi před

implementací

7


vývoje

testování 9

Tab.4.5. – Hodnoty kritérií a jejich hodnocení metodiky TDD

4.4 Analýza číselného hodnocení kritérií

V následující kapitole byla provedena interpretace tabulkové části. Provedená

analýza vyjadřuje porovnání metodik podle kritérií. Hlavním cílem je vysvětlení a

zdůvodnění číselného vyjádření hodnot kritérií pro každou metodiku podle zadání

projektu.

Kritérium typ řešení

Pro toto kritérium je nejvíce žádoucí metodika rozšiřující stávající systém o nové

funkčnosti popř. o implementaci změnových požadavků již zavedených funkčností.

Toto kritérium podle požadavků na projekt nejlépe splňují metodiky TDD a XP, proto

byly číselně ohodnoceny jako lépe vyhovující pro realizaci projektu. Metodiky RUP a

FDD byly spíše navrhnuty pro vývoj nového řešení informačního systému, nikoliv pro

jeho změny či inovace.


44

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é


45

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.


46

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 1 2 3 4 5 6

Váha 0,06 0,12 0,10 0,28 0,24 0,20

Tab.4.6. – Stanovení vah pro kritéria

Vyčíslení jednotlivých kritérií pro uvedené metodiky vývoje ukazuje tabulka

(Tab.4.7). Kritérium míra složitosti je vymezeno jako minimalizační z důvodu zadání

projektu.

Kritérium 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.


47

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 i j , dále jejich sumu (součet) ∑ y2 i j a následně

odmocninu √ ∑ y2 i j .

3. krok: Vytvořená normalizovaná kriteriální matice R (Tab.7.4)

R i j podle vztahu : R i j = y i j / √ ∑ 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.

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

v1 r11 v2 r12 . . .

v1 r21 v2 r22 . . .

W = . .

. .


48

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.

5. TESTOVACÍ STRATEGIE

49

5. Testovací strategie

Testovaní je nejdůležitější proces zajišťování kvality software. Proto je důležité

tento proces organizovat, plánovat a řídit. Tento úkol se snaží vyřešit testovací strategie.

Strategie testování stanovuje postup, podle kterého bude testovací tým provádět

ověřování a kontrolu funkčnosti software. Popisuje časový plán testů, definuje

sledování výsledků testování z hlediska chybovosti a rovněž vymezuje rizikové oblasti

testování. Na základě výsledků optimalizační metody je testovací strategie určena

metodice RUP.

5.1 Testovací cyklus

Cyklus testování metodiky RUP je založen na iterativním vývoji. V následující

tabulce (Tab.5.1) je stručně popsáno jaké činnosti probíhají a jaké dokumenty jsou

vytvářeny v jednotlivých fázích testovacího cyklu.

Fáze testovacího cyklu

(kompetentní role) Činnosti Dokumenty

Plánování testů

(Test manager)

Definice testovacího rozsahu

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

testování

Identifikace rizik

Rozsah testů (Test scope)

Testovací plán

Testovací požadavky

Návrh testů

(Test architect)

Definice typů testů Strategie testů

Definice prostředí

Vytváření testů

(Test designer & tester )

Příprava manuálních a

automatizovaných testů

Definice testovacích dat

Testovací případy

Testovací scénáře

Vykonávání testů

(Tester)

Test report

Testovací výsledky

Seznamy chyb

Vyhodnocení testů

(Test manager)

Zhodnocení testů Závěrečné shrnutí

Test protokol

Sledování defektů

Defect report

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


50

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]


51

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, nebo-

li 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ů.


52

• 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]


53

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]


54

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.


55

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]


56

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.


57

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.


58

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]


59

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]

6. ZÁVĚR

60

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

6. ZÁVĚR

61

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.

6. ZÁVĚR

62

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.

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 80-

7226-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: <http://nb.vse.cz/~buchalc/metodiky.pdf >.


64

[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: <http://objekty.vse.cz>.

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

WWW: <http://www.unicorn.eu/cz/ospolecnosti/profil.php>.

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

2008-08-11]. Dostupný z WWW: <http://archiv.cw.cz/cwarchiv.nsf/clanky/

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: <http://computerworld.cz/cw.nsf/id/090B

A46ADD0842DAC1256E9400332DEA?OpenDocument&Highlight=0,>.


65

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


66

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


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


RUP 0,39223227 0,61159284 0 0,68033605 0,62279916 0,55738641

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


67

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


RUP 0,02353394 0,07339114 0 0,19049409 0,1494718 0,11147728

XP 0,0353009 0,03145335 0,06804138 0,12699606 0,11210385 0,08360796

FDD 0,02353394 0,08387559 0,02721655 0,06349803 0,0747359 0,0696733

TDD 0,0353009 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


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


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

Date post:	24-Sep-2019
Category:	Documents
Upload:	others
View:	5 times
Download:	0 times

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

Documents