Obsah 1
2
3
4
5
6
7
8
Úvod ..............................................................................................................................6 1.1 Co to je softwarové inženýrství? .............................................................................6 1.2 Selhání softwarového inženýrství............................................................................7 1.3 Životní cyklus softwarového díla ..........................................................................10 1.4 Řešení problému ...................................................................................................10 Koncepty řízení SW projektů........................................................................................12 2.1 Základní pojmy.....................................................................................................12 2.2 Zralost organizace.................................................................................................12 2.3 Koncepty řízení projektu.......................................................................................13 Plánování a vedení projektu..........................................................................................19 3.1 Softwarové mýty...................................................................................................19 3.2 Plán projektu.........................................................................................................21 3.3 Plánování času ......................................................................................................22 Softwarové metriky ......................................................................................................33 4.1 Základní klasifikace metrik ...................................................................................33 4.2 Vztahy mezi metrikami .........................................................................................38 4.3 Faktory ovlivňující produktivitu tvorby softwaru ..................................................39 4.4 Metriky kvality softwaru.......................................................................................39 Odhady času, zdrojů a nákladů .....................................................................................41 5.1 Popis rozsahu softwaru .........................................................................................41 5.2 Schůzky se zákazníkem ........................................................................................41 5.3 Plánování zdrojů ...................................................................................................42 5.4 Odhad ceny a pracnosti .........................................................................................43 Řízení rizik...................................................................................................................52 6.1 Vysvětlení základních pojmů ................................................................................53 6.2 Kategorie rizik ......................................................................................................54 6.3 Identifikace rizik...................................................................................................54 6.4 Rizika softwarového projektu................................................................................55 6.5 Rizikové komponenty ...........................................................................................59 6.6 Kategorie dopadu..................................................................................................60 6.7 Ohodnocení rizik ..................................................................................................61 6.8 Protiriziková opatření............................................................................................62 6.9 Plán řízení rizik.....................................................................................................64 6.10 Softwarový rizikový management podle [Boehma] ..............................................65 Kvalita softwaru ...........................................................................................................67 7.1 Základní pojmy.....................................................................................................67 7.2 Zabezpečení jakosti kvality...................................................................................68 7.3 Techniky řízení jakosti softwaru ...........................................................................69 7.4 Cena za jakost.......................................................................................................71 7.5 Statistické přístupy k jakosti softwaru ...................................................................74 7.6 Diagram příčin a následků.....................................................................................75 7.7 Chybový index......................................................................................................75 7.8 Spolehlivost softwaru............................................................................................76 7.9 Benchmarking.......................................................................................................77 7.10 Normy ISO ...........................................................................................................77 Techniky testování........................................................................................................79
4
8.1 Charakteristika testování .......................................................................................80 8.2 Principy testování .................................................................................................80 8.3 Testovatelnost.......................................................................................................81 8.4 Black-box testování...............................................................................................82 8.5 White-box testování ..............................................................................................84 8.6 Testování podle základních cest ............................................................................87 8.7 Testování podle řídicí struktury.............................................................................89 8.8 Metody založené na grafu .....................................................................................90 8.9 Beizer, B.: Black-Box Testing, Wiley ...................................................................91 8.10 Metoda rozdělení do tříd ekvivalencí (Equivalence Partitioning) ..........................91 8.11 Metoda analýzy okrajových hodnot (Boundary Value Analysis).........................92 8.12 Srovnávací testování (Comparison Testing, back-to-back testing) .........................92 8.13 Testování pro speciální prostředí a aplikace ..........................................................93 9 Strategie testování softwaru ..........................................................................................96 9.1 Verifikace a validace.............................................................................................96 9.2 Nesprávné názory na strategii testování.................................................................96 9.3 Ukončení testování ...............................................................................................97 9.4 Testování jednotek................................................................................................98 9.5 Integrační testování............................................................................................. 100 9.6 Validační testování ............................................................................................. 101 9.7 Systémové testování............................................................................................ 102 10 Řízení změn............................................................................................................ 104 10.1 Příčiny změn....................................................................................................... 104 10.2 Srovnávací základna ........................................................................................... 104 10.3 Proces SCM........................................................................................................ 105 10.4 Řízení verzí......................................................................................................... 106 10.5 Řízení změn........................................................................................................ 106 10.6 Audit konfigurací................................................................................................ 107 11 Projektový management.......................................................................................... 109 11.1 Projekt ................................................................................................................ 109 11.2 Týmový management projektu............................................................................ 110 12 Zpětné inženýrství .................................................................................................. 114 12.1 Nástroje pro zpětné inženýrství ........................................................................... 115 12.2 Meze zpětného inženýrství.................................................................................. 115 13 Nástroje CASE ....................................................................................................... 116 14 Normy v SI ............................................................................................................. 118 14.1 IEEE Standard 1042............................................................................................ 118 14.2 IEEE standard 1058 ............................................................................................ 119 14.3 IEEE Standard 828.............................................................................................. 119 14.4 IEEE Standard 1074............................................................................................ 120 Příloha I Návrh, dokončení a prezentace projektu ............................................................. 124 Příloha II Jazyk UML....................................................................................................... 128 Příloha III Projekt Evidence HW ...................................................................................... 136 Příloha IV Projekt Inteligentní domácnost ........................................................................ 147
5
1 Úvod Softwarový inženýr amatér vždy hledá kouzelnou, senzační metodu nebo nástroj, jejíž aplikace slibuje triviální návrh softwaru. Profesionál ví, že takové řešení neexistuje. Grady Booch, in Object Oriented Analysis and Design
1.1
Co to je softwarové inženýrství?
Disciplina softwarové inženýrství byla zavedena v roce 1968 jako odpověď na neutěšený stav vývoje softwaru. Softwarové inženýrství je disciplina, která se zabývá problematikou tvorby softwaru, který mál být vytvořen včas, v požadované kvalitě a při dodržení rozpočtu. Důraz je kladen jak na software tak na inženýrství. Můžeme říci, že softwarové inženýrství se snaží o zavedení inženýrských metod do návrhu softwaru. Čím je návrh softwaru specifický? Složitostí, komplexností a změnami. V následující tabulce je znázorněn vývoj hardwaru, softwarových nástrojů a metod softwarového inženýrství v druhé polovině dvacátého století. nástroje
HW
strojový kód
elektronky
assembler
tranzistory
SI techniky
1950
strukturované programování jazyky 3. generace jazyky 4. generace jazyky AI objektové programování
integrované obvody paralelní procesy VLSI
funkcionální dekompozice strukturální analýza datová analýza objektová analýza
2000
6
Z tabulky vyplývá, že první představy o systematickém přístupu k tvorbě softwaru přišly se strukturovaným programováním koncem šedesátých let. Softwarové inženýrství je: o Modelování – tvorba modelu, kdy se během jeho tvorby soustředíme jen na nejnutnější detaily a ostatní zanedbáváme. V průběhu tvorby softwaru je potřeba vytvořit řadu různých modelů, které odpovídají jednotlivým pohledům na řešený úkol. o Řešení problémů – modely jsou použity k hledání akceptovatelného řešení. o Získávání znalostí – softwarové inženýrství sbírá data z modelů řešených problémů, ukládá je jako informace a znalosti pro řešení dalších úloh. Tento proces je nelineární a jeden špatný údaj v datech může příslušný model znehodnotit. o Racionálně vedená aktivita – při získávání znalostí je nutné postupovat logicky, rozumově, aby získané informace byly přínosné, aby získané modely byly použitelné, umožňovaly změny a pomohly při nových řešeních. Softwarové inženýrství řeší problémy, hledá modely, sbírá znalosti a hledá racionální řešení. Každá z těchto aktivit je však ovlivňována lidmi, časem a rozpočtem, který má k disposici. Mimo to se v každém okamžiku mohou objevit požadavky na změny.
1.2
Selhání softwarového inženýrství
Jedním ze zdrojů získávání znalostí v softwarovém inženýrství je analýza „počítačových havárií“. Proč studovat havárie? o Z havárií se učíme. o Analyzujeme systém „v terénu“. o Nemusíme havárii simulovat. o O havárii je obvykle více informací. o Při havárii nastanou situace, které se nedají předvídat a obvykle návrháře při testování nenapadnou. Uvedeme si příklady některých typických havárií. Problém typu Y2K V roce 1992 dostala paní Mary z Winona ve státě Minnesota v USA pozvánku k návštěvě mateřské školy. Pani Mary bylo v té době 104 let. Přestupný rok Supermarket dostal dne 29. února 1988 pokutu 1000 $ za to, že prodával maso, které mělo o jeden den prošlou záruční lhůtou. Program, který tiskl dobu trvanlivosti na balíčky s masem nepočítal s tím, že rok je přestupný.
7
Nesprávný interface 10 dubna 1990 opustil vlak podzemní dráhy v Londýně stanici bez řidiče. Řidič zmáčkl tlačítko, které startovalo vlak a spoléhal se na automatické zajištění, které neumožňovalo odjezd vlaku s otevřenými dveřmi. Protože se dveře zpříčily a nebylo je možné zavřít automaticky, vystoupil řidič z vlaku aby dveře uvolnil. Jakmile se tak stalo, vlak jednoduše odjel bez řidiče. Bezpečnost 2 listopadu 1988 byl do Internetu vypuštěn virus, který dnes označujeme jako internetový červ. Virus využil zranitelnosti některých síťových služeb jako např. Unixové posílání pošty a začal se nekontrolovaně šířit. Výsledkem bylo napadení asi 10 % procent všech internetových počítačových uzlů, kde zaplnil celou paměť a způsobil výpadek počítače. Trvalo několik dnů než byly problémy odstraněny. Překročení rozpočtu a pozdní dodání V roce 1995 chyba v automatickém systému kontroly zavazadel na novém letišti v Denveru způsobila ničení zavazadel. Letiště bylo uzavřeno a znovu otevřeno až po 16 měsících, kdy rozpočet na dodání systému byl překročen o 3,2 miliardy dolarů a manipulace se zavazadly byly prováděny převážně ručně. Dodání včas Za 18 měsíců a 200 milionů dolarů byl v roce 1984 předán systém pro zdravotní pojišťovnu ve Wisconsinu. Systém však nikdy nepracoval dobře. Bylo zjištěno přeplacení účtů o 60 milionů dolarů a trvalo další tři roky systém opravit. Zbytečná složitost Přepravní letoun C-17 firmy McDonnell Douglas překročil rozpočet o 500 milionů dolarů, protože byly problémy v navigačním systému. Vybavení letounu mělo na palubě 19 počítačů, 80 mikroprocesorů a při jeho implementaci bylo použito 6 různých programovacích jazyků.
Havárie záchranné služby v Londýně Ukážeme si podrobnější rozbor jedné počítačové havárie. Londýnský záchranný systém byl navržen počátkem devadesátých let a měl být plně automatický. Základní částí systému byla počítačem podporovaná pomoc, vozidla záchranné služby byly automaticky naváděny, řidiči měli na palubě počítačovou mapu a hlasová komunikace byla založena na radiovém spojení. Dne 26. a 27. října 1992 se systém zhroutil. Řidiči nevěděli kde jsou. K jednomu případu vyjelo několik vozidel. V řídícím centru byl přeplněné kontrolní obrazovky a přetížené telefony. Bylo přetížené radiové spojení. Při zavolání služby byla odpověď až za 10 minut, přičemž pouze 20% volání bylo úspěšných. Vznikla situace, která ohrožovala lidské životy.
8
Co způsobilo havárii? o Nesmyslný návrh – Zadání projektu bylo 6.3.1991, ukončení výběrového řízení 15.4.1991, implementace systému konec roku 1991, smlouva s dodavatelem podepsána v srpnu 1991, systém předán 8.1.1992. o Nezkušenost – Celkem se o projekt ucházelo 17 realizátorů. Oborníci, kteří prováděli analýzu zadání doporučovali, aby byl požadován úplný systém za 1,5 milionů £ s dobou zpracování 18 měsíců. Byl akceptován neúplný systém za 937 000 £, který byl dodán za 5 měsíců. Firma, která získala zakázku použila CASE (Computer Aided Software Engineering) systém, který se učila, nikdy podobný systém nerealizovala a na tvorbu systému měla v době zadání 35 000 £. o Mnoho automatizace – Lokalizace vozidel byla přímo podle hlášení případů, personál řídícího centra zasahoval až po 11 minutách. Nebyla žádná písemná dokumentace. Předpokládala se stoprocentní spolupráce řidičů záchranných vozidel, přitom řidiči nebyli dostatečné ohodnoceni. o Uživatelské problémy – Posádky vozů nebyly při tvorbě systému konzultovány. Uživatelé byli vyškoleni dříve, než byl systém realizován. Systém neakceptoval prioritu operátorů v centru. Špatná lokalizace byl mnohem častější než při předchozí hlasové komunikaci s operátory. o Neadekvátní komunikační systém a softwarové chyby - Na kontrolních obrazovkách bylo mnoho informací, které však nebyly pro nedostatek paměti ukládány. V kritické dny nebyli ve službě žádní záložní operátoři. Systém byl 26.10 uveden do provozu se dvěma vážnými a 44 malými chybami. Programátoři zapomněli odstranit část ladicích tisků, která způsobila ztrátu informací na serverech. Celý systém byl napsán ve variantě programovacího jazyku Basic. o Špatný uživatelský interface – Zprávy rolovaly po obrazovce a nebylo je možné zastavit, posádka vozu mohla velmi snadno na ovládacím panelu zmáčknout špatný knoflík, tiskárny bylo možné vypnout, aniž se zprávy někde ukládaly. o Špatný management projektu –Nikdo nechtěl projekt vést, nikdo nepracoval na projektu na plný úvazek, programátoři nezvládli použitý CASE nástroj, softwarové změny se prováděly za pochodu, celý systém nebyl nikdy předem otestován. K uvedenému příkladu není co dodat. Řada chyb při návrhu a realizaci projektu se nám může zdát nepochopitelná, můžeme se domnívat, že nám by se nic podobného nemohlo stát. Praxe ukazuje, že tomu je právě naopak.
9
1.3
Životní cyklus softwarového díla
V předchozí části jsme specifikovali softwarové inženýrství mimo jiné jako modelování. Základními modely jsou modely životního cyklu SW díla. Všechny modely mají některé společné základní aktivity, kterými jsou: 1. Specifikace. Definujeme především funkce a omezení systému. 2. Návrh a implementace. Snaha o vytvoření systému, který splňuje specifikace. 3. Validace softwaru. Software musí být testován tak, aby se prokázalo, že splňuje požadavky zadavatele. 4. Evoluce softwaru. Software se musí vyvíjet tak, aby byl schopen uspokojit potřeby zákazníka v případě změn. Životní cyklus zahrnuje i další činnosti : o řízení projektu o analýzu o návrh o implementaci o zajištění kvality o údržbu Příklady modelů životního cyklu softwarového díla: o Model vodopád- Jednotlivé aktivity jsou zpracovány jako nezávislé procesy, které na sebe navazují. o Evoluční model – Tento přístup prokládá jednotlivé etapy realizace kontrolou se zákazníkem a jejich paralelním zpracováním tak, aby se postupné verze realizovaného systému co nejrychleji blížily požadavkům zákazníka. o Formální návrh –Tento přístup je založen na vytvoření formálního matematického modelu specifikace systému, který je převeden do programové podoby.Verifikace systému je odvozena z matematického dokazování specifikací. o Znovupoužití vývoje – Tento přístup je založen na faktu, že existuje značné množství komponent do nově vytvářeného systému.
1.4
Řešení problému
Při řešení problému bychom si měli nejprve odpovědět na základní otázku softwarové inženýrství.
10
Koupit? Přebudovat? Znovupoužít? Navrhnout a realizovat? Ne vždy je potřeba navrhovat a realizovat nový systém. Stále častěji se setkáváme s řešeními, kdy výsledný produkt skládáme z již hotových nebo upravených modulů. Aktivity, spojené s řešením problému můžeme shrnout do pěti kroků: •
formulace problému
•
analýza problému
•
hledání řešení
•
volba vhodného řešení
•
řešení
Vazby mezi jednotlivými aktivitami jsou uvedeny v obrázku 1.1 projekt
* aktivity je vytvořen
produkt
*
* úkol
spotřebovává
*
zdroje
účastník
systém
čas
model dokument
vybavení
Obr 1.1 Důsledkem uvedených skutečností je, že o průměrně 50% velkých projektů trvá déle než bylo odhadováno, o tři čtvrtiny velkých projektů má provozní chyby, o jedna čtvrtina velkých projektů je zrušena.
11
2 2.1
Koncepty řízení SW projektů Základní pojmy
Než si řekneme které jsou nejdůležitější prvky řízení při práci na softwarových projektech, zavedeme si základní pojmy, bez kterých se při výkladu neobejdeme.
Projekt je časově ohraničené úsilí vynaložené s cílem vytvořit jedinečný výsledek (produkt).
Proces je ucelený sled činností, který má na výstupu měřitelný výsledný produkt.
Produkt může být hmotný (výrobek) nebo nehmotný (informace) nebo to může být služba.
Softwarové inženýrství je systematický, disciplinovaný a kvalifikovaný přístup k vývoji, provádění a údržbě softwaru. definice IEEE 1993
2.2
Zralost organizace
Organizace, které realizují softwarové projekty, jsou na tuto činnost různě připraveny a vybaveny. Softwarové inženýrství je založeno na předchozích zkušenostech a informacích. Čím více jich organizace má, tím lépe je na realizaci projektu připravena. Z pohledu připravenosti organizace rozeznáváme několik úrovní a mluvíme v této souvislosti o úrovni zralosti organizace. Pět základních úrovní zralosti organizace je: 1. Počáteční - SW proces je prováděn ad hoc, příležitostně až chaoticky. Několik procesů je definováno, případné úspěchy závisí na osobním úsilí. 2. Opakovatelná - Jsou zavedeny základní procesy řízení projektu. Je snaha opakovat procesy úspěšných projektů podobných aplikací.
12
3. Definovaná - SW proces jak z hlediska řízení tak i z hlediska SI je dokumentován, standardizován a integrován do ostatních procesů organizace. 4. Řízená - Jsou prováděna podrobná měření kvality SW procesu a produktu. 5. Optimalizovaná - Soustavné zdokonalování procesů využívá kvantitativní zpětnou vazbu z procesů a testů nových myšlenek a technologií.
2.3
Koncepty řízení projektu
Při realizaci projektu organizací, je nutné sledovat tři základní oblasti: o Lidé - práce s lidmi. o Problém - pochopení řešeného problému. Špatným pochopením problému může vzniknout sice elegantní řešení, ale pro jiný problém. o Proces - sledování procesu. Proces je nutné připravit, naplánovat, kontrolovat a řídit.
Lidé Nejdůležitějším předpokladem pro úspěšný softwarový projekt je výběr vysoce kvalifikovaných odborníků.
Role lidí, kteří ovlivňují softwarový proces o vrcholový management o manažer projektu o pracovníci o zákazníci o koncoví uživatelé Úloha manažera projektu : o komunikace se zákazníkem o plánování projektu o řízení rozpočtu o výběr řešitelů o kontrola stavu projektu o prezentace výsledků Schopnosti manažera projektu: o řešení problémů o identifikace o aktivita o vliv a budování týmu
13
Organizace týmu Existují tři základní typy organizace týmů pro tvorbu softwaru: 1. n osob je přiřazeno k m různým úkolům, vyskytuje se jen relativně malá společná část, kterou je třeba koordinovat 2. n osob je přiřazeno k m různým úkolům, m
Vhodná struktura týmu závisí na o stylu řízení o počtu pracovníků a jejich dovednostech o složitosti problému
Rozeznáváme tři typy týmové struktury:
DD - decentralizovaně demokratická
Rozhodnutí se provádí na základě skupinového konsensu. Komunikace uvnitř týmu je horizontální.
CD - řízeně decentralizovaná
Je určen vedoucí týmu (případně vedoucí podskupin), který koordinuje úkoly. Řešení problému se provádí ve skupině. Komunikace mezi podskupinami a individui je horizontální. Vedle toho existuje ještě vertikální komunikace.
CC – řízeně centralizovaná
Problémy se řeší na vrcholové úrovni, vnitřní koordinaci řídí vedoucí týmu. Komunikace mezi vedoucím a týmem je vertikální.
14
Dopad charakteristik projektu na organizaci týmu
Týmové struktura CD
Týmová struktura CC
nízká
X
X
velká
X
X
X
X
X
X
X
X
Týmová struktura DD vysoká
složitost řešeného problému
velikost výsledného programu
malá doba trvání týmu (životnost týmu)
X
X
krátká dlouhá
X
vysoká
stupeň modularizace problému
nízká požadovaná kvalita a spolehlivost budovaného systému
X
vysoká nízká
X
vysoká
tvrdost předávacích termínů požadovaný stupeň vnitřní komunikativnosti týmu (sociability)
X
nízká
X
vysoká
X
nízká
X
X
X
Jiná klasifikace rozlišuje pro organizaci týmů čtyři různá paradigmata: Uzavřené paradigma
struktura s tradiční hierarchií autorit (podobné CC)
Náhodné paradigma
uvolněná struktura, závislá na individualitách
Otevřené paradigma
pokus strukturovat tým s určitým řízením jako v uzavřeném paradigmatu, ale s ponecháním volnosti v tvorbě jako v náhodném paradigmatu
Synchronní paradigma
záleží na přirozeném dělení problému a organizuje členy týmu, aby pracovali na částech bez potřeby velké komunikace mezi sebou.
15
Koordinace a komunikace v týmu o Formální, neosobní přístup - dokumentace, zdrojový kód, zprávy, zápisy… o Formální, interpersonální procedury - týkají se zajištění kvality SW produktu. Kontrolní schůze, inspekce návrhu a kódu o Neformální, interpersonální procedury - schůze a neformální porady, které slouží k předávání informací v týmu a řešení problémů o Elektronická komunikace o Interpersonální síť - neformální diskuse se zkušenými experty mimo tým, kteří mohou asistovat členům týmu
Problém U řešeného projektu je nejdůležitější pochopit o cíle projektu o rozsah projektu o alternativy řešení o technická omezení Při popisu rozsahu (vymezení) softwaru rozlišujeme o kontext o vstupní a výstupní informace o funkce systému, kde nás zajímá jednoznačnost, srozumitelnost a omezenost Pro dekomposici problému používáme princip "Rozděl a panuj".
Modely softwarového procesu V úvodní kapitole jsme si uvedli čtyři základní modely životního cyklu SW projektu. V praxi rozeznáváme řadu dalších, kterými jsou: · lineární sekvenční model · model prototypování · rad model · přírůstkový model · spirálový model · model skládání komponent · model souběžného vývoje · formální metody · techniky čtvrté generace
16
Lineární sekvenční model (model vodopád) Je to klasický životní cyklus. V 80. letech byl podroben kritice, která dospěla k formulování základních nedostatků, kterými jsou: o reálné projekty zřídka kdy sledují jednotlivé kroky v předepsaném pořadí o pro zákazníka je obtížné vyjádřit předem všechny požadavky o provozuschopná verze bude k disposici až po delší době (může být už zastaralá) o často dochází k prodlevám Přesto však i v současné době je pro řešení řady i velkých projektů model vodopádu používán. Prototypování Slouží k pochopení požadavků na systémy, které nejdou dobře specifikovat předem. Prototypy, na kterých mají být modelovány nějaké vlastnosti systému, mohou být dělány s vědomím, že budou zahozeny. Tento model lze použít pro menší systémy. RAD model Rapid Application Development Je to lineární sekvenční model spočívající v extrémně krátkém vývojovém cyklu - do 3 měsíců. Model je určen pro dobře srozumitelné a dobře vymezené problémy, s malými riziky. Problém je rozdělen na samostatné moduly, které se rozdělí týmům. Při vývoji jsou využívány hotové softwarové komponenty. Přírůstkový model (evoluční model) Kombinuje lineární model s iterativní filosofií. Produkt se vytváří po částech (přírůstcích), které jsou funkční (na rozdíl od prototypu). První přírůstek je označován jako jádro. Model je vhodný pro malý tým a velký úkol, který se dá zvládnout v předem po částech, v domluvených termínech. Spirálový model (evoluční model) Model kombinuje prototypování se systematickým sekvenčním přístupem a opakováním na výším stupni zvládnutí problematiky. Je založen na prioritě tvorby verze s vyšší rizikovostí. Části s větší mírou rizika jsou realizovány dříve . Nevýhodu modelu je, že nelze stanovit přesné termíny (při práci na zakázku), závisí na správnosti rizikové analýzy, náročné na zkušenost pracovníků (je nutné více kontrolních bodů, po každé analýze rizik). Je vhodný pro velké systémy. Model skládání komponent (evoluční model) Spirálový model pro objektové technologie, který využívá skládání hotových komponent z knihovna tříd objektů.
17
Model souběžného vývoje (evoluční model) Jednotlivé komponenty jsou vyvíjeny paralelně (vývoj je modelován jako paralelní procesy). Je vhodný např. pro klient/server aplikace. Formální metody Spočívají na formálních specifikacích, podporují formální verifikaci programů. Nevýhody, které zatím brání praktickému nasazení je, že je drahý a časově náročný, je náročný na kvalifikaci vývojářů , je v něm obtížná komunikace s běžným uživatelem. Techniky čtvrté generace Jsou založeny na programování na vysoké úrovni abstrakce. Výhodou je rychlý vývoj a zvýšení produktivity. Nevýhodou je, že některé prostředky jsou stejně složité jako klasické programovací jazyky, výsledný kód nemusí být dostatečně efektivní a údržba velkého systému může být problematická. Za perspektivní metodu vývoje softwaru se považuje spojení CASE nástroje s modelem skládání komponent.
Proces Při řešení problematiky procesu realizace softwaru jsou nejdůležitější následující faktory: o výběr modelu o propojení problému a procesu o dekomposice (zjemnění) procesu
Závěr Podstatný vliv na management softwarových projektů mají 3P: o Pracovníci musí být organizování do efektivních týmů, motivováni k vysoce kvalitní práci, koordinováni tak, aby dosáhli efektivní komunikace. o Problém musí být definován v komunikaci zákazníka s realizátorem, rozdělen (dekomponován) na části a přidělen softwarovým týmům. o Proces musí být přizpůsoben lidem a problému, vybrán vhodný model
18
3
Plánování a vedení projektu
Při realizaci softwarového projektu je velmi důležitá komunikace se zákazníkem. Kdy komunikace se zákazníkem je jedna z nejobtížnějších částí projektu, a to i tehdy (často právě tehdy), jedná-li se o zákazníka poučeného. Na počátku má zákazník obvykle velmi jednoduché otázky, na které je velmi obtížné a často nemožné okamžitě odpovědět.
·
Rozumíte mému problému?
·
Umíte navrhnout systém, který bude řešit můj problém?
·
Jak dlouho vám bude trvat vyvinout takový systém?
·
Kolik to bude stát?
Zákazník i tvůrce jsou často ovlivňováni softwarovými mýty.
3.1
Softwarové mýty
Softwarové mýty se projevují na nejrůznějších úrovní tvorby systému. Uvedeme si zde některé z nich.
Mýty o řízení projektu mýtus
skutečnost
Existují normy, procedury, kuchařky jak co udělat…..
Jsou nepoužitelné, nejsou kompletní, neřeší naše problémy…..
Máme CASE, nejnovější počítače….
Počítače nejsou rozhodující, i nejnovější CASE neřeší vše …
Jestliže "nestíháme", dodáme více programátorů….
Neumí, nejsou seznámeni s problémem, musíme je školit….
19
Zákaznické mýty mýtus
skutečnost
Obecné zadání stačí, aby se začal psát program
Formální a detailní specifikace je podmínkou dobrého SW Ano, SW se snadno přizpůsobí, ale a jakou cenu? Čím později se požadují změny, tím jsou dražší…..
Požadavky se průběžně mění, ale SW je přizpůsobivý
Z následujícího grafu je patrné, jak rostou náklady na změny v programu, vyžadované v různých fázích životního cyklu softwarového díla. náklady na změnu
100 80 60 40 20 0
specifíikace
vývoj
údržba
náklady na změnu
obr. 3.1
Mýty praktika mýtus
skutečnost
Jestliže napíšeme program a ten "chodí", je hotovo
Čím dříve začneme psát program, tím později bude hotov. 50% - 70% práce na programu jsou až po předání zákazníkovi
Dokud program "neběží" nezjistím jeho kvalitu
Existují metody formální evaluace kvality
Je to jen část výsledného produktu. Musíme Jediný produkt úspěšného projektu je funkční doplnit dokumentaci, testování, údržbu, program zaškolení …..
20
Funkční program je jen část výsledného produktu. Na následujícím obrázku je znázorněna úplná konfigurace softwaru, která musí být zdokumentována nejen pro zajištění úspěšného vývoje systému, ale i pro je další údržbu.
3.2
Plán projektu
Abychom mohli naplánovat práce na projektu, musíme mimo jiné vědět, co vše bychom měli zákazníkovi předat. Mezi předávané části – produkty (deliverables) patří: o dokumentace o předvedení funkce o návrh subsystémů o důkaz přesnosti o prezentace efektivity, bezpečnosti a realizace Během práce na projektu je nutné stanovit jednotlivé aktivity a kontrolní dny, tzv. milníky (milestones). Příklad úkolů a kontrolních milník;u je uveden na obr. 3.23
procedurální návrh kontrola
analýza test
požadavky
návrh dat
kódování
testování
test jednotky
návrh
plánování testů
integra ční validační test test test
testování
milníky
Obr. 3.2
21
vyhodnocení testů
Na obrázku 3.5 jsou jednotlivé fáze projektu, které jsou rozčleněny na jednotlivé kroky a těm přiřazeny odpovídající aktivity.
Fáze, kroky a aktivity projektu fáze 1 projekt
krok 1 krok 2
fáze 2
krok 1 krok 2
fáze 3
krok 1 krok 2
aktivita 1.1 aktivita 1.2 ….. aktivita 2.1 aktivita 2.2 …..
….. …..
…. Obr.3.5
3.3
Plánování času
Při plánování (nejen softwarových projektů) platí tzv. pravidlo 90-90
Pravidlo 90 -90 Je-li odhadováno, že práce je hotová z 90%, pak ve skutečnosti zbývá dokončit ještě 90% práce.
Příčiny pozdního dodání softwaru Nejčastější příčiny pozdního dodání softwaru lze shrnout do následujícího seznamu: o nerealistický termín stanovený někým vně softwarové skupiny o změna požadavků zákazníka, se kterou se nepočítalo o podcenění pracnosti a nebo nutných zdrojů o předvídatelná nebo nepředvídatelná rizika, která nebyla uvažována při plánování projektu o technické obtíže, které nebyly předpokládány o lidské problémy, které nebyly předpokládány o nedorozumění a nebo špatná komunikace mezi členy týmu o chyba managementu projektu, že nepoznal, že se projekt zpožďuje a nezahájil opravné akce.
22
Zákazník má občas požadavky na dodání softwaru, které neodpovídají realitě. Záleží na vzájemné spolupráci jak jsou tyto situace řešeny. Existují obecné strategie, které je dobré dodržet. Obrana proti nerealistickým termínům zákazníka: 1.
Udělej podrobný odhad podle dat z minulosti. Urči odhad pracnosti a trvání projektu.
2. Použij přírůstkový model procesu a sestav plán dodání jádra systému, které bude zahrnovat kritické funkce systému a bude jej možné dodat do plánovaného termínu. S tím, že se zbytek dodá později. Připrav dokumentaci tohoto plánu. 3.
Vysvětli zákazníkovi, že jeho termíny jsou nerealistické a proč.
4.
Navrhni mu přírůstkovou strategii a dohodni se na řešení.
Základní principy plánování času o Rozdělení na zvládnutelné aktivity a úkoly o Stanovení vzájemných závislostí o Alokace času o Zvážení pracnosti o Stanovení odpovědností o Stanovení výstupů o Definování milníků
Mýtus Jestliže nestíháme plnit časový plán, přijmeme víc programátorů a doženeme skluz. Vztah mezi počtem lidí a produktivitou není lineární!
Pro rozložení pracnosti při práci na projektu platí pravidlo 40-20-40, které říká, že 40% práce je analýza 20 % je kódování 40 % testování
23
Při časovém plánování vycházíme s následujícího seznamu aktivit: o odhad pracnosti o dekomposice funkce produktu o výběr vhodného modelu procesu o výběr typu projektu a množiny úkolů
Typy softwarových projektů Softwarové projekty můžeme klasifikovat podle nejrůznějších kriterií, následující seznam je člení podle typu aplikace. 1. Projekty pro vývoj nového konceptu 2. Projekty vývoje nové aplikace 3. Projekty pro zdokonalení aplikace 4. Projekty údržby aplikace 5. Projekty pro reinženýrství
Stupeň rigoróznosti Při tvorbě softwaru se zajímáme i o to, jaké jsou specifické požadavky na proces tvorby a na produkt. Mluvíme o stupni rigoróznosti. Rozeznáváme tyto stupně rigoróznosti: o neformální - minimální množina úkolů, redukovaná dokumentace o strukturovaný - rámcové aktivity a příslušné úkoly o přísný - úplný proces, potřeba vysoké kvality, robustní dokumentace o rychlá reakce - vzhledem k nouzové situaci jsou aplikovány jen ty aktivity, které zajišťují dobrou kvalitu, úplná dokumentace je dodělána dodatečně po dodání produktu Jak stanovíme stupeň rigoróznosti? Existuje celá řada faktorů, ze kterých jsou nejdůležitější následující: o velikost produktu o počet potenciálních uživatelů o kritičnost mise o délka životnosti aplikace o stabilita požadavků o snadnost komunikace uživatel/zákazník o zralost aplikační technologie o omezující podmínky provedení
24
o vložené (embeded)/nevložené charakteristiky o pracovníci projektu o reinženýrské faktory Hodnota každého faktoru je 0-5 přičemž 1- projekt s malou podmnožinou úkolů, metodické a dokumentační požadavky jsou minimální 5 - kompletní množina procesních úkolů a metodické a dokumentační požadavky jsou podstatné
Příklad tabulky stupňů rigoróznosti pro úkol Kritéria
stupeň
váha
součin
násobek vstupního bodu koncept
nová apl.
zdokonal.
údržba
reinženýr.
velikost
2
1,2
0
1
1
1
1
2,4
Počet uživatelů
3
1,1
0
1
1
1
1
3,3
kritičnost
4
1,1
0
1
1
1
1
4,4
životnost
3
0,9
0
1
1
0
0
2,7
stabilita požadavků
2
1,2
0
1
1
1
1
2,4
komunikace
2
0,9
1
1
1
1
1
1,8
zralost techniky
2
0,9
1
1
0
0
1
1,8
omezení
3
0,8
0
1
1
0
1
2,4
embedded/non
3
1,2
1
1
1
0
1
3,6
zaměstnanci
2
1
1
1
1
1
1
2
spolupráce
4
1,1
0
1
1
1
1
4,4
reinženýring
0
1,2
0
0
0
0
1
0 2,6
Výběrová hdnota TSS pro úkol
Postup výpočtu výběrové hodnoty (TSS - Task set selector value): 1. stanov hodnotu každého kritéria (0-5)
25
2. uprav váhový faktor (0,8-1,2) podle důležitosti kritéria v místním prostředí 3. vynásob hodnotu kritéria * váhový faktor * násobek vstupního bodu, který označuje typ projektu 4. spočti průměrnou hodnotu výsledků Co nám udává hodnota stupně rigoróznosti?
Interpretace TSS: TSS < 1.2
neformální stupeň rigoróznosti
1 < TSS < 3
strukturovaný stupeň rigoróznosti
2,4 < TSS
přísný stupeň rigoróznosti
Př. 2.8 je buďto strukturovaný nebo přísný stupeň.
Tvorba plánu projektu Při tvorbě plánu projektu musíme o komunikovat o rozsahu a zdrojích s managementem, realizátorem a zákazníkem o definovat rizika a navrhnout techniky jejich řízení o definovat cenu a rozvrh kontrol managementu o poskytnout celkové informace o přístupu k řešení projektu všem, kteří na projektu budou spolupracovat o určit, jak bude zajištěna kvalita a jak budou řízeny změny Plán projektu obsahuje 8 základních částí: 1. 2. 3. 4. 5. 6. 7. 8.
úvod projektové odhady strategie řízení rizik časový harmonogram zdroje projektu organizační členění způsob kontroly přílohy
Příklad plánu projektu: I.
Úvod
26
A. Účel plánu B. Rozsah projektu a cíle 1. Rozsah 2. Hlavní funkce 3. Provedení 4. Technická omezení II.
III.
Projektové odhady A. Historická data použitá pro odhady B. Techniky odhadu C. Odhady pracnosti, ceny a trvání Strategie řízení rizik A. Tabulka rizik B. Diskuse o rizicích, která mají být řízena C. Plán RMMM pro každé riziko: 1. Snížení rizika 2. Monitorování rizika 3. Řízení rizikové situace
IV. Časový harmonogram A. Rozdělení nebo dekomposice projektových úkolů B. Síť úkolů C. Časový rozvrh (Ganttův graf) D. Tabulka zdrojů V. Zdroje projektu A. Lidské zdroje B. Hardware a software C. Speciální zdroje VI.
Organizační členění A. Struktura týmu B. Organizace zpráv managementu
VII.
VIII.
Způsob sledování a kontroly A. Zajištění kvality a kontrola B. Řízení změn a kontrola Přílohy
Sledování plánu
27
Jak probíhá sledování plánu? ·
periodické schůze o stavu projektu (zprávy o pokroku a problémech)
·
vyhodnocování výsledků všech kontrol během SI procesu
·
sledování, zda formální milníky byly splněny v plánovaných dnech
·
porovnání skutečných a plánovaným časů pro zahájení všech úkolů
·
neformální setkání s realizátory k získání jejich subjektivního odhadu postupu a předpokládaných problémů
Je potřeba ihned reagovat na případné problémy (i časový skluz je příznakem nějakého problému)!
Nástroje pro sledování plánu Uvedli jsme si, jak můžeme sledovat, zda je plán projektu plněn. Pro toto sledování je užitečné použít existující nástroje, kterými jsou: o Matice zodpovědností o Síť úkolů (PERT, CPM) o Časový diagram (Úsečkový graf, Ganttův diagram) o Tabulka projektu (projekt table) o Tabulka zdrojů (sloupcový graf - histogram) Jak jednotlivé nástroje fungují. Matice zodpovědností Matice zodpovědností vymezuje role a pravomoci subjektů, účastnících se prací na projektu.. Tvar matice zodpovědností: Činnosti/ Subjekty
Subjekt 1
Subjekt 1
Subjekt 1
...
činnost 1 činnost 2 činnost 3 ...
V prvním sloupci tabulky jsou uvedeny činnosti, pro které se přiřazují odpovědné subjekty. V první řádce tabulky jsou uvedeny odpovědné subjekty (osoby, role, organizační jednotky). Uvnitř tabulky jsou uvedeny písmena označující typy zodpovědnosti. Obvyklé typy zodpovědnosti jsou: P
subjekt je za činnost odpovědný
28
O
subjekt činnost provádí
K
subjekt má zodpovědnost konzultační
S
subjekt má odpovědnost schvalovací
Typy zodpovědnosti jsou závislé na povaze konkrétního projektu. Každá matice zodpovědnosti musí být doplněna vysvětlením typů zodpovědnosti. Metody síťových grafů Jde o síťový graf logického sledu činností konec-začátek konec-konec začátek-začátek začátek-konec CPM - metoda kritické cesty: V této metodě se nejprve stanoví doba trvání t úkolů (nejpravděpodobnější odhad času podle statistických modelů). Potom se spočítají hraniční časy pro jednotlivé úkoly podle těchto kriterií : 1. B1 - nejdříve možné zahájení úkolu (když předchozí úkoly jsou zvládnuté v minimálním čase) 2. B2 - nejpozději přípustný začátek úkolu (aniž by došlo ke skluzu projektu) 3. E1 - nejdříve možné ukončení úkolu ( (1)+doba trvání) 4. E2 - nejpozději přípustný konec úkol ((2)+ doba trvání) 5. povolený skluz 6. určí se kritická cesta (řetěz úkolů, určujících trvání projektu) Určíme časovou rezervu, která se spočítá následovně: celková rezerva
RC = E2 - B1 - t
volná rezerva
RV = E1 - B1 - t
nezávislá rezerva
RN = E1 - B2 - t
` Kritická cesta je nejdelší cestou v grafu. Doba jejích činností přímo ovlivňuje dobu trvání projektu.
29
1. Průchodem od začátku do konce se určí nejdříve možné začátky činností (vstupuje-li do určitého uzlu více činností, je to maximální hodnota - max. součet nasbíraných dob trvání), 2. Průchodem od konce se určí nejpozději přípustné začátky. 3. Pak se určí časové rezervy a kritická cesta. Činnosti kritické cesty mají nulovou časovou rezervu. Dobu projektu můžeme zkrátit: o změnou logiky vazeb o přesunem vnitřních zdrojů (z nekritických do kritických činností) o nasazením dodatečných zdrojů
"Aplikace síťových metod v řízení softwarových prací trpí nepřesností v odhadech dob řešení. Rovněž návaznost může být jiná než se předpokládá…používají se spíše u velkých projektů a i tam se střídavým úspěchem." Prof. Jaroslav Král Tabulka projektu (project table) Tabulka projektu obsahuje následující údaje: o úkol o plánované zahájení o skutečné zahájení o plánované skončení o skutečné skončení o přidělené osoby o pracnost o poznámky Sloupcový diagram zdrojů (histogram) pro plánování a sledování disponibilních zdrojů - (diagram vytížení zdrojů)
30
V nástroji MS Project:
obr.3.4 Výhodnější je zapojit zdroje, co nejpozději (Metoda Just in Time) - projekt tak váže nejmenší objem oběžných prostředků. Metoda tvorby struktury členění prací (WBS - Work Breakdown Structure)
obr. 3.5 Základní principem metody tvorby WBS je hierarchická dekomposice projektu na menší celky, aby bylo možné
31
·
zvýšit přesnost odhadů nákladů, času a zdrojů,
·
definovat srovnávací základnu pro měření výkonů a řízení prací,
·
umožnit jasné stanovení odpovědnosti.
Postup 1. Stanovte hlavní prvky projektu. Jsou to obecně předměty dodávek (služby i produkty) a řízení projektu. Jako první úroveň dekomposice mohou být použity fáze životního cyklu, které budou v další úrovni rozčleněny podle předmětů dodávek. 2. Rozhodněte, zda na dané úrovni je možné stanovit odpovídající odhady nákladů a trvání. V případě, že je odpovídající odhad možný, přejděte ke kroku 4, jinak ke kroku 3. 3. Stanovte dílčí předměty dodávek. Dílčí předměty by měly být stanoveny podle hmatatelných, ověřitelných výsledků. Mohou zahrnovat služby i produkty. Vraťte se ke kroku 2. 4. Ověřte správnost dekomposice: o Jsou položky na nejnižší úrovni dekomposice nutné a postačující pro dokončení dekomponované položky? o Je každá položka definovaná jasně a úplně? Jinak je potřeba popisy revidovat nebo rozšířit. o Může být každá položka naplánována, rozpočtována a přidělena konkrétní organizační jednotce (např. týmu nebo pracovníku), která převezme odpovědnost za její provedení? Jestliže ne, je potřeba provést revizi. 5. Pokud jsou prvky WBS popsány jako předměty dodávek, přepište je jako činnosti, vedoucí k tvorbě těchto dodávek. Poznámka: Při tvorbě WBS využívejte jako vzory WBS minulých podobných projektů.
32
4
Softwarové metriky
Metriky produktu, procesu a projektu jsou kvalitativní charakteristiky programů, procesu jejich tvorby a projektu. Důvody pro měření metrik: o plánování projektu (odhad nákladů, pracnosti, času) o kontrola kvality produktu o odhad produktivity o zdokonalení práce (růst výkonnosti organizace) Používané metriky vychází převážně z "historických zkušeností": o Jaké byla produktivita vývoje minulých projektů? o Jaká byla kvalita vytvořeného softwaru? o Jak mohou být tato data, týkající se kvality a produktivity, extrapolována na současný projekt? o Jak nám pomůže minulost při plánování a odhadech současného projektu?
4.1
Základní klasifikace metrik
Ukazatel (indikátor) je metrika nebo kombinace metrik, které poskytují náhled na softwarový projekt, proces nebo produkt. Slouží k jejich hodnocení, aby bylo možné případně provést nápravu. Ukazatelé procesu umožní náhled na efektivitu existujícího procesu. Metriky procesů jsou sbírány dlouhodobě v průběhu řešení různých projektů. Mají indikovat zlepšení softwarového procesu. (strategie) Ukazatelé projektu umožní odhadnout stav projektu, potenciální rizika, odkrýt oblasti problému, dřív než budou kritické, přizpůsobit směr práce a úkolů, vyhodnotit schopnosti projektového týmu řídit kvalitu SW. (taktika)
33
Určujícími prvky kvality softwaru a efektivity organizace jsou: o Zkušenost a motivace lidí o Složitost produktu o Technologie (metody softwarového inženýrství) o obchodní podmínky (obchodní pravidla, termíny..) o charakteristiky zákazníka (snadnost komunikace..) o vývojové prostředí (CASE) Metriky softwarového procesu mohou hrát významnou roli v růstu výkonnosti podniku, ale mohou být i zneužity a přinášet víc problémů, než užitku. Aby nebyly metriky zneužívány, měly bychom je používat v souladu s následujícími doporučeními:
o Při interpretaci dat používej zdravý rozum a organizační cit. o Poskytuj zpětnou vazbu týmům a jednotlivcům, kteří sbírali data a prováděli daná měření. o Nepoužívej metriky k hodnocení jednotlivců. o Veď jednotlivce a týmy k tomu, aby si stanovili jasné cíle a metriky, s jejichž pomocí by těch cílů dosáhli. o Nikdy nepoužívej metriky k vyjednávání s jednotlivci ani s týmy. o Data, která indikují nějaký problém, nemají být považována za negativní - jsou to pouze data, která poslouží k zlepšení procesu. o Nezaměř se jen na jednu metriku, nezapomeň na ostatní důležité metriky.
Metoda SSPI (Statistical Software Process Improvement) Tato metoda definuje následující postup: o chyby a defekty jsou kategorizovány podle původu (chyba ve specifikaci, v logice..) o je stanovena cena za opravu chyby o sečte se počet chyb podle kategorie o je stanovena celková cena chyb podle kategorie o analyzují se kategorie s nejdražšími chybami o snaha modifikovat proces, aby se eliminovala frekvence výskytu chyb v této kategorii
34
Projektové metriky Projektové metriky slouží k taktickým účelům (odhady času, nákladů, k monitorování projektu a k jeho vyhodnocování). Model projektové metriky: o vstupy: měří se zdroje (lidé, zařízení..) potřebné pro práci o výstupy: měří se předané výstupy nebo produkty vytvořené během projektu o výsledky: měří se efektivita (užitečnost) výstupů Tato metrika se může použít i k měření procesu a projektu. U projektu ji lze použít postupně pro každou vývojovou fázi.
Měření softwaru Při měření softwaru používáme dva odlišné přístupy: o přímá měření - počet řádek kódu (LOC), rychlost výpočtu, velikost paměti, počet chyb za určitou dobu … o nepřímá měření - funkčnost, kvalita, složitost, pracnost, spolehlivost, schopnost údržby,…
Metriky orientované na velikost (size-oriented) Tato metrika je odvozená z velikosti produktu a normalizovaná faktorem kvality či produktivity. Vychází se statistiky minulých projektů. Vstupní hodnoty odvozené z předcházejících projektů zahrnují: o počet řádek kódu (LOC) o pracnost (m/m) o cena o počet stran dokumentace o počet chyb o počet defektů o počet realizátorů Z těchto údajů můžeme odvodit: o počet chyb na KLOC o počet defektů na KLOC o cena LOC
35
o počet stran dokumentace na KLOC o počet chyb za člověkoměsíc o počet LOC za člověkoměsíc o cena stránky dokumentace
Funkčně orientované metriky Základní veličinou, se kterou pracujeme je FP (function point, funkční bod. Tato veličina je dána empirickým vztahem mezi spočitatelným měřením informační domény a odhadem složitosti softwaru. Rozhodující pro její určení jsou údaje: A
počet logicky různých vstupů
B
počet výstupů
C
počet dotazů
D
počet vnitřních logických souborů
E
počet souborů na rozhraních
Příklad výpočtu FP měrný faktor
váhový faktor
Počet
jednoduchý
průměrný
A:
(3 a1
+
4 a2
+
6 a3)
=
B:
(4 b1
+
5 b2
+
7 b3)
=
C:
(3 c1
+
4 c2
+
6 c3)
=
D:
(7 d1
+
10 d2
+
15 d3)
=
E:
(5 e1
+
7 e2
+
10 e3)
=
TOTAL
=
36
složitý
FP = TOTAL x (0,65+0,01 x suma (Fi))
Fi
pro i = 1..14 ( i je složitost zpracování) Mají hodnotu 0 – 5 hodnota Fi
vliv
0
nemá vliv
1
nahodilý
2
mírný
3
průměrný
4
významný
5
podstatný vliv
Fi F1
význam Požaduje systém zálohování a obnovu?
F2
Jsou požadovány datové přenosy?
F3
Obsahuje funkce distribuovaného zpracování?
F4
Je požadován kritický výkon?
F5
Bude systém pracovat za silném provozu?
F6
Požaduje systém přímý vstup dat?
F8
Požadují vstupní transakce přímé vstupy dat prostřednictvím více obrazovek nebo operací? Jsou hlavní soubory aktualizovány přímo?
F9
Jsou vstupy, výstupy, soubory a dotazy složité?
F10
Je složité vnitřní zpracování?
F11
Je kód navržen pro opakované použití?
F12
Jsou v návrhu zahrnuty konverze a instalace?
F13
Je systém navržen pro vícenásobné instalace na různých místech?
F14
Je aplikace navržena tak, aby usnadnila změny a snadné uživatelské ovládání?
F7
37
Rozšířené funkční metriky Třírozměrná funkční metrika - 3D Function Point pracuje ve třech rozměrech. K hodnotám A – E, ze kterých jsme odvozovali hodnotu FP, přichází další dva rozměry s hodnotami F a G: 1. datový (jako FP) 2. funkční (F - počet vnitřních operací potřebných k transformaci vstupních dat na výstupní) 3. řídicí (G - počet přechodů mezi stavy) měrný faktor
váhový faktor
Počet
jednoduchý
průměrný
složitý
A:
(3 a1
+ 4 a2
+ 6 a3)
=
B:
(4 b1
+ 5 b2
+ 7 b3)
=
C:
(3 c1
+ 4 c2
+ 6 c3)
=
D:
(7 d1
+ 10 d2
+ 15 d3)
=
E:
(5 e1
+ 7 e2
+ 10 e3)
=
F:
(7 f1
+ 10 f2
+ 15 f3)
=
G:
(1 g1
+ 1 g2
+ 1 g3)
=
3DFP
4.2
=
Vztahy mezi metrikami
Hrubý odhad počtu LOC na 1 FP pro různé programovací jazyky: Assembler
320
C
128
Cobol
105
Fortran
105
Pascal
90
Ada
70
objektově orientované jazyky
30
4GLs
20
tabulkové kalkulátory
6
grafické jazyky (ikony)
4
38
4.3
Faktory ovlivňující produktivitu tvorby softwaru
Produktivitu softwaru ovlivňuje řada faktorů, některé jsou objektivní jiné subjektivní. Některé se ovlivňují snadno, jiné se prakticky nedají ovlivnit. Hlavní faktory, které ovlivňují tvorbu softwaru jsou: o Lidský faktor (velikost a zkušenosti firmy) o Faktor problému (složitost problému, počet změn v návrhu omezení a požadavků) o Faktor procesu (techniky analýzy a návrhu, jazyk a CASE, techniky kontroly) o Faktor produktu (chování a spolehlivost systému) o Faktor zdrojů (dostupnost CASE nástrojů, HW a SW zdrojů)
4.4
Metriky kvality softwaru
Jak se dá měřit kvalita softwaru? Umíme posoudit složitost použitých algoritmů, ale ověřit správnost a spolehlivost softwaru je složitější. Správnost (correctness) se měří nejčastěji počtem chyb na tisíce řádku kódu (KLOC ). Udržovatelnost (maintainability) je snadnost, s níž může být program opraven, když se vyskytne chyba, jak rychle může být upraven, změní-li se prostředí, jak může být zdokonalován, rozhodne-li se zákazník upravit požadavky. Používáme zde přímé metriky. Používáme metriku MTTC (mean-time-to-change) – střední doba potřebná pro realizaci změn tj. doba potřebná pro analýzu požadovaných změn, návrh, implementaci, otestování a distribuci uživatelům. Rozeznáváme: o Spoilage - cena za opravu defektů objevených po distribuci. o Integrita - odolnost vůči náhodným nebo záměrným útokům z vnějšího prostředí (viry, hackers). integrita = suma (1- hrozba x (1- bezpečnost)) hrozba je pravděpodobnost útoku speciálního typu bezpečnost je pravděpodobnost odolání útoku speciálního typu suma je součet přes všechny typy útoků o užitečnost (usebility) - je snaha změřit "uživatelskou přívětivost".
39
Čtyři charakteristiky dobrého softwaru z pohledu zákazníka:: 1. fyzická a intelektuální dovednost nutná pro zvládnutí systému 2. čas potřebný na to, aby uživatel byl mírně zdatný v ovládání systému 3. vzrůst produktivity vzhledem k systému, který produkt nahrazuje, jestliže je uživatel mírně zdatný 4. subjektivní ocenění uživatelů (dotazníkem) Měření účinnosti odstraňování chyb softwaru DRE (Defect Removal Efficiency)
DRE = E / ( E + D) kde
E je počet chyb nalezených před předáním uživateli D je počet defektů po předání.
Hodnotu DRE definujeme vzhledem k jednotlivým vývojovým fázím: DREi= Ei / ( Ei + Ei+1 ) kde
Ei je počet chyb nalezených během SI etapy i Ei+1 je počet chyb nalezených během SI etapy i+1, které vznikly vlivem neobjevených chyb v etapě i
Závěr o Sbírám-li data o projektu, procesu a vytvářeném produktu, provádím-li měření a počítám-li metriky, mám možnost srovnání a poučení se vlastních chyb. o
Bez měření nepoznám, zda se zlepšuji.
40
5
Odhady času, zdrojů a nákladů
Odhady pracnosti, času, zdrojů a nákladů jsou hlavními aktivitami etapy, která se někdy označuje jako plánování rozsahu projektu.Odhady vychází z hodnot, které jsou dány: o složitostí projektu o velikostí projektu o metrikami minulých projektů o variabilitou v softwarových požadavcích
5.1
Popis rozsahu softwaru
Rozsah softwaru je dán řešeným problémem, jmenovitě: o funkcí systému o chováním o rozhraním o omezujícími podmínkami o spolehlivostí Všechny uvedené atributy problému mají vliv na jeho rozsah. Rozsah problému se stanoví na základě interwiev se zákazníkem
5.2
Schůzky se zákazníkem
Schůzky se zákazníkem mají svá pravidla a obvykle začínají předběžnou řízenou schůzkou se zákazníkem.
Předběžná řízená schůzka se zákazníkem Během této schůzky pokládáme zákazníkovy tři typy otázek: otázky bez vazby na řešený problém, otázky vedoucí k hlubšímu pochopení problému a otázky, které na první pohled s problémem nesouvisí, tzv. meta otázky. 1. Bezkontextové otázky (context free questions): o Kdo tu práci požaduje? o Kdo ji bude užívat? o Jaký bude ekonomický užitek při úspěšném ukončení? o Je ještě jiná možnost, jak to vyřešit?
41
2. Otázky vedoucí k hlubšímu pochopení problému a názoru zákazníka: o Jak byste charakterizoval "dobrý" výstup? o Na jaké problémy je toto řešení zaměřeno? o Ukažte mi (popište) prostředí, kde to bude systém pracovat? o Jsou nějaké speciální požadavky na chování systému a na jeho omezení? 3. "meta otázky": o Jste ta správná osoba, která mi může na tyto otázky odpovědět? o Jsou vaše odpovědi oficiální? o Jsou mé otázky relevantní k danému problému? o Nedávám vám moc otázek? o Je tu ještě někdo další, kdo by mohl poskytnout doplňující informace? o Je ještě něco, na co bych se měl zeptat?
Další schůzky Další setkání se zákazníkem jsou formálnější. Týkají se řešení problému, vyjednávání a specifikací zadání. Velmi často se zde využívá techniky označované jako FAST (Facilitated Application Specification Techniques). Schůzka, která využívá FAST je charakterizována následovně: o Je to schůzka realizátorů a zákazníků. o Je řízena neutrální stranou (facilitátorem). o Určují se pravidla pro přípravu a průběh realizace projektu. o Je specifikována agenda, která bude vedena. o Používá se tabule, flip chart apod. o Cílem schůzky je identifikovat problém, navrhnout řešení, vyjednat odlišné přístupy a specifikovat předběžnou množinu požadavků
5.3
Plánování zdrojů
Po stanovení rozsahu projektu je třeba naplánovat zdroje. Mezi zdroje řadíme: o lidské zdroje o využitelné SW komponenty o HW a SW nástroje Je nutné provést identifikaci každého zdroje, jeho popis, zjistit jeho dostupnost, čas, kdy bude požadován a na jak dlouho. V současné době mají stále vetší význam softwarové komponenty.
42
Rozlišujeme čtyři druhy těchto komponent: 1. hotové komponenty (off-the-shelf components) 2. komponenty se zkušeností (full-experience components) 3. komponenty s částečnou zkušeností (partial-experience components) 4. nové komponenty Při plánování využití softwarových komponent platí tato doporučení: o Pokud nějaká hotová komponenta odpovídá projektovým specifikacím, získej ji. Cena za nákup a její integraci je skoro vždycky menší, než cena za vývoj. Také rizika jsou relativně malá. o Pokud jsou dostupné komponenty se zkušeností, riziko spojené s jejich modifikací a integrací je obecně přijatelné. o Pokud jsou dostupné komponenty s částečnou zkušeností, jejich použití pro současný projekt musí být detailně analyzováno. Pokud je třeba velkých modifikací, buď opatrný. Cena za modifikaci takových komponent může být větší než cena za vývoj nových.
5.4
Odhad ceny a pracnosti
S plánováním projektu souvisí i odhad ceny a pracnosti projektu. Tento odhad je možné provést jako: o Odhad se zpožděním. o Počáteční odhad podle minulého podobného projektu. o Odhad s použitím dekomposičních technik. o Odhad s použitím empirických modelů. Přesnost odhadu projektu je ovlivněna: o přesností odhadu velikosti produktu o schopností převést odhad velikosti na odhad pracnosti, času, finančních nákladů (závisí na dostupnosti spolehlivých metrik z minulých projektů) o schopnostmi projektového týmu o stabilitou požadavků na projekt a vývojovým prostředím
Dekomposiční techniky Dekompoziční techniky jsou odhady vycházející z problému. Tyto techniky používají veličiny LOC – počet řádků kódu a FP – funkční bod.
43
LOC a FP se používají: o jako proměnné pro odhad různých veličin v projektu o jako základní údaje o minulých projektech K odhadu používáme tzv. tříbodový odhad, který je dán vzorečkem:
EV = ( sopt + 4 sm + spes ) / 6 kde sopt sm spes
je optimistický odhad je střední odhadovaná hodnota je pesimistický odhad
Odhad založený na procesu
Příklad 5.1 Máme navrhnou CAD systém, který bude akceptovat dvourozměrná a třírozměrná data. Uživatel interaktivně komunikuje se systémem. Komunikace musí být uživatelsky přívětivá. Všechna geometrická data a další informace jsou uchovávána v CAD databázi. Modul analýzy návrhu bude vytvářet výstupy pro různá grafická zařízení. Systém bude komunikovat s periferními zařízeními typu myš, digitizér, displej, laserová tiskárna a plotter. Abychom mohli provést odhad, stanovíme si následující funkce systému a jim odpovídající moduly.: o UICF - modul řízení a komunikace s uživatelem o 2DGA - dvojrozměrná geometrická analýza o 3DGA - třírozměrná geometrická analýza o DBM - řízení databáze o CGDF - modul grafického zobrazení o PC - řízení periferií o DAM - modul analýzy návrhu
Příklad 5.1 - Odhad LOC Odhad počtu řádků kódu pro jednotlivé moduly počítáme podle tříbodového odhadu. EV = ( sopt + 4 sm + spes ) / 6
44
Např.pro modul 3DGA je tento výpočet (4600+4*6900+8600)/6=6800
Optimistický odhad
Střední odhad
Pesimistický odhad
Výsledná hodnota
UICF
1800
2400
2650
2340
2DGA
4100
5200
7400
5380
3DGA
4600
6900
8600
6800
DBM
2950
3400
3600
3350
CGDF
4050
4900
6200
4950
PC
2000
2100
2450
2140
DAM
6600
8500
9800
8400
celkem
33360
Z historických údajů víme, že průměrná produktivita pro systémy tohoto typu je 620 LOC/mm (řádků kódu na jeden člověkoměsíc). Počítáme-li náklady 30 000Kč na mm (člověkoměsíc), pak cena jedné LOC je 48,38 Kč. Celková cena produktu podle tohoto odhadu bude 1 614 000 Kč (zaokrouhleno na tisíce) a pracnost 54 mm. V praxi bychom měli provést odhad pro každý modul zvlášť.
Příklad 5.1 - Odhad FP Jiný odhad můžeme provést podle veličiny FP (Funkční bod). Opět použijeme tříbodový odhad. Odhad pro projekt z příkladu 5.1 je v následující tabulce. optimistický pravděpodobný pesimistický
EV
váha
FP
počet vstupů
20
24
30
24,3
4
97,2
počet výstupů
12
15
22
15,7
5
78,5
počet dotazů
16
22
28
22
4
88
počet souborů
4
4
5
4,2
10
42
počet externích souborů
2
2
3
2,2
7
15,4
součet
321,1
45
V následující tabulce je odhad FP pro 14 hodnot složitosti zpracování F i: F1
zálohování a obnova
4
F2
datové přenosy
2
F3
distribuované zpracování
0
F4
kritický výkon
4
F5
existující operační prostředí
3
F6
přímý vstup dat
4
F7
vstupní transakce přes více obrazovek
5
F8
přímá aktualizace hlavních souborů
3
F9
složité hodnoty domény informací
5
F10
složité vnitřní zpracování
5
F11
návrh kódu pro opakované použití
4
F12
v návrhu jsou konverze/instalace
3
F13
vícenásobné instalace
5
F14
návrh aplikace pro změny
5
celkem
52
Výpočet FP provedeme podle metodiky z kapitoly 4.1.5, kde je uvedeno, že FP=TOTAL * (0,65 + 0,01 * suma (Fi), kde TOTAL je celková odhadovaná hodnota 321 a suma Fi byla vypočítána v předchozí tabulce. Tedy FP = 321 * (0,65+0,01*52) =376 Z historických údajů víme, že průměrná produktivita pro systémy tohoto typu je 6,5 FP/mm, tedy pracnost v tomto případě bude 376 / 6,5 = 58 mm. Cena 1 FP je asi 3850 Kč, tedy odhadovaná cena produktu bude 376 * 3850 = 1 448 000 Kč. Celková cena produktu bude při tomto odhadu 1 448 000 Kč (zaokrouhleno na tisíce) a pracnost 58 mm.
46
Příklad 5.1 - Procesní odhad aktivita
analýza
návrh
kódováni
testováni
celkem
UICF
0,3
0,7
0,1
1,1
2,2
2DGA
0,7
3,3
1,5
3,2
8,7
3DGA
0,8
4,0
2,0
3,8
10,6
DSM
0,7
2,0
1,0
1,3
5,0
CGDF
0,5
3,8
1,3
3,5
9,1
PDF
0,6
2,0
1,2
1,8
5,6
DAM
1,3
4,5
1,4
2,1
9,3
celkem
4,9
20,3
8,5
16,8
50,5
cena za jednotku
24000
25000
26000
21000
cena
117600
507500
221000
352800
1198900
Celková cena produktu podle procesního odhadu bude 1 199 000 Kč a pracnost 51 mm. Porovnání odhadů pracnosti a ceny z příkladu 5.1 Procesní odhad 51 mm
1 199 000 Kč
Odhad FP
58 mm
1 448 000 Kč
Odhad LOC
54 mm
1 614 000 Kč
Příklad 5.1 Průměrná hodnota odhadu času je 53 mm (největší odchylka je 7 %) . Průměrný odhad ceny je 1 440 000 Kč
Empirické modely odhadu
47
Pro odhad pracnosti existuje celá řada empirických modelů, ve kterých vystupují veličiny FP nebo LOC vycházející z řešeného projektu a empiricky odvozené konstanty z předchozích projektů A, B, C. Při jejich použití je vhodné provést porovnání odhadu podle několika modelů. Obecný tvar rovnice modelů je
E = A + B (ev)C kde
E je pracnost A, B, C jsou empiricky odvozené konstanty ev je proměnná udávající hodnotu LOC nebo FP
E= 5,2 (KLOC)0,91
Walson-Felixův model
E= 5,5+ 0,73(KLOC)1,16
Bailey-Basiliho model
E= 3,2 (KLOC)1,05
Boehmův jednoduchý model
E= 5,288 (KLOC)1,047
Dotyův model pro KLOC >9
E = -13,39 + 0,0545 FP
Albrecht a Gaffneyův model
E = 60,62x 7,728 x 10-8 FP3
Kemererův model
E = 585,7 + 15,12 FP
Matson, Barett a Mellichampův model
Model COCOMO (COnstructive COst MOdel) Za nejpropracovanější a nejpoužívanější empirický model můžeme považovat model COCOMO. Jsou definovány tři třídy projektů, které v modelech COCOMO rozeznáváme: 1. Organický mód 2. Přechodný mód 3. Uzavřený mód Model COCOMO je definován ve třech úrovních: 4. Základní COCOMO model - pracnost a cena jako funkce velikosti programu v LOC. 5. Střední COCOMO model - pracnost a cena jako funkce velikosti programu v LOC a množiny dalších faktorů (produkt, HW, lidé, projekt). 6. Pokročilý COCOMO model – má navíc odhad faktorů každé etapy softwarového procesu. Rovnice základního modelu
48
E= a (KLOC)b D= c (E)d kde
E je pracnost v člověkoměsících, D je doba vývoje v měsících koeficienty a, b, c, d se odvozují z třídy projektu
Koeficienty a, b, c, d pro základní model: a
b
c
b
organický mód
2,4
1,05
2,5
0,38
přechodný mód
3,0
1,12
2,5
0,35
uzavřený mód
3,6
1,2
2,5
0,32
Rovnice středního modelu
E= a (KLOC)b * EAF kde
EAF je faktor pracnosti a nabývá hodnot mezi 0.9 a 1.4
Koeficienty a, b, c, d prostřední model model: Střední model COCOMO
a
b
organický mód
3,2
1,05
přechodový mód
3,0
1,12
uzavřený mód
2,8
1,2
Faktor EAF vychází z charakteristiky projektu a zahrnuje v sobě
49
1. atributy produktu: o RELY - míra požadavků na spolehlivost o DATA - míra rozsahu datové základny o CPLX - složitost produktu 2. atributy hardware: o TIME - míra požadavků na dobu odezvy o STOR - míra využití paměti o VIRT - míra stability počítače 3. atributy týmu: o ACAP - míra schopnosti analytiků o AEXP - míra zkušenosti programátorů s aplikací o PCAP - míra kvality programátorů o VEXP - míra zkušenosti s virtuálním počítačem (OS, programovací prostředí) o LEXP - míra zkušenosti s programovacím nástrojem 4. atributy projektu: o MODP - míra použití moderních programovacích metod o TOOL - míra použití moderních programovacích nástrojů o SCED - tvrdost požadavků na dobu realizace
Příklad 5.1 – odhad COCOMO Pro systém z příklady 5.1 zvolíme základní model s rovnicí E= a (KLOC)b pro výpočet pracnosti E. Úloha představuje přechodný mód projektu, tedy hodnoty a, b, c, d budu z tabulky 3,0; 1,05; 2,5 a 0,35. Výpočet: E = 3 (33,2)1,05 = 120 mm D = 2,5 (120)0,35 = 15,3 m Doporučený počet osob: N = E/D = 120 / 15,3 = asi 8 lidí
Softwarová rovnice
50
Další možnost jak provést odhad pracnosti je využití softwarové rovnice.
E = (LOC x B 0,333/ P) 3 * (1 / t 4) kde
E je pracnost v mm t je trvání projektu v měsících nebo letech B je faktor zkušenosti pro KLOC =5..15, je B= 0,16, pro KLOC>70 je B=0,39 P je parametr produktivity, který odráží: celkovou zralost procesu a praktik vedení projetu použité praktiky analýzy a návrhu úroveň programovacího jazyka stav softwarového prostředí zkušenost softwarového týmu složitost aplikace P = 2000 -.systémy reálného času P = 10000 -telekomunikační a systémový software, P = 28000 - obchodní aplikace
Závěr Při plánování je třeba odhadnout: dobu trvání jednotlivých činností pracnost činností (v mm) potřebné zdroje (lidí, HW, SW a jiné zařízení a nástroje) Máme dvě kategorie odhadů: dekomposice - rozdělení hlavních funkcí a odhad velikosti nebo pracnosti implementace každé funkce) empirické modely - odvozené formule pro pracnost a čas Přesnější odhady získáme porovnáním více technik.
Vše závisí na dobrých historických datech!
51
6
Řízení rizik
Představme si, že plánujeme nějaký výlet nebo dokonce delší prázdninovou cestu do zahraničí. Pokud nevyužijeme služeb některé cestovní kanceláře, ale ani tam, jak dobře víme, to není bez rizika, budeme muset shánět potřebné informace a plánovat cestu sami. Ale ať máme sebelepší plán, skutečnost může dopadnout jinak. Jak se s tím vyrovnáme? Dejme tomu, že jedeme vlakem a máme přestupovat. Vlak má zpoždění a plánovaný přípoj nám ujede. Co budeme dělat? Pojede do našeho cíle jiný spoj, nebo se budeme muset vrátit, či snad budeme muset někde neplánovaně přenocovat? Chystáme se na výlet a předpokládáme příjemné slunečné počasí, ale počasí se zkazí a bude pršet. Naplánovali jsme si občerstvení v hospůdce při cestě, ale netušíme, že pivo naší oblíbené značky, došlo. Jedeme lyžovat do Alp a zlomíme si nohu. Každá taková cesta skrývá řadu rizik, se kterými se musíme vyrovnat. Některá jsou vážná, jiná méně. Některá rizika můžeme přijmout, jiná ne. Možná, že budeme ochotni přijmout riziko nedostatku oblíbeného nápoje. Možná přijmeme i riziko náhlé změny počasí. Nanejvýš si pro klid duše přibalíme pláštěnku. Jiná rizika, ale přijmout nemůžeme. Víme, že pravděpodobnost zpoždění vlaku, alespoň u nás, není malá, a tak se na ně budeme muset připravit. A pokud neexistuje náhradní způsob dopravy, bude rozumnější naplánovat cestu jinudy nebo jinam. Která rizika jsou tedy vážná? Jsou to rizika, která s velkou pravděpodobností nastanou a která nám způsobí velkou nesnáz. S takovými riziky je potřeba počítat v našem plánu. Nejprve se budeme snažit takovým rizikům vyhnout. Například abychom se vyhnuli riziku zpoždění vlaku při přestupování, pokusíme se nalézt přímý spoj do cílové stanice. Pokud se riziku vyhnout nelze, budeme se snažit je zmírnit. Nalezneme spojení, kde bude dostatečná časová rezerva pro přestup (snížíme pravděpodobnost rizika, že nám další vlak ujede), nebo vyhledáme spojení s přestupem v místě, kde bychom mohli rozumně přečkat do odjezdu dalšího vlaku (zmírníme negativní dopad tohoto rizika). Některým rizikům se vyhnout nelze a nedá se je ani zmírnit. Pak se budeme muset připravit na to, že situace může nastat. Na změnu počasí se připravíme dostatečným oblečením, proti následkům případného úrazu můžeme uzavřít pojištění. Pro případ, že hospůdka, ve které plánujeme oběd, bude mimo provoz, bychom měli mít připravené náhradní řešení, havarijní plán.
Zopakujme si to. Při plánování výletu, ale samozřejmě i při plánování každého většího projektu, bychom měli identifikovat možná rizika, vyhodnotit je s ohledem na pravděpodobnost s jakou nastanou a na negativní důsledky, které mohou způsobit. Potom bychom měli vybrat ta rizika, která jsou pravděpodobná a
52
mohou mít vážné důsledky a pro ně navrhnout odezvu nebo takzvaná protiriziková opatření. Tím řízení rizik nekončí. Během realizace projektu budeme monitorovat příznaky vytipovaných rizik a budeme rozhodovat o nasazení protirizikových opatření. Budeme přemýšlet, zda se nezměnila situace a zda třeba některá rizika, která jsme přijali jako málo pravděpodobná, už nejsou významná, nebo zda se neobjevila rizika nová. Možná, že vám výše popsané chování připadá příliš úzkostlivé, že jste ten typ lidí, kteří si říká, že to vždycky „nějak dopadne“, který řeší problémy, až když nastanou, a který je hrdý na to, že zatím vždycky všechno zvládl. Takové chování je obdivuhodné u hrdiny akčního filmu, ne však u vedoucího projektu.
6.1
Vysvětlení základních pojmů
Riziko je nejistá událost, která má nějaký dopad na daný objekt nebo proces. Riziko se měří v pojmech pravděpodobnosti a dopadu. V běžném slova smyslu chápeme rizika, jako taková, která hrozí negativním dopadem, ztrátou. Některé metodiky definují rizika jako nejisté události, které mohou mít jak negativní tak i positivní dopad. Těm negativním říkají hrozby, těm positivním příležitosti. Řízení rizik (Risk Management) je systematické uplatňování taktiky, praktik a procedur managementu s cílem identifikovat, analyzovat rizika a reagovat na tato rizika. Řízení rizik v projektu se skládá z několika procesů. Proces identifikace rizik, proces ohodnocení rizik a proces plánování protirizikových opatření se provádí v plánovací fázi projektu. Ve fázi realizace projektu se pak provádí operativní řízení protirizikových opatření. Pokud jsou rizika řešena ad hoc, až v okamžiku, kdy nastanou, jedná se o reaktivní strategii („hašení problémů“ dobře známe z běžné praxe). Přístup o kterém hovoříme zde - proaktivní strategie- je efektivnější, protože je levnější se předem zabývat riziky než potom jejich negativními následky. Rizika jsou charakteristická tím, že vždy zahrnují nejistoty a v případě, že nastanou, ztráty. Postup zpracování a řízení rizik je thematicky zobrazen na obr. 6.1 Rozeznání rizik
Seznam možných rizik
Analýza rizik
Plánování rizik
Seznam rizik podle priorit
Předcházení rizik
53
Monitorování rizik
Vyhodnocení rizik
obr.6.1
6.2
Kategorie rizik
Rizika bývají dělena podle možnosti jejich identifikace: ·
známá rizika - dají se odhalit po pečlivém vyhodnocení plánu, obchodního a technického prostředí a z jiných spolehlivých zdrojů
·
předvídatelná rizika - jsou extrapolována ze zkušenosti z předchozích projektů
·
nepředvídatelná rizika - dají se jen velmi těžko předpovědět.
Rizika můžeme dělit také na ·
rizika vnitřní – tato rizika může tým projektu ovládat nebo ovlivnit
·
rizika vnější – to jsou rizika, které tým projektu ovlivnit nemůže.
Dělení rizika podle [Boehma]: -
Generická rizika – společná pro všechny projekty, týkají se základního plánu vývoje softwaru, např. poruchový produkt, neřízené projekty, nekontrolované produkty
-
Projektově specifická rizika – ta by měla být popsána ve specifickém plánu rizik, např. nejasnosti uživatelského rozhraní, nejednoznačné požadavky chování, napnuté termíny a rozpočet.
6.3
Identifikace rizik
Identifikace rizik spočívá v určení, která rizika mohou ovlivnit projekt. Tato rizika je zapotřebí popsat a dokumentovat. K identifikaci rizik se nejčastěji používá metoda kontrolních seznamů. Je to seznam otázek, který by nás měl navést na oblasti možných rizik. Při tvorbě kontrolních seznamů můžeme vycházet z literatury. Je ale přirozené, že softwarové knihy se zaměřují převážně na generická rizika. Projektově specifická rizika si musíme ošetřit sami. Důležité je, abychom se uměli učit z vlastních chyb. Víme-li, co nám způsobilo nesnáz v minulém projektu, zapíšeme do kontrolního seznamu. Tam, kde kontrolní seznamy nestačí, je potřeba rozmýšlet specifické podmínky projektu v týmu a vyzpovídat zainteresované strany. Měli bychom vzít v úvahu různé zdroje rizik, jako je například - změna požadavků zákazníka - chybná nebo neúplná specifikace zadání - špatné odhady pracnosti a času - nedostatečně kvalifikovaní pracovníci a další, a také možné rizikové události, kterými může být jak přírodní katastrofa tak i třeba odchod člena týmu.
54
Tam, kde je to možné, měli bychom identifikovat příznaky rizik, které mohou indikovat blížící se rizikovou událost (např. nespokojenost pracovníků může být příznakem rizika zpoždění projektu nebo fluktuace pracovníků). [Pressman] uvádí různé kategorie rizik, kterými bychom se měli zabývat, abychom postihli všechny aspekty spojené s projektem, procesem a vytvářeným produktem. Jsou to například: o
Projektová rizika, která se týkají plánu projektu: problémy rozpočtu, harmonogramu, zdrojů, zákazníka, jeho požadavků a jejich dopadů na projekt.
o
Technická rizika, která se týkají kvality produktu, potenciální rizika návrhu, implementace, verifikace, údržby produkovaného softwaru.
o
Obchodní rizika, která mohou být například: · vybudování skvělého produktu, který nikdo nechce (marketingové riziko) · vybudování produktu, který už nezapadá do obchodní strategie firmy (strategické riziko) · vybudování produktu, kterému obchodní zástupci nerozumí a neví, jak ho prodat · ztráta podpory vedení, vlivem změny zaměření nebo změny osob (riziko managementu) · ztráta rozpočtu (rozpočtové riziko)
6.4
Rizika softwarového projektu
Ukažme si příklady kontrolních seznamů, které uvádí [Pressman] pro identifikaci známých a předvídatelných rizik následujících generických kategorií: ·
velikost produktu
·
obchodní dopad
·
charakteristiky zákazníka
·
definice procesu
·
vývojové prostředí
·
vytvářená technologie
·
velikost týmu a jeho zkušenost
Rizika spojená s velikostí produktu Čím je větší produkt, tím jsou větší případná rizika, že se dodávka zpozdí, objeví se nepředvídané okolnosti, které projekt prodraží, nebo způsobí snížení kvality výsledného produktu. Následuje výčet možných zdrojů rizik velikosti produktu:
55
·
odhad velikosti v LPC nebo FP
·
stupeň důvěry v odhad
·
odhad velikosti produktu v počtu programů, souborů, transakcí
·
průměrná procentuální odchylka velikosti produktu z průměru velikostí předchozích produktů
·
velikost databáze vytvářené nebo používané v produktu
·
počet uživatelů produktu
·
počet projektovaných změn požadavků pro produkt - před dodáním, po dodání
·
množství znovupoužitého softwaru
V každém případě se vyplatí, můžeme-li daný projekt porovnat s projekty minulými, poučit se ze zkušenosti s problémy nebo s chybami, které jsme udělali dříve. Je-li současná situace podobná, je riziko, že se problémy budou opakovat, větší.
Rizika obchodního dopadu Tato skupina představuje rizika, která se mohou objevit po dokončení produktu. Následuje výčet otázek, které nás mohou upozornit na možný zdroj rizika: ·
Jak produkt ovlivní zisk společnosti?
·
Je produkt viditelný vedením společnosti?
·
Je dodací termín rozumný?
·
Počet zákazníků, kteří budou používat tento produkt a konsistence jejich potřeb s vlastnostmi produktu?
·
Počet ostatních produktů/systémů, s nimiž musí produkt spolupracovat?
·
Kvalifikace koncových uživatelů?
·
Množství a kvalita dokumentace produktu, která musí být vytvořena a dodána zákazníkovi?
·
Státní omezení (normy) na tvorbu produktu?
·
Cena za pozdní dodání?
·
Cena za defektní produkt?
Při identifikaci rizik nám opět pomůže zkušenost s minulými projekty a porovnání s těmi úspěšnými i neúspěšnými.
Rizika spojená se zákazníkem Tato část by měla postihnout rizika práce se zákazníkem, které mohou vyplývat z jeho neschopnosti či neochoty spolupracovat, z nemožnosti komunikace s ním a podobně. Záporná odpověď na následující otázky může znamenat případný zdroj rizika. ·
Pracoval jsi se zákazníkem již dříve?
56
·
Ví zákazník dobře, co požaduje? Věnoval čas tomu, aby to popsal?
·
Souhlasí s tím, že bude muset věnovat čas realizátorům, aby mohli s jeho pomocí stanovit požadavky a identifikovat rozsah projektu?
·
Chce komunikovat s realizátorem?
·
Chce se zúčastnit kontrolních dnů projektu, při přezkoumávání produktu?
·
Je zákazník technicky vzdělaný v oblasti produktu?
·
Nechá zákazník pracovníky dělat svou práci - tzn. nebude se jim tak zvaně „dívat přes rameno“?
·
Rozumí zákazník softwarovému procesu?
Procesní rizika Procesní rizika se týkají jednak špatně definovaného procesu a jednak technik, které se používají a mohou být nedostatečné. Proces, který neodpovídá osvědčeným standardům, může být rizikový. Nevhodné techniky mohou být zdrojem rizik. Záporná odpověď na některou z následujících otázek indikuje, že softwarový proces je slabý a rizika vysoká. Otázky o procesu: ·
Podporuje vedení společnosti standardizaci procesu softwarového vývoje?
·
Vydala vaše organizace popis softwarového procesu, který je možné použít pro projekt?
·
Přijali členové týmu tento popis budou ho používat?
·
Byl tento softwarový proces používán pro jiné projekty?
·
Poskytuje vaše organizace kurzy pro manažery a technické pracovníky?
·
Jsou publikované standardy SI poskytovány všem vývojářům a manažerům?
·
Jsou dokumentované všechny dodávky, které jsou součástí softwarového procesu?
·
Jsou řádně prováděna přezkoumání specifikací požadavků, návrhu a kódu?
·
Jsou řádně prováděna přezkoumání testovacích procedur a testovacích případů?
·
Jsou přezkoumání dokumentována, včetně nalezených chyb a použitých zdrojů?
·
Je zajištěno, aby práce na projektu odpovídaly standardům SI?
·
Jsou řízeny konfigurace k udržení konsistence v systémových/softwarových požadavcích, návrhu, kódu a testovacích případech?
·
Jsou řízeny změny v požadavcích zákazníka, které mají dopad na software?
·
Je pro každý subkontrakt dokumentována práce, specifikace softwarových požadavků a plán softwarového vývoje?
Otázky k technikám: ·
Jsou používány facilitativní techniky při komunikaci zákazníka s vývojářem?
·
Jsou požívány specifické metody pro softwarovou analýzu?
57
·
Používáte specifické metody pro návrh dat a architektury?
·
Je více než 90% vašeho kódu napsáno v jazyce vyšší úrovně?
·
Je definována a používána specifická konvence pro dokumentaci kódu?
·
Používáte specifické metody pro návrh testovacích dat?
·
Používají se softwarové nástroje pro podporu plánování a řízení?
·
Používají se softwarové nástroje pro řízení konfigurací a změn?
·
Používají se softwarové nástroje pro podporu analýzy softwaru a proces návrhu?
·
Používají se nástroje pro tvorbu softwarových prototypů?
·
Používají se softwarové nástroje pro podporu testování?
·
Používají se softwarové nástroje pro podporu tvorbu dokumentace?
·
Sbírají se kvalitativní metriky v každém softwarovém projektu?
·
Sbírají se metriky produktivity v každém softwarovém projektu?
Technologická rizika Moderní technologie se velmi rychle rozvíjí. Je přirozené, že se snažíme překonávat technická omezení a za použití nejnovějších technologií plně rozvinout své představy. Nicméně nové technologie přinášejí velká rizika. Kladná odpověď na některou z následujících otázek může indikovat zdroj rizika, který by měl být blíže prověřen. ·
Je budovaná technologie pro vaši organizaci nová?
·
Požaduje zákazník tvorbu nových algoritmů nebo vstupně výstupní technologie?
·
Bude mít software rozhraní s novým a neověřeným hardwarem?
·
Bude mít vytvářený software rozhraní s nakoupeným softwarovým produktem, který není prověřený?
·
Bude mít vytvářený software rozhraní s databázovým systémem, jehož funkce a chování nebylo ověřeno v dané aplikační oblasti?
·
Je požadováno speciální uživatelské rozhraní?
·
Je požadována tvorba programových komponent, které jsou odlišné od dříve vytvořených ve vaší organizaci?
·
Je požadováno používání nových metod analýzy, návrhu nebo testování?
·
Je požadováno použití nekonvenčních metod vývoje softwaru, jako jsou formální metody, přístupy založené na umělé inteligenci nebo neuronových sítí?
·
Obsahují požadavky nadměrná funkční omezení produktu?
·
Zákazník si není jistý, zda požadovaná funkčnost bude proveditelná?
Rizika vývojového prostředí
58
Je-li většina odpovědí na následující otázky záporná, je softwarové vývojové prostředí slabé a rizika jsou vysoká. · Je k disposici nástroj pro management softwarového projektu? · Je k disposici nástroj pro management softwarového procesu? · Jsou k disposici nástroje pro analýzu a návrh? · Poskytují nástroje pro analýzu a návrh metody vhodné pro vytvářený produkt? · Jsou k disposici překladače nebo generátory kódu a jsou vhodné pro vytvářený produkt? · Jsou k disposici nástroje pro testování a jsou vhodné pro vytvářený produkt? · Jsou k disposici nástroje pro konfigurační management? · Jsou všechny softwarové nástroje integrovány? · Byli členové týmu vyškoleni v používání všech nástrojů? · Jsou k disposici konzultanti, kteří jsou schopni zodpovědět dotazy týkající se nástrojů? · Je on-line help a dokumentace adekvátní pro ony nástroje?
Rizika spojená s velikostí týmu a jeho zkušeností Pokud bude některá odpověď záporná, je potřeba učinit další vyšetření možného rizika. ·
Jsou k disposici nejlepší pracovníci?
·
Mají tito lidé potřebnou kvalifikaci a zkušenosti?
·
Je jich dostatečný počet?
·
Jsou všichni vyčleněni na celou délku projektu?
·
Nebude někdo pracovat na projektu jen na částečný úvazek?
·
Mají pracovníci odpovídající finanční očekávání?
·
Dostali pracovníci nezbytné školení?
·
Bude případný úbytek pracovníků dostatečně nízký, aby umožnil kontinuitu?
6.5
Rizikové komponenty
U.S.Air Force ve své příručce [SRA] podává návrh přístupu k identifikaci a ohodnocení rizik. Při hodnocení dopadu rizika softwarového projektu navrhují zkoumat dopad v následujících čtyřech rizikových komponentech a vyčíslit jej ve stupnici čtyř kategorií. Komponenty: · Rizika provedení - stupeň nejistoty, že produkt bude odpovídat požadavkům a bude vyhovovat zamýšlenému použití · Rizika ceny - stupeň nejistoty, že bude zachován rozpočet
59
· Rizika podpory - stupeň nejistoty, že software půjde snadno opravovat, upravovat a zlepšovat · Rizika času - stupeň nejistoty, že časový harmonogram bude dodržen a že produkt bude dodán včas
6.6
Kategorie dopadu
Dopad rizik může být různé úrovně. Rozeznáváme čtyři kategorie dopadu 1. zanedbatelný 2. marginální 3. kritický 4. katastrofický Pro snazší vyhodnocení dopadu je užitečné si připravit tabulku, ve které budou popsány jednotlivé kategorie dopadu v rámci jednotlivých komponent. Příklad tabulky pro odhad dopadu rizika. kategorie/ provedení komponenta zanedbatelné Nebezpečí malého odchýlení od požadavků na produktu. marginální
Nebezpečí odchýlení od požadavků na produkt.
podpora Nebezpečí malých nedostatků v podpoře produktu. Nebezpečí nižší podpory produktu.
60
cena Malá finanční odchylka, pravděpodobné malé překročení rozpočtu (do 10 tis. Kč) Větší finanční odchylka, pravděpodobné překročení rozpočtu (do 50 tis. Kč).
čas Možný skluz v dodání.
Termín dodání s malým časovým skluzem.
kritické
Neakceptovatelné ale opravitelné odchýlení od požadavků na produkt.
Nízká podpora produktu (např. dlouhé termíny softwarových modifikací).
katastrofické
Neakceptovatelné a neopravitelné odchýlení od požadavků na produkt.
Produkt bez možnosti podpory.
6.7
Velká finanční odchylka, pravděpodobné velké překročení rozpočtu (do 500 tis. Kč). Významná finanční odchylka, pravděpodobné velké překročení rozpočtu (nad 500 tis. Kč)
Termín dodání s větším časovým skluzem.
Termín dodání s neakceptovatelným časovým skluzem.
Ohodnocení rizik
V mnoha případech můžeme rizika ohodnotit dvěma údaji: pravděpodobností, že riziko je reálné, a jeho důsledky, jestliže nastane. [Pressman] navrhuje vytvořit tabulku rizik následujícím způsobem: 1. Do prvního sloupce tabulky se sepíší všechna rizika, která připadají pro náš projekt v úvahu. Mohou být nalezená pomocí kontrolních seznamů. 2. Ve druhém sloupci se každé riziko zařadí do kategorie (velikost softwaru, obchodní, zákaznická, technická,..) 3. V dalším sloupci se stanoví pravděpodobnost každého rizika, například průměrem z odhadů každého člena týmu. 4. Dále je odhadnut dopad rizika v kategoriích - 1-4: katastrofický, kritický, marginální, zanedbatelný. Lze použít tabulky pro odhad dopadu rizika, kde se stanoví dopad v každé rizikové komponentě, a výsledek se stanoví jako vážený průměr těchto dílčích hodnot (vahou je možné zohlednit důležitost jednotlivých komponent). 5. Tabulka rizik je potom uspořádána podle hodnoty pravděpodobnosti a dopadu. Významná rizika s velkou pravděpodobností a velkým dopadem budou na začátku tabulky, měně významná na jejím konci. 6. Oddělení dostatečně významných rizik, která bude nutné plánovat, je na rozhodnutí manažera projektu. Ten stanoví dělící čáru. Bude třeba se zabývat riziky s velkým dopadem a průměrnou nebo vysokou pravděpodobností a také s riziky s nízkým dopadem ale vysokou pravděpodobností. 7. Pro všechna rizika nad dělicí čarou se navrhnou opatření pro zmírnění, sledování a řízení rizika.
61
Příklad tabulky rizik: rizika
kategorie
pravděpodobnost
dopad
zákazník změní požadavky
zákazník
80%
2
fluktuace členů týmu
projektový 70% tým
2
nízký odhad velikosti
velikost produktu
60%
2
nedostatečné školení práce ve vývojové vývojovém prostředí prostředí
20%
3
plánovaná opatření
… Dopad: 1 - katastrofický, 2 - kritický, 3 - marginální, 4 – zanedbatelný V tomto případě byla vybrány tři významná rizika a byla oddělena čarou. Tabulka rizik je součástí plánu řízení rizik a musí být přezkoumávána a případně upravována během realizace projektu, jakmile dojde k novým skutečnostem, které mohou ovlivnit vznik nových rizik nebo změnu hodnocení rizik stávajících.
6.8
Protiriziková opatření
Pro každé významné riziko je potřeba navrhnout opaření, které, pokud by neumožnilo se mu vyhnout, by jej zmírnila, monitorovala nebo řídila.
Příklad 6.1 Zjistili jsme riziko velké fluktuace pracovníků. Podle zkušeností a intuice manažera, pravděpodobnost fluktuace je 0,7 nebo vyšší. Odhaduje
Řešení Zmírnění rizika Aby se snížilo toto riziko, je potřeba: - společně s týmem hledat příčiny fluktuace (např. špatné pracovní podmínky, nízký plat, konkurující trh práce) - ošetřit ty příčiny, které má manažer pod kontrolou, dřív než projekt začne - když projekt začne, předpokládat fluktuaci a připravit postupy k zajištění kontinuity, - zajistit komunikaci mezi pracovníky a šíření všech informací o vývoji projektu v rámci týmu - stanovit standardy pro vytváření dokumentace a zabezpečit, aby byla produkována včas - zajistit vzájemné kontroly práce tak, aby více než jedna osoba byla seznámena s každou prací - určit záložní členy týmu pro každou kritickou technologii
62
Monitorování rizika: Monitorování faktorů, které mohou ovlivnit pravděpodobnost rizika: - obecný postoj členů týmu v závislosti na tlacích v projektu - stupeň týmové soudržnosti - vzájemné osobní vztahy mezi členy týmu - potenciální platové problémy - možnosti zaměstnání uvnitř nebo mimo organizaci - Současně je potřeba kontrolovat provádění stanovených aktivit pro zmírnění případného rizika (např. včasná tvorba dokumentace) Řízení rizikových situací: Za předpokladu, že snaha o zmírnění selže a riziková situace nastane. Stane se, že některý člen týmu podá výpověď. Máme záložní pracovníky, informace jsou dokumentovány, znalosti rozšířeny v týmu. Navíc, vedoucí projektu se může dočasně zaměřit na úkoly, které jsou dostatečně zajištěny, a poskytnout novým pracovníkům čas na zapracování. Ti, co odcházejí, dostanou za úkol zaškolit nové pracovníky. Navržená opatření mohou být následujících typů: ·
Havarijní plány: Jsou to plány ošetření rizikových událostí, sestávající se z akčních kroků, která je nutno přijmout, jestliže riziková událost nastane.
·
Alternativní strategie: Rizikovým událostem lze někdy předejít změníme-li strategii řešení.
·
Rezervy: Jsou to opatření, která mají zmírnit rizika nákladů a harmonogramu. Často jsou blíže specifikována účelem, to znamená, jaká rizika mají být zmírněna (např. provozní rezerva, rezerva na nepředvídané události, časová rezerva).
·
Obstarávání: Některé činnosti mohou být méně rizikové, budou-li provedeny externí firmou, která má s nimi větší zkušenosti.
·
Pojištění: Pojistné smlouvy mohou odstranit nebo zmírnit některá rizika.
Měli bychom si uvědomit, že každé opatření stojí nějaké peníze. Proto musíme zvážit do jaké míry se příslušné kroky vyplatí. Jde o klasickou analýzu ceny a užitku. [Boehm] pracuje s pojmem projev rizika (RE – risk expression). RE je funkcí neuspokojivého výstupu (UO – unsatisfactory outcome) a vyčíslí se jako součin pravděpodobnosti a ztráty: RE = Prob(UO) x Loss(UO) Při stanovení opatření ke snížení efektu rizika se počítá výsledný účinek (RRL – risk reduction leverage) jako poměr snížení projevu rizika a ceny za toto snížení:; RRL = (REBEFORE – REAFTER)/ Risk Reduction Cost
63
6.9
Plán řízení rizik
[Pressman] navrhuje následující obsah plánu řízení rizik:
I. Úvod 1. Rozsah a účel dokumentu 2. Přehled hlavních rizik 3. Odpovědnosti a. Management b. Technický personál II. Tabulka rizik projektu 1. Popis všech rizik nad dělicí čárou 2. Faktory ovlivňující pravděpodobnost a dopad III. Opatření na zmírnění, monitorování a řízení rizik n-té riziko a. Zmírnění i. Obecná strategie ii. Specifické kroky k zmírnění rizika b. Monitorování i. Faktory, které mají být monitorovány ii. Způsob monitorování c. Řízení i. Plán pro případ, že nastane riziková situace ii. Speciální zřetel IV.
Harmonogram iterací plánu řízení rizik
V.
Závěr
Uvedená metoda analýzy a řízení rizik není jediná. Existují i jiné modely. V mnoha případech není možné nebo ne vždy se spokojíme s vyčíslením rizika za pomoci odhadu jeho pravděpodobnosti. Zvláště u finančních rizik je potřeba pracovat s přesnějšími modely.
64
6.10
Softwarový rizikový management podle [Boehma]
Ohodnocení rizika (Risk Assesment) Identifikace rizika ·
kontrolní seznamy (checklists) – zachycuje předchozí zkušenost a slouží jako vodítko k úplné a systematické kontrole.
·
analýza faktorů rozhodování (decision driven analysis) – Jaké jsou zdroje rozhodování o systému. Pokud jde o jiné než technické nebo manažerské faktory, může to způsobit rizika (např. politicky řízené rozhodování, marketinkově řízené, protiklad rozhodování podle krátkodobého versus dlouhodobého horizontu)
·
analýza předpokladů (assumption analysis) – Jaké jsou třeba i skryté předpoklady, nejsou příliš optimistické.
·
dekomposice – na úrovni vyššího stupně abstrakce může být řada problémů s detaily skryta. (lze použít Paretův princip: 80% přispění pochází od 20% přispěvovatelů, nebo diagram PERT k nalezení závislostí mezi úkoly)
Analýza rizika (využívání modelů z předchozí zkušenosti) ·
výkonové modely (performance models)
·
cenové modely (cost models)
·
síťová analýza
·
rozhodovací analýza
·
analýza jakostních faktorů (quality factor analysis)
Stanovení priorit pro rizika (Risk prioritization) ·
projev rizika (risk exposure)
·
efekt rizika (risk leverage)
·
složené snížení rizika (compound risk reduction)
Řízení rizika (Risk control) Plánování rizikového managementu ·
získání informací (buing information)
·
vyhnutí se riziku (risk avoidance)
·
odsunutí rizika (risk transfer)
·
snížení rizika (risk reduction)
·
plánování jednotlivých rizik
·
integrace plánu rizik
65
Rozpoznání rizik (risk resolution) ·
prototypování
·
simulace
·
benchmarking
·
analýzy
·
staffing
Monitorování rizika ·
sledování milníků
·
sledování TOP-10
·
přezkoumání rizik
·
opravné akce
Závěr
Shrňme si na závěr některé myšlenky řízení rizik: o Řízení rizik se vyplatí, pokud nám neřízená rizika mohou způsobit větší škody než je práce vynaložená na jejich řízení. o Někdy je užitečné jenom to, že si rizika uvědomíme a pojmenujeme. o Pokud se stane, že jsme nějaké riziko nezvládly, že jsme získali užitečné zkušenosti nebo jsme nasbírali zajímavé informace, postaráme se o to, abychom je využili v příštím projektu.
66
7
Kvalita softwaru
Můj dědeček měl třicet let starý oblek, který mi někdy s hrdostí ukazoval a říkával, že je ušitý z kvalitní anglické látky. Můj syn prý zase někdy stahuje z internetu kvalitní muziku a manželce se zalíbila nabídka jakési cestovní kanceláře, která údajně poskytuje kvalitní služby. Slovo kvalita, kvalitní používáme často a někdy ani přesně nechápeme, co vlastně znamená. Možná, že bychom měli problémy s vymezením toho, co kvalitní výrobek je, ale tušíme, co kvalitní výrobek není. Asi by v nás neměl vyvolávat negativní pocity. Rozhodně by neměl být vadný. Přepokládáme, že kvalitní výrobek bude splňovat naše očekávání, dokonce i ta, která si zatím neuvědomujeme. Je tedy kvalita subjektivní vlastnost, nebo ji lze objektivně definovat?
7.1
Základní pojmy
Norma ISO/DIS 9000:2000 definuje jakost, kvalitu (pozn. oba termíny jsou chápány jako synonyma a my je budeme také tak používat): Schopnost souboru inherentních znaků výrobku, systému nebo procesu plnit požadavky zákazníků a jiných zainteresovaných stran. Inherentním znakem výrobku je nějaká rozlišující vlastnost, která je pevně svázána s výrobkem. Může to být fyzikální vlastnost (např. pevnost, pružnost, odolnost vůči atmosférickým poruchám), funkčnost, smyslová vlastnost (barva, chuť, zvuk…), bezporuchovost a podobně. Není to ovšem cena výrobku, která se může změnit, a nemá tudíž s kvalitou nic společného. Výrobkem nebo produktem rozumí norma čtyři základní kategorie: hardware, software, služby a zpracované materiály. Požadavky jsou potřeby nebo očekávání, které se předpokládají nebo jsou závazné. Závazné požadavky na software jsou dány jeho specifikací. Kromě toho ale předpokládáme, že bude výsledný software stabilní, nebude kolidovat s ostatními programy nebo dokonce je ohrožovat. To jsou implicitní požadavky, které zákazník mlčky předpokládá, aniž by je specifikoval v nějakém závazném dokumentu, ale bez jejich splnění nepovažuje výsledný produkt za kvalitní. Konečně výrobek by měl splňovat požadavky zainteresovaných stran. To jsou kromě zákazníků všichni, kteří mají zájem na výkonnosti a úspěchu organizace. Tedy vlastníci, zaměstnanci, dodavatelé, sponzoři, partneři a další. Jiná definice jakosti softwaru [Pressman] říká: Je to shoda s explicitně stanovenými požadavky na funkci a chování, explicitně dokumentovanými vývojovými standardy a implicitními charakteristikami, které se očekávají od každého profesionálně vyvinutého softwaru.
67
Tomu už rozumíme, možná až na vývojové standardy, o kterých jsme se ještě nezmínili. Jedná se o to, že kvalitní produkt musí být vytvořen kvalitním procesem. To platí, jak si ukážeme dále, pro software dvojnásob. Bez kvalitního vývoje si nemůžeme být jisti kvalitou výsledku. Kvalitu nemůžeme kontrolovat až potom, co byl vytvořen programový kód. Kvalitou se musíme zabývat během celého vývoje softwaru. Terminologie a přístup k managementu jakosti se u různých autorů může lišit. Držme se normy ISO/DIS 9000:2000, která říká, že management jakosti jsou koordinované činnosti pro nasměrování a řízení organizace s ohledem na jakost. Obvykle zahrnuje 1) stanovení politiky jakosti a cílů jakosti 2) plánování jakosti 3) řízení jakosti 4) zabezpečování jakosti 5) zlepšování jakosti. Z hlediska řízení projektu se managementu jakosti týkají hlavně body 2)-4), které najdeme popsané i v americké normě pro projektové řízení [PMBOK]. Plánování jakosti spočívá ve stanovení cílů jakosti a specifikování procesů pro splnění těchto cílů. Výsledkem této činnosti je plán řízení jakosti. Řízení jakosti je zaměřené na splnění požadavků na jakost. Spočívá ve sledování konkrétních výsledků projektu a posuzování, zda odpovídají standardům a stanoveným požadavkům. Pokud neodpovídají, navrhují se způsoby odstraňování příčin nevyhovujícího plnění. Zabezpečování jakosti je zaměřené na poskytování důvěry, že jsou splněny požadavky na jakost. Je tedy zaměřeno na to, aby zákazník, vedení prováděcí organizace, případně další strany nabyly důvěry v kvalitu procesu a produktu (je to vlastně ujištění zákazníka nebo třetí strany o kvalitě). Činnosti pro zabezpečování jakosti mohou být prováděny i externě, třeba formou externího auditu.
7.2
Zabezpečení jakosti kvality
Ve starším pojetí byl proces zabezpečení jakosti nadřazen a zahrnoval i činnosti plánování a řízení jakosti. S tímto přístupen se setkáme v řadě softwarových knih. Podle [Pressman], jednou ze zastřešujících aktivit procesu vývoje softwaru je zabezpečování jakosti softwaru (SQA – Software Quality Assurance), která zahrnuje ·
cíle managementu jakosti
·
efektivní technologie (metody a nástroje)
·
formální revize, přezkoumání
·
strategii testování
·
řízení softwarové dokumentace a jejích změn
·
zajištění shody se standardy
·
měření a vykazování
68
Podle [Paulk 93] spolupracuje na vývoji softwaru nezávislá skupina pro SQA, která provádí následující aktivity: Příprava plánu řízení jakosti pro projekt. Plán je vytvořen během plánování jakosti. Aktivity SQA jsou pak vedeny podle tohoto plánu. Plán stanoví: ·
prováděná vyhodnocování
·
prováděné audity a přezkoumání
·
standardy, které se mají použít v projektu
·
procedury pro evidenci a sledování chyb
·
dokumenty, které budou vytvářeny skupinou SQA
·
zpětnou vazbu poskytovanou projektovému týmu.
Účast při vývoji popisu procesu softwarového projektu. Skupina SQA přezkoumá popis procesu vzhledem ke shodě s politikou organizace a externími normami (např. ISO) a ostatními částmi plánu projektu. Přezkoumání analýzy a návrhu softwaru a verifikace vzhledem k definovanému softwarovému procesu. Skupina SQA identifikuje, dokumentuje a sleduje odchylky a verifikuje prováděné opravy. Audity stanovených softwarových produktů, verifikace vzhledem k specifikacím. Skupina SQA identifikuje, dokumentuje a sleduje odchylky a verifikuje prováděné opravy, periodicky podává zprávy vedení projektu. Zajištění, aby odchylky v softwarové práci a produktech byly dokumentovány a ošetřeny podle dokumentovaných procedur. Zaznamenání všech neshod a vykazování managementu. Navíc má skupina SQA koordinovat řízení změn a pomáhat při sběru a analýze softwarových metrik.
7.3
Techniky řízení jakosti softwaru
Přezkoumání, revize, testování, oponentura, inspekce, audit jsou různé typy kontroly. Jejich výklad se u různých autorů mnohdy liší, a to také v závislosti na rozdílném překladu z angličtiny. Přezkoumání (nebo také revize, v angličtině review) je podle definice normy ISO činnost prováděná k zajištění vhodnosti, přiměřenosti, efektivnosti a účinnosti předmětu s cílem dosáhnout stanovených cílů. [Humphrey]rozlišuje tři základní metody přezkoumání: · inspekci · procházení (walk-throughs) · osobní přezkoumání
69
Inspekce je formální metoda týmového přezkoumání podle přísných pravidel. [Fagan] popsal inspekci softwaru s pevnou strukturou a pravidly. Skládá se ze tří fází: 1. příprava 2. vlastní inspekce 3. zpráva Příprava začíná krátkou schůzkou, kde se jsou účastníci inspekce seznámeni s problematikou tak, aby byl všem jasný produkt a jejich role během inspekce. Potom následuje individuální studium podkladů a odkrývání problémů a otázek. Vlastní inspekce je setkání inspekčního týmu s realizátory, kde se probírají nalezené problémy a vyjasňují případné otázky. V poslední fázi se specifikují nalezené defekty a píše se zpráva z inspekce. Procházení (walk-through) podle Humphreye je méně formální metoda, která může spočívat v prezentaci pro spolupracovníky, případně pro uživatele. Realizátor prochází programem (nebo jeho návrhem) a vysvětluje posluchačům, jak program řeší jednotlivé situace. Cílem je objevit případná nedorozumění a nedostatky. Osobní přezkoumání je aktivita, kterou provádí sám tvůrce. Autor by si měl projít analytický model, návrh softwaru nebo napsaný program předtím, než bude implementován, přeložen nebo testován. Měl by se snažit objevit, co nejvíc chyb dřív, než bude předložen k inspekci. Spoléhat na testování hotového programu se nevyplácí. Ideálnem je napsat program, který nebude mít žádnou chybu. Tím, že budeme jednotlivé vývojové fáze procházet a upravovat, aby byly průhledné a srozumitelné, vyhneme se celé řadě logických chyb. Pokud bude náš produkt srozumitelný a bude mít jasnou strukturu, usnadníme práci sobě i inspekčnímu týmu. Můžeme to srovnat s literární činností. Jen málo z knih, které se zdají být napsány lehce, byly takto napsány hned napoprvé. Obvykle se výsledný tvar rodí pomalu po mnohém přepisování. Domnění, že přezkoumáváním programového kódu ztrácíme čas, je mylné. Ušetříme si často mnohem delší dobu, kterou bychom strávili laděním špatně napsaného programu. Vyplatí se, když i do osobního přezkoumání vneseme řád. Tím může být předem připravený postup třeba ve formě kontrolního seznamu, který nás povede. Pressman používá pro inspekci termín formální technická revize (FTR – Formal Technical Review). Jejím cílem je ·
odkrýt chyby ve funkci, v logice, v implementaci
·
ověřit, že software vyhovuje požadavkům
·
ujistit se, že software je reprezentován podle definovaných standardů
·
zajistit, aby software byl vyvinut jednotným způsobem
·
docílit, aby projekt byl lépe řiditelný.
FTR má být prováděna v týmu o třech až pěti pracovnících. Vlastní revizní jednání by neměla být delší než dvě hodiny, pak přestává mít požadovaný efekt. Pokud jde o rozsáhlý produkt, je třeba jej rozdělit podle jeho struktury na menší části, které budou přezkoumávány samostatně. FTR může probíhat i v několika fázích. Každou FTR musí někdo vést a každé jednání musí někdo zapisovat. Mělo by se postupovat podle předem známého programu. Je třeba si
70
uvědomit, že účelem FTR není kritizovat autory, ale nalézt chyby. Problémy je třeba pojmenovat, nikoli je v rámci FTR řešit (na to není čas a ani to není účelem revize). Závěr FTR musí jednoznačně rozhodnout, zda 1. akceptovat produkt bez modifikací, nebo 2. odmítnout produkt kvůli závažným chybám (budou-li opraveny má se uskutečnit nová revize) 3. předběžně akceptovat s tím, že menší chyby budou opraveny (nová revize nebude prováděna).
Opravdu účinné techniky jsou takové, které postupují podle předem daných pravidel. Avšak i méně formální techniky mají své místo. Mohou to být i pravidelná „posezení u kávy“ s kolegy, na kterých si vzájemně vyjasňujeme problémy. Testování je prověřování funkčnosti produktu. U programu to znamená jeho spuštění za účelem nalezení chyb. Pokud testování chyby neobjeví, neznamená to, že v programu žádné chyby nejsou. Znamená to jenom, že jsme neprovedli správný test. Simulace jsou ruční nebo poloautomatické procházení částí programu se symbolickým prováděním výpočtu. Formální důkaz správnosti je metoda, která má formou matematického důkazu ověřit, že je program správný. Evaluace je celkové zhodnocení rozsáhlých materiálů, provádí se technikou přezkoumání nebo inspekce. Může jít například o oponenturu požadavků (studie proveditelnosti, anglicky feasibility study). Zjištění, zda jsou požadavky úplné, bezesporné, ve shodě s cíly projektu. Verifikace je ověření, zda výstupy etapy splňují požadavky vstupních dokumentů (shoda cíle a specifikací, návrhu a specifikací, kódu a návrhu a specifikací). Provádí se technikou přezkoumání, inspekce, procházení nebo čtení kódu. Dále se sleduje dodržování termínů, rozpočtu, know-how, norem a standardů. Validace je předvedení a praktické ověření správné činnosti technikou testování. Audit je prověření dodržování a stavu plnění úkolů nezávislou skupinou. Některou specifickou oblast (jako např. účetní audit, audit kvality podle normy ISO 9000) může prověřovat jen akreditovaná organizace.
7.4
Cena za jakost
Každá inspekce a každý test něco stojí. Každý další test může odkrýt další chyby a přispět tak ke zvýšení kvality produktu. Kdy to skončit? Kdy budeme s dosaženou kvalitou spokojeni? Jak vysokou cenu za kvalitu máme investovat? Pochopitelně se budeme snažit za minimální náklady dosáhnout maximální kvality.
71
Následující odstavec by vás měl přesvědčit, že je vždy výhodnější vynaložit náklady na kvalitu na začátku procesu než na jejím konci. Jestliže začneme s prověřováním kvality již v definici požadavků, během analýzy a návrhu, bude méně chyb v konečném produktu. Přitom oprava chyby na začátku procesu je mnohonásobně levnější než oprava chyby hotového produktu u zákazníka. Náklady na kvalitu můžeme dělit na náklady vynaložené na prevenci, na prověření a na odstranění chyb. Do prevence patří plánování jakosti, školení týmu a také třeba pořízení nástrojů na testování. Náklady na prověřování zahrnují cenu za přezkoumání, inspekce a testování. Náklady na odstranění chyby se liší, byla-li chyba objevena před dodáním zákazníkovi (vnitřní chyba) nebo po dodání (vnější chyba). Ukazuje se, že náklady dramaticky rostou od prevence defektů k jejich detekci, od odstraňování vnitřních chyb k odstraňování chyb vnějších.
Bylo publikováno několik srovnání, pokud jde o relativní dobu resp. cenu za identifikaci nebo opravu chyby v různých fázích vývoje softwaru: ·
[Boehm] dospěl v rámci svého výzkumu k následujícímu porovnání relativních dob pro identifikace chyb: během stanovení požadavků 1, během návrhu 3-6, během kódování 10, při vývojovém testu 15-40, při akceptačním testu 30-70, během provozu 40-1000.
·
[Remus] dle výsledků výzkumu firmy IBM je relativní doba pro identifikaci chyb: během revize návrhu 1, během inspekce kódu 20, během testu 82.
·
[Humphrey] podle nepublikovaných pravidel IBM je relativní cena za identifikaci chyb: během návrhu 1,5, před kódováním 1, během kódování 1,5, před testováním 10, během testování 60, v provozu 100.
·
[Bush] uvedl průměrnou cenu za chybu: $90-120 během inspekce, $10000 během testování.
·
[Freedman a Weinberg] tvrdí, že projekt, který používá revize a inspekce dosáhl desateronásobného snížení chyb objevených při testování a 50-80% snížení ceny za testování, včetně ceny za revize a inspekce.
Je pochopitelné, že cena za opravu defektu u zákazníka je tím větší, čím víc zákazníků produkt používá. Taková cena zahrnuje náklady za vyřízení reklamace, za vrácení produktu, jeho opravy a poskytnutí náhrady. Ztráta důvěry ve firmu následkem takové reklamace je cena, kterou lze jen těžko vyčíslit. V IBM je používán model zesilování defektů k ilustraci generování a detekci chyb během vývoje softwaru. Budeme si tento model ilustrovat v následující tabulce na hypotetickém příkladu. Myšlenka, na které je postaven tento model, říká, že v každém kroku vývoje softwaru můžeme a obvykle uděláme nějaké chyby. Jestliže je neobjevíme, přenáší se do dalšího kroku, kde buďto přetrvávají beze změny, nebo v častějším případě jsou zdrojem následných chyb – zesilují se.
72
Vývojový krok spec. požadavků návrh kódování a jednotkový test integrační test validační test systémový test
chyby, které počet chyb z předchozího se nemění kroku 0 0
chyby, které se zesilují 0
nově generované chyby 10
procentuální účinnost detekce chyb 0%
10 37
6 10
4x1,5 27x3
25 25
0% 20%
93 47 24
93 47 24
0 0 0
0 0 0
50% 50% 50%
Vidíme, že na konci procesu, po systémovém testování zbylo ještě 12 chyb. Podívejme se, jak by vypadaly náklady za odstranění chyb: nalezené chyby jednotkový test integrační test systémový test po dodání
počet 24 46 23 12
cenová jednotka 10 15 30 60 celkem
celkem 240 690 690 720 2340
Všimněme si, že v prvních dvou krocích jsme neobjevili žádnou chybu. Podívejme se, jak bychom dopadli, kdybychom v těchto krocích prováděli účinné přezkoumání. Vývojový krok spec. požadavků návrh kódování a jednotkový test integrační test validační test systémový test
počet chyb chyby, které z předchozího se nemění kroku 0 0
chyby, které se zesilují 0
nově generované chyby 10
procentuální účinnost detekce chyb 70%
3 15
2 5
1x1,5 10x3
25 25
50% 20%
48 24 12
48 24 12
0 0 0
0 0 0
50% 50% 50%
V tomto případě je počet chyb, které jsme neobjevili poloviční, a cena také téměř poloviční.
73
nalezené chyby spec. požadavků návrh jednotkový test integrační test systémový test po dodání
7.5
počet 7 14 12 24 12 6
cenová jednotka 1 3 10 15 30 60 celkem
celkem 7 42 120 360 360 360 1249
Statistické přístupy k jakosti softwaru
Tak jako jinde i zde platí, že pokud se chceme zlepšovat, musíme své procesy měřit, naměřené hodnoty uchovávat, abychom měli porovnání a věděli, jestli se zlepšujeme nebo zhoršujeme, a abychom se z minulých chyb uměli poučit. Statistický přístup k jakosti softwaru se sestává z následujících kroků: 1. Sběr a kategorizace informací o softwarových defektech 2. Nalezení příčiny pro každý defekt (např. neshoda specifikací, chyba návrhu, porušení standardů, špatná komunikace se zákazníkem) 3. Identifikace závažných příčin. Paretův princip říká, že velkou část následků způsobuje jen malé procento příčin (Uvádí se typický poměr 80:20, který znamená, že zdrojem 80% všech chyb je jen 20% možných příčin). 4. Ošetření problémů, které způsobují závažné příčiny.
Příklad 7.1 Pro ilustraci si uveďme jednoduchý příklad. Dejme tomu, že máme malou firmu a že jsme si po určitou dobu (řekněme jeden rok) zaznamenávali počty chyb a jejich příčiny. Chyby jsme rozdělili podle závažnosti do tří skupin. Příčina Vážné Střední Malé Celkem 1 neúplné nebo chybné specifikace 45 68 103 216 2 nedorozumění v komunikaci se zákazníkem 11 72 76 159 3 odchylka od specifikací 1 24 23 48 4 chyba v datových representacích 32 68 36 136 5 chyba v logice návrhu 10 14 21 45 6 neúplné nebo chybné testování 20 25 28 73 7 nepřesná nebo neúplná dokumentace 2 20 14 36 8 chyba v převodu návrhu do programovacího jazyka 15 19 26 60 9 nejednoznačné nebo nekonsistentní uživatelské rozhraní 3 17 8 28 10 ostatní 0 15 41 56 součet
139
74
342
376
857
Po roce jsme zjistily, že 60% všech chyb bylo způsobeno příčinami, které jsou uvedeny v řádcích 1, 2, 4. Pokud bychom vzali v úvahu jen závažné chyby, budou hlavní příčiny 1, 4 a 6 (70% chyb). Jaké poučení si z toho vezmeme? Zdá se, že se budeme muset zaměřit na kvalitu tvorby specifikací a zlepšit komunikaci se zákazníky. Pokud jde o chyby v datových reprezentacích je možné uvažovat o nákupu CASE pro modelování dat. Podobně, abychom zlepšili kvalitu testování, měli bychom uvažovat o koupi vhodného nástroje.
7.6
Diagram příčin a následků
Klasickým prostředkem pro vizualizaci a analýzu příčin a následků je Ishikawův diagram. Je nazván je podle japonského odborníka na zabezpečování jakosti prof. Kaoru Ishikawa. Jiný název je fishbone (rybí kost) diagram. Tak jak se vyhledávají příčinné jevy, které brání hladkému průběhu procesu, zakreslují se do diagramu. Přitom je možné znázornit jejich strukturální rozklad. Na následujícím obrázku je příklad rozkladu příčin, které vedou k chybě specifikací:
ne úp
ln
é
ko ch m yb un ná ika ce špatné informace od zákazníka
7.7
je d
no
zn
ač
né
chybné specifikace
né áv r sp ne
é ěn n ě zm
ý r al sta z a d ro j c í z a or m in f
ne
Chybový index
Chybový index (EI error index) je softwarová metrika popsaná v [SES94]. Jestliže označíme: Ei celkový počet chyb objevených v i-tém kroku procesu, z toho Vi počet vážných chyb Si počet středních chyb Mi počet malých chyb PS velikost produktu (v počtu LOC, řádek návrhu, stran dokumentace) v i-tém kroku wv, ws, wm váhový faktor (doporučené hodnoty jsou 10, 3, 1)
75
Potom v každém kroku spočítáme fázový index, jako PIi = wv(Vi/ Ei) + ws (Si / Ei)+ wm (Mi / Ei) Chybový index bude souhrnným výsledkem efektu fázového indexu v každém kroku, s vahou, která vyjadřuje, že chyby nalezené později mají závažnější důsledky, než chyby objevené v dřívějších krocích: EI = suma (i x PIi)/PS Chybový index je metrika sloužící k indikaci zlepšování jakosti softwaru.
7.8
Spolehlivost softwaru
Spolehlivost je jistě důležitým znakem kvality softwaru. [Musa] definuje spolehlivost softwaru jako „pravděpodobnost bezporuchového fungování programu v daném prostředí a daném čase“. Poruchou (failure) programu se rozumí neshoda s jeho požadovanými specifikacemi. Na rozdíl od hardwaru, kde porucha zařízení může vzniknout v průběhu času jeho opotřebením, u softwaru vznikají příčiny budoucích poruch chybami při jeho vývoji. Jde o odlišný přístup k pojmu spolehlivost, a proto metody měření spolehlivosti, které se používají pro hardware, v oblasti softwaru nelze použít.
Střední doba mezi poruchami Střední doba mezi poruchami je metrika pro měření spolehlivosti softwaru. Je součtem střední doby do poruchy a doby k jejímu odstranění: MTBF = MTTF + MTTR kde MTBT MTTF MTTR
střední doba mezi poruchami (mean time between failure) střední doby do poruchy (mean time to failure) střední doba opravy (mean time to repaire)
Ukazuje se, že tato metrika je k měření spolehlivosti z pohledu uživatele vhodnější, než například součet všech chyb na jednotku programu (počet defektů/KLOC). Chyby mohou být různé, některé se projeví už v prvním měsíci používání, ale jiné mohou přetrvávat roky. Pokud odstraníme ty druhé, nebude to mít takový dopad na spolehlivost z pohledu uživatele jako, když se nám podaří odstranit chyby v nejčastěji používaných částech programu.
Použitelnost Další metrikou je použitelnost software (availability). Je to pravděpodobnost, že program bude pracovat podle požadovaných specifikací v daném čase: A = MTTF/(MTTF+MTTR) x 100%
76
7.9
Benchmarking
Benchmarking je technika pro sledování procesu a porovnávání jej s podobnými procesy, prováděnými jinými jedinci, skupinami nebo organizacemi. Cílem je najít náměty pro zlepšování, stanovit standard pro porovnání výkonů. Podmínkou je, aby procesy byly měřitelné metrikami nezávislými na procesu ale odrážejícími jeho schopnosti a robustnost. Postup benchmarkingu by měl splňovat určité předpoklady [Humphrey]: ·
Měřit schopnost procesu produkovat vysoce kvalitní produkt.
·
Poskytovat jasné uspořádání vlastností procesu od nejlepšího k nejhoršímu.
·
Indikovat schopnost procesu odolat krizovým situacím.
·
Poskytovat požadovaná data objektivně měřitelná.
·
Poskytovat data včas.
Problémem softwarového procesu je stanovení vhodných metrik pro tento účel. Abychom mohli proces hodnotit, musíme statisticky vyhodnotit prováděná měření většího počtu programů, vytvořených tímto procesem.
7.10
Normy ISO
Tuto kapitolu jsme začali definicí jakosti podle normy ISO/DIS 9000:2000. V tomto odstavci si o této a dalších normách souboru ISO 9000 řekneme něco víc. Tyto normy byly vypracovány na pomoc organizacím všech typů při provozování efektivních systémů jakosti. Normy jsou vytvářeny a pravidelně aktualizovány Mezinárodní organizací pro normalizaci (ISO). První byly vydány v roce 1987. Byly postupně doplňovány a roce 1994 revidovány. Poslední vydání, ze kterého zde citujeme, je z roku 2000. Organizace si mohou dát certifikovat své systémy managementu jakosti podle souboru norem ISO 9000 u akreditovaných společností. U nás je to Česká společnost pro jakost. Tato certifikace představuje pro klienty firmy záruku jakosti a pro firmu samozřejmě konkurenční výhodu. ·
Norma ISO 9000 popisuje zásady systémů managementu jakosti a specifikuje příslušnou terminologii.
·
Norma ISO 9001 specifikuje požadavky na systémy managementu jakosti, které se používají k prokázání způsobilosti organizace, a tedy k udělení příslušného certifikátu.
·
Norma ISO 9004 poskytuje návod na systémy managementu jakosti, včetně procesů pro neustálé zlepšování. Je to tedy návod, jak splnit požadavky specifikované v normě ISO 9001.
·
Norma ISO 19011 poskytuje návod pro řízení a provádění auditů životního prostředí a auditů jakosti.
Všechny čtyři normy společně tvoří související soubor norem.
77
Poslední vydání norem ISO/DIS 9000:2000 je postaveno na osmi zásadách managementu jakosti: 1. Zaměření na zákazníka – je třeba porozumět potřebám zákazníka, plnit jeho požadavky a snažit se překonat jeho očekávání. 2. Vedení – úloha vedoucích pracovníků 3. Zapojení pracovníků – plné zapojení všech pracovníků a využití jejich schopností. 4. Procesní přístup – procesní řízení zdrojů a činností vede k účinnějšímu dosažení požadovaného výsledku 5. Systémový přístup k managementu 6. Neustálé zlepšování 7. Přístup k rozhodování na základě faktů 8. Vzájemně výhodné dodavatelské vztahy
Závěr Závěrem si shrňme nejdůležitější poznatky: ·
kvalitu produktu nemůžeme pouze kontrolovat na konci výrobního procesu, musíme ji řídit po celou dobu procesu
·
řízení kvality softwaru je levnější a účinnější, čím dříve v procesu vývoje začneme provádět účinné kontroly a přezkoumání
·
kvalitní produkt vytvoříme jenom kvalitním procesem
·
řídit kvalitu procesu můžeme jen tehdy, pokud jej budeme měřit
·
máme-li zlepšovat proces, musíme hledat příčiny minulých chyb a poučit se z nich
·
normy nám pomáhají využívat zkušeností a vyzkoušených praktik úspěšných organizací.
78
8
Techniky testování
Cílem testování je objevit chyby v softwaru a ne ukázat, že v něm chyby nejsou. Testování softwaru tedy v žádném případě nemůže dokázat, že software je správný, že splňuje zadání. Důvodem je složitost programu, velké množství různých průchodů programem a velké množství argumentů funkcí. Jediné, co můžeme od testování očekávat, je nalezení exitujících chyb. Jestliže test najde jen velmi málo chyb, neznamená to, že software je správný. Pravděpodobně je chybné testování (alespoň pro většinu softwarových produktů to platí). Na rozdíl od programování je testování chápáno jako destruktivní činnost. Má zničit software, objevit jeho chyby.
Mýtus praví, že ten, kdo je skutečně dobrý programátor nedělá chyby, když se soustředí na práci, když používá strukturované programování, návrh shora dolů atd.
Mýtus říká, že děláme chyby, protože nejsme dobří, a proto se máme cítit vinni. Testování je přiznáním viny. Když připustíme, že žádná lidská činnost není perfektní a chybování je přirozenou součástí lidské aktivity, pak testování není destruktivní. Je to jedna z důležitých technik zabezpečení kvality výsledného produktu. Testování softwaru se objevuje v různých etapách životního cyklu systému a v několika úrovních. Tyto etapy se často označují jako úroveň modulu, úroveň jednotky nebo úroveň systému v závislosti na velikosti části, která je testována. Existuje několik pohledů na testování SW. Pro SW, který je napsán v procedurálních jazycích jako je C, Ada, Pascal nebo Fortran, je základní jednotkou funkce (procedura, podprogram v závislosti na terminologii jazyka).
79
Pro procedurální jazyky existuje přirozená hierarchie testovaných částí: modul jednotka podsystém systém Upřednostňovaný přístup k testování je začít testováním programů na úrovni modulu, ty jsou pak sestavovány do větších celků až na úroveň celého systému. Situace testování je zcela odlišná při objektovém programování, kdy SW je napsaný v programovacích jazycích jako je C++, Java, Smalltalk nebo Eiffel. Paradigma objektového programování předpokládá, že program sestává z množiny nezávislých objektů, které spolu komunikují a spolupracují prostřednictvím předávání zpráv. Hierarchie testovaných částí pro objektově orientované programovací jazyky: třída interakce mezi třídami subsystém systém Protože však základy testování jsou v obou případech stejné, nebudeme při popisu testování mezi těmito dvěma přístupy rozlišovat.
8.1
Charakteristika testování
Testování je proces spouštění programu za účelem nalezení chyb. Dobrá testovací data jsou taková, která s velkou pravděpodobností objeví dosud neobjevené chyby. Úspěšný test je takový, který objevil dosud neobjevené chyby. Cílem je tedy navrhnout test, který systematicky odkryje různé třídy chyb s minimálním úsilím a časem může ukázat, že pro určitá data program vyhovuje požadovaným specifikacím Test je indikací spolehlivosti a kvality softwaru. Testování ale nemůže dokázat absenci chyb, může jen dokázat jejich přítomnost.
8.2
Principy testování
Základní principy testování můžeme shrnout do následujících několika bodů: Testy by se měly vztahovat k požadavkům zákazníka (většina defektů z pohledu zákazníka se projeví neshodou s požadavky). Testy by měly být plánovány v předstihu (plánovat je jakmile jsou specifikovány požadavky, navrhnout data, jakmile je proveden návrh programu.)
80
Princip Pareto (pravidlo 80:20): většina všech neobjevených chyb má původ v několika málo modulech. Problémem je ty moduly nalézt. Testování by mělo začít testováním “v malém” a pokračovat testování “ve velkém”. (Začít testováním modulů, pak integrovaných skupin (clusterů) modulů a nakonec celého systému) Úplné otestování není možné (nelze otestovat počet všech kombinací cest programem) Testování by mělo být vedeno nezávislou třetí stranou (jiný úhel pohledu, snaha nalézt chybu, ne dokázat, že tam není)
8.3
Testovatelnost
Výčet vlastností vedoucích k dobré testovatelnosti: Spustitelnost (operability) - čím lépe modul pracuje, tím účinněji může být otestován - chyby nebrání běhu programu, může být testován a vyvíjen současně. Přehlednost (observability) - testuješ, co vidíš - různé výstupy pro různé vstupy, stavy systému a proměnné jsou viditelné během chodu, faktory ovlivňující výstup jsou viditelné, nesprávné výstupy jsou lehce identifikovatelné, vnitřní chyby jsou automaticky detekovány a zaznamenávány, je dostupný zdrojový kód . Kontrolovatelnost (controllability) - čím lépe lze software kontrolovat/řídit, tím spíše lze testování automatizovat a optimalizovat - všechny možné výstupy jsou generovány nějakou kombinací vstupů, veškerý kód je spustitelný nějakou kombinací vstupů, vstupní a výstupní formát je konsistentní a Dekomponovatelnost - kontrolováním rozsahu testování můžeme rychleji oddělit problémy a provést následné testy. Jednoduchost - čím méně máme testovat, tím rychleji to můžeme provést - jednoduchost funkce, struktury, kódu Stabilita - čím méně změn softwaru, tím lépe - nejsou časté, jsou řízené, neovlivní provedené testy. Srozumitelnost - čím víc máme informací, tím budou testy chytřejší - srozumitelný návrh, srozumitelné závislosti mezi vnitřními, vnějšími a sdílenými komponentami, dostupnost a srozumitelnost technické dokumentace. Vlastnosti dobrého testu: ·
s velkou pravděpodobností objeví chybu. Měl by hledat chybu tam, kde může být,
·
není redundantní Na testování je málo času, proto má mít každý test mít jiný účel,
·
měl by objevit celou třídu chyb ,
·
neměl by být ani moc jednoduchý ani moc složitý.
Testy by se měly spouštět nezávisle, aby jejich případné vedlejší efekty nepřekryly chyby.
81
8.4
Black-box testování
Testování, které označujeme jako testování černé skříňky, je testování správného provádění funkcí systému. V následující tabulce jsou uvedeny vstupy, které by měly být zahrnuty v testovacích datech při tomto typu testování. 1.
Testovaný modul
2.
Soubor specifikací výstupu pro specifický vstup.
3.
Soubor případů, které indikují, že modul je správný. Tento soubor testů obvykle sestavuje tester.
4.
Metoda porovnání skutečných výsledků s výsledky předpokládanými pro daný vstup.
5.
Metoda ukládání výsledků testu pro budoucí možnou analýzu.
6.
Soubor softwarových nástrojů pro automatizaci testování.
Ne vždy je možné všechny potřebné vstupu pro testování zajistit. V těchto případech je nutné zvážit, zda výsledky testů mají nějakou vypovídací hodnotu a zda jsme opravdu příslušný modul otestovali. V následující tabulce jsou uvedeny příklady testovacích vstupů pro různé argumenty modulu. Typ argumentu
Testované případy
Logická hodnota
True, False
Celé číslo
Min_int, -1, 0, 1, Max_int
Kladné celé číslo
1, Max_int
Nezáporné celé číslo
0, 1, Max_int
Necelé číslo
Min_float, -1.0, 0.0, 1.0, Max_float
Dvojnásobná přesnost
Min_double, -1.0, 0.0, 1.0, Max_double
Znak
Tištitelný, prázdný, specielní
Index pole
Min index, Max index
Pole
Libovolný index
Ukazatel
Normální, prázdný
Strukturované pole
Jeden nebo více testů pro každé pole struktury, v závislosti na typu
Řetězec znaků
Prázdný, délky 2, maximální délka
82
Black-box testování si ukážeme na následujícím jednoduchém příkladu.
Příklad 8.1 Následující program má spočítat faktoriál nezáporného čísla, jehož hodnota vstupuje jako parametr. Int fact (int n) { if (n < 0) { printf („chyba – zaporne int\n“ ); return (-1); } else if (n = 0) return 1; /* 0! Je definovan jako 1 */ else return (n * fact (n – 1)) } Na první pohled v uvedeném programu vidíme chybu, protože v podmínce if je uveden chybně příkaz přiřazení ( n = 0 ) místo porovnání ( n = = 0 ). Nicméně při black-box testování tuto chybu neobjevíme tak snadno. Program nebude fungovat už pro jednoduchý test n = 2.
Příklad 8.2 Implementovaná funkce je specifikována následovně: Pro všechna i z intervalu 1 .. N, prohledej pole A (i,1), A (i,2), A (i,3), …, a najdi první nenulový prvek. Ulož pozici prvního nenulového prvku do pole W (i) a její typ (+1 pro kladou a -1 pro zápornou hodnotu) do pole T (i). Předpokládej, že pole A bude vždy nenulový prvek. Jaké testy musíme připravit pro tuto funkci, jestliže neznáme její implementaci? Některé příklady testů jsou v následujícím seznamu: Všechny prvky matice A mají hodnotu nula. Všechny prvky matice A mají kladnou hodnotu. Všechny prvky matice A mají zápornou hodnotu. Každý řádek matice má kladné a záporné hodnoty. Každý řádek matice má hodnoty nenulové a nulové. Při testování funkce z příkladu 7.2 mohou nastat tyto problémy: Problémy s prvkem v prvním a posledním řádku. Problémy prvkem v prvním a posledním sloupci. Hodnota N může být systémem limitována.
83
Uvedená funkce v příkladu 8.2 prakticky nelze plně otestovat jako black-box. Je nutné použít technologii, která je označována jako white-box testování. Black-box testování (funkcionální testování) – je testování správného provádění všech navržených funkcí produktu. Tento typ testování nemusí postihnout všechny podrobnosti implementace. White-box testing (strukturální testování) – testuje, zda všechny vnitřní komponenty správně fungují. Tento typ testování nemusí postihnout chybějící alternativy.
8.5
White-box testování
White-box testování se liší od black-box tím, že používá informace o vnitřní struktuře testovaného modulu a znalosti zdrojového kódu.V následující tabulce jsou uvedeny potřebné informace pro white-box testování. 1. 2. 3. 4. 5. 6. 7.
Testovaný modul Soubor specifikací výstupu pro specifický vstup. Počet větvení ve zdrojovém programu. Počet a typ cyklů ve zdrojovém programu. Počet volání funkcí ve zdrojovém programu. Počet nepodmíněných skoků ve zdrojovém programu. Použití rekurze, které je třeba věnovat zvláštní pozornost.
White-box testování (strukturální testování) prověřuje následující programové struktury: · všechny samostatné cesty uvnitř modulu budou provedeny alespoň jednou ·
všechny podmínky se projdou větví s hodnotou ANO (true) i větví s hodnotou NE (false)
·
projde všechny cykly
·
prověří vnitřní datové struktury
V příkladu 8.2 byl uveden program, který nebylo možno otestovat bez znalosti zdrojového programu. Zdrojový program v C může mít tvar, který je uveden jako příklad 8.3 (není však zamýšlen jako ilustrace správného programu).
Příklad 8.3 Zdrojový program funkce specifikované v příkladu 8.2
84
i = 0; done = false; new_one = true; while (!done) { if (new_one) { if (i <= N) { j = 1; new_one = false; rest = false; else done = true; } else { if (rest) { j = j + 1; rest = false; } else { W(i) = j; if (A(i,j) > 0) { T(i) = 1; new_one = true; } else { if (A(i.j) < 0) T(i) = -1; new_one = true; else rest = true; } } } if new_one i = i+1; } } } Pro uvedený příklad nemůžeme otestovat nekonečně mnoho průchodů programem.
85
Příklad 8.4 i = 1; while (i>0) { i = i+1; do_cokoliv(); } Abychom našli potřebný počet průchodů programem pro testování nahradíme program z příkladu 8.3 grafem, kde každý příkaz programu odpovídá uzlu grafu a hrany představují logickou posloupnost příkazů. Takový graf nám pomůže najít všechny důležité průchody programem. Na obr.8.1 je graf programu z příkladu 8.3 uveden. Počet větví v programovém grafu můžeme redukovat na minimu potřebné k úplnému otestování. Redukovaný graf pro příklad 8.3 je uveden na obr.8.2.
Obr. 8.1
Obr. 8.2
86
Protože nemůžeme otestovat nekonečně mnoho průchodů programem, hledáme cesty, jak jejich počet omezit. Jedním z používaných řešení je i přístup uvedený v následující tabulce: 1.
Otestuj program s 0, 1 nebo libovolným počtem průchodů cyklem.
2.
Otestuj zda cyklus je vždy ukončen (předpokládáme, že tomu tak je).
3.
Pro vložené cykly otestuj vnější i vnitřní cyklus. Jestliže je více než dva vnořené cykly, otestuj každý alespoň jednou.
8.6
Testování podle základních cest
V předchozím příkladu jsme si uvedli příklad, jak můžeme nahradit zdrojový program programovým grafem. Graf můžeme sestavit i z vývojového diagramu.
Příklad 8.5 vývojový diagram
graf toku řízení
87
Počet nezávislých cest v programu je udán cyklomatickou složitostí. Cyklomatická složitost je metrika složitosti programu, která udává počet nezávislých cest v programu. Nezávislá cesta je taková, která prochází od začátku do konce programem a prochází alespoň jedním příkazem nebo podmínkou, kterým neprochází jiná taková cesta.
Nezávislé cesty v příkladu 8.5 Cesta 1: 1-11 Cesta 2: 1-2-3-4-5-10-1-11 Cesta 3: 1-2-3-6-8-9-10-1-11 Cesta 4: 1-2-3-6-7-9-10-1-11
Cyklomatická složitost V(G)
je počet oblastí v grafu toků
V(G) = E- N + 2
kde E je počet hran grafu G, N je počet uzlů
V(G) = P +1
kde P je počet predikátových uzlů v grafu G.
Počet nezávislých cest je menší nebo roven číslu V(G), současně je to počet testů, které musí být provedeny, aby byl každý příkaz proveden alespoň jednou. Odvození testovacích dat Postup při tvorbě testovacích dat: ·
vytvoř graf toku řízení
·
urči cyklomatickou složitost
·
urči množinu nezávislých cest
·
odvoď testovací data pro každou cestu
88
8.7
Testování podle řídicí struktury
Testování podmínek Restování podmínek předstvuje testování všech podmínek v programu. Testování větví (branch testing) - otestování obou větví podmínky. Testování domén (domain testing) - otestování všech kombinací vztahů proměnných testu (např. pro A relace B, budou tři testy, kdy A>B, A
Testování cyklů Jednoduchý cyklus 1. přeskoč cyklus 2. projdi právě jednou 3. projdi dvakrát 4. projdi m krát, m< n, kde n je max počet průchodů 5. n-1, n, n+1 průchodů
Vložené cykly (redukovaná strategie jednoduchého cyklu) 1. začni nejvnitřnějším cyklem, ostatní cykly nastav na minimum průchodů 2. proveď všechny testy pro jednoduchý cyklus 3. postupuj směrem k vnějšímu cyklu, vnější cykly nastav na minimum průchodů, vnitřní na “typickou hodnotu” 4. pokračuj dokud neotestuješ všechny cykly
89
Zřetězené cykly Pokud jsou nezávislé, postupuj jako u samostatného jednoduchého cyklu, pokud jsou navzájem závislé (mají např. stejný čítač) postupuj jako u vložených cyklů Nestrukturované cykly by měly být pokud možno předělány na strukturované Black-box testing (behavior testing, partition testing, funkcionální testování) Je založeno na funkčních požadavcích. Vzhledem k white-box testing jde o doplňkovou nikoli alternativní metodu. Hledá · · · · ·
nesprávné nebo chybějící funkce chyby rozhraní chyby datových struktur nebo přístupu k externím databázím chybné chování (performance) chyby inicializace nebo skončení
Aplikuje se až po white-box testing. Hledají se odpovědi na otázky: · Jaká je validita funkcí? · Jaké třídy vstupů tvoří dobrá testovací data? · Je systém zvlášť citlivý na některá vstupní data? · Jaká jsou hranice tříd vstupních dat? · Jaké rozsahy a hodnoty dat systém toleruje? · Jaký efekt na systém mají speciální kombinace dat? Testy by měly redukovat počet dalších testů. Testy by měly napovědět něco o přítomnosti či absenci tříd chyb.
8.8
Metody založené na grafu
Ověřit, že všechny objekty jsou v požadovaných vzájemných vztazích. Znázornit graficky a navrhnout test, který pokrývá graf. Objekty grafu mohou být jak datové objekty tak i programové objekty (moduly, nebo množina programových příkazů). Výběr menu generuje (čas generování <1 s)
okno dokumentu
nový soubor dovoluje editovat je reprezentován
obsahuje text dokumentu 90
Atributy: zahájení: implicitní nastavení, nebo volba barva pozadí: bílá barva textu: implicitní nebo volba
8.9
Beizer, B.: Black-Box Testing, Wiley
Transaction flow modeling. Uzly jsou kroky nějaké transakce (např. leteckého rezervačního systému), hrany jsou logické vztahy mezi nimi. (např. vstup je následován ověřením práv). Je možné vycházet z DFD. Finit state modeling. Uzly jsou různé uživatelsky sledovatelné stavy systému (např. sled obrazovek), hrany reprezentují přechody mezi stavy. Vychází se ze STD. Data flow modeling. Uzly jsou datové objekty, hrany reprezentují transformace jednoho datového objektu na druhý. Timing modeling. Uzly jsou programové objekty a hrany reprezentují sekvenční následnost mezi nimi. Mohou mít váhy - předpokládaný čas provedení. První testy by měly pokrýt všechny uzly (ověří se, že žádný uzel není vynechán, ověří se jeho atributy). Pak se provede pokrytí hran. Otestuje se symetričnost, transitivita či reflexivita relací. Ověří se váhy hran, jsou-li uvedeny. Provedou se případné testy cyklů.
8.10 Metoda rozdělení do tříd ekvivalencí (Equivalence Partitioning) Rozdělení vstupní domény programu do tříd dat a odvození testovacích dat. Třídy ekvivalence odvozené ze vstupní podmínky. Pokud vstupní podmínka specifikuje rozsah, jedna třída bude pro platná data a dvě pro neplatná. Pokud vstupní podmínka požaduje specifickou hodnotu, bude jedna platná a jedna neplatná. Pokud vstupní podmínka specifikuje množinu dat, bude jedna platná a jedna neplatná. Pokud vstupní podmínka je booleovská, bude jedna platná a jedna neplatná. Příklad: Automatický bankovní systém Uživatel komunikuje s bankou použitím osobního počítače. Posílá data následujícího formátu: kód oblasti, prefix, sufix, heslo, příkaz. Vstupní podmínky: Kód oblasti: booleovská podmínka - kód oblasti je nebo není přítomen, rozsah - hodnoty mezi 200 a 999 se speciálními výjimkami. Prefix: rozsah - hodnoty >200, s žádnými nulami Sufix: hodnota - čtyři číslice Heslo: booleovská podmínka - heslo je nebo není přítomné, hodnota - šestimístný znakový řetězec Příkaz: množina obsahující možné příkazy
91
8.11 Metoda analýzy okrajových hodnot (Boundary Value Analysis) Z málo známých důvodů se velký počet chyb vyskytuje kolem okrajových podmínek vstupních dat spíše než uprostřed. Doplňuje předešlou metodu. Vybírají se data blízká hranicím tříd ekvivalence. Uvažují se jak vstupní podmínky tak i výstupní podmínky. Pokud vstupní podmínka specifikuje rozsah od A do B, testovací data mají být A, B, bezprostředně nad a pod A a B. Pokud vstupní podmínka specifikuje počet hodnot, testovací data mají obsahovat minimální a maximální hodnotu. Body 1 a 2 aplikuj pro výstupní specifikace. (např. výstup je tabulka hodnot, navrhněme test, který by produkoval maximální (minimální) hodnoty tabulky.) Pokud vnitřní datová struktura má předepsané ohraničení (např. limit položek), navrhni test ohraničení.
8.12 Srovnávací testování (Comparison Testing, back-toback testing) Pro požadavky zvýšené spolehlivosti (navigace letadel, řízení nukleární elektrárny a pod.) mohou být některé časti (HW i SW) redundantní, zpracovávané nezávislými týmy ze stejných specifikací. Každá aplikace je testována se stejnými daty a výsledky by měly být stejné. Pak jsou všechny verze prováděny paralelně s porovnáním reálného času výsledků a zajištění konsistence. Někdy se pouze kritické části programují paralelně, ale předává se jen jedna verze. Testy se provádějí podle některé z výše uvedených metod.
92
8.13
Testování pro speciální prostředí a aplikace
Testování GUI Serie obecných testů pro okna: ·
Bude okno správně otevřeno klávesovými příkazy či příkazy menu?
·
Může být okno zmenšeno/zvětšeno, přesunuto, schováno?
·
Jsou všechna data uvnitř okna dostupná myší, funkční klávesou, šipkami a klávesnicí?
·
Je okno správně obnoveno, když se překryje a znovu zavolá?
·
Jsou všechny funkce v okně dostupné, když je potřeba?
·
Jsou všechny funkce v okně spustitelné?
·
Jsou všechny roletová menu, nástrojové lišty, dialogová okénka, knoflíky, ikony a ostatní řídicí prvky správně zobrazeny?
·
Je aktivní okno správně vysvícené?
·
Jsou všechny roletová menu, nástrojové lišty, dialogová okénka, knoflíky, ikony a ostatní řídicí prvky správně zobrazeny?
·
Je aktivní okno správně vysvícené?
·
Pokud se užívá multitasking (zpracování několika úloh současně), jsou všechna okna správně a ve správný čas aktualizovaná?
·
Nezpůsobí vícenásobné kliknutí myši, nebo kliknutí mimo okno neočekávaný vedlejší efekt?
·
Objevují se správně zvuková nebo barevná upozornění?
·
Zavře se okno správně?
Pro roletová menu a operace myši ·
Je zobrazena správná příkazová lišta v odpovídajícím kontextu?
·
Jsou správně zobrazeny doplňující údaje (např. čas)?
·
Pracuje správně stahování menu?
·
Jsou všechny funkce v menu a případné podfunkce správně zobrazeny?
·
Jsou všechny funkce v menu správně ovladatelné myší?
·
Dají se příslušné funkce spustit správně odpovídajícím klávesovým příkazem?
·
Jsou funkce správně vysvíceny nebo neosvíceny podle daného kontextu?
·
Dělá každá funkce, co má?
·
Jsou názvy funkcí názorné a srozumitelné (self-explanatory)?
·
Je pro každou položku menu dostupný help a je kontextově závislý?
93
·
Jsou operace myši správně rozpoznány?
·
Pokud je požadované vícenásobné kliknutí, je správně rozpoznáno?
·
Je správně zobrazen a změněn kurzor v daném kontextu?
Pro datové vstupy: · Jsou alfanumerické datové vstupy správně zavedeny do systému? ·
Jsou nesprávná data správně rozpoznána?
·
Navíc se může použít metoda konečných automatů pro odvození doplňujících testů.
Testování uživatelské dokumentace a helpu Je frustrující, když postupujete podle dokumentace a dostanete nesprávné výsledky
Testování dokumentace musí být součástí plánu testování. Dvě fáze testování: 1. inspekce prověřuje obsah a formu samotné dokumentace 2. živé (life) testy prověřují dokumentaci ve spojení s programem Používají se analogické metody jako pro black-box testování: ·
Popisuje dokumentace správně provedení změny módu?
·
Je dobře popsaná posloupnost interaktivní komunikace?
·
Jsou uvedené příklady správné?
·
Je terminologie, popisy menu, a systémových odezev popsána konsistentně s programem?
·
Je relativně snadné nalézt v dokumentaci případnou radu, návod?
·
Je popsáno chování v případě problému? (trableshooting)
·
Má dokumentace správný obsah a rejstřík?
·
Je grafická úprava přehledná (a není matoucí)?
·
Jsou všechna chybová hlášení podrobně popsána v dokumentaci?
·
Jsou hypertextové odkazy správné?
94
Závěr o Testování má zvýšit pravděpodobnost, že v programu nejsou chyby. o White-box testing vychází ze znalosti programové řídicí struktury. Testy by měly vyzkoušet alespoň jeden průchod všemi příkazy a vyzkoušet všechny logické podmínky. o Je to testování v malém, pro malé programy a moduly. o Black-box testing hledá chyby ve funkčním chování, bez ohledu na jejich implementaci. Je zaměřeno na informační doménu, odvozuje testovací data ze vstupních a výstupních podmínek. o Speciální metody testování jsou pro různé typy programů a aplikačních oblastí - GUI, klient/server, real time, dokumentace a help. o Zkušení programátoři říkají: “Testování nikdy nekončí, jenom se přesouvá od programátora k zákazníkovi. Pokaždé, když zákazník spouští program, tak ho vlastně testuje.”
95
9
Strategie testování softwaru
Strategie testování integruje metody návrhu testů do celkového plánu procesu tvorby softwarového produktu. Strategie testování zahrnuje plánování testů, návrh testů, provedení testů a vyhodnocení jejich výsledků. · · · ·
Testování začíná na úrovni modulu a pokračuje “směrem ven” k integraci kompletního počítačového systému. Pro různé situace se používají různé techniky testování. Pro malé projekty je testování řízeno realizátorem, pro větší nezávislou skupinou. Testování a odstraňování chyb jsou rozdílné aktivity, avšak odstraňování chyb musí být zahrnuto do strategie testování.
9.1
Verifikace a validace
Verifikace: Ověření, že software správně implementoval specifické funkce. “Vytvořili jsme produkt správně?” Validace: Ověření, že software odpovídá požadavkům zákazníka. “Vytvořili jsme správný produkt?” Verifikace a validace jsou součástí zabezpečení kvality softwaru (SQA). Testování hraje důležitou roli při verifikaci a validaci.
9.2 · · ·
Nesprávné názory na strategii testování
Tvůrce by neměl provádět žádné testování! Software má testovat někdo nezávislý, který to provede bez jakýchkoli ohledů. Tester má vstoupit do projektu až v okamžiku testování.
Tvůrce by měl testovat jednotky (moduly), v mnoha případech řídí také integrační testy. Až v okamžiku, kdy je software kompletní, nastupuje nezávislá skupina testérů (ITG independent test group), která ověří kvalitu SW. Při tomto ověřování sledujeme v zásadě postup návrhu systému tak, jak je znázorněno na obr. 9.1.
96
systémové požadavky analýza požadavků návrh
White box testování
kód Verifikace programové konstrukce (black box částečně white box testování)
jednotkový test integrační test
Ověření, že program vyhovuje požadavkům na funkci, chování a provedení (black box)
validační test
Test v kombinaci s ostatními systémovými prvky –HW, databáze, uživatelé.
systémový test
obr. 9.1.
9.3
Ukončení testování
“Kdy skončit testování, jak poznat, že jsme testovali dostatečně?” Odpověď na tuto otázku není jednoduchá. Existuje celá řada strategií z nichž si jako příklad uvedeme alespoň jednu. [Musa a Ackerman] zavedly následující model :
Logarithmic Poisson execution-time model: f(t) = (1/p) ln (l 0 pt + 1) kde f(t) je kumulativní počet poruch, které se očekávají, že nastanou po testování softwaru po určitou dobu t, l0
je počáteční softwarová intenzita poruch (poruchy za časovou jednotku) na začátku testování
p
je exponenciální snížení intenzity poruch po odhalení chyb a jejich odstranění
Okamžitá intenzita poruch l(t) : l(t) = l0 / (l0 pt + 1)
97
9.4
Testování jednotek
Testování zaměřené na verifikaci malých jednotek softwarového návrhu - modulů. Podle popisu návrhu procedur jsou testovány důležité cesty uvnitř modulu. Testování jednotek je prováděno metodami white-box testování paralelně pro více modulů. V rámci testování jednotky se prověřuje ·
rozhraní
·
lokální datové struktury (zda dočasně uložená data zachovávají svou integritu)
·
okrajové podmínky (zda modul pracuje správně na hranicích, omezujících výpočet)
·
nezávislé cesty (zaručující, že každý příkaz bude proveden alespoň jednou)
·
cesty pro zpracování chyb
·
Testování rozhraní Kontrolní seznam (checklist) pro testování rozhranní: 1. Je počet vstupních parametrů roven počtu argumentů? 2. Odpovídají atributy parametrů a argumentů? 3. Je počet argumentů přenášených do volaného modulu roven počtu parametrů? 4. Je počet atributů argumentů přenášených do volaného modulu roven počtu argumentů parametrů? 5. Jsou definice globálních proměnných konsistentní v modulu? 6. ... 7. Pokud modul ovládá externí I/O, musí být doplněny další testy, které ověří: 1. správné atributy souborů 2. správné příkazy open/close 3. zda odpovídá příkaz i/o specifikacím 4. zda odpovídá velikost bufferu velikosti záznamu 5. zda jsou soubory před použitím otevírány 6. správné podmínky eof 7. ošetření i/o chyb 8. kontrola textových výstupních informací
98
Pro lokální datové struktury je nutné otestovat: 1. nevhodné a nekonsistentní typy 2. chybné inicializace nebo default hodnoty 3. nesprávné (překlepy) jména proměnných 4. nekonsistentní datové typy 5. podtečení, přetečení a adresní výjimky Kromě toho je potřeba kontrolovat zpracování globálních dat. Mezi časté chyby patří: 1. nepochopené nebo nesprávné priority aritmetických operací 2. smíšené operace (mixed mode) 3. nesprávná inicializace 4. nesprávná symbolická reprezentace výrazu
Antibugging Antibugging je předvídání chybného chování při návrhu cesty pro zpracování chybného stavu, které ukončují výpočet s chybovým hlášením. Je třeba testovat, zda nenastane některý z následujících případů: 1. Popis chyb není příliš inteligentní. 2. Oznámené chyby nekorespondují se skutečnými. 3. Chyba způsobí zásah do systému dříve, než je ošetřena. 4. Nesprávné ošetření výjimečných podmínek. 5. Popis chyby neposkytuje dostatečné informace k lokalizaci chyby.
Pomocné programy pro testování modulů Rozeznáváme dva typy pomocných programů pro testování modulů: ·
řídicí programy - drivers (nahrazují nadřazené programy)
·
testovací kódy (makety) - stubs (nahrazují volané podprogramy).
Někdy nelze tyto programy napsat pro každý modul, pak se musí testování jednotky odložit na úroveň kroku integračního testování.
99
9.5
Integrační testování
V integračním testování rozeznáváme dva přístupy: ·
přístup “velkého třesku”
·
inkrementální integrace
·
Přístup „velkého třesku“ - spojí se všechny moduly a pak se testuje vše najednou. Přitom se ovšem v záplavě chyb nelze orientovat. Pro velké systémy je tento přístup nevhodný. Inkrementální integrace je opakem této strategie.
Integrace shora-dolů Při této strategii se začíná s hlavním řídicím modulem a postupuje se směrem dolů: buď strategií do hloubky nebo do šířky. 1. Hlavní modul je řídicí (driver), makety (stubs) nahrazují všechny podřízené moduly. 2. Postupně (buď podle přístupu do hloubky nebo do šířky) jsou makety nahrazovány skutečnými moduly. 3. Po každém přidání modulu je systém otestován. 4. Regresní testování má zajistit, že nebyly zavlečeny nové chyby. Problém může nastat, když očekáváme významné výstupy z podřízených modulů, které nám makety neumí poskytnout. Úrovně složitosti maket ·
zobrazí zprávu
·
zobrazí aktuální parametry
·
navrací hodnoty z tabulky nebo externího souboru
·
provádí vyhledání z tabulky podle vstupních parametrů a vrací příslušné výstupní parametry
Integrace zdola nahoru Tento přístup eliminuje potřebu maket. 1. Nejnižší moduly jsou spojeny do skupin (clusterů), které provádí specifické funkce. 2. Je napsán řídicí modul (driver), který je koordinuje. 3. Skupina (cluster) je otestována. 4. Drivery se odstraní a skupiny se pospojují směrem výše v programové struktuře.
100
Regresní testování Testuje se, zda nenastal vedlejší efekt přidáním nového modulu (zavlečené chyby) opakováním předchozích testů. Existují nástroje na toto testování (Capture-playback tools) - opakují se zde tři rozdílné třídy testů: ·
representativní vzorek testů, zkoušejících všechny softwarové funkce
·
testy zaměřené na funkce, které by mohly být pravděpodobně zasaženy změnou
·
testy softwarových komponent, které byly změněny
Výhody a nevýhody jednotlivých metod Top-down - nevýhodou je potřeba tvorby maket. Bottom-up - program neexistuje dokud není kompletní. Sendwich testing - integrace v obou směrech. Doporučuje se začít kritickými moduly, které se vyznačují tím, že: 1. řeší více požadavků 2. jsou na vyšší úrovni řízení (výše v programové struktuře) 3. jsou složité nebo náchylné k chybám 4. mají pevně definované požadavky Integrační testy musí být dokumentovány (plán testování, popis pomocného sw – řídicí moduly a makety, pořadí integrace, popis testových případů, očekávaných a skutečných výsledků).
9.6
Validační testování
Provádí se po integraci a slouží k ověření, že software splňuje “rozumná očekávání” zákazníka, která jsou definovaná ve specifikacích softwarových požadavků (“validační kritéria”). Provádí se metodami black-box testování. Pokud je SW určen pro jednoho uživatele, dá se mu do užívání k akceptačním testům. Pokud je určen pro více různých uživatelů, provádí se alfa a beta testování.
101
Alfa testování provádí zákazník v řízeném prostředí dodavatele (“programátor se mu dívá přes rameno”). Beta testování se provádí u jednoho nebo více zákazníků. Vývojář není přítomen. Zkouší se to v “živých” podmínkách. Zákazník zapisuje všechny problémy (skutečné i imaginární) a určitých intervalech je posílá dodavateli.
9.7
Systémové testování
Systémové testování je série různých testů, která prověřuje celý počítačový systém (HW, SW prostředí, databáze, lidi…).
Testování obnovy (Recovery testing) Systémové testování ověřující, že poruchy byly řádně ošetřeny v předepsaném čase. Pokud je ošetření automatické, vyhodnocuje se re-inicalizace, mechanismus checkpointů, obnova dat, restart. Je-li prováděno manuálně, ověřuje se, zda "střední hodnota opravy (mean-time to repair)" byla v limitu.
Bezpečnostní testování (Security testing) Testování odolnosti proti útokům hackerů. Tester supluje roli hackera a snaží se proniknout do systému. Má-li dost času a zdrojů, tak se mu to podaří. Úlohou systémového návrháře je, aby cena proniknutí do systému byla větší než cena informací, které lze získat.
Zátěžové testování (Stress testing) Cílem je prověřit program v abnormální situací (kvantita, frekvence nebo obsah). Jak dlouho mohu systém namáhat, než se zhroutí? Např. 1. generovat 10 přerušení za sekundu 2. vstupní data zvětšit o řád než je dovoleno a vyhodnotit chování vstupní funkce 3. požadovat maximální paměť či jiné zdroje 4. pokusit se způsobit problém v operačním systému 5. velké nároky na disk apod. Variantou je sensitivity testování, které se snaží objevit kombinace dat (v rámci platného omezení), které mohou způsobit nestabilitu či nesprávnou funkci.
102
Ladění (The art of debugging) Zatímco testování lze plánovat a systematicky provádět podle nějaké strategie, ladění, které je důsledkem úspěšného testování (našly se chyby), je víceméně uměním. Oprava nesouhlasu mezi očekávaným a skutečným výstupem spočívá v nalezení příčiny daného symptomu. Příčina se buď najde a chyba se opraví, nebo se musí navrhnout jiný test, který ji pomůže lokalizovat
Přístupy k ladění Při ladění programů jde o kombinaci systematického vyhodnocování, intuice a štěstí. Existuje několik různých přístupů: ·
hrubá síla - nejčastější metoda a nejméně efektivní
·
backtracking - postupujeme zpětně (manuálně) od daného symptomu po všech cestách a hledáme chybu (To je možné jen pro malé programy).
·
eliminace příčin - návrh testů má eliminovat možné příčiny.
Všechny přístupy mohou být podpořeny ladicími nástroji (debugging tools) – trasování, automatické generátory testů, výpisy paměti, křížové odkazy, ladicí nástroje překladačů. Často stačí vysvětlit problém jinému kolegovi (jiný pohled) a chyba se objeví.
Náměty k zamyšlení
O čem bychom měli přemýšlet, když objevíme chybu: · · ·
Neopakuje se chybný kód ještě v jiných částech programu? Opravíme-li chybu, nemůžeme tím do programu zavléci další chyby (a jaké)? Jak zabránit, abychom se takovým chybám v budoucnu vyhnuli? (Je to snaha odstranit chybu nejenom z produktu, ale i z procesu.)
103
10 Řízení změn Změny při vývoji softwaru jsou přirozené a je nutné s nimi počítat. Změny je potřeba analyzovat dříve, než nastanou a evidovat je před tím, než se implementují. Je nutné uvědomit o chybách ty, kterých se týkají. Řízení softwarových konfigurací označujeme jako SCM (Software Configuration management) a má za cíl: 1. identifikovat změny 2. řídit změny 3. zajistit, aby změny byly řádně implementovány 4. informovat o změnách ty, kterých se to týká SCM je aktivita, která začíná na začátku softwarového projektu a končí až, když je software vyřazený z provozu.
10.1
Příčiny změn
Příčiny změn mohou být velmi různé, ale mezi nejčastější patří: ·
nové obchodní nebo tržní podmínky, které vyvolávají změny v požadavcích na produkt nebo v obchodních pravidlech
·
nové potřeby zákazníka, vyžadující modifikace produkovaných dat z IS, funkčnosti produktu, nebo služeb poskytovaných počítačovým systémem.
·
reorganizace nebo obchodní změny, které mohou způsobovat změny v prioritách projektu nebo v realizačním týmu
·
omezení rozpočtu nebo harmonogramu, které způsobují změnu definice systému nebo produktu
Prvkem softwarové konfigurace SCI (software configuration item) může být program, dokumentace nebo data, která jsou výstupem či produktem softwarového projektu nebo některé jeho etapy. SCI může být např. dokument systémových specifikací, plánu softwarového projektu, nebo sada testovacích dat nebo programových komponent.
10.2
Srovnávací základna
Srovnávací základna (Baseline ) je specifikace nebo produkt (SCI), který byl formálně revidován a odsouhlasen tak, že pak slouží jako základ pro další vývoj a může být změněn jenom formálně řízenou změnovou procedurou.
104
Dříve než se produkt stane srovnávací základnou jsou změny snadné (týkají se jen jednoho nebo úzkého okruhu tvůrců). Jakmile se stane srovnávací základnou - prakticky po nějakém milníku, kdy byla provedena revize, jsou změny komplikovanější, protože se týkají více lidí, musí se provést podle určitých pravidel. Po revizi je schválené SCI - srovnávací základna - uloženo do projektové databáze (softwarový repositář nebo projektová knihovna). Často jsou jako SCI - srovnávací základny uvažovány i verze kompilátoru, CASE nástroje a editory, protože jiné verze mohou způsobovat změny produktu. (Verze produktu je potřeba vztahovat k verzím vývojových nástrojů)
10.3
Proces SCM
Proces řízení softwarových komunikací musí odpovědět na otázky: ·
Jak organizace identifikuje a řídí velké množství existujících verzí programů (včetně dokumentace) tak, aby bylo možné účinně provádět změny.
·
Jak řídí organizace změny před a po dodání softwaru zákazníkovi?
·
Kdo zodpovídá za schvalování a určování priorit změn?
·
Jak je zabezpečeno, aby změny proběhly správně?
·
Jak jsou ošetřeny vedlejší změny, které mohou nastat?
Aby proces SCM mohl na uvedené otázky odpovědět, musí provést některé základní úkoly, kterými jsou: ·
identifikace SCI
·
řízení verzí
·
řízení změn
·
audit konfigurací
·
evidence a zprávy
Identifikace SCI Prvky softwarové komunikace (SCI) mohou být graficky reprezentovány jako objekty s atributy a vazbami na jiné objekty. Každý objekt je identifikován: ·
jménem (jednoznačný řetězec znaků)
·
popisem (typ SCI: dokument, program, data; identifikace projektu, změny, verze)
·
seznamem zdrojů (entity “poskytované, zpracovávané, odkazované nebo jinak požadované objektem” - např. datové typy, funkce, proměnné)
105
·
part of (např.objekt je částí agregovaného objektu, ERD je částí datového modelu, datový model je částí analytické specifikace)
·
interrelated (např. datový model je v relaci s DFD, s testovacími daty apod.)
10.4
Řízení verzí
Forma reprezentace verzí je evoluční graf, který zobrazuje hierarchii změn: drobné úpravy 1.1 → 1.1.1, větší změny 1.1 → 1.2, ještě větší 1.1 → 2.0 Každý uzel je agregovaný objekt, kompletní verze softwaru - sada SCI (zdrojový kód, dokumentace a data). Verze - varianta - komponenta Každá verze může být složena z různých variant. Varianty se mohou lišit např. výběrem různých komponent (např. pro monochromní nebo barevný displej) Každá varianta je složena s odlišného souboru objektů jedné úrovně revize a tudíž koexistuje paralelně s jinými variantami. Komponenta je složena z objektů stejné úrovně revize.
10.5
Řízení změn
Proces změny můžeme popsat následujícími body: ·
zjištěná potřeba změny
·
požadavek na změnu od uživatele
·
vyhodnocení vývojářem
·
generování změnové zprávy
·
odpovědná osoba nebo skupina - CCA (change control authority) rozhodne o změně (v případě neakceptace je informován uživatel a proces změny končí)
·
požadavek je zařazen do pořadí k vyřízení, stanoví se kritéria pro revizi či audit - ECO (engineering change order)
·
určí se pracovníci
·
příslušný konfigurační objekt se vybere z databáze
·
provedou se změny
·
provede se revize (audit)
·
konfigurační objekt se zařadí do databáze
·
stanoví se srovnávací základna pro testování
106
·
provedou se aktivity QA a testování
·
změny se zahrnou do dalšího vydání (release)
·
přepracuje se příslušná verze softwaru
·
revize (audit) změn ve všech SCI
·
zahrnout změny do nové verze
·
distribuovat novou verzi
Přístup k databázi musí mít synchronizační kontrolu, aby dvě osoby nemohli provádět současně změny jednoho objektu. Neformální řízení změny - předtím, než se SCI stane srovnávací základnou. Vývojář se dotáže, zda změny jsou v souladu s technickými a projektovými požadavky (pokud se nedotýkají širších systémových požadavků) Řízení změny na projektové úrovni - když je SCI srovnávací základna. Vývojář musí dostat schválení k provedení změny od projektového manažera (je-li změna místní, nebo CCA, zasáhne-li další SCI. Formální řízení změny (viz výše).- jakmile se produkt dodá zákazníkovi. CCA musí rozhodnout: jak změna ovlivní chování systému, jak se projeví z pohledu zákazníka, jak to ovlivní kvalitu a spolehlivost.
10.6
Audit konfigurací
1) Formální revize je zaměřena na technickou správnost modifikovaného konfiguračního objektu, prověří konzistentnost k jiným SCI, úplnost, případné vedlejší efekty. 2) SC audit kontroluje, zda byly změny specifikované v ECO provedeny, zda nebyly provedeny ještě další změny, zda byly změny správně označeny v SCI, zda bylo zaznamenáno datum a autor změny. Zda byla změna evidována a oznámena. Zda byly opraveny všechny související SCI. Evidence stavu (status reporting) 1. co se stalo 2. kdo to udělal 3. kdy se to stalo 4. co dalšího to ovlivnil
107
Závěr Softwarová konfigurace je množina vzájemně se ovlivňujících objektů (SCI), které jsou produktem některé SI aktivity. Když je konfigurační objekt vytvořen a prošel oponenturou, stává se srovnávací základnou. Řízení změn je procedurální aktivita, zajišťující kvalitu a konsistenci, při provádění změn na objektu. Konfigurační audit je SQA aktivita, která pomáhá zajistit kvalitu provedené změny. Evidence stavu poskytuje informace pro toho, kdo to má vědět.
108
11 Projektový management Klasický management - slouží k udržování a rozvíjení zavedených systémů, které jsou prostředkem pro nepřetržitou, kontinuální a opakující se tvorbu požadovaných výstupů. Projektový management - slouží k zabezpečení realizace jedinečných, neopakovatelných, časově a zdrojově limitovaných procesů, které vedou k dosažení předem stanovených cílů. Management projektu o plánování projektu o řízení realizace projektu Organizování a koordinování projektů o vytváření organizačního prostředí o koordinování projektů
11.1
Projekt
Projekt znamená plánování a řízení rozsáhlých operací vedoucích ke konkrétnímu cíli, se stanovenými termíny zahájení a ukončení, s omezenými zdroji a náklady. Není to periodicky se opakující rutinní činnost, ale jedinečná, systémová činnost s nejistotou a rizikem. Plánování je popis (nikoli toho, co se stane, ale) toho, co chceme, aby se stalo. Řízení realizace je proces, kterým chceme dosáhnout toho, aby se plánované události skutečně staly, k neplánovaným, aby nedocházelo. Proces plánování projektu ·
stanovení cílů a definování strategie vedoucí k jejímu dosažení
·
zpracování strukturované dekompozice činností projektu
·
vytvoření projektové organizační struktury a sestavení projektových týmů
·
zpracování implementačních plánů projektu, tj. časových plánů, plánů nákladů, alokace zdrojů
·
specifikace nástrojů a technik pro řízení projektu
·
identifikace možných omezení, rizikových oblastí a návrh způsobů eliminace těchto vlivů
109
Proces řízení realizace projektu zahrnuje následující aktivity: ·
realizace implementačních plánů projektu a koordinace subjektů podílejících se na jeho realizaci
·
identifikace a analýza aktuálních dat
·
řízení, kontrola a průběžné vyhodnocování, analýza a korekce průběhu projektu kontrola stanovených cílů, termínů a čerpání zdrojů a nákladů
·
řešení konfliktních a nestandardních situací
·
technická a administrativní podpora projektu
·
změnová řízení
·
koordinace postupné integrace sytému
·
vyhodnocení dílčích etap projektu a návrh úprav
Začlenění projektového managementu do organizační struktury může být na těchto úrovních: ·
útvarový projektový management
·
maticový projektový management
·
čistý projektový management
·
síťový projektový management
11.2
Týmový management projektu
Stejně jako aktivity realizace projektu je nutné organizovat projektový tým. V projektovém týmu platí tato hierarchie: ·
manažer projektu
·
vedoucí projektové skupiny
·
členové týmu
·
dozor projektu
·
expertní tým
110
Tým může být organizován různými způsoby, které určují i styly řízení týmu. Metody týmové práce: ·
pracovní porady
·
komunikace a koordinace
Psychologie týmové práce: ·
motivace
·
řešení konfliktů
·
rizika skupinového myšlení
Manažer projektu zodpovídá za: ·
řízení realizace implementačních plánů
·
identifikace odchylek od plánů, včetně návrhů a realizace nápravných opatření
·
poskytování informací o průběhu realizace projektu
·
formulování a předkládání požadavků, která jsou nad rámec jeho pravomocí
·
předvídání vzniku problémů a hledání vhodných způsobů jejich řešení
·
vyřizování pracovních nároků a problémů členů týmu
·
sledování a vyhodnocování vynaložených nákladů vzhledem k danému rozpočtu
·
vytváření potřebných pracovních kontaktů na všech úrovních řízení
Možné charakteristiky členů týmu ·
neví a neví, že neví (neví a tvrdí, že ví)
·
ví a ví, že ví
·
neví a ví, že neví
·
neví, že ví
V týmu se uplatní tyto metody chování a práce: Asertivní chování - sebeprosazování otevřenou komunikací při zachování práv druhých. Synergický efekt - zesilující účinek projevující se např. v týmové práci. Brainstorming - skupinová metoda hledání alternativ. Tato metoda slouží ke generování námětů a alternativ řešení. Je založena na asociativní týmové práci. Každý říká nahlas své nápady, ostatní se jimi nechají inspirovat a produkují nápady další. Náměty se zapisují a na konci zpracují.
111
Pracovní porady Pracovní porady mohou mnít různý charakter i význam - pravidelné porady, porady zaměřené na kvalitu, koordinační porady, plánovací porady, informační porady.. Porada je vhodná pro tyto aktivity: ·
kontrola postupu prací a specifikace důsledků neočekávaných změn
·
diskuse o alternativních možnostech realizace projektových činností
·
udržování potřebné informovanosti členů týmu
·
koordinování potřeb projektu s dalšími stranami
·
kontrola a minimalizace projektových nákladů
·
dodržování kvality
·
řešení konfliktních situací
Zásady pro efektivitu porad ·
včas poskytnout všem pracovní materiály, které se budou projednávat
·
znát předem čas zahájení a ukončení porady
·
zahájit porady bezodkladně
·
porada musí mít svého předsedajícího a zapisovatele
·
zápis má obsahovat uložené úkoly jmenovitě a s termínem
·
na závěr porady je třeba zrekapitulovat úkoly a termíny
·
zápisy se musí distribuovat podle jasných pravidel (komu a do kdy)
·
zvát na porady jenom ty pracovníky, kterých se daná problematika týká
Motivace Motivace členů týmu mohou být různé, hovoříme o motivačním profilu člověka. Hodnotové skupiny motivace jsou: ·
individuální (spokojený život, rodina, domov)
·
pracovní (sebezdokonalování, seberealizace)
·
společenské (kontakt s lidmi, postavení)
·
materiální (peníze, jídlo, zábava)
·
hodnota volného času (život podle vlastních zálib)
112
Existují tři skupiny pracovníků ·
pracovníci orientovaní na úkol (motivovaní samotnou prací)
·
pracovníci orientovaní na spolupráci (motivovaní přítomností a prací kolegů)
·
pracovníci orientovaní na sebe (motivovaní vlastním úspěchem)
Zásady neegoistického programování: ·
chyby v programech se považují za nutné zlo
·
programy jsou považovány za společné dílo týmu, nikdo nepovažuje program za vlastní dítě, které je třeba hájit
·
při rozhodování je každý ochoten přijmout řešení optimální pro celý tým, i když to může znamenat dočasnou nevýhodu pro něho samého
Výhody menších týmů (2-8 členů): ·
snazší dohoda norem kvality programů, jak mají být psány, testovány a předávány
·
možnost se učit jeden od druhého
·
snáze se realizuje neegoistické programování
·
znají navzájem svou práci, není takový problém, když někdo odejde
Vhodné pracovní podmínky pro programátory: ·
dostatek soukromí - možnost pracovat v klidu bez vyrušování
·
možnost pracovat při denním světle
·
programátoři jsou vyhraněné osobnosti a programování je individuální práce, vyplatí se dát jim možnost upravit si pracoviště a pracovat tak, jak jim vyhovuje (při splnění zákonných podmínek).
·
důležité je, aby se tým měl kde scházet.
schopnosti x podmínky x motivace
113
→ výkon jednotlivce
12 Zpětné inženýrství Co to je zpětné inženýrství ? Je to proces analýzy systému s cílem : a) identifikovat komponenty systému a jejich vzájemné vazby – „obnovení dokumentace“ b) vytvořit reprezentaci systému v jiné formě nebo na jiné úrovni abstrakce – „obnovení návrhu“
Obnovení dokumentace je odvození sémanticky ekvivalentního popisu na stejné úrovni abstrakce. Patří sem např: přeformátování zdrojového textu, konstrukce vývojových diagramů … Obnovení návrhu je odvození sémanticky ekvivalentního popisu na vyšší úrovni abstrakce. Při provádění zpětného inženýrství během změn původního systému se rozlišuje restrukturalizace a reinženýrství. Restrukturalizace je transformace systému z jedné reprezentace do druhé na stejné úrovni abstrakce beze změn funkce systému. Restrukturalizace je např: nové naprogramování modulu po změně návrhu, překonvertování existujícího software do podoby, kdy je složen ze znovupoužitelných modulů Reinženýrství (reengineering) jsou zásahy a změny do reálného systému nebo dokumentů na příslušné úrovni abstrakce. Reinženýrství je např: změna funkčnosti modulu, doplnění funkce modulu pro možnost obecnějšího použití.
114
12.1
Nástroje pro zpětné inženýrství
Existují ·
Reformátovací programy, které usnadňují vnímání zdrojového textu.
·
Nástroje zkoumající statickou strukturu programu – poskytují křížové odkazy, indikují mrtvé části kódu, generují vývojové diagramy, grafy použití modulů, grafy volání funkcí …
·
Nástroje zkoumající dynamické chování programu (monitorovací programy) – zobrazují průběh výpočtu jako sekvenci použitých modulů / volaných fcí, animaci měnících se datových struktur.
12.2
Meze zpětného inženýrství
Jestliže předáte nestrukturovaný nemodulární nepořádek některému ze systémů, které řeší restrukturalizaci, obdržíte v nejlepším případě strukturovaný, nemodulární nepořádek.
Automatická rekonstrukce návrhu ze zdrojového textu je neproveditelná. Důvody jsou: 1. Ztráta informací z vyšších úrovní abstrakce 2. Nepřítomnost vnějších informací Např: b(x, n2) okraj(okno,cerna) m(w,[x]) kurzor(objekt[okno])
115
13 Nástroje CASE Co jsou to CASE nástroje a k čemu slouží? V současné době to jsou softwarové nástroje, které podporují tvorbu softwaru. CASE = Computer Aided Software Engineering V minulosti to byl každý program, který poskytuje podporu při návrhu, údržbě softvaru, nebo procesu vývoje softwaru (softwarového projektu). Podle této definice CASE nástroj je i překladač, editor, ladící prostředek... Nyní jsou to především systémy integrovaných nástrojů, které pokrývají více než jednu fázi životního cyklu softwaru. CASE nástroje vznikly jako prostředek pro zmírnění softwarové krize. Umožňují „menšímu počtu programátorů“ vytvářet „více programů“. Takto vytvořené programy by měly být spolehlivější, snadněji modifikovatelné a udržovatelé. Výběr vhodného CASE nástroje Při výběru CASE nástroje je nutné si předem odpovědět na následující otázky: ·
Podporuje CASE integraci s ostatními nástroji potřebnými pro projekt?
·
Splňuje nástroj požadavky procesu vývoje vašeho systému?
·
Jakou notaci nástroj podporuje?
·
Je možné v rámci vývoje sledovat plnění požadované specifikace?
·
Je nástroj modulární?
·
Jak silný má nástroj repositury? Je v databázi nebo v souborech?
·
Je nástroj otevřený a přístupný modifikacím?
·
Jak nástroj podporuje verze a sdílení komponent?
·
Umožňuje spravovat projekt?
·
Podporuje nástroj kontrolu konzistence, úplnosti a dodržování metodiky?
·
Jaký je komfort ovládání?
·
Jaké je možnost sdílení a znovupoužiti (reusing) analýzy či návrhu?
·
Vytváří nástroj automaticky dokumentaci? Je možno tvorbu ovlivnit?
·
Generuje nástroj datový model? Pro jaké databáze?
116
·
Generuje nástroj kód aplikační logiky? Pro jaké jazyky? Používá nástroj šablony generovaní?
·
Disponuje nástroj možností round trip engineeringu?
·
Disponuje nástroj možností reverse engineeringu?
Problémy s CASE nástroji V současné době existuje celá řada CASE nástrojů, které jsou však velmi drahé, náročné na zvládnutí a neumí vše, co bychom od nich potřebovali. Řada firem CASE nástroje používá, ale pečlivě si tyto systémy chrání a velmi často je ani nezveřejňuje. Dalšími problémy, spojenými s CASE nástroji je: ·
Podcenění školení a potřeby adaptace současných softwarových procesů
·
Neopodstatněný optimizmus (CASE vyřeší všechny problémy).
·
CASE prostředek v rukách slabého softwarového inženýra mu umožní vytvářet více špatného softwaru.
·
Zatím je nedostatečná integrace CASE prostředků.
·
CASE prostředky jsou drahé a je potřeba s tím počítat.
117
14 Normy v SI Už v předchozích kapitolách jsme se zmínili o některých normách ISA používaných v softwarovém inženýrství.V této kapitole si uvedeme normy, které navrhla profesní organizace inženýrů IEEE (Institution of Electrical and Electronics Engineers).
14.1
IEEE Standard 1042
Norma IEEE 1042 byla přijata v roce 1987. Tato norma definuje pojmy a procesy řízení konfigurací. Koncept řízení je na obr. 15.1.
*
řízená položka
* agregace
položka konfigurace
verze
konfigurace řízení
*
iniciace
uvolnění
* workspace
archiv
obr. 15.1
118
14.2
IEEE standard 1058
Tato norma obsahuje dokumenty, které se vztahují ke konceptu řízení projektu. Vztahy mezi jednotlivými účastníky procesu jsou uvedeny na obr. 15.2 Harmonogram Přiřazen
* Úkol
*
1
produkt činnosti
produkuje * 1 Role přiřazení * 1
Účastník
přiřazení *
1 Tým
přiřazení obr. 15.2
14.3
IEEE Standard 828
Tato norma byla přijata v roce 1990 a je normou pro psaní Plánů řízení SW konfigurací (Software Configuration Management Plans – SCMP). SCMP plán obsahuje: 1. úvod: účel, rozsah, klíčová slova, literatura 2. managment: organizace, zodpovědnosti 3. aktivity 4. harmonogram
119
5. plán údržby
14.4
IEEE Standard 1074
Norma IEEE 1074 je normou pro tvorbu životního cyklu procesů. Definuje soubor aktivit a procesů povinných pro vývoj a údržbu softwaru. Proces je soubor aktivit, které provádíme za účelem splnění jistého cíle. Standard IEEE 1074 obsahuje 17 základních procesů seskupených do šesti skupin. Procesní skupiny jsou: · model životního cyklu · řízení projektu · „předvývoj“ · vývoj · „povývoj · integrace“ Procesy jsou např. : specifikace požadavků, návrh, implementace. SW procesy v IEEE 1074 procesní skupiny
aktivity
model životního cyklu
výběr modelu
řízení procesu
inicializace, monitorování a kontrola řízení kvality
předvýboj
stanovení konceptu volba systému
vývoj
požadavky návrh implementace
povývoj
instalace provoz a jeho podpora údržba odstavení
integrace
verifikace a validace konfigurace
120
zpracování dokumentace školení Na obr. 15.3 je model životního cyklu SW.
životní cyklus fáze produkt
procesní skupina vytváří
úkol
spotřebovává
proces
zdroje
účastník aktivity čas finance
Obr. 15.3 Procesy řízení projektu proces inicializace projektu
monitorování a kontrola
aktivity mapování aktivit životního cyklu zajištění zdrojů vytvoření projektového prostředí plán řízení projektu analýza rizik „hodnotové“ plánování řízení projektu záznam nabídek model hlášení problémů
121
řízení kvality
plán řízení kvality určení metrik řízení kvality rozeznání nutnosti zlepšení
Procesy vývoje proces požadavky návrh
implementace
aktivity stanovení sw požadavků definice interface integrace a stanovení priorit návrh architektury návrh databází návrh interface výběr a tvorba algoritmů detailní návrh tvorba testovacích dat napsání programu generování kódu tvorba provozní dokumentace plán integrace systému provedení integrace
Procesy povývoje proces instalace
provoz a jeho podpora údržba ukončení provozu
aktivity plán instalací distribuce SW instalace SW akceptování SW v provozních podmínkách provoz systému poskytování technické asistence a konzultací zpracování požadavků o pomoc znovuaplikování životního cyklu upozornění uživatelů umožnění paralelního zpracování ukončení provozu systému
122
Procesy integrace proces Verifikace a validace
Správa konfigurace SW
Tvorba dokumentace školení
aktivity Plán verifikací a validací Provedení verifikací a validací Shromáždění a vyhodnocení dat Metriky Plán testování Požadavky na testování Provedení testů Plán konfigurace Zjištění požadavků konfigurace Provedení kontroly konfigurace Provedené zhodnocení konfigurace Plán dokumentace Implementace dokumentace Vytištění a rozeslání dokumentace Plán školení Tvorba výukových materiálů Vaidace školení Implementace programu školení
123
Příloha I Návrh, dokončení a prezentace projektu Návrh je prvním krokem vývojové fáze každého inženýrského produktu nebo systému. Návrh může být definován jako: …proces aplikace různých technik a principů za účelem vytvoření dostatečně podrobného popisu zařízení, procesu nebo systému tak, aby ho bylo možné realizovat. Cílem návrháře je vytvořit model nebo reprezentaci něčeho, co bude později skutečně vytvořeno. Proces tvorby modelu je kombinace intuice a zvažování požadavků a je založen na zkušenostech s tvorbou podobných systémů. Soubor těchto principů a heuristik je návod, podle kterého je model vytvářen a výsledkem těchto aktivit je výsledný návrh reprezentace. Na obr. 10.1. je uveden vztah návrhu softwaru a softwarového inženýrství. informační model funkční model návrh dat chování modelu
návrh návrh architektury další požadavky procedurální návrh
kódování
programové moduly testování
integrovaný a ověřený software obr. 10.1
124
Objektový návrh Softwarový návrh je základem každé procesu v softwarovém inženýrství. V objektovém přístupu jsou základem návrhu vzory, které řeší základní problémy programování. Vzory můžeme rozdělit do tří skupin: 1. vzory pro tvorbu 2. vzory struktury 3. vzory chování Tvorba softwaru má vzory pro: •
obecnou úroveň návrhu objektů
•
reprezentaci dat a jejich konverze
•
návrh „podtříd“ objektů
•
prototypy
•
základní globální objekty
Struktura softwaru má vzory pro: •
přizpůsobení objektů s nekompatibilními metodami
•
návrh mechanismů pro možnost přidávání metod (otevřený návrh)
•
návrh potřebného interface metod
•
minimalizace „malých“ objektů
Chování systému má vzory pro: •
zřetězení funkcí
•
příkazy (ovládání)
•
monitorování vnitřních stavů
•
sledování funkcí
•
stav systému
Záleží na zkušenosti návrháře i vhodnosti volby vzorů jak bude návrh úspěšný.
Dokončení Řada problémů, které jsme v průběhu návrhu a realizace softwaru nevyřešili, se může projevit až ve fázi dokončování systému. Každou takovou situaci je potřeba analyzovat, abychom zjistili v jaké fázi řešení projektu došlo k chybě a jak se ji napříště vyvarovat.
125
Mezi základní problémy, které se mohou projevit až při dokončovaní, patří: •
odchod člena týmu
•
nedokonalá analýza
•
nová technologie pro členy týmu
•
větší složitost problému
Všechny tyto situace by měla předvídat a řešit analýza rizik. Jaká rozeznáváme rizika jsme si uvedli v příslušné kapitole. Ve fázi dokončování jsou hlavními riziky: •
neznalost algoritmů a technologií
•
úroveň abstrakce
•
neúplnost řešení
•
složitost algoritmů a metod
•
chyby v analýze a návrhu algoritmů
•
nedostatečná strukturalizace
Vyhodnocení jednotlivých etap projektu Při zpracování projektu je nutné po dokončení každé etapy provést její vyhodnocení. Při tomto vyhodnocení zjišťujeme případní rizika a hledáme odpovědi na některé otázky. Patří mezi ně: •
rozeznání rizik a jejich ošetření
•
přiřazení rizik etapám
•
analýza zachování funkčnosti příslušné části
•
zjištění, které části projektu budou ovlivněny případnou chybou
•
vytváříme seznam rizik podle jejich významu ve vztahu k členům týmu
•
mapujeme jednotlivé částí projektu pro případ omezení funkčnosti systému
Na základě provedené analýzy hledáme „poučení“ z projektu. První otázky, které si můžeme položit jsou: •
Má neohodnocení projektu nějaké důsledky pro naši další práci?
•
Byly požadavky na funkčnost po implementaci?
Jestliže jsme si na uvedené otázky odpověděli ANO, byla chybná analýza. Otázky, které prověřují návrhovou fázi: •
Byly požadavky na změnu uživatelského rozhraní po dokončení projektu?
•
Byla špatná komunikace příčinou problémů?
•
Byla architektura zpracování projektu špatná?
126
V těchto případech šlo o chybný návrh. Další otázky, které vedou v vyhodnocení projektu: •
Vyžadoval systém realizaci většího množství funkcí než bylo specifikováno?
•
Bylo potřeba mnoho modifikací v průběhu implementace?
•
Bylo nutné restrukturalizovat specifikaci po návrhu?
•
Byla architektura zpracování projektu špatná?
•
Vyžadoval systém realizaci většího množství funkcí než bylo specifikováno?
•
Bylo potřeba mnoho modifikací v průběhu implementace?
•
Bylo nutné restrukturalizovat specifikaci po návrhu?
•
Vyžadovalo testování více času z důvodu modifikací? Vyžadovalo testování více času, protože nebylo vhodně navrženo?
•
Vznikly chyby po ukončení testování?
•
Vyžadovalo testování více času, protože nebyly dobře otestovány jednotky?
Ve všech těchto případech jde o chybný návrh i analýzu. PO zjištění chyb je nutné provést analýzu co konkrétně bylo chybné a co bylo příčinou.
Prezentace Po ukončení projektu se obvykle provádí prezentace. Rozlišujeme dva základní typy prezentací: •
prezentace technická
•
prezentace funkční
Technická prezentace se soustředí na prezentaci technické stránky projektu. Je určena pro speciální uživatele. Je strukturována okolo případů použití a má ilustrovat strukturu systému. Při technické prezentaci je důležité uvést významné algoritmy, znovupoužití kódu, komunikaci modulů atp. Funkční prezentace se soustředí na předvedení funkcí systému a měla by se lišit podle cílové skupiny uživatelů, které je určena. V této souvislosti rozeznáváme tyto typy uživatelů: •
koncový uživatel
•
osamělý uživatel
•
profesionální uživatel
Funkční prezentace by měla být „dobře strukturovaná procházka“ funkcí systému. Může být určena všem typům uživatelů i jednotlivým skupinám. Měla by názorně předvést navigaci v systému a přednosti SW z uživatelského pohledu .
127
Příloha II Jazyk UML Motivace vzniku jazyka ·
Základem každého (úspěšného) projektu je dobře připravený návrh (plán) bez komentáře
·
Projekt je třeba konzultovat se zákazníkem zákazník musí být schopen týmu sdělit své požadavky (měl by rozumět notaci)
·
Vývoj je (měl by být) teamovou záležitostí každý člen teamu by měl vědět, jak bude jeho práce zapadat do celkového výsledku
·
Vývoj je omezen na krátké časové úseky když se na sebe začnou kupit termíny, je kvalitně provedený a spolehlivý návrh nutností
Potřeba kvalitních a spolehlivých návrhů s sebou přinesla i potřebu notace návrhu, který by analyti jazyka ci, vývojáři a klienti přijali jako standard - touto notací je UML.
Historie jazyka ·
Jedním z největších iniciátorů vzniku UML byla firma Rational (autoři UML: Grady Booch, James Rumbaugh, Ivar Jacobson)
·
konec roku 1995: vznik předchůdce UML - Unified Method 0.8 (Ivar Jacobson)
·
červen roku 1996: firma Rational představuje Unified Modeling Language verze 0.9.
·
Myšlenky formulované do tohoto jazyka zaujaly i ostatní velké SW firmy a tak do projektu vstoupily také společnosti Microsoft, IBM, Oracle, HP, Texas Instruments a další.
·
leden roku 1997 tyto firmy společně představují jazyk UML verze 1.0.
·
listopad roku 1997: UML bylo uznáno společností OMG (Object Management Group) jako standard.
128
Ještě trocha objektové teorie ·
·
·
· · ·
·
Abstrakce Přenesení atributů objektů reálného světa do světa OOP filtrováním těch vlastností a operací, které jsou potřebné pro popis v konkrétní implementaci. Dědičnost Objekt který je instancí určité třídy, má všechny vlastnosti a operace své třídy. Třídy mohou být závislé, rozlišujeme pak odvozené třídy - tzv. podtřídy, nadřízené třídy a na vrcholu hierarchie tzv. bazické třídy. Platí, že odvozené třídy dědí atributy a operace svých nadřízených tříd. Polymorfismus Operace v podtřídách určité nadřízené třídy mají stejný název, ale mohou mít různou implementaci. Zapouzdření Implementace operací daného objektu zústává před okolím skryta. Zasílání zpráv Zasílání zpráv je způsob jakým objekty vzájemně komunikují. Asociace Asociace je relace mezi třídami. Třída může být spojena (asociována) s jinou třídou více než jen jedním způsobem, dále je možné, aby třída byla asociována i s několika třídami. Agregace Objekt může být kombinací mnoha rúzných typů objektů. Speciálním druhem agregace je kompozice, kdy daná komponenta existuje pouze uvnitř složeného objektu.
Součásti jazyka UML Ze zkušeností vývojářů vyplynulo, že během vývoje IS/IT je třeba zachytit systém z různých pohledů v různé fázi jejich vývoje. Modelovací jazyk UML proto přináší následující prostředky:
Diagramy ·
Diagram tříd slouží k reprezentaci statické struktury systému Definice: Třída je kategorie nebo skupina věcí, které mají podobné vlastnosti a stejné nebo podobné chování. Poznámka: Každá třída může mít vlastnosti a operace. Příklad:
129
·
Diagram objektů slouží ke konkretizaci instance třídy - objektu Definice: Objekt je instance třídy, tedy určitá věc, která má specifické hodnoty vlastností a chování. Příklad:
·
Diagram případů užití slouží k vymezení hranic systému a specifikaci jeho základních funkčností Definice: Případ užití je popis chování systému z pohledu uživatele. Definice: Participantem (také aktérem) nazýváme účastníka ve vztahu uživatel-systém. Příklad:
·
Diagram stavů (stavový diagram) znázorňuje chování a stavy objektů Notace: Počáteční stav se zobrazuje jako kruh Koncový stav se zobrazuje jako kružnice se soustředně umístěným kruhem uvnitř. Jednotlivé stavy se zapisují do obdélníků se zaoblenými rohy, popis se umisťuje uprostřed čtverců. Přechody mezi jednotlivými stavy se naznačují šipkou vedoucí z výchozího do cílového stavu.
·
Diagram sekvencí ukazuje časovou dynamiku interakcí mezi objekty, typické je, že u každého objektu jsou viditelné probíhající akce Notace: Horizontálně vedle sebe se zakreslí třídy které spolu interagují. Názvy tříd jsou podtržené. Vertikálně se vedou časové osy.
130
Probíhající proces se na časové ose označí nevyplněným obdélníkem. Čekání (prázdný proces) se označuje přerušovanou čarou. Interakce se označují pomocí šipek komentovaných názvem interakce. ·
Diagram činností zachycuje sekvence činností objektů, nezabývá se tím, který objekt provádí danou akci Notace: Akce se zakreslují do obdélníků s oblými rohy, název akce se zapisuje uprostřed obdélníka. Návaznosti akcí se zakreslují šipkou vedenou od zdrojové k cílové akci.
·
Diagram spolupráce prostorově znázorňuje objekty, vazby a jejich vzájemné interakce, v podstatě je přímým rozšířením diagramu objektů Notace: Třídy se zakreslují do obdélníku, název třídy je uveden uprostřed obdélníku a je podtržen Interakce se znázorňují šipkou s komentářem a případně s pořadím dané interakce. Vazby mezi interagujícími třídami se naznačují plnou čarou.
·
Diagram komponent Software je v dnešní době vyvíjen po jednotlivých komponentách. Jazyk UML použití určité softwarové komponenty označuje graficky jako obdélník, uvnitř kterého je umístěn název komponenty. Příklad:
·
Diagram nasazení ukazuje fyzickou architekturu počítačového systému (počítače, zařízení a jejich vzájemné propojení, software který je na určitém zařízení nainstalován)
Některé další funkce ·
Balíčky dovolují seskupovat prvky diagramů do skupin Příklad:
Pokud chceme uvést, které třídy náleží do daného balíčku, zakreslíme je jako obdélníky uvnitř daného balíčku.
131
Příklad:
·
Poznámky dovysvětlují význam takových částí diagramu, které nemají jednoznačný účel, nebo neobsahují pokyn jak s nimi pracovat Notace: Poznámka je zakreslena jako obdélník s ohnutým rohem, spojený s komentovaným objektem přerušovanou čarou. Uvnitř obdélníka je umístěn komentář.
·
Stereotypy umožňují použít již existující prvky jazyka UML a vytvořit z nich nové Notace: Stereotyp se zapisuje mezi znaky << a >>. Příklad: <<Stereotyp>>
·
Rozhraní umožňuje opakovaně používat skupinu způsobů chování v celém modelu (jedná se o třídu, která má pouze operace a nikoli vlastnosti) Příklad:
Diagramy tříd Abstraktní třída Abstraktní třída je taková třída, která nemá instance objektů. Slouží jako předek pro ostatní, závislé třídy. Vztah mezi abstraktní rodičovskou třídou a podřízenými třídami se nazývá závislost. Příklad:
Třída s názvem cesty Pokud je daná třída součástí balíčku a není explicitně uvedena uvnitř balíčku, lze diagram příslušné třídy označit názvem cesty k balíčku.
132
Příklad:
Třídní atributy a metody Třídní atributy mohou být definovány takto: AttributeName [: AttributeType [= Initial Value]]
Notace pro zápis metod tříd je definována takto:
MethodName({ArgumentName : ArgumentType = DefaultValue} )[ : ReturnValue]
Přístupová práva a viditelnost UML umožnuje popisovat viditelnost atributů a metod. Standardně jsou definovány tyto možnosti: · · ·
public – atribut nebo metoda je přístupná pro všechny ostatní třídy protected – atribut nebo metoda je přístupná pouze v dané třídě a jejích podtřídách private – atribut nebo metoda je prístupná pouze pro danou třídu
Asociace Asociace reprezentují vztahy mezi dvěma (potažmo více) třídami. Graficky se znázorňují rovnou, případně lomenou čarou, která spojuje ikony tříd které jsou v dané asociaci. UML umožňuje pojmenovat jednotlivé asociace tak, aby pojmenování vystihovalo jejich funkci. Příklad:
Násobnosti asociací UML umožňuje definovat počet objektů dané třídy, které se mohou vztahovat k jednomu objektu asociované třídy, tzv. násobnost asociace. Násobnosti asociací mohou být následující: ·
1:1 Právě jeden
·
1:* Žádný nebo více
Příklad: 1:M ·
1:0,1 Žádný nebo jeden
Příklad: 1:0 nebo 1:1 ·
1:1..* Jeden nebo více
Příklad: 1:1 nebo 1:N ·
1:M..N Od M objektů do N
Příklad: 1:M až 1:N
133
·
1:M,N M nebo N objektů
Příklad: 1:M nebo 1:N
Dědičnost, neboli zobecnění Notace jazyka UML zobrazuje dědičnost (UML nazývá dědičnost termínem zobecnění) jako čáru, která spojuje rodičovskou třídu s podtřídou. Část čáry, která je spojena s rodičovskou třídou, nese nevybarvený trojúhelník, který ukazuje na rodičovskou třídu. Příklad:
Agregace Agregace je zvláštním druhem asociace, kdy se určitá třída skládá z několika tříd komponent. Komponenty a třída, kterou vytvářejí, jsou v asociaci typu je součástí. Příklad:
Implementace jazyka UML ·
Rational - komerční produkt Rational Rose - zaměřen pouze na UML, tím pádem nepodporuje vytváření modelů dat a modelů aplikačních procesů - lze vyžádat demo verzi na CD na stránkách firmy Rational [http://www.rational.com/]
·
SELECT Enterprise - byl vytvořen jako modelovací nástroj pro všechny oblasti podnikání - není pouze zaměřen na UML, podporuje i to co není v UML implementováno umožňuje sdílení repozitáře a správu verzí - více informací [http://www.selectst.com/]
·
Visual Modeler - varianta Rational Rose distribuovaná spolu s produktem Microsoft Developer Studio - umožňuje nejen tvorbu diagramů založených na standardech UML ale i celou řadu
134
dalších efektivních funkcí - zejména možnost generovat zdrojové kódy (definice tříd, metod, atributů...) přímo z modeláře na základě príslušných diagramů a to do celé řady programovacích jazyků (C++, Visual Basic, Java) ·
UML jako standardní modelovací jazyk se prosazuje do stále více prostředí a je implementován i do dalších produktů. Příkladem může být rodina modelovacích nástrojů ARIS firmy IDS Scheer, která byla nedávno rozšířena o nástroj ARIS UML Designer. "
135
Příloha III Projekt Evidence HW Slovo úvodem Evidence of hardware je databázový systém, který se zabývá evidencí výpočetní techniky. Je navrhován v rámci předmětu SI2. Dále následují kroky, které se podnikají při řešení SW projektů.
1. Úvodní studie 1.1 Deklarace záměru Systém se bude zabývat evidencí výpočetní techniky v podniku a jeho detašovaných pracovišť. Tedy zařazování nové techniky, vyřazování staré techniky, změnu atributů techniky v případě upgrade.
1.2 Odborný článek Základem systému je soustava budov (objektů), v nichž je umístěna IT technika. Počet a určení budovy je nastavitelné. Každá položka je umístěna v seznamu položek. Seznam položek je tabulka, kde každá jednotka má přidělen typ (počítač, tiskárna, CD-ROM, ...), výrobní číslo, inventární číslo, místo (adresa budovy), umístění (číslo místnosti), technické údaje. Role v systému: Vedoucí I -
vyžaduje informace o aktuálním stavu techniky, má na to k dispozici rozsáhlé možnosti dotazů nad systémem. Provádí inventarizaci. Vkládá nebo ruší nové jednotky. Je povolena editace výrobních čísel u jednotlivých jednotek. Nemůže ale editovat inventární čísla ani umístění jednotek v rámci budovy
Vedoucí II -
vyžaduje informace o aktuálním stavu techniky, má na to k dispozici rozsáhlé možnosti dotazů nad systémem. Provádí inventarizaci. Není povoleno vkládání nebo rušení nových jednotek. Není povolena editace výrobních čísel techniky. Může editovat inventární čísla a umístění v rámci budovy.
Uživatel -
vyžaduje informace o aktuálním stavu techniky, má na to k dispozici rozsáhlé možnosti dotazů nad systémem.
136
Administrátor - od systému získává informace o nastavení a běhu systému. Stará se o přidělování práv uživatelům, zálohování a archivaci. Tato role se v analýze příliš neprojeví a do systému se zpracovává při implementaci.
1.3 Kontextový diagram
Vedoucí I
správa budov editace dat
Vedoucí II informace editace dat
informace
EHW Sys. info správa uživatelů
Administrátor
informace archivace a rearchivace
Uživatel
Popis kontextového diagramu: elipsa – Systém EHW obdélník – aktéři systému šipka – vyznačuje datový tok
1.4 Řešitelský tým Softwarový tým EHW má celkem 7 členů. Tvoří ho tři analytici, vedoucí, dokumentátor, tester a návrhář. Část Deklarace záměru a úvodní studie Kontextový diagram Rozpočty Plán řešení Datový model Funkční model Dynamický model Moduly Uživatelské prostředí
vedoucí analytik
-
sys. anal.
anal.-op. návrhář dokum. tester
x
-
-
-
-
-
-
x x x
-
-
-
-
-
-
x -
x -
x x -
-
-
137
x x -
x x x
x x
1.5 Odhad rozpočtu na vývoj metodou COCOMO 1.5.1 Vývoj Náročnost = k * (Rozsah)n * o Čas = 2,5 * (Náročnost)m Zdroje = Náročnost / Čas Rozsah 25 tisíc zdrojových instrukcí Pak tedy Náročnost je 60,2 člověko-měsíce Čas potřebný pro řešení je 11,9 měsíce A potřebné lidské zdroje čítají 5 lidí Předpokládáme průměrný platu 20 000 na měsíc a osobu, to činí celkem: 1 200 000 Kč V našem případě půjde o variantu známého projektu což určuje koeficienty k 2,4
n 1,05
m 0,38
Určíme opravné faktory : Jméno Hodnota Popis Faktory systému RELY 1,10 DATA 1,08 CPLX 0,85 Faktory počítače TIME 1,00 STOR 1,00 VIRT 1,00 TURN 1,07 Faktory týmu ACAP 1,19
Spolehlivost Rozsah dat Složitost Časové omezení Paměťové omezení Stabilita Rychlost odezvy Znalosti a zkušenosti analytika Znalost aplikace Zkušenost programátorů Znalost virt. počítače Znalost prog. jazyka
AEXP 1,13 PCAP 1,00 VEXP 1,00 LEXP 0,95 Faktory projektu MODP 0,86 Moderní prog. metody TOOL 0,91 Použití progr. nástrojů SCED 1,00 Časový plán Souhrnný opravný faktor (o) 1,08 1.5.2 Údržba a změny
S produktem souvisí také potřeba jeho údržby a změn během provozu. M=Z*E
138
M – náklady na údržbu v člověko-měsících Z – předpokládaný koeficient změny 15% E – náklady na tvorbu v člověko-měsíců 60 Bude potřeba například 2 lidí na 4 měsíce s plným úvazkem Při 15 tis. Kč na osobu a měsíc to je 135 000 Kč Celkové náklady na vývoj systému skladového hospodářství jsou mzdy týmu a budou tedy celkem činit 1 335 000 Kč
1.6 Rozpočet na HW a SW pro běh systému Server: Výkonný počítač na kterém bude provozován SQL server. Důraz je kladen na rychlost a spolehlivost. Jsou použity disky technologie SCSI UltraWide2. Kvůli bezpečnosti jsou disky jsou spojeny do RAID 1 pole zrcadlení. Každý z disků je připojen na zvláštní kanál řadiče.
Komponent Typ Cena Typ a software Mironet Počítač 10685,- Systém: Hummer 1600-2 Procesor
Pentium III 550
15145,- Databáze:
Paměť
512MB 2 x 20 GB SCSI UW2 LVD Adaptec SCSI UW2 LVD
20850,-
Harddisk Extra Cena celkem
Jméno software
Cena
Microsoft Windows 36 867,2000 Server, 5 CL Microsoft SQL Server 52 211,7, 5 CL
41250,7554,95 484,- Cena celkem
89 078
Stanice Klientské počítače Komponent Počítač Procesor Paměť Harddisk Cena celkem
Typ
Cena
Typ software
Mironet 3000
2985,-
Systém
5260,-
Extras
Pentium Celeron 400 128 MB IDE 10GB
2545,4867,15 657,-
Cena celkem
139
Jméno software
Cena
Microsoft Windows 11 267,2000 Workstation Microsoft SQL Server 13 991,7, 5 CL
25 258,-
Celkové náklady Komponent Typ Hardware 1 x 94 Server 484,Hardware 3 x 20 Stanice 159,Software 1 x 89 Server 078,Software 3 x 25 Stanice 258,Cena celkem
Cena 154 961,-
164 852,-
319 813,-
Ceny jsou uvedeny bez DPH. Byly sestaveny podle ceníku firmy Mironet.
Harmonogram a struktura členění prací projektu Začátek projektu: Čt 1.3.01 Ukončení projektu: St 16.5.01
140
Úkoly ID
Jméno úkolu Projekt Evidence HW 1 (EHW) 2 Úvodní studie 3 Deklarace záměru
Trvání
Start
Konec
Předchůdci
Použité zdroje
Hotovo
61 days
Mon 13.3.00
Tue 16.5.00
19 days 1 day
Mon 13.3.00 Mon 13.3.00
Tue 4.4.00 Mon 13.3.00
5 days
Tue 14.3.00
Mon 20.3.00
3
2 days
Tue 21.3.00
Wed 22.3.00
4
4 days
Tue 21.3.00
Fri 24.3.00
4
Sys. Analytik;Analytik;Vedoucí Vedoucí;Analytik;Analytikoponent Návrhář;Analytik-oponent;Sys. Analytik Vedoucí
9 days
Tue 21.3.00
Fri 31.3.00
4
Analytik;Sys. Analytik
100%
1 day 3 days 33 days 18 days 19 days 5 days 1 day
Sat 1.4.00 Sun 2.4.00 Wed 5.4.00 Wed 5.4.00 Mon 10.4.00 Sat 29.4.00 Wed 3.5.00
Sys. Analytik;Analytik;Testér Vedoucí;Analytik;Sys. Analytik
100% 100% 100% 100% 100% 100% 100%
15 Úprava analytické studie
3 days
Fri 5.5.00
Sun 7.5.00
14
16 17 18 19
9 days 2 days 5 days 4 days
Mon 8.5.00 Mon 8.5.00 Wed 10.5.00 Mon 8.5.00
Tue 16.5.00 Tue 9.5.00 Sun 14.5.00 Thu 11.5.00
10 15 17 15
20 Kontrola návrhu
1 day
Mon 15.5.00
Mon 15.5.00
19;18
21 Úprava návrhu 22 Uzavření projektu
1 day 1 day
Mon 15.5.00 Tue 15.5.00
Tue 16.5.00 Tue 16.5.00
20 21
4 Průzkum a odborný článek 5 6 7 8 9 10 11 12 13 14
Návrh řešení - HW a SW požadavky Plánování,rozpočet Kontextový diagram a datový slovník Kontrola úvodní studie Úprava úvodní studie Analýza Datový model Funkční model Dynamický model Kontrola analýzy
Návrh Definice modulů GUI Návrh impl. a akcept. testů
100%
Sat 1.4.00 7 Tue 4.4.00 8 Sun 7.5.00 2 Sat 22.4.00 Fri 28.4.00 11SS+5 days Wed 3.5.00 12 Thu 4.5.00 13
Analytik;Návrhář Sys. Analytik;Analytik-oponent Sys. Analytik;Analytik-oponent Sys. Analytik;Analytik;Testér Dokumentátor;Analytik;Sys. Analytik Návrhář;Dokumentátor Návrhář;Dokumentátor Testér Návrhář;Testér;Dokumentátor;V edoucí Návrhář;Testér;Dokumentátor Vedoucí
100% 100% 100% 100% 100%
100% 100% 100% 100% 100% 100% 100% 100%
Struktura členění prací Projekt evidence HW 1. Úvodní studie
2. Analýza
3. Návrh
5. Implementace
4. Konzultace se zadavatelem 6. Nasazení a testy
1. Úvodní studie Získání informací od zadavatele.Definování cíle projektu. Připravení rozpočtu a plánu akce za účelem zjištění proveditelnosti projektu. Hrubý nástin funkcí systému, uživatelských rolí a jeho požadavků. Zpracování rozpočtu na techniku jíž bude potřeba nasadit pro běh systému.
141
2. Analýza Podrobná analýza projektu. Vytvoření datové,funkční a dynamické analytické studie jako co možná nejpodrobnějšího popisu dat, funkcí(operací) a chování systému při zpracovávání jednotlivých úkolů. Vytvoření podkladů pro implementaci 3. Návrh Návrh členění systému do modulů pro implementaci. Dále návrh grafického uživatelského rozhraní a akceptačních testů, kterými bude nutno projít pro dokončení systému a ověření funkčnosti. 4. Konzultace se zadavatelem V této fázi je už podrobně problém zanalyzován a máme již i představu o vzhledu systému. Je proto vhodné předvést dosavadní práci zadavateli, osvětlit mu nabízené funkce a ověřit si zda bude takto systém vyhovovat (i přímým uživatelům) 5. Implementace Část projektu vlastního kódování modulů jejich testů a spojování. Na konci této etapy by měl systém plně funkční a připraven k nasazení. 6. Nasazení a testy Po instalaci u uživatele proběhnete testovací a školící fáze během níž jsou uživatelé podrobně seznámeni s funkcemi a fungováním systému a zároveň jsou provedeny testu na živých datech souběžné s původním systémem. V této fázi je systém doladěn a nastaven, tedy případně provedeny menší úpravy. Během dalšího roku se ovšem počítá s dalšími i rozsáhlejšími úpravami tak jak se budou uživatelé seznamovat se systémem a požadovat nové nebo změnu stávajících funkcí.
1.8 Definování rizik a návrh techniky jejich řízení Obecně možná rizika: · Rizika velikosti produktu - Pracovníci již mají větší zkušenosti s tvorbou podobného SW. Z předchozích zkušeností vychází velikost produktu jako optimální. Tvorba rizik v této kategorii je minimální. · Rizika obchodního dopadu - Firma není závislá pouze na tomto produktu. Dodací lhůta je rozumná, avšak při pozdním dodání nebo zjištěných chybách hrozí penále. · Rizika týkající se zákazníka: Se zákazníkem se ještě nepracovalo. Podle dodatečných zjištění se zdá být spolehlivý a je připraven účastnit se pravidelných inspekcí. · Procesní rizika - Vedení společnosti využívá standardizaci procesu softwarového vývoje. Pravidelně se provádějí revize požadavků, návrhu, kódu i testování doposud vytvořeného softwaru na různých úrovních. Pravidelně se také vše dokumentuje včetně nalezených chyb a použitých zdrojů. Výraznější rizika mohou vzniknout pouze při změnách požadavků zákazníka. · Otázky techniky – Většina kódu bude napsána ve vyšším programovacím jazyce a přepokládá se využití softwarové nástroje pro podporu plánování a řízení,řízení konfigurací a změn, analýzy softwaru a procesu návrhu, testování a tvorbu dokumentace.
142
· ·
·
·
Technologická rizika - Předpokládáme práci na ověřeném softwaru a hardwaru. Nepředpokládá se použití žádných nekonvenčních metod vývoje softwaru ani požadavky na speciální uživatelské rozhraní. Rizika vývojového prostředí - Jsou k dispozici všechny nutné prostředky na návrh a realizaci testování softwarového produktu včetně nástroje pro řízení softwarového procesu. S velkou většinou z nich se již pracovalo na dřívějších projektech. Zde by neměly vznikat žádná velká rizika. Rizika spojená s velikostí týmu a jeho zkušeností - Pracovníci mají odpovídající zkušenosti. Nejdůležitější pracovníci mají trvalý pracovní poměr. Pro případ nemoci nebo jiné neočekávané události jsou nasmlouváni externisté, bez trvalého pracovního poměru. Rizikové komponenty: Počítá se s případnými menšími změnami, opravami nebo vylepšeními, na které už se předem v harmonogramu vyčlenil určitý čas. Realizovaný produkt by měl jít snadno opravovat a zlepšovat podle nároků zákazníka.
Tabulka rizik Kategorie Pravděp Dopad Řešení Rizika . zákazník změní procesní 80 % 2 dohoda se požadavky zákazníkem a úprava specifikace průběžné předvádění Odklon od požadavků procesní 10% 2 Průběžné předvádění fluktuace členů týmu penále při pozdním odevzdání nízký odhad velikosti
Tým
Vedoucí Testér Vedoucí
projektový tým obchodní
40 %
3
záložní pracovníci
30 %
2
velikost produktu projektový tým
35 %
3
10 %
2
Zaměstnání více lidí, použití časové rezervy nebo dohoda se zákazníkem Více lidí nebo její lepší rozdělení Záložní pracovníci Pravidelné schůze
Testér, Vedoucí Vedoucí Testér
-
-
-
-
10 %
3
5%
3
nedorozumění a nebo špatná komunikace mezi členy týmu méně významná rizika změny, úpravy, rizikové softwarová a komponent hardwarová podpora y vada nebo chyba HW technika nebo SW, či případná ztráta části dat
Řešitel
Rychlé a správné a včasné reakce na požadavky Zálohování data a hardware, tvorba verzí Záložní pracovníci s většími zkušenostmi
nedostatečné školení vývojové 3% 3 práce ve vývojovém prostředí prostředí Dopad: 1 - katastrofický, 2 - kritický, 3 - marginální, 4 - zanedbatelný
143
Tým
Programátoři Programátoři a Testér Vedoucí Testér
Monitorování faktorů, které mohou ovlivnit pravděpodobnost rizika: · reakce na změny projektu v závislosti na požadavcích zákazníka · směr změn v projektu · výpadků v zaměstnání (nemoc nebo jiné neočekávané události) · dodržování časového plánu a úpravy v něm · postoj členů týmu v závislosti na tlacích v projektu · vzájemné osobní vztahy mezi členy týmu · zkušenosti při případných vzniklých problémech · možnosti zaměstnání uvnitř a mimo organizaci a potenciální platové problémy · funkčnost SW a HW · požadavky zákazníka po dodání produktu Zmírnění rizika: ·
společně s týmem hledat příčiny fluktuace (např. špatné pracovní podmínky, nízký plat, konkurující trh práce)
·
když projekt začne, předpokládat fluktuaci a připravit postupy k zajištění kontinuity
·
zajistit šíření všech informací o vývoji projektu v rámci týmu
·
stanovit standardy pro vytváření dokumentace a zabezpečit, aby byla produkována včas
·
zajistit vzájemné kontroly práce tak, aby více než jedna osoba byla obeznámena s prací
·
určit záložní členy týmu
·
pravidelně zálohovat data i dokumentaci a při výpadcích mít připravený náhradní HW , testy provádět na více strojích
·
pravidelné konzultace k zabránění odklonu od požadavků
Analýza 2.1 Datový E-R model 2.2 Funkční model 2.3 Dynamický model 2.4 Harmonogram a struktura členění analýzy
Návrh uživatelského rozhraní (GUI) 3.1 Dokumentace návrhu
144
3.2 GUI 3.3 Návrh testů Při řešení zadaného problému je počítáno s prováděním pravidelných kontrol a testů každé fáze projektu, po čemž ještě obvykle následují případné změny. To odpovídá vodopádovému modelu řešení, který jsem zvolil zejména pro jeho jednoduchost. Hlavní nevýhodou tohoto řešení je, že se již nevrací k uzavřeným částem projektu, takže je nutné pečlivým testováním vyloučit všechny možné problémy už v rámci dané fáze projektu. V úvodní a analytické části je na kontrolu a úpravy vymezeni 3 a 5 (respektive 5 a 15) dní, což se sice může zdát jako poněkud přehnaná doba, ale jejím důvodem je fakt, že včasné odstranění případných problémů a nejasností zmenšuje riziko vzniku mnohem větších problémů v pozdějších fázích projektu. Po této kontrolní fázi, spojené zároveň s následnými změnami v projektu, následuje konzultace s jeho zadavatelem, během níž je zejména nutné se zadavatelem prodiskutovat námi navrhované řešení, aby bylo dosaženo co nejlepší shody požadavků s návrhem. Předpokládáme, že zadavatel v této fázi přijde ještě s novými požadavky na projekt, případně bude upřesňovat požadavky původní, a tyto změny bude potřeba zapracovat do již provedené analýzy projektu ještě před jeho implementační fází. V implementační fázi jsou jednotlivé části projektu testovány okamžitě během jejich vytváření, aby se tak předcházelo případným problémům při změnách na ně navazujících částí. Následně jsou ještě jednou všechny moduly důkladně otestovány než dojde k integraci. Po integraci je provedena sada testů prověřujících systém jako celek, tedy zejména vzájemnou spolupráci jeho jednotlivých částí. K těmto testům je vhodné získat od zadavatele "reálná" data, aby tak provádění testů co nejvěrněji simulovala reálnou zátěž. Po této fázi následuje další konzultace se zadavatelem, během které je předveden v podstatě hotový produkt a zejména jeho bezchybná funkce na testovaných datech. Zadavatel zde má prakticky poslední možnost nějakým výraznějším způsobem ovlivnit výsledný produkt, aby plně odpovídal jeho představám. Pokud zadavatel vznese nějaké nové požadavky, následuje fáze zapracování těchto změn a nových testů před zkušebním spuštěním systému. Zde bude proveden akceptační test, během něhož zadavatel poskytne "ostrá" data, na kterých bude simulován provoz systému za předem určené časové období a jeho výstupy budou podrobeny detailní analýze a porovnány s požadavky zadavatele. Poslední fází projektu je instalace systému u zadavatele, zaškolení obsluhy a zkušební provoz systému již v reálných podmínkách. Pro případ, že se během tohoto zkušebního provozu vyskytnou ještě nějaké problémy, nebo zadavatel přijde s požadavky na další dodatečné úpravy, máme ještě několikadenní rezervu pro případné úpravy systému a jeho následné testy. 1) Validace požadavků: 6 dnů a) validace potřeb uživatele b) prověření konzistentnosti požadavků c) prověření úplnosti požadavků d) reálnost požadavků
145
2) Testování analýzy: 5 + 13 dnů - ověření, zda specifikace problému splňuje požadavky zadavatele a) ověření, zda navržené uživatelské role splňují požadavky zákazníka b) ověření datového modelu - ověření použitelnosti datového modelu s testovacími daty, navrženými podle datového slovníku c) ověření funkčního modelu - ověření úplnosti a korektnosti navrženého funkčního modelu d) ověření funkčnosti - ověření datového modelu a funkčního modelu jako celku na experimentálních datech 3) Testování modulů během kódování: 50 dnů - závěrečné kompletní testování před předvedením zadavateli, ověření vzájemné spolupráce všech implementovaných modulů na "skutečných" datech, odpovídajících reálnému provozu systému a) revize a optimalizace kódu programu b) vytvoření testovacích dat a metody testování - od zadavatele získáme "ostrá" data, která bude systém používat, tvorba testovacích příkladů a dokumentace b) provedení testů - testování všech nezávislých větví a cest programu, testování mezních hodnot systému, opakované testování opravených chyb 4) Závěrečné testy po instalaci systému: 10 dnů - testy prováděné po instalaci hardwaru a softwaru a) testy hardwaru - ověření funkčnosti nainstalovaného hardwaru b) testy softwaru - ověření funkčnosti nainstalovaného softwaru c) testy spolupráce - ověření vzájemné spolupráce mezi hardwarem a softwarem
146
Příloha IV Projekt Inteligentní domácnost Tento dokument obsahuje pokračování projektu z SI1, konkrétně dokumentaci manažera kvality.
Plán kontrol: Název kontroly / týden Kontrola úvodní studie Kontrola odborného článku Kontrola datového modelu Kontrola stavového diagramu Kontrola procesního diagramu Kontrola analýzy Kontrola uživatelského rozhraní Kontrola dokumentace
1
2 3
4 5
6 7
8
9 10 11 12
Součástí plánu kontrol jsou i jejich výsledky. V případě nepříznivého výsledku některé kontroly je nutné naplánovat její opakování po odstranění nedostatku.
Plán testů softwaru: Pro následující testy je nutno vytvořit zkušební domácnost se skutečnými přístroji. Je nutno zkoušet různé kombinace přístrojů a jejich připojení.
Jednotkový test - white box testing Název testu / týden
21 22 23 24 25 26 27 28 29 30 31 32
Test systému 1. 2. 3. 4. 5.
ověření úplnosti tabulek a atributů kontrola integritních omezení na tabulkách a mezi tabulkami test zabezpečení přístupu k tabulkám, autentikace a autorizace kontrola uložených procedur a triggerů ošetření chybových stavů a výjimek
Test rozhraní 1. 2.
kontrola dostupnosti ovládaných zařízení v systému test chybových hlášení
147
Test logické hladiny 1.
kontrola vhodné reprezentace dat pomocí datových typů kontrola zapouzdření dat ověření přítomnosti všech metod kontrola návratových hodnot metod ověření viditelnosti všech tříd a metod v modulu test okrajových podmínek v metodách
1. 2. 3. 4. 5.
Test uživatelského rozhraní 1. 2. 3.
ověření přítomnost všech formulářů test správného vzájemného volání formulářů kontrola správného zobrazení nabídek a formulářových polí test volání funkcí ve formulářích kontrola čitelnosti textu test chybových hlášení
4. 5. 6.
14.5
Integrační test - metoda zdola nahoru
Název testu / týden
21 22 23 24 25 26 27 28 29 30 31 32
Test vzdáleného přístupu 1. 2. 3.
kontrola otevření spojení volání uložených procedur, manipulace s daty kontrola uzavření spojení
test propojení datového konektoru k logické hladině 1. 2. 3.
volání datového konektoru pomocí metod tříd manipulace s daty pomocí metod tříd test chybových situací a okrajových podmínek
test napojení prezentační hladiny na logickou hladinu 1. 2. 3. 4.
volání metod tříd z uživatelského rozhraní test předání dat do prezentační hladiny test zadávání dat kontrola zobrazení chybových hlášení z logické hladiny
14.6
Validační test - alfa i beta testování
Název testu / týden
29 30 31 32 33 34 35 36 37 38 39 40
testy z pohledu uživatele 1. 2. 3. 4.
hledání ve znalostní bázi zadání požadavku zobrazení uživatelových požadavků poslání emailu řešiteli
5.
kontrola oznámení
testy z pohledu koordinátora 1. 2. 3. 4. 5. 6. 7.
přijmutí požadavku přiřazení požadavku předání požadavky výpis požadavků kontrola oznámení zadávání, úpravy a odstranění řešitelů zobrazení statistik
testy z pohledu řešitele 1. 2. 3. 4.
otevření požadavku dokumentování řešení požadavku odložení a uzavření požadavku spoluúčast řešitelů
5.
poslání emailu uživateli
testy z pohledu vydavatele
148
1. 2.
obdržení řešení požadavku vydání článku
3.
úpravy článků
testy z pohledu administrátora 1. 2.
přímé napojení do systému plán a funkčnost zálohování
3.
údržba koordinátorů
Systémový test Název testu / týden
29 30 31 32 33 34 35 36 37 38 39 40
recovery testing 1. 2.
test správného nastartování a vypnutí systému náhodný restart
3.
simulace poruchy čidel
security testing 1. 2. 3. 4. 5.
anonymní přístup do systému přístup do systému z okolního prostředí intranetu přihlášení autorizovaných uživatelů zadávání dat neoprávněnými uživateli zabezpečení podkladových tabulek v SŘBD
stress testing 1. 2.
vložení nadměrného množství dat do systému nadměrná frekvence přístupu uživatelů skrz prezentační hladinu
Analýza rizik ·
Rizika obchodního dopadu Firma není existenčně závislá na tomto produktu. Jedná se o produkt, který firma vyvíjí a následn ě jej bude jako hotový nabízet. Zůstává riziko nezájmu o produkt.
·
Rizika velikosti produktu Pracovníci mají zkušenosti s tvorbou informačního systému podobného rozsahu. Rizika této kategorie jsou minimální.
·
Procesní rizika Pravidelně se provádějí revize požadavků, návrhu, kódu i testování doposud vytvořeného informačního systému na různých úrovních. Vše se také pravidelně dokumentuje včetně nalezených a opravených chyb. Využívají se prostředky standardizace procesu softwarového vývoje. Výraznější rizika mohou vzniknout pouze při zásadních změnách v požadavcích zákazníka.
·
Otázky techniky Kód bude napsán ve vyšším programovacím jazyce. Přepokládá se využití softwarových nástrojů pro podporu plánování a řízení, analýzy softwaru a procesu návrhu, řízení verzí, testování a tvorbu dokumentace.
·
Technologická rizika Práce bude probíhat na ověřeném softwaru a hardwaru. Nepředpokládají se žádná nestandardní řešení. Ověřená jsou i ovládaná zařízení a jejich připojení.
·
Rizika vývojového prostředí Jsou k dispozici všechny nutné prostředky pro návrh a realizaci testování softwarového produktu včetně
149
nástroje pro řízení softwarového procesu. Společnost má pro případ nouze uzavřenu smlouvu s dodavatelem vývojového software o technické podpoře. ·
Rizika spojená s velikostí týmu a jeho zkušeností Pracovníci mají zkušenosti s prací v týmu. Klíčoví pracovníci mají trvalý pracovní poměr. Pro případ nemoci nebo jiné neočekávané události jsou nasmlouváni externisté bez trvalého pracovního poměru.
·
Rizika komponent Počítá se s drobnými změnami. Harmonogram byl vytvořen s ohledem na možnost vzniku drobných změn.
Zmírnění rizik: ·
společně s týmem hledat příčiny fluktuace (špatné pracovní podmínky, nízký plat, konkurující trh práce) a pokusit se je odstranit
·
předpokládat fluktuaci zaměstnanců během vývoje informačního systému a připravit se k zajištění kontinuity vývoje
14.7 zajistit šíření všech informací o vývoji projektu v rámci týmu ·
stanovit standardy pro vytváření dokumentace
·
zajistit vzájemné kontroly práce tak, aby byla s prací seznámena více než jedna osoba
·
určit záložní členy týmu
·
denně zálohovat data i dokumentaci
·
pro případ selhání mít připravený náhradní hardware
·
testy provádět na více strojích
·
pravidelná sezení k zabránění odklonu od požadavku
150
