Team Se@Msi: Meranie v softvérovom inžinierstve. - FIIT STU ...
Team Se@Msi: Meranie v softvérovom inžinierstve. - FIIT STU ...
Team Se@Msi: Meranie v softvérovom inžinierstve. - FIIT STU ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
6 Eseje<br />
To znamená, že zmena v jednej časti systému nevyžaduje ďalšie zmeny<br />
v ostatných častiach. Pán Boehm už v roku 1987 zaznamenal, že ak sa<br />
chceme vyhnúť drahým opravám, treba sa zamerať na skorú verifikáciu,<br />
validáciu a na prototypovanie zhora nadol. Druhá rada je, že dobrým<br />
architektonickým návrhom môžeme značne redukovať faktor<br />
stupňovania nákladov aj pre veľké systémy. Dobrým príkladom na to je<br />
milión riadkový TRW CCPDS-R systém uvedený v knihe s názvom<br />
Software Project Management, ktorej autorom je Walker Royce. Faktor<br />
zvýšenia nákladov v uvedenom systéme bol iba 2:1.<br />
Tento jav – oprava chýb po predaji – sa môže vyskytnúť aj v iných<br />
odvetviach. Zoberme si len nedávny prípad s prvými procesormi typu<br />
Pentium, u ktorých výsledky niektorých matematických operácii boli<br />
nepresné. Napriek tomu vlastníci procesorov ich používali a často ani<br />
nezbadali tú malú chybičku. Opraviť chybu v návrhu procesora určite<br />
nestálo veľa peňazí, ale už výmena vydaných procesorov dotyčnú firmu<br />
stálo oveľa viac, lebo procesory musela znovu vyrobiť a bezplatne<br />
vymeniť. Oprava chýb v softvérových systémoch takisto vyžaduje<br />
finančné náklady, ale cena výmeny (zavedenie produktu do prevádzky) je<br />
oveľa nižšia v porovnaní s hardvérovými súčiastkami (alebo produktmi z<br />
iných odvetví). Na opravu chýb treba vynaložiť dosť veľké úsilie. Autori v<br />
[Boehm01] hovoria, že 40-50% vynaloženého úsilia ide na prácu, ktorá<br />
nie je nevyhnutná. Táto práca je spôsobená vyskytnutými chybami,<br />
nečakanými procesmi. Keď zoberieme pravidlo rozdelenia úsilia na<br />
jednotlivé etapy vývoja, t.j. 1/3 návrh, 1/6 implementácia, 1/4 testovanie<br />
modulov a 1/4 testovanie systému, vyjde, že 50 percent celkového úsilia<br />
treba vynaložiť na testovanie produktu. Je to len náhoda, že odhad týchto<br />
dvoch hodnôt je rovnaký Priznajme si, že na testovanie produktov<br />
nevynaložíme toľko úsilia, ako by bolo potrebné. S tým úzko súvisia aj<br />
rôzne zanedbania ošetrení chýb pri programovaní, ktoré môžu spôsobiť<br />
vážne chyby v správaní programu.<br />
Zo štúdií niekoľkých projektov sa zistil nasledujúci zoznam tried chýb<br />
[Basili84]:<br />
• chybné a nepochopené požiadavky<br />
• chybná a nepochopená funkcionálna špecifikácia<br />
• zlý návrh niekoľkých komponentov (nesprávny predpoklad o hodnote<br />
štruktúry alebo údajov, nesprávne riadenie, zlý výpočet)<br />
• zlý návrh alebo zlá implementácia v jednom module<br />
• nepochopenie vonkajšieho prostredia<br />
• chyba v implementačnom jazyku, v prekladači<br />
• chyby, ktoré vznikli odstránením predošlých chýb<br />
Z analýzy rozdelenia chýb sa zistilo, že polovica chýb vznikne<br />
z chybných špecifikácií a z nepochopenia požiadaviek. Na korekciu týchto<br />
chýb je treba vynaložiť vyše 50% z celkového úsilia.
Change language