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

More documents

Recommendations

Info

100 <strong>Meranie</strong> a životný cyklus softvéru meranie a vyhodnocovanie výsledkov merania. Nárastom používania štandardizovaných metodík návrhu a CASE prostriedkov sa situácia na tomto poli postupne zlepšuje. Včasné uplatnenie merania je kľúčovým faktorom pre úspešný manažment vývoja softvéru. Informácie získané z výsledkov merania v etape návrhu sa používajú na: • Včasnú identifikáciu chýb vo výstupoch z fáz špecifikácie a návrhu, čím sa znížia náklady na odstránenie týchto chýb zo systému. • Pri výskyte alternatívnych riešení vo fáze návrhu výsledky merania pomáhajú zhodnotiť, ktoré riešenie je vhodnejšie. • Identifikáciu zložitých modulov a modulov, ktoré sú náchylné k chybám. Modulom, ktoré sú identifikované ako problematické, sa pridelia dodatočné zdroje a skúsenejší programátori, s cieľom vyhnúť sa oneskoreniam a iným problémom v etapách implementácie, testovania a údržby daného modulu. • Sledovanie kvality softvérového produktu a procesu vylepšené tým, že sa so sledovaním kvality začne v skorších etapách životného cyklu. • Odhad miery možnosti znovupoužitia modulov v počiatočných etapách ich vývoja. Čo meriame Pri meraní v rôznych etapách životného cyklu softvéru sa sledujú vybrané atribúty výstupu, ktorý daná etapa produkuje. Niektoré atribúty sú spoločné pre viacero etáp životného cyklu. Tak napríklad je možné uvažovať atribúty ako sú zložitosť alebo veľkosť systému pri špecifikácii, návrhu alebo v zdrojovom kóde, alebo súdržnosť a zviazanosť modulov pri návrhu a v zdrojovom kóde. Kvalita výstupu z danej etapy životného cyklu sa posudzuje podľa hodnôt získaných meraním vybraných atribútov. Napríklad všeobecne zaužívané pravidlo „dobrého návrhu“ je snaha o minimálnu zviazanosť (miera previazanosti elementov patriacich rozličným modulom) a maximálnu súdržnosť (miera previazanosti elementov v rámci jedného modulu). Je možné, že tieto dva koncepty sa medzi semou budú vylučovať, a preto sa musí hľadať ich najlepší pomer z hľadiska kvality systému. Pritom sa nesmie zabúdať na iné kritériá kvality, akým je napríklad možnosť znovupoužitia modulov alebo mieru rozšíriteľnosti a modifikovateľnosti produktu. Treba uviesť, že v literatúre existuje nejednoznačnosť v chápaní významu pojmov, ktorými sa označujú niektoré atribúty výstupov softvérového procesu významné pre definíciu softvérových metrík. V práci [Briand a kol., 1995] autori zaviedli dostatočne všeobecný model na popis vlastností charakterizujúcich jednotlivé atribúty (pomenované ako „koncepty“) softvérového systému. Model je založený na popise systému pomocou orientovaného grafu, v ktorom uzly predstavujú jednotlivé moduly systému na vybranej úrovni abstrakcie a hrany vyjadrujú vzťahy medzi nimi. Na základe tejto reprezentácie autori definovali axiómy pre
<strong>Meranie</strong> v etape návrhu 101 niektoré významné koncepty merania, ako sú veľkosť, dĺžka, zložitosť, súdržnosť a zviazanosť. Pomocou týchto axióm je možné overiť, či metrika spĺňa vlastnosti týkajúce sa konceptu, pre ktorý je navrhovaná. Návrh systému sa vykonáva v troch na seba nadväzujúcich fázach [Salamon94]: • Predbežný návrh. V tejto fáze sa príbuzné požiadavky zoskupujú do funkčných celkov a identifikujú sa závislosti medzi funkciami. Predbežný návrh môže byť reprezentovaný diagramami toku dát, štruktúrnymi diagramami na vysokej úrovni abstrakcie, alebo jednoduchým zoznamom požiadaviek kladených na podsystémy [Salamon94]. Výber metrík závisí od zvolenej reprezentácie systému. Napríklad pri reprezentácii pomocou diagramu toku údajov je možné merať zložitosť informačných tokov. • Podrobný návrh. Pri podrobnom návrhu sa definuje celková architektúra softvérového systému. Funkcie a údaje sa prideľujú k jednotlivým častiam systému, definujú sa vnútorné rozhrania. Na reprezentáciu návrhu systému v tejto fáze sa najčastejšie používajú štruktúrne diagramy. Metriky, ktoré sa používajú v tejto fáze, sú napríklad zložitosť informačných alebo dátových tokov, metrika externej zložitosti, zložitosť odvodená na základe reprezentácie pomocou grafov a iné. • Návrh softvérových súčiastok. V tejto fáze sa definujú algoritmy a údajové štruktúry, ako aj implementačné detaily. Návrh je reprezentovaný pseudokódom alebo popisom modulov v prirodzenom jazyku. Okrem návrhu v týchto troch fázach je možné hovoriť aj o návrhu používateľského rozhrania ako oddelenej oblasti, ktorá ma veľký vplyv na konečné hodnotenie produktu používateľom. Pri návrhu používateľského rozhrania sa špecifikujú entity používateľského rozhrania (napríklad obrazovky) a ich vzájomné prepojenie. Reprezentácia návrhu používateľského rozhrania je viazaná na typ rozhrania, často sa však používajú diagramy používateľského rozhrania. Používanými metrikami sú napríklad plytkosť rozhrania, kompaktnosť a navigovateľnosť smerom dole, navrhnuté pre hypermediálne systémy. Tieto metriky zohľadňujú jednak kognitívnu záťaž na používateľa, jednak zložitosť štruktúry hypermediálneho obsahu. Niektoré metriky používané v etape návrhu Metriky pre zložitosť Slovník IEEE [IEEEGLOSS] definuje zložitosť ako mieru toho, ako je návrh systému alebo komponentu ťažké porozumieť alebo preveriť.
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: Meranie v etape návrhu Stanislav H
Page 113 and 114: Meranie v etape návrhu 103 Metrika
Page 115 and 116: Meranie v etape návrhu 105 Pomocou
Page 117 and 118: Meranie v etape návrhu 107 Funkcio
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?