21 KiB
Przygotowanie do projektu badawczo-rozwojowego
12. Ocena jakości systemu informatycznego[wykład]
Krzysztof Jassem (2021)
1. Czym jest jakość produktu?
Definicja wg Toma de Marco
Jakość produktu to funkcja tego, jak bardzo zmienia on świat na lepsze.Definicja wg Geralda Weinberga
Jakość to subiektywnie pojmowana wartość.Definicja wg Josepha Jurana
1. Jakość składa się z tych cech produktu, które spełniają potrzeby klientów i dostarczają im satysfakcji. 2. Jakość to brak braków.Definicja wg Armanda Feigenbauma
Jakość to coś, co określa tylko i wyłącznie klient - a nie inżynier, dział marketiingu, czy też kierownictwo.Definicja wg Williama Edwardsa Deminga
Cała trudność w zdefiniowaniu jakości polega na przełożeniu przyszłych potrzeb użytkownika na wymierne cechy w taki sposób, aby produkt dawał klientowi satysfakcję za akceptowalną cenę.2. Definicja jakości oprogramowania
Jakość oprogramowania
Jakość oprogramowania to funkcja wypadkowa wartości określonych właściwości oprogramowania.2.1. Proces określania jakości oprogramowania
Proces określenia jakości oprogramowania składa się z dwóch etapów:
Zdefiniowanie funkcji jakości oprogramowania:
- Określ właściwości istotne dla danego typu oprogramowania (np. rozmiar, funkcjonalność, użyteczności, dostępność).
- Dla każdej włąsciwości zdefiniuj zakres wartości liczbowych lub kategorii, określających, w jakim stopniu spełnia ona oczekiwania użytkowników.
- Zdefiniuj jakość oprogramowania jako funkcję wartości poszczególnych właściwości:
Quality = q(wartości właściwości)
Ocena jakości oprogramowania
- Wyznacz wartości poszczególnych cech oprogramowania.
- Oblicz jakość oprogramowania za pomocą zdefiniowanej funkcji _Quality.
3. Jakość kodu źródłowego
Cechy kodu żródłowego:
- rozmiar,
- złożoność
3.1. Metryki rozmiaru kodu źródłowego
3.1.1. Liczba wierszy (LOC - Lines of Code)
LOC mierzy liczbę wierszy w metodzie, klasie lub całej aplikacji.
W obliczaniu LOC trzeba podjąć kilka nieoczywistych decyzji.
Przykłady:
Decyzja | Rekomendacja |
Czy liczyć puste wiersze? | NIE |
Czy liczyć komentarze? | NIE |
Czy liczyć liczbę wierszy czy liczbę instrukcji? | Liczbę wierszy |
Reguła 30
Jeśli element zawiera wiecej niż 30 podelementów, to najprawdopodobniej w działaniu wystąpi jakiś poważny problem.Methods should not have more than an average of 30 code lines (not counting line spaces and comments).
A class should contain an average of less than 30 methods, resulting in up to 900 lines of code.
A package shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines.
Subsystems with more than 30 packages should be avoided. Such a subsystem would count up to 900 classes with up to 810,000 lines of code.
A system with 30 subsystems would thus possess 27,000 classes and 24.3 million code lines.
Przeczytaj w Internecie
3.1.2. Punkty funkcyjne
Punkty Funkcyjne - metryka, która wyznacza liczbę funkcjonalności dostarczaną przez system.
Współczynnik produktywności języka programowania: ile (średnio) linii kodu potrzeba do zakodowania jednego punktu funkcyjnego?
Wartość kodu w punktach funkcyjnych wyznacza się, dzieląc wartośćLOC przez współczynnik produktywności.
Tablica produktywności języków programowania
![Tablica produktywności](/rjawor/aitech-pbr-rjawor/media/commit/7cbf0c11fe3ef8aee6b6676264c9531c98ab1891/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/LOC%20vs%20FP.jpg)
3.1.3. Liczba tokenów - metryka Halsteada
Metryka Halsteada wyznacza objętość (wielkość) kodu na podstawie liczby unikatowych tokenów. Wyróżniane są dwa typy tokenów:
operatory (funkcje, słowa kluczowe itp.),
operandy (zmienne, stałe, wartości).
Wartości metryk Halsteada (w przeciwieństwie do LOC) nie zależą od długości przyjętego nazewnictwa.
![Liczby tokenów](/rjawor/aitech-pbr-rjawor/media/commit/7cbf0c11fe3ef8aee6b6676264c9531c98ab1891/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/Halstead1.png)
Na podstawie liczby tokenów można oszacować objętość (wielkość) programu:
![wielkość programu](/rjawor/aitech-pbr-rjawor/media/commit/7cbf0c11fe3ef8aee6b6676264c9531c98ab1891/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/Halstead2.png)
3.2. Metryki oceny złożoności kodu źródłowego
3.2.1. Metryki złożoności Halsteada
Złożoność programu szacowana jest pod kilkoma aspektami - na podstawie liczby tokenów:
3.2.2. Złożoność cyklomatyczna
Złożoność cyklomatyczna określa liczbę niezależnych ścieżek przebiegu programu.
Jeśli program reprezentowany jest w postaci schematu blokowego (grafu), to:
CC = e - n + 2 * p
e – liczba krawędzi grafu
n – liczba węzłów grafu
p – liczba składowych grafu
Złożoność cykolmatyczną można łatwo wyliczyć na podstawie wzoru:
CC = d + 1, gdzie d oznacza liczbę węzłów decyzyjnych, np. instrukcji:
- if
- while
- for
- case
3.2.3. Uśrednione metody na klasę (Weighted Methods per Class - WMC)
Metryka uwzględnia zarówno liczbę metod w klasie, jak i ich złożoność cyklomatyczną: (n oznacza liczbę metod w klasie, a ci oznacza złożoność cykolomatyczną i-tej metody).
![Uśrednione metody na klasę](/rjawor/aitech-pbr-rjawor/media/commit/7cbf0c11fe3ef8aee6b6676264c9531c98ab1891/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/WMC.png)
3.2.4. Odpowiedzialność klasy (Response for a Class - RFC)
Metryka RFC oznacza całkowitą liczbę metod, które mogą być potencjalnie wywołane w odpowiedzi na komunikat odebrany przez obiekt klasy.
Wysoka wartość RFC oznacza większą funkcjonalność, ale zarazem i wyższą złożoność.
4. Właściwości produktu wpływające na ocenę jakości oprogramowania
4.1. Przydatność funkcjonalna (Functional Suitability - F)
Przydatność funkcjonalna określa stopień, w jakim program dostarcza oczekiwane funkcjonalności.
Wartość przydatności funkcjonalnej można wyznaczyć podczas testowania:
M = 1 - A/B
- A = funkcjonalności problemowe
- B = wszystkie testowane funkcjonalności
4.2. Niezawodność
Niezawodność określa prawdopodobieństwo, że wykonanie operacji przez program będzie bezbłędne.
Wartość niezawodności można wyznaczyć podczas testowania:
M = A/B
- A = liczba testów ukończonych pomyślnie,
- B = liczba wszystkich testów
4.3. Użyteczność (Usability - U)
Użyteczność określa łatwość użytkowania.
Wartość użyteczności można wyznaczyć podczas testów użyteczności:
M = A/B
- A = liczba funkcjonalności odkryta przez użytkownika,
- B = liczba wszystkich funkcjonalości.
4.4. Wydajność (Performance Efficiency)
Wydajność określa liczbę wykonanych operacji w odniesieniu do czasu i zużytych zasobów.
Przykładowe metryki pomiaru wydajności:
- Czas odpowiedzi: M = T1 (end) - T2 (start)
- Czas postoju: M = T1 (waiting time) / T2 (total time)
- Przepustowość = Liczba zadań wykonanych w jednostce czasu
- Zużycie pamięci (w bajtach)
4.5. Łatwość konserwacji (Maintainability - M)
Łatwość konserwacji to łatwość, z jaką program jest utrzymywany w celu:
- poprawiania błędów,
- wprowadzania nowych funkcji.
Przykładowa metryka: Ile czasu zajmuje średnio naprawienie błędu?
M = SUM(czas naprawy) / N
- N oznacza liczbę napraw
4.6. Przenośność (Portability - P)
Przenośność to Łatwość przenoszenia systemu pomiędzy różnymi środowiskami platformami / systemami operacyjnymi.
Przykładowe metryki:
łatwość adaptacji
M = T
- T oznacza czas adaptacji do nowego środowiska
łatwość instalacji:
M = A / B
- A = przypadki pomyślnej instalacji
- B = wszystkie przypadki instalacji
4.7. Dostępność (Availibility - A)
Dostępność to czas, w którym program zobowiązany jest odpowiadać zgodnie z oczekiwaniami.
- Metryka:
M = A / B
- A = Czas dostępności
- B = Czas całkowity
- Przykładowe wartości metryki dostępności:
Miara dostępności | Czas niedostępności w roku |
99,999 | 5 minut 20 sekund |
99,8 | 17 godzin 30 minut |
97,5 | 219 godzin |
4.8. Kompatybilność (Compatibility)
Kompatybilność to możliwość współpracowania z systemami zewnętrznymi.
4.9. Bezpieczeństwo (Security - S)
Bezpieczeństwo to możliwość chronienia danych przetwarzanych przez aplikację.
- Przykładowa metryka:
M = A / B
- A = Liczba przetestowanych funkcji programu uznanych jako bezpieczne
- B = Liczba wszystkich przetestowanych funkcji
5. Schematy oceny jakości
Aby ocenić jakość oprogramowania należy wybrać właściwości oprogramowania, które wchodzą w skład oceny. Służą do tego schematy oceny jakości.
5.1. CUMPRIMDSO (schamat wprowadzony przez IBM)
- Capability (odpowiednik przydatności funkcjonalnej)
- Usability (użyteczność)
- Performance – wydajność
- Reliability – niezawodność
- Installability – łatwość instalacji
- Maintainibility – łatwość utrzymania (pielęgnowalność)
- Documentation – dokumentacja
- Service – serwis
- Overall - ocena ogólna
5.2. CUMPRIMDA
- Capability (odpowiednik przydatności funkcjonalnej)
- Usability (użyteczność)
- Performance – wydajność
- Reliability – niezawodność
- Installability – łatwość instalacji
- Maintainibility – łatwość utrzymania (pielęgnowalność)
- Documentation – dokumentacja
- Availibility - dostępność
5.3. FURPS (schemat wprowadzony przez Hewlett-Packard)
- Functionality
- Usability
- Reliability
- Performance
- Supportability – łatwość wspierania
6. Funkcja oceny jakości oprogramowania
6.1. Pojęcie korelacji
Korelacja to miara zależności pomiędzy dwoma zmiennymi (cechami).
Korelacja przyjmuje wartości z przedziału [-1, 1].
korealacja > 0 → korelacja dodatnia
- gdy wartości jednej cechy rosną, to drugiej również rosną.
r < 0 → korelacja ujemna
- gdy wartości jednej cechy rosną, to drugiej maleją i odwrotnie
r = 0 → korelacja zerowa
- brak związku między cechami.
Przykłady korelacji:
źródło: https://cyrkiel.info/statystyka/korelacja-pearsona/
6.2. Korelacja między właściwościami oprogramowania
Korelację między poszczególnymi właściwościami oprogramowania obrazuje tabela:
![Korelacja między właściwościomi oprogramowania](/rjawor/aitech-pbr-rjawor/media/commit/7cbf0c11fe3ef8aee6b6676264c9531c98ab1891/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/korelacja%20w%C5%82a%C5%9Bciwo%C5%9Bci.png)
Tabela wskazuje, że polepszenie jednej cechy oprogramowania (np. przydatności funkcjonalnej) może pogorszyć inną cechę (np. wydajność), bo cechy te są ujemnie skorelowane.
6.3. Waga właściwości oprogramowania
Istotność poszczególnych właściwości oprogramowania zależy od typu programu.
Stephen H. Kan ("Metryki i modele w inżynierii jakości oprogramowania") podaje, że dla metryki UPRIMDA najbardziej odpowiednie kolejności właściwości są następujące:
- RUIPMDA
- RUAIMPD
6.4. Wzór na ocenę jakości oprogramowania
Procedura opracowania wzoru na ocenę jakości oprogramowania odpowiedniego dla danego typu programu:
Wybierz schemat (np. FURPS)
Zdefiniuj typ funkcji (np. funkcja liniowa)
Quality = a + b_F + cU +dR + eP + f*S
- Zdefiniuj współczynniki tak, by korelacja z oceną ludzką była jak najwyższa.
Przykładowy proces dostrajania współczynników jakości
- Zorganizuj grupę użytkowników (co najmniej 5 osób).
- Zbierz od użytkowników oceny poszczególnych właściwości oprogramowania.
- Zbierz od użytkowników oceny ogólne jakości.
- Określ heurystycznie wartości współczynników we wzorze na ocenę ogolną.
- Oblicz współczynnik korelacji między:
- ocenami ogólnymi jakości podanymi przez użytkowników,
- ocenami ogólnymi jakości wyznaczonymi przez wzór na oceną ogólną na podstawie ocen cząstkowych użytkownikow.
- Jeśli korelacja jest niska, to powróć do punktu 4.
Podsumowanie
Istnieje wiele definicji jakości programowania.
- Na wykładzie zdefiniowano jakość jako funkcję poszczególnych właściwości oprogramowania.
Istnieją metryki oceny kodu źrodłowego.
- Na ich podstawie można ocenić jakość kodu.
Jakość oprogramowania można oceniać również z punktu widzenia klienta.
- Stosowane są różne schematy oceny, które biorą pod uwagę różne właściwości oprogramowania.
Ocenę ogólną oprogramowania (z punktu widzenia klienta) można zdefiniować jako funkcję liniową ocen poszczególnych właściwości.