Obsah 1 Ú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 2 Koncepty řízení SW projektů...12 2.1 Základní pojmy...12 2.2 Zralost organizace...12 2.3 Koncepty řízení projektu...13 3 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 4 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 5 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 6 Ří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 7 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 8 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í. 1950 nástroje HW SI techniky strojový kód elektronky 2000 assembler jazyky 3. generace jazyky 4. generace jazyky AI objektové programování tranzistory integrované obvody paralelní procesy VLSI strukturované programování funkcionální dekompozice strukturální analýza datová analýza objektová analýza 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
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í Koupit? Přebudovat? Znovupoužít? Navrhnout a realizovat? Vazby mezi jednotlivými aktivitami jsou uvedeny v obrázku 1.1 projekt * aktivity produkt systém je vytvořen spotřebovává * * úkol * účastník zdroje model čas 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 Koncepty řízení SW projektů 2.1 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<n. Vznikají neformální týmy a ad hoc vedoucí týmu. Koordinaci řídí softwarový manažer. 3. n osob organizovaných do t týmů, každý má jeden či více úkolů, pracují na jednom projektu. Koordinaci provádí projektový manažer. 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 DD Týmové struktura CD Týmová struktura CC složitost řešeného problému velikost výsledného programu doba trvání týmu (životnost týmu) stupeň modularizace problému požadovaná kvalita a spolehlivost budovaného systému vysoká X nízká X X velká X X malá X krátká X X dlouhá X vysoká X X nízká X vysoká X X nízká X tvrdost předávacích termínů vysoká nízká X X X požadovaný stupeň vnitřní komunikativnosti týmu (sociability) vysoká X nízká X X Jiná klasifikace rozlišuje pro organizaci týmů čtyři různá paradigmata: Uzavřené paradigma Náhodné paradigma Otevřené paradigma Synchronní paradigma struktura s tradiční hierarchií autorit (podobné CC) uvolněná struktura, závislá na individualitách 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 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 Existují normy, procedury, kuchařky jak co udělat.. Máme CASE, nejnovější počítače. Jestliže "nestíháme", dodáme více programátorů. skutečnost Jsou nepoužitelné, nejsou kompletní, neřeší naše problémy.. Počítače nejsou rozhodující, i nejnovější CASE neřeší vše Neumí, nejsou seznámeni s problémem, musíme je školit. 19
Zákaznické mýty mýtus Obecné zadání stačí, aby se začal psát program Požadavky se průběžně mění, ale SW je přizpůsobivý skutečnost 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žší.. 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 Jestliže napíšeme program a ten "chodí", je hotovo Dokud program "neběží" nezjistím jeho kvalitu Jediný produkt úspěšného projektu je funkční program skutečnost Čí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 Existují metody formální evaluace kvality Je to jen část výsledného produktu. Musíme doplnit dokumentaci, testování, údržbu, 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 kódování testování test jednotky analýza požadavky návrh dat návrh integrační validační test test test test plánování testů testování vyhodnocení testů milníky Obr. 3.2 21
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 krok 1 aktivita 1.1 krok 2 aktivita 1.2.. projekt fáze 2 krok 1 aktivita 2.1 krok 2 aktivita 2.2 fáze 3 krok 1 krok 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 násobek vstupního bodu součin 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 Výběrová hdnota TSS pro úkol 2,6 Postup výpočtu výběrové hodnoty (TSS - Task set selector value): 1. stanov hodnotu každého kritéria (0-5) 25