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

More documents

Recommendations

Info

6 Eseje To znamená, že zmena v jednej časti systému nevyžaduje ďalšie zmeny v ostatných častiach. Pán Boehm už v roku 1987 zaznamenal, že ak sa chceme vyhnúť drahým opravám, treba sa zamerať na skorú verifikáciu, validáciu a na prototypovanie zhora nadol. Druhá rada je, že dobrým architektonickým návrhom môžeme značne redukovať faktor stupňovania nákladov aj pre veľké systémy. Dobrým príkladom na to je milión riadkový TRW CCPDS-R systém uvedený v knihe s názvom Software Project Management, ktorej autorom je Walker Royce. Faktor zvýšenia nákladov v uvedenom systéme bol iba 2:1. Tento jav – oprava chýb po predaji – sa môže vyskytnúť aj v iných odvetviach. Zoberme si len nedávny prípad s prvými procesormi typu Pentium, u ktorých výsledky niektorých matematických operácii boli nepresné. Napriek tomu vlastníci procesorov ich používali a často ani nezbadali tú malú chybičku. Opraviť chybu v návrhu procesora určite nestálo veľa peňazí, ale už výmena vydaných procesorov dotyčnú firmu stálo oveľa viac, lebo procesory musela znovu vyrobiť a bezplatne vymeniť. Oprava chýb v softvérových systémoch takisto vyžaduje finančné náklady, ale cena výmeny (zavedenie produktu do prevádzky) je oveľa nižšia v porovnaní s hardvérovými súčiastkami (alebo produktmi z iných odvetví). Na opravu chýb treba vynaložiť dosť veľké úsilie. Autori v [Boehm01] hovoria, že 40-50% vynaloženého úsilia ide na prácu, ktorá nie je nevyhnutná. Táto práca je spôsobená vyskytnutými chybami, nečakanými procesmi. Keď zoberieme pravidlo rozdelenia úsilia na jednotlivé etapy vývoja, t.j. 1/3 návrh, 1/6 implementácia, 1/4 testovanie modulov a 1/4 testovanie systému, vyjde, že 50 percent celkového úsilia treba vynaložiť na testovanie produktu. Je to len náhoda, že odhad týchto dvoch hodnôt je rovnaký Priznajme si, že na testovanie produktov nevynaložíme toľko úsilia, ako by bolo potrebné. S tým úzko súvisia aj rôzne zanedbania ošetrení chýb pri programovaní, ktoré môžu spôsobiť vážne chyby v správaní programu. Zo štúdií niekoľkých projektov sa zistil nasledujúci zoznam tried chýb [Basili84]: • chybné a nepochopené požiadavky • chybná a nepochopená funkcionálna špecifikácia • zlý návrh niekoľkých komponentov (nesprávny predpoklad o hodnote štruktúry alebo údajov, nesprávne riadenie, zlý výpočet) • zlý návrh alebo zlá implementácia v jednom module • nepochopenie vonkajšieho prostredia • chyba v implementačnom jazyku, v prekladači • chyby, ktoré vznikli odstránením predošlých chýb Z analýzy rozdelenia chýb sa zistilo, že polovica chýb vznikne z chybných špecifikácií a z nepochopenia požiadaviek. Na korekciu týchto chýb je treba vynaložiť vyše 50% z celkového úsilia.
Chyby v procese tvorby softvéru a ich príčiny 7 Okolo 80% nepotrebnej práce, ktorá vzniká opravou chýb spočíva v odstraňovaní 20% chýb. Číslo 80% samozrejme závisí od veľkosti systému, ale sa netreba hrať na maličké percentá, hlavný je pomer. Rýchla špecifikácia požiadaviek, návrh a vývoj zvyčajne zapríčiňujú hlavné chyby v architektúre, v návrhu a v kóde, ktorých dôvodom je neskoré prispôsobenie požiadaviek. Veľkú úsporu vynaloženého úsilia môžeme získať zdokonaľovaním vyspelosti softvérových procesov, softvérových architektúr a manažmentu rizík, ktorý vzniká z nadbytočnej práci. Z uvedených pravidiel jednoznačne vyplýva, že presnou špecifikáciou, zameranou na nejednoznačné časti systémov znížime počet vyskytnutých chýb, nedostatkov. Keďže mnoho zákazníkov nevie jednoznačne vyjadriť svoje požiadavky, počas vývoja sa treba zamerať aj na rýchle a skoré prototypovanie. Dobre vytvorené prototypy pomôžu lepšie identifikovať nedostatky (nepreskúmané možnosti) v systémoch a to nielen nám, ale aj zákazníkom. S tým docielime zníženie počtu chýb, ktorých odstránenie vyžaduje značnú časť celkového úsilia. Tento názor potvrdzuje aj pravidlo, že väčšina chýb vzniká v 20% modulov a asi polovica modulov je bezchybná. Kontrola, ako riešenie Je dané, že skoré zachytenie a oprava mnohých chýb v životnom cykle projektu je viac cenovo efektívna, ako zachytenie neskôr. Pokúšame sa teda nájsť chyby čím skôr. Mnoho výskumov potvrdilo tvrdenie pána Boehma, že opätovná kontrola zachytí 60% chýb. Výsledkom výskumov je, že vizuálna kontrola a testovanie zachytí rozličné triedy chýb v rozličných bodoch v životnom cykle. Taktiež sa zistilo, že riadenou kontrolou identifikujeme o jednu tretinu viac chýb, než neriadenou kontrolou. Vzniká teda potreba empirického výskumu na výber najlepšej stratégie pri hľadaní chýb. Basili [Basili97] uvádza metódu snímania založenú na scenároch, ktorá ponúka množinu formálnych postupov pre detekciu nedostatkov. Tieto techniky sa používajú pri odstraňovaní nedostatkov počas vývoja softvéru – pri špecifikácii požiadaviek, pri objektovo-orientovanom návrhu a pri kontrole používateľského rozhrania. Podobne je potvrdené, že disciplinované osobné prevádzkové predpisy (dobré organizovanie) môžu redukovať výskyt chýb až o 75%. Hypotéza Harlana Millsa hovorí, že ľudia nekontrolujú tak ako by mali, lebo veria, že testovanie odhaľuje chyby za nich. Dokazovanie tejto hypotézy bolo jednoduché: ľudia, ktorí čítali (kontrolovali) a vedeli, že nemôžu testovať, robili to dôslednejšie, pozornejšie než tí, ktorí vedeli, že môžu testovať neskôr. Každý môže cítiť tento vplyv na človeka aj na vlastnej koži. Pri písaní programov (resp. textov) urobíme preklepy, ktoré si pri pozornej vizuálnej kontrole všimneme a opravíme, inak to necháme na kompilátor (resp. zapneme kontrolu pravopisu). Síce syntaktické analyzátory odhalia syntaktické chyby, ale chyby v sémantike už neodhalia. Teda môžeme konštatovať, že vizuálna kontrola je
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: Chyby v procese tvorby softvéru a
Page 19 and 20: Chyby v procese tvorby softvéru a
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 69 and 70:
Page 71 and 72:
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:
Page 83:
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 104 and 105:
Page 106 and 107:
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 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:
Page 127:
Page 130 and 131:
120 Meranie a životný cyklus soft
Page 132 and 133:
Page 134 and 135:
Page 137 and 138:
Meranie pri testovaní, prevádzke
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Meranie vyspelosti softvérového p
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
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?