Několik poznámek k projektovému řízení

1. Několik poznámek k projektovému řízení Akceptace, projektové metriky a odhady

2. Akceptace • Jeden z procesů projektového řízení. Jde o odsouhlasení výstupů projektu ve smyslu uzavření závazku ze smluvního plnění, výsledkem je akceptační protokol. • Hlavní principy akceptace jasně definují okamžik splnění závazku vůči zákazníkovi, neakceptovaná práce se jeví jako závazek vůči zákazníkovi. • Výstupem je dokument Protokol o převzetí plnění, kde zákazník jednoznačně potvrzuje smluvní plnění. • Jednotlivé úkoly procesu Akceptace: • Příprava akceptace • Převzetí plnění do akceptační procedury • Akceptační procedura a zpráva o akceptaci • Oponentura výsledků akceptace a akceptační protokol

3. Akceptace • Tým akceptace je v rámci jednotlivých fází projektu podpůrným orgánem, který: • Připravuje akceptační kriteria. • Posuzuje a přebírá výstupy jednotlivých fází a připravuje podklady pro rozhodnutí o akceptaci těchto výsledků. • Připravuje a provádí akceptační proceduru. • Členy akceptačního týmu jsou zástupci obou smluvních stran. • Sepisují se akceptační kritéria, tak aby nemohlo dojít na konci projektu k rozdílné interpretaci mezi zadavatelem a projektovým manažerem (lze je v průběhu rozdělit do jednotlivých milníků projektu, které mohou pomoci s kontrolou, že projekt jde správným směrem). Akceptační protokol, který je připravován již na začátku projektu, jednoznačně definuje způsob posouzení toho, zda výsledek prací je, či není pro zadavatele přijatelný. Pravidlem akceptace je „ Nepředávej nic co nebylo požadováno“.

4. Akceptace • Akceptace začíná zahájením projektu, je důležité aby už na začátku projektu bylo známo, jaká omezení jsou v rámci projektu akceptovatelná. • V průběhu prací může dojít k upřesňování akceptačních kritérií, ale každá byť nepatrná změna musí být realizována na základě změnového řízení projektu a odsouhlasena všemi stranami. • Pokud nejsme schopni na začátku projektu stanovit jasná akceptační kritéria, musíme projekt rozdělit a pracovat na dílčí části s jasně definovanými akceptačními kritérii. • Akceptační protokol by měl při jeho přijetí vyhodnotit nejlépe nezávislý dohled.

5. Nejdůležitější výstupy řízení projektu • Smlouva • Základní dokument projektu viz dále • Plán projektu • Interní objednávka kapacit • Rozpočet projektu • Zpráva o stavu projektu • Protokoly o převzetí plnění do akceptační procedury • Protokoly o převzetí plnění • Zápisy z jednání Řídící komise (vrcholný rozhodovací orgán) • Statistika projektu (postup a kvantitativní charakteristiky projektu) • Znalostní báze projektu (přehled souborů v adresáři – dokumentace projektu, statistika, číslo projektu, název, datum zahájení, ukončení, ředitel, účetní, typ projektu – malý, velký – studie, implementace, vývoj, údržba, klíčová slova projektu)

6. Základní dokument projektu • Navazuje a rozpracovává smlouvu, schvaluje jej řídící komise projektu a definuje: • Výstupy a rozsah projektu • Kritéria úspěchu • Rizika • Rozpočet • Způsob řízení • Kapitoly dokumentu • Kapitola Úvod (účel a vymezení pojmů), kapitola Cíle (cíle, přínosy výstupů projektu, kapitola Rozsah projektu (předmět plnění, pokryté procesy, data, požadavky, související projekty, kritické faktory úspěchu, rizika), kapitola Řízení projektu (odkazy na pravidla a metodiky, role, orgány, pravidla pro sdílení informací, harmonogram, rozpočet), kapitola Přílohy, kapitola Podpisy, kapitola Přehled změn.

7. Zadávání úkolů a evidence rozpracovanosti Zadávání úkolů (Všem účastníkům projektu musí být jasné co, jak, v jakém termínu a s jakou pracností mají dělat). Jde o písemné zadání: • ID úkolu • Smysl úkolu • Plánovaná pracnost úkolu • Datum dokončení • Popis úkolu • Popis výstupu V procesu Evidence rozpracovanosti musí účastníci projektu vykazovat svou práci v rámci • Timesheets • Detailní evidence pracnosti (po hodinách), je to projektově závislá evidence, nikdy se nepoužívá k hodnocení pracovníků, ale jen a pouze k evidenci skutečně spotřebovaného času • Sběr údajů pro metriky a statistiky projektu

8. Informování o stavu projektu • Způsob informování o projektu určuje Zřizovatel • Obvykle dělá vedoucí projektu následující reporty: • Směrem k řídící komisi • Směrem ke zřizovateli • Text - hlavní události, rizika, návrhy k řešení • Čísla – stav rozpracovanosti a čerpání zdrojů ve fázích, sledování rozpočtu a porovnání s odhadem a s reálným čerpáním.

9. Techniky odhadování pracnosti http://www.odbornecasopisy.cz/index.php?id_document=37927 • Východiska • Pracnost (člověkohodiny) • Trojúhelník řízení (price boxing, time boxing, output boxing) kvalita, čas, náklady. • Přístupy a metodiky odhadu obecně • Expertní odhady • Porovnání • Statistiky (sledování průběhu) • Metriky • Systém proměnných a jejich hodnot používaných pro odhady a měření pracnosti.

10. Projektové metriky Slouží k taktickým účelům (odhady času, nákladů, k monitorování projektu a k jeho vyhodnocování) Model projektové metriky obsahuje: • Vstupy: měří se zdroje (lidé, zařízení..) potřebné pro práci • Výstupy: měří se předané výstupy nebo produkty vytvořené během projektu • Výsledky: měří se efektivita (využití) výstupů (může se použít k měření procesu i projektu, u projektu lze použít postupně pro každou vývojovou fázi) Měření softwaru • přímá měření - počet řádek kódu (LOC), rychlost výpočtu, velikost paměti, počet chyb za určitou dobu … • nepřímá měření - funkčnost, kvalita, složitost, pracnost, spolehlivost, schopnost údržby,…

11. Projektové metriky Metriky orientované na velikost (size-oriented) jsou metriky odvozené z velikosti produktu a normalizované faktorem kvality či produktivity. Statistika projektů: • podle počtu řádek kódu (LOC Line of Code) • pracnost • cena • počet stran dokumentace • počet chyb • počet defektů Počet výskytů můžeme odvodit: • počet chyb na KLOC (1000 LOC) • počet defektů na KLOC • cena LOC • počet stran dokumentace na KLOC • počet chyb za člověkoměsíc • počet LOC za člověkoměsíc • cena stránky dokumentace  

12. Projektové metriky http://cs.felk.cvut.cz/~richta/www-si2/WS3.HTML Funkčně orientované metriky FP (Function Point) funkční bod (jednice) • (empirický vztah mezi spočitatelným měřením informační domény a odhadem složitosti softwaru) • 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 • 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+ 10e3)=______       • TOTAL = 

13. Projektové metriky • FP = TOTAL x (0,65+0,01 x suma (Fi)) • Fimají hodnotu 0-5 pro i = 1..14 (Fisložitost zpracování) • hodnoty: 0 nemá vliv, 1 nahodilý, 2 mírný, 3 průměrný, 4 významný, 5 podstatný vliv • Požaduje systém zálohování a obnovu? • Jsou požadovány datové přenosy? • Obsahuje funkce distribuovaného zpracování? • Je požadován kritický výkon? • Bude systém pracovat za silného provozu? • Požaduje systém přímý vstup dat? • Požadují vstupní transakce přímé vstupy dat prostřednictvím více obrazovek nebo operací? • Jsou hlavní soubory aktualizovány přímo? • Jsou vstupy, výstupy, soubory a dotazy složité? • Je složité vnitřní zpracování? • Je kód navržen pro opakované použití? • Jsou v návrhu zahrnuty konverze a instalace? • Je systém navržen pro vícenásobné instalace na různých místech? • Je aplikace navržena tak, aby usnadnila změny a snadné uživatelské ovládání?

14. Projektové metriky Rozšířená funkčně orientovaná metrika 3D Function Point(Whitmire, S.A., An Introduction to 3D Function Pionts, Software Development, April 1995) 3 dimenze: • datová (A až E stejné jako FP viz výše ) • funkční(F počet vnitřních operací potřebných k transformaci vstupních dat na výstupní) • ří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=  

15. Metrika Object Based • Slouží k přesnému odhadu a měření pracnosti jednotlivých činností na nízké hierarchické úrovni WBS (work breakdown structure) a jako základ měření rozpracovanosti produktů. Jejím použitím se dostává plánování, sledování a vyhodnocování pracnosti jednotlivých činností a jejich produktů pod reálnou kontrolu řízení projektu, základním principem je vzorec: Pracnost = počet objektů daného typu X průměrná pracnost potřebná k vytvoření jednoho objektu Pozn.: (největší know how je vybrat vhodné objekty měření) • Typickým příkladem objektů jsou (analytický model, datová entita, DB tabulka, proces, programová komponenta, okno uživatelského rozhraní, nastavená transakce aplikačního software, test, vyškolený uživatel, …) • Nástroj Excel slouží pro výpočet metriky (pro každý typ objektu definuj proměnné: počet výskytů objektu (specifikovaný nebo odhadnutý) a odhad (statistická zkušenost) doby pracnosti vytvoření jednoho objektu • Pro každý výskyt objektu se eviduje • Plánovaná odchylka, rozpracovanost a výsledná spotřebovaná pracnost • Kromě tabulek v Excelu lze vytvářet i sofistikované modely závislé na charakteristikách a složitosti objektu.

16. Metrika WAVE • Metoda váženého průměru slouží k odhadu pracnosti resp. trvání projektu, vážený průměr je metoda vhodná pro počáteční fáze projektu • WAVE se počítá na základě kombinace různých odhadů jednoho projektu (je to velice snadná metoda a dobře se kombinuje s týmovým odhadem, obecně existuje více variant vzorců pro výpočet). • Proměnné: • BC = optimistický odhad, ML = realistický odhad, WC = pesimistický odhad Vzorce: • M (výsledná hodnota) = (BC+4ML+WC)/6 • S (standardní odchylka) = (WC-BC)/6 • D (spodní hodnota intervalu rozptylu) = M-1,96*S • E (horní hodnota intervalu rozptylu) = M+1,96*S Platí • Je 95% pravděpodobnost, že výsledek bude v intervalu (D;E) • S by neměla být větší než M/20 (tzv. pravidlo palce) jinak je třeba odhad zpřesňovat zpodrobňováním rozkladu činností.

17. Metrika WAVE • Platí pravidlo, že s nižší zvolenou úrovní podrobnosti • Se zvyšuje náročnost odhadu • Roste znalost potřebná k odhadům jednotlivých položek • Roste pravděpodobnost správnosti (tj. reálnost) odhadu. • Pro ostatní úrovně se předpokládá, že: • Vyšší úrovně budou dopočítány agregací • A nižší úrovně tzv. rozvržením • Právě pro tyto dodatečné výpočty je třeba definovat pravidla Pozn. Metrika Rychlý odhad • Využívá se na počátku projektu nebo fáze pro rychlý expertní odhad, u odhadu ceny.

18. Faktory ovlivňující produktivitu softwaru • Lidský faktor (velikost a zkušenosti firmy) • Faktor problému (složitost problému, počet změn v návrhu omezení a požadavků) • Faktor procesu (techniky analýzy a návrhu, jazyk a CASE, techniky kontroly) • Faktor produktu (chování a spolehlivost systému) • Faktor zdrojů (dostupnost CASE nástrojů, HW a SW zdrojů)

19. Metriky kvality softwaru • Správnost(correctness) - nejčastěji počet defektů na KLOC • Udržovatelnost (maintainability) - snadnost, s níž může být program opraven, když se vyskytne chyba, upraven, změní-li se prostředí, zdokonalen, rozhodne-li se zákazník upravit požadavky. • Integrita - odolnost vůči náhodným nebo záměrným útokům z vnějšího prostředí (viry, hackers). Pozn. : 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ů • Užitečnost(usebility) - je snaha změřit "uživatelskou přívětivost". Čtyři charakteristiky uživatelské přívětivosti: • fyzická a intelektuální dovednost nutná pro zvládnutí systému • čas potřebný na to, aby uživatel byl mírně zdatný v ovládání systému • vzrůst produktivity vzhledem k systému, který produkt nahrazuje, jestliže je uživatel mírně zdatný • subjektivní ocenění uživatelů (dotazníkem)

20. Opak kvality • Omyl (error ) - přehlédnutí, omyl nebo špatné designové rozhodnutí programátora; • Důsledkem je • Defekt (defect, též fault či bug ) • Závada, nedostatek ve zdrojovém kódu dodaného produktu • Důsledkem může být • Chybový stav(run-time fault ) - jiný než očekávaný (správný) run-time stav nebo výstup (sub)systému • Selhání (failure ) - neschopnost systému nebo jeho části vykonávat požadované funkce v požadovaných výkonnostních limitech; pozorovatelné navenek.

21. Jednou vzniklá chyba způsobí řetězovou reakci Model zesilování defektu (IBM 1981) Čím později je chyba odhalena, tím dražší je náprava i relativní cena pro odstranění chyby. Prevence je vždycky lepší

22. Způsoby zajištění kvality • Preventivní techniky • Cíl: zabránit vzniku event. dalšímu šíření chyby • „Racionální proces“ a „best practices“ • Kontroly a měření meziproduktů • Častější v úvodních fázích • Detekční a opravné techniky • Cíl: najít a opravit již existující chybu • Testování a ladění • Typické v koncových fázích („výstupní kontrola“)

23. Způsoby zajištění kvality • Kontroly • Prověření meziproduktu nezávislým oponentem dříve než se z něj začne vycházet v další práci • Technická oponentura • Strukturované procházení • Čtení kódu • Párové programování • Měření • Kvantitativní ukazatele pomáhají najít slabiny kvality • Přesnost a dokazatelnost, možnost statistik • GQM přístup (globální management jakosti, GQM = Global Quality Management), FURPS

24. Technická oponentura • Též Faganovská inspekce (Fagan, IBM 1976) • Skupinová technika (využití diverzity pohledů, cca 4-7 lidí) • Cíl: odhalit chyby v návrhu/kódu, sledování standardů, vzdělávání • Ne: dělat potíže autorovi (neúčast vedení), hledat nápravu chyb • Role ve skupině • moderátor – řídí diskusi • průvodce – předkládá dílo (není autor) • autor – vysvětluje nejasnosti • zapisovatel – zaznamenává nalezené problémy • oponenti – hledají chyby, obvykle podle seznamů otázek

25. Technická oponentura • Příprava • Distribuce díla (moderátor), projití a hledání problémů (oponenti) • několik dní předem, cca 2h práce • Schůzka • sekvenční procházení díla (průvodce či moderátor) • vznášení připomínek • zapisování nálezů (chyb a otevřených otázek) • nejvýše 2 hodiny • nepřipouštět dlouhé diskuse, řešení chyb (moderátor) • možná následná schůzka pro vyjasnění otázek • Závěry • verdikt: v pořádku / drobné chyby / nutné přepracování / nová oponentura • autor odstraní chyby dle nálezů, moderátor zkontroluje • dokument „Nálezy oponentury“

26. Technická oponentura • Přínosy • použitelné ve všech fázích životního cyklu • zejména v analýze a návrhu, kdy neexistují strojovězpracovatelné artefakty • velmi dobrá detekce chyb (až 75%) • některé studie uvádí 10-100x nižší výsledný počet chyb při používání inspekcí • většina chyb (až 60%) nalezena před testováním • výsledkem jsou nižší náklady na vývoj a vyšší produktivita • úspora 40-70% nákladů díky levnější opravě chyb v dřívějších fázích cyklu • ze studií IBM (60 projektů) plyne až o 35% vyšší DSLOC při použití inspekcí • Nároky • náročné na čas – nejde automatizovat • podle IBM optimální rychlost procházení cca 60-80 SLOC / hod • je třeba zkušenost • důraz na zaškolení lidí, zejména moderátora • účinnost podle pořadí inspekce: č.1: 15%, č.2: 41%, č.3: 61% [Humprey89]

27. Prevence je vždycky lepší (2) • Účinnost detekce chyb • Modelování, prototypování 65% avg 80% max • Formální oponentury návrhu 55% 75% • Neformální procházení 40% 60% • Čtení kódu 40% 60% • Integrační testování 45% 60% • Testování modulů 25% 50%

28. FURPS • Metoda FURPS byla vytvořena společností Hewlett–Packard na základě potřeby definovat, jak poznat a ověřit kvalitu dodávaného software.  První zmínky o této metodě pocházejí z roku 1986 a veřejně myšlenky publikovali Robert Grady a Deborah Caswell v knize „Software Metrics: Establishing a Company–Wide Program“ v roce 1987. • FURPS se dívá na kvalitu software nebo informačního systému z pěti základních hledisek: funkčnost, užitečnost, spolehlivost, výkon a rozšiřitelnost. Metoda definuje na nejvyšší úrovni, co by mělo být hodnoceno, ale nespecifikuje, jakým způsobem mají být oblasti hodnoceny. V těchto jednotlivých oblastech musí být dále vytvářeny konkrétní metriky a jejich hodnoty. • Pokud chcete dodávat zákazníkům opravdu dobrý software, tak je vhodné začít už při plánování testování zohledňovat tyto oblasti.

29. FURPS Hlediska (dimenze) kvality Software • F (functionality) – funkčnost (zaměřuje se na hlavní funkcionality a schopnosti programu, zda software podporuje byznys proces a bezpečnost systému). • U (usability) – užitečnost (hodnotí se zejména z pohledu lidského faktoru, jakým celkovým dojmem působí aplikace, dokumentace a školící materiály). • R (reliability) – spolehlivost (jedná se o hodnocení četnosti a závažnost chyb, přesnosti zpracování vstupů a výstupů). Pro vyjádření spolehlivosti se často používá pojem MTFB (mean time between failures), což je střední doba mezi chybou nebo selháním. V této oblasti se také sledují možnosti obnovení provozu a zotavení výpadku, zejména formou stress testu. • P (performace) – výkon (hodnocení celkové rychlosti odezev systému a zpracování klíčových byznys aktivit. Zároveň se sledují i technické parametry testovaného systému, např. vytížení zdrojů OS, zatížení síťového provozu, vytížení jednotlivých komponent systému). • S (supportability) – rozšiřitelnost.

30. Dalším hlediskem hodnocení je oblast rozšiřitelnosti aplikace v případě potřeby, možnosti údržby aplikace, její testovatelnosti. V této oblasti se taktéž hodnotí i přizpůsobitelnost a možnosti konfigurování. V zájmu není jen aplikace samotná, ale i její součásti pro konfiguraci a monitorování provozu. V poslední době se metoda FURPS rozšířila o malé a nenápadné znaménko, na FURPS+. Co vlastně toto označení „plus“ znamená? Odpověď je vcelku jednoduchá. Postupem času přestaly jednotlivé kategorie dostačovat, a proto bylo zavedeno toto „plus“, které označuje, že je metoda rozšířena o další dílčí elementy nebo podoblasti. Často se rozšiřuje o: Implementace – různá omezení, jazykové mutace, speciální nástroje a HW Rozhraní – efektivita rozhraní na externí IT systémy Operační systémy – speciální požadavky na OS a jeho případnou úpravu, včetně návrhu další správy Obchodní a právní aspekty – licencování a případná právní omezení pro různé demografické regiony FURPS