====== N-AP2 ====== ====== Zadání ====== SW metriky a jejich využití. Techniky odhadu pracnosti a doby řešení. Funkční body. COCOMO. ====== SW metriky a jejich využití ====== Metrika je kvalifikovaný atribut softwaru. Bez měření nelze kvalitně řídit ani hodnotit kvalitu SW, atributy kvality mohou ale být různé. Softwarová metrika je nějaký údaj (měření), který lze nakonec převést na číselné hodnocení nějakého atributu softwaru. Dělí se na: - **produktové**: zdrojový kód, dokumentace, cyklomatická složitost (počet cest programem), počty funkčních bodů - **procesní**: činnosti spojené s vývojem, doba strávená na jednotlivých úlohách, původní odhad a skutečná reálná doba - **metriky zdrojů**: HW, lidé, čas, nemocnost, výkonnost ---- * **Implicitní (in proces)** -- zjistitelné pouze během vývoje * **Explicitní (after proces)** -- zjistí se kdykoliv i po skončení vývoje (z artefaktů produktů systému) ---- * **Interní** -- potřebuje řešitelský tým pro řízení a kontrolu prací: cost, effort, LOC, speed, memory, ... * **Externí** -- charakterizují uživatelské vlastnosti produktu: functionality, quality, complexity, efficiency, reliability, maintainability, ... ---- Měření softwaru mohou být také: **přímá**: počet řádek kódu (LOC), rychlost výpočtu, velikost paměti, počet chyb za určitou dobu … **nepřímá**: funkčnost, kvalita, složitost, pracnost, spolehlivost, schopnost údržby,… ===== ad1. Metriky kvality (finálního) produktu ===== – explicitní výsledky vývoje SW, zdrojový kód, dokumentace. Popisují charakteristiky produktu jako je jeho velikost, komplexita, návrhové vlastnosti, výkonnost, úroveň kvality, atd. * Metriky kvality produktu - orientované na zákazníka MTTF (mean time to failure) - používá se v bezpečnostně kritických systémech jako řízení letového provozu, letecká elektrotechnika, zbraně, atd. * Metriky kvality produktu - z pohledu zákazníka **Problémy hlášené zákazníkem** měří potíže zákazníka používajícího produkt. **Metrika** problémů se obvykle vyjadřuje pomocí problémů vztažených na uživatele a měsíc (PUM - per user month) ===== ad2. Metriky kvality (průběhu) procesu ===== – mohou být využity při zlepšování vývoje softwaru a procesu údržby (efektivita odstraňování defektů během vývoje, vzor přírustků defektů během testování, doba odezvy procesu oprav). * Jsou méně formálně definované. Znamenají zaznamenávání přírustků defektů během formálního testování. **Hustota defektů během formálního testování** * vyšší rychlosti defektů nalezených během testování indikují vyšší hladinu injektování chyb do softwaru během jeho vývoje. * defekty na KLOC **Vzor přírustků defektů během formálního testování** * může indikovat, že testování začalo pozdě, že testovací sada nebyla dostatečná, nebo že testování skončilo předčasně. **Profil odstraňování defektů podle fází** vyžaduje trasování defektů ve všech fázích vývojového cyklu. **Efektivnost odstraňování defektů - DRE (Defect Removal Efficiency)** DRE = E / ( E + D) E je počet chyb nalezených před předáním uživateli D je počet defektů po předání. ===== ad3. Metriky kvality projektu/zdrojů ===== – cena, rozvrh, produktivita, hardware, čas, počet vývojářů. ===== Implicitní (in proces) ===== * //Prac// -- pracnost * //Doba// -- doba řešení * //team(t)// a //Team// -- velikost týmu v čase a průměrná velikost * //MTBF(t)// -- střední doba mezi poruchami * další: spotřeba práce, produktivita, počet selhání systému v čase, defekty, spokojenost zákazníka, ... ===== Explicitní (after proces) ===== * //Del// -- délka programu v řádcích * //Fun(P)// -- počet podprogramů, počet metod * //Srnd// a //Nrnd// -- rozsah a výskyt operandů, * //Soper// a //Noper// -- rozsah a výskyt operací, * další: počet funkcí, tříd, počet datových tabulek, ... ===== Důvody pro měření metrik ===== * plánování projektu (odhad nákladů, pracnosti, času) * kontrola kvality produktu * odhad produktivity * zdokonalení práce (růst výkonnosti organizace) Příkladem může být tzv. Halsteadtova metrika, která je založena na teorii informací. Výsledkem výzkumu SW metrik jsou metodiky vývoje (SOA, OO, strukturované programování, znalosti a vlivu kvality specifikací atd.) a metodiky odhadu pracnosti a doby řešení COCOMO, funkční body, a filosofií SOA ITIL ===== Použití SW metrik ===== * **Výzkum:** podklad pro hledání metod realizace softwarových produktů, které by přinesly podstatné zvýšení jeho kvality a snížení nákladů a doby vývoje a hlavně rozsahu prací při údržbě softwaru (výzkum metod a zákonitostí vývoje softwaru). * **Normy:** základ pro stanovení technicko-ekonomických podkladů pro řízení prací při tvorbě softwaru (normy pracnosti, odhady takových metrik, jako je pracnost či doba řešení) a uzavírání smluv (cena, termíny), předpoklad CMM. * **Kontrola kvality:** prostředek sledování spolehlivosti softwaru při provozu a podklad pro řídící zásahy během údržby,procesy zajišťující kvalitu. * **Operativa:** prostředek sledování průběhu prací při vývoji (dodržování termínů, procento testovaných komponent, trendy počtů chyb, počty nově zanesených chyb, komponenty s největším počtem chyb, atd.). ===== Potíže s metrikami ===== * rozptyl hodnot * produktivita práce programátor, jejich kvalita * druh SW, obtížně splnitelné termíny realizace * moderní projekční techniky * kvalita zúčastněných * omezení SW a HW ===== Datové typy metrik ===== * příslušnost ke třídě -- id, číslo tramvaje; vztah: = * fuzzy metrika –- slabý, dobrý, velmi dobrý, vynikající; vztah: =, < * fuzzy číselná -- známky ve škole; vztah: =, < , (aritm. operace) * interval -- teplota, čas * číselná metrika -- plná data (délka, ...) ====== Techniky odhadu pracnosti a doby řešení ====== **Odhad ceny a pracnosti** - Odhad se zpožděním - Počáteční odhad podle minulého podobného projektu - Použití dekompozičních technik - Použití empirických modelů **Přesnost odhadu projektu je ovlivněna** * přesností odhadu velikosti produktu * 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ů) * schopnostmi projektového týmu * stabilitou požadavků na projekt a vývojovým prostředím ---- **__Dekompoziční techniky__** **Odhad podle problému: LOC metoda** (lines of code) a **FP metoda** (function points) se používají * jako proměnné pro odhad různých veličin v projektu * jako základní údaje o minulých projektech používají **tříbodový odhad Program Evaluation and Review Technique (PERT)**: EV = ( soptimisticky + 4 spravdepodobny + spesimisticky ) / 6 **Odhad založený na procesu: procesní metoda** **Odhad metodou COCOMO** ===== Příklad: ===== **Předběžný popis rozsahu systému:** "Do CAD vstupují dvou a třídimensionální data. Uživatel interaktivně komunikuje se systémem. Komunikace musí být dobře uživatelsky navržená. 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 na různá grafická zařízení. Systém bude komunikovat s periferními zařízeními typu myš, digitizér, displej, laserová tiskárna." ---- **Stanovení následujících funkcí systému:** UICF - modul řízení a komunikace s uživatelem 2DGA - dvojdimenzionální geometrická analýza 3DGA - třídimenzionální geometrická analýza DBM - řízení databáze CGDF - modul grafického zobrazení PC - řízení periferií DAM - modul analýzy návrhu ---- **Odhad ceny a pracnosti metodou LOC:** Pro každou funkci systému odhadneme optimistický, pravděpodobný a pesimistický počet LOC a určíme EV. Například pro funkci 3DGA: EV = ( soptimisticky + 4 spravdepodobny + spesimisticky ) / 6 = (4600+4*6900+8600)/6=6800 Součtem všech odhadů EV dostaneme **celkový počet LOC = 33200**. | |EV| |UICF |2300| |2DGA |5300| |3DGA |6800| |DBM |3350| |CGDF |4950| |PC |2100| |DAM |8400| |**LOC** |**33200**| Z historických údajů víme, že **průměrná produktivita** pro systémy tohoto typu je **620 LOC/mm**. Tedy **pracnost** se rovná 33 200/620 = **54 mm**. Počítáme-li náklady 20 000 Kč na 1 mm (člověkoměsíc), pak **cena jedné LOC** je 20 000/620 = **32,25 Kč**. **Celková __cena produktu bude 20 000*54 = 1 080 000 Kč__ (zaokrouhleno na tisíce).** ---- **Odhad ceny a pracnosti metodou FP (Function Points):** | |opt.|pravděp.|pes.|EV|váha|UFP| |počet vstupů (EI - External Inputs)|20|24|30|24,3|4|97,2| |počet výstupů (EO - External Outputs)|12|15|22|15,7|5|78,5| |počet dotazů (EQ - External Enquiry)|16|22|28|22|4|88| |počet souborů (ILF - Internal Logical Files)|4|4|5|4,2|10|42| |počet externích souborů (EIF - External Interface Files)|2|2|3|2,2|7|15,4| |**Celkem UFP**| | | | | |**321,1**| Pro zisk jednotlivých "neupravených" funkčních bodů UFP je zde odhad EV navíc násoben jednotlivými váhami, tedy UFP = ( soptimisticky + 4 spravdepodobny + spesimisticky ) / 6 * váha Celkem dostaneme 321 UFP. Ty se ale musí ještě vynásobit koeficientem PCA, získaným z následující tabulky: | |PCA| |zálohování a obnova| 4| |datové přenosy| 2| |distribuované zpracování| 0| |kritický výkon| 4| |existující operační prostředí| 3| |přímý vstup dat| 4| |vstupní transakce přes více obrazovek| 5| |přímá aktualizace hlavních souborů| 3| |složité hodnoty domény informací| 5| |složité vnitřní zpracování| 5| |návrh kódu pro opakované použití| 4| |v návrhu jsou konverze/instalace| 3| |vícenásobné instalace| 5| |návrh aplikace pro změny| 5| |**Celkem PC**| **52**| **PCA** = 0,65 + (0,01 * PC) = 0,65 + (0,01 * 52) = 1,17 **Odhad FP = UFP * PCA = 321 * 1,17 =376** Z historických údajů víme, že **průměrná produktivita** pro systémy tohoto typu je **6,5 FP/mm**. Tedy **pracnost** se rovná 376/6,5 = **58mm**. Počítáme-li náklady 20 000 Kč na 1 mm (člověkoměsíc), pak **cena jednoho FP** je 20 000/6,5 = **3077 Kč**. **Celková __cena produktu bude 20 000 * 58 = 1 160 000 Kč__(zaokrouhleno na tisíce).** ---- **Odhad ceny a pracnosti metodou COCOMO:** K vysvětlení a výpočtu je použita stránka: http://sunset.usc.edu/research/COCOMOII/cocomo81_pgm/cocomo81.html Rozsah projektu odhadněme na řádově 10 000 řádků. Zvolíme vázaný mód (1,2) metody COCOMO. A nastavíme každý z 15ti volených atributů a máme tak všechny potřebné atributy: size = 10000 mode = 1.20 rely = 1.00 data = 0.94 cplx = 1.00 time = 1.00 stor = 1.00 virt = 1.00 turn = 1.00 acap = 1.00 aexp = 1.00 pcap = 1.00 vexp = 1.00 lexp = 1.00 modp = 1.00 tool = 1.00 sced = 1.00 Pracnost = 41,71 mm Plán = 8,25 měsíců Odhadovaná **cena projektu** bude 20 000*41,71 = **834 000 Kč**. ====== Funkční body ====== **Funkční body = normalizovaná metrika softwarového projektu** Je to metodika pro měření velikosti informačního systému. Počítají se funkce (činnosti) software a na základě jejich váženého součtu se provede odhad. * měří aplikační oblast, nezkoumá technickou oblast * měří aplikační funkce a data, neměří kód * měří vstupy, výstupy, dotazy, vnitřní paměti, vnější paměti odhad = velikost projektu x složitost x rizikové faktory === Funkční body vztažené k transakčním funkcím === * Externí vstupy (EI - External Inputs) * Externí výstupy (EO - External Outputs) * Externí dotazy (EQ - External Enquiry) === Funkční body vztažené k datovým funkcím === * Vnitřní logické soubory (ILF - Internal Logical Files) * Soubory vnějšího rozhraní (EIF - External Interface Files) Výsledek se zanese do formuláře UFP, který se pak znásobí koeficientem složitosti. Výsledkem je odhad práce, času a velikosti. === Neupravené funkční body (UFP) === Před výpočtem musíme EI, EO, EQ, ILF, EIF roztřídit do skupin podle vah. Potom spočítame UFP {{:mgr-szz:in-ins:1_matica_ftr_det.png?350|}}{{:mgr-szz:in-ins:1_matica_ret_det.png?350|}}{{:mgr-szz:in-ins:1_ufp.png?400|}} === Faktor technické složitosti (FTS) === 14 charakteristik: - 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ém 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í? Každá charakteristika je hodnocená ve stupnici 0 – 5 takto: * 0 = bez vlivu * 1 = náhodný * 2 = mírný * 3 = průměrný * 4 = významný * 5 = podstatný === Výpočet === - Identifikujte a spočtěte ILF, EIF, EI , EO, EQ. Pro každou ILF a EIF identifikujte počet RET a počet DET. Pro každou EI, EO a EQ, identifikujte počet FTR a DET - S použitím matic složitosti spočtěte váhy EI, EO, EQ, ILF, EIF (nízká, průměrná, vysoká) a vložte je do tabulky UFP. - Spočtěte Počet neupravených funkčních bodů z tabulky UFP. - Určete hodnoty 14 charakteristik systému. - Sečtěte hodnoty charakteristik -- určíte tak Faktor technické složitosti (FTS) systému. - Určete Počet upravených FP systému. FP=(0.65 + (0.01*FTS))*(UFP) ====== Cocomo ====== (Typ projektu, počet řádků kódu) **CO**nstructive **CO**st **MO**del – založen na souboru významných veličin, které ovlivňují cenu a dobu řešení projektu. Výstupem je počet člověkoměsíců. Existuje základní a rozšířené COCOMO. Základní COCOMO používá rozdělení projektů na tři typy jednoduché, středně složité a složité. Pak používá metriku počet řádků kódu a na základě určení typu projektu z této metriky pomocí různých vzorečků odvozuje potřebný počet programátorů a dobu vývoje v měsících. ==== Odhady ==== * 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) ==== COCOMO ==== **COCOMO – COnstructive COst MOdel** * existuje víc druhů COCOMO -- COCOMO 81, COCOMO II === COCOMO 81 === * Cena vývoje aplikace přímo závisí na velikosti SW. * Přesnost odhadu velikosti SW závisí na etapě vývoje. * V pozdějších etapách je odhad přesnější. * Přesnost odhadu se může lišit až čtyřikrát (4:1) oběma směry. == 3 úrovně detailu == * **Základní model** -- hrubý odhad E(KSLOC) a T(KSLOC) založen na odhadu KSLOC. * **Střední model** -- vliv jiných faktorů na E(KSLOC) a T(KSLOC). * **Pokročilý model** -- bere v úvahu vlivy vývojové etapy, ve které se projekt nachází. == Vývojové módy projektů == * **Organický mód (koeficient 1,05)** -- velikost projektu = málo set tisíc řádků, malé problémy pro malé týmy, typické jsou mírné normy a malá omezení na specifikaci rozhraní a možnost ovlivnit požadavky. Algoritmy a postupy jsou dobře známy, podmínky realizace relativně stabilní, nejsou ostré podmínky ani termíny. Příklad: zpracování dat v dávkovém provozu, úpravy známého operačního systému nebo kompilátoru. * **Bezprostřední (přechodný) mód (koeficient 1,12)** -- typ mezi organickým a vázaným, velikost projektu < 400 tisíc řádků, pokud není kód generován automaticky. V týmu jsou zkušení i méně zkušení pracovníci, tým má nemoc velké zkušenosti z předchozích obdobných realizací, úloha poměrně složitá. Příklad: menší dedikované oper. systémy, běžné transakční systémy, systém řízení výroby, jednoduchý systém řízení vojsk a zbraní. * **Vázaný mód (koeficient 1,2)** -- SW pracuje za velmi ostrych omezení na výkonnost a dobu odezvy, velikost jsou miliony řádků, vyžaduje práci s komplikovanýmy SW a HW systémy za ostrých předpokladů na předepsané fce, spolehlivost, termíny, přenositelnost, modifikovatelnost. Požadavky je obtížné měnit, řeší se nové problémy, se kterými se pracovníci dosud nesetkali. Obvykle: specifikaci požadavků + návrh dělá malá skupina, vývoj částí – velký tým. Programování a testy – souběžné. Příklad: nové rozsáhlé oper. systémy, kosmické lodě, letadla, atomové elektrárny, RT aplikace. == Atributy produktu == RELY – požadovaná spolehlivost DATA – velikost databáze CPLX – složitost produkt == HW atributy == TIME – omezení času výpočtu STOR – využití paměti/disku VIRT - spolehlivost virtuálních stroj TURN – míra rychlosti oběhu úlohy počítačem == Atributy vývojového týmu == ACAP – analytické schopnosti PCAP – programovací schopnosti AEXP – zkušenosti s podobnými aplikacemi VEXP – zkušenosti se spec. virt. strojem LEXP – zkušenosti se spec. prog. Jazykem == Atributy projektu == MODP – použití moderních prg. technik TOOL – použití SW nástrojů == Vzorce == E=a*(KSLOC)^b T=c*E^d a,b,c,d: parametry podle úrovně modelu a vývojového módu * V základním modelu mají všechny parametry konstantní hodnoty. * Ve středním a pokročilém modelu ve všech vývojových módech a závisí na F_c (a*F_c), ostatní parametry jsou konstantní. * korekční faktor F_c je součinem hodnot 15 atributů specifických pro vývojový proces == Postup při stanovení odhadu pracnosti == - určí se úroveň modelu a mód projektu - určí se hodnocení vlivu faktorů reprezentovaných jednotlivými atributy (velmi nízký, nízký, normální, velký, velmi velký, extrémně velký) - určí se číselné hodnocení atributů z tabulek - určí se korekční faktor F_c jako součin takto získaných hodnot (střední a pokročilý model) - podle úroveň modelu a módu projektu se určí parametry a,b,c,d a vypočtou hodnoty odhadu podle vzorců === COCOMO II (1995)=== Potřeba změnit COCOMO 81 * nové softwarové procesy * nové jevy měření velikostí * nové jevy znovupoužití software * potřeba rozhodování na základě neúplné informace == 3 různé modely == * ACM (Aplication Composition Model) pro projekty s použitím moderních nástrojů a GUI * EDM (Early Design Model) pro hrubé odhady v úvodních etapách, kdy se architektura vyvíjí * PAM (Post Architecture Model) pro odhady poté, co byla specifikována architektura == Výpočet == PM_estimated=A*(Size)^{(SF)}*(prod{i}{}{EM_i}) SF=1.01+0.01*sum{}{}{(hodnocení driverů exponentu)} A v rozsahu 1.01 - 1.26 Size je určená několika přístupy: * KSLOC (tis.řádek zdroj. kódu) * UFP (neupravené fukční body) * EKSLOC (ekvivalentní velikost zdroj. kódu) SF - upravený součet 5 driverů s hodnocením 0 – 5 Drivery exponentu: * návaznost na předchozí výsledky * flexibilita vývoje * rozhodnutí architektury/rizika * koheze týmu *vyspělost procesu (podle SEI CMM) EM: multiplikátory úsilí (7 pro EDM, 17 PAM) -- nové atributy ====== Předměty ====== PA105 Technologie informačních systémů II PA104 Vedení týmového projektu Doplňte prosím ====== Vypracoval ====== Marek Menšík UČO 255679 Z mé strany hotovo. Nevím přesně, kdo otázky zpracoval přede mnou, pouze jsem je sem umístil, doplnil chybějící věci a opravil nepřesnosti. Připomínám, že věci zde uvedené nemusí být korektní a zatím neprošly kontrolou žádného z profesorů. ====== Použitá literatura a weby ====== http://cs.felk.cvut.cz/~richta/www-si2/WS4.htm http://statnice.dqd.cz/mgr-szz:in-ins:1.2-ins http://vis-projekt.sweb.cz/si2/vedouci/zdroje.htm https://is.muni.cz/el/1433/jaro2012/PA105/10MereniSW.pdf http://sunset.usc.edu/research/COCOMOII/cocomo81_pgm/cocomo81.html http://groups.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/kutcher/kutcher.html http://www2.fiit.stuba.sk/~bielik/courses/msi-slov/kniha/2011/essays/esej2010_09-si-xkompanek.pdf ~~DISCUSSION~~