Metryki jakości

Metryki jakości to miary pewnych własności
produktu, które są istotne dla jego jakości.

Termin ten nie ma opracowanej precyzyjnej
definicji, jednak intuicyjnie najczęściej oznacza on
wyznaczenie konkretnej wartości liczbowej według
określonych przepisów, charakteryzującej
określony produkt.

Na podstawie tej wartości można zinterpretować
poziom jakości produktu.

Metryki jakości

Cel stosowania metryk

różnorodne oszacowania

kontrola zaawansowania prac

określenie złożoności projektu

kontrola jakości

analiza ryzyka

walidacja metod projektowania

podstawa dla wypracowywania decyzji

Metryki jakości

Metryki dotyczą

produktów projektowych



np. kwestie rozmiaru, złożoności, wydajności
produktu

procesów projektowych



np. wzorce i efektywność wykrywania usterek,
czas potrzebny na usunięcie usterki

projektów (jako przedsięwzięć)



np. liczba osób w zespole produkcyjnym,
programy zatrudnień, harmonogramy, koszty,
ocena wydajności projektu

Metryki jakości

Kryteria oceny metryk

Obiektywność



oparcie na bezpośrednich atrybutach produktu np. dla
oprogramowania: liczba linii kodu, czas testowania

Obserwowalność



metryka może być wyprowadzona na podstawie
istniejących już produktów projektowych

Użyteczność



dobrze skorelowana z procesem produkcyjnym np.
kosztem, czasem, pracochłonnością

Rodzaje metryk jakości

Metryki wewnętrzne

Specyfikacja wymagań

Ocena jakości kodu źródłowego

Raport z przeglądu

Metryki zewnętrzne

Raport z analizy problemu

Raport z testów oprogramowania

Metryki użycia

Raport z obserwacji użytkowników

Monitoring użycia (np. czas miesięcznego użycia

aplikacji)

Metryki jakości oprogramowania

Jakość oprogramowania = jakość produktu + satysfakcja klienta

Można zaproponować metryki jakości oprogramowania
uwzględniające następujące aspekty:

Średni czas bezawaryjnej pracy oprogramowania (MTTF)

Częstość defektów występujących w oprogramowaniu

Problemy klienta

Satysfakcja klienta

Serwisowanie oprogramowania

Ś

redni czas bezawaryjnej pracy (ang. Mean time to

failure - MTTF)

Określenie to oznacza średni czas pracy oprogramowania

bez przerwy, aż do momentu wystąpienia awarii.

Poprzez awarię rozumiemy stan, w którym dowolna jednostka

funkcyjna programu nie jest w stanie pełnić swojej funkcji w
pewnym zakresie bądź wcale (klasycznym przykładem
całkowitej awarii jest „zawieszenie się” całego programu).

Najczęściej stosowaną jednostką jest w tym przypadku

godzina, przy czym najczęściej średnią bezawaryjność
powinno mierzyć się w dziesiątkach tysięcy, jeśli nie w
milionach godzin

.

Ś

redni czas bezawaryjnej pracy

Współczynnik MTTF oparty jest zwykle na intensywnych

badaniach bądź przewidywaniach jeśli chodzi o
niezawodność produktu.

Jego wartość nie jest jednak związana z jakąkolwiek

gwarancją, np:



To, że dla danego produktu „MTTF = 5 lat” nie oznacza,
ż

e tyle ma trwać gwarancja na ten produkt. Nie oznacza to

również, że produkt będzie w ciągu tych 5 lat na pewno
poprawnie funkcjonował (jako, że wynik stanowi średnią).

Na podstawie współczynnika MTTF można dla danego

produktu wyznaczyć prawdopodobieństwo wystąpienia awarii.

Ś

redni czas bezawaryjnej pracy

Metrykę MTTF stosuje się zarówno dla software jak też

hardware.

Dla software (oprogramowanie) często wyznacza się czas

awaryjności w ciągu określonej jednostki czasu (np. 1
sekunda w ciągu doby czyli prawdopodobieństwo wystąpienia
awarii wynosi 1 : 86 400).

Dla hardware (np. dyski twarde) często wyznacza się

bezpośredni czas bezawaryjności (np. 200 000 godzin).

Ś

redni czas bezawaryjnej pracy

Metrykę MTTF stosuje się przede wszystkim w systemach o

wysokim priorytecie bezpieczeństwa, gdzie od wysokiej
bezawaryjności zależy czasem życie ludzkie, np:



kontrola ruchu linii lotniczych



systemy sterowania uzbrojeniem

Np. Czas niesprawności systemu kontroli lotu rządu USA nie

może przekraczać 3 sekund w ciągu roku, czyli
prawdopodobieństwo wystąpienia awarii ma się jak

3 : 31 536 000.

Częstość defektów

Wyraża się jako stosunek liczby wykrytych w oprogramowaniu

defektów do sposobności ich popełnienia.

Sposobność popełnienia defektów oznacza w praktyce liczbę

linii kodu albo liczbę punktów funkcyjnych.

Defekty rozumiemy tu jako nieprawidłowości (anomalia) w

działaniu oprogramowania.

Niektóre defekty mogą doprowadzić do powstania awarii (np.

nieskończona rekurencja może zawiesić program).

Liczba linii kodu

Liczba linii kodu jest najwiarygodniejszym miernikiem

sposobności popełnienia defektów dla języków
programowania niskiego poziomu (np. Assembler), gdzie
każda linia kodu jest konkretną instrukcją dla procesora,
więc stanowi realną okazję do wystąpienia defektu.

Liczba linii kodu

Natomiast w językach wysokiego poziomu (np. C++) liczba

wszystkich linii kodu przestaje być obiektywnym miernikiem,
gdyż np. w liniach kodu z deklaracją zmiennych (typu „int a;”)
albo komentarzami trudno o wystąpienie realnego defektu.

W tym przypadku można stosować dobór odpowiadających

nam subiektywnie typów linii kodu (np. wszystkie albo nawet
tylko niektóre wykonywalne linie kodu – czyli na pewno bez
komentarzy, nawiasów klamrowych, itp.).

Liczba punktów funkcyjnych

Alternatywną miarą sposobności popełnienia defektów w

językach wysokiego poziomu jest wyznaczenie liczby punktów
funkcyjnych w aplikacji.

Metoda ta polega na podzieleniu oprogramowania na różne

części składowe, a następnie ocenie stopnia złożoności
każdej z tych części jako łatwego, średniego lub trudnego
(ocena jest subiektywna, gdyż dokonują jej zwykle twórcy
kodu).

Ostatecznie w zależności od ustalonego stopnia złożoności,

każdej części składowej oprogramowania przyznaje liczbę
punktów funkcyjnych według ustalonej skali, otrzymując w ten
sposób sumę wszystkich punktów funkcyjnych.

Problemy klienta

Metryka problemów klienta ukazuje stopień w jakim wykonane
oprogramowanie sprawia realne problemy klientom, a w związku
z tym pokazuje czy oprogramowanie jest przyjazne klientowi.

Potencjalne problemy, na które napotyka klient najczęściej

należą do następujących dziedzin:



Niejasna dokumentacja



Trudności w obsłudze



Błędy użytkownika

Z punktu widzenia klienta problemami nie są bezpośrednio defekty kodu.

Problemy klienta

Jeśli wskaźnik PUM > 1, to można wysnuć wniosek, że

wytworzone oprogramowanie może nie być przyjazne dla
użytkownika

By obniżyć wartość PUM można zastosować strategie:



Redukcja liczby defektów



Poprawienie dokumentacji



Poprawienie interfejsu programu (łatwości obsługi)



Szkolenia i wsparcie dla klientów



Wzrost sprzedaży produktów (rozwiązanie doraźne)

Satysfakcja klienta

Najpopularniejszą metodą sprawdzania poziomu satysfakcji

klienta jest przeprowadzenie ankiet konsumenckich,
najczęściej z pięciostopniową skalą odpowiedzi:



Bardzo zadowolony



Zadowolony



Neutralny



Niezadowolony



Bardzo niezadowolony

Satysfakcja klienta

Poziom satysfakcji klienta płynącej z użytkowania

oprogramowania należy sprawdzić pod kątem następujących
jego cech:



Funkcjonalność



Łatwość obsługi



Wydajność



Niezawodność



Łatwość instalacji



Dokumentacja



Serwis



(ewentualnie) inne aspekty użytkowania

Satysfakcja klienta

Na podstawie ankiet można uzyskać różne metryki satysfakcji

klienta; najczęściej będą do nich należały:



Odsetek tylko całkowicie zadowolonych



Odsetek usatysfakcjonowanych (zadowoleni i bardzo
zadowoleni)



Odsetek nieusatysfakcjonowanych (neutralnych,
niezadowolonych i bardzo niezadowolonych)

Metryki serwisowe oprogramowania

Po zakończeniu produkcji oprogramowania rozpoczyna się

jego faza serwisowa, której jakość można zobrazować
poprzez metryki serwisowe, do których należą m.in. :



Wskaźnik zarządzania opóźnieniem napraw



Ilość niewykonanych w terminie napraw problemów o
danym priorytecie



Odsetek źle wykonanych napraw

Wskaźnik zarządzania opóźnieniem napraw (ang.

Backlog management index – BMI)

Wskazuje on stopień opóźnienia napraw dotyczących

zgłoszonych przez klientów problemów z oprogramowaniem,
czyli pokazuje czy naprawy wykonywane są w należytym
terminie.

Często organizacje wytwarzające oprogramowanie przyjmują

granice kontrolne, zarówno z dołu (LCL) jak i z góry (UCL),
czyli spełniony będzie warunek (LCL < BMI < UCL). Są to
innymi słowy subiektywnie wyznaczane granice
akceptowalnych dla danej organizacji wartości współczynnika
BMI.

Ilość niewykonanych w terminie napraw problemów

o danym priorytecie

Problemom zgłaszanym przez klientów można

przyporządkować priorytety (wagi – np. w skali od 1 do 5) pod
względem ich złożoności czy też istotności dla poprawnego
działania oprogramowania.

Wówczas dla problemów o określonym priorytecie można

ustalić pewien okres czasu, w którym problem powinien zostać
rozwiązany – począwszy od zgłoszenia problemu aż do
udostępnienia poprawki zamykającej defekt.

Istotną kwestią dla jakości oprogramowania może być

monitorowanie wartości metryki ilości niewykonanych napraw
zgłoszonych problemów o danym priorytecie.

Odsetek źle wykonanych napraw

Źle wykonana naprawa oznacza wykonaną (zakończoną)

„pseudo-naprawę” zgłoszonego problemu, polegającą na
wydaniu poprawki, która nie likwiduje istniejącego problemu
albo likwidując go, powoduje powstanie innego problemu.

Odsetek źle wykonanych napraw oznacza stosunek liczby źle

wykonanych napraw do liczby wszystkich wykonanych napraw
(zwykle w danym okresie czasu).

Kryteria jakości w pytaniach

Czy wytwarzane przez nas oprogramowanie:

Robi to czego chcemy?

Robi to czego chce użytkownik?

Będzie działać na naszym sprzęcie?

Będzie wykorzystywać nasz sprzęt efektywnie?

Będzie działać na innym sprzęcie?

Jest bezpieczne?

Nie ma błędów?

Jest niezawodne?

Można łatwo naprawić?

Można łatwo pielęgnować?

Można łatwo zmienić?

Można łatwo testować?

...

Podsumowanie

Jakość wbudowuje się w oprogramowanie

w fazie projektowania i wykonania

Jakość oprogramowania to suma

pożądanych cech jakości

Kryteria jakości zapewniają względną

obiektywność ocen produktów

Oprogramowanie nie starzeje się, każda

wada wskazuje na błąd projektowy lub
wykonania

Metryki pozwalają uporządkować produkty

różnej jakości w wymiarze związanym z
określonym kryterium