(3 - Metryki jako\234ci \346wiczenia)

Metryki jakości oprogramowania – ćwiczenia

Kryteria jakości, a niedociągnięcia

w oprogramowaniu

Wyznaczanie poziomu jakości

serwisu oprogramowania

Wyznaczanie wskaźnika problemów

klienta

Porównywanie awaryjności

oprogramowań

Wyznaczanie ilości błędów i

defektów w oprogramowaniu

W. 0 – kryteria jakości oprogramowania

Firma ABC wyprodukowała oprogramowanie, jednak
zidentyfikowano w nim następujące niedociągnięcia:

- brak modułowej budowy programu

- brak kreatora instalacji programu

- brak szyfrowania hasła podczas procedury logowania

- wykorzystanie nieoptymalnych algorytmów

- niemożliwość odzyskania danych utraconych w wyniku
awarii programu

- zbyt lakoniczna dokumentacja

Na niekorzyść jakich kryteriów jakości zewnętrznej i
wewnętrznej oprogramowania świadczą znalezione ubytki?
Do każdego kryterium podaj najlepiej odpowiadającą mu
charakterystykę szczegółową.

W. 0 – kryteria jakości oprogramowania

Kolejnym niedociągnięciom przyporządkujemy
odpowiednie kryteria i charakterystyki, na niekorzyść
których one wpływają:

- brak modułowej budowy programu

(PIELĘGNOWALNOŚĆ ---> modyfikowalność)

- brak kreatora instalacji programu

(PRZENOŚNOŚĆ ---> instalowalność)

- brak szyfrowania hasła podczas procedury logowania

(FUNKCJONALNOŚĆ ---> bezpieczeństwo)

W. 0 – kryteria jakości oprogramowania

- wykorzystanie nieoptymalnych algorytmów

(SKUTECZNOŚĆ ---> przepustowość)

- niemożliwość odzyskania danych utraconych w wyniku
awarii programu

(NIEZAWODNOŚĆ ---> odtwarzalność)

- zbyt lakoniczna dokumentacja

(UŻYTECZNOŚĆ ---> zrozumiałość)

W. 1 – problemy klienta i ich rozwiązywanie

Firma ABC do tej pory sprzedała łącznie 200 licencji na
oprogramowanie GAMMA.

Od 1 stycznia do 31 marca zgłoszono 42 problemy - w tym
czasie 25 tych problemów naprawiono z pozytywnym
skutkiem.

Poza tym 2 wydane poprawki nie naprawiły problemów, a 5
wydanych poprawek naprawiło zgłoszony problem ale
spowodowało wystąpienie innego. Pozostałych problemów
w danym czasie nie udało się naprawić.

Wyznacz i zinterpretuj następujące metryki:

- wskaźnik problemów klienta

- wskaźnik zarządzania opóźnieniem napraw (dla LCL=65%)

- odsetek źle wykonanych napraw

W. 1 – problemy klienta i ich rozwiązywanie

Obliczymy najpierw wskaźnik problemów klienta (PUM):

Wartość wskaźnika problemów klienta jest stosunkowo
niska (poniżej 10%), a więc akceptowalna –
oprogramowanie nie sprawia zbyt wielu problemów
użytkownikom.

problemów

wykrytych

liczba

600

200

licencji

miesiecy

liczba

⋅

600

PUM

W. 1 – problemy klienta i ich rozwiązywanie

Sprawdźmy teraz czy zgłaszane przez użytkowników
problemy są na bieżąco rozwiązywane (wskaźnik BMI):

Do problemów rozwiązanych zaliczamy tylko te naprawy,
które rozwiązały zgłoszony problem nie powodując innego.

problemów

rozwiazany

liczba

problemów

zgloszonyc

liczba

≈

BMI

W. 1 – problemy klienta i ich rozwiązywanie

Wartość wskaźnika zarządzania opóźnieniem napraw jest
umiarkowanie wysoka (im większa, tym lepiej) i wynosi 60%.

Jednak z drugiej strony oznacza to, że 40% problemów nie
zostało rozwiązanych w ciągu analizowanego okresu (3
miesiące). Dla zwiększenia dokładności analizy należałoby
sprawdzić, czy są to problemy zgłoszone pod koniec tego
okresu – wówczas może to podwyższyć ocenę jakości
procesu serwisowania.

Dodatkowo wartość BMI jest mniejsza niż założona przez
organizację ABC dolna granica kontrolna (BMI < LCL=65%),
więc należy niezwłocznie przyspieszyć proces efektywnego
rozwiązywania problemów klienta.

W. 1 – problemy klienta i ich rozwiązywanie

Sprawdźmy również ile spośród wykonanych napraw
zostało źle wykonanych, obliczając odsetek źle
wykonanych napraw.

le wykonane naprawy to takie, które nie rozwiązują

głównego problemu, bądź rozwiązując go powodują
wystąpienie innego.

Odsetek źle wykonanych napraw wynosi

napraw

wykonanyc

liczba

napraw

wykonanyc

liczba

≈

W. 1 – problemy klienta i ich rozwiązywanie

Zatem 22% wszystkich napraw w ciągu analizowanego
okresu zostało źle wykonanych.

Wartość ta powinna być bardzo bliska zero, gdyż każda źle
wykonana naprawa bardziej psuje jakość (oraz wizerunek
firmy w oczach klienta) niż niewykonanie naprawy w
terminie.

W związku z tym w badanej firmie należałoby poświęcić
więcej uwagi analizie zgłoszonych problemów, w celu
prawidłowego ich rozwiązywania.

W. 1 – problemy klienta i ich rozwiązywanie

Podsumowując, 60% problemów rozwiązano poprawnie i w
terminie (BMI=60%), jednak jest to za mało w stosunku do
ustalonego limitu kontrolnego (LCL=65%). Natomiast
pozostałe 40% problemów w dalszym ciągu z różnych
powodów czeka na naprawę.

Końcowy wniosek analizy jest taki, że w organizacji ABC
należy zdecydowanie podnieść jakość serwisowania
oprogramowania.

W. 2 – czas pracy do wystąpienia awarii

Oprogramowanie ALFA stworzone przez firmę ABC w fazie
testowania ma awarię średnio przez 0,25 sekundy w ciągu
minuty.

Natomiast oprogramowanie BETA ma
prawdopodobieństwo bezawaryjności równe 0,996.

Które oprogramowanie na obecnym etapie rozwoju jest
bardziej niezawodne?

W. 2 – czas pracy do wystąpienia awarii

W celu porównania niezawodności oprogramowania ALFA
oraz BETA należy w obu przypadkach wyrazić poziom
awaryjności w tych samych jednostkach.

Niech będzie to prawdopodobieństwo wystąpienia awarii.
Obliczmy zatem prawdopodobieństwo wystąpienia awarii
dla oprogramowania ALFA:

0042

240

sek

min

sek

)

(

≈

ALFA

awaria

W. 2 – czas pracy do wystąpienia awarii

Wyznaczmy teraz prawdopodobieństwo awaryjności
oprogramowania BETA:

Zatem prawdopodobieństwo wystąpienia awarii jest
nieznacznie większe dla oprogramowania ALFA, więc
bardziej niezawodne jest aktualnie oprogramowanie BETA
(chociaż różnica jest bardzo niewielka).

004

996

)

(

)

(

−

BETA

bezawar

awaria

0042

)

(

ALFA

awaria

W. 3 – błędy i defekty w oprogramowaniu

W przykładowym "miniaturowym" programie napisanym w
języku PHP:

- popraw wszystkie błędy składniowe (te, które
uniemożliwiają kompilację)

- następnie wyznacz metrykę częstości występowania
defektów

- wskaż w kodzie te defekty, które spowodują awarię
programu

W. 3 – błędy i defekty w oprogramowaniu

Błędy składniowe w programie napisanym w konkretnym
języku uniemożliwiają kompilację i uruchomienie
programu. Jednak nie są one traktowane jako defekty.

Defekty są bowiem nieprawidłowościami występującymi
podczas działania programu. Można je zatem analizować
dopiero po uruchomieniu programu, a więc po poprawieniu
błędów składniowych.

W. 3 – błędy i defekty w oprogramowaniu

Częstość defektów wyliczamy przy pomocy wzoru:

Jako miarę sposobności popełnienia defektu można
przyjąć liczbę linii kodu. Jednak policzenie wszystkich linii
jako sposobności popełnienia błędu byłoby nieobiektywne.

Dlatego warto policzyć tylko linie z konkretnymi
instrukcjami, a także deklaracje funkcji (bez nawiasów
klamrowych, komentarzy, pustych linii).

W. 3 – błędy i defekty w oprogramowaniu

Zgodnie z omówionym podejściem można wyróżnić od 21
do 24 linii kodu – przyjmijmy, że będą to 24 linie.

Po poprawieniu błędów składniowych w kodzie znaleziono
12 defektów.

Dlatego częstość defektów wynosi

Zatem częstość występowania defektów jest bardzo duża –
połowa programu (w sensie kodu źródłowego) jest
nieprawidłowo napisana. Program bezwzględnie wymaga
poprawy.

W praktyce, tak wysoki poziom występowania defektów
jest usprawiedliwiony tylko w przypadku, gdy autorem
programu jest osoba ucząca się programować.