pilka/aitech-pbr-pilka
1
0
Fork 0
forked from AITech/aitech-ppb-pbr
Code Issues Pull Requests Projects Releases Wiki Activity
bcf8d804e7
aitech-pbr-pilka/materiały na PPB (wykład)/.ipynb_checkpoints/12_ocena_jakości_systemu-checkpoint.ipynb

21 KiB
Raw Blame History

Logo 1

Przygotowanie do projektu badawczo-rozwojowego

12. Ocena jakości systemu informatycznego[wykład]

Krzysztof Jassem (2021)

Logo 2

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:

  1. Zdefiniowanie funkcji jakości oprogramowania:

    1. Określ właściwości istotne dla danego typu oprogramowania (np. rozmiar, funkcjonalność, użyteczności, dostępność).
    2. 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.
    3. Zdefiniuj jakość oprogramowania jako funkcję wartości poszczególnych właściwości:

    Quality = q(wartości właściwości)

  2. Ocena jakości oprogramowania

    1. Wyznacz wartości poszczególnych cech oprogramowania.
    2. 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 źródło: Adam Roman, "Testowanie i jakość oprogramowania"

Porównaj w Internecie

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 źródło: Wikipedia

Na podstawie liczby tokenów można oszacować objętość (wielkość) programu:

wielkość programu źrodło: Wikipedia

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:

  • D: trudność implementacji,
  • L: poziom programu (im wyższy tym program jest mniej podatny na błędy),
  • E: wysiłek implementacji,
  • T: czas implementacji
  • B: liczba błędów.metryki złożoności Halsteada żródło: Wikipedia

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ę

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:

korelacja Pearsona ź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 źródło: opracowanie własne na podstawie: Stephen H. Kan "Metryki i modele w inżynierii jakości oprogramowania"

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:

  1. Wybierz schemat (np. FURPS)

  2. Zdefiniuj typ funkcji (np. funkcja liniowa)

Quality = a + b_F + cU +dR + eP + f*S

  1. Zdefiniuj współczynniki tak, by korelacja z oceną ludzką była jak najwyższa.

Przykładowy proces dostrajania współczynników jakości

  1. Zorganizuj grupę użytkowników (co najmniej 5 osób).
  2. Zbierz od użytkowników oceny poszczególnych właściwości oprogramowania.
  3. Zbierz od użytkowników oceny ogólne jakości.
  4. Określ heurystycznie wartości współczynników we wzorze na ocenę ogolną.
  5. 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.
  1. 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.