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:

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

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

  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 = ( 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.EVváhaUFP
počet vstupů (EI - External Inputs)20243024,3497,2
počet výstupů (EO - External Outputs)12152215,7578,5
počet dotazů (EQ - External Enquiry)16222822488
počet souborů (ILF - Internal Logical Files)4454,21042
počet externích souborů (EIF - External Interface Files)2232,2715,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

Faktor technické složitosti (FTS)

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ý

Výpočet

  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.

FP=(0.65 + (0.01*FTS))*(UFP)

Cocomo

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

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
  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 F_c 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,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

You could leave a comment if you were logged in.
mgr-szz/ap-ap/2-obr.txt · Poslední úprava: 2020/04/12 16:56 (upraveno mimo DokuWiki)
Nahoru
CC Attribution-Noncommercial-Share Alike 4.0 International
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0