Vysoká škola ekonomická v Praze

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií

Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie

Diplomant: Bc. Pavel Vávra Vedoucí diplomové práce: doc. Ing. Ota Novotný, Ph.D. Oponent diplomové práce: Ing. Zdeněk Jonáš

Podpora řízení softwarové kvality v malé firmě

školní rok 2009/2010

Prohlášení

Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem čerpal.

V Praze dne

………………………………. podpis

Poděkování

Rád bych poděkoval svému vedoucímu doc. Ing. Otovi Novotnému, Ph.D. za cenné připomínky a rady, které mi pomohly s vytvořením této práce.

Abstrakt (česky): Cílem této práce je vytvoření návrhu frameworku vhodného pro podporu řízení kvality softwaru v malé firmě. Framework zahrnuje procesy, metodiky a nástroje, které mají dohromady sloužit ke zlepšení kvality softwarových produktů firmy. Konkrétní implementace frameworku je ukázána formou případové studie. Podrobnější vytýčení cílů a účelu této práce a určení cílového čtenáře lze nalézt v kapitole 1. Úvod. Pojmy používané v práci jsou popsány v kapitole 2. Vymezení pojmů. Kapitola 3. Softwarová kvalita a její definice se zabývá definicí pojmu „softwarová kvalita“ a popisuje specifika malých firem. Kapitola 4. Podpora řízení softwarové kvality představuje teoretický základ práce. Je v ní popsáno, jak na oblast softwarové kvality a testování nahlíží metodiky RUP a CMMI. V kapitole 5. Návrh frameworku už se pak nachází konkrétní návrh frameworku pro řízení softwarové kvality. Framework byl vytvořen jak na základě relevantních zdrojů, tak na základě autorových zkušeností. Kapitola 6. Případová studie pak popisuje příklad implementace navrženého frameworku v malé firmě. Součástí případové studie jsou i popisy použitých nástrojů. V kapitole 7. Závěr se pak nachází stručné shrnutí výsledků práce.

Klíčová slova (česky): Softwarová kvalita, řízení softwarové kvality, vývoj softwaru, framework, metodika, software quality assurance, testování, malé firmy, případová studie, CMMI, RUP, OpenUP.

Abstract (English): The goal of this thesis is to create a proposal of framework which can be used to support software quality management in a small company. Framework is composed of processes, methodologies and tools which together should improve the quality of software products of a small company. Concrete implementation of the framework is shown as a case study. The detailed goal setting for this thesis and the definition of the target reader can be found in the chapter 1. Introduction. The definition of main terms, which will appear in the rest of the thesis, is contained in the chapter 2. Terms. Chapter 3. Software quality and its definition is explains the term “software quality” and the nature of the small companies. Chapter 4. Software quality management forms the theoretical foundation of the thesis. In this chapter you find how the methodologies RUP and

CMMI view the software quality. Chapter 5. Framework concept contains the concept of the software quality management framework. Framework is based upon relevant sources and also author’s personal experience. The chapter 6. Case study describes the concrete example of the implementation of the proposed framework. The case study also contains descriptions of the used software tools. The chapter 7. Conclusion contains the brief resume of the findings of the thesis.

Key words (English): Software quality, software quality management, software development, framework, methodology, software quality assurance, testing, small companies, case study, CMMI, RUP, OpenUP

Obsah: 1

Úvod................................................................................................................................................ 1 1.1

Vymezení tématu a současný stav oblasti .............................................................................. 1

1.2

Cíle práce ............................................................................................................................... 2

1.3

Očekávané vlastní přínosy ..................................................................................................... 3

1.4

Určení práce........................................................................................................................... 4

2

Vymezení pojmů.............................................................................................................................. 4

3

Softwarová kvalita a její definice.................................................................................................... 6

4

3.1

Co je softwarová kvalita? ...................................................................................................... 6

3.2

Malé firmy z hlediska softwarové kvality ........................................................................... 11

Podpora řízení softwarové kvality................................................................................................. 13 4.1

Požadavky na framework..................................................................................................... 13

4.2

Procesy a metodiky.............................................................................................................. 14

4.2.1

Metodika RUP a SQA ..................................................................................................... 15

4.2.1.1

Základní principy.................................................................................................... 15

4.2.1.2

Životní cyklus ......................................................................................................... 16

4.2.1.3

Disciplíny................................................................................................................ 17

4.2.1.4

Kvalita v RUP......................................................................................................... 19

4.2.1.5

Využití RUP v případové studii .............................................................................. 21

4.2.2

CMMI a SQA .................................................................................................................. 21

4.2.2.1

Základní koncepty CMMI ...................................................................................... 21

4.2.2.2

Kauzální analýza a řešení ....................................................................................... 23

4.2.2.3

Kvantitativní projektový management.................................................................... 24

4.2.2.4

Řízení rizik.............................................................................................................. 25

4.2.2.5

Verifikace................................................................................................................ 25

4.2.2.6

Validace................................................................................................................... 26

4.2.2.7

Zajištění kvality procesu a produktu....................................................................... 27

4.2.2.8

Měření a analýza..................................................................................................... 27

4.2.2.9 5

Návrh frameworku ........................................................................................................................ 28 5.1

OpenUP a proces vývoje...................................................................................................... 29

5.1.1

Základní principy............................................................................................................. 29

5.1.2

Role SQA ve fázích projektu........................................................................................... 32

5.2 5.2.1 5.3

Řízení rizik........................................................................................................................... 34 Seznam rizik .................................................................................................................... 34 Tvorba požadavků................................................................................................................ 37

5.3.1

Pracovní produkty a role ................................................................................................. 37

5.3.2

Slovník............................................................................................................................. 38

5.3.3

Vize.................................................................................................................................. 39

5.3.4

Zápis požadavků.............................................................................................................. 41

5.3.5

Rozdělení požadavků....................................................................................................... 42

5.4

Tvorba a správa případů užití a testovaných případů .......................................................... 44

5.4.1

Uživatelské případy......................................................................................................... 45

5.4.2

Testované případy............................................................................................................ 48

5.4.3

Správa testovaných případů............................................................................................. 50

5.5

Testování.............................................................................................................................. 51

5.5.1

Typy testů ........................................................................................................................ 51

5.5.2

Testovací proces .............................................................................................................. 53

5.5.3

Správa chyb ..................................................................................................................... 55

5.5.4

Automatizace testů .......................................................................................................... 58

5.6 6

Využití CMMI v případové studii........................................................................... 28

Vlastní přínos....................................................................................................................... 60

Případová studie ............................................................................................................................ 61 6.1

Cíle a předmět případové studie .......................................................................................... 61

6.2

Popis firmy Cleverbee s.r.o.................................................................................................. 62

6.3

Situace v SQA ve firmě ....................................................................................................... 64

6.3.1

Pracovní tým.................................................................................................................... 64

6.3.2

6.3.2.1

Úroveň řízení rizik.................................................................................................. 66

6.3.2.2

Úroveň tvorby a správy požadavků ........................................................................ 67

6.3.2.3

Úroveň tvorby případů užití a testovaných případů................................................ 67

6.3.2.4

Úroveň testování..................................................................................................... 68

6.4

Implementace frameworku .................................................................................................. 69

6.4.1

Řízení rizik ...................................................................................................................... 69

6.4.1.1

Implementace.......................................................................................................... 69

6.4.1.2

Použité nástroje....................................................................................................... 69

6.4.2

Tvorba požadavků ........................................................................................................... 70

6.4.2.1

Implementace.......................................................................................................... 70

6.4.2.2

Nástroje................................................................................................................... 70

6.4.3

Tvorba a správa případů užití a testovaných případů ..................................................... 72

6.4.3.1

Implementace.......................................................................................................... 72

6.4.3.2

Nástroje................................................................................................................... 73

6.4.4

7

Úroveň používaných procesů .......................................................................................... 66

Testování.......................................................................................................................... 75

6.4.4.1

Implementace.......................................................................................................... 75

6.4.4.2

Nástroje................................................................................................................... 76

6.5

Zhodnocení frameworku jako celku .................................................................................... 80

6.6

Náklady na framework......................................................................................................... 81

Závěr ............................................................................................................................................. 83 7.1

Shrnutí výsledků .................................................................................................................. 83

7.2

Splnění stanovených cílů ..................................................................................................... 84

7.3

Můj přínos............................................................................................................................ 84

7.4

Využitelnost a další náměty k řešení.................................................................................... 85

8

Přehled literatury a informačních zdrojů....................................................................................... 87

9

Terminologický slovník................................................................................................................. 89

10

Přílohy ....................................................................................................................................... 91

10.1

Seznam rizik (seznam_rizik.xls).......................................................................................... 91

10.2

Vize (vize.doc) ..................................................................................................................... 91

1 Úvod 1.1 Vymezení tématu a současný stav oblasti Softwarová kvalita je oblastí, která při vývoji aplikací v současnosti stále často ustupuje do pozadí. Někdy není dokonce ani brána jako samostatný obor, ale je považována za integrální součást jiných disciplín (např. vývoj, procesní řízení a optimalizace). I celkový obsah pojmu „kvalita softwaru“ je vnímán různě, většina lidí si pod ním nejspíše představí pouze samotné testování aplikací, které je ve skutečnosti pouze jedním ze způsobů, kterými je kvalita zajišťována (resp. ověřována). Kontrola a řízení kvality je přitom ale poměrně dosti široký obor, který zahrnuje velké množství poddisciplín a týká se celého vývojového procesu, nikoli jen jeho poslední části (což je obvykle testování). Tento obor se anglicky nazývá Software Quality Assurance (dále jen SQA) a zahrnuje kromě testování (ručního i automatizovaného) i optimalizaci a měření procesů, kontrolu kvality programátorského kódu, dokumentaci, change management, návrh uživatelských rozhraní a další disciplíny. Důležité pro charakterizaci SQA je to, že se nesnaží kvalitu primárně zjistit nebo kontrolovat, ale hlavně zajistit. SQA manažeři se účastní vývojového procesu už od začátku a snaží se nastavovat a měřit procesy tak, aby byl výsledný produkt kvalitní podle obecně platných norem (jakými jsou např. ISO 9000, ISO 9126 a CMMI, o kterých bude řeč dále). Většina velkých firem zabývajících se vývojem softwaru disponuje už poměrně velkými odděleními, která se této oblasti věnují, a jejich proces řízení softwarové kvality bývá do detailu propracován. Z mých zkušeností ale vyplynulo, že u malých firem tomu takto zdaleka není a propracovanost SQA metodiky u nich bývá často velmi nízká nebo takováto metodika dokonce vůbec neexistuje. V menších softwarových společnostech bývá spíše zvykem nabrat jednoho, dva testery, dát jim produkt na otestování a spoléhat na to, že většinu kritických chyb budou schopni odchytit předtím, než bude tento produkt vydán. Na tomto přístupu v zásadě není nic špatného, ale ukazuje přílišnou krátkozrakost manažerů takovéto firmy při vnímání toho, co softwarová kvalita je. Ačkoli se testerské oddělení v této firmě může nazývat Quality Assurance, o opravdovou Quality Assurance (tj. zajištění kvality) se nejedná – testeři pouze reportují nalezené chyby, ale nijak se nesnaží o vytvoření prostředí, které by zabránilo těmto chybám v jejich opětovném výskytu. Samozřejmě malé firmy jsou v tomto případě limitovány svou velikostí a velikostí svého rozpočtu – nejsou schopny zaplatit kvalifikované SQA manažery, nemají k dispozici dostatečné know-

1

how a ani si nemohou dovolit zakoupit balíky nákladných specializovaných nástrojů, které by jim firemní SQA podpořily. A právě vytvořením a konkrétní implementací platformy, která by takovémuto malému podniku umožnila zajišťovat softwarovou kvalitu efektivně a s nízkými náklady, se zabývá tato práce. Popis způsobů, kterými bych toho chtěl dosáhnout, je uveden v další kapitole. Téma jsem si zvolil, protože mě tato oblast (řízení softwarové kvality) zajímá a věnuji se jí i v praxi, a kromě toho vidím poměrně velký nedostatek prací v českém jazyce, které by se mu věnovaly. Chtěl bych též ukázat, že se jedná o téma podstatně komplexnější, než se na první pohled může zdát. Jak již jsem uvedl výše, řízení softwarové kvality bývá často podceňováno a rád bych, aby tato práce pomohla ukázat, že je tomu tak neprávem.

1.2 Cíle práce Má práce má dva hlavní cíle. Prvním hlavním cílem je vytvoření návrhu obecně platného frameworku, který by umožňoval malým softwarovým firmám efektivně zajišťovat kvalitu svých produktů. Anglické slovo framework, které používám, tu znamená určitou konceptuální strukturu, která zahrnuje jak metodiky a procesy, tak technické nástroje. Blíže je tento pojem vysvětlen v kapitole 2. Vymezení pojmů. U tohoto cíle je třeba zdůraznit, že se budu snažit vytvořit framework pro malé firmy a možnostmi jeho použití pro větší organizační jednotky se zde zabývat nebudu. Druhým hlavním cílem práce je pak vytvoření případové studie, která ukáže vytvoření a užití takovéhoto frameworku v praxi. Tj. studie bude obsahovat popis nějaké malé firmy, která tento framework implementovala, popíše jeho součásti a jejich vzájemné vazby a nakonec zhodnotí účinnost této implementace a identifikuje případné problémy. Vytvoření vhodného SQA frameworku se bude skládat z těchto hlavních částí: • Identifikace pojmu „softwarová kvalita“ a identifikace požadavků na framework, které z této definice vyplývají (jako výchozí zde budou brány zejména norma ISO 9126 a CMMI, což je model pro zlepšení zralosti procesů ve vývoji produktů a služeb [3]). • Identifikace potřeb malých firem v oblasti softwarové kvality a toho, čím se tyto potřeby liší od firem větších. • Identifikace nástrojů, procesů a metodik, z kterých by se měl takovýto framework skládat. • Důkladný popis všech výše zmíněných součástí frameworku a popis jejich vzájemných souvislostí a vazeb. • Praktická část práce - případová studie, která bude popisovat implementaci podobného SQA frameworku v konkrétní malé firmě. Pro tento případ bych si vybral firmu, kde pracuji, a kde 2

v současnosti probíhá implementace takovéhoto frameworku – Cleverbee s.r.o. Praktická část bude popisovat i problémy, které se vyskytly v průběhu implementace a návrhy na zlepšení, které z ní vzešly. Součástí bude i stručný popis firmy a stavu, v kterém se nacházela oblast SQA a vývoje obecně, před implementací frameworku. V této části zároveň popíši konkrétní nástroje, které byly v rámci implementace frameworku ve firmě Cleverbee použity. • Pokračování praktické části - Zhodnocení výsledků implementace frameworku, jeho limitů a diskuze případných alternativ. Diskuze způsobů měření efektivity tohoto frameworku. Je třeba zdůraznit, že tato práce nechce obsáhnout oblast SQA v celé její rozsáhlosti, ale jak vyplývá z výše zmíněných cílů, chce se hlavně zaměřit na to, co bude SQA v malých firmách co nejefektivněji podporovat.

1.3 Očekávané vlastní přínosy Osobně vidím tyto hlavní přínosy, které práci dodám já sám: •

Vytvoření návrhu SQA frameworku, který bude obecně použitelný v malých softwarových firmách. Při vytvoření frameworku budu vycházet z obecně platných norem týkajících se požadavků na softwarovou kvalitu (ISO normy, CMMI atd.) a případně také z publikací a expertních článků, které se zabývají touto problematikou. Framework bude zohledňovat specifické potřeby malých firem (limity v oblasti financí, lidských zdrojů atd.).

•

Vytvoření konkrétní případové studie, která bude ukazovat aplikaci SQA frameworku v praxi. Součástí studie bude i popis konkrétních nástrojů, které byly použity, tak aby se takovýto konkrétní framework dal jednoduše vzít a aplikovat v praxi. Součástí bude i zhodnocení efektivity této aplikace frameworku (i v porovnání s dobou předtím), nákladů na něj a identifikace prostoru pro zlepšení. Toto zhodnocení tak může pomoci případným čtenářům práce v rozhodnutí, zdali by podobný framework mohl být přínosem i pro jejich firmu.

Jako dílčí vlastní přínosy pak vidím tyto: •

Analýza požadavků na softwarovou kvalitu s přihlédnutím ke specifikům malých firem a jejich sepsání.

•

Identifikace hlavních nástrojů, procesů a metodik používaných při řízení softwarové kvality a nalezení konkrétních příkladů.

•

Nalezení vazeb mezi součástmi řízení softwarové kvality a jejich zdokumentování.

3

1.4 Určení práce Pro koho by měla být tato práce primárně určena? Doufám, že její přečtení bude alespoň částečným přínosem pro většinu lidí, kteří se zabývají oblastí SQA, ale asi největší užitek by z ní měl mít ten, kdo by chtěl nějaký podobný framework naimplementovat ve firmě podobné té, která byla zkoumána v případové studii. Typickým představitelem je tedy manažer kvality v menší softwarové firmě, která buď žádným podobným frameworkem zatím nedisponuje, anebo ten svůj současný považuje za neefektivní. Podobný přínos může mít ale práce i pro ostatní profese, které se zabývají zajišťováním kvality v procesu vývoje, jako jsou techničtí vedoucí, projektoví manažeři atd. Profitovat z ní může ale i obyčejný tester, který sice oblast kvality na vyšší úrovni neřeší, ale může využít např. popisy konkrétních testerských nástrojů, které se v této práci nacházejí. Opět je třeba zdůraznit, že tato práce se zabývá výhradně nástroji a procesy, které jsou vhodné pro malé firmy – tj. nejsou přehnaně robustní, jsou levné, mohou fungovat ve frameworku s dalšími nástroji/procesy atd. Problematika kvality ve velkých softwarových firmách o stovkách zaměstnanců je podstatně komplexnější, existují pro ni velká specializovaná řešení a tato práce se jimi tedy nehodlá zabývat. To ovšem neznamená, že by nic z toho, co zde bude řešeno, nebylo využitelné i pro manažera kvality ve větší firmě – zvlášť pokud by chtěl ušetřit, tak zde najde příklady nenáročných řešení, která by pro něj mohla být relevantní.

2 Vymezení pojmů V této práci budu zacházet s několika pojmy, jejichž definice nemusí být vždy jednoznačná. U několika takovýchto termínů, které se budou vyskytovat v celé práci, tu tedy popíši, jakým způsobem je budu vnímat a používat - tak aby nedošlo k případným mýlkám. Kromě čistokrevných definic zde také uvedu můj osobní názor na ně a také případná další možná vnímání těchto pojmů. Vysvětlím i způsob jejich použití v této práci. Je třeba zdůraznit, že toto je ale výběr pouze několika nejčastějších pojmů, jejich kompletní přehled je možné nalézt na konci práce v terminologickém slovníku. Většina definic pochází původně z anglických zdrojů a překlad jsem provedl já sám, takže nemusí úplně odpovídat oficiálnímu překladu, který se vyskytuje např. v českých verzích ISO norem. softwarová kvalita: dle normy ISO 9126 je softwarová kvalita: „Schopnost souhrnu funkcionality a vlastností softwarového produktu naplnit vyslovené i předpokládané požadavky na tento produkt“ [1]. Blíže se pojmu softwarové kvality budu věnovat v kapitole, která jí je přímo věnována. Tam si tuto její definici také rozšíříme a podíváme se i na další možné aspekty vnímání tohoto pojmu.

4

softwarová jakost: v českých překladech ISO norem je používán výraz „jakost“ jako překlad anglického výrazu „quality“. Já osobně dávám přednost českému překladu „kvalita“, který mi přijde v podmínkách českých softwarových firem zažitější - koneckonců hovoříme častěji o manažerech kvality a nikoli o manažerech jakosti. V této práci tedy budu používat častěji výraz „kvalita“, pokud se ale objeví výraz „jakost“, tak je brán jako ekvivalentní termín. Žádný významový rozdíl mezi oběma termíny tedy činit nebudu. software quality assurance: dle ISO 9000 je quality assurance „součást managementu kvality zaměřující se na zajištění splnění požadavků na kvalitu“ [2]. Model CMMI obsahuje o něco širší definici, dle ní jsou quality assurance: „plánované a systematické prostředky, které umožní managementu zajistit, že definované standardy, praktiky, procedury a metody daného procesu budou aplikovány“ [3]. V této práci budu považovat za platné obě tyto definice, vzájemně se nijak nevylučují. Do obou definic je pak třeba ještě doplnit, že se v tomto případě týkají výhradně softwarových produktů a procesů používaných při jejich vývoji. Termín budu používat v jeho anglickém znění, protože nemá žádný kodifikovaný český překlad. Používaná zkratka je SQA. software quality management: v ISO 9000 je „quality assurance“ bráno jako poddisciplína oblasti „quality management“, která je definována jako „Koordinované aktivity sloužící k řízení a kontrole organizace z hlediska kvality. Toto řízení a kontrola z hlediska kvality obvykle zahrnuje tvorba politiky a cílů kvality, plánování, kontrolu, zajišťování a zlepšování kvality“ [2]. Opět platí, že definici je v případě této práce nutno zúžit pouze na kvalitu softwarových produktů. řízení softwarové kvality: v této práci je tento pojem používán jako ekvivalent pojmu „software quality management“. Je třeba zdůraznit, že za hlavní součástí řízení softwarové kvality budu brát oblast SQA, která zahrnuje většinu činností, které může hledaný framework podporovat. framework: Anglický výraz „framework“ jsem se rozhodl použít, protože mezi českými slovy nevidím takové, které by strukturu, již chci vytvořit, dostatečně charakterizovalo, navíc je slovo „framework“ v IT branži poměrně zažité. V češtině tedy „framework“ obecně platnou definici nemá. Podíváme-li se do uznávaného amerického slovníku Merriam–Webster, najdeme tam pouze tuto stručnou definici: „základní konceptuální struktura“ [4]. Podrobnější popis frameworku přináší IT encyklopedie WhatIs?, dle ní je framework: „reálná nebo konceptuální struktura, která má sloužit jako podpora nebo návod k tvorbě něčeho, co rozšíří tuto strukturu v něco použitelného“ [5]. V oblasti IT pak dle WhatIs? může framework obsahovat konkrétní aplikace, specifikovat programová rozhraní a nabízet podpůrné programátorské nástroje. Framework je obvykle obsáhlejší než protokol a více svazující a normativnější než pouhý návrh struktury. Jak plyne z předchozích definic, framework může zahrnovat jak čistě konceptuální strukturu (kterou v této práci bude reprezentovat popis SQA procesů a metodik), tak konkrétní aplikace a rozhraní mezi nimi, a tak budu také jeho definici interpretovat.

5

testování: Významnou složkou SQA je testování softwaru (a jak jsem psal v úvodu, mnozí ho považují za složku jedinou) a v dalších kapitolách mu proto bude věnován velký prostor. Dle slovníku IEEE je testování softwaru definováno buď jako: „spouštění systému nebo komponenty dle definovaných podmínek, pozorování a zaznamenávání výsledků a zhodnocení nějakého aspektu tohoto systému nebo komponenty“ [6], nebo „proces analyzování softwarového produktu tak, aby byly zjištěny rozdíly mezi současným a požadovaným stavem (tj. chyby), a tak aby byly zhodnoceny vlastnosti tohoto systému“ [6]. V této práci považuji obě definice za platné, testování se zabývá hledáním chyb a zároveň celkovým vyhodnocováním vlastností systému (např. zhodnocením uživatelské přívětivosti). Osoby, které se zabývají testováním softwaru, se nazývají testeři. proces: Dle ISO 12207 je proces definován jako „soubor souvisejících aktivit, které transformují vstupy ve výstupy“ [7]. Proces je tedy přesným popisem toho, jak je (nebo má být) nějaká činnost vykonávána, nejedná se pouze o nějaký návod. metodika: Ačkoli v češtině můžeme rozlišit rozdíl mezi pojmy „metodika“ a „metodologie“ (což je spíše pojem označující vědní disciplínu), v angličtině se v oblasti softwaru ujal název „methodology“ (jako je např. v „software develepment methodology“ – „metodologie pro vývoj software“) a jeho význam tu budu považovat za ekvivalent českého slova „metodika“. Dle Merriam-Webster je „methodology“ definována jako „soustava metod, pravidel a postulátů používaných nějakou disciplínou“ nebo též „určitá procedura nebo soustava procedur“ [8]. Podrobnější definici uvádí Buchalcevová ve své knize Metodiky vývoje a údržby informačních systémů: „Metodika vývoje a údržby IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení.“ [31]. Můžeme tedy říci, že metodika je v podstatě návod, jak provádět určité činnosti v rámci určité disciplíny (v tomto případě je touto disciplínou SQA). Metodika je tedy obecnější než proces, popis metodiky se může týkat množství různých procesů.

3 Softwarová kvalita a její definice 3.1 Co je softwarová kvalita? Definice softwarové kvality (jakosti) už jsme se dotkli v předchozí kapitole, pojďme si ji nyní ale ještě trochu více rozebrat. Je jisté, že pokud bychom položili otázku „Co je softwarová kvalita?“ různým lidem účastnícím se vývojového procesu, dostali bychom spoustu různých odpovědí. Pro vývojáře může být kvalitní taková aplikace, která má přehledný a dobře zdokumentovaný kód, a naopak pro testera to může být ta, která má přívětivé uživatelské rozhraní, s kterým se mu dobře 6

pracuje. Největší výpovědní hodnotu má ale dle mého názoru stanovisko zákazníka. Vývojáři aplikace mohou být sice se svým produktem spokojeni, ale pokud je s ním nespokojen zákazník (tj. ten, komu je tento produkt primárně určen), tak sotva můžeme říci, že požadavky na kvalitu byly naplněny. Důležitost požadavků zohledňuje i výše zmíněná definice v normě ISO 9126, kterou si zde ještě pro pořádek zopakujme: „Softwarová kvalita je schopnost souhrnu funkcionality a vlastností softwarového produktu naplnit vyslovené i předpokládané požadavky na tento produkt“ [1]. Ačkoli zní tato definice logicky, tak nám proces řízení kvality asi příliš neusnadní. Co si například máme představit pod pojmem „předpokládané požadavky na produkt“? Pokud zákazník požadavky pouze předpokládá, ale nevysloví je, tak jak máme vědět, jaké jsou? ISO 9126 proto nekončí touto definicí a rozlišuje 6 charakteristik kvality softwarových produktů [1]: •

funkčnost

•

bezporuchovost

•

použitelnost

•

účinnost

•

udržovatelnost

•

přenositelnost Každou z těchto charakteristik stručně popíšu na dalších řádcích včetně jejich dílčích

podcharakteristik. Uvedu i původní anglické názvy pro případ, že by měl čtenář zájem si je vyhledat. Jako české překlady používám termíny, které byly uvedené v článku Roberta Pergla Plánování zajištění jakosti produktu dle ISO/IEC 9126: princip a představení praktického řešení [9] Funkčnost (Functionality): Shrnuje vlastnosti softwaru, které se týkají hlavních funkcí aplikace. Jsou to ty, které nejvíce naplňují ony vyslovené a/nebo předpokládané požadavky na produkt. Zahrnuje 5 podcharakteristik [1]: •

Funkční přiměřenost (Suitability) – schopnost produktu dodávat odpovídající funkce pro definované uživatelské úkoly a cíle.

•

Přesnost (Accuracy) – schopnost produktu dodávat přesné výsledky na potřebné úrovni preciznosti.

•

Schopnost spolupráce (Interoperability) – schopnost produktu spolupracovat s jedním nebo více definovanými systémy.

7

•

Bezpečnost (Security) – schopnost produktu chránit informace a data tak, že k nim nebudou mít přístup neautorizované systémy a osoby, a autorizovaným systémům a osobám tento přístup nebude odmítnut.

•

Shoda ve funkčnosti (Functionality Compliance) – schopnost produktu dodržovat standardy, konvence a právní regulace týkající se jeho funkčnosti.

Bezporuchovost (Reliability): Zahrnuje vlastnosti, které indikují schopnost softwaru pracovat po stanovený čas v rámci stanovených podmínek. Má 4 podcharakteristiky [1]: •

Zralost (Maturity) – schopnost vyhnout se selhání v případě výskytu chyb v produktu.

•

Odolnost vůči vadám (Fault Tolerance) – schopnost produktu zachovat si specifikovanou úroveň výkonu v případě výskytu chyb nebo určitého omezení jeho rozhraní.

•

Schopnost zotavení (Recoverability) – schopnost produktu vrátit se na specifikovanou úroveň výkonu a obnovit svá data v případě selhání.

•

Shoda v bezporuchovosti (Reliability Compliance) – schopnost produktu dodržovat standardy, konvence a právní regulace týkající se jeho bezporuchovosti.

Použitelnost (Usability): Zahrnuje vlastnosti, které určují, jak náročné je daný software používat, a jak je toto používání hodnoceno jeho uživateli. Má 5 podcharakteristik [1]: •

Srozumitelnost (Understandability) – schopnost produktu, která vyjadřuje, nakolik je uživatel schopen pochopit určení tohoto produktu, a jak tento produkt může používat ke splnění úkolů, pro které je určen.

•

Naučitelnost (Learnability) – schopnost produktu, která vyjadřuje, jak těžké je pro uživatele se naučit ho používat.

•

Provozovatelnost (Operability) – schopnost produktu, která vyjadřuje, jak těžké je pro uživatele tento produkt používat a ovládat.

•

Atraktivnost (Attractivness) – schopnost produktu být atraktivní pro svého uživatele.

•

Shoda v použitelnosti (Usability Compliance) - schopnost produktu dodržovat standardy, konvence a právní regulace týkající se jeho použitelnosti. 8

Účinnost (Efficiency): Zahrnuje vlastnosti, které se týkají vztahu mezi výkonem aplikací a množstvím zdrojů, které daný

software

spotřebovává

(za

9

daných

podmínek).

Má 3 podcharakteristiky [1]: •

Časové chování (Time Behaviour) – schopnost produktu podávat odpovídající odezvy, časy zpracování požadavků a průtok těchto požadavků, když tento produkt vykonává své funkce za určitých stanovených podmínek.

•

Využití zdrojů (Resource Utilisation) – schopnost produktu používat odpovídající množství a typy zdrojů během vykonávání své funkce za stanovených podmínek.

•

Shoda v účinnosti (Efficiency Compliance) - schopnost produktu dodržovat standardy, konvence a právní regulace týkající se jeho účinnosti.

Udržovatelnost (Maintainability): Zahrnuje vlastnosti, které vyjadřují, jak náročné je daný software udržovat a modifikovat. Má 5 podcharakteristik [1]: •

Analyzovatelnost (Analysability) – schopnost produktu, která vyjadřuje, jak obtížné je v něm nalézt nedostatky a identifikovat příčiny chyb, které se v něm vyskytly.

•

Měnitelnost (Changeability) – schopnost produktu umožnit implementaci specifikovaných změn.

•

Stabilnost (Stability) – schopnost produktu vyhnout se neočekávaným důsledkům změn v něm provedených.

•

Testovatelnost (Testability) – schopnost produktu, která vyjadřuje, jak obtížné je ho validovat.

•

Shoda v udržovatelnosti (Maintainability Compliance) - schopnost produktu dodržovat standardy, konvence a právní regulace týkající se jeho udržovatelnosti.

Přenositelnost (Portability): Zahrnuje vlastnosti, které vyjadřují, jak náročné je přenést software z jednoho prostředí do druhého. Má 6 podcharakteristik [1]: •

Přizpůsobitelnost (Adaptability) – schopnost produktu, která vyjadřuje, jak obtížné je ho adaptovat pro různá prostředí, aniž by bylo nutné provádět jiné akce než ty, které pro tuto adaptaci poskytuje sám software.

•

Instalovatelnost (Installability) – schopnost produktu, která vyjadřuje, jak obtížné je ho instalovat v specifikovaném prostředí. 10

•

Slučitelnost (Co-existence) – schopnost produktu koexistovat ve společném prostředí s jinými nezávislými produkty při sdílení společných zdrojů.

•

Nahraditelnost (Replaceability) – schopnost produktu, která vyjadřuje, jak obtížné je ho použít místo nějakého jiného produktu pro stejný účel a ve stejném prostředí.

•

Shoda v přenositelnosti (Portability Compliance) - schopnost produktu dodržovat standardy, konvence a právní regulace týkající se jeho přenositelnosti. Výše zmíněné charakteristiky jsou už poměrně vyčerpávajícím shrnutím toho, co všechno

může softwarová kvalita zahrnovat. Framework, který budu v dalších kapitolách popisovat, si neklade za cíl pokrytí všech těchto charakteristik, protože to by v podmínkách malých firem často ani nebylo nutné (např. jen málo z těchto firem bude řešit právní normy týkající se udržovatelnosti a přenositelnosti softwaru). Budu se ale rozhodně snažit, aby výsledný framework podporoval co nejvíce z nich. Je třeba ještě zmínit, že do oblasti softwarové kvality zasahuje podstatně více norem než jen výše zmíněná ISO 9126, dle článku Is there hope for software quality? od Dennise J. Fraileyho [18] je to např. ISO 25000 (známá též jako SQuaRE), která vychází z ISO 9126; ISO 12207 a ISO 15288, zabývající se procesy a životními fázemi vývoje softwaru; ISO 12119, které řeší požadavky na softwarové balíky a jejich testování nebo CMMI (Capability Maturity Model Integration), který není normou v pravém slova smyslu, ale také se obšírně zabývá kvalitou softwarových procesů a jejich vylepšováním. O některých z těchto norem budu ještě rozsáhleji psát v částech věnovaných procesům, ale pro obecnou definici softwarové kvality a požadavky na softwarové produkty si vystačím s obsahem normy ISO 9126.

3.2 Malé firmy z hlediska softwarové kvality V této kapitole bych se rád podíval na to, jak je v současnosti oblast softwarové kvality řešena v případě malých firem, a v čem jsou tyto firmy specifické. Napřed je ale třeba si definovat, jakou firmu vlastně můžeme považovat za malou. Je samozřejmé, že obecně platná definice se najít nedá, firmy, které jsou v jedné zemi považované za malé, mohou být v další považované za střední a naopak. Já budu používat definici Evropské unie, dle které jsou malé všechny firmy mající méně než 50 zaměstnanců, a které mají obrat (nebo součet rozvahy) pod 10 milionů eur [10]. Podle této definice existuje ještě podmnožina malých podniků, která se nazývá mikropodniky - jsou to ty, které mají méně než 10 zaměstnanců a jejichž obrat (nebo součet rozvahy) je nižší než 2 miliony eur [10]. Osobně nebudu mezi těmito malými podniky a mikropodniky rozlišovat, počítám s tím, že z frameworku, který se budu snažit najít, může do určité míry profitovat i firma, která má velmi malý počet zaměstnanců nebo velmi nízký obrat. 11

Jak již jsem zmínil v úvodu, v malých firmách bývá SQA často odsunuto na druhou kolej a tyto firmy většinou nedisponují žádnou metodikou, která by předepisovala, jak testovat a jak řídit softwarovou kvalitu. Částečně je to dáno i tím, že normy a metodiky, které jsou v této oblasti k dispozici, jsou dimenzované pro větší firmy a nezabývají se případy, kdy softwarovou kvalitu ve firmě řeší jen několik málo lidí. Příkladem budiž model CMMI, zaměřující se na zlepšování firemních procesů, který má ve své poslední verzi 573 stránek a popisuje procesy v softwarové firmě z mnoha různých pohledů. Pro velký podnik je takovýto robustní manuál ideální, pro manažera v menší firmě je ale velmi časově náročné celý ho prostudovat a vybrat z něj informace, které jsou pro jeho situaci relevantní. Služby externích firem zabývajících se implementací podobných metodik bývají také zaměřeny na větší podniky a tomu odpovídají i jejich ceny. Na podobné problémy může SQA manažer narazit i v případě, že se pokusí obstarat si software pro podporu řízení kvality. K dispozici jsou rozsáhlé balíky, které pokrývají všemožné aspekty SQA (správa chyb, správa testů, automatizované testování, zátěžové testování atd.), ale ty jsou obvykle opět dimenzovány pro větší firmy, jsou dosti nákladné a obsahují funkcionalitu, kterou malé firmy nepotřebují. Jako příklad těchto softwarových balíků si můžeme uvést HP Quality Center1 nebo IBM Rational ClearQuest2. Limitujícími faktory u malých softwarových firem jsou tedy hlavně lidé a finance. Manažeři kvality disponují omezeným počtem lidí, kteří mají oblast kvality softwaru na starosti – dá se čekat, že ve firmě o 50 zaměstnancích jich nebude více než 10 a neobvyklé není, pokud má SQA oddělení třeba jen 2 členy. Z vlastních zkušeností vím, že časté také bývá, že tito lidé zastávají v podniku více rolí, kromě SQA se mohou věnovat např. vývoji, řízení, tvorbě dokumentace nebo podpoře uživatelů. Takováto situace ale není úplně šťastná, SQA oddělení by mělo k testovaným produktům v první řadě přistupovat nezaujatě a je pochopitelně těžké si takovouto nezaujatost udržet, pokud se testeři zároveň podílejí na procesu vývoje. Vhodné rozdělení rolí v SQA oddělení bude tedy také součástí hledaného frameworku a budu ho podrobněji rozebírat v dalších částech práce. Co se týče finančních prostředků, tak je pochopitelné, že menší firmy jich nemají nazbyt a spíše je uvolní na nákup různých nástrojů pro podporu vývoje, jemuž se v nich věnuje většina lidí, než nástrojů podporujících testování. Tyto limity budu brát v potaz i při hledání vhodného frameworku, budu se snažit najít takový, který není obtížné ovládnout, jehož zavedení a provoz není nákladný a který je schopen efektivně podporovat i oddělení s malým počtem zaměstnanců. Blíže se požadavkům, vyplývajícím z těchto limitů,

1

budu

věnovat

v

kapitole

týkající

se

frameworku.

HP Quality Center, https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-

127-24_4000_100__ 2

vymezení

Rational ClearQuest, http://www-01.ibm.com/software/awdtools/clearquest/

12

4 Podpora řízení softwarové kvality V této části se pokusím vymezit požadavky na hledaný SQA framework a součásti, které by měl obsahovat. Bude se jednat zatím pouze o teoretický a obecný popis, konkrétní příklady jednotlivých částí frameworku se objeví v dalších kapitolách a hlavně v závěrečné případové studii. Požadavky na obsah frameworku budou vycházet jak z informací obsažených v předchozím textu, tak z nových zdrojů, použitých specificky za účelem tohoto vymezení.

4.1 Požadavky na framework Pokud hledáme SQA (Software Quality Assurance) framework, tak hned první požadavek vyplývá z jeho samotného názvu – framework by měl splňovat normy softwarové kvality. Bylo by určitě vhodné tento požadavek definovat nějak přesněji, uveďme si ho proto takto: •

„framework má zajistit, aby softwarový produkt, jehož kvalita je řízena, odpovídal obecně platným normám na tuto kvalitu“. O charakteristikách softwarové kvality už jsem se rozepisoval v kapitole 3.1 Co je softwarová

kvalita?. Vzhledem k jejich množství ale není v podstatě možné, aby SQA framework pro nějakou malou firmu pokrýval všechny tyto charakteristiky stejnou měrou. Důkladné pokrytí všech charakteristik často ani není nutné, např. pro firmu, které vyvíjí nenáročné aplikace pro malé množství uživatelů, nemají velký význam požadavky na účinnost (Efficiency) a společnost, která se zaměřuje na software pro státní správu, zase bude klást obzvláštní důraz na procesy a nástroje, které jí pomáhají zajistit shodu s právními normami. Konkrétní SQA framework bude popsán v kapitole 6. Případová studie a v níž se zmíním o tom, jaké konkrétní potřeby byly naplněny u firmy Cleverbee (jež se účastnila případové studie). V této teoretické části si ale vystačíme s výše zmíněným požadavkem. Dalšími požadavky, které framework musí splňovat, vyplývají z jeho určení – framework musí být vhodný pro malé firmy. O těchto požadavcích už jsem psal v kapitole 15. Malé firmy z hlediska softwarové kvality: framework by nemělo být obtížné ovládnout, jeho zavedení a provoz by neměl být nákladný a měl by být schopen efektivně podporovat i oddělení s malým počtem zaměstnanců. Vzhledem k tomu, že toto jsou požadavky poměrně vágní, rozhodl jsem se jim nastavit tyto metriky: •

Nasazení frameworku by nemělo stát více než 500 000 Kč

•

Náklady na údržbu a provoz frameworku by neměly překročit 100 000 Kč ročně

•

Zavedení frameworku a zaškolení odpovídajících zaměstnanců by nemělo trvat déle než 3 měsíce

13

•

Framework by měl fungovat v QA odděleních, která mají alespoň 2 zaměstnance Výše zmíněné limity vycházejí z mých zkušeností a rozhodl jsem se je zvolit také proto, abych

při vytváření nezacházel v některých oblastech příliš daleko – např. aby se v něm nenacházeli SQA nástroje, jejichž cena by byla pro většinu firem příliš drahá. Předpokládám, že náklady na nasazení frameworku budou z největší části mzdovými náklady - zohledňuji tak čas lidí, kteří se budou implementací zabývat. Do nákladů na údržbu jsem se rozhodl zahrnout také mzdy, ale dá se předpokládat, že to většinou nebudou náklady na práci členů SQA, kteří sice budou mít framework na starosti, ale nebudou správu dělat na plný úvazek, ale v podstatě paralelně se svou běžnou pracovní náplní. V případě jejich práce by se tak těžko odlišovalo, které odpracované hodiny opravdu šly přímo na správu frameworku. Mzdové náklady na údržbu tak reprezentují spíše práci programátorů, kteří budou mít případně na starosti integraci (a případně rovnou vývoj) jednotlivých součástí frameworku. V případě, že si firma nevyvine framework sama, tak největší položkou v nákladech na údržbu a provoz frameworku budou pravděpodobně náklady na obnovu licencí softwaru. Co se týče požadavků na velikost oddělení, předpokládával jsem, že zaměstnanců v SQA ve firmě by mělo být tolik, aby se vůbec dali nazývat oddělením tj. alespoň 2. Samozřejmě, i pokud by se ve firmě věnoval SQA jen jeden člověk, tak můžu najít ve zde uvedeném příkladu frameworku užitečné informace, ale s takovouto situací jsem při vytváření frameworku nepočítal. Očekávám, že framework se nejvíce uplatní v odděleních, která mají cca 3 – 7 zaměstnanců, ale žádný horní limit počtu uživatelů nevidím, pokud bude daná firma splňovat definici malé firmy (tj. bude mít méně než 50 zaměstnanců). Výše zmíněné požadavky (včetně požadavku na dodržování softwarové kvality) považuji za dostatečné, v dalších kapitolách tak přejdu přímo k obecnému popisu jednotlivých součástí frameworku.

4.2 Procesy a metodiky V této části se podívám na to, jaké SQA procesy by měl framework pokrývat a na metodiky, které se dají použít jako podklad pro jeho vytvoření. Pro metodologický základ frameworku jsem se rozhodl použít dobře známou metodiku RUP (Rational Unified Process) od firmy IBM a už dříve zmíněný model CMMI. Z RUP si vezmu obecný popis vývojového procesu a pak popisy součástí softwarového testování jako jsou různé nástroje, testy, dokumentace atd. Z CMMI pak použiji popisy procesních oblastí zabývajících se softwarovou kvalitou a zlepšováním relevantních procesů. Zatímco CMMI je volně dostupné, tak metodika RUP je placená a tedy pro menší firmy hůře dostupné. Z tohoto důvodu v samotné případové studii budu operovat s komunitně vyvíjenou 14

metodikou OpenUP, která je i vhodnější pro malé firmy, protože je specificky zaměřená na projekty menšího rozsahu a obsahuje jen ty nejzákladnější informace. RUP je oproti ní velmi robustní a rozsáhlá, její části se ale dají vhodně použít pro doplnění méně popsaných oblastí OpenUP. V této úvodní teoretické části ale popíši základní principy RUP pro ilustraci fungování SQA procesů při vývoji softwaru. Zmíním také, jaké procesní oblasti do SQA spadají podle CMMI.

4.2.1 Metodika RUP a SQA Metodika RUP patří k nejznámějším metodikám pro vývoj software. Nejedná se ovšem o detailní a autoritativní řešení, které by předpisovalo, jak při vývoji postupovat, je to spíše soubor doporučení, návodů a dokumentů, z kterého si mohou vývojářské týmy vybírat pouze to, co považují za relevantní pro svoji práci. Nás bude v případě této metodiky zajímat hlavně její část, která se věnuje testování softwaru, ale podívejme se napřed na její základní principy, ať máme představu, jak vlastně funguje.

4.2.1.1 Základní principy RUP stojí na 6 základních principech (11): •

Přizpůsobování procesu (Adapt the Process) – vývojový proces musí být vždy přizpůsoben velikosti daného projektu, nesmí zde nic chybět ani být navíc. Všechny subprocesy vývojového procesu musí být neustále vylepšovány – po každé vývojové iteraci by měly být dosavadní výsledky zhodnoceny a procesy by měly být podle nich upraveny, tak aby byly ještě efektivnější.

•

Vyvažování protichůdných zákaznických priorit (Balance Competing Stakeholder Priorities) – je třeba neustále vyvažovat požadavky zákazníků a hledat pro ně odpovídající řešení. Tyto požadavky mohou být často protichůdné (např. požadavek na dodání aplikace co nejrychleji vs. nutnost rozsáhlých modifikací aplikace kvůli novým požadavkům zákazníka). RUP v tomto případě zdůrazňuje nutnost prioritizace požadavků zákazníka a znovupoužívání starých softwarových komponent.

•

Spolupráce napříč týmy (Collaborate Across Teams) – tento princip zdůrazňuje nutnost optimálního nastavení komunikace v projektových týmech. Toho je dosaženo vytvořením samořízených

týmů

a

spoluprácí

mezi

zaměstnanci

působících

v různých

oblastech - ve vývoji, businessu atd. •

Iterativní předvádění výsledků (Demonstrate Value Iteratively) – tento princip zdůrazňuje důležitost iterativního vývoje. Aplikace je v něm vyvíjena po částech v několika opakováních

15

(iteracích). Zákazník tak vidí aplikaci několikrát ještě předtím, než dostane hotovou verzi. Je tak schopen upravovat svoje požadavky v průběhu vývoje na základě předvedených výsledků. •

Zvýšení úrovně abstrakce (Elevate Level of Abstraction) – vzhledem k tomu, že současné informační systémy jsou velmi komplexní, je třeba je napřed zachytit na vysoké úrovni abstrakce, kdy jsou v modelech zakresleny napřed jen hlavní komponenty. Tento princip také zdůrazňuje důležitost návrhu architektury – vytvoření modelů by mělo předcházet každému programování.

•

Neustálé zaměření na kvalitu (Focus Continuously On Quality) – aby bylo dosaženo dostatečné kvality softwarového produktu, je třeba se na ni zaměřovat ve všech fázích vývojového procesu. Za kvalitu produktu by měl být zodpovědný celý tým, nejenom testeři. Testy by měly v průběhu vývoje postupně automatizovány. Nás pochopitelně zaujme nejvíce poslední bod, který se přímo týká oblasti SQA, ale v tomto

případě z těchto principů není možné nijak vybírat – pokud má být metodika RUP pro daný projekt použitelná, měly by být principy aplikovány všechny.

4.2.1.2 Životní cyklus Co se týče životního cyklu projektu, tak ten je v metodice RUP rozdělen do 4 fází (11): •

Zahájení (Inception) – v této fázi se zjišťuje, jestli je možné projekt udělat a jsou sbírány a konzultovány první zákaznické požadavky na projeky. Součástí fáze je i vytvoření vize projektu. Fáze je dokončena, když se dodavatel shodne se zákazníkem na vizi, požadavcích, ceně, časovém plánu a případných rizikách projektu.

•

Upřesnění (Elaboration) – v této fázi je navržena architektura systému, podle které se bude v další fázi tento systém vyvíjet. Současné požadavky jsou také upřesňovány a dodatečné požadavky specifikovány. V této fázi jsou vytvořeny i první prototypy komponent systému. Fáze je ukončena, když jsou požadavky, vize a návrh definitivně stabilizovány (tj. zákazník k nim už nemá žádné připomínky); jsou vytvořeny dostatečné iterační plány a byly vytvořeny prototypy komponent, na kterých bylo ověřeno, že hlavní projektová rizika byla ošetřena.

•

Realizace (Construction) – toto je obvykle nejrozsáhlejší fáze, je v ní vyvinuta celá aplikace na základě architektury specifikované v předchozí fázi. V této fázi také probíhá velmi intenzivní testování. Fáze končí, když byl produkt dokončen a otestován a je připraven na předání.

•

Předání (Transition) – v přípravné fázi se ověřuje, že produkt může být předán uživatelům k užívání. Probíhá finální testování, jsou učiněny drobné úpravy v aplikaci na základě 16

připomínek uživatelů a uživatelé jsou zaškoleni. Fáze končí, když zákazník přijme dodávaný produkt. Je třeba si uvědomit, že všechny výše zmíněné fáze probíhají v iteracích tj. každá z nich může proběhnout více než jednou - podle toho, jak je potřeba. Např. fáze Zahájení a Upřesnění mohou proběhnout relativně bezproblémově a rychle ve dvou iteracích, ale ve fázi Realizace bude potřeba velkého množství verzí, než bude produkt dokončen, a tak tato fáze bude potřebovat 9 iterací, než bude dokončena.

4.2.1.3 Disciplíny Všechny úkoly v každé iteraci jsou pak v RUP rozřazeny do jedné z devíti disciplín, každá disciplína reprezentuje určitou oblast vývoje. Disciplíny jsou tyto (11): •

Obchodní modelování (Business Modeling)

•

Požadavky (Requirements)

•

Analýza a design (Analysis and Design)

•

Implementace (Implementation)

•

Testování (Test)

•

Nasazování (Deployement)

•

Řízení změn a konfigurací (Configuration & Change Management)

•

Projektové řízení (Project Management)

•

Prostředí (Environment) Blíže zde jednotlivé disciplíny popisovat nebudu, protože do budoucna pro nás bude hlavně

relevantní jen jedna disciplína a to je Testování. Jakým způsobem se jednotlivé disciplíny podílí na jednotlivých fázích životního cyklu je vidět na následujícím obrázku (Obrázek 1):

17

Obrázek 1 - Disciplíny a fáze v životním cyklu projektu v metodice RUP, zdroj: (11)

Jak je vidět, testování hraje největší roli ve fázi Realizace, ale vstupuje alespoň částečně do všech fází. Podívejme se nyní na tuto disciplínu poněkud detailněji. Co vlastně zahrnuje? Disciplína Testování v metodice RUP není pouze jen o testování, jak by se mohlo zdát z jejího názvu. Zabývá se komplexním zjišťováním a měřením kvality produktu, takže se blíží již výše uvedené definici Software Quality Assurance. RUP ale rozlišuje i koncept nazývaný jako Quality Management, který ale nemá samostatnou disciplínu. Quality Management zdůrazňuje důležitost kontroly kvality v celém životním cyklu projektu a zároveň i ve všech disciplínách. Kvalitu je nutné začít zajišťovat co nejdříve, neboť platí, že čím později je nějaká chyba nalezena, tím větší jsou náklady na její odstranění. Je to dobře vidět na následujícím obrázku (Obrázek 2):

Obrázek 2 - Růst nákladů na odstranění chyby v závislosti na fázi, v které byla tato chyba nalezena, zdroj: (11)

18

Na vertikální ose na Obrázku 2 vidíme náklady na odstranění chyby a na horizontální ose životní cyklus projektu. Čím později je chyba nalezena, tím jsou náklady na její odstranění vyšší – RUP uvádí, že nalezení a oprava chyb je po nasazení aplikace 100 až 1000 nákladnější než před ním (11). Dle RUP by tedy měly být všechny produkty procesů (nazývané jako artefakty - artifacts) otestovány ve chvíli, kdy skončí aktivita, která je vyprodukovala, a zároveň na konci každé iterace. Každý dokončený kus softwaru, který je spustitelný a umožňuje uživatelům vyzkoušet jeho funkcionalitu, by měl být vždy důkladně testován na základě předem definovaných testovacích scénářů. Standardní způsob testování, kdy byla kvalita produktu zjišťována až zcela na konci vývojového cyklu, označuje RUP za chybný a zastaralý.

4.2.1.4 Kvalita v RUP RUP rozlišuje dva odlišné koncepty kvality – kvalitu produktu a kvalitu procesu. Zatímco kvalita produktu se zabývá přímo hodnocením produktu, který je vytvářen v průběhu procesu, tak kvalita procesu se týká kontroly a vylepšování procesů, které k vytvoření produktu vedly. O možnostech zajišťování kvality produktu se budeme dále bavit v části věnované nástrojům podporujících testování. Co se týče kvality procesů, tak jejím řešením v metodice RUP se zde budu zabývat minimálně, ale budu vycházet hlavně z CMMI, která se kvalitě softwarových procesů věnuje v mnohem větší hloubce. Zmiňme si ale ještě, jaké možnosti řízení softwarové kvality RUP vidí v jednotlivých disciplínách mimo disciplínu Testování (11): •

Požadavky – u požadavků je kontrolována jejich konzistence (s ostatními požadavky), jednoznačnost (zda jsou napsány jasně a srozumitelně) a přesnost (zda jsou dostatečně detailní a obsažné).

•

Analýza a design – zahrnuje zkoumání hotového designu, kontrolu konzistence mezi jednotlivými částmi modelu a kontrolu návaznosti na odpovídající požadavky a implementační artefakty.

•

Implementace – zahrnuje kontrolu implementačních artefaktů (např. softwarové komponenty, technická dokumentace…) a ověřování zdrojového kódu a spustitelných artefaktů proti odpovídajícím požadavkům, modelu designu a testovacím artefaktům (např. testovaným případům).

•

Prostředí – zahrnuje nastavení procesů v prostředí tak, aby co nejlépe splňovaly požadavky na kvalitu.

•

Nasazení – zahrnuje kontrolu nasazené aplikace a zkoumání nasazených spustitelných souborů proti požadavkům, modelu designu a testovacím artefaktům, které mají zajistit, že produkt bude možné dodat zákazníkovi. 19

•

Projektový management – zahrnuje shrnutí většiny činností pro řízení kvality a její součástí jsou např. audity, reporty, zhodnocení atd. Vraťme se ještě nyní k disciplíně, která je dle RUP pro řízení kvality nejzásadnější - Testování.

Hlavním cílem testování je zajištění výše zmíněné kvality produktu, kvalita procesů už spadá spíše pod ostatní disciplíny. RUP vidí těchto 5 hlavních praktik, které dohromady tvoří testování (11): •

Nalézt a zdokumentovat chyby v softwaru.

•

Podávat rady a informace ohledně zjištěné softwarové kvality.

•

Validovat a ověřit předpoklady o softwaru vytvořené na základě specifikací v designovém modelu a požadavcích a to pomocí konkrétního předvedení softwaru.

•

Ověřit, že softwarový produkt funguje tak, jak byl navržen.

•

Ověřit, že požadavky byly vhodně naimplementovány. Výše zmíněné praktiky zní poměrně jasně, přesto z nich ale evidentně nevyplývá, jaké

konkrétní činnosti musí členové SQA oddělení v průběhu testování vlastně provádět. RUP proto definuje 6 konkrétních úkolů týkajících se testování, které se dále rozkládají na dílčí podúkoly. Hlavní úkoly jsou tyto: •

Zhodnotit a prosazovat kvalitu (Assess and Advocate Quality) – zahrnuje identifikování a prosazování řešení chyb, které mají významný vliv na kvalitu softwaru. Patří sem i monitorování a podporování změn, které mají zlepšit softwarovou kvalitu, tak aby dosáhla požadované úrovně.

•

Definovat přístup k testování (Define Test Approach) – zahrnuje definování testovací strategie a technik, které během ní budou použity. Patří sem i příprava architektury pro automatizaci testování.

•

Určit výsledky testů (Determine Test Results) – do tohoto úkolu spadá zaznamenávání výsledků testů a návrh opravných akcí, které mají vyřešit nalezené chyby.

•

Spustit skupinu testů (Execute Test Suite) – do tohoto úkolu patří spuštění odpovídajících skupin testů a zachycení jejich výsledků.

•

Identifikovat testovací nápady (Identify Test Ideas) – během tohoto úkolu jsou identifikovány relevantní testovací nápady, které ukazují možnosti, jak aplikaci testovat.

•

Implementovat skupiny testů (Implement Test Suite) – do tohoto úkolu spadá vytvoření testovacích skupin – zjišťuje se, které testy by bylo vhodné spouštět pohromadě.

20

•

Strukturovat implementaci testů (Structure the Test Implementation) – definuje se zde struktura,v které budou implementovány testovací skupiny. Zjišťuje se, jaké testovací skupiny budou použity, jaké testovací nástroje je třeba použít a jaká organizační struktura musí být v týmu vytvořena, aby testování bylo efektivní. Dále se už kvalitě procesů z hlediska RUP zabývat nebudu, tato oblast bude řešena podrobněji

v další kapitole a to z hlediska CMMI. K metodice RUP se ještě vrátíme v kapitole věnované způsobům testování a testovacím nástrojům.

4.2.1.5 Využití RUP v případové studii Jak již jsem se zmínil, v případové studii budu brát jako hlavní zastřešující metodiku OpenUP – odlehčenou verzi RUP. Principy a poznatky získané z RUP budu ale při vytváření frameworku stále používat – tato metodika obsahuje množství rad, návodů, šablon atd., které se dají při řízení kvality softwaru využít. Pokud bude některá část frameworku pocházet z RUP, tak to vždy v dané části zmíním. Mým cílem je vybrat pouze to, co pomůže k vylepšení řízení softwarové kvality speciálně malým firmám, aniž by byly tyto firmy nuceny celý RUP zakoupit – tato investice by pro mnohé z nich byla zbytečnou, protože by mnoho z obsahu vůbec nevyužily.

4.2.2 CMMI a SQA Model CMMI je modelem pro zlepšování kvality procesů v oblasti vývoje produktů a služeb. Shrnuje znalosti týkající se vývojových a udržovacích činností, které pokrývají životní cyklus produktu od jeho návrhu až jeho vytvoření a následné údržbě. CMMI je v současnosti vytvářen organizací Carnegie Mellon Software Engineering Institute [3] a jeho poslední verzí (z které jsem čerpal) je CMMI for Development, Version 1.2. Ačkoli byl model CMMI původně určen hlavně pro oblast vývoje software, tak v současnosti je natolik univerzální a abstraktní, že je použitelný pro procesy v mnoha různých oblastech – tedy za předpokladu, že se tyto procesy zabývají vývojem produktů a služeb.

4.2.2.1 Základní koncepty CMMI Zásadním konceptem modelu CMMI jsou tzv. úrovně zralosti (maturity) a způsobilosti (capability). Úrovně způsobilosti měří zlepšování procesů v jednotlivých procesních skupinách. Tyto úrovně slouží ke zlepšení procesů odpovídajících této jedné vybrané procesní oblasti. Naproti tomu úrovně zralosti měří zlepšování procesů v rámci několika různých procesních skupin. Tyto úrovně se pak dají použít k předvídání výsledků projektů, které se těchto procesních oblastí týkají.

21

Úrovně zralosti jsou tyto: 1. Počáteční (Initial) – procesy jsou neřízené a chaotické. Organizace neposkytuje žádné stabilní prostředí, které by tyto procesy podporovalo. 2. Řízený (Managed) – procesy jsou prováděny na základě nějakých předpisů. Projekty v organizaci jedou podle plánů zanesených v dokumentaci. 3. Definovaný (Defined) – procesy jsou dobře popsány ve standardech, procedurách, nástrojích a metodách. Je vytvořen soubor standardních procesů společnosti a tento soubor je postupně vylepšován. Procesy pro daný projekt jsou odvozeny z procesů v tomto standardizovaném souboru. 4. Kvantitativně řízený (Quantitatively Managed) – organizace si na této úrovni vytvoří kvantitativní cíle pro měření kvality a výkonu procesů a používá je při jejich řízení. Výsledky z měření procesů jsou shromažďovány a statisticky analyzovány. 5. Optimalizovaný (Optimizing) – na této úrovni používá organizace výsledky měření procesů k hledání důvodů výkyvů ve výkonu jednotlivých firemních procesů a snaží se pak tyto procesy vylepšovat, aby dosáhla předem definovaných kvantitativních cílů zlepšení. Cílem je procesy co nejvíce vylepšit – optimalizovat. Úrovní způsobilosti je 6: 0. Nekompletní (Incomplete) – proces není vykonáván vůbec nebo jen částečně. 1. Prováděný (Performed) – tento proces splňuje základní cíle procesní skupiny a zajišťuje vytvoření potřebných produktů. 2. Řízený (Managed) – proces je prováděn na základě nějakého předpisu. Disponuje základní infrastrukturou, která tento proces podporuje. 3. Definovaný (Defined) – je proces, který byl vytvořen na základě souboru standardních procesů společnosti a je prováděn podle návodů platných globálně pro procesy tohoto typu. Na rozdíl od úrovně jsou tak všechny instance tohoto procesu v podstatě stejné. 4. Kvantitativně řízený (Quantitatively Managed) – jedná se v podstatě o proces úrovně 3, který ale kontrolován a měřen pomocí statistických a jiných kvantitativních technik. Jsou vytvořena kvantitativní kritéria pro měření procesu. 5. Optimalizovaný (Optimizing) – jedná se o kvantitativně měřený proces, který byl vylepšován díky znalosti důvodů výkyvů v tomto procesu. Je snaha tento výkon tohoto procesy neustále vylepšovat a optimalizovat pomocí různých metod. 22

Už dříve jsem zmínil, že model CMMI je velmi rozsáhlý – jeho hlavní dokument má 573 stránek a obsahuje popis celkem 16 různorodých procesních oblastí [3]. Vzhledem k tomu, že ne všechny tyto oblasti jsou relevantní pro procesy, které spadají pod oblast SQA, vyberu z nich jen některé, které dále popíši. Vybraným procesům se nebudu věnovat zcela do detailu, protože nejsou hlavním předmětem frameworku, ale pouze jeho součástí. Vždy ale uvedu stručný popis procesu a zmíním postupy, které jsou v něm obsaženy, přičemž případně zdůrazním, které části procesu jsou pro SQA framework obzvláště relevantní. Z procesních oblastí obsažených v CMMI verze 1.2 jsem vybral celkem 7, které dle mého názoru nejvíce ovlivňují SQA. Jedná se o tyto oblasti (3)3: •

Kauzální analýza a řešení (Causal Analysis and Resolution)

•

Kvantitativní projektový management (Quantitative Project Management)

•

Řízení rizik (Risk Management)

•

Verifikace (Verification)

•

Validace (Validation)

•

Zajištění kvality procesu a produktu (Process and Product Quality Assurance)

•

Měření a analýza (Measurement and Analysis )

Existuje i několik oblastí, které se kvalitou přímo nezabývají, ale nějakým způsobem s ní souvisí: •

Tvorba požadavků (Requirements Development)

•

Integrace produktu (Product Integration)

•

Technické řešení (Technical Solution)

Vybrané procesní oblasti stručně popíši v následujících kapitolách.

4.2.2.2 Kauzální analýza a řešení Cílem kauzální analýzy a řešení (CAR) je identifikovat příčiny chyb a dalších problémů provést opatření, která zabraní jejich dalšímu výskytu v budoucnosti (3). Oblast CAR zlepšuje kvalitu a produktivitu tím, že se specificky zaměřuje na prevenci vzniku chyb v produktu. Aby mohla být efektivní, musí zasahovat do každé fáze projektu – spoléhat se na odhalování až poté, co k nim došlo, není cenově efektivní. Tato procesní oblast by měla fungovat jako mechanismus, který bude předávat zkušenosti mezi projekty – pokud se např. na některém projektu vyskytne nějaký druh defektu, který

3

Autorem českých překladů jsem já sám.

23

se mohl opakovat i jinde, měly by být o tom okamžitě informování vedoucí ostatních projektů, aby mohli zavést preventivní opatření. Kauzální analýza se může týkat různých problémů, nemusí se jednat jen o chyby v produktu. Může být použita třeba k tomu, aby zlepšila nějaký atribut kvality projektu – takovým atributem může být např. čas, který trvá nějaký cyklus v projektu. Všechna vylepšení, která byla pomocí CAR vytvořena a zhodnocena jako efektivní, by měla být předána dále – na organizační úroveň, tak aby z vylepšení mohly těžit všechny projekty v organizaci. CAR má 2 hlavní specifické cíle (SG) a 5 postupů (SP): •

SG 1 – Zjistit příčinu chyb – cílem je zjistit, jaké jsou hlubší příčiny chyb, které se na produktu vyskytly o SP 1.1 – Sebrat data pro analýzu o SP 1.2 – Zjistit příčiny

•

SG 2 – Řešit příčiny chyb – cílem je řešit příčiny chyb tak, aby se už dále nevyskytovaly o SP 2.1 – Implementovat návrhy zlepšení o SP 2.2 – Zhodnotit výsledky změn o SP 2.3 – Zaznamenat data

4.2.2.3 Kvantitativní projektový management Cílem kvantitativního projektového managementu (QPM) je zajistit předem danou kvalitu projektu a splnit cíle kladené na výkonnost procesu. Tato oblast se také zabývá identifikací subprocesů, průběžným monitorováním projektu z hlediska naplňování jeho cílů, výběru metrik a analytických technik sloužících k statistickému měření procesů. Výkon procesu je měřen aktuálními výsledky projektu, které mohou být buď procesního (délka cyklu, rychlost při odstraňování chyb) nebo produktového charakteru (hustota chyb, čas odezvy atd.). QPM má 2 hlavní specifické cíle (SG) a 8 postupů (SP): •

SG 1 – Kvantitativně řídit projekt o SP 1.1 – Vytvořit cíle projektu o SP 1.2 – Složit definovaný proces o SP 1.3 – Vybrat statisticky řízené subprocesy o SP 1.4 – Řízení výkonů projektu 24

•

SG 2 – Statisticky řídit výkon subprocesů o SP 2.1 – Výběr metrik a analytických technik o SP 2.2 – Aplikovat statistické metody o SP 2.3 – Monitorovat výkonnost o SP 2.4 – Zaznamenávat statistická data

4.2.2.4 Řízení rizik Cílem řízení rizik (RSKM) je identifikovat potenciální problémy ještě předtím, než k nim dojde. Aktivity sloužící k řešení rizik tak mohou být plánovány dopředu a poté podle potřeby využívány v průběhu životního cyklu produktu/projektu. Řízení rizik je kontinuální proces, který se snaží primárně identifikovat problémy, které by mohly ohrozit kritické cíle projektu. Rizika musí být vždy identifikována dopředu za účasti co největšího množství stran zainteresovaných na projektu. Předběžná identifikace rizik je obvykle lehčí a méně nákladná než řešení rizik v pozdějších fázích projektu. RSKM má 3 hlavní specifické cíle (SG) a 7 postupů (SP): •

SG 1 – Příprava na řízení rizik o SP 1.1 – Určení zdrojů rizik a kategorií o SP 1.2 – Definice parametrů rizik o SP 1.3 – Vytvoření strategie řízení rizik

•

SG 2 – Identifikovat a analyzovat rizika o SP 2.1 – Identifikovat rizika o SP 2.2 – Zhodnotit, kategorizovat a prioritizovat rizika

•

SG 3 – Snížit rizika o SP 3.1 – Vytvořit plán snížení rizik o SP 3.2 – Implementace plánu snížení rizik

4.2.2.5 Verifikace Cílem verifikace (VER) je zajistit, že dané produkty odpovídají specifickým požadavkům. Verifikace zahrnuje verifikaci finálního produktu i jednotlivých meziproduktů. Verifikace probíhá v průběhu celého životního cyklu – začíná se už verifikací samotných požadavků na produkt. 25

RSKM má 3 hlavní specifické cíle (SG) a 7 postupů (SP): •

SG 1 – Příprava na verifikaci o SP 1.1 – Výběr pracovních produktů k verifikaci o SP 1.2 – Tvorba verifikačního prostředí o SP 1.3 – Tvorba verifikačních procedur a kritérií

•

SG 2 – Vytvoření posudků o SP 2.1 – Příprava na posudky o SP 2.2 – Provádění posudků o SP 2.3 – Analýza dat posudků

•

SG 3 – Ověření vybraných pracovních produktů o SP 3.1 – Provedení verifikace o SP 3.2 – Analýza výsledků verifikace

4.2.2.6 Validace Cílem validace (VAL) je zajistit, že produkt nebo jeho komponenty splňují svůj zamýšlený účel. Pokud jsou umístěny do zamýšleného prostředí. Validace může být aplikována u všech aspektů produktu ve všech jeho zamýšlených prostředích: provozování, školeních, podpoře atd. VAL má 2 hlavní specifické cíle (SG) a 5 postupů (SP): •

SG 1 – Připravit na validaci o SP 1.1 – Vybrat produkty k validaci o SP 1.2 – Vytvořit validační prostředí o SP 1.3 – Tvorba validačních procedur a kritérií

•

SG 2 – Validace produktů nebo produktových komponent o SP 2.1 – Provést validaci o SP 2.2 – Analyzovat validační výsledky

26

4.2.2.7 Zajištění kvality procesu a produktu Cílem oblasti Zajištění kvality procesu a produktu (PPQA) je zprostředkovat managamentu a dalším zaměstnancům podrobný pohled na procesy a jejich produkty. Zahrnuje hodnocení prováděných procesů v návaznosti na použitelné standardy a procedury a identifikaci a dokumentaci problémů. Verifikace zahrnuje verifikaci finálního produktu i jednotlivých meziproduktů. Verifikace probíhá v průběhu celého životního cyklu – začíná se už s verifikací samotných požadavků na produkt. Manažeři a další zainteresované osoby pak dostávají k dispozici podrobné reporty o kvalitě procesů a jejich produktů. PPQA má 2 hlavní specifické cíle (SG) a 4 postupy (SP): •

SG 1 – Objektivní zhodnocení procesů a jejich produktů o SP 1.1 – Zhodnocení procesů o SP 1.2 – Zhodnocení produktů procesů a služeb

•

SG 2 – Zprostředkovat objektivní pohled o SP 2.1 – Reportovat nalezené problémy o SP 2.2 – Vytvořit záznamy

4.2.2.8 Měření a analýza Cílem měření a analýzy (MA) je vyvinout a udržovat možnosti měření, tak aby podporovaly informační potřeby managementu. Oblast zahrnuje specifikaci metrik, analytických technik, metod sběru dat a reportingu atd. Možnosti měření a reportingu mohou ze začátku fungovat na úrovni projektu, ale mohou se týkat i celé organizace. RSKM má 2 hlavní specifické cíle (SG) a 8 postupů (SP): •

SG 1 – Propojit měřící a analytické aktivity o SP 1.1 – Vytvořit cíle měření o SP 1.2 – Specifikovat metriky o SP 1.3 – Specifikovat procedury ukládání a sběru dat o SP 1.4 – Specifikovat analytické procedury

•

SG 2 – Dodat výsledky měření 27

o SP 2.1 – Shromáždit naměřená data o SP 2.2 – Analyzovat naměřená data o SP 2.3 – Uložit data a výsledky o SP 2.4 – Sdělit výsledky

4.2.2.9 Využití CMMI v případové studii Podobně jako v případě metodiky RUP platí, že CMMI je opět velmi robustní záležitostí – jak již jsem zmínil, jeho poslední verze má 573 stránek. Narážíme tu tedy opět na podobný problém jako v případě RUP – model CMMI je velmi vhodný pro řízení kvality vývojových procesů, ale při jeho kompletní implementaci hrozí, že by se pod vahou všech opatření sloužících k zlepšení kvality ve firmě tato firma paradoxně zhroutila. Proto budu opět vybírat z CMMI jen části, které jsou relevantní pro oblast malých firem a poznatky z nich z těchto částí využiji při tvorbě frameworku v případové studii. Které procesní disciplíny nejvíce SQA ovlivňují (a tedy budou mít nejpravděpodobněji i použití při tvorbě frameworku) jsem už zmínil v předchozí kapitole. Mohlo by se zdát, že reálné možnosti využití CMMI v malých firmách budou malé, vzhledem k tomu, že původně byl zamřen na větší organizace, ale práce Thoughts on Applying CMMI in Small Settings [12] a Lessons Learned from Adopting CMMI for Small Organziations [13] tvrdí opak. Tyto studie jsou volně dostupné na webu Carnegie Mellon Software Engineering Institute a ukazují příklady použití v malých organizacích. Docházejí k závěrům, že ač zavedení CMMI v menším prostředí může být ze začátku pro manažery velkou výzvou, tak malé firmy mají určité výhody, které mohou samotné zavádění naopak ulehčit – zaměstnanci v malých firmách jsou flexibilnější, náklady na zaškolení jsou nižší, lépe se nastavují metriky atd. [13].

5 Návrh frameworku V této části se budu konečně zabývat konkrétními součástmi frameworku a jejich implementací. Napřed popíši proces vývoje produktu dle OpenUP a identifikuji ty oblasti, které spadají pod působnost firemního SQA. Dále pak budu popisovat jednotlivé oblasti, a jak je bude mnou navržený framework podporovat. Oblasti budou vycházet nejen z OpenUP ale i z CMMI, pokusím se v každé z nich najít průnik obou těchto modelů. Stručný popis procesních oblastí z hlediska plné verze CMMI se už nacházel v předchozích kapitolách. V průběhu popisu se budu zmiňovat, jak ta která část do frameworku zapadá a jaké jsou její vazby na ostatní komponenty. V dalších kapitolách je pak možné nalézt případovou studii ve firmě, 28

která právě takovýto framework implementuje, a ve které se zmíním i o tom, na jaké problémy jsem při jeho implementaci narazil. V průběhu popisu se budou prolínat informace, které jsem načerpal z OpenUP, CMMI a dalších zdrojů, s informacemi, které jsem dodal já sám na základě mých pracovních zkušeností v oblasti SQA (tyto zkušenosti jsou pak více rozepsány v případové studii). Vzhledem k tomuto prolnutí ale nemusí vždy být jasně patrné, co je mým vlastním přínosem a co je převzato. Na konci návrhu frameworku jsem tedy ještě vložil tabulku, která shrnuje moje části, jež jsem vytvořil zcela sám.

5.1 OpenUP a proces vývoje V teoretické úvodní části jsem zmínil, že jako metodický základ pro framework použiji metodiku OpenUP [14]. OpenUP je projektem nadace Eclipse Foundation4, který je vyvíjen formou open source tj. pracuje na něm široká komunita lidí a jeho text je volně dostupný a volně upravitelný. OpenUp vychází z metodiky RUP (resp. Unified Process, na kterém je RUP založen), ale představuje jeho výrazně zredukovanou verzi, která má plně pokrýt potřeby malých softwarových firem. OpenUP se podobně jako RUP zabývá celým vývojovým procesem, tj. říká jakým způsobem získat požadavky na produkt, jak navrhnout, vytvořit a dodat. Jaké je umístění metodiky OpenUp v celém frameworku? OpenUP je v podstatě jeho jádrem, říká nám, jak na sebe jednotlivé procesy navazují, a podává rady, jak tyto procesy řídit a zajišťovat jejich kvalitu. Pochopitelně ne všechny popisy obsažené v OpenUP jsou naše účely dostatečně rozsáhlé, proto některé z nich doplňuji popisy přímo z metodiky RUP. OpenUp říká hlavně, jak by měla situace vypadat a už se tolik nezabývá tím, jak existující procesy zlepšit, a proto v dalších kapitolách využijeme i některé znalosti načerpané z CMMI.

5.1.1 Základní principy OpenUP je metodikou založenou na unifikovaném procesu, která ve svém životním cyklu využívá iterativní a inkrementální přístup [14]. OpenUP je založen na čtyřech vzájemně se podporujících principech, které jsou podobné jako principy RUPu: •

Vyvažování protichůdných zákaznických priorit (Balance competing priorities to maximize stakeholder value) – je třeba neustále vyvažovat požadavky zákazníků a hledat pro ně

4

Eclipse Foundation, http://www.eclipse.org/

29

odpovídající řešení. Zákazníci i členové projektového týmu musí dospět k dohodě na těchto třech základních faktorech: řešeném problému, omezeními vývojářského týmu (zdroje, náklady atd.) a omezeními kladenými na produkt. Doporučované postupy, kterými je možno dosáhnout tohoto cíle jsou tyto: oddělit problém od řešení (co zákazník chce vs. co systém musí dělat), zajistit společné porozumění řešené oblasti (pomocí vize a společného slovníku) a používání případů užití (use cases) pro zmapování požadavků. •

Spolupráce za účelem vzájemného porozumění (Collaborate to align interests and share understanding) – je důležité zajišťovat dobré pracovní prostředí, ve kterém se nevyskytují možné překážky komunikace. Tento princip zdůrazňuje sdílení odpovědnosti mezi členy týmu a neustálé společné poznávání a učení.

•

Zaměřit se na architekturu od začátku (Focus on the architecture early to minimize risks and organize development) – podrobná architektura systému musí být vytvářena už od samého začátku, jinak bude systém vznikat chaoticky. Aby byli lidé schopni pochopit složitý systém, je třeba pracovat s úrovněmi abstrakce – vytvořit např. model požadavků, z kterého se dá dostat až na nejnižší úroveň modelu tříd.

•

Evoluce za účelem zisku zpětné vazby (Evolve to continuously obtain feedback and improve) – je důležité, aby projektový tým získával zpětnou vazbu od zákazníka v průběhu celého projektu a ne až na jeho konci. Doporučované postupy, kterými je možno dosáhnout tohoto cíle jsou tyto: důsledné využívání iterací, na jejichž konci následuje vyjádření zákazníka; zavést řízení rizik a připravení strategií jejich řešení, měření postupu projektu pomocí iterací a případných dalších metrik atd.

Jak vlastně vypadá vztah jednotlivých vrstev OpenUP je vidět na následujícím obrázku (Obrázek 4):

30

Obrázek 3 - Vrstvy OpenUP, zdroj: (14)

Práce prováděná účastníky na projektu v OpenUP je rozdělena do tzv. mikro-inkrementů. Tyto mikro-inkrementy reprezentují malé jednotky práce, které dohromady umožňují sledovat postupný pokrok ve vývoji projektu. Práce na jednom mikro-inkrementu obvykle zabere několik hodin až dní. Celý projekt je pak rozdělen do iterací, což jsou ohraničené časové úseky (obvykle v délce několika týdnů), na jejichž konci je zákazníkům dodán nebo předveden použitelný kus softwaru. V plánu každé iterace je přesně definováno, co má být oddáno na jejím konci. Týmy, které pracují na jedné iteraci podle OpenUP, si sami rozdělují práci a určují si, jak přesně dosáhnout cílů iterace Celkový vývoj projektu je pak sledován pomocí projektového plánu přes čtyři projektové fáze. Tyto fáze jsou stejné jako v RUP – tj. Zahájení (Inception), Upřesnění (Elaboration), Realizace (Construction) a předání (Transition). Cílem této práce je navrhnout framework, který se zabývá podporou řízení pouze softwarové kvality a nikoli celého projektu, proto zde nebudu detailně popisovat, jak použít OpenUP v rámci celého vývoje. V další kapitole však stručně popíši, v kterých fázích projektu je nutné kvalitu řídit a jakým způsobem. Zmíním se, i jaká je v dané fázi role QA oddělení.

31

5.1.2 Role SQA ve fázích projektu Úvodní vize Jak jsem již několikrát zmínil, SQA se musí prolínat všemi fázemi projektu, a proto je důležité, aby se členové QA oddělení podíleli na projektu už v samém jeho začátku. Úvodními dokumenty, které by měly být vytvořeny na začátku každého projektu, jsou dle OpenUP vize (Vision) a slovník (Glossary). Už v této fázi by měli být členové QA seznámeni s těmito dokumenty a měli by mít také možnost je zkontrolovat a nahlásit nalezené problémy, i když budou třeba jen stylistického charakteru. Pokud by testeři a další členové QA tento dokument neznali, tak by hrozilo, že by už v samém počátku ztratili s projektem kontakt a nebyli by poté schopni najít s ostatními členy projektového týmu společnou řeč. Znalost vize je pro QA důležitá i z toho důvodu, že umožňuje poznat na několika stránkách účel projektu a základní požadavky zákazníka. I nepříliš kvalifikovaný tester tak z ní pozná, k čemu má aplikace sloužit a co má tedy primárně testovat. Seznam rizik Po vizi a slovníku následuje vytváření iteračního plánu (Iteration Plan), seznamu rizik (Risk List) a seznamu pracovních položek (Work Items List). Nejdůležitější z hlediska SQA je seznam rizik, jehož vytvoření by mělo z velké části být zodpovědností manažera kvality. Tento seznam obsahuje rizika, která projektu hrozí v jeho průběhu. Na základě tohoto seznamu je pak možné lépe odhadnout, jak bude projekt náročný a drahý a jaké zkušenosti musí mít lidé, kteří na něm budou pracovat. Seznamu rizik se budu dopodrobna věnovat v kapitole Řízení rizik. Požadavky Ve fázi zahájení jsou také dokumentovány požadavky na vyvíjenou aplikaci. Tato fáze patří k jedné z nejdůležitějších, protože pokud během ní dojde k nepochopení mezi zákazníkem a řešitelem, tak mohou v důsledku toho vytvořit vývojáři velkou část aplikace zcela zbytečně. OpenUP doporučuje zapisovat požadavky formou uživatelských případů tzv. use cases, které představují sled kroků popisujících reakci systému na vnější podněty (např. stisknutí tlačítka). Sepsání uživatelských případů je z hlediska SQA velmi důležité, protože tyto potom budou dále sloužit jako podklad pro testované případy tzv. test cases. Testované případy totiž detailně popisují, jak otestovat některou část funkcionality aplikace. Dle OpenUP by měly být testované případy vytvářeny zároveň s uživatelskými případy a poté doplňovány a rozšiřovány. Díky tomu mohou testeři začít aplikaci testovat, jakmile vývojáři vytvoří první spustitelný kód. Uživatelské a testované případy jsou velmi významnou složkou SQA ve firmě a tedy i našeho frameworku, a proto jim budou dále věnovat samostatnou kapitolu. 32

Požadavky popsané v OpenUP mají návaznost i na CMMI, které se řízení požadavků věnuje v kapitolách Requirements Management (tj. Správa požadavků) a Requirements Development (tj. Vytváření požadavků). Pro SQA je ale nejvýznamnější CMMI oblast Verifikace (Verification), která popisuje, jak vhodně ověřovat, že vytvořený produkt odpovídá požadavkům zákazníka. Ověřování by mělo pochopitelně probíhat ve všech fázích projektu a hlavní zodpovědnost za něj opět nese firemní QA oddělení. Návrh, vývoj a testování Po sepsání požadavků by mělo začít vytváření architektury systému. Architektura popisuje strukturu systému po technické stránce: návrh modulů systému, datový model, hardwarovou infrastrukturu atd. Testeři většinou do tvorby architektury nevstupují, ale i tak je pro ně důležitá. Řeší se v ní totiž také např.: jaká bude testovací infrastruktura systému, kde poběží testovací verze aplikace a jak se k ní bude přistupovat. Poté, co je dokončen návrh architektury, je možné začít se samotným vývojem systému. Vývoj obvykle zabere ze všech procesů nejvíce času a podílí se na něm nejvíce lidí. V průběhu vývoje by si už sami vývojáři měli psát testy, které je pak možné spouštět proti jednotlivým částem kódu – tzv. unit testy a integrační testy. Jak již bylo řečeno výše, vývoj probíhá v iteracích a na konci každé iterace by měla být vytvořena část aplikace, kterou je možné ukázat zákazníkovi. Před jakýmkoli předvedením by aplikace měla být testery manuálně otestována – toto testovaní je jednou z hlavních náplní práce SQA oddělení ve firmě. Testovat lze různými způsoby – testovat kvalitu uživatelského rozhraní, testovat zátěž, testovat zabezpečení aplikace atd. O různých druzích testování si blíže povíme v samostatné kapitole. Dokumentace a předání V průběhu vývoje je třeba psát uživatelskou a technickou dokumentaci, která je pak finalizována a předávána zároveň s produktem. Technickou dokumentaci budou testeři pravděpodobně zkoumat pouze ze stylistického hlediska, ale na uživatelské dokumentaci už by se měli podílet od samého začátku, protože znají aplikace po uživatelské stránce pravděpodobně nejlépe. Projektový management Po celou dobu vývoje má nad projektem dohled projektový manažer, který ho řídí. K řízení využívá v první řadě plán projektu (Project Plan) a iterační plán (Iteration Plan), důležitý je pro něj i seznam rizik a pracovních položek. I na oblast projektového managementu má SQA velký vliv. Projektový manažer potřebuje co nejvíce informací o fungování projektu, aby ho mohl správně řídit, a právě vhodný SQA framework mu umožní dodat tyto informace – kdo na čem strávil kolik času, jakou měla tato práce chybovost, jaká je současná kvalita produktu, dochází k zlepšování nebo zhoršování 33

této kvality atd. Aby byl projektový manažer schopen tyto informace získat, musí spolupracovat s firemním manažerem kvality a zároveň disponovat nástroji, které mu tyto informace dodají.

5.2 Řízení rizik Dle OpenUP je riziko: „nejistá událost nebo okolnost, která, pokud k ní dojde, bude mít negativní nebo pozitivní efekt na jeden nebo více projektových cílů“ [14]. Na rizika se tedy dá nahlížet jako na hrozby nebo příležitosti. Já se v tomto případě budu zabývat hlavně tradičním řešením rizik coby hrozeb, příležitosti, které se mohou náhle vyskytnout, obvykle řeší jiná oddělení než SQA.

5.2.1 Seznam rizik Uvědomění si rizik, které projektu hrozí, je důležitým předpokladem správného řízení kvality. Pokud víme, jaké problémy se mohou na projektu vyskytnout, jsme schopni si dopředu připravit plány na vyrovnání se s těmito problémy a nejsme pak v případě jejich výskytu zaskočeni. Je třeba ale zabývat se řízením rizik nejen na projektové úrovni, ale i na úrovni celé firmy. V takovém případě se pokoušíme řídit rizika na všech projektech najednou a zaměřujeme se na jejich společné vlastnosti. Řízení rizik na úrovni firmy je více rozepsáno v kapitole Risk Management v CMMI [3]. Dle OpenUP je zásadním dokumentem při řízení rizik na projektu seznam rizik. Zavedení tohoto dokumentu bych také doporučil každé menší firmě jako jeden z prvních kroků při zavádění SQA frameworku. Seznam rizik může být opravdu i relativně jednoduchý seznam, který hodnotí rizika podle několika kritérií. Takovými kritérii mohou být [11] [14]: •

Důsledky (Impacts) – co se stane, pokud k riziku dojde.

•

Indikátory (Indicators) – co indikuje, že se riziko naplňuje.

•

Dopad (Impact) – jak velký je dopad daného rizika. Zapisuje se jako číselná škála.

•

Závažnost (Magnitude) – jak je dané riziko závažné. Jedná se o číslo, které vznikne vynásobením dopadu a pravděpodobnosti.

•

Preventivní strategie (Mitigation strategy) – jak zabránit výskytu rizika.

•

Pravděpodobnost (Probability) – jak je dané riziko pravděpodobné. Dá se zapsat jako procentuální pravděpodobnost, vytvoření takovéhoto čísla je ale velmi obtížné – k přesnější hodnotě je možné se dobrat jen při prozkoumání starších projektů a jejich rizik.

•

Typ (Type) – zda se jedná o přímé nebo nepřímé riziko. Nad přímým rizikem má projekt kontrolu, zatímco nepřímé riziko kontrolovat nemůže (např. krach dodavatele). 34

•

Kategorie (Category) – kategorie, do které se dá riziko zařadit (např. technologické riziko).

Popis každého rizika by měl dále obsahovat datum, kdy bylo riziko identifikováno; jeho název a popis. Co se týče rizik, dají se tato rozdělit do několika skupin, podle toho, čeho se týkají: •

Organizační – např. neexistence vhodných procesů atd.

•

Finanční - nedostatek financí, nepřesné cenové odhady atd.

•

Lidé – nedostatek lidí, členové týmu se vzájemně neznají, nedostatek zkušeností projektového týmu atd.

•

Čas – časové odhady nejsou realistické, určité datum v projektu je kritické atd.

•

Obchodní rizika – konkurence dokončí svůj produkt dříve, dodavatelé nebudou spolupracovat atd.

•

Technologická rizika – nová technologie, zatížení systému bude příliš velké, systém je svislý na externích systémech atd. CMMI zdůrazňuje důležitost rozdělování rizik do skupin a tvorbu kategorií, pokud je to

možné – pro podobná rizika se totiž pak dá vytvořit společná preventivní strategie (3). Podívejme se nyní, jak postupovat při vyhledávání rizik dle RUP (11): 1) Sestavení týmu – na vytváření seznamu rizik by měl spolupracovat celý projektový tým. Z mých zkušeností ale vyplynulo, že tohle není vždy možné. V menších firmách často zaměstnanci pracují na více projektech a bývají často relokováni na jiné projekty velmi náhle. Proto se často ve fázi vytváření seznamu rizik nedá spolehnout, že všichni tehdejší účastníci se na projektu budou později opravdu podílet. Jako nejdůležitější osoby, které by se tvorby plánu měly účastnit, tak vidím projektového manažera, manažera kvality, technického vedoucího, konzultanta/analytika a případně osoby, které mají hlubší znalost technologií nebo procesů, které mohou projekt ovlivnit. 2) Identifikace potenciálních rizik a zdrojů rizik – Při vyhledávaní rizik by se členové měli zamyslet nad tím, co všechno se může během projektu zkazit. Takový list by samozřejmě mohl být velmi široký, je tedy třeba zaměřit se hlavně na ta rizika, u kterých výrazně hrozí, že zabrání vytvoření produktu s těmi správnými vlastnostmi, s odpovídající kvalitou, včas a/nebo se správným rozpočtem. Rizika je vhodné hledat metodou brainstormingu, tj. členové napřed vygenerují nápady a teprve, když jsou všechny nápady zapsány, tak se hodnotí, kategorizují a prioritizují. RUP nedoporučuje, kde přesně máme rizika vyhledávat, ale seznam možných zdrojů rizik najdeme v CMMI [3]: a) Nejasné požadavky. 35

b) Nedostatečné odhady pracnosti. c) Nereálný design. d) Nepřístupná technologie. e) Nereálné termíny. f) Nedostatečné množství lidí na projektu a jejich nedostatečné znalosti. g) Nedostatečný rozpočet. h) Nedostatečná součinnost dodavatele. 3) Analýza a prioritizování rizik – V této fázi členové týmu sloučí rizika do kategorií a nastaví jim prioritu. Pro nastavení priority se používají kritéria pravděpodobnosti a dopadu rizika, z nichž je vypočítána celková závažnost. Podle závažnosti pak můžeme rizika seřadit a zjistit tak, která z nich jsou nejnebezpečnější. 4) Identifikace preventivních strategií – Po identifikaci rizik by měl tým vymyslet preventivní strategie, které říkají, jaká opatření je třeba přijmout, aby se zmírnila pravděpodobnost výskytu rizika nebo jeho dopad. Jsou možné čtyři druhy preventivních strategií: a) Vyhnutí se – reorganizovat projekt tak, aby mu riziko nehrozilo (např. vyřazením některých rizikových pracovních činností). b) Zmírnění – návrh akcí, které sníží pravděpodobnost výskytu nebo dopad rizika. c) Přesun – reorganizace projektu tak, že riziko ponese někdo jiný. Riziko tímto krokem není eliminováno. d) Přijmutí – riziko přijmeme a vymyslíme záložní plán pro případ jeho výskytu. Vytváření záložních plánů je dobré i v případě ostatních preventivních strategií – ve všech případech se může stát, že navzdory všem preventivním opatřením k riziku nakonec dojde. Součástí návrhu záložních plánů by mělo být i vytvoření indikátoru, který říká, že by měl být plán spuštěn (např. přihlašovací modul není hotov do 1. Září.) 5) Úprava seznamu rizik během iterace – Seznam rizik by měl být v průběhu iterace stále upravován – je možné, že se objeví nová rizika a stará rizika ztratí platnost. Během každé iterace by pak měla být všem členům týmu zdůrazňována existence rizik a manažer by se měl ujistit, že členové provádějí akce k jejich prevenci. Na konci iterace je pak seznam rizik zrevidován a pravděpodobnosti a dopady rizik jsou případně změněny. Ukažme si nyní, jak takový seznam rizik může vypadat (Obrázek 5). Šablona pro seznam rizik byla získána z OpenUP. Jedná se o reálný příklad seznamu rizik používaného na projektech v případové studii (jména zainteresovaných firem byla změněna): 36

Obrázek 4 – Příklad seznamu rizik, zdroj: autor

Jak je vidět formát seznamu rizik byl v tomto případě ponechán včetně anglických názvů. V příloze této práce je možné najít mnou vytvořenou a přeloženou šablonu seznamu rizik, kterou je možné použít v rámci frameworku nebo mimo něj.

5.3 Tvorba požadavků Tvorba požadavků je velmi významnou částí vývoje, protože se od ní odvíjí všechny další projektové činnosti. Je tedy důležité, aby se na ní od samého začátku podílelo i oddělení SQA, které díky tomu získá představu, jaké jsou skutečné potřeby zákazníky, a může na základě toho vytvářet testované případy. Požadavky mohou být zapsány jen poměrně stručně, ale to stačí k tomu, aby všechny zúčastněné strany pochopily, jak má vypadat výsledný produkt.

5.3.1 Pracovní produkty a role Dle OpenUP je výsledkem fáze tvorby požadavků celkem 5 výstupů [14]: slovník (Glossary), vize (Vision), globální systémové požadavky (System-Wide Requirements), model uživatelských případů (Use-Case Model) a samotné uživatelské případy (Use Cases). Cílem fáze je pak zaznamenat veškeré zákaznické požadavky na systém v takové podobě, aby dle nich bylo možné systém vytvořit. Je třeba zdůraznit, že požadavky v takové podobě, v jaké budou zaznamenány, jen málokdy přetrvají až do konce. OpenUP zdůrazňuje nutnost jejich neustále revize. V praxi jsem se setkal s tím, že když byl zákazníkovi dodán první prototyp nějaké komponenty systému (tj. byla dokončena první iterace), tak zákazník pochopil, že jeho původní představy se v mnohém lišily, od toho co skutečně chtěl, a bylo tak nutné většinu požadavků (a tím i uživatelských případů) zcela přepsat. V OpenUP je role, která je zodpovědná za tvorbu požadavků ve všech jejich formách pojmenovaná jako analytik (Analyst). Ve firmě Cleverbee se tradičně pro tuto roli používal název konzultant (resp. business konzultanta) a ten tedy budu dále používat i já. Role konzultanta 37

v Cleverbee má také poněkud širší pojetí – nejedná se o osobu, která jen sbírá požadavky a sepisuje je, ale snaží se zároveň zákazníkovi radit v tom, co by pro něj bylo nejlepší a zároveň ho usměrňovat, pokud by se jeho požadavky staly příliš nereálnými. Osobně s tímto pojetím souhlasím a myslím, že v OpenUP nejsou konzultační možnosti analytika zdůrazněny. V případě, že by analytik totiž pouze zaznamenal požadavky a aplikace by dle nich byla později vytvořena, tak stále hrozí, že ji zákazník odmítne, s tím, že si představoval něco jiného. I ve firmě Cleverbee jsem byl před zavedením SQA frameworku a nového vývojového procesu svědkem toho, že některé projekty dopadly podobným způsobem. Je to proto, že v některých případech platí okřídlené heslo: „zákazník neví, co chce“. Zákazník má mnohdy pouze vágní představu o tom, čeho by chtěl dosáhnout (např. „chceme rychleji zpracovávat faktury“), ale už netuší, jakými cestami se k požadovanému výsledku dobrat. Je na konzultantovi, aby mu vysvětlil, jaké možnosti existují, a společně se zákazníkem se dobral k tomu, která možnost by daný cíl nejlépe podporovala. Spousta požadavků tak v podstatě vytvoří konzultant (který má i lepší představu o tom, jaká jsou na projektu technická omezení) a zákazník je pouze odsouhlasí. Příkladem takového požadavku může být: „Aplikace bude uživateli našeptávat možné hodnoty“, což znamená, že když uživatel zadá do nějakého pole pár písmen z hledaného výrazu, aplikace mu sama nabídne odpovídající možnosti, aniž by uživatel musel na cokoli klikat. Zákazník si sám pravděpodobně neuvědomí, že taková možnost existuje, protože v době psaní této práce (rok 2009), našeptávání hodnot není stále zcela běžnou součástí vytvořených aplikací. Konzultant může ale zákazníkovi tuto funkcionalitu nabídnout, i když nebyla původně požadována, protože umožní zefektivnit práci uživatelů a tím zároveň přispěje ke splnění původního požadavku zákazníka (kterým mohlo být např. ono zmíněné „chceme rychleji zpracovávat faktury“).

5.3.2 Slovník Dle OpenUP by samotnému sběru požadavků mělo předcházet vytváření slovníku [14]. Slovník umožňuje konzultantům a zákazníkům najít společnou řeč. Pokud by nebyl zaveden, tak by vzrostla pravděpodobnost nepochopení požadavků na straně vývojového týmu. Samotný slovník, může být velmi jednoduchý – stačí dokument ve formátu Microsoft Excel, který bude obsahovat všechny relevantní výrazy včetně jejich vysvětlivek. Součástí slovníku by měly být i zkratky, které budou v analýze používány. Oddělení SQA se na tvorbě slovníku přímo nepodílí, ale bylo by vhodné, aby vytvořený slovník prošel jeho kontrolou – členové SQA mohou odhalit nějaké nejasnosti. Vytvořený slovník by pak měl být ukázán všem členům projektového týmu, kteří jsou povinni se s ním seznámit. Jak může vypadat takový vzorový slovník je vidět na následujícím obrázku (Obrázek 6):

38

Obrázek 5 - Příklad slovníku, zdroj: autor

5.3.3 Vize Dalším důležitým dokumentem vytvářeným ve fázi sběru požadavků je vize. Tento dokument zachycuje pohled zákazníka na vyvíjené technické řešení. Obsahuje seznam základních vlastností systému dle potřeb zákazníka. Ve vizi se též nachází náčrt hlavních požadavků na systém, které budou později dále rozpracovány. Vize by měla být napsaná jednoduše a stručně, aby ji byly schopny pochopit všechny strany projektu. Důležitým atributem vize, který zdůrazňuje i OpenUP, je, že by měla v první řadě zachycovat problém, který chce zákazník řešit, a až sekundárně jeho řešení. Zákazníci totiž často přicházejí s už vymyšleným návrhem systému a od dodavatele chtějí jen jeho realizaci. Toto řešení mohlo být ale vymyšleno pouze několika lidmi z IT oddělení zákazníka a nemusí zohledňovat skutečné potřeby business vlastníků odpovídajících procesů. Vize by měla obsahovat tyto součásti [14]: •

Popis řešeného problému

•

Popis vytvářeného produktu

•

Popis zákazníka a dalších zainteresovaných stran (tzv. stakeholderů)

•

Popis uživatelského prostředí – jaké je nyní a jak se změní, po implementaci systému.

•

Seznam zákaznických potřeb a vlastností systému, které je budou řešit. 39

•

Případná omezení systému.

•

Další nutné požadavky na systém.

V následující tabulce je uvedeno, jak může vypadat definice zákaznického problému ve vizi dle OpenUP (Tabulka 1): Tabulka 1 - Příklad definice problému ve vizi

Problém

Organizace a administrace HR procesů nejsou efektivně řešeny (HR procesy: 1/ proces tréninků a 2/ proces hodnocení a povyšování). Logické propojení obou procesů je zajištěno, nicméně jejich organizace a administrace jsou vedeny samostatně, převážně v .xls souborech a ukládány na vnitřním file systému.

Postihuje

sekce HRD (Sekce rozvoje lidských zdrojů) sekce H&S (Sekce bezpečnosti zdraví) Vedoucí pracovníky Zaměstnance

Má za následek

Neefektivní práci při organizaci a administraci procesů tréninků a hodnocení a povyšování (z hlediska času a vynaložené práce). Chyby způsobené lidským faktorem (v obou procesech).

Úspěšné řešení by Jednotně vedená agenda obou procesů. bylo

Jednotné automatické řízení vybraných částí procesů (tréninky, hodnocení a povyšování). Jednotný přístup k informacím a úkolům (pro všechny zúčastněné skupiny zaměstnanců). Automatické cílení úkolů na odpovědné pracovníky. Strukturovaná a kvalitní výstupní dokumentace. Dlouhodobá archivace dokumentů dle ISO standardu a řešení bezpečnosti přístupů k obsahu dokumentů.

V příloze k této práci se nachází přeložená šablona vize, kterou jsem vytvořil pro tento framework a která obsahuje všechny části, jež by měla vize obsahovat včetně stručného vysvětlení. Co se týče použití tohoto dokumentu z hlediska SQA – manažer kvality a jeho oddělení by s ním měli být seznámeni co nejdříve a měli by se ho pokoušet propagovat mezi ostatními členy projektového týmu. Je to proto, že vize je v podstatě jediným dokumentem, který obsahuje popis problému, který má být řešen, a proč zákazník chce, aby řešen byl. Pokud se ho tedy podaří oddělení SQA dostatečně propagovat, tak budou členové týmu přesně vědět, co vytváří, což může přispět k výsledné kvalitě. Příkladem takovéhoto zlepšení kvality může být např. výše zmíněný systém pro 40

zrychlení práce s fakturami – pokud si vývojáři a konzultanti nebudou uvědomovat, že aplikace má proces primárně zrychlit, tak hrozí, že do ní přidají tolik funkcí, že bude v reálu práce s ní dosti pomalá.

5.3.4 Zápis požadavků Co se týče samotného zápisu požadavků, doporučuje ho OpenUP dělat formou uživatelských případů. Ne všechny požadavky jsou ovšem vhodné k tomu, aby mohly být zapsány jako po sobě jdoucí sled kroků. Proto OpenUP rozlišuje i tzv. globální systémové požadavky, což jsou prostá vyjádření, která říkají, co má systém splňovat. Jako příklad takového vyjádření je např.: „Systém musí umožnit současné připojení 100 uživatelů.“ V čem se osobně poněkud rozcházím s názorem OpenUP je psaní požadavků primárně jako uživatelských případů. Tvorba uživatelských případů zabere zaprvé poměrně dost času, a tak je v podstatě nemožné zapisovat všechny požadavky touto formou na schůzkách se zákazníkem. V procesu přepisování požadavků pak vždy hrozí, že se určitá informace ztratí nebo bude interpretována špatným způsobem. Nelíbí se mi příliš ani, že by část požadavků (globální systémové požadavky) byla napsána jedním způsobem a část požadavků jiným (uživatelskými případy) – hrozí pak nekonzistence. Můj návrh je tedy zapisovat požadavky napřed všechny na jedno místo a zapisovat je, pokud možno co nejstručnějším možným způsobem – tak, aby požadavky vyjadřovaly skutečné přání zákazníka a konzultant si do nich nepřidával nic svého. Požadavky, které je možné přepsat do uživatelských případů, pak budou přepsány a bude u nich uvedeno, jakého případu se týkají, a podobně u daného případu bude uvedeno, který požadavek realizuje. Toto pojetí odpovídá i tomu, uvedenému v CMMI v procesní oblasti Requirements Management (tj. Správa požadavků) [3], kde je uvedeno, že je třeba neustále udržovat vazby mezi požadavky, výsledky práce (tj. modely) a projektovým plánem. Podobný návrh můžeme najít i v plné verzi metodiky RUP pod názvem Concept: Traceability [11], což se dá přeložit jako koncept vystopovatelnosti. Na následujícím obrázku je vidět, jak se dají jednotlivé prvky v systému vystopovat (Obrázek 6):

41

Obrázek 6 - Vystopování navazujících prvků (tracing) napříč systémem, zdroj: [11]

Jak je vidět tak případy užití a další specifikace budou vycházet z potřeb zákazníka (Stakeholder Requests/Needs), vize (Vision) a obchodních pravidel (Business Rules). Z těchto pak dále vychází model designu (Design Model), skupiny (Test Suites) a dokumentace a tréninkové materiály (End-User Documentation Materials and Training Materials). Ve vhodném nástroji je pak možné naznačit, které prvky designu vycházejí z kterých. Požadavky je sice možné jednoduše sepsat v tabulkových procesorech typu Microsoft Excel, ale toto nepovažuji za příliš vhodné. Požadavky se velmi úzce týkají modelů v analýze systému a tato analýza bývá obvykle vytvářena ve specializovaných nástrojích. Firma Cleverbee např. pro vytváření modelů v populárním modelovacím jazyce UML využívá kupříkladu nástroj Enterprise Architect. Sepsání požadavků v tomto Enteprise Architektu jim tak umožňuje jednoduše provázat na uživatelské případy a další komponenty systému. Výhodou je i, že Enterprise Architect podporuje editaci jednotlivých diagramů více uživateli najednou, což zvyšuje efektivitu práce.

5.3.5 Rozdělení požadavků Dle CMMI (procesní oblast Requirement Development tj. tvorba požadavků) je vhodné požadavky také rozdělit do několika úrovní: •

Zákaznické – odpovídají požadavkům zadaným zákazníkem. Netýkají se ale samotného designu.

•

Produktové – většinou je už vytváří analytici/konzultanti v dodavatelské firmě. Popisují už přímo návrh systému

•

Produktově komponentové – týkají se přímo požadavků na jednotlivé komponenty. Bývají obvykle dosti technické a zákazník na ně nemá vliv.

42

Je samozřejmě vhodné požadavky i sdružit do kategorií podle dalších kritérií např. podle jednotlivých modulů – přihlašování, správa uživatelů, fakturace atd. V RUP je uvedeno ještě další dělení, které je víceméně podobné tomu v OpenUP [11]: •

Funkční požadavky – specifikují akce, které musí být systém schopný provést bez ohledu jakákoli fyzická omezení

•

Nefunkční požadavky – popisují atributy systému nebo jeho okolí (např. výkon, rozšiřitelnost, vzhled…) Jak může vypadat rozdělení požadavků (na funkční a nefunkční) a jejich navázaní na

uživatelské případy v aplikaci Enterprise Architect je vidět na dalších dvou obrázcích (Obrázek 7 a 8):

Obrázek 7 - Rozdělení požadavků v aplikaci Enterprise Architect, zdroj: autor

43

Obrázek 8 - Navázání požadavků na případy užití

Povšimněme si, že všechny případy užití a požadavky mají identifikátory, které je jasně označují REQ001, UC001 atd. Díky tomu je možné je jednoduše dohledat. Bližší informace k vytváření případů užití a požadavků v Enterprise Architectu budou k dohledání v kapitole věnované tomuto nástroji. Jak by měl vypadat zápis požadavků formou případů užití si vzhledem k větší komplexitě problému, popíšeme dále v samostatné kapitole.

5.4 Tvorba a správa případů užití a testovaných případů Tvorba případů užití a tvorba testovaných případů se úzce prolíná, proto si ji zmíníme v jedné kapitole. Napřed si ale ještě znovu ujasněme použitou terminologii, která je tu dost nejednotná. Následuje výpis relevantních pojmů, tak jak jsou použity v RUP, a jejich vysvětlení [11]: use case = případ užití. Jedná se o popis chování systému v reakci na vnější podněty. test case = testovaný případ. Jedná se o sadu vstupních dat, podmínek a očekávaných výsledků [14]. test = test. Jeden nebo více testovaných případů. Někdy může být také definován také jako akt provedení testovaného případu. test script = testovací postup. Instrukce, které krok za krokem popisují, jak zrealizovat daný test [14]. test scenario = testovací scénář. Jeden způsob průchodu testem dle testovacího postupu. test suite = skupina testů. Sada podobných testů. A jaký mají tedy mezi sebou tyto pojmy vztah? Dle metodiky RUP [11] na začátku máme nějaký testovací postup (test script), který definuje, jakým způsobem můžeme danou funkcionalitu 44

otestovat. Různé způsoby, kterými můžeme tímto testovacím postupem projít, se nazývají testovací scénáře (test scripts). Rozšíříme-li nějaký takovýto scénář o vstupní data, podmínky a očekávané výsledky, dostaneme testovaný případ (test case). Sada testovaných případů pro otestování jedné funkcionality (např. přihlášení do systému) pak představuje test. Jako skupinu testů (test suite) označujeme soubor testů, které mají něco společného (např. skupina testů týkajících se zabezpečení systému). Přičemž platí, že obvyklými podklady pro tvorbu testovaných případů a postupů jsou uživatelské případy.

5.4.1 Uživatelské případy O uživatelských případech (pro které se i v českých softwarových firmách často používá název use casey) jsme v této práci už hodně mluvili. Je to proto, že v OpenUP je na případy užití kladen velký důraz, jedná se v podstatě o jádro analýzy, z kterého pak vycházejí ostatní modely. OpenUp dokonce doporučuje zapisovat formou případů užití většinu požadavků na systém, kterýžto návrh ale považuji v lecčems za rizikový – jak již bylo uvedeno výše v kapitole věnované požadavkům. Případy užití jsou z hlediska SQA velmi důležité, podle nich jsou schopni i méně kvalifikovaní testeři pochopit fungování aplikace a pak ji otestovat. Od toho, jak kvalitně jsou případy užití napsané, se bude odvíjet i kvalita celé aplikace. Případy užití jsou důležité pro QA oddělení i z důvodu, že jsou podle nich obvykle vytvářeny testované případy, které přesně popisují, jak aplikaci testovat. A jak tedy můžeme případy užití zapisovat? Všechny případy užití by měly být součástí tzv. Modelu případů užité (Use-Case Model)[14]. Tento model ukazuje, jak různí uživatelé pracují se systémem za účelem vyřešení daného problému. Model případů užití se skládá ze tří základních druhů elementů: •

Případů užití (Use Cases)

•

Aktorů (Actors)

•

Asociací (Associations) Aktoři představují činitele mimo systém, kteří spouštějí jednotlivé případy užití. Obvykle se

jedná o uživatele přihlášené do systému. Asociace ukazují vztah, který nastává mezi aktory a případy užití. Asociace mohou být definovány i mezi samotnými aktory resp. samotnými případy užití. Dalšími možnými elementy v modelu jsou [14]: •

Ohraničení (Subject)

•

Generalizace (Generalizations)

•

Závislosti (Dependencies) 45

Ohraničení ukazuje hranice systému, kterého se případy užití týkají. Generalizace ukazuje vztahy nadřízenosti a podřízenosti mezi aktory. Závislosti naznačují další možné vztahy mezi případy užití. Běžně používanými vztahy závislosti jsou <<extend>> (rozšíření) a <> (zahrnutí). Rozšíření znamená, že daný případ užití nepovinně rozšiřuje vybraný případ a zahrnutí znamená, že naopak tento případ v sobě zahrnuje. Na následujícím obrázku (Obrázek 9) je vidět příklad modelu (vytvořeného v aplikaci Enterprise Architect) případů užití bankomatu včetně vazeb a aktorů: uc Bankov ní systém Bankomat

UC02 - Vybrat peníze

ACT02 - Banka

ACT01 - Zákazník banky «include» UC03 - Pře v ést peníze «include» UC01 - Ov ě řit uživ atele

ACT03 - Pracov ník banky

UC04 - Dopl nit peníze

Obrázek 9 - Příklad modelu případů užití, zdroj: autor

Povšimněte si opět, že všechny komponenty modelu mají unikátní identifikátory, aby bylo lehčí se v nich vyznat. V tomto případě nejsou v modelu z důvodu zjednodušení navázány na případy užití požadavky, ale jak už jsem uvedl v kapitole Tvorba požadavků, doporučuji, aby tomu tak bylo. Podívejme se nyní na to, jak konkrétně každý případ užití rozepsat. Jak již jsem uvedl, zjednodušeně řečeno se jedná o seznam kroků, které vedou k nějakému cíli. Každý případ užití většinou nemá jen jeden způsob, kterým se dá provést, ale definuje i různé alternativní cesty, které reprezentují odchylky od hlavního postupu. Nejlépe si to ukážeme na příkladu: představme si jednoduchý případ užití, který se týká přihlášení do systému. Hlavní cesta a alternativní cesty takovéhoto případu jsou popsány v následující tabulce (Tabulka 2): 46

Tabulka 2 - Vzorový případ užití a jeho alternativní cesty, zdroj: autor

Hlavní cesta

1. uživatel vstoupí na přihlašovací obrazovku aplikace 2. uživatel zadá své uživatelské jméno 3. uživatel zadá své heslo 4. uživatel stiskne tlačítko „Přihlásit“ 5. systém ověří uživatelovy údaje proti databázi a pošle zpátky výsledek 6. uživateli se zobrazí hlavní stránka aplikace

Alternativní cesta 1

1. uživatel ve 2. kroku Hlavní cesty zadá chybné uživatelské jméno 2. přejděte na 3. krok Hlavní cesty

Alternativní cesta 2

1. uživatel ve 2. kroku Hlavní cesty zadá chybné heslo 2. přejděte na 4. krok Hlavní cesty

Alternativní cesta 3

1. v 6. kroku Hlavní cesty nebudou úspěšně ověřeny uživatelovy údaje 2. byly-li chybné údaje zadány po třetí, přejděte na Alternativní cestu 3 3. uživatel zůstane na přihlašovací obrazovce a zobrazí se mu chybová hláška 4. uživatel může dále pokračovat 2. krokem Hlavní cesty

Alternativní cesta 4

1. na tuto cestu je možné přejít pouze z 3. kroku Alternativní cesty 3 2. zobrazí se chybová hláška a přihlašování z IP adresy uživatele je zablokováno na 1 hodinu 3. správci aplikace přijde informační e-mail

Výše zmíněný způsob případů užití samozřejmě není jediný možný a nedá se říci, že by byl správnější než jiné. Vychází ale ze způsobu popsaného v metodice RUP, takže je kompatibilní i s námi používanou OpenUP. Uvedený případ užití je v něčem možná až příliš podrobný. Na základě svých zkušeností jsem zjistil, že je obvykle lepší psát případy užití tak, aby důsledně nepopisovaly každou součást uživatelského rozhraní ve stylu „klikněte na tlačítko ‚Odhlásit‘ v pravém horním rohu obrazovky“. Je to proto, že je pak velmi náročné udržovat konzistenci případů užití a návrhu 47

grafického rozhraní – pokud vývojář posune tlačítko někam jinam, je případ užití rázem neplatný. Pokud by bylo v popisu uvedeno jen „klikněte na odhlašovací tlačítko“, tak už případ užití bude fungovat bez ohledu na to, jak se tlačítko jmenuje, a kde se nachází. Detailní popis rozhraní by měl existovat, jen pokud na něm zákazník trval – tj. např. chce, aby všechny ovládací prvky byly vždy v pravém horním rohu.

5.4.2 Testované případy Jestliže jsem v předchozí kapitole uvedl, že případ užití by neměl příliš detailně popisovat jednotlivé ovládací prvky, tak pro testované případy platí opak. Mělo by z nich být zcela jasné, co má uživatel v aplikaci použít, a jak vypadá očekávaný výsledek. Prvním krokem při tvorbě testovaných případů by tedy mělo být odpovídající rozepsání případů užití, tak aby neexistovaly nejasnosti v tom, jak bude ten který případ proveden. Je zde třeba opět zdůraznit, že s tvorbu testovaných případů by se mělo začít co nejdříve – obvykle zároveň s psaním případů užití a dalších požadavků. Častou chybou je nechávat jejich psaní až nakonec, když je aplikace téměř hotová. Pokud obdrží testeři testovatelnou aplikaci, měli by začít okamžitě testovat a rozhodně ne teprve pátrat potom, jak bude aplikace testována. Testované případy navíc představují pro manažery velmi dobrý způsob, jak sledovat stav dokončení aplikace, protože teprve, když prošel testovaný případ pro danou komponentu, tak můžeme říci, že je tato komponenta funkční. Podíl úspěšně provedených testovaných případů na jejich celkovém množství nám také říká, jaké procento aplikace je hotové (odpovídá požadavkům zákazníka). Přikročme ale dále k popisu tvorby vzorového testovaného případu. Když už jsme dostatečně rozšířili případy užití, je třeba definovat testovací scénáře. Každý scénář je jednou z cest, kterou se dá případem projít. Možné testovací scénáře založené na případu užití z předchozí kapitoly jsou uvedeny v následující tabulce (Tabulka 3): Tabulka 3 - Příklad testovacích scénářů, zdroj: autor

Scénář 1 - Úspěšné přihlášení

Hlavní cesta 1

Scénář 2 – Chybně zadané Hlavní cesta 1 -> Alternativní cesta 1 -> Hlavní cesta 1 -> uživatelské jméno

Alternativní cesta 3

Scénář 3 – Chybně zadané Hlavní cesta 1 -> Alternativní cesta 2 -> Hlavní cesta 1 -> heslo

Alternativní cesta 3

Scénář 4 – Chybně zadané Hlavní cesta 1 -> Alternativní cesta 1 -> Alternativní cesta 2 -> jméno a heslo

Hlavní cesta 1 -> Alternativní cesta 3

Scénář 5 – Údaje jsou potřetí 3x (Hlavní cesta 1 -> Alternativní cesta 1 a/nebo 2 -> Hlavní cesta zadány chybně

1 -> Alternativní cesta 3) -> Alternativní cesta 4 48

Jak vidno v tomto případě je scénářů stejně jako cest, v reálu jich ale může být i mnohem víc. Tady jsme také nepokryli všechny situace, které mohou nastat např. dvojnásobné chybné zadání přihlašovacích údajů. Nyní už můžeme pokračovat s vytvářením samotných testovaných případů. Jako základ použijeme testovací scénáře, které rozšíříme o vstupy a očekávaný výsledek (Tabulka 4): Tabulka 4 - Příklad testovaných případů, zdroj: autor

ID

Scénář

Uživatelské

Heslo

Očekávaný výsledek

jméno TC1 1

platné

platné

Uživatel je úspěšně přihlášen.

TC2 2

neplatné

platné

Chybová

hláška.

Uživatel

může

pokračovat 1. krokem Hlavní cesty. TC3 3

platné

neplatné

Chybová

hláška.

Uživatel

může

pokračovat 1. krokem Hlavní cesty. TC4 4

neplatné

neplatné

Chybová

hláška.

Uživatel

může

pokračovat 1. krokem Hlavní cesty. TC5 5

platné

neplatné

Chybová hláška. Informační e-mail pro správce. IP uživatele je blokována.

TC6 5

neplatné

platné

Chybová hláška. Informační e-mail pro správce. IP uživatele je blokována.

TC7 5

neplatné

neplatné

Chybová hláška. Informační e-mail pro správce. IP uživatele je blokována.

Z původních 5 scénářů jsme tedy odvodily 7 různých testovaných případů. Tyto případy berme spíše pouze ilustračně, protože jejich popis není dostatečný – chybí nám tu informace o podmínkách potřebných pro jejich splnění a není ani specifikováno, která uživatelská jména a hesla jsou vlastně platná. Pokud by tester chtěl podle těchto testovaných případů aplikaci otestovat, tak by nevěděl, jakou hodnotu mají přihlašovací údaje mít, a musel by spoléhat na svůj vlastní úsudek. Správně by se tedy ve sloupcích Uživatelské jméno a Heslo měly nacházet konkrétní hodnoty, které se dají zadat do přihlašovacího formuláře - např. „123456“ nebo „prázdné“. V takovém případě by ale testovaných případů bylo ještě mnohonásobně více. Je ale třeba si uvědomit, že zvláště v případě malých firem je nutné dělat při dokumentaci testovaných případů kompromisy. Kompletní popis, tak jak ho chce RUP, by mohl znamenat, že testeři 49

stráví veškerý čas psaním a nebudou už míry, kdy provádět samotné testování. Je tedy třeba vždy rozmyslet, jak velký přínos budou mít podrobnější testované případy, a porovnávat tyto přínosy s náklady na tvorbu těchto případů. Obecně platí, že u kritických aplikací (např. aplikace pro letiště, nemocnice atd.) by měly být testované případy vždy co nejpodrobnější, u menších systémů naopak často stačí, když se bude testovat podle upravených případů užití.

5.4.3 Správa testovaných případů Uvedený příklad byl velmi jednoduchý, jednalo se o pouhé přihlášení uživatele, přesto bychom z něj mohli vytvořit opravdu velké množství různých testovaných případů. Zdokumentování všech možných způsobů otestování dané funkčnosti samozřejmě není ve většině případů nutné a někdy ani možné. Klíčové při přípravě testovací strategie je hlavně identifikovat, které testy jsou zásadní, a vhodně je rozdělit do skupin, s jejichž pomocí by se daly otestovat všechny hlavní funkce systému. Co se týče vhodného rozdělení testů do skupin, mělo by platit, že jejich rozdělení musí dávat smysl v první řadě testerům a ne nutně vývojářům. Pro vývojáře by mohlo být např. logické vytvořit si skupinu pojmenovanou jako „Práce s databází“, která bude obsahovat veškeré funkce aplikace, jejichž provádění zahrnuje zápis do databáze. Tester ale mezi testy v této skupině nenajde žádnou souvislost, není schopen rozeznat, který prvek uživatelského rozhraní do databáze zapisuje, a který ne. Vhodné je tedy rozdělit testy buď podle nějaké funkcionality, která se prolíná celou aplikací (např. „Ukládání dokumentů“ nebo „Přihlášení a zabezpečení“) nebo podle nějakých logických částí grafického uživatelského rozhraní (např. „Hlavní menu“ nebo „Složky s dokumenty“). V případě systémů pro řízení procesů pak můžeme třídit testy i podle jednotlivých aktivit v procesu (např. „Schvalování dokumentu“ nebo „Tvorba návrhu smlouvy“). Pro správu a ukládání testů většinou není vhodné používat dokumenty na disku, které postrádají vazbu na zjištěné defekty a nejsou přizpůsobeny pro paralelní zpracování více uživateli. Lepší volbou je použití nějakého specializovaného nástroje pro správu testů (angl. test case management). Zatímco nástroje pro sledování chyb (angl. bugtracker), jako je např. Bugzilla nebo Mantis, jsou většinou nedílnou součástí testovacího procesu, nástroje pro správu testů takovouto silnou pozici zatím vybudovanou nemají. Na trhu jich je ale v současnosti už poměrně velké množství. Z těch významných můžeme jmenovat např. IBM Rational ClearQuest5, Team Foundation Server6 nebo

5

Rational ClearQuest, http://www-01.ibm.com/software/awdtools/clearquest/

6

Team Foundation Server, http://msdn.microsoft.com/en-us/teamsystem/default.aspx

50

ExtraView7. Mezi základní funkce těchto nástrojů patří rozsáhlé možnosti správy testů, navazovaní zjištěných chyb na tyto testy, správa testovacích cyklů, možnosti reportingu atd. Pro účely tohoto frameworku samozřejmě bude vhodné vybrat nějaký jednoduchý nástroj, který je možné pořídit s nízkými náklady. Blíže se budeme nástroji pro správu testů zabývat v kapitole věnované případové studii. Jak přesně podle testovaných případů testovat pak osvětlím v další kapitole, která se zabývá testováním obecně.

5.5 Testování Podívejme se nyní, jakými způsoby můžeme vlastně aplikaci testovat, a jaké typy testů existují.

5.5.1 Typy testů Co se týče jednotlivých typů testování, je OpenUP na informace poměrně skoupý – hlavní informací, kterou se dozvíme je, že máme vytvořit testované případy, otestovat je podle testovacích postupů a zapsat výsledky (v OpenUP pojmenované jako Test Log). Existuje zde ale stručné rozlišení typů testů [14], které vychází z definice kvality dle normy ISO 9126, již jsme si uvedli v kapitole 3.1 Co je softwarová kvalita?: Testy funkčnosti •

Funkční testy – ověření funkcí aplikace podle předem daných metod resp. případů užití

•

Testy bezpečnosti – testuje se schopnost produktu chránit informace a data tak, že k nim nebudou mít přístup neautorizované systémy a osoby

•

Kapacitní testy – testuje se schopnost systému pracovat s velkými objemy dat. Testeři se tu např. snaží zobrazit co největší množství dat v systému.

Testy použitelnosti •

Testy použitelnosti – tyto testy se zabývají kontrolou aplikace z hlediska kvality jejího ovládání, estetických vlastností, kvality dokumentace a nápovědy atd.

•

Testy integrity – testují kvalitu kódu, používání zdrojů, odolnost vůči pádům atd. Testuje se obvykle proti definovaným jednotkám programového kódu a testy si vytváří sami programátoři.

7

ExtraView, http://www.extraview.com/

51

•

Testy struktury – kontrolují, zda struktura aplikace odpovídá jejímu designu. Typickým příkladem je kontrola odkazů ve webové aplikaci.

Testy bezporuchovosti •

Stres testy – test chování systému v abnormálních podmínkách – při velkém množství přístupů, nedostatečné paměti, nedostupnosti některých služeb atd.

•

Srovnávací testy – srovnání výkonu za určitých podmínek s výkonem za jiných, už zdokumentovaných podmínek.

•

Testy vícenásobného přístupu – testuje se vícenásobný přístup k nějakému zdroji.

Testy výkonu •

Zátěžové testy – testují se operační možnosti systému – např. jakou zátěž je schopen maximálně vydržet.

•

Profilování – monitorují se systémová volání, datové toky a přístupy atd. Tak aby bylo zjištěno, které procesy jsou neefektivní, a kde se nacházejí úzká místa v systému.

•

Testy konfigurace – testování vlastností systému na různých hardwarových a softwarových konfiguracích.

Testy přenositelnosti •

Testy instalace – testuje se instalace na různých platformách a za různých podmínek (např. při nedostatečném místě na disku). Toto je ale pouze jeden pohled, podle kterého se dají testy rozdělit, možných dělení existuje

podstatně více. William E. Lewis ve své knize Software Testing and Continuous Quality Improvement[19, str. 39-41] zmiňuje další možné typy testů: •

Black-box testing (funkční testování) - při funkčním testování kontrolujeme správné chování externích funkcí aplikace tím, že sledujeme její vnější chování v průběhu testu. K aplikaci tu tedy přistupujeme jako k černé skříňce (anglicky black box), nezajímá nás jaká je logika uvnitř a co jí pohání, ale jak se chová navenek.

•

White-box testing (strukturní testování) - při tomto testování kontrolujeme správnou implementaci vnitřních částí aplikace, jako jsou různé komponenty, datové struktury atd. Toto testování většinou vyžaduje důkladnou znalost technického fungování aplikace, a proto se o ně obvykle starají sami vývojáři.

•

Gray-box testing (strukturní a zároveň funkční testování) – tester zde při testování komunikuje s vývojářem, který mu objasňuje fungování aplikace (např. které stavy mohou nastat). 52

•

Manuální testování – testování, které provádí lidé (tj. obvykle testeři).

•

Automatizované testování – testování je prováděno samotným systémem podle daných pravidel.

•

Statické testování – je nezávislé na čase. Testuje se, aniž by bylo nutné spouštět testovaný program. Typickým příkladem je kontrola napsaného kódu aplikace.

•

Dynamické testování – je závislé na čase. V průběhu testování je prováděna specifická sekvence instrukcí. Do dynamického testování se řadí většina testů. Co se týče potřeb této práce, bylo by zbytečné se zabývat všemi možnými testovacími

technikami, protože malá firma jistě bude chtít používat jen některé z nich a to ideálně ty, které budou mít největší vliv na kvalitu jejích produktů a zároveň budou klást co nejmenší nároky na lidskou práci a finanční prostředky. V dalších kapitolách se tak podíváme hlavně na to, bez čeho se SQA oddělení neobejde: •

Testovací proces

•

Správa chyb

Jako na specifický případ se pak podíváme na automatizované testování, které je pro malé vývojářské firmy zajímavé, protože jim za určitých okolností může ušetřit dost práce.

5.5.2 Testovací proces Už jsme si řekli, jaké místo má testování ve vývojovém cyklu projektu dle OpenUP, jak na ně nahlíží RUP a napsali jsme si i jak testy dokumentovat pomocí testovaných případů. Chtělo by to ale stále upřesnit testovací proces pro běžného testera, který by říkal, jak má při otestování aplikace postupovat a jaké nástroje má použít. Jak na testování nahlíží OpenUP, už bylo zmíněno – tester si napíše testované případu, poté obdrží část aplikace k testování, otestuje ji podle testovacího postupu (test scriptu) a pak někam zapíše výsledky. Zápisem výsledků testování se budu zabývat v samostatné kapitole věnované správě chyb, vytvoření testovaných případů a jejich použití se ale pokusím dále rozepsat, přičemž vyjdu z informací, které už jsem zde dříve uvedl. Tester tedy napřed musí vytvořit testované případy. Kam ale nejlépe tyto případy zapsat a jak je uložit? Osobně bych doporučil dvě možnosti – pokud disponujeme modelovacím nástrojem, který je schopný importovat testované případy do nějaké aplikace pro správu testů, tak bych použil jako primární zdroj tento nástroj. Umožní nám to mít testované případy hned vedle případů užití a je opět možné je vzájemně provázat. Pro členy týmu je pak příjemné, když mají všechny modely na jednom 53

místě. V případě potřeby je pak možné testované případy z modelu vyexportovat a nahrát do nástroje pro správu testovaných případů. Export a import testovaných případů není ale vždy standardní funkcí, proto bude někdy nutné psát testované případy přímo v nástroji určeném pro jejich správu. Takový nástroj by měl umožňovat vložení testovaných případů do jednotlivých cyklů. Každý cyklus by měl představovat testování jedné iterace v rámci OpenUP. Poté, co je testování dokončeno, se pak v závislosti na počtu nalezených chyb zhodnotí, jestli je danou iteraci možné předat zákazníkovi nebo je třeba vytvořit novou iteraci, v které budou chyby opraveny. Je třeba zdůraznit, že součástí každého testovacího cyklu nemusí být zdaleka všechny testy, které se týkají dané iterace. Měly by tam být jen ty opravdu relevantní. Součástí každého testovacího cyklu by ale vždy měly být tzv. smoke testy, což jsou testy, které by měly bezpodmínečně projít. Typickým příkladem je výše zmíněné přihlášení: pokud se do aplikace nemohu přihlásit, tak můžu zapomenout na provádění jakýchkoli dalších testů. Zásadní jsou též testy pro tzv. akceptační testování. To jsou testy, které ověřují splnění tzv. akceptačních kritérií. Tato kritéria definují požadavky, které musí aplikace splnit při převzetí díla zákazníkem. Provedení těchto testů by mělo být samozřejmostí před každou předávkou zákazníkovi. Pokud testujeme nějakou část aplikace vícekrát za sebou, je někdy dobré úspěšný test na nějakou dobu z cyklů vyřadit a znovu ho zařadit později, tak aby testeři nebyli nuceni stále testovat už jednou ověřenou funkcionalitu. Lidé mají totiž tendenci přeskakovat testy, které v předchozích cyklech prošly. Pro usnadnění práce s SQA frameworkem jsem připravil seznam činností, které by měly být provedeny před započetím nového cyklu včetně jejich pořadí: 1. Vytvořit strukturu testovaných případů – připravit si a pojmenovat skupiny testů. 2. Vytvořit testované případy na základě případů užití. Naznačit případné vztahy mezi nimi. 3. Provést případný import do nástroje pro správu testovaných případů, pokud v něm aktuální případy ještě nejsou. 4. Ujistit se, že na případném předchozím testovacím cyklu byly zverifikovány všechny chyby a uzavřít tento cyklus. 5. Vytvořit v nástroji pro správu případů nový testovací cyklus. Napsat, jaké verze aplikace (a jaké iterace) se tento cyklus týká. 6. Vložit do testovacího cyklu případy, které budou testovány. 7. Označit testovací cyklus jako spuštěný. 54

8. Provést testovaní a zaznamenat nalezené chyby k odpovídajícím testovaným případům. 9. Informovat všechny zainteresované osoby o výsledcích testování. Je vhodné podpořit výsledky statistikami získanými z použitých nástrojů. 10. Ujasnit si, jaké kroky budou dále provedeny a kdy proběhne další cyklus.

5.5.3 Správa chyb Správa chyb je jedním ze zásadních úkolů SQA oddělení a zároveň se jedná o úkol, který výrazně ovlivňuje všechna další oddělení účastnící se vývojového procesu. Nástroj pro správu chyb bude pravděpodobně tím nejdůležitějším z hlediska podpory řízení softwarové kvality – a to jak pro management, tak pro obyčejné testery. Je tomu tak, protože z tohoto nástroje je možné získat kvantifikovatelné přehledy o tom, jak jsou aplikace firmy kvalitní. Je možné zjistit, kolik chyb se v průměru na projektu nachází, jak jsou tyto chyby závažné, kteří vývojáři dělají chyb nejvíce, jak dlouho jim oprava těchto chyb trvá atd. V menších společnostech je možné nástroje pro správu chyb (v angličtině obvykle jako issue tracking tools nebo bug tracking tools) používat i jako nástroj projektového managementu – mohou být přes ně přiřazovány úkoly a sledován čas, který při plnění úkolů zaměstnanci strávili. Pro malou firmu je takové využití výhodné i kvůli tomu, že ušetří peníze za nákup softwaru pro projektový management, který bývá obvykle dost drahý. Na druhou stranu mnoho nástrojů pro správu chyb je volně dostupných a funkcionalita těchto nástrojů je pro potřeby malé vývojářské firmy plně dostatečná – jako příklad můžeme uvést Bugzillu8, Trac9 nebo Mantis10. Jak tedy vhodně takové nástroje používat? Osvětleme si napřed, jaký je životní cyklus chyby (nebo jiného požadavku) nalezené na nějakém softwarovém produktu. Jako příklad použijme životní cyklus používaný v nástroji Bugzilla, který je vidět na dalším obrázku (Obrázek 10):

8

Bugzilla, http://www.bugzilla.org/

9

Trac, http://trac.edgewall.org/

10

Mantis, http://www.mantisbt.org/

55

Obrázek 10 - Životní cyklus chyby v nástroji Bugzilla, zdroj:[20]

Vysvětleme si napřed jednotlivé stavy chyby: •

UNCONFIRMED (Neověřeno) – chyba byla zadána uživatelem, který nemá právo přímo zadávat chyby (např. zákazníkem) a je třeba rozhodnout, jestli se jí budeme zabývat nebo ne. V rámci zjednodušení nedoporučuji v malé firmě tento stav používat.

•

NEW (Nová) – chyba byla nově zadána. Chyby může zadat kdokoli, nejčastěji to ale bývají testeři.

•

ASSIGNED (Přiřazeno) – vývojář si chybu převezme – označí tak, že už na ní začal pracovat.

•

RESOLVED (Vyřešeno) – Vývojář označí chybu jako vyřešenou a označí, jakým způsobem k vyřešení došlo: o

FIXED (Opraveno) – vývojář chybu vyřešil vlastními silami.

56

o

DUPLICATE (Duplikát) – chyba je duplikátem už nějaké existující chyby, takže nebude dále řešena.

o

WONTFIX (Nebude se opravovat) – sice se jedná o chybu, ale vývojář ji z nějakého důvodu nechce opravit – důvod je třeba zaznamenat. Může tomu být např. proto, že tato chyba není příliš závažná, ale její oprava by byla z hlediska času velmi náročná. Může se také stát, že chybu opravit vůbec nelze.

o

WORKSFORME (Funguje) – Vývojáři se už chyba neprojevila, vše funguje správně. Může k tomu dojít např. když někdo s opravou jiné chyby opravil i tuto.

o

INVALID (Neplatná) – chyba je neplatná – nejedná se o chybu. K tomuto obvykle dojde, když tester špatně pochopí fungování aplikace.

•

VERIFIED (Ověřeno) – tester ověřil, že oprava je správná.

•

REOPEN (Znovuotevřeno) – tester zkontroloval řešení chyby a došel k závěru, že nebylo správné – chyba se stále vyskytuje. Chyba je tedy znovuotevřena a vývojář si ji musí znovu přidělit a podívat se, kde je problém.

•

CLOSED (Uzavřeno) – po dokončení testování jsou všechny ověřené chyby uzavřeny. Podobný životní cyklus je součástí v podstatě všech nástrojů pro správu chyb, jen se jednotlivé

stavy jinak jmenují. Jména stavů je samozřejmě možné změnit tak, aby vyhovovaly potřebám dané firmy. Při zadávání chyb by mělo být vždy možné zadávat ještě tyto informace: •

Produkt – jakého produktu se chyba týká.

•

Verze – verze testované aplikace.

•

Komponenta – jaká část aplikace je zrovna testována. Komponenta se může shodovat se skupinou testů.

•

Závažnost – jak je daná chyba závažná – např. kritická chyba znemožňuje práci s nějakou významnou částí aplikace, zatímco triviální chyba může znamenat jen překlep. V Bugzille je možné zde označit, že se nejedná o chybu, ale o vylepšení (enhancement) nebo úkol (task).

•

Priorita – jak prioritně má být daný chyba řešena. Toto nemusí nutně souviset se závažností, někdy může být nutné řešit napřed méně závažné chyby, protože se např. týkají funkcionality, kterou chce zákazník vidět jako první.

57

•

Řešitel – osoba, které je chyba přiřazena. Tester by měl obvykle chybu přiřadit na nějakého výchozího řešitele nebo nepřiřazovat vůbec. Technický vedoucí se pak dále postará o přiřazení chyb těm pravým lidem.

•

Zadavatel – kdo chybu zadal.

•

Závislosti – toto pole není nutné, ale jeho použití je velmi doporučováno. Je možné ukázat závislost na dalších chybách. Je pomocí něho možné vytvářet i hierarchickou strukturu požadavků – jedna chyba má podřízené chyby a ty mají další podřízené chyby atd.

•

Hodiny – počet hodin, které vývojáři a testeři strávili prací na chybě. Navržený framework má sloužit jako podpora řízení softwarové kvality nejen manažerům

kvality (kteří mají často správu chyb na starosti), ale i projektovým manažerům. Proto bych zde chtěl sepsat i seznam možností, které nabízí vhodně zvolený nástroj pro správu chyb projektovým manažerům: •

Sledovaní vykazovaných hodin – manažeři v něm mohou sledovat, kolik hodin účastníci projektu vykazují na jednotlivých úkolech. Mohou také zjistit, které komponenty jsou z hlediska práce nejnáročnější. Pokud je vytvořena vhodná struktura chyb, kdy nadřízené chyby představují iterace, tak je možné zjistit, i jak jsou jednotlivé iterace náročné a jak se mění pracnost s jednotlivými iteracemi. Získané informace je pak možné využívat např. při tvorbě nabídek.

•

Úkolování zaměstnanců – je možné využívat tyto nástroje pro úkolování zaměstnanců, místo chyb se v tomto případě zadávají úkoly (např. v Bugzille pro to slouží závažnost „task“). Úkol prochází stejnými stavy jako chyba – je vidět, kdy si ho zaměstnanec přiřadil; kdy manažer ověřil jeho splnění atd.

•

Tvorba reportů – nad nástroji pro správu chyb je možné vytvářet různé reporty – např. počty chyb na jednotlivé zaměstnance, průměrné počty chyb na projekty a jednotlivé komponenty, průměrné časy řešení chyb atd. Tyto reporty jsou zajímavé jako pro manažery kvality, tak pro projektové manažery. Příklad nástroje pro správu chyb použití si uvedeme v kapitole věnované nástrojům použitým

ve frameworku.

5.5.4 Automatizace testů Automatizované testy jsou specifickým případem testováním. V tomto případě nejsou testy prováděny lidmi ale samotným systémem. Osoby zodpovědné za automatizované testování napřed připraví skripty, podle kterých bude systém testy spouštět, a ten je pak v předem daných časech 58

provede. Za formu automatizovaných testů můžeme považovat tzv. unit (jednotkové) a integrační testy. Unit testy testují, zda nějaká část kódu funguje správně, zatímco integrační testy testují spolupráci mezi více částmi kódu [21]. I když je jejich důležitost velká a ke kvalitě výsledného softwaru bezesporu významně přispívají, tak se jimi zde nebudeme zabývat. Je to proto, že tyto testy by měly být vytvářeny samotnými vývojáři a jsou tak očím SQA oddělení většinou poměrně utajené. I když by manažer kvality měl tlačit vývojářské oddělení k používání unit testů a integračních testů, tak pokud on sám nemá dostatečné technické znalosti, tak obtížně pozná, že je vývojáři dělají správně. Existuje ale druhý způsob testování, který už by měl spadat do oblasti působnosti SQA oddělení – testování grafického rozhraní. V tomto případě jsou zaznamenány akce uživatele v aplikaci a automatizační software se je pak pokusí později spustit. Pokud některá z akcí selže, obdrží o tom zodpovědná osoba zprávu a může provést případná opatření. Typickým příkladem může být např. stisknutí tlačítka v aplikaci, které zobrazí seznam faktur – pokud automatizační software tlačítko stiskne a nic se nezobrazí, je to vyhodnoceno jako problém a příslušné osoby jsou informovány. Ideálem automatizovaného testování je nástroj, kterému je předán testovaný případ, on ho provede bez zásahu testera a sám zapíše výsledky. Takto to bohužel funguje jen velmi výjimečně, zaprvé převést testované případy tak, aby je jedna ku jedné byl schopen provést počítač, je dost obtížné. Aplikace se navíc stále mění, takže testované případy rychle zastarávají a tím pádem zastarávají i skripty pro automatizované testy a nacházejí tak chyby tam, kde žádné nejsou. I William E. Lewis ve své knize Software Testing and Continuous Quality Improvement [19, str. 400] uvádí, že aby mohly být automatizované testy efektivně používány, musí se jim v podstatě na plný úvazek věnovat jedna nebo více osob. A je těžké najít osoby, které by se vytvářením skriptů pro automatizované testování zabývaly, protože jejich příprava vyžaduje programátorské znalosti, které testeři většinou nemají, a programátorům se zase na druhou stranu nechce testovat. Je pochopitelné, že malé firmy nemají lidí nazbyt, a tak je pro ně obtížné jich několik vyčlenit, jen kvůli tomu, aby připravovali automatizované testy – to už vše mohou pochopitelně otestovat manuálně. Znamená to tedy, že automatizace testů v SQA frameworku pro malou firmu nemá své místo? To si nemyslím, je ale potřeba se zamyslet, kde opravdu mohou automatizované testy čas ušetřit, aniž by k tomu bylo potřeba mnoho lidské práce. Při každém testování jsou vždy v každé iteraci opakovány některé rutinní činnosti, které zaberou poměrně dost času, ale je stále nutné je provádět – např. přihlášení do aplikace, ověření základních funkcí, ověření funkčnosti aplikace v několika prohlížečích zároveň atd. Tyto činnosti jsou jasnými kandidáty na automatizaci: jsou rutinní, nemění se nebo jen velmi málo, opakují se v každé iteraci a zaberou poměrně dost času. Pokud se manažerovi kvality a dalším účastníkům vývojového procesu podaří identifikovat několik takovýchto činností, tak se použití automatizovaného nástroje nabízí, protože pak může skutečně ušetřit testerům dosti práce. 59

Nyní jsou k dispozici i použitelné automatizační nástroje, které jsou zcela zdarma, takže náklady jsou v tomto případě opět hlavně v lidské práci. Něco více o nástrojích pro automatizované testování si povíme v případové studii.

5.6 Vlastní přínos Jak již jsem psal dříve, mnoho informací uvedených v návrhu frameworku vychází z mých vlastních zkušeností, které jsem načerpal při vytváření případové studie. V textu jsem tyto informace přímo neodlišoval, ale pro zájemce jsem vytvořil tabulku, kde jsou mé vlastní přínosy k návrhu frameworku přehledně shrnuty (Tabulka 5): Tabulka 5 - Vlastní přínosy v návrhu frameworku, zdroj: autor

Kapitola 5.1 OpenUP a proces vývoje

Vlastní přínos •

Přeložení termínů z OpenUP.

•

Identifikace disciplín a fází projektů relevantních pro SQA.

•

Popis vlastních zkušeností v kapitole 5.1.2 Role SQA ve fázích projektu

5.2 Řízení rizik

5.3 Tvorba požadavků

•

Přeložení termínů z OpenUP a RUP.

•

Vytvoření vzorového seznamu rizik.

•

Přeložení termínů z OpenUP a RUP.

•

Popis vlastních zkušeností s tvorbou a správou požadavků. Příklad konkrétních problémů, které mohou vyvstat.

•

Vytvoření vzorového slovníku.

•

Vytvoření vzorové vize.

•

Vytvoření vzorových diagramů s požadavky a stručný popis jejich použití.

5.4 Tvorba a správa případů užití a testovaných případů

•

Přeložení a vysvětlení relevantních termínů z RUP.

•

Vytvoření vlastního příkladu tvorby testovaného případu (příklad vychází z RUP).

•

Kapitola 5.4.3 Správa testovaných případů byla celá sepsána na základě mých vlastních zkušeností.

5.5 Testování

•

Přeložení relevantních termínů. 60

•

Kapitola 5.5.2 Testovací proces byla sepsána na základě mých vlastních zkušeností s implementací testovacího procesu ve firmě Cleverbee.

•

Na základě mých vlastních zkušeností jsem popsal použití nástroje pro správu chyb – Bugzilly (v kapitole 5.5.3 Správa chyb).

5.6 Automatizace testů

•

Popis vlastních zkušeností s automatizací testů.

6 Případová studie 6.1 Cíle a předmět případové studie Jak jsem již uvedl v části věnované cílům celé práce, budu se snažit vytvořit takový framework, který by umožňoval malým softwarovým firmám efektivně zajišťovat kvalitu svých produktů. Domnívám se, že pouhý popis frameworku je nedostatečný, protože nic neříká o tom, jak se daný framework osvědčil v praxi. Proto jsem se rozhodl popsat i konkrétní implementaci navrženého frameworku formou případové studie v konkrétní firmě. Touto firmou je Cleverbee s.r.o., kde v současnosti (listopad 2009) pracuji už druhým rokem na pozici Quality Engineer – tj. jsem zodpovědný za kvalitu vytvářených produktů. Studie tedy bude napřed zahrnovat popis firmy a situace v oblasti SQA, která v ní panovala před zavedením frameworku pro její řízení. Následuje pak studie věnovaná konkrétní implementaci ve firmě Cleverbee s.r.o. – bude zde popsáno, jak implementace probíhala, na jaké problémy jsem při ní narazil a budou se zde nacházet i rady pro firmy, které by dané součásti frameworku také rády implementovaly. Na konci případové studie je pak zhodnocení efektivity frameworku, soupis nákladů na framework a návrhy na případná další zlepšení. Cílem je tedy popsat implementaci frameworku takovým způsobem, aby ho podle ní byl schopný implementovat jakýkoli průměrně zkušený manažer kvality, ve firmě která je velikostí a fungováním podobná firmě Cleverbee s.r.o. Detailní rozbor technického řešení frameworku už je na osobách, které by ho v dané firmě implementovaly. Ještě je třeba uvést, jakého období se případová studie vlastně týká a jaký vliv jsem na implementaci SQA frameworku v tomto období měl. V době, kdy jsem přišel do firmy Cleverbee (říjen 2007), zde byla úroveň SQA na poměrně nízké úrovni, ale pod vedením tehdejšího manažera kvality se velmi rychle rozvíjela. V tomto období jsem se začal intenzivněji podílet na vytváření 61

frameworku, který by pomohl zlepšit řízení SQA ku prospěchu manažerů i testerů. Po odchodu manažera kvality jsem pak získal hlavní zodpovědnost za oblast SQA ve firmě a poté, co jsem začal psát tuto práci (v únoru 2008), tak jsem začal zavádění SQA frameworku intenzivněji dokumentovat a začal jsem do něj vkomponovávat poznatky získané ze zdrojů této práce. Detailnější popis mého působení ve firmě Cleverbee a jejího stavu SQA se nachází v kapitole Současná situace v SQA ve firmě.

6.2 Popis firmy Cleverbee s.r.o. Cleverbee s.r.o. je česko-švýcarská softwarová společnost, působící na trhu od roku 2000. Zabývá se převážně distribucí a vývojem IT řešení ve formě softwaru na zakázku. Daná řešení se zaměřují na správu informací, jejich integraci, procesní zpracování a také na prezentaci těchto informací pomocí systémů pro správu dokumentů a obsahu [22]. V současné době nabízí své služby a řešení v České republice, Švýcarsku, Rakousku a Německu. Dále udržuje a rozšiřuje své aktivity v ostatních zemích Evropy. Kompletní portfolio služeb firmy je toto [23]: •

Audit stávajících aplikací a IT infrastruktury

•

Konzultační činnosti

•

Poradenství v oblasti návrhu a rozvoje rozsáhlých IT řešení

•

Integrace dat, procesů a aplikací

•

Individuální vývoj aplikací

•

Poimplementační podpora a služby

•

Zajištění kvality

•

Školení Firma se v poslední době zaměřuje na řešení správy dokumentů (pomocí DMS systému

Alfresco) a na procesní a konverzní řešení postavené na platformách firmy Adobe (převážně systém Adobe Livecycle zaměřující se na automatizaci procesů, konverzi PDF atd.). Aplikace jsou obvykle vytvářeny v jazyce Java. Zákazníci firmy pocházejí z různých oblastí: státní správy, bankovnictví, pojišťovnictví, automobilového průmyslu, telekomunikací, školství atd. Cleverbee má v současnosti 25 zaměstnanců, přičemž tato firma prošla v poslední době výrazným zeštíhlením, ještě před dvěma lety se počet jejích zaměstnanců blížil 50.

62

Firma má 4 hlavní oddělení a jejich organizační struktura je vidět na následujícím obrázku (Obrázek 11):

Obrázek 11 - Organizační struktura firmy Cleverbee, zdroj: autor

Oddělení jsou tedy: Finance & Administration, Sales & Marketing, Services a Product Development. Nás bude zajímat hlavně oddělení třetí tj. Services, které má na starosti proces vývoje a údržby aplikací a jehož součástí je i oddělení Quality Assurance, které je zodpovědné za kvalitu ve firmě. Oddělení Services má dále celkem 6 pododdělení, která sdružují zaměstnance věnující se jednotlivým částem vývojového procesu. Oddělení jsou tato: • Project Management (PM) – v tomto oddělení pracují manažeři, kteří mají na starosti řízení jednotlivých vývojových projektů. • Consulting – v tomto oddělení pracují konzultanti a analytici, kteří mají na starosti sběr požadavků zákazníků, zmapování zákaznických procesů a návrh uživatelského rozhraní aplikací. • Architecture – v tomto oddělení pracují systémoví architekti, kteří navrhují strukturu software po technické stránce – jaké komponenty bude obsahovat, jak spolu budou tyto komponenty komunikovat atd. • Development - v tomto oddělení pracují vývojáři, kteří mají na starosti samotný vývoj tj. programování aplikací. • Quality Assurance (QA) - v tomto oddělení pracují testeři, kteří hledají chyby ve vytvořených aplikacích a zároveň mají na starosti podporu zákazníků.

63

• Systems Integration (SI) - v tomto oddělení pracují systémoví administrátoři, kteří se starají o technickou infrastrukturu ve firmě (servery, sítě) a zároveň pomáhají implementovat potřebnou infrastrukturu u zákazníka. Dále se o celkové firemní situaci rozepisovat nebudu, protože nás zajímá hlavně jedna oblast – SQA a to, jak se prolíná skrz jednotlivá oddělení firmy. Tomu se ale budeme věnovat v další kapitole.

6.3 Situace v SQA ve firmě Fáze fungování SQA ve firmě můžeme rozdělit do 3 období. V období od založení firmy (rok 2000) až do června roku 2007 nebylo SQA vnímáno jako samostatná disciplína, do firmy bylo najmuto několik nekvalifikovaných testerů, kteří v podstatě bez jakékoli dokumentace testovali aplikace, které dostali. V červnu roku 2007 nastoupil nový manažer kvality Zdeněk Jonáš, který se pokusil dát oblasti SQA směr a začal zavádět nové postupy a používání nových nástrojů. V průběhu jeho působení se tak v podstatě začaly rýsovat obrysy SQA frameworku, který by umožnil rozsáhlou podporu řízení kvality v celé firmě. V červenci roku 2008 poté Zdeněk Jonáš odešel a zodpovědnost za oblast kvality jsem převzal já. Ve spolupráci s managementem firmy jsem se pak pokusil navázat na jeho práci, integrovat dosavadní nástroje používané ve firmě a zavést nové postupy převzaté z obecně uznávaných metodik, tak aby dohromady tyto nástroje tvořily jeden celek – SQA framework. Na dalších stránkách tak budu převážně popisovat zavádění tohoto SQA frameworku v době psaní této práce (tj. od února 2009), budu se ale rozsáhle vracet i ke zkušenostem s implementací jednotlivých částí frameworku, které tomuto období předcházely. Je třeba si uvědomit, že tento framework není v žádném případě monolitický – skládá se z mnoha různých částí, které byly zaváděny postupně a paralelně. Jeho zavádění také stále pokračuje, rozhodně se nejedná o ukončený proces. V další části proto vždy zmíním, v jakém období byla ta která část implementována, aby si čtenář mohl uvědomit návaznosti mezi všemi komponentami frameworku.

6.3.1 Pracovní tým Přejděme nyní ke konkrétnímu popisu fungování firmy Cleverbee z hlediska SQA. Jak již bylo zmíněno výše, oddělením, které má ve společnosti na starost vývoj softwaru, je Services. Oblast SQA se tak v podstatě týká jen tohoto oddělení, protože členové obchodu nebo oddělení lidských zdrojů se na kvalitě výsledných produktů přímo nepodílejí. Pro lepší pochopení fungování vývojového procesu zde vkládám seznam pracovních pozice, které se ve firmě nacházejí: •

Projektový manažer – má na starosti vedení projektů, jedná se o hlavní řídící roli v oddělení Services. 64

•

Technický konzultant – řeší se zákazníky implementaci aplikací po technické stránce. Obvykle má na starosti činnosti, které nespadají přímo před vývojáře (např. databáze).

•

Business konzultant – řeší se zákazníky jejich požadavky a pak dokumentuje jejich procesy, podnikovou strukturu atd. a podle této dokumentace navrhuje uživatelský vzhled aplikace.

•

Systémový architekt – navrhuje aplikaci po technické stránce – její komponenty, moduly, strukturu atd.

•

Vývojář – programuje aplikaci. Může se podílet i na návrhu architektury a uživatelských rozhraní.

•

Senior vývojář – nejzkušenější vývojáři ve firmě, kteří mají na starosti vývoj těch nejobtížnějších částí softwaru.

•

Junior vývojář – vývojář-začátečník, který se teprve zaučuje a má na starosti pouze jednoduché programování.

•

Technický teamleader – řídí proces vývoje a rozděluje práci mezi několik vývojářů. Sám se na procesu vývoje podílí (obvykle se jedná zároveň o Senior vývojáře)

•

Tester – testuje aplikace a píše k nim dokumentaci.

•

Quality engineer – má na starosti přípravu testovacích plánů a složitější testy – zátěžové a automatizované testování.

•

Manažer kvality – vedete tým testerů a quality engineerů. Je zodpovědný za koncepci kvality v celé firmě.

•

Systémový administrátor – spravuje systémy ve firmě a technickou infrastrukturu. Nás pochopitelně zajímají nejvíce 3 role, které spadají pod oddělení QA: tester, quality

engineer a manažer kvality. Je ale třeba si uvědomit, že oblast SQA se prolíná všemi oblastmi a to, jak zajistit tvorbu kvalitního softwaru, který splňuje požadavky zákazníků, musí ve velké míře řešit i např. projektoví manažeři, konzultanti nebo techničtí team leadeři. Co se týče obsazenosti QA oddělení, tak nyní zahrnuje pouze dva lidi včetně mě – oba na pozici Quality Engineer. V době mého nástupu do firmy, kdy v ní byl zaměstnán téměř dvojnásobek současného počtu lidí, mělo QA oddělení čtyři členy včetně mě: jednoho manažera kvality, jednoho quality engineera a dva testery. Po zhruba půl roce od mého příchodu do firmy odešel jeden tester, a jak již bylo zmíněno v červenci roku 2008 odešel manažer kvality, načež oddělení nadále fungovalo jen o dvou lidech. Jednotlivé součásti frameworku tak byly v průběhu jeho implementace používány variabilním množstvím lidí.

65

6.3.2 Úroveň používaných procesů Můžeme říci, že před nástupem nového manažera kvality v roce 2007 nebyly SQA procesy zdokumentovány v podstatě vůbec. Všechna dokumentace byla vytvářena ad hoc – tester na konci procesu testování sepsal chyby způsobem, který mu zrovna přišel nejlepší. Co se týče úrovně procesů ve firmě, tak vývojové procesy byly do určité míry zdokumentovány – bylo určeno, kdo má jaké zodpovědnosti a jak by na sebe měly jednotlivé fáze vývoje navazovat. Tyto informace byly ale pouze uloženy v podnikovém archivu a nebyly nijak propagovány mezi zaměstnance firmy, kteří většinou netušili, že nějaká takováto dokumentace vůbec existuje. SQA pak bylo zmíněno pouze jako fáze testování, která měla proběhnout až poté, co byl vývoj víceméně ukončen. Pokud bych tedy aplikoval znalosti z CMMI, které bylo rozepsáno výše, zhodnotil bych úrovně způsobilosti procesních skupin ve firmě takto: •

Vývojové procesy – procesy byly zdokumentovány, a tedy by odpovídaly úrovni způsobilosti 2 (Managed) dle CMMI. Jak jsem již zmínil, tak v mnoha případech zaměstnanci o tomto zdokumentování vůbec nevěděli a tedy se definovanými procesy neřídili. Úroveň vývojových procesů před červnem 2007 ve firmě bych tedy hodnotil někde mezi úrovní 2 a 1 (Initial).

•

SQA procesy – tyto procesy nebyly zdokumentovány vůbec, a tedy se pochopitelně členové QA oddělení neměli čím řídit. SQA procesů byly tedy před červnem 2007 náhodné a chaotické, což dle CMMI odpovídá úrovni 1 (Initial). O tom, jak v průběhu implementace frameworku vzrůstala úroveň odpovídajících procesů, se

zmíním v dalších kapitolách. Podívejme se nyní, jak vypadala úroveň procesů v jednotlivých oblastech SQA.

6.3.2.1 Úroveň řízení rizik Ve firmě Cleverbee před implementací frameworku žádný specializovaný systém pro řízení rizik neexistoval. Samozřejmě si ale manažeři uvědomovali, že je třeba vědět, jaká rizika projektu hrozí, aby bylo možné odhadnout, jak bude daný projekt náročný. Existoval tedy určitý seznam potenciálních rizik, který byl vždy vytvářen pro každý projekt ve fázi podání nabídky. Tento seznam v podstatě zdůvodňoval zákazníkovi, proč je cena taková, jaká je. Odhadovaná cena za projekt totiž bývá navýšena v závislosti na tom, jaká rizika projektu hrozí – vyšší rizika znamenají vyšší pracnost. Seznam těchto rizik neměl žádný předem daný formát, byl vytvářen v závislosti na požadavcích dané nabídky. Na seznamu rizik se obvykle podílel obchodník a konzultant. S riziky už se po vytvoření nabídky většinou dále nepracovalo a seznam rizik obvykle zůstal nepovšimnut někde na projektovém disku. Žádná strategie, která by říkala, jak se rizikům vyhnout, vytvářena nebyla. 66

Z hlediska CMMI bych tak označil úroveň způsobilosti procesu řízení rizik jako 1. Proces je sice vykonáván a podporuje vytváření odpovídajících produktů, ale není podrobněji zdokumentován a ve firmě nemůžeme vysledovat snahu o jeho optimalizaci. Takováto úroveň procesu je pochopitelně nedostatečná a proto by jí implementace SQA frameworku měla pomoci.

6.3.2.2 Úroveň tvorby a správy požadavků Ve firmě Cleverbee byly požadavky pochopitelně sledovány po celou dobu její existence, protože bez zapsaných požadavků by byl vývoj v podstatě nemožný. Nedá se ale říci, že by existoval nějaký propracovaný systém jejich zaznamenávání – požadavky byly prostě sepsány a v průběhu vývoje tým kontroloval, jestli systém požadavkům odpovídá. Častý byl ale případ, že se na požadavky pozapomnělo a použity znovu byly až ve fázi testování, kdy byl systém proti nim ověřován. Tehdy se samozřejmě často zjistilo, že některé komponenty systému požadavkům neodpovídají, a bylo nutné je přeprogramovat. Pro zaznamenávání požadavků byl používán Microsoft Excel, což není příliš šťastná volba, protože se v něm obtížně zaznamenávají vazby na ostatní požadavky a jeho nevýhodou je také, že ho nemůže zároveň editovat více osob, což činí týmovou práci obtížnou. Požadavky v něm byly uvedeny jako nekategorizovaný výčet bez podrobnějších detailů. Kromě požadavků nebyl vytvářen žádný dokument, který by umožňoval si v jednoduchém formátu přečíst základní přehled funkcionality systému a zjistit také jeho účel. Jediné, co se mu blížilo, byla obchodní nabídka, vytvářená obchodníky ve spolupráci s konzultanty a technickými vedoucími. V této nabídce bylo obvykle stručně sepsáno, co má systém umět, k čemu má sloužit a jaká je cena za jeho jednotlivé komponenty. Součástí nabídky také byl návrh smlouvy, který obsahoval tzv. akceptační kritéria. Tato kritéria definovala, co má systém splňovat, aby ho zákazník od dodavatele převzal. Akceptační kritéria se tak vlastně stala automaticky prvními požadavky a to rovnou těmi nejdůležitějšími – bez jejich splnění nemohl být systém zákazník akceptován. Jak tedy můžeme zhodnotit proces zaznamenávání a správy požadavků z hlediska CMMI? Podobně jako u řízení rizik, bych úroveň způsobilosti procesu ohodnotil jako 1 – firma proces provádí, ale nijak zvlášť ho nedokumentuje a nepokouší se o jeho vylepšení. Takovouto úroveň považuji u takto důležitého procesu za jednoznačně nedostatečnou – je třeba zjistit, jak je možné ji zlepšit.

6.3.2.3 Úroveň tvorby případů užití a testovaných případů Ve firmě Cleverbee se případy užití a testované případy používaly už před zavedením SQA frameworku. Případy užití byly také jednou ze základních komponent návrhu systému, tak jak by tomu mělo být. Neexistoval ale žádný předem daný systém, který by říkal, jak je psát. Každý konzultant si psal případy užití svým vlastním způsobem a vývojáři a testeři byli nuceni se jejich individuálním 67

stylům přizpůsobovat. Chyběla také provázanost případů na ostatní komponenty systému, proto bylo často těžko dohledatelné, co ten který uživatelský prvek vlastně dělá. Uživatelské případy byly obvykle napsány na začátku vývojového cyklu společně s požadavky, ale na rozdíl od požadavků se pak většinou zapomínalo na jejich aktualizaci. Výsledkem tak bylo, že ve fázi testování už se případy užití velmi rozcházely s tím, co bylo skutečně testováno a testeři, tak často tápali a nevěděli, které chování je žádoucí a které ne. Co se týče testovaných případů, tak ač byly u některých projektů vytvářeny, zdaleka to nebylo pravidlem. Bylo dost projektů, ke kterým se testeři dostali až na jejich konci a neměli tedy čas sepisovat případy a testovat podle nich. Výsledkem bylo, že některé funkce aplikace nebyly testovány a chyby, které se v nich vyskytovaly, byly odhaleny až zákazníkem, což vrhalo na projektový tým špatné světlo. Pro manažera kvality pak bylo obtížné tým testerů řídit, protože nevěděl, co už bylo otestováno a co ne. Podobně jako u případů užití, také platilo, že neexistoval přesný systém jejich zápisu, a každý tester si vytvářel svoje testované případy. Pokud tak více testerů pracovalo na jednom projektu, tak se jejich nesourodé případy slučovaly dohromady velmi obtížně. Do oblasti správy testovaných případů spadá v podstatě jediný specializovaný SQA nástroj, který byl před implementací navrženého frameworku používán. Byla jím interně vyvíjená aplikace Clevertrack, která byla určena ke správě testovaných případů a zápisu chyb. Ani tento nástroj nebyl ale využíván příliš hojně, a navíc se jednalo v té době v podstatě o betaverzi, která sama obsahovala hodně chyb. Úroveň procesů dle CMMI v oblasti tvorby případů užití a testovaných případů bych tedy ohodnotil také jako 1 – procesy nebyly ani v tomto případě dostatečně zdokumentovány.

6.3.2.4 Úroveň testování SQA oddělení se samozřejmě o testování ve firmě staralo vždy, nás ale zajímá především, na jaké úrovni byly dříve odpovídající testovací procesy – jak byly zdokumentovány, jaké byly plány k jejich optimalizaci, čím byly podporovány atd. V tomto případě musím konstatovat, že úroveň testovacích procesů byla dříve dost slabá. Chyběl hlavně centrální nástroj pro správu chyb, který v té době částečně simuloval interně vyvíjený Clevertrack, jenž byl ovšem sám stále ve vývojovém procesu. Nějaká metodika, podle které by se testovalo, v tu dobu také neexistovala. Na testery se před příchodem nového manažera kvality nahlíželo přesně tak, jak bylo uvedeno v úvodu této práce: jako na nepříliš kvalifikované zaměstnance, kteří bez zapojení vlastní iniciativy na konci vývojového procesu aplikaci projdou, zapíší chyby a tím jejich zapojení končí. Testeři do

68

úvodních fází vývojového procesu vůbec nevstupovali, aplikaci dostávali k testování, až když už byla téměř hotová. Nějaké další podpůrné nástroje (např. pro automatizované testovaní) zapojovány nebyly. Testeři ani neměli žádné znalosti o nástrojích používaných v analýze a ve vývoji a obtížně se tak orientovali v UML diagramech, v kterých byla zdokumentována většina aplikací. Úroveň testovacích procesů tedy opět hodnotím jako 1 – procesy existují, provádějí se, ale dokumentace chybí.

6.4 Implementace frameworku Nyní popíši, jak probíhala implementace frameworku a pokusím se zhodnotit její výsledky. Napřed stručně popíši zkušenosti s implementací jednotlivých oblastí frameworku a na konci sepíši celkové zhodnocení a shrnutí nákladů na framework. Zároveň popíši konkrétní nástroje, které jsme se rozhodli v rámci frameworku použít.

6.4.1 Řízení rizik 6.4.1.1 Implementace Zavedení seznamu rizik se ve firmě Cleverbee podařilo prosadit a v současnosti je už tento seznam při vývoji používán téměř dva roky. Šablona pro seznam rizik byla získána z OpenUP a seznam rizik vypadá stejně jako ten uvedený v návrhu frameworku. Co se týče zhodnocení přínosu seznamu rizik, tak jeho přesné vyčíslení je obtížné – nedá se říci, kolik přesně rizik díky němu bylo odvráceno, a ke kolika z nich by nedošlo, i kdyby seznam nebyl používán. Pozoroval jsem ale, že jeho zavedení vedlo k podstatně většímu zájmu o rizika projektu a tím pádem o jeho kvalitu než dříve. Seznam s riziky představoval jednoduše přístupný a stručný dokument, který se dal hned vytisknout a konzultovat. Díky tomu byla možná rizika na projektu řešena mnohem častěji než dříve. K tomu přispělo i dodržování zásad práce se seznamem rizik dle OpenUP tj. průběžná revize a úpravy seznamu rizik. Použití seznamu rizik se ukázalo být výhodné i z cenového hlediska – náklady na jeho implementaci jsou ideální.

6.4.1.2 Použité nástroje Pro řízení rizik nebyly použity žádné specifické nástroje

69

6.4.2 Tvorba požadavků 6.4.2.1 Implementace Shrňme si nyní, jaké změny v rámci implementace řízení požadavků byly ve firmě Cleverbee provedeny: •

Bylo zavedeno používání vize.

•

Strukturovaný přístup k psaní a kategorizaci požadavků.

•

Požadavky jsou zapisovány v nástroji Enterprise Architect.

•

Požadavky jsou provazovány na odpovídající případy užití a další komponenty systému. Celkový přínos zavedení vize se dá obtížně hodnotit, ale mohu to provést z pozice testera,

kterou jsem zastával na některých projektech, na kterých byla vize používána. Když jsem disponoval vizí, tak jsem ušetřil čas při studiu podkladů pro testování, protože jsem byl po přečtení několika stránek schopen rychle pochopit, co má aplikace dělat a jaká atributy systému jsou pro zákazníka nejdůležitější. Vzhledem k tomu, že před začátkem testování nebyla obvykle dispozici žádná uživatelská dokumentace, byla vize jedinou možností, jak si přečíst základní požadavky na systém na jednom místě. Podobně vize šetřila čas ostatním testerům a i dalším osobám, které se dostávaly do projektu v jeho průběhu. Co se týče nového systému vytváření požadavků, došlo po jeho zavedení k nepochybnému vzrůstu kvality aplikace. Z pohledu testera bylo výrazně jednodušší testovat zákaznické požadavky, protože se dalo dohledat, které části systému byly na základě toho daného požadavky vytvořeny. V aplikaci Enterprise Architect je pak možné zjistit, kde je každý požadavek navázaný – v kterých diagramech byl použit. Pokud testeři (nebo jiní účastníci projektu) zjistili, že požadavek není nikde navázán, okamžitě se začalo zjišťovat, proč tomu tak není, a jestli byl požadavek vůbec někde v aplikaci implementován. Takto se podařilo odhalit některé problémy, které by při odevzdání projektu mohly znamenat jeho nepřijetí.

6.4.2.2 Nástroje Jak jsem již popsal v části věnované návrhu frameworku, pro správu požadavků doporučuji použít nástroj, který se zároveň používá pro správu. Již před implementací frameworku byl ve firmě Cleverbee pro vytváření UML modelů používán Enterprise Architect od australské společnosti Sparx Systems11. Jedná se o komerční

11

Sparx Systems, http://www.sparxsystems.com.au/

70

aplikaci, která ale disponuje širokým portfoliem funkcí za přístupnou cenu – licence se dají koupit už od 135 dolarů za kus [17]. Portfolio funkcí Enterprise Architectu zahrnuje: •

Kompletní podpora modelovacího jazyka UML 2.1.

•

Kompletní podpora modelovacího jazyka BPMN 1.0.

•

Správa požadavků.

•

Vícenásobný přístup uživatelů k souboru s modely a jednotlivým modelům v něm (soubor je uložen jako MDB databáze). Aplikace podporuje i modifikaci jednoho diagramu více uživateli zároveň.

•

Generování dokumentů (např. ve formátu RTF a HTML) s podporou šablon.

•

Generování programového kódu přímo z modelů.

Všechny výše zmíněné vlastnosti dobře podporují fungování našeho SQA frameworku. Enterprise Architect v sobě dokonce obsahuje i nástroje pro projektový management (např. sledování úkolů) nebo odhad ceny projektu. Tyto moduly se pak dají využít při případném rozšíření frameworku o části podporující projektové řízení – ve firmě Cleverbee zatím k takovémuto rozšíření nedošlo. Jak v Enterprise Architektu vypadají diagramy požadavků a případů užití jsem již ukázal, podívejme se ještě, jak v něm vypadá taková struktura projektu (Obrázek 12):

Obrázek 12 - Ukázková struktura projektu v nástroji Enterprise Architect, zdroj: autor

71

Celou tuto strukturu je pak možné ideálně vyexportovat do nástroje pro správu testovaných případů. Dalších možných programů pro UML modelování, které by se daly použít jako náhrada Enterprise Architektu, je ve skutečnosti velmi mnoho, ale nákup jejich licencí je ve většině případů velmi nákladný – např. ceny za nejpoužívanější UML nástroj Sybase Powerdesigner12 začínají na hranici 3000 dolarů za jednu licenci[24], což je více než dvacetinásobek ceny Enterprise Architektu. Samozřejmě existuje i množství nástrojů, které jsou zcela zdarma, ale z mých zkušeností se žádný z nich zatím komerčním nástrojům nevyrovná – portfolio jejich funkcí je výrazně tenčí. UML modely jsou navíc natolik zásadním zdrojem návrhu softwarových systémů, že se do jejich pořízení určitě vyplatí investovat i firmě s limitovanými finančními prostředky. Pokud má ale někdo zájem prozkoumat i možnosti volně dostupných nástrojů, zde jsou některé příklady: StarUML13, ArgoUML14, NetBeans (v plné verzi 6.0)15 a další. Určitým problémem při používání Enterprise Architektu může být, že se jedná o aplikaci pro operační systém Windows. Vývojářské firmy, které používají operační systém Linux, budou tedy asi nuceny využít jiný nástroj např. Umbrello UML Modeller16.

6.4.3 Tvorba a správa případů užití a testovaných případů 6.4.3.1 Implementace Firma Cleverbee provedla v oblasti případů užití a testovaných případů během implementace frameworku velké množství změn. Nejvýznamnější z nich jsou tyto: •

Byl vytvořen jednotný formát pro jejich psaní.

•

Bylo vytvořeno jednotné úložiště – modelovací nástroj Enterprise Architect.

•

Případy užití a testované případy byly v modelech navazovány na ostatní prvky.

•

Tvorba testovaných případů začala zároveň s tvorbou případů užití. Změny byly provedeny na základě návrhu SQA frameworku, ne všechny ale byly

implementovány v plné míře. Ukázalo se například, že SQA oddělení je příliš malé na to, aby jeho

12

Sybase Power Designer, http://www.sybase.com/products/modelingdevelopment/powerdesigner.

13

StarUML, http://staruml.sourceforge.net/en/

14

ArgoUML, http://argouml.tigris.org/

15

NetBeans, http://netbeans.org/

16

Umbrello UML Modeller, http://uml.sourceforge.net/

72

členové dokázali popsat testované případy v takové míře, v jaké je definuje RUP. Nakonec se tedy přešlo k zjednodušené verzi, kdy každý testovaný případ byl reprezentován případem užití rozšířeným o podmínky, výstupy a detailnější popisy uživatelského rozhraní. Testeři do případů užití také dopisovali situace neodpovídající běžnému užití – např. zadávání příliš dlouhých řetězců, vkládání velkých souborů atd. Tato forma testovaných případů se poměrně osvědčila, protože bylo možné je psát velice rychle – stačilo vzít podklady od konzultantů (v podobě případů užití a případných dalších požadavků) a rozšířit je. Negativem bylo, že takto psané testované případy nebyly nikdy dost podrobné, a tak stále docházelo k tomu, že některá funkcionalita nebyla otestována. Oproti předchozímu stavu se však stále jedná o jasné zlepšení. Osobně jako velký přínos vidím, že byly změněny interní procesy, tak že testované případy začaly být vytvářeny zároveň s případy užití. Tato zdánlivě drobná změna, vyústila v to, že testeři byli zapojeni do vývojového procesu od samého začátku a mnohem lépe komunikovali s celým vývojovým týmem.

6.4.3.2 Nástroje Pro tvorbu případů užití a testovaných případů (stejně jako pro správu případů užití) se začal používat Enteprise Architect, který už byl popsán dříve. Podívejme se ale ještě, jak v něm vypadá struktura vytvořená podle rad uvedených v návrhu frameworku:

73

Obrázek 13 - Struktura případů užití v nástroji Enterprise Architect, zdroj: autor

Co se týče správy testovaných případů, tak pro ni si firma Cleverbee vyvinula vlastní nástroj Clevertrack. Jedná se o webovou aplikaci, kterou Cleverbee nabízí i komerčně formou Software as a Service tj. servery s aplikací běží u prodávající firmy a zákazníci k ní přistupují vzdáleně pomocí webového prohlížeče. Clevertrack byl vyvíjen už před implementací SQA frameworku, ale do použitelného stavu se dostal v podstatě až během ní. Clevertrack nabízí většinu standardních funkcí: •

možnost tvorby testovaných případů přímo v aplikaci

•

uživatelské role s různými právy na projektech

•

tvorba testovacích cyklů

•

tvorba skupin testů

•

přiřazování chyb k testovaným případům

•

funkce podporující současnou spolupráci několika testerů

Funkce, které jsou ale spíše unikátní, a které dobře zapadají do definovaného frameworku jsou tyto: •

import testovaných případů ve formátu XMI (tento formát je podporován i Enterprise Architektem) 74

•

propojení s Bugzillou a dalšími nástroji pro správu chyb

•

tvorba PDF reportů z testovacích cyklů

Jak vypadá testovací obrazovka nástroje Clevertrack, je vidět na následujícím obrázku (Obrázek 14):

Obrázek 14 - Testovací obrazovka nástroje Clevertrack, zdroj:[25]

Povšimněme si hlavně možnosti přiřazení chyb k testovaným případům, díky které se dá jednoduše dohledat, jaký postup k výskytu chyby vedl.

6.4.4 Testování 6.4.4.1 Implementace V oblasti testování došlo k nejvýraznějším změnám v oblasti testovacích nástrojů, které byly zavedeny. Nově používaný nástroj pro správu chyb (Bugzilla) se stal nakonec jednou z nejpoužívanějších aplikací ve vývojovém oddělení a začal se postupně využívat i jako nástroj projektového managementu – na sledování výkonnosti zaměstnanců, úkolování, vykazování hodin atd. Velkým přínosem bylo i zdokumentování testovacího procesu. Testeři nyní mají jasně definovaný sled činností, které mají provést před tím než započne samotné testování produktu: •

Studium projektové dokumentace a případů užití.

75

•

Psaní testovaných případů v modelovacím nástroji.

•

Export do nástroje pro správu testovaných případů.

•

Vytvoření odpovídajícího testovacího cyklu. Manažer kvality je tak nyní schopný jednoduše sledovat, v jaké fázi testování každý projekt je.

V rámci implementace SQA frameworku se plánovalo i využití automatizovaného testování, tento plán ale zatím zůstal na půl cesty. Původně se očekávalo, že testy na některých projektech se podaří zautomatizovat takovým způsobem, že na nich nebudou vůbec potřeba testeři. Ukázalo se ale, že kompletní pokrytí projektu automatizovanými testy zabere jejich tvůrcům více času, než by trvalo samotné manuální testování. V současnosti se tak automatizované testy používají jen pro základní funkce aplikace (např. přihlášení) na vybraných projektech.

6.4.4.2 Nástroje V rámci implementace frameworku bylo třeba zvolit pro firmu Cleverbee vhodný nástroj pro správu chyb. Jak již bylo zmíněno, nástroje pro správu chyb jsou jedním ze zásadních pomocníků SQA oddělení a dají se využít i např. v oblasti projektového řízení. Naštěstí je jich velké množství dostupné zdarma a většinou jsou plně dostačující pro potřeby malé firmy. Nakonec byla během implementace frameworku vybrána Bugzilla vyvíjená nadací Mozilla Foundation, která patří mezi volně dostupné nástroje. Jedná se o webovou aplikaci, takže Bugzilla je dostupná na všech platformách, pro její použití stačí webový prohlížeč. Je ale nutné ji nainstalovat někde lokálně a pak ji zpřístupnit všem uživatelům v dané podnikové síti. Potřeba je funkční aplikační server pro programovací jazyk Perl 5 a databázový systém (buď MySQL, PostgreSQL nebo Oracle) [26]. Jednou z výhod Bugzilly je, že je velice rychlá – většina stránek se zobrazuje v jednoduchém HTML téměř bez grafiky. Nabízí také svým uživatelům rozsáhlé možnosti konfigurace a zvláště vyhledávání – je možné vyhledávat chyby podle všech jejich parametrů a výsledky si ukládat pro další použití. Jak vypadá takový vyhledávací dialog v Bugzille je vidět na dalším obrázku (Obrázek 15):

76

Obrázek 15 - Vyhledávací dialog v nástroji Bugzilla, zdroj: autor

Podívejme se nyní ještě, jak vypadá detail zadaného požadavku (Obrázek 16):

77

Obrázek 16 - Ukázka detailu požadavku v nástroji Bugzilla, zdroj: autor

Povšimněme si zvláště možností vykazovaní hodin – je možné zde nastavit deadline (tj. termín), odhadovaný počet hodin a pak sledovat, kolik hodin už bylo skutečně odpracováno. Zajímavá jsou také pole „Požadavek X závisí na“ a „Požadavek X blokuje“, kterými je možné vyjadřovat závislost mezi požadavky a vytvářet tak stromovou strukturu požadavků, o které již byla řeč v kapitole o správě chyb. Ve firmě Cleverbee se postupem času začaly používat obě tyto možnosti: vývojáři i testeři vykazovali na chyby čas, který strávili jejich řešením, a byla též vytvořena stromová struktura chyb s úrovněmi: Milník->Komponenta->Případné subkomponenty->Chyby. Je třeba zdůraznit, že Bugzilla je pouze jednou z možností a nedá se říci, že nutně tou nejlepší. Dle mých zkušeností je její nevýhodou poměrně velká složitost – obsahuje množství voleb a novým uživatelům trvá dlouho, než se v nich zorientují a naučí se ji používat. Spoustě uživatelů se také nelíbí její strohý design. Některé firmy tak budou možná chtít využít jiné nástroje.

78

Existuje ale velké množství podobně kvalitních a zdarma dostupných alternativ, které mohou někomu vyhovovat lépe. Jedná se např. o již dříve zmíněný Trac a Mantis. Co se týče automatizovaného testování, zvolila firma Cleverbee jako nástroj Selenium17, což je sada zdarma dostupných nástrojů sloužících k zaznamenávání a spouštění automatizovaných testů. Selenium se skládá z těchto dvou hlavních nástrojů [27]: •

Selenium IDE

•

Selenium Remote Control Selenium IDE je rozšíření webového prohlížeče Firefox, které umožňuje zaznamenávat

činnosti uživatele a poté je opět přehrát. Záznamy činností se dají ukládat ve formátu HTML. Zaznamenané testy je možné exportovat jako skripty do několika programovacích jazyků: Java, Groovy, C#, Perl, PHP, Python a Ruby. Výsledné testy pak mohou být použity nástrojem Selenium Remote Control, který umožňuje automatizované spouštění testů bez zásahu uživatele. Selenium server tedy provede po spuštění všechny zadané příkazy a pak informuje uživatele o výsledku. Selenium Remote Control nemá žádnou grafickou nadstavbu, ale testy pro něj je možné vytvářet ve všech vývojových prostředích používaných běžně s výše zmíněnými programovacími jazyky. Jak vypadá Selenium IDE, sloužící k zaznamenávání činností uživatele, je vidět na dalším obrázku (Obrázek 17):

17

Selenium, http://seleniumhq.org/

79

Obrázek 17 - Ukázka zaznamenávání činností uživatele v Selenium IDE, zdroj: autor.

6.5 Zhodnocení frameworku jako celku Zavádění nového SQA frameworku trvá od června 2007, takže k datu této práce (listopad 2009) už 29 měsíců. Tento proces stále není u konce, plánuje se další rozšiřování možností frameworku – hlavně co se týče hlubšího propojení jednotlivých nástrojů pomocí interně vyvinutých komponent. Za dva a půl roku ale došlo k bezpochyby v důsledku implementace frameworku k velkým změnám a kvalita SQA ve firmě vzrostla. Jako důkaz může posloužit, že od půlky roku 2008 (tj. od doby, kdy se povedlo zavést základní části frameworku) nedošlo k situaci, kdy by zákazník odmítl nějaký projekt kvůli nedostatečné kvalitě, přičemž dříve se takovéto případy stávaly. Zde je shrnutí některých základních přínosu frameworku: •

Jasnější dokumentace požadavků, případů užití a testovatelných částí aplikace.

•

Ušetřený čas vývojářů a testerů, kteří se v nich mohou snadněji orientovat.

•

Snadnější komunikace se zákazníkem (díky využívání slovníku, vize atd.).

•

Manažeři získali lepší přehled o procesu vývoje a větší možnosti řízení kvality produktů (pomocí reportů o chybách, dokumentace procesů atd.). 80

•

Byly zdokumentovány procesy a jasně odlišeny vazby mezi nimi.

•

Podařilo se zapojovat testery do procesu vývoje od samého začátku, takže nedocházelo k situacím, kdy by po dlouho nebyli využiti a naopak na konci práci nestíhali.

•

Dařilo se lépe dodržovat projektové termíny díky jasně zdokumentované návaznosti procesů a existenci nástrojů, které umožnily jejich sledování. Přínosem, který nebyl původně plánovaný, byla podpora projektových manažerů ve firmě.

V průběhu implementace se ukázalo, že nástroje, které měly původně sloužit pouze k podpoře řízení SQA v sobě skrývají i možnosti podpory projektového managementu. Některé z těchto možností byly nakonec využity a tak např. Bugzilla nyní slouží i k vykazování hodin a úkolování zaměstnanců (tj, nejen k zapisování chyb). Některé projektové nástroje pak byly upraveny tak, aby komunikovaly s nově zavedenými SQA nástroji – např. již dříve používaný Microsoft Project byl navázán na Bugzillu, takže úkoly vytvořené v něm se rovnou vytvářely i v Bugzille. Tyto úpravy jsem ale v této práci nepopisoval, protože nespadají do oblasti SQA. Trochu problematické se ukázaly snahy o automatizaci testování, ze začátku se plánovalo, že se podaří zautomatizovat většinu projektů a tím pádem bude ve firmě dlouhodobě potřeba jen malé množství testerů. Tvorba automatizovaných testů se ale ukázala být tak pracnou, že se od těchto plánů nakonec upustilo. K alespoň částečné implementaci automatizace došlo, ale jen u malého množství projektů – u takových, kde je produkováno velké množství verzí, které musí být neustále testovány. U těchto projektů automatizace smysl má, protože testovací činnosti jsou rutinní a nemění se, a není tedy nutné testy stále přepisovat. Co se týče kvantifikace přínosů frameworku, tak ta je velmi obtížná. Nedá se přesně říci, které náklady byly ušetřeny v důsledku implementace frameworku. Navíc při snaze o nějaký přesnější odhad pracujeme s velkou neurčitostí. Je možné, že některý projekt dopadl úspěšně jen díky frameworku, protože byly nalezeny chyby, které by zabránily akceptaci. Nejsme to ale nikdy schopni říct se stoprocentní jistotou. Náklady na framework není také lehké vyčíslit, pokusil jsem se o to ale v další kapitole. Většinou se jedná o náklady představující práci lidí, kteří framework implementovali.

6.6 Náklady na framework V následující tabulce jsou shrnuty náklady na implementaci seznamu rizik ve firmě, co se týče interní práce (v člověkodnech) a cenách licencí (v korunách) – viz Tabulka 6:

81

Tabulka 6 - Náklady na implementaci SQA frameworku, zdroj: autor

Aktivita

Interní práce/

Licence/CZK

člověkodny Vytvoření šablon dokumentů a návodů

5

na jejich použití Prezentace návrhu SQA frameworku a

5

diskuze Instalace a konfigurace Bugzilly

3

Příprava struktury Enterprise

2

Architektu Instalace a konfigurace Clevertracku

2

Instalace a konfigurace Selenium IDE

3

a Selenium RC Školení na používání nástrojů

15 33 17718

Zakoupení Enterprise Architektu – 10 1 licencí Propojení nástrojů ve frameworku

4

Celkem

40

31 777

Co se týče nákladů na jeden člověkoden, budou se velmi lišit firmu od firmy. Ve firmě Cleverbee je vyčíslíme jako ušlý zisk – kolik by lidé alokovaní na projektu SQA frameworku byli schopni vydělat, kdyby pracovali na jiném projektu pro platícího zákazníka. V tom případě by byly průměrné náklady na člověka a den cca 8 000 korun, od čehož se dostáváme k celkovým nákladům na framework v hodnotě 351 777 CZK. Náklady byly reálně ale pravděpodobně vyšší, protože se jich část rozplynula v dalších projektech. Celkově by ale náklady měly odpovídat mým původním plánům, kdy jsem chtěl, aby celková cena frameworku byla nižší než 500 000 CZK.

18

Cena za jednu licenci: 189$, zdroj: [17]; Kurz dolaru: 17,554, zdroj: [16]

82

Náklady na roční údržbu momentálně nejsem schopen přesně vyčíslit, protože framework je stále ve vývoji a tak se tyto náklady často kryjí s náklady na jeho implementaci. Pokud ale vezmeme v potaz, že údržba zahrnuje pouze aktualizaci šablon, reinstalaci nástrojů atd., tak předpokládám, že by cena

za

ní

neměla

přesáhnout

10

člověkodnů

-

tedy

v přepočtu

80 000

CZK.

7 Závěr 7.1 Shrnutí výsledků Z výsledků uvedených v kapitolách věnovaných celkovému zhodnocení frameworku a nákladům na něj jsem dospěl k závěru, že implementace frameworku ve firmě Cleverbee byla úspěchem. Podařilo se dodržet plánované náklady a kvalita softwarových produktů firmy bezpochyby vzrostla. Jako indikátor úspěchu můžeme použít i množství úspěšně dokončených projektů – po uplynutí jednoho roku od počátku implementace nedošlo k situaci, kdy by nějaký projekt nebyl akceptován. K tomu pravděpodobně přispělo i zlepšení pracovní atmosféry ve firmě, v důsledku optimalizace procesů se o kvalitu začalo zajímat stále více zaměstnanců, a snížil se počet výskytů případů, kdy byl do testování odevzdán nekvalitní produkt. Ne všechno bylo implementováno v rozsahu definovaném v prvotním návrhu (např. na tvorbě a správě testovaných případů by se dalo ještě zapracovat), ale myslím si, že mohu říci, že životaschopnost frameworku se prokázala. Pro ostatní malé firmy tak může tato práce sloužit jako vhodný základ pro tvorbu jejich vlastního frameworku. Rozhodně bych jim ale v tomto případě doporučil i rozsáhlejší studium podkladů uvedených v seznamu citované literatury. V mnoha případech jsem se totiž dostal opravdu jen na povrch dané problematiky. S čím nejsem úplně spokojen, je přesné vyčíslení přínosů frameworku, které jsem dříve plánoval. Doufal jsem, že budu schopný určit, kolik peněz framework firmě ušetřil, a jak se podepsal na výskytu chyb na projektech. Ukázalo se, že SQA se prolíná s ostatními oblastmi tak úzce, že se nedá přesně říct, která úspora resp. zlepšení padá na vrub SQA, a která už je dílem ostatních oddělení. Číselných ukazatelů tak v této práci není takové množství, v jaké jsem původně doufal.

83

7.2 Splnění stanovených cílů Tabulka 7 - Úroveň splnění cílú práce, zdroj: autor

Cíl

Úroveň splnění

Vytvoření

návrhu

SQA frameworku

vhodného Splněno (viz kapitola 5. Návrh frameworku) pro

malé

firmy Vytvoření

případové

studie, Splněno (viz kapitola 6. Případová studie)

která ukáže vytvoření a užití SQA frameworku v praxi U obou hlavních cílů mohu říci, že jsem je splnil v rozsahu, který jsem si předsevzal v úvodu práce. Obě součásti práce (návrh frameworku a případová studie) by se ale ještě daly rozhodně rozpracovat do větší hloubky.

7.3 Můj přínos Původně očekávané hlavní přínosy (Tabulka 8): Tabulka 8 - Úroveň splnění hlavních přínosů, zdroj: autor

Přínos

Úroveň splnění

Na základě norem a obecně Splněno (viz kapitola 5. Návrh frameworku). uznávaných metodik vytvořím framework,

který

splňuje

požadavky malých firem. Vytvoření

případové

z oblasti SQA k rozšíření návrhu frameworku a uvedení praktických příkladů (formou tabulek, šablon, diagramů atd.)-

studie Splněno (viz kapitola 6. Případová studie)

v konkrétní firmě včetně popisu použitých nástrojů a zhodnocení efektivity

Mým vlastním přínosem bylo hlavně využití vlastních zkušeností

Případovou studii, jsem vytvořil ve firmě, kde pracuji (Cleverbee). Většina popisu vychází přímo z mojí praxe. Popsal jsem i konkrétní příklady použitých nástrojů včetně rad, jak je implementovat. Zhodnocení efektivity bylo pouze slovní.

84

Původně očekávané vedlejší přínosy (Tabulka 9): Tabulka 9 - Úroveň splnění hlavních přínosů, zdroj: autor

Přínos

Úroveň splnění

Analýza

požadavků

softwarovou s přihlédnutím

na Splněno. kvalitu

ke

specifikům

malých firem.

Uvedeny požadavky na softwarovou kvalitu dle norem a stručně zmíněna specifika malých firem (viz kapitola 3. Softwarová kvalita a její definice).

Identifikace hlavních nástrojů, Splněno (částečně). procesů a metodik používaných při řízení softwarové kvality a nalezení konkrétních příkladů

Hlavní procesy a použitelné metodiky byly zmíněny v kapitole 4. Podpora řízení softwarové kvality. Konkrétní příklady nástrojů včetně alternativ byly uvedeny v kapitole 6. Případová studie. Seznam není vyčerpávající, byly uvedeny pouze nástroje, procesy a metodiky, které jsem považoval za relevantní pro malou firmu.

Nalezení vazeb mezi součástmi Splněno (částečně). řízení softwarové kvality a jejich zdokumentování.

Některé možné vazby byly zdokumentovány slovně v kapitolách 5. Návrh frameworku a .6. Případová studie.

Původně neočekávané přínosy práce: •

Vytvořil jsem šablony některých dokumentů používaných ve frameworku. Tyto šablony mohou zájemci využít pro vytvoření svých vlastních dokumentů.

•

Uvedl jsem v práci odkazy na další nástroje, které se mohou firmě hodit, pokud jí nebudou vyhovovat nástroje použité v případové studii.

7.4 Využitelnost a další náměty k řešení Celkově si ale myslím, že výsledky této práce jsou v praxi použitelné. Pro manažery menších vývojových firem může návrh zde uvedeného frameworku sloužit jako podklad pro ten jejich. Samozřejmě nějaká úprava bude vždy nutná a výběr použitých nástrojů bude muset vždy vycházet z potřeb té dané firmy. Informace o možných nástrojích a rady pro implementaci je možné vyčíst z případové studie a dále pak ze zdrojů, z kterých jsem čerpal. Některým firmám také mohou přijít vhod přiložené šablony dokumentů.

85

Téma SQA je ale velmi rozsáhlé, takže by se mu dalo věnovat dále a dále. Naznačil jsem např., že navržený framework má ještě nevyužité možnosti v oblasti projektového řízení – pokud by byl rozšířen tímto směrem, tak by se v podstatě mohl stát hlavní platformou pro řízení vývoje v celé firmě. V takovém případě by bylo nutné ale prozkoumat i další manažerské procesy a nástroje a navrhnout jejich propojení s dosavadními součástmi frameworku. Dalšími možnostmi rozšíření frameworku by bylo zařazení konkrétních technických návodů týkajících se propojení jednotlivých nástrojů, jejich konfigurace, skriptování atd. Z výsledků práce by tak mohly čerpat i techničtější profese než jsou manažeři a testeři. Nevylučuji tedy, že tuto práci ještě v budoucnu nějakým způsobem rozšířím – toto téma považuji za zajímavé a rád bych se mu dále věnoval.

86

8 Přehled literatury a informačních zdrojů 1. International Organization for Standardization. ISO/IEC 9126-1:2001. 2001. 2. International Organization for Standardization.. ISO 9000:2005. 2005. 3. Carnegie Mellon Software Engineering Institute. CMMI for Development, Version 1.2. [Online] srpen 2006. http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf. 4. Merriam-Webster. Merriam-Webster Online Dictionary. framework - Definition from the MerriamWebster Online Dictionary. [Online] listopad 2009. http://www.merriamwebster.com/dictionary/framework. 5. Whaitis?. Whaitis?.com. What is framework? - a definition from WhatIs.com. [Online] listopad 2009. http://whatis.techtarget.com/definition/0,,sid9_gci1103696,00.html. 6. IEEE Standards Board. IEEE Standard Glossary of Software Engineering Terminology. září 1990. 7. International Organization for Standardization. ISO/IEC 12207:2008. 2008. 8. Merriam-Webster. methodology - Definition from the Merriam-Webster Online Dictionary. Merriam-Webster Online Dictionary. [Online] 2009. http://www.merriamwebster.com/dictionary/methodology. 9. Pergl, Robert. Plánování zajištění jakosti produktu dle ISO/IEC 9126: princip a představení praktického řešení. [Online] 2008. http://www.kardos.cz/konf/2008/Pergl.doc. 10. European Comission. Europa. Enterprise - SME Definition. [Online] listopad 2009. http://ec.europa.eu/enterprise/enterprise_policy/sme_definition/index_en.htm. 11. IBM. Rational Unified Process Base Plug-in, Version 7.0.1. 2005. 12. Garcia, SuZ. Thoughts on Applying CMMI in Small Settings. 2005. 13. Garcia, SuZ, a další. Lessons Learned from Adopting CMMI for Small Organziations. 2005. 14. Eclipse Foundation. OpenUP. [Online] listopad 2009. http://epf.eclipse.org/wikis/openup/. 15. Český normalizační institut. ČSN EN ISO 9001. březen 2002. 16. Česká národní banka. Kurzy 27.11.2009. listopad 2009. 17. Sparx Systems. Enterprise Architect – Pricing and Purchasing. listopad 2009.

87

18. Frailey, J. Dennis. Is there hope for software quality?. [Online] březen 2009. http://www.library.illinois.edu/archives/erecords/ASQ%20Archives/1182001_Division_General/SoftwareDiv/Software_News_Win2004.pdf. 19. Lewis, E. William. Software Testing and Continuous Quality Improvement, Third Edition. 2009. 20. The Bugzilla Team. Life Cycle of a Bug. [Online] listopad 2009. http://www.bugzilla.org/docs/3.0/html/lifecycle.html. 21. Majda, David; Bulej, Lubomír. Defenzivní programování.. [Online] listopad 2009. http://dsrg.mff.cuni.cz/teaching/nprg043/lecture10.html. 22. Cleverbee. O nás. [Online] listopad 2009. http://www.cleverbee.com/web/cs/about.jsp. 23. Cleverbee. Služby přesně na míru. [Online] listopad 2009. http://www.cleverbee.com/web/cs/sluzby.jsp. 24. Sybase. Sybase Releases PowerDesigner 12.0. [Online] leden 2006. http://www.sybase.com/detail?id=1038932. 25. Clevertrack. Clevertrack White Paper. [Online] listopad 2009. http://www.clevertrack.com/download/whitepaper/WhitePaper_cs.pdf 26. The Bugzilla Team. Installation. [Online] listopad 2009. http://www.bugzilla.org/docs/3.4/en/html/installation.html. 27. OpenQA.org. Selenium Web Application Testing System. [Online] listopad 2009. http://seleniumhq.org/. 28. Object Management Group. UML. [Online] listopad 2009. http://www.uml.org/. 29. Sparx Systems. Enterprise Architect – Overview. listopad 2009. http://www.sparxsystems.com.au/products/ea/index.html 30. The Bugzilla Team. Bugzilla. [Online] listopad 2009. http://www.bugzilla.org/about/. 31. Buchalcevová, Alena. Metodiky vývoje a údržby informačních systémů. 2009.

88

9 Terminologický slovník Termín

Zkratka

Bugzilla

Capability Maturity Model Integration

Význam Bugzilla je nástroj pro správu chyb vyvíjený nadací Mozilla Foundation [30].

CMMI

Model pro zlepšení zralosti procesů ve vývoji produktů a služeb [3].

Clevertrack

Nástroj pro správu testovaných případů vyvíjený firmou Clevertrack [autor]

Enterprise Architect

Víceuživatelský UML grafický nástroj, který má pomoci týmům ve vytváření robustních a udržovatelných systémů [29]. Je produktem společnosti Sparx Systems.

framework

Základní konceptuální struktura[4] resp. reálná nebo konceptuální struktura, která má sloužit jako podpora nebo návod k tvorbě něčeho, co rozšíří tuto strukturu v něco použitelného [5] Framework obsahovat konkrétní aplikace, specifikovat programová rozhraní a nabízet podpůrné programátorské nástroje. Framework je obvykle obsáhlejší než protokol a více svazující a normativnější než pouhý návrh struktury.

metodika

Soustava metod, pravidel a postulátů používaných nějakou disciplínou resp. určitá procedura nebo soustava procedur [8].

Open Unified Process

proces

OpenUP

Metodika vývoje a údržby IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení [31]. Odlehčený unifikovaný proces, který aplikuje iterativní a inkrementální přístupy v rámci strukturovaného životního cyklu [14]. soubor souvisejících aktivit, které transformují vstupy ve výstupy [7]

89

případ užití

Případ užití posiuje chování systému, které přináší viditelné výsledky těm, kdo se systémem interagují [14].

Quality Assurance

QA

plánované a systematické prostředky, které umožní managementu zajistit, že definované standardy, praktiky, procedury a metody daného procesu budou aplikovány[3].

Rational Unified Process

RUP

Framework složený z metod a stavebních bloků procesů. Soubor myšlenek a principů sloužících k úspěšnému vývoji softwaru. Jazyk pro definici procesů a metodik [11].

řízení softwarové kvality Software Quality Assurance

viz software quality management SQA

součást managementu kvality zaměřující se na zajištění splnění požadavků na kvalitu softwaru [2]

software quality management

Koordinované aktivity sloužící k řízení a kontrole organizace z hlediska kvality. Toto řízení a kontrola z hlediska kvality obvykle zahrnuje tvorba politiky a cílů kvality, plánování, kontrolu, zajišťování a zlepšování kvality[2]

softwarová jakost softwarová kvalita

viz softwarová kvalita Schopnost souhrnu funkcionality a vlastností softwarového produktu naplnit vyslovené i předpokládané požadavky na tento produkt [1].

test case testování

viz testovaný případ spouštění systému nebo komponenty dle definovaných podmínek, pozorování a zaznamenávání výsledků a zhodnocení nějakého aspektu tohoto systému nebo komponenty [6] resp. proces analyzování softwarového produktu tak, aby byly zjištěny rozdíly mezi současným a požadovaným stavem (tj. chyby), a tak aby byly zhodnoceny vlastnosti tohoto systému [6].

90

testovaný případ

Soubor vstupů, podmínek spuštění a očekávaných výsledků, které se používají k vyhodnocení určitého scénáře[14].

Unified Modelling Language

UML

use case

viz případ užití

Jazyk sloužící k modelování aplikačních struktur, chování, architektury, business procesů a datových struktur [28]. Specifikaci jazyka vytváří konsorcium Object Management Group.

10 Přílohy 10.1 Seznam rizik (seznam_rizik.xls) Šablona seznamu rizik je ve formátu Microsoft Excel. Šablona je založená na šabloně, která je součástí OpenUP, přidal jsem do ní ale i další informace (Indikátory, Kategorie a Důsledky) a ke všem sloupcům jsem vložil komentáře s vysvětlením. Šablonu jsem také kompletně přeložil do češtiny.

10.2 Vize (vize.doc) Šablona vize ve formátu Microsoft Word. Šablona je založená na šabloně, která je součástí OpenUP, přidal jsem do ní ale další informace, které jsem považoval za podstatné (Náklady a Odkazy) a mírně jsem poupravil komentáře. Šablonu jsem také kompletně přeložil do češtiny.

91