Testowanie oprogramowania. Wykład 11 inżynieria jakości oprogramowania cz. I podstawy teorii pomiarów metryki rozmiaru: LOC metryki rozmiaru: FP

Transkrypt

1 Testowanie oprogramowania Adam Roman Instytut Informatyki UJ Wykład 11 inżynieria jakości oprogramowania cz. I podstawy teorii pomiarów metryki rozmiaru: LOC metryki rozmiaru: FP 1/50

2 Zagadnienia inżynierii jakości INŻYNIERIA JAKOŚCI OPROGRAMOWANIA 1. podstawy teorii pomiarów 2. metryki wolumenowe 3. metryki złożoności 4. estymacja pracochłonności 5. defekty i metryki defektów 6. pomiar i predykcja niezawodności oprogramowania 7. czas odpowiedzi i dostęność 8. pomiar postępu 9. benchmarking 10. efektywne prezentowanie dla managementu 2/50

3 Wstęp do inżynierii jakości 3/50

4 Raport CHAOS 2012 statystyki dla projektów IT 4/50

5 Potrzeby Inżynierowie oprogramowania muszą posiadać umiejętności estymacji i pomiaru, tzn.: rozumieć czynności i ryzyka w rozwoju oprogramowania przewidywać i kontrolować działania zarządzać ryzykami dostarczać niezawodności zarządzać proaktywnie aby uniknąć kryzysów Aby przewidywać i dobrze kontrolować musisz mierzyć Aby rozumieć postęp w rozwoju musisz mierzyć Aby zrozumieć i ocenić jakość musisz mierzyć 5/50

6 Co mierzyć? (1) Istnieje wiele charakterystyk oprogramowania. Należy zdefiniować program metryk. Aby to zrobić, należy odpowiedzieć sobie na następujące pytania: kto jest klientem dla tych metryk? jakie są cele klientów dotyczące mierzonego produktu, procesu, zasobów? jakie metryki pokażą czy cel został osiągnięty? 6/50

7 Co mierzyć? (2) Metoda 1: Goal Question Metric (GQM) Metoda podana przez Basiliego (2002), podejście top-down GOAL (cel) zidentyfikuj cel dla produktu / procesu / zasobu. Ten cel chce osiągnąć klient. QUESTION (pytanie) określ pytanie/pytania, które scharakteryzują metodę osiągnięcia celu METRIC (metryka) zdefiniuj metrykę/metryki, które dostarczą ilościowej odpowiedzi na pytanie 7/50

8 Co mierzyć? (3) Metoda 1: Goal Question Metric (GQM) - przykład GOAL (cel) dostarczyć produkt który spełni oczekiwania klienta co do funkcjonalności QUESTION (pytanie) jak bardzo dostarczony program odchyla się od wymagań klienta? METRIC (metryka) liczba defektów polowych, albo: satysfakcja klienta (ankieta) 8/50

9 Co mierzyć? (4) Metoda 1: Goal Question Metric (GQM) rozszerzenie GOAL QUESTION METRIC MECHANISM (mechanizm) kto odpowiedzialny za zbieranie danych i raportowanie, jak często, jaka infrastruktura będzie do tego potrzebna? 9/50

10 Co mierzyć? (5) Metoda 2: Decision Maker Model metoda skupia się na podejmowaniu decyzji projektowych klientem jest osoba podejmująca decyzje określa się potrzeby osoby podejmującej decyzje (mogą się zmieniać w czasie) metoda zgodna z GQM potrzeby informacyjne DECYZJE PROJEKTOWE MIARY PROJEKTOWE produkty informacji (dane) 10/50

11 Co mierzyć? (6) Metoda 3: Metryki oparte na standardach Istnieje wiele generycznych standardów inżynierii oprogramowania dla zbiorów metryk Np. model dojrzałości SEI wykorzystuje metryki: rozmiar systemu czas trwania projektu wysiłek defekty produktywność Inne przykładowe standardy: TL9000 dla telekomunikacji, EIC 60880: dla elektrowni jądrowych itd. Wiele organizacji posiada swoje własne programy metryk (Motorola, IBM). 11/50

12 Dlaczego pomiary są trudne? Modele pomiarów 12/50

13 Dlaczego pomiary są trudne ile linii kodu ma poniższy program? /* Strncat() appends up to count characters from string src to string dest, and then appends a terminating null character. If copying takes place between objects that overlap, the behavior is undefined. */ char *strncat(char *dest, const char *src, size_t count) { char *temp = dest; if (count) { while (*dest) dest++; while ((*dest++ = *src++)) { if (--count == 0) { *dest = \0 ; break; } } } return temp; } 13/50

14 Dlaczego pomiary są trudne ile linii kodu ma poniższy program? /* Strncat() appends up to count characters from string src to string dest, and then appends a terminating null character. If copying takes place between objects that overlap, the behavior is undefined. */ char *strncat(char *dest, const char *src, size_t count) { char *temp = dest; if (count) { while (*dest) zwykle dest++; while ((*dest++ = *src++)) { rozrzut if (--count == 0) { pomiędzy *dest = \0 ; break; 11 a 19 } } } return temp; } 14/50

15 Wyzwania pomiarów wiele rzeczy które chcemy mierzyć wydają się niemierzalne Jak zmierzyć złożoność programu? Co w ogóle oznacza złożoność? Jak zmierzyć produktywność? Jeśli ktoś napisze 100 linii kodu w 2 godziny ale program ma 5 defektów, czy to jest rozsądna produktywność? Czym jest produktywność? A jeśli ktoś ten sam program napisze w jednej linijce, w jedną godzinę, jaka jest jego produktywność? Czyja produktywność jest lepsza? 15/50

16 Modele pomiarów (1) klucz do mierzenia niemierzalnego Model = abstrakcja realnego obiektu badań Typy modeli: tekstowe (słowa) diagramatyczne (rysunki) algorytmiczne (liczby) 16/50

17 Modele pomiarów (2) modele tekstowe Najmniej efektywne, ale najpowszechniejsze. Przykład model rozwoju oprogramowania: wysiłek czas wymagany dla rozwoju produktu, wyrażony jako wzrost czasu rozwoju (np. staff months/hours); generalnie wysiłek jest funkcją rozmiaru i skutkuje kosztem cechy wymagania produktu do stworzenia rozmiar wielkość tworzonego produktu; generalnie rozmiar jest funkcją cech defekty niekompletność produktu; są funkcją rozmiaru i harmonogramu harmonogram łączny czas tworzenia; czasy zakończenia dla głównych kamieni milowych; harmonogram jest funkcją wysiłku i zasobów zasoby liczba deweloperów przydzielonych do rozwoju produktu Każdy element jasny i łatwy do zrozumienia Trudno zwizualizować zależności pomiędzy nimi 17/50

18 Modele pomiarów (3) modele diagramatyczne Mogą być bardzo potężne. Pozwalają modelować encje, zależności między nimi i ich dynamikę. Przykład (prostego) modelu diagramatycznego dla modelu rozwoju oprogramowania: Koszt Cechy Zasoby Wysiłek Rozmiar Harmonogram Defekty 18/50

19 Modele pomiarów (4) modele algorytmiczne Zwane też parametrycznymi. Zwykle bardzo potężne, gdyż w jasny sposób wyrażają ilościowe relacje pomiędzy encjami. Przykłady: Wysiłek = Czas * Zasoby % Defektów Znalezionych w Jednym Cyklu = 30% defektów pozostałych w produkcie Wysiłek = A * (RozmiarProgramu) B + C, gdzie A, B, C to empirycznie wyznaczone stałe 19/50

20 Meta-model dla metryk KONCEPT abstrakcja DEFINICJA świat empiryczny DEFINICJA OPERACYJNA RZECZYWISTY POMIAR 20/50

21 Meta-model dla metryk abstrakcja KONCEPT DEFINICJA czas odpowiedzi średni czas odpowiedzi systemu na wejście świat empiryczny DEFINICJA OPERACYJNA RZECZYWISTY POMIAR średnia z (czas początku odpowiedzi czas naciśnięcia klawisza Enter) średnia z typowej godziny (czas transmisji + czas na serwerze + czas do wyświetlenia) 21/50

22 Wstęp do teorii pomiaru 22/50

23 Wprowadzenie do teorii pomiaru Teoria pomiaru pozwala poprawnie definiować pomiary i metryki oraz używać analizy statystycznej na zmierzonych danych Przykład: wyniki ankiety satysfakcji klienta dotyczącej wsparcia klienta. Możliwe odpowiedzi: 1 bardzo zadowolony 2 zadowolony 3 średnio zadowolony 4 niezadowolony 5 bardzo niezadowolony Średnia = 3.0. Czy to oznacza, że mamy dobre wsparcie klienta? Czy wystarczy poprawić je tylko trochę? 23/50

24 Wprowadzenie do teorii pomiaru Teoria pomiaru pozwala poprawnie definiować pomiary i metryki oraz używać analizy statystycznej na zmierzonych danych Przykład: wyniki ankiety satysfakcji klienta dotyczącej wsparcia klienta. Wyniki ankiety: 1 bardzo zadowolony 10 odpowiedzi (50%) 2 zadowolony 0 odpowiedzi (0 %) 3 średnio zadowolony 0 odpowiedzi (0 %) 4 niezadowolony 0 odpowiedzi (0 %) 5 bardzo niezadowolony 10 odpowiedzi (50%) Średnia = 3.0. Czy to oznacza, że mamy dobre wsparcie klienta? Czy wystarczy poprawić je tylko trochę? Nie. Tu branie średniej nie ma sensu. Teoria pomiaru pozwala zrozumieć wariancję, zakresy, typy błędów itd. używając narzędzi statystycznych 24/50

25 Skale pomiarowe (1) Która waga jest lepsza? 25/50

26 Skale pomiarowe (1) Która waga jest lepsza? Żadna. Każda mierzy INACZEJ (łazienkowa ma skalę absolutną, ale na większy błąd pomiaru) 26/50

27 Skale pomiarowe (2) 1. Skala nominalna 2. Skala porządkowa bardzo zadowolony zadowolony średnio zadowolony niezadowolony bardzo niezadowolony 3. Skala interwałowa 4. Skala stosunkowa 27/50

28 Miary tendencji centralnej Miary tendencji centralnej: średnia (μ) suma pomiarów dzielona przez ich liczbę (I, S) mediana wartość dzieląca posortowany zbiór na połowy (P, I, S) moda wartość występująca najczęściej (N, P, I, S) X = {1, 2, 2, 2, 3, 3, 5, 10} średnia ze zbioru X = ( )/8 = 3.5 mediana = 2.5 moda = 2 mediana to inaczej 50-ty percentyl albo 2-gi kwartyl inna nazwa mody: dominanta, wartość dominująca 28/50

29 Miary zmienności Miary zmienności: rozstęp różnica między wartością największą a najmniejszą odchylenie odległość od średniej wariancja miara rozproszenia, Var = (Deviations 2 )/N odchylenie standardowe (sd) pierwiastek z wariancji indeks wariancji (IV) opisuje pewność pomiaru, IV = sd/μ Moduł A: 10 KLOC, B: 24 KLOC, C: 50 KLOC Rozstęp = (50 10) KLOC = 40 KLOC Odchylenia: 84/3 KLOC = 28 KLOC. Dla A: 18, dla B: 4, dla C: 22 Wariancja = ( )/3=275. Odch std = 16.6 KLOC Indeks wariancji = 16.6/28 = 0.59 Im niższy IV, tym mniejsza wariancja (większa pewnośc pomiaru) 29/50

30 Wariancja przykład częstość rozkład X z mniejszą wariancją rozkład X z większą wariancją 30/50

31 Odpowiedniość i spójność pomiaru 31/50

32 Błąd losowy pomiaru mały błąd losowy duży błąd losowy 32/50

33 Błąd systematyczny pomiaru z błędem systematycznym bez błędu systematycznego 33/50

34 Błąd pomiaru - podsumowanie wartość rzeczywista średnia bias błąd losowy 34/50

35 Pomiar rozmiaru oprogramowania 35/50

36 Po co mierzyć rozmiar programu? Jak duży jest program? Jak duży jest w porównaniu do innych programów? Jak wiele wysiłku musimy włożyć, aby zbudować program? Jak jakość naszego programu wypada na tle innych projektów? Jak produktywni jesteśmy w porównaniu do innych projektów? 36/50

37 Dwa rodzaje rozmiaru oprogramowania ROZMIAR OPROGRAMOWANIA FIZYCZNY FUNKCJONALNY 37/50

38 Pomiar fizyczny LOC (1) Metoda prosta i niezawodna Wspierana narzędziami SEI opublikowało listę kontrolną pozwalającą precyzyjnie opisać metodę zliczania linii kodu Organizacje używają różnych wersji tej metryki, np.: NKLOC (non-commented thousand LOC LLOC (logical lines of code) 38/50

39 Pomiar fizyczny LOC (2) współczynnik produktywności języka Język QSM SLOC/FP min średnia mediana max Access David Consulting Group Assembler C C C# Fortran 210 J2EE Java Powerbuilder SQL /50

40 Pomiar fizyczny LOC (3) reużywany i refaktorowany kod Aby poprawnie mierzyć (i porównywać) produktywność i gęstość defektów, należy określić rozmiar kodu, który jest reużywany i refektorowany Np. klasyfikacja NASA: kod reużyty w sensie dosłownym kod lekko zmodyfikowany (<25%) kod silnie zmodyfikowany (>25%) kod nowy 40/50

41 Pomiar fizyczny LOC (4) długość specyfikacji i projektu Kusząca jest hipoteza, wg której rozmiar dokumentacji jest predyktorem rozmiaru kodu (a więc i wysiłku) Fenton & Pfleeger: korelacja zależy silnie od organizacji Miary: liczba stron liczba shalls ( system powinien ) 41/50

42 Pomiar funkcjonalny FP (1) pośrednia miara rozmiaru funkcjonalnego oprogramowania Problem z LOC: nie ma wiele wspólnego z tym, co program robi; klienta interesuje rozwiązanie, nie język/technologia Pomysł: mierzyć system wg tego co robi, a nie jak wewnętrznie to robi Co można mierzyć? wejścia wyjścia interfejsy bazy danych zapytania METODA PUNKTÓW FUNKCYJNYCH 42/50

43 Pomiar funkcjonalny FP (2) zliczanie punktów funkcyjnych wg IFPUG Adjusted FP Unadjusted FP Value Adjustment Factor AFP = UFP * ( *VAF) Cmpnt Smpl Avg Cplx Input Output Data file Interface Inquiry (0-5) No. Charakterystyka 1 Komunikacja danych 2 Rozproszone dane/przetwarzanie 3 Cele wydajnościowe 14 Łatwość zmian 0 brak wpływu, 5 znaczny wpływ 43/50

44 Pomiar funkcjonalny FP (3) przykład: system bezpieczeństwa dla domu System składa się z 5 kontrolerów (dla: alarmów drzwi i okien; detektorów ruchu; panic buttons ; detektorów ognia; włącznika światła), kontrolera/monitora dla urządzenia (on-off) oraz bezprzewodowego urządzenia z kontrolerem Oszacować wysiłek dla budowy systemu. Załóż produktywność 10 FP/osobomiesiąc z odchyleniem std ±1 osobomiesiąc 44/50

45 Pomiar funkcjonalny FP (4) przykład: system bezpieczeństwa dla domu c.d. Panic button controler Door/Window Alarm 1 input 1 input System Config 1 internal file Main Processor 1 input 1 input 1 output Motion Detector Controller Fire Detector Controller 1 output 1 input/output Wireless Dial-out Device Controller Key Device Controller Light Activator/ Deactivator Ctrlr 45/50

46 Pomiar funkcjonalny FP (5) przykład: system bezpieczeństwa dla domu c.d. Simple Input = 5 Simple Output = 2 Simple Internal Database = 1 Medium Output (to Dial-out Controller) = 1 UFP = 3*5 + 4*2 + 7*1 + 5*1 = = 35 VAF = = 33 AFP = 35*( ) = 35*0.98 = 34.3 Liczba osobomiesięcy = 34.3/10 = 3.4 sd ±1 osobomiesięcy: 34.3/9 = 3.81, 34.3/11 = 3.12 Odpowiedź: Oczekiwany wysiłek: między 3.12 a 3.81 osobo/mc-y 46/50

47 Pomiar funkcjonalny FP (6) konwersja Punktów Funkcyjnych na rozmiar fizyczny Wykorzystuje współczynniki produktywności języka Np.: w przykładzie mieliśmy 35 FP. Ile linii kodu będzie miał program napisany w Javie? (średni SLOC/FP = 60) Odpowiedź: 60*35 = 2100 (2.1 KLOC) Pytanie który współczynnik produktywności wybrać? Np. QSM oparte o większą liczbę danych i nowsze niż te z David Consulting Group 47/50

48 Pomiar funkcjonalny FP (7) szacowanie czasu i zasobów na podstawie FP Modele wg. Jonesa: Czas = FP 0.4 [m-cy kalendarzowych] Zasoby = FP/150 (zasoby = deweloperzy, testerzy, QA, dokumentaliści, project managerowie, administratorzy baz danych) Wysiłek = Czas * Zasoby Dla czasu wykładnik przybiera postać od 0.32 dla prostych projektów do 0.45 dla skomplikowanych projektów. Wartość to czas od wymagań do dostarczenia oprogramowania 48/50

49 Pomiar funkcjonalny FP (8) szacowanie czasu i zasobów na podstawie FP c.d. Dla wcześniejszego przykładu (FP = 35): Czas = = 3.12 m-cy Zasoby = 35/150 = 0.23 osób (!!!) Wysiłek = 3.12 * 0.23 = 0.72 osobomiesiąca Ad. zasoby: dobry przykład szacowań inżynierskich i estymacji Reguła dla zasobów zwykle nie działa dla małych projektów Ale i tak dobra metoda jako punkt wyjścia! 49/50

50 KONIEC 50/50