Při řízení prací při vývoji či customizaci a také při provozu IS je nutné sledovat kvantitativní (číselné) charakteristiky, jako je počet řádku programů, doba řešení, pracnost řešení atd., umožňující hodnotit průběh prací a odhadovat kvalitu softwaru a přijímat odpovídající opatření. Příkladem je sledování řešení těch částí, ve kterých je velmi mnoho závad. Pro kvantitativní charakteristiky softwaru se používá termín softwarové metriky. Sledování metrik, jako jsou trendy počtů selhání systému, nebo kvantifikované hodnocení systémů uživateli, je základem zajišťování kvality SW
Norma ISO 9126 (je již přijata i jako CSN) orientovaná na kvantitativní charakteristiky kvality softwaru a řízení prací rozeznává metriky:
· interní, tj. takové, které potřebuje řešitelský tým pro řízení a kontrolu prací, příkladem je aktuální procento otestovaných modulů systému. Interní metriky mohou být:
1. explicitní, např. počet tříd v programech
2. implicitní, např. podíl zkontrolovaných programů
· externí, které charakterizují uživatelské vlastnosti produktu.
Odhad parametrů na realizaci a termínů realizace softwarového produktu je obtížný z následujících důvodů:
1. Silná závislost všech parametrů výsledného produktu, jako jsou náklady, kvalita řešení atd., na kvalitě řešitelského týmu.
2. Rychle se měnící podmínky (vlastnosti hardwaru, měnící se způsoby používání počítačů, např. v poslední době přechod na interaktivní a distribuované způsoby práce atd.) silně snižují opakovatelnost nebo podobnost řešení. Jedná se tedy o stanovení pracnosti úkolu, který je do značné míry unikátní.
3. V programování se dosud neustálily pracovní postupy.
4. Vývoj je natolik rychlý, že ke změnám podmínek řešení (know-how, použitý hardware) může dojít i během řešení jediného úkolu.
Lze tedy očekávat, že každá metoda odhadu bude zatížena značnými chybami. Přesto je nějaký, byt’ hrubý odhad potřebný a nutný. Za této situace je nutné se do značné míry spoléhat na zkušenost a intuici odhadce. V případech, kdy organizace získala dostatek zkušeností s realizací příbuzných systémů, může být odhad nejrůznějších metrik softwaru, jako je pracnost, rozsah dokumentace atd., dostatečně přesný. V každém případě musí být odhad svěřen kvalifikovanému odhadci. V dalším se omezíme na 2 nejrozšířenější metody odhadu: COCOMO a Funkční body
§ dva principy odhadu – odhady pracnosti (člověko-měsíce) – E a doby řešení (měsíce) – T
§ obě varianty odhadu (COCOMO, FP) jsou použitelné v různých etapách životního cyklu
§ COCOMO – vychází z odhadu délky programů KSLOC = tisíce zdrojových řádků (COCOCMO II už může mít na vstupe UFP)
§ Funkční body – odhad na základě struktury aplikace (nezkoumá kód ale funkci aplikace)
Je to metrika, která slouží k odhadování pracnosti vyvíjeného softwaru metodou výpočtu funkčních bodů, které se vypočítají z rozsahu požadavků na systém (např. počet datových struktur, uživatelských vstupů a výstupů, …). Z výsledného počtu funkčních bodů lze odhadnout velikost budoucího programu, protože pro různé programovací jazyky je na základě statistických měření známo, kolik příkazů je třeba na pokrytí jednoho funkčního bodu. Metoda „feature points“ je variantou této metody pro případ objektové tvorby softwaru.
Metoda funkčních bodů patří sice mezi ty složitější, ale poskytuje poměrně správné hodnoty. Princip spočívá v rozdělení cílového systému do kategorizovaných prvků (těmi jsou například externí vstupy či výstupy). Následně se každému prvku přiřadí složitost, která se vynásobí tzv. váhovým faktorem (ke stanovení složitosti jsou k dispozici tabulky zohledňující vlastnosti prvků; stejně tak jsou pevně stanoveny váhové faktory). Součet takto získaných hodnot pak určuje tzv. neupravený počet funkčních bodů. Dalším krokem je přechod k upravenému počtu funkčních bodů (zahrne se vliv dalších faktorů, které nejsou obsaženy v kategorizovaných prvcích). A konečně se stanoví celková doba trvání realizace projektu v tzv. člověkodnech (opět jsou k dispozici převodní tabulky dle použitých vývojových nástrojů a dalších prostředků). Hlavní nevýhodou této metody je nutnost mít co možná nejpřesnější představu o výsledku našeho snažení.
Výhody FP
i. Nezáleží na množství kódu
ii. Není závislý na použitém prog. jazyku.
iii. Specifikace potřebných dat již na začátku projektu. Potřebujeme pouze detailní specifikaci.
Nevýhody FP
i. Možnost subjektivního posuzování.
ii. Těžké pro výpočet.
iii. Ignorace kvality výstupu.
iv. Orientace na tradiční data zpracovávaných aplikací.
v. Fyzikální význam, vyžaduje zkušenost.
COCOMO (COnstructive COst MOdel) je jeden z nejpoužívanějších algoritmů sloužících ke stanovení odhadu nákladů softwarových projektů. Lze vycházet z úvahy, že pracnost, cena a čas vytvoření nového systému jsou úměrné velikosti zdrojových souborů. Odhad pracnosti a nákladnosti vývoje softwaru vychází z myšlenky, že úsilí E a doba vývoje T jsou úměrné velikosti zdrojového kódu. Odtud je dále možné stanovit i finanční náklady na vývoj projektu.
Slabým místem tohoto přístupu je zejména přesnost počátečního odhadu velikosti produktu, což jsou tisíce řádků zdrojového kódu. Odhad velikosti se může od skutečnosti značně lišit (až čtyřikrát), a to oběma směry. Bez předešlých zkušeností nebo jiného zdroje empirických dat, není zpravidla reálné dostatečně přesný odhad budoucí velikosti kódu učinit.
Dále je před vlastním výpočtem třeba nastavit další parametry modelu, jimiž jsou úroveň detailu výpočetního modelu a použitý vývojový mód. Úroveň detailu výpočtu říká, zda a v jaké míře mají být do výpočtu zahrnuty i jiné faktory, než je vlastní velikost kódu. Existují tři úrovně, kterými jsou základní model, střední model a pokročilý model. Základní model žádné jiné faktory, než je velikost kódu, nepoužívá. Střední model zohledňuje další aspekty projektu. Pokročilý model používá stejné atributy jako model střední a dále ještě přihlíží k fázi, ve které se projekt nachází.