SW metriky a jejich využití. Techniky odhadu pracnosti a doby řešení. Funkční body. COCOMO.

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:

1. produktové: zdrojový kód, dokumentace, cyklomatická složitost (počet cest programem), počty funkčních bodů
2. procesní: činnosti spojené s vývojem, doba strávená na jednotlivých úlohách, původní odhad a skutečná reálná doba
3. 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,…

– 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)

– 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í.

– cena, rozvrh, produktivita, hardware, čas, počet vývojářů.

• 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, …

• 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, …

• 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

• 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.).

• 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

• 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, …)

Odhad ceny a pracnosti

1. Odhad se zpožděním
2. Počáteční odhad podle minulého podobného projektu
3. Použití dekompozičních technik
4. 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 = ( s_optimisticky + 4 s_{pravdepodobny} + s_pesimisticky ) / 6

Odhad založený na procesu: procesní metoda Odhad metodou COCOMO

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 = ( s_optimisticky + 4 s_{pravdepodobny} + s_pesimisticky ) / 6 = (4600+4*6900+8600)/6=6800
Součtem všech odhadů EV dostaneme celkový počet 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):

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 = ( s_optimisticky + 4 s_{pravdepodobny} + s_pesimisticky ) / 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 = 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 = 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

• Externí vstupy (EI - External Inputs)
• Externí výstupy (EO - External Outputs)
• Externí dotazy (EQ - External Enquiry)

• 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.

Před výpočtem musíme EI, EO, EQ, ILF, EIF roztřídit do skupin podle vah. Potom spočítame UFP

14 charakteristik:

1. Požaduje systém zálohování a obnovu?
2. Jsou požadovány datové přenosy?
3. Obsahuje funkce distribuovaného zpracování?
4. Je požadován kritický výkon?
5. Bude systém pracovat za silném provozu?
6. Požaduje systém přímý vstup dat?
7. Požadují vstupní transakce přímé vstupy dat prostřednictvím více obrazovek nebo operací?
8. Jsou hlavní soubory aktualizovány přímo?
9. Jsou vstupy, výstupy, soubory a dotazy složité?
10. Je složité vnitřní zpracování?
11. Je kód navržen pro opakované použití?
12. Jsou v návrhu zahrnuty konverze a instalace?
13. Je systém navržen pro vícenásobné instalace na různých místech?
14. 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ý

1. 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
2. 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.
3. Spočtěte Počet neupravených funkčních bodů z tabulky UFP.
4. Určete hodnoty 14 charakteristik systému.
5. Sečtěte hodnoty charakteristik – určíte tak Faktor technické složitosti (FTS) systému.
6. Určete Počet upravených FP systému.

(Typ projektu, počet řádků kódu)

COnstructive COst MOdel – 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.

• 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 – COnstructive COst MOdel

• existuje víc druhů COCOMO – COCOMO 81, COCOMO II

• 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.

• 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í.

• 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.

RELY – požadovaná spolehlivost
DATA – velikost databáze
CPLX – složitost produkt

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

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

MODP – použití moderních prg. technik
TOOL – použití SW nástrojů

: 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 závisí na (), ostatní parametry jsou konstantní.
  • korekční faktor je součinem hodnot 15 atributů specifických pro vývojový proces

1. určí se úroveň modelu a mód projektu
2. určí se hodnocení vlivu faktorů reprezentovaných jednotlivými atributy (velmi nízký, nízký, normální, velký, velmi velký, extrémně velký)
3. určí se číselné hodnocení atributů z tabulek
4. určí se korekční faktor jako součin takto získaných hodnot (střední a pokročilý model)
5. podle úroveň modelu a módu projektu se určí parametry a vypočtou hodnoty odhadu podle vzorců

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

• 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

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

PA105 Technologie informačních systémů II
PA104 Vedení týmového projektu
Doplňte prosím

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ů.

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