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 ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Meranie</strong> pri testovaní, prevádzke a údržbe softvérových systémov 129<br />
ďalšie chyby. Namiesto toho treba zadať žiadosť na zmenu a pri kontrole<br />
akosti potom zistia, či nájdenú chybu treba opraviť alebo nie.<br />
Softvérové metriky zložitosti úzko súvisia s poruchami, ktoré sa<br />
vyskytujú v jednotlivých moduloch softvérového systému. Je priamy<br />
vzťah medzi niektorými metrikami zložitosti a medzi počtom attribútov<br />
pre poruchu, ktoré môžeme nájsť počas testovania systému. Iste totiž<br />
platí, že čím sú jednotlivé moduly zložitejšie, tým je pravdepodobnejšie,<br />
že nastane porucha.<br />
Lipow vytvoril model, ktorý predpovedá počet porúch softvérového<br />
systému pre jednotlivé riadky. Tento model je založený na Halsteadovej<br />
softvérovej metrike. Crawford našiel viaceré metriky pre vyjadrenie<br />
zložitosti softvéru, ktoré podávajú ešte lepšie výsledky ako metriky<br />
založené na počte riadkov [Munson92].<br />
Ako sme už povedali, v praxi niektoré chyby úmyselne nie sú<br />
odstránené. Z tohto zdôvodu má zmysel hovoriť o počte známych<br />
neodstránených chýb. Ak vážime počet chýb závažnosťou ich dôsledkov,<br />
môžeme dosiahnúť ešte lepšiu porovnateľnosť. Na ohodnotenie môžeme<br />
používať napr. trojstupňovú ordinálnu mierku (pozri [Varga99]).<br />
Ďalšia metrika, ktorú môžeme merať počas testovania je podiel<br />
bezchybných testovacích behov k celkovému počtu testovacích behov,<br />
ktorá sa využíva na predpovedanie spoľahlivosti softvéru. Miera je<br />
normalizovaná do intervalu . Problém je v tom, že hodnota tejto<br />
metriky závisí nielen od kvality softvéru, ale aj od toho, ako dobre bol<br />
otestovaný daný softvérový systém. Aby sme vedeli určiť mieru ako dobre<br />
bol daný softvérový systém otestovaný, potrebujeme poznať nielen počet<br />
nájdených chýb ale aj počet všetkých chýb v softvéri. Bohužiaľ, počet<br />
všetkých chýb sa dá iba odhadnúť, na čo sa používajú rôzne metódy.<br />
Jedna z najznámejších je tzv. úmyselné včlenenie známeho počtu<br />
chýb do softvéru pred testovaním. Na to sa používa vzťah:<br />
N = A.<br />
B / C<br />
kde A je počet všetkých vložených chýb, B je počet všetkých chýb,<br />
ktoré sme našli počas testovania, C je počet nájdených vložených chýb a<br />
N je odhad celkového počtu chýb v softvéru.<br />
Ďalšia metóda, ktorú môžeme používať na zistenie rozsahu<br />
otestovania je tzv. analýza pokrytia. Pri tejto metóde sa určí podiel<br />
testami pokrytých prvkov vnútornej štruktúry programu ako sú: príkazy,<br />
vetvenia, úseky medzi vetveniami, atď [Varga99].<br />
<strong>Meranie</strong> počas prevádzky<br />
Prirodzenou mierou kvality softvéru v prevádzke je počet zlyhaní a<br />
porúch, ktoré nastanú počas prevádzky softvéru. Je veľmi dôležité, aby<br />
boli správne klasifikované tieto nedostatky. Kým poruchy ovplyvňujú<br />
použiteľnosť systému, zlyhania charakterizujú spoľahlivosť systému<br />
[Varga99]. Na modelovanie spoľahlivosti sa používajú matematické
Change language