Team Se@Msi: Meranie v softvÃ©rovom inÅ¾inierstve. - FIIT STU ...

More documents

Recommendations

Info

106 Meranie a životný cyklus softvéru množín interakcií typu DD a DS vo vnútri modulu s výnimkou interakcií typu DD medzi dátovou deklaráciou a formálnym parametrom podprogramu v module. Na základe tejto definície bola definovaná metrika pomeru súdržných interakcií RCI softvérovej súčiastky sp ako pomer počtu prvkov množiny súdržných interakcií C k počtu prvkov množiny všetkých interakcií M softvérovej súčiastky sp. RCI ( sp) = CI ( sp) M ( sp) Táto metrika bola použitá v [Briand a kol., 1994] na odhad náchylnosti modulov k chybám v rámci rovnakého experimentu ako pri metrike zviazanosti na základe interakcií. Súdržnosť vo fáze návrhu podľa [Bieman98] Pri tejto metrike sa vychádza zo závislosti medzi vstupmi a výstupmi modulu reprezentovanej grafom závislostí medzi vstupmi a výstupmi (input-output dependence graph, IODG). Každý vstup prispieva k jednému alebo viacerým výstupom z modulu. Vychádzajúc z reprezentácie pomocou IODG grafov sa v [Bieman98] definuje šesť relácií, pomocou ktorých je možné rozlíšiť jednotlivé úrovne súdržnosti (usporiadané od najslabšej k najsilenejšej): 1. náhodná - dva výstupy z modulu nezávisia medzi sebou ani od spoločného vstupu. 2. podmienečná - dva výstupy z modulu podmienečne závislé od spoločného vstupu (hodnota vstupu rozhoduje o vetvení programu). 3. iteračná - dva výstupy z modulu sú iteračne závislé od spoločného vstupu (hodnota vstupu rozhoduje o prerušení opakovania). 4. komunikačná - dva výstupy z modulu závisia od spoločného vstupu. Vstup sa používa na počítanie hodnôt oboch výstupov, ale sa podľa neho nerozhoduje pre niektý z výstupov ani o procese iterovania. 5. postupná – jeden výstup závisí od druhého. 6. funkcionálna – existuje iba jeden výstup z modulu. Metrika súdržnosti vo fáze návrhu (design-level cohesion) DLC sa určuje na základe relácií medzi pármi výstupov z modulu. Pre každý pár sa berie najsilnejšia úroveň súdržnosti medzi nimi. Výsledná súdržnosť modulu je najslabšia z úrovní súdržností párov výstupov z modulu. Platnosť tejto metriky bola v [Bieman98] preskúmaná na systémových programoch operačného systému UNIX aj na programoch vytvorených študentmi. Výsledky analýzy ukázali, že výsledky merania súdržnosti vo fáze návrhu vo vysokej miere zodpovedajú výsledkom merania zdrojového kódu.
Meranie v etape návrhu 107 Funkcionálna súdržnosť vo fáze návrhu podľa [Bieman98] Pri odvodení tejto triedy metrík sa vychádzalo z úvah použitých na vývoj analogickej metriky funkcionálnej súdržnosti určenej na meranie na základe dostupného zdrojového kódu [Bieman98]. Na meranie v etape návrhu bola pôvodná metrika funkcionálnej súdržnosti upravená tak, aby vychádzala z reprezentácie závislostí medzi vstupnými a výstupnými komponentmi modulu pomocou IODG grafu. Metriky funkcionálnej súdržnosti vo fáze návrhu (DFC) sú vyjadrené na základe počtu tzv. izolovaných a podstatných komponentov a na základe spojitosti komponentov. Izolovaný komponent je taký, ktorý je vo vzťahu závislosti iba s jedným výstupom. Podstatný komponent je taký, ktorý je vo vzťahu závislosti so všetkými výstupmi. Spojitosť komponentu C je definovaná ako pomer medzi počtom výstupov, s ktorými je komponent viazaný reláciou závislosti, a celkovým počtom výstupov z modulu. V prípade, že modul má iba jeden výstup, spojitosť má hodnotu 1. V [Bieman98] sú definované tri metriky pre súdržnosť: • Voľná súdržnosť D LC = T E • Pevná súdržnosť TC = T (kde D je počet neizolovaných komponentov, E je počet podstatných komponentov a T je celkový počet komponentov v module). • Súdržnosť modulu MC bola definovaná ako stredná hodnota spojitosti komponentov v module. T ∑ Ci i MC = T Tieto metriky boli použité pri rovnakom experimente ako pri metrike funkcionálnej súdržnosti vo fáze návrhu a dospelo sa k podobným výsledkom. Meranie používateľského rozhrania Kvalitu používateľského rozhrania môžeme hodnotiť z viacerých aspektov, pričom sa často opierame o subjektívne pocity a názory používateľov, ťažko použiteľné ako vstupné údaje pre meranie. Kvantitatívne hodnotenie používateľského rozhrania je možné získať viacerými spôsobmi. Je možné zakomponovať zber údajov počas fázy testovania do samého programu alebo založiť meranie na údajoch ako sú počet chýb priemerného používateľa pri práci s programom alebo cena prístupu k funkciám alebo údajom v systéme. Cena môže byť vyjadrená časom alebo počtom operácií, potrebných na prístup k danému prvku
Page 1:
MSI KIVT FEI STU Bratislava
Page 5 and 6:
Slovenská technická univerzita 20
Page 7:
Predslov Publikácia, ktorú práve
Page 11:
DIEL I. Eseje o manažmente softvé
Page 15 and 16:
Chyby v procese tvorby softvéru a
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Je otvorený zdrojový text riešen
Page 23 and 24:
Technické problémy Je otvorený z
Page 25 and 26:
Je otvorený zdrojový text… 15 p
Page 27 and 28:
Zlatá rybka Peter AGH „Chcem to
Page 29 and 30:
Zlatá rybka 19 treba počítať a
Page 31 and 32:
Zlatá rybka 21 určité znalosti a
Page 33 and 34:
Softvérový manažér Ján Pidych
Page 35 and 36:
Softvérový manažér 25 Príbeh d
Page 37:
N Softvérový manažér 27 a mana
Page 40 and 41:
30 Eseje Všadeprítomné modely Pr
Page 42 and 43:
32 Eseje Príklad kolízie medzi mo
Page 44 and 45:
34 Eseje a revízia pokračuje v di
Page 46 and 47:
36 Eseje technikou vyjednávania o
Page 48 and 49:
38 Eseje • Kapacita procesu • S
Page 50 and 51:
40 Eseje dostupné používateľovi
Page 52 and 53:
42 Eseje Manažér môže podniknú
Page 54 and 55:
44 Eseje prístup. Nestačí zhroma
Page 56 and 57:
46 Eseje Napriek všetkým snahám
Page 58 and 59:
48 Eseje [LOCS] 10 15 10 14 10 13 1
Page 61 and 62:
Pripravte sa zlyhať Michal Šrámk
Page 63 and 64:
Pripravte sa zlyhať 53 Zabehnuté
Page 65 and 66: Pripravte sa zlyhať 55 k pokroku.
Page 67 and 68: Testovanie požiadaviek a človek v
Page 73 and 74: Čo robiť, keď zákazník nevie p
Page 75 and 76: Čo robiť, ked zákazník nevie pr
Page 77 and 78: Čo robiť, ked zákazník nevie pr
Page 79 and 80: Ako zlepšiť softvérové procesy
Page 81 and 82: Ako zlepšiť softvérové procesy
Page 83: Ako zlepšiť softvérové procesy
Page 86 and 87: 76 Eseje snažia splniť normy (nap
Page 88 and 89: 78 Eseje myslieť aj na to, že int
Page 90 and 91: 80 Eseje Obstarávanie môže pomô
Page 92 and 93: 82 Eseje [Cross] CROSS, S.E.: Towar
Page 95 and 96: Úvod Priznám sa, že keď som prv
Page 97 and 98: Úvod 87 Produktom etapy návrhu je
Page 99: Úvod 89 merania softvéru z pohľa
Page 102 and 103: 92 Meranie a životný cyklus softv
Page 109 and 110: Meranie v etape návrhu Stanislav H
Page 111 and 112: Meranie v etape návrhu 101 niektor
Page 113 and 114: Meranie v etape návrhu 103 Metrika
Page 115: Meranie v etape návrhu 105 Pomocou
Page 119 and 120: Meranie v etape návrhu 109 kompakt
Page 121 and 122: Meranie v etape implementácie Vlad
Page 123 and 124: Meranie v etape implementácie 113
Page 125 and 126: Meranie v etape implementácie 115
Page 127: Meranie v etape implementácie 117
Page 130 and 131: 120 Meranie a životný cyklus soft
Page 137 and 138: Meranie pri testovaní, prevádzke
Page 147 and 148: Meranie vyspelosti softvérového p
Page 159 and 160: Meranie produktivity Ján Pidych Ab
Page 161 and 162: Meranie produktivity 151 Takisto je
Page 163 and 164: Meranie produktivity 153 TDEV je č
Page 165 and 166: Meranie produktivity 155 komunikác
Page 167:
Meranie produktivity 157 Litaratúr
Page 170 and 171:
160 Meranie a manažment, meranie p
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
Page 178 and 179:
show all

Team Se@Msi: Meranie v softvÃ©rovom inÅ¾inierstve. - FIIT STU ...

Create successful ePaper yourself

Delete template?

Save as template?