Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů

Transkript

1 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Alena Buchalcevová Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, katedra informačních technologií nám. W. Churchilla 4, Praha 3 buchalc@vse.cz Abstrakt: Hlavním cílem článku je poukázat na význam kvality softwarového produktu, přiblížit mezinárodní a národní normy, které se kvalitou softwarových produktů zabývají, a analyzovat, jak je posuzování kvality adresováno ve vybraných metodikách budování informačních systémů. Klíčová slova: informační systém, kvalita, jakost, normy kvality, řízení kvality, metodiky vývoje softwaru Abstract: The main goal of this paper is to mention the importance of software product quality, describe international and national quality standards and analyze how these standards are used in software development methodologies. Keywords: information system, quality, quality standards, quality management, software development methodologies 1. Úvod V současné informační společnosti stále roste význam informačních systémů a informačních a komunikačních technologií (IS/ICT), které pomáhají podnikům uspět v tržních podmínkách, využít nabízených možností a čelit potencionálním hrozbám. Spolu s tím ale roste i význam kvality informačního systému, neboť potenciální chyba může způsobit finanční škody, ovlivnit samu existenci firmy či zdraví a životy lidí. Proto se kvalita informačního systému a zejména její ověření dostává do popředí zájmu nejen softwarových firem, ale i zákazníků. Kvalita je definována různě, s ohledem na zaměření tohoto článku vyjdu z definice kvality tak, jak je uvedena v národních normách. V té souvislosti je třeba uvést, že národní normy používají pro překlad anglického termínu quality pojem jakost tak, aby to bylo v souladu s překladem používaným dříve (např. u norem řady ISO 9000). Jakost (quality) je celkový souhrn charakteristik entity, které ovlivňují její schopnost uspokojovat stanovené nebo předpokládané potřeby. [ČSN , 2002] Entitou je přitom myšlen softwarový produkt. Pojmy kvalita a jakost budu používat jako synonymum. Na zajištění kvality informačního systému se můžeme dívat ze dvou pohledů. Jednak jde o zajištění kvality procesu budování informačního systému a jednak zajištění kvality produktu tedy informačního systému. Nejprve objasním pojem budování informačního systému, který používám proto, že v dnešní době se úplně nový software respektive informační systém vytváří v menší míře. Častěji jde o implementaci již hotových řešení, integraci různých komponent a SYSTÉMOVÁ INTEGRACE 1/

2 Alena Buchalcevová služeb. Pro zajištění kvality procesu budování informačních systémů slouží zejména řada norem ISO které patří u nás k nejznámějším a nejčastěji zaváděným. Základní normou je ČSN EN ISO 9001:2001 Systémy managementu jakosti Požadavky na systém, ve které jsou specifikovány požadavky na systém řízení jakosti, jehož zavedení umožňuje organizaci prokázat schopnost trvale poskytovat výrobek, který splňuje požadavky zákazníka a příslušné požadavky předpisů, zvyšovat spokojenost zákazníka a neustále zlepšovat své procesy. Pro organizace, které se zabývají budováním IS, má význam zejména norma ISO/IEC 90003, respektive ČSN ISO/IEC Softwarové inženýrství Směrnice pro použití ISO 9001:2000 na počítačový software. Pro získání certifikace na ISO 9000, musí organizace definovat procesy pro vývoj, provoz a údržbu softwaru, posloupnost těchto procesů a jejich vzájemné vazby. Doporučuje se využít normy ISO/IEC Procesy v životním cyklu softwaru, která obsahuje Referenční model procesů. Kromě mezinárodních a národních norem se na zlepšování procesů budování IS zaměřuje také model CMMI Integrační model zralosti (Capability Maturity Model Integration) a četné metodiky budování IS, kterým je věnována kapitola 3. Úroveň kvality procesu budování IS se zjišťuje na základě posouzení procesů, které se provádí buď na základě normy ISO/IEC anebo metodou SCAMPISM posuzující podle modelu CMMI. Druhý pohled, pohled na kvalitu produktu, posuzuje vlastnosti produktu z pohledu uživatele. Produktem je software resp. informační systém, nebo poskytovaná služba. Jak uvádí [Vaníček, 2007], normalizace v oblasti kvality produktů naráží na problém, že normy pro jednotlivé typy produktů se musí od sebe podstatně lišit, a tak je obtížné nalézt společné požadavky na kvalitu produktů podobně jako u norem procesů řízení jakosti. Přesto existuje celá řada norem, které se zabývají definování kvality jakosti softwaru a jejím posuzováním (viz následující kapitola). Tyto normy jsou však obecně méně známé a používané než normy řady ISO U nás je malá známost těchto norem podpořena ještě tím, že trh informačních produktů je stále v našich podmínkách spíše než trhem zákazníka trhem dodavatelů informatických produktů a to především velkých světových firem. [Vaníček, 2007] 2. Normy v oblasti kvality softwaru Řada norem ISO/IEC 9126 Softwarové inženýrství Jakost produktu je představována normou ISO/IEC Model jakosti (podrobněji v 2.1) a třemi technickými zprávami, které obsahují příklady měr jakosti Vnější míry jakosti , Vnitřní míry jakosti a Míry jakosti užití Řada ISO/IEC Softwarové inženýrství Hodnocení softwarového produktu obsahuje šest částí. Norma Obecný přehled je úvodním dokumentem, který definuje terminologii a postupy při hodnocení. Vlastní postupy při hodnocení jsou popsány v částech: Postup vývojáře, Postup opatřovatele a Postup (nezávislého) hodnotitele. Poslední norma této řady Dokumentace hodnotících postupů sjednocuje způsoby, jak hodnocení dokumentovat. [Vaníček, 2007] Vzájemné vztahy mezi normami ISO/IEC 9126 a ISO/IEC zachycuje obrázek 1. V současnosti se v rámci ISO/IEC JTC1 SC7 připravuje nová řada norem ISO/IEC pod názvem SQuaRE - Software Quality Requirements and 110 SYSTÉMOVÁ INTEGRACE 1/2011

3 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Evaluation. Popis aktuálního stavu projektu SQuaRE a zejména problémů s ním spojených lze nalézt v [Vaníček, 2007]. Obrázek 1. Vzájemné vztahy mezi normami ISO/IEC 9126 a ISO/IEC 14598, zdroj:[čsn , 2002] 2.1 Model jakosti Vzhledem k tomu, že klíčové normy projektu SQuaRE ještě nebyly vydány a ty již vydané nejsou zatím uvažovány pro převzetí jako ČSN, budu vycházet při posuzování podpory kvality softwaru v metodikách budování informačních systémů z normy ČSN ISO/IEC Softwarové inženýrství Jakost produktu Část 1: Model jakosti. Tato norma popisuje model jakosti, který má dvě části: vnitřní a vnější jakost a jakost při používání. Jak ukazuje obrázek 2, kvalitu můžeme posuzovat na úrovni procesu vytváření produktu, produktu samotném a účinku používání produktu. Proces vytváření softwaru je popsán například v normě ISO/IEC Procesy v životním cyklu softwaru. Jedním z procesů definovaných v této normě je proces Ověřování kvality softwaru (Software Quality Assurance). Ověření se provádí na základě měření vnitřních atributů (obvykle statické míry meziproduktů) nebo měřením vnějších atributů (obvykle měření chování softwaru při běhu) nebo měřením atributů jakosti při používání. Cílem je, aby produkt měl požadovaný účinek v určitém kontextu použití. Normalizace v oblasti kvality je založena na přesvědčení, že zlepšování procesu vývoje softwaru je prostředkem pro zlepšování jakosti produktu a hodnocení a zlepšování jakosti produktu je prostředkem pro zlepšování jakosti při používání. Na druhou stranu hodnocení jakosti při používání poskytuje zpětnou vazbu pro zlepšování produktu a hodnocení produktu poskytuje zpětnou vazbu pro zlepšování procesu. Vhodné vnitřní atributy softwaru jsou nezbytným předpokladem pro dosažení požadovaného SYSTÉMOVÁ INTEGRACE 1/

4 Alena Buchalcevová vnějšího chování a vhodné vnější chování je nezbytným předpokladem pro dosažení jakosti při používání. Obrázek 2. Přístupy k jakosti, zdroj:[čsn , 2002] Pohled na vnitřní jakost, vnější jakost a jakost při používání se v průběhu životního cyklu softwaru mění. Na obrázku 3 jsou zachyceny vzájemné vztahy mezi druhy jakosti a požadavky na ně v průběhu životního cyklu softwaru. Obrázek 3. Jakost v životním cyklu softwaru, zdroj:[čsn , 2002] 112 SYSTÉMOVÁ INTEGRACE 1/2011

5 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Potřeby uživatele týkající se jakosti mohou být specifikovány jako požadavky na jakost pomocí měr jakosti při používání, vnější jakosti a vnitřní jakosti. Tyto míry mají být používány jako kritéria při validaci produktu a akceptační kritéria. Požadavky na vnější jakost specifikují požadovanou úroveň jakosti z vnějšího pohledu pohledu uživatele a mají být specifikovány pro všechny charakteristiky jakosti s použitím měr vnější jakosti. Požadavky na vnější jakost se transformují na požadavky na vnitřní jakost, které specifikují úroveň požadované jakosti z vnitřního pohledu produktu (meziproduktů), a slouží jako kritéria při hodnocení produktu. Tato jakost je chápána z pohledu vývojářů. Jakost při používání představuje pohled uživatele na jakost softwarového produktu, který je používán v konkrétním prostředí a v konkrétním kontextu, a měří splnění cílů. Jak uvádí [ČSN , 2002], smyslem řízení jakosti je dosáhnout nezbytné a postačující jakosti, aby se naplnily skutečné potřeby uživatelů. Problémem ale je, jak poznat a definovat skutečné potřeby uživatelů. Potřeby stanovené uživatelem totiž vždy neodráží skutečné potřeby uživatele, protože: uživatel si často neuvědomuje své skutečné potřeby, potřeby se mohou po jejich stanovení změnit, rozdílní uživatelé mají rozdílné provozní prostředí, obtížné je zjistit potřeby všech typů uživatelů zvláště u typového aplikačního softwaru. Proto je obtížné na začátku životního cyklu specifikovat požadavky na jakost v celém rozsahu a je třeba počítat i s jejich změnami. Na obrázku 4 jsou zachyceny charakteristiky vnější a vnitřní jakosti: funkčnost, bezporuchovost, použitelnost, účinnost, udržovatelnost a přenositelnost. Obrázek 4. Model jakosti pro vnější a vnitřní jakost, zdroj:[čsn , 2002] SYSTÉMOVÁ INTEGRACE 1/

6 Alena Buchalcevová Funkčnost je způsobilost softwarového produktu poskytovat funkce, které uspokojují stanovené a předpokládané potřeby, pokud je software používán za specifikovaných podmínek. Bezporuchovost je způsobilost softwarového produktu udržovat specifikovanou úroveň výkonu, pokud je používán za specifikovaných podmínek. Použitelnost je způsobilost softwarového produktu být srozumitelný, zvládnutelný, používaný a atraktivní pro uživatele, pokud je používán za specifikovaných podmínek. Účinnost je způsobilost softwarového produktu poskytovat vhodný výkon s ohledem na množství použitých zdrojů a za stanovených podmínek. Udržovatelnost je způsobilost softwarového produktu být modifikován. Modifikace mohou zahrnovat nápravy, zlepšování nebo adaptace softwaru na změny v prostředí, v požadavcích a ve specifikaci funkcí. Přenositelnost je způsobilost softwarového produktu být přenesen z jednoho prostředí do jiného prostředí. [ČSN , 2002] Každá z těchto charakteristik by měla být hodnocena zvlášť. Pro hodnocení jsou charakteristiky dále dekomponovány na podcharakteristiky, pro které jsou stanoveny jejich měřitelné vlastnosti atributy. Hodnoty atributů měřené v definované stupnici míry se porovnávají s hodnotami stanovenými v požadavcích indikátory kvality. Seznam atributů a měr měl být určen částmi 2 až 4 normy Zde se však rozumný seznam sestavit nezdařilo. [Vaníček, 2007] Na obrázku 5 jsou uvedeny charakteristiky jakosti při používání: efektivnost, produktivita, bezpečnost a uspokojení. Efektivnost je způsobilost softwarového produktu umožnit, aby uživatelé dosáhli specifikovaných cílů s přesností a kompletností ve specifikovaném kontextu použití. Produktivita je způsobilost softwarového produktu umožnit, aby uživatelé vynaložili ve vztahu k dosažené efektivnosti a ve specifikovaném kontextu použití vhodné množství zdrojů. Bezpečnost je způsobilost softwarového produktu dosáhnout akceptovatelné úrovně rizika škod na lidech, byznysu, softwaru, vlastnictví nebo prostředí ve specifikovaném kontextu použití. Uspokojení je způsobilost softwarového produktu uspokojovat uživatele ve specifikovaném kontextu použití. [ČSN , 2002] Obrázek 5. Model jakosti pro jakost při používání, zdroj:[čsn , 2002] 114 SYSTÉMOVÁ INTEGRACE 1/2011

7 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů Použití modelu jakosti Model jakosti definovaný v normě ČSN ISO/IEC je použitelný pro různé typy softwaru. Poskytuje terminologii, a to i českou, v oblasti kvality softwarového produktu. Jeho využití je v oblasti správy požadavků pro identifikaci požadavků na software, strukturování požadavků na kvalitu softwaru, validaci úplnosti specifikace požadavků. Může být použit pro identifikaci cílů návrhu a testování softwaru, identifikaci kritérií zabezpečování jakosti a identifikaci akceptačních kritérií pro dokončený softwarový produkt. Norma ČSN ISO/IEC může být použita jako doplňková v rámci použití dalších norem, zejména: při posuzování procesů dle ISO/IEC 15504, protože poskytuje strukturu pro specifikaci jakosti, podporu pro procesy verifikace a validace a podporu pro specifikaci cílů jakosti organizace, normy ISO/IEC 12207, kde poskytuje strukturu pro specifikaci požadavků na jakost softwarového produktu a podporu pro procesy verifikace a validace, společně s ISO 9001 a poskytuje podporu pro nastavení cílů jakosti a podporu pro přezkoumání návrhu, verifikaci a validaci. 3. Analýza podpory hodnocení kvality ve vybraných metodikách budování informačních systémů V České republice se pro zlepšování procesů při budování informačních systémů daleko více využívá metodik než mezinárodních norem (ISO/IEC 12207, 15504) a standardů (model CMMI ). Metodika budování 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í. [Buchalcevová, 2009] V praxi se dnes setkáme se dvěma hlavními kategoriemi metodik, kterými jsou tradiční (rigorózní) metodiky a agilní metodiky. Rigorózní metodiky vycházejí z přesvědčení, že procesy při budování IS/ICT lze popsat, plánovat, řídit a měřit, a proto je podrobně a přesně definují. Podle agilních metodik vývoj softwaru není definovaný proces, ale empirický proces, který vyžaduje monitorování a adaptaci. Vývoj probíhá ve velmi krátkých iteracích, které končí dodáním funkční verze systému. Každá z agilních metodik je svým způsobem specifická, ale všechny jsou postaveny na stejných principech a hodnotách, které byly v roce 2001 definovány v Manifestu agilního vývoje softwaru. [Beck, 2001] Mezi agilní metodiky byly od počátku řazeny následující metodiky a přístupy: Dynamic Systems Development Method (DSDM), Adaptive Software Development ( ASD), Feature Driven Development (FDD), Extrémní programování (Extreme Programming, XP), Lean Development, Scrum, Crystal metodiky, Agilní modelování (Agile Modeling). Později vznikly nové agilní metodiky jako například Microsoft Solutions Framework (MSF) for Agile Software Development a metodika OpenUP. Aby bylo možné agilní metodiky efektivně použít, musí být splněny určité předpoklady. Nejdůležitějším předpokladem použití agilních metodik je požadavek, aby zákazník byl součástí týmu a byl k dispozici podle potřeby. Dalším klíčovým předpokladem je velikost týmu. Ideální agilní tým má maximálně 8 vývojářů, kteří pracují v jedné SYSTÉMOVÁ INTEGRACE 1/

8 Alena Buchalcevová místnosti a mohou tak plně využívat výhod osobní komunikace. Třetím klíčovým požadavkem jsou vysoké znalosti, zkušenosti a morální hodnoty vývojářů. [Mullaney, 2008] uvádí omezené použití agilních metodik pro distribuovaný vývoj, vývoj se subdodavateli, pro vytváření znovupoužitelných artefaktů, pro vývoj ve velkém týmu, pro vývoj kritických aplikací a pro vývoj velkého komplexního softwaru. V poslední době jsme svědky stále častějšího používání agilních přístupů, ale také vzájemného ovlivňování obou skupin metodik. Ukazuje se, že rigorózní metodiky je možné odlehčit a aplikovat v jejich rámci některý z agilních přístupů. Na druhé straně, pokud potřebujeme použít agilní metodiky na větší projekty, projekty vyvíjené distribuovanými týmy či projekty větší důležitosti, je třeba je více formalizovat a obohatit o nové praktiky. Analýzu podpory hodnocení kvality jsem provedla na vybraných metodikách budování IS/ICT, jak rigorózních, tak agilních. Při výběru metodik jsem vycházela z průzkumů používání metodik ve světě [Ambler, 2006] a vybrala pro hodnocení metodiky, které se nejvíce používají. Mezi hodnocené metodiky jsem zařadila také novou a perspektivní metodiku OpenUP. 3.1 Rational Unified Process Metodika Rational Unified Process (RUP) je v současnosti de facto standardem mezi metodikami. Původně byla zařazována mezi rigorózní metodiky zejména z důvodu velké podrobnosti metodiky, ale od roku 2003 je doplňována o agilní praktiky a v současné době představuje rámec, ve kterém je možné vytvořit metodiky pro všechny typy projektů od velmi formální metodiky až po velmi lehkou, agilní metodiku. Metodika RUP je založena na nejlepších praktikách softwarového vývoje: iterativní vývoj, řízení požadavků, použití komponentové architektury, vizuální modelování, kontrola kvality softwaru a řízení změn. Životní cyklus softwaru je rozdělen do 4 po sobě jdoucích fází. V rámci fáze Zahájení se definují cíle projektu, požadavky, vytváří se harmonogram projektu, odhadují se náklady projektu a definují rizika. Cílem fáze Rozpracování je definovat architekturu systému a ověřit ji. Předmětem Konstrukční fáze je návrh a realizace systému včetně testování. Cílem fáze Zavedení je zajistit, aby uživatelé mohli systém používat. Součástí této fáze je školení uživatelů, předání dokumentace, vytvoření help-desku atd. Každá fáze je uzavřena milníkem, ve kterém se posuzuje, zda byly splněny cíle fáze a rozhoduje se o dalším postupu. Metodika RUP se vyznačuje velmi výraznou podporou zajištění kvality. Tuto podporu explicitně deklaruje tím, že jednou z 6 nejlepších praktik, na kterých je postavena, je praktika Kontinuální ověřování kvality. RUP je postaven na iterativním životním cyklu a ověřování kvality je integrální součástí každé iterace. Na konci iterace se hodnotí, zda byly splněny cíle iterace, adresována rizika, dodána plánovaná funkčnost a splněny atributy kvality. Kvalita je v metodice RUP definována v rámci dimenzí, které odpovídají modelu FURPS F (functionality), U (usability), R (reliability, P (performace), S (supportability), který byl poprvé publikován v [Grady, 1987]. V poslední době se model FURPS rozšířil o další dílčí prvky a používá se pro něj označení FURPS+. Dimenze kvality modelu FURPS v podstatě odpovídají charakteristikám vnější a vnitřní jakosti modelu jakosti dle ČSN ISO/IEC , které jsou zachyceny na obrázku 4. Model jakosti navíc jako charakteristiku uvádí přenositelnost, která je ovšem v modelu 116 SYSTÉMOVÁ INTEGRACE 1/2011

9 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů FURPS součástí dimenze supportability. RUP používá tyto dimenze kvality pro definování struktury dokumentu Supplementary specification, který je součástí specifikace požadavků. Na základě dimenzí kvality se definují jednotlivé typy testů. RUP poskytuje poměrně komplexní sadu postupů pro zajištění kvality. V rámci disciplíny Testování jsou definovány 4 role manažer testů, analytik testů, návrhář testů a tester. Pro každou roli jsou definovány činnosti, které provádí, a artefakty, za které zodpovídá. 3.2 OpenUP Metodika OpenUP je nová agilní metodika dostupná pod Eclipse Public License. OpenUP je minimálně dostatečná, kompletní metodika pro vývoj softwaru, která je snadno přizpůsobitelná a rozšiřitelná. Vznikla zeštíhlením metodiky Unified Process, je tedy založena na iterativním a inkrementálním modelu životního cyklu, případech užití, řízení rizik a architektuře. Celý životní cyklus projektu je opět rozdělen do 4 fází Zahájení, Rozpracování, Konstrukce a Zavedení. Metodika OpenUP je určena pro menší týmy. Ve snaze být agilní metodikou je oproti metodice Unified Process zredukován jak počet disciplín, tak počet rolí. Metodika OpenUP definuje disciplíny Řízení projektu, Požadavky, Architektura, Vývoj a Testování a role zainteresovaná strana, analytik, architekt, vývojář, tester, vedoucí projektu a kdokoli. Metodika také využívá modelu FURPS+ pro definování dimenzí kvality. V oblasti správy požadavků jsou dimenze kvality opět použity pro definování kvalitativních požadavků zde jsou součástí dokumentu System Wide Requirements, pro který je poskytována šablona určující jeho strukturu a také kontrolní seznam ověřující kvalitu tohoto dokumentu. Funkční požadavky jsou specifikovány ve formě případů užití a kvalitativní požadavky ve struktuře U (usability), R (reliability), P (performace), S (supportability). Odlehčení metodiky OpenUP se dle mého názoru nepříznivě projevuje v nedostatečné podpoře zajištění kvality. Jediná role Tester není dostatečná1 a jsou pro ni definovány pouze činnosti Vytvoření testovacích případů, Implementace testů a Spuštění testů. Metodika se zaměřuje v podstatě jen na funkční testy, vůbec neřeší ostatní typy testů, které by ověřovaly ostatní dimenze kvality. 3.3 Feature driven development Metodika Feature driven development (FDD) se řadí mezi agilní metodiky, ale definuje procesy, byť odlehčené, a zdůrazňuje nutnost modelování předem. Je formálnější než ostatní agilní metodiky, a tak ji lze úspěšně použít i na větší projekty. Metodika FDD je založena na iterativním vývoji, který je řízen užitnými vlastnostmi produktu. Užitná vlastnost (feature) je malý výsledek užitečný z pohledu zákazníka, který je srozumitelný, měřitelný a realizovatelný v rámci dvoutýdenní iterace. Základem pro zajištění kvality v metodice FDD jsou zejména praktiky doménové objektové modelování a inspekce. Praktika doménové objektové modelování spočívá ve vytvoření konceptuálního modelu tříd a definování vlastníků tříd na začátku životního cyklu, čímž pomáhá držet konceptuální integritu systému. FDD spoléhá na inspekce, které zajišťují vysokou kvalitu návrhu a kódu. Inspekce mohou podstatně snížit počet chyb jejich včasnou detekcí. Primárním účelem inspekcí v metodice FDD 1 jednotkové testy provádí role Vývojář SYSTÉMOVÁ INTEGRACE 1/

10 Alena Buchalcevová je odhalení defektů, ale pokud se inspekce provádějí dobře, můžeme získat ještě dodatečné přínosy jako přenos znalostí a dodržování standardů. Inspekce se vhodně doplňují s praktikou malých týmů pro užitné vlastnosti. Pokud vývoj užitné vlastnosti neovlivňuje jiné týmy, probíhají inspekce pouze v rámci jednoho týmu. Metodika FDD se věnuje zejména charakteristikám vnitřní jakosti. Vnější jakost a jakost při používání je řešena podobně jako u ostatních agilních metodik zapojením zákazníka do projektu, čímž se získává rychlá zpětná vazba. 3.4 Metodika Scrum Podle výsledků průzkumů [Ambler, 2006] patří Scrum spolu s metodikou Extrémní programování mezi nejpoužívanější agilní metodiky. Metodika Scrum je zaměřena hlavně na řízení projektu. Vývoj probíhá v 30denních iteracích nazývaných Sprint, ve kterých se dodává vybraná množina užitných vlastností. Klíčovou praktikou jsou denní porady (Scrum Meetings), které slouží pro koordinaci prací. Metodika Scrum definuje jen 3 role Product Owner, Team a ScrumMaster. Product Owner spravuje seznam požadavků (Product Backlog) tak, aby maximalizoval hodnotu projektu. Team je skupina lidí s různou specializací, kteří se sami řídí tak, aby v každém Sprintu dodali fungující software. Scrum Master zodpovídá za metodiku, její správnou implementaci a maximalizaci užitku. Řízení kvality v metodice Scrum explicitně adresováno není, a to zejména ze dvou důvodů. První důvod spočívá v tom, že je metodika Scrum zaměřena na řízení projektu a jen v malé míře se zabývá softwarovým inženýrstvím. Druhý důvod pak spočívá v podstatě agilních metodik, které definují jen principy a praktiky, nikoli přesné a podrobné postupy. Metodika tedy nijak nepracuje s charakteristikami kvality softwaru, přesto tu základ pro zajištění kvality produktu nalezneme. Spočívá zejména v plném zapojení zástupce uživatelů role Product Owner, do práce na projektu a v jeho zodpovědnosti za požadavky. Dalším nástrojem zajištění kvality produktu je vývoj v krátkých iteracích sprintech a díky tomu časná zpětná vazba, která se realizuje v rámci praktik Sprint Review Meeting, na kterém se uživateli předvádí výsledek iterace, a Sprint Retrospective Meeting, který slouží k hodnocení průběhu iterace. 3.5 Metodika Extrémní programování Extrémní programování (XP) je velmi lehká, ale disciplinovaná metodika, která zavádí specifické praktiky jako párové programování, refaktorizace, testy před kódováním a další. Extrémní programování je typická agilní metodika, jejíž praktiky mají za cíl vyvinout produkt, který uspokojí aktuální potřeby zákazníka. Řízení kvality metodika neřeší explicitně, ale spíše implicitně. Důležitým aspektem dodání kvalitního softwaru je opět zákazník, který je součástí týmu a odpovídá za požadavky. Požadavky se v XP definují ve formě uživatelských příběhů (user story), které píší sami zákazníci a vyjadřují v nich své potřeby, které má systém podpořit. Pro každý požadavek specifikuje zákazník akceptační test, který ověří, zda byl požadavek implementován úspěšně. Extrémní programování se hodně věnuje také vnitřní jakosti, tedy kvalitě z pohledu vývojářů. Ta je zajišťována jednak požadavkem na vysokou kvalifikaci vývojářů, velmi dobře definovanými standardy a konvencemi a zejména využíváním techniky testy řízený vývoj (Test driven development), kdy vývojáři musí 118 SYSTÉMOVÁ INTEGRACE 1/2011

11 Normy kvality softwaru a jejich podpora v metodikách budování informačních systémů nejprve napsat testy, až poté kód. Testy řízený vývoj spolu s refaktorizací zajišťuje stálou kvalitu kódu. Praktika párové programování pak představuje kontinuální ověřování kvality. 3.6 Metodika Microsoft Solutions Framework Microsoft Solutions Framework je rámec pro vývoj softwaru, ve kterém je možné definovat metodiku pro konkrétní organizaci, či konkrétní projekt. Součástí MSF 4.0 jsou dvě definované metodiky. MSF for Agile Software Development je agilní metodika, která je vhodná pro menší projekty s rychlou dodávkou. MSF for CMMI Process Improvement má formálnější plánování, více dokumentace, podrobnější sledování času, složitější workflow a je navržena tak, aby odpovídala úrovni zralosti 3 podle modelu CMMI. Metodika MSF se vyznačuje výraznou podporou řízení kvality, která je vyjádřena definováním principu Investice do kvality jako jednoho z 8 základních principů metodiky MSF. Investice do kvality je investicí do lidí, procesů a nástrojů. Tým musí být přesvědčen, že vyrábí dostatečně kvalitní produkt. Úspěšné řízení kvality předpokládá, že se kvalita stává součástí firemní kultury. Zároveň je třeba zajistit, aby byl dodáván kvalitní produkt i při změnách požadavků. MSF definuje 2 modely týmový model a Governance model. Týmový model definuje 7 skupin uživatelských rolí: Řízení produktu (Product Management), Řízení programu (Program Management), Architektura (Architecture), Vývoj (Development), Testování (Test), Provoz (Release/Operations) a Zkušenosti uživatelů (User Experience). Řízení kvality se promítá do činností všech skupin rolí. Role Řízení produktu má na starosti definování požadavků, jejich pochopení a sledování jejich naplnění. Součástí Řízení programu je realizace procesu Řízení kvality (Project Quality Managament). Testování je nutné pro splnění kvalitativních požadavků zákazníka. Testy předvídají, hledají a reportují jakékoliv problémy, které mohou snížit kvalitu řešení. Probíhá zde také monitoring, měření a vyhodnocování kvality řešení. Na rozdíl od skupiny Vývoj, která má na starosti jednotkové testování, předmětem role Testování je funkční testování a systémové testování. Kvalita při používání je předmětem zájmu role Zkušenosti uživatelů (User Experience). Tato skupina reprezentuje pohled ze strany zákazníka. Řešení musí vycházet ze znalostí a zkušeností uživatelů a přizpůsobit se jim pro zajištění maximální efektivity jejich práce. Skupina musí chápat prostředí uživatelů jako celek, rozpoznat všechny potřeby a požadavky koncových uživatelů a zajistit, aby si celý tým uvědomil význam použitelnosti z pohledu koncových uživatelů Governance model pak představuje celý životní cyklus vývoje a zaměřuje se na kvalitu procesu. Mezi jednotlivými fázemi jsou definovány kontrolní body, kdy je vytvořené řešení porovnáváno s kvalitativními kritérii stanovenými na začátku projektu. Hlavním kontrolním bodem je převzetí řešení zákazníkem, které spočívá především v hodnocení produktu podle předem definovaných akceptačních kritérií. Na zvyšování kvality se podílí i MSF Readiness Management Discipline, která se stará o optimální zastoupení schopností a dovedností v týmu. 4. Závěr Článek ukázal rostoucí potřebu zajistit dodávku kvalitních softwarových produktů a přiblížil cesty k jejímu dosažení. Mezinárodní a národní normy, podobně jako tradiční SYSTÉMOVÁ INTEGRACE 1/

12 Alena Buchalcevová metodiky budování informačních systémů, vycházejí z předpokladu, že čím bude kvalitnější proces budování IS, tím kvalitnější bude i výsledný produkt. Současně se zlepšováním procesů při budování IS se ale věnují také měření kvality produktu s pomocí vnitřních a vnějších charakteristik jakosti a jakosti při používání. Agilní metodiky, které jsou proti podrobnému popisu procesů a formálním měřením a hodnocením, prosazují takové praktiky, které implicitně vedou k vysoké vnitřní jakosti produktu. Vnější jakost, zejména splnění měnících se požadavků zákazníka, je zajištěna vtažením zákazníka do procesu vývoje a přenesením odpovědnosti za definování požadavků, určení jejich priorit a akceptační testy na něj. Příspěvek vznikl v rámci řešení grantu IG Zavedení procesu řízení kvality jako integrální součásti metodiky vývoje informačního systému 5. Použité zdroje AMBLER, S. W.: Agile software development methods and techniques are gaining traction. In Dr. Dobb Portal, srpen [online]. Think Services, c2007 [cit ]. Dostupný z WWW: < BECK K. et al. Manifesto for Agile Software Development [cit ]. Dostupný z WWW < BUCHALCEVOVÁ, A.: Metodiky budování informačních systémů. 1. vyd. Praha : Oeconomica, s. ISBN GRADY, R.; CASWELL, D.: Software Metrics: Establishing a Company-wide Program. Prentice Hall pp. p ISBN ČSN ISO/IEC Softwarové inženýrství Jakost produktu Část 1: Model jakosti VANÍČEK, J.: Kvalita informačních systémů z pohledu mezinárodní normalizace (aktuální informace), Sborník příspěvků z konference Systém řízení kvality a bezpečnosti informačních systémů ve zdravotnictví, ČZU, Praha, 2007, 2007, s Dostupný z WWW < 120 SYSTÉMOVÁ INTEGRACE 1/2011