Kontrola jakoci artefaktów

Transkrypt

1 Kontrola jakoci artefaktów Witam serdecznie! Na dzisiejszym wykładzie bdzie mowa o kontroli jakoci artefaktów. Wikszo artefaktów, czyli wytworów rk ludzkich, wymaga kontroli jakoci. Na slajdzie mamy pokazan kontrol jakoci płytki krzemu w wietle zielonej lampy. 1

2 Plan wykładów! "# $ % & ' "# $ % & '' ( )! * + +, -! *. / $! ) 0 ( 0 ( Kontrola jakoci artefaktów (2) Jest to trzeci wykład w ramach Inynierii oprogramowania. 2

3 Plan wykładów! " "# $ % & ' "# $ % & '' ( * + + *. / ) 0 ( 0 ( Kontrola jakoci artefaktów (3) W pewnym sensie bdzie to rozwinicie pierwszego wykładu, w ramach którego była mowa o zasadach skutecznego działania. 3

4 Plan wykładów # $! " "# $ % & ' "# $ % & '' ( * + + *. / ) 0 ( 0 ( Kontrola jakoci artefaktów (4) Mona go te traktowa, jako kontynuacj wykładu dotyczcego specyfikacji wymaga, bowiem jednym z głównych artefaktów w informatyce s dokumenty dotyczce specyfikacji wymaga i w kadej szanujcej si firmie programistycznej powinny one podlega przegldom. 4

5 Plan wykładu 1! % 1 & 1! " 1 # ' Kontrola jakoci artefaktów (5) Wykład został podzielony na cztery czci. Najpierw chciałbym wyjani pojcie jakoci, gdy celem przegldów jest zapewnienie jakoci artefaktów powstajcych w trakcie wytwarzania oprogramowania. Potem przeszlibymy do ogólnego omówienia testowania. Testowanie jest bardzo wan metod zapewniania jakoci i naley je traktowa jako uzupełnienie przegldów. W ramach tego przedmiotu problematyce testowania bd powicone odrbne dwa wykłady. W trzeciej czci wykładu zostanie zaprezentowana konkretna metoda dokonywania przegldów oprogramowania zwana przegldami Fagana. Ostatni cz wykładu chciałbym powici problemowi szacowania liczby defektów, jakie pozostały w kodzie lub w specyfikacji po przeprowadzeniu przegldu. Zacznijmy od pojcia jakoci. 5

6 Jako oprogramowania ( ) ( ) 2 ( * ' ! Kontrola jakoci artefaktów (6) Jest wiele definicji jakoci. Du popularno zyskała definicja jakoci zaproponowana przez Philipa Crosby ego: Jako jest to zgodno z wymaganiami. Problem polega na tym, e nie wszystkie wymagania s jawnie podane przez klienta. Profesjonalizm firmy informatycznej przejawia si umiejtnoci wydobycia wymaga, których klient pocztkowo nie jest wiadom, a na których tak naprawd bardzo mu zaley. Mog to by albo wymagania dla niego oczywiste, albo te takie, co do których w danej chwili nie ma odpowiedniej wiedzy. Wiele systemów informatycznych ma charakter nowatorski i bazuje na zupełnie nowych koncepcjach organizacyjnych. Trudno si wic dziwi, e klient nie ma klarownego pogldu na wymagania, bo nikt łcznie z nim takiego systemu jeszcze nie widział. 6

7 Koszt naprawy błdu + % '%,-. 1 "./ Kontrola jakoci artefaktów (7) Powstaje pytanie: czy warto przeprowadza przegldy? Z danych zebranych w rónych firmach informatycznych wynika, e zdecydowanie tak. Na slajdzie mamy dane dotyczce przedsiwzi realizowanych przez firm IBM. Jeli przyjmiemy, e redni czas identyfikacji błdu na poziomie przegldu projektu oprogramowania wynosi 1 godz., to wykrycie tego samego błdu na poziomie inspekcji kodu bdzie ju kosztowało 20 godzin. A jeli ten błd zostałby wykryty na poziomie testów maszynowych, to jego identyfikacja kosztowałaby ju 82 godziny. Jak wic wida, im szybciej jaki błd zostanie wykryty, tym mniejsze s koszty z nim zwizane. Zatem warto dba o jako od samego pocztku, ju na etapie specyfikacji wymaga. Ale jak mamy tylko specyfikacj wymaga, to o testowaniu nie moe by mowy. Std tak dua rola przegldów, o których bdziemy mówili w trakcie tego wykładu. 7

8 Zasady skutecznego działania Ostrz pił Dbaj o synergi Najpierw staraj si zrozumie Myl o obopólnej korzyci Aby rzeczy pierwsze były pierwsze Zaczynaj majc koniec na wzgldzie Bd proaktywny Kontrola jakoci artefaktów (8) Potrzeba dbania o jako, w tym dokonywanie przegldów i testowanie oprogramowania, wynika take z drugiej zasady Covey ego. Zasada ta kae zaczyna majc koniec na wzgldzie. W przypadku przedsiwzicia programistycznego tym kocem jest oddanie oprogramowania i opinia klienta o produkcie. Aby mie uzasadnione nadzieje na akceptacj i zadowolenie klienta trzeba ju zawczasu dba o jako i j kontrolowa dokonujc najpierw przegldów, a póniej gdy dostpny bdzie ju kod przegldów oraz testowania. 8

9 Jako oprogramowania (, - (, - Kontrola jakoci artefaktów (9) Jeli mówimy o jakoci (a w przegldach chodzi o zapewnienie jakoci), to trzeba sobie zdawa spraw, e jako ma dwa oblicza: mona mówi o jakoci projektu i jakoci wykonania. Jako projektu, jest to zespół cech zalenych od pomysłów twórców. Jeli mówimy o jachcie, to jako projektu mogłaby dotyczy jego szybkoci, liczby miejsc w kajucie, wyposaenia tego jachtu w sprzt nawigacyjny itd. Niektóre z rozwiza mog by tak bardzo innowacyjne, e zdecydowanie przycign uwag potencjalnego klienta i bdzie miał ochot taki jacht kupi. Ale jest te druga strona jakoci jako wykonania. Jeli okae si, e wykonanie jest słabe, e tu si co nie domyka, a tam tapeta zaczyna si odkleja, to klient moe si szybko zniechci. Podobnie jest z oprogramowaniem. Jako projektu to bdzie w tym przypadku warto pomysłów dotyczcych funkcjonalnoci systemu, ergonomiczno interfejsu uytkownika, załoona przepustowo. Jeli chodzi o jako wykonania, to bd to wszelkiego rodzaju defekty, które spowoduj, e system czego nie bdzie mógł wykona, e w pewnych warunkach si zawiesi itd. W dalszej czci wykładu bdzie mowa o jakoci w sensie jakoci wykonania. 9

10 Osiem wymiarów jakoci = %, : (% % &;< & 3 4 = > & A 2 ( /3+ (, '( (, % ( '% (, ( 8 39 : 3* ; 3< 2 3 ( Kontrola jakoci artefaktów (10) Bardzo ciekaw klasyfikacj atrybutów zwizanych z jakoci zaproponował David Garvin z Harvard Business School. Według niego mona mówi o omiu wymiarach jakoci. Pierwszy dotyczy szeroko rozumianej wydajnoci. W przypadku systemu informatycznego mogłaby to by np. szybko przetwarzania liczona w transakcjach na minut. Drugim wymiarem jest niezawodno. Mona j rozumie np. jako czstotliwo pojawiajcych si błdów w zachowaniu systemu albo jako redni czas midzyawaryjny. Trzecim wymiarem jest wytrzymało. W odniesieniu do sprztu takiego jak telefon komórkowy, czy komputer to łatwo j zinterpretowa jak długo ten sprzt bdzie działał. W przypadku oprogramowania jest trudniej, ale mona by przyj, e chodzi w tym przypadku o to, jak długo system bdzie mógł pracowa bez istotnych modyfikacji funkcjonalnych. Jeli dobrze został zaprojektowany (ma np. wbudowane mechanizmy dostosowania), to moe by bardzo długo wykorzystywany (słyszałem o oprogramowaniu, które było wykorzystywane podobno przez 30 lat bez adnych modyfikacji). Czwartym wymiarem składajcym si na jako jest łatwo naprawy. Jest to w duej mierze cecha projektu. Jeli oprogramowanie zostało zaprojektowane modularnie z uyciem odpowiednich wzorców, to jego naprawa bdzie pewnie duo łatwiejsza ni oprogramowania o strukturze monolitycznej. Estetyka w przypadku oprogramowania chyba najbardziej odnosi si do interfejsu uytkownika. Do samego kodu klient rzadko zaglda, zatem trudno byłoby tutaj mówi o wraeniach estetycznych. Cechy funkcjonalne David Garvin wymienia na 6. miejscu. W przypadku systemów informatycznych s one niezmiernie wane i mog odgrywa pierwszoplanow rol przy wyborze systemu. Na nasze postrzeganie jako ma wpływ take reputacja wytwórcy. Jest to szczególnie widoczne w przemyle samochodowym. W informatyce odgrywa to chyba znacznie mniejsz rol. Ósmym wymiarem (czy kryterium jakoci) według Garvina jest zgodno ze standardami i innymi wymaganiami. W informatyce dopiero rodz si standardy dotyczce rónego typu aplikacji (swego czasu trwały w Polsce intensywne prace sponsorowane przez Stowarzyszenie Ksigowych w Polsce i Polskie Towarzystwo Informatyczne dotyczce standardu dla systemów finansowo-ksigowych). Zazwyczaj, jeli w jakim obszarze standardy i wymagania prawne istniej, to wchodz do wymaga dotyczcych budowanego systemu i MUSZ by honorowane. 10

11 Cztery filary zapewniania jakoci Jako oprogramowania C ) (+ B & + Kontrola jakoci artefaktów (11) W przypadku systemów informatycznych mona powiedzie, e ich jako opiera si na czterech filarach: Zarzdzaniu konfiguracj (bdzie na ten temat osobny wykład). Testowaniu (dotyczy to kodu). Przegldach (kady dokument i kod moe by poddany przegldowi). Refaktoryzacji (jest to specjalna technika radzenia sobie z ewolucj oprogramowania i te bdzie na ten temat osobny wykład). 11

12 Przetargi dot. kontroli jakoci 1 # A! + '.3/ 1 # A? AAB, B -. % 1 # & * A# & >< 0. : 1 1 3C D Kontrola jakoci artefaktów (12) O wanoci problematyki dotyczcej kontroli jakoci mogwiadczy przetargi organizowane przez róne instytucje rzdowe a dotyczce zapewnienia jakoci. Na przykład w zwizku z budow systemu informatycznego do obsługi wyborów parlamentarnych i prezydenckich ogłoszono osobny przetarg o wartoci ok. 1 mln zł na przetestowanie tego systemu. Podobna sytuacja była przy budowie systemu informatycznego dla Głównego Inspektora Informacji Finansowej (jest to jedna z kluczowych pozycji w Ministerstwie Finansów). Ogłoszony przetarg na kontrol jakoci miał warto kilkuset tysicy złotych. Podobnej skali przedsiwziciem była kontrola jakoci Systemu Zintegrowanej Taryfy Celnej ISZTAR2. Jak wic wida, rodzi si rynek na usługi w zakresie kontroli jakoci oprogramowania. 12

13 Plan wykładu 1! % 1 & 1! " 1 # ' Kontrola jakoci artefaktów (13) Przejdmy teraz do omówienia podstawowych zagadnie dotyczcych testowania. Jak ju wspomniałem, ta problematyka bdzie szerzej omówiona w trakcie osobnych dwóch wykładów. 13

14 Cele testowania wg Glena Myersa (1979) Testowanie : '% 3. 4 '"3. '3 '% 3 Kontrola jakoci artefaktów (14) Pierwsze pytanie, jakie mona postawi, jest nastpujce: co to jest testowanie? Według Glena Myersa testowanie jest to wykonanie programu celem znalezienia błdu. Ta kocówka zdania celem znalezienia błdu jest bardzo wana. Wynika z niej, e udany test to taki, który wykrywa jeszcze nie wykryty błd (jeli test wykrywa błd, o którym ju wiemy, e istnieje, to nie jest to dla nas adna wana informacja). Na tej podstawie mona przyj, e miar jakoci przypadku testowego jest prawdopodobiestwo znalezienia jeszcze nie wykrytego błdu. 14

15 Pracochłonno testowania Testowanie: ~ 30 % - 40 % całkowitej pracochłonnoci. B / 2 ; 1 D ; 2 1 D 2 E F! C & ) Kontrola jakoci artefaktów (15) Kolejne pytanie, jakie powstaje, to ile czasu potrzeba na testowanie? Inaczej mówic, jak cz całkowitej pracochłonnoci zajmuje testowanie? Według Rogera Pressmana, jednego z uznanych ekspertów w dziedzinie inynierii oprogramowania, w amerykaskich przedsiwziciach informatycznych testowanie typowego projektu pochłania 30 do 40% ogólnej pracochłonnoci. Jest to całkiem sporo. Wynika z tego, e jeeli 1000 godzin powicamy na specyfikacj wymaga, projekt architektury systemu, kodowanie, napisanie dokumentacji, to dodatkowe 500 godzin zajmie testowanie takiego systemu. W przypadku systemów krytycznych (takich, jak sterowanie samolotem albo prac elektrowni jdrowej) testowanie zajmuje jeszcze wicej czasu i moe siga nawet 80% całkowitej pracochłonnoci. 15

16 Rodzaje testowania Testy Wykonanie automat. Wykonanie rczne Dane automat. Dane rczne Kontrola jakoci artefaktów (16) Cz prac zwizanych z testowaniem moe by zautomatyzowana. Jeli mówimy o testowaniu, to mamy na myli dwie grupy zada: wymylenie przypadków testowych (dane wejciowe i spodziewane wyniki) oraz wykonanie testów. Kada z tych czynnoci moe by wykonana rcznie (tzn. przez człowieka) lub automatycznie (przez komputer). S wic moliwe cztery podejcia do testowania. 16

17 Rodzaje testowania Testy Wykonanie automat. Wykonanie rczne Dane automat. Dane rczne E! Kontrola jakoci artefaktów (17) Pierwszy wariant dotyczy sytuacji, gdy wszystko jest realizowane automatycznie, zarówno opracowanie danych testowych, jak i wykonanie testów. To podejcie jest bardzo atrakcyjne, ale póki co udaje si to robi tylko w bardzo ograniczonym zakresie. Generalnie nie mona jeszcze w przypadku komercyjnych przedsiwzi mówi o w pełni automatycznym testowaniu wszystkich moliwych właciwoci systemu informatycznego. Zaznaczmy zatem ten wariant kolorem szarym by moe w przyszłoci bdzie to, przynajmniej w duym stopniu, moliwe, ale teraz nie ma jeszcze warunków (głównie wiedzy i narzdzi), eby firmy informatyczne mogły na tym podejciu polega. Drugi wariant, to rcznie przygotowywane dane i automatycznie wykonywane testy. Jest to podejcie znajdujce coraz szersze uznanie i bdce jedn z głównych praktyk zapewniania jakoci w metodyce zwanej Programowaniem Ekstremalnym (w skrócie XP). Mona te myle o rcznym wykonywaniu testów według danych przygotowanych przez komputer. Moe to mie sens tylko w wyjtkowych wypadkach. Jeli chodzi o testowanie oprogramowania, to raczej takie podejcie nie ma sensu, bowiem przy wymylaniu testów potrzebna jest kreatywno i tutaj człowiek ma znaczn przewag nad komputerem, natomiast samo wykonanie ma charakter czysto automatyczny (trzeba wprowadzi dane i zobaczy, czy wyniki odpowiadaj oczekiwaniom) w tym zakresie komputer jest znacznie szybszy od człowieka i nie nuy si wykonywaniem tego typu zada. Zatem oznaczmy ten wariant kolorem czarnym, eby pokaza, e raczej nie ma on praktycznego znaczenia. Ostatni, czwarty, wariant polega na wykonywaniu wszystkiego przez człowieka. Jego zadaniem jest zarówno przygotowanie przypadków testowych, jak i ich wykonanie. W praktyce ten wariant jest szeroko stosowany. Teraz główna dyskusja dotyczy w zasadzie tylko jednej kwestii: czy warto automatycznie wykonywa testy, czy nie. Jeli chodzi o przygotowywanie danych testowych i oczekiwanych wyników, to raczej jest tutaj zgodno, e naley powierzy to zadanie człowiekowi. 17

18 Plan wykładu 1! % 1 & 1! " 1 # ' Kontrola jakoci artefaktów (18) Pozostawmy problematyk dotyczc testowania i przejdmy do omówienia przegldów, jako metody kontroli jakoci. 18

19 Anomalia > )# F 4 " 4 ' 3 # " 9 ' 2 & (& G ; (G ( &2 ( Kontrola jakoci artefaktów (19) Zacznijmy od pojcia anomalii. Na slajdzie pokazane s dwa serca. To z lewej jest normalne, to z prawej ma wad zwan anomali Ebsteina. Midzy innymi wida na prawym zdjciu znacznie powikszon praw komor serca oznaczon jako RA. Na uytek wykładu przyjmiemy definicj anomalii zaproponowan w standardzie IEEE 1028 dotyczcym przegldów. Przez anomali rozumie si sytuacj rón od oczekiwanej, przy czym oczekiwania opieraj si na specyfikacji, standardach lub na czyim dowiadczeniu. Ta definicja pasuje zarówno do anomalii anatomicznych, jak i do anomalii dotyczcych oprogramowania. 19

20 Przegld Artefakt 1 ), 3 - % '3 1 ) 3 Kontrola jakoci artefaktów (20) Zgodnie ze standardem IEEE 1028 przegld (po angielsku review ) jest to proces lub spotkanie, w trakcie którego artefakt zwizany z oprogramowaniem (np. kod) jest prezentowany rónym osobom w celu skomentowania lub uzyskania jego zatwierdzenia. Inaczej mówic, przegld jest to ocena artefaktu (np. kodu lub specyfikacji) realizowana przez grup osób. Inspekcja (po angielsku inspection ) jest to wizualne sprawdzenie artefaktu celem wykrycia lub zidentyfikowania anomalii dotyczcych oprogramowania. Inspekcje s przeprowadzane przez osoby z tego samego szczebla zarzdzania (szefowie nie bior w nich udziału), a prowadz je specjalnie przeszkoleni (niezaleni) moderatorzy (po angielsku facilitators lub Inspection leaders ). 20

21 Rola przegldów Zapewnianie jakoci Przekazywanie informacji Kontrola jakoci artefaktów (21) Przegldy i inspekcje spełniaj dwie funkcje: z jednej strony słu zapewnieniu jakoci, a z drugiej s sposobem przekazywania informacji o tworzonym oprogramowaniu. Jeli nawet kto nie tworzył danego modułu, ale brał udział w jego inspekcji, to na pewno bdzie wicej wiedział na temat tego modułu ni kto, kto w ogóle nie miał stycznoci z tym modułem. Podobnie jest z inspekcj specyfikacji. Ponadto, jeli programista w trakcie inspekcji specyfikacji nie wykrył jakiego błdu, to póniej z wikszym zrozumieniem odniesie si do tego błdu, gdy go wykryje na etapie np. kodowania. 21

22 Inspekcje zgodne z IEEE 1028! # > A # Kontrola jakoci artefaktów (22) Chciałbym przedstawi inspekcje w wersji zgodnej ze standardem IEEE 1028 z 1997 roku. Jak ju wspomniałem, spotkanie inspekcyjne jest prowadzone przez moderatora. Jego zadaniem jest zaplanowanie inspekcji, sprawne jej przeprowadzenie i zebranie danych zwizanych z inspekcj. Zgodnie ze standardem IEEE 1028 oprócz moderatora s jeszcze cztery inne role. Zadaniem prezentera jest przedstawienie artefaktu (np. kodu lub specyfikacji wymaga) w zrozumiały sposób i podkrelenie najistotniejszych elementów. Zadaniem autora artefaktu jest przygotowanie go do inspekcji, wyjanienie ewentualnych wtpliwoci, jakie mog si pojawi si w trakcie inspekcji i usunicie defektów wykrytych w trakcie inspekcji. Inspektor jest to główna rola. Zadaniem inspektora jest wykrycie anomalii, jakie by moe zakradły si do badanego artefaktu. Zazwyczaj w inspekcji bierze udział kilku inspektorów reprezentujcych róne punkty widzenia. W roli inspektora moe by analityk, reprezentant klienta, specjalista od bezpieczestwa systemów informatycznych itp. Ostatni, pit rol jest rola sekretarza. Sekretarz ma dokumentowa wykryte anomalie, podjte decyzje, rekomendacje itp. Rol sekretarza i moderatora moe pełni ta sama osoba. 22

23 Inspekcje zgodne z IEEE 1028 Prezenter Inspektor Autor 1. Omówienie (cały zespół) 2. Przygot. (indywidualnie) 3. Inspekcja (cały zespół) Moderator Sekretarz 1! 1 > 1! Kontrola jakoci artefaktów (23) Kada inspekcja powinna by poprzedzona działaniami przygotowawczymi ze strony kierownictwa oraz czynnociami o charakterze planistyczno-organizacyjnymi, za które odpowiada moderator. Cały proces składa si z piciu kroków. Najpierw ma miejsce omówienie. Spotyka si cały zespół biorcy udział w inspekcji i autor przedstawia ogólne omówienie artefaktu, natomiast moderator podaje dla orientacji dane dotyczce minimalnego czasu, jaki bdzie potrzebny na przygotowanie si inspektorów do inspekcji oraz jak wiele anomalii wykryto we wczeniejszych tego typu przedsiwziciach. Potem kady z inspektorów pracuje indywidualnie i ocenia dany artefakt (tzn. czyta kod, czy te specyfikacj). Oczywicie, w trakcie czytania zauwaa róne anomalie, które dokumentuje na formularzach przygotowanych przez moderatora i przekazuje te formularze moderatorowi. Moderator zbiera informacj o anomaliach i przesyła je dalej do autora. Ponadto moderator lub prezenter ustalaj sposób prezentacji artefaktu w trakcie spotkania, jakie si ma odby. W trzecim kroku dochodzi do drugiego spotkania inspekcyjnego, w którym bierze udział cały zespół inspektorów. Moderator otwiera spotkanie, sprawdza, czy wszyscy inspektorzy s przygotowani do inspekcji i prezentowane s uwagi natury ogólnej dotyczce artefaktu. Nastpnie prezenter przedstawia artefakt i zaczyna si omawianie dostrzeonych anomalii. Na kocu podejmowana jest decyzja w sprawie artefaktu. S trzy moliwoci: Artefakt moe by w pełni zaakceptowany. Moe by akceptacja warunkowa, co oznacza, e s potrzebne pewne korekty ale skala poprawek jest na tyle mała, e sprawdzenie poprawnoci wykonania tych korekt powierza si moderatorowi lub innemu członkowi zespołu inspekcyjnego. Moe te by wykrytych tyle powanych anomalii, e zespół inspekcyjny moe doj do wniosku, i po dokonaniu poprawek przez autora potrzebna bdzie jeszcze jedna inspekcja. 23

24 Inspekcje zgodne z IEEE 1028 Prezenter Moderator Inspektor Autor Sekretarz 1. Omówienie (cały zespół) 2. Przygot. (indywidualnie) 3. Inspekcja (cały zespół) 4. Naprawa 5. Sprawdzenie Kontrola jakoci artefaktów (24) W czwartym kroku ma miejsce korekta wykrytych anomalii. Na kocu dochodzi do sprawdzenia, przez moderatora lub inn wyznaczon osob, czy korekty zostały poprawnie wprowadzone. Jeli nie wykryto adnych anomalii, to ten krok jest pusty. Jeli była decyzja, e potrzebna jest jeszcze jedna inspekcja, to ten krok zamienia si w kolejn inspekcj. 24

25 Inspekcje Fagana Cykl ycia Projekt Kod Specyfikacje zewntrzne (funkcje) Specyfikacje wewntrzne (moduł) - I 0 Specyfikacje logiki przetw - I 1 inspek projek Kodowanie (logika) - I 2 inspek kodu Testowanie jednostkowe Test Test funkcji (zewn.), składnika, systemu Kontrola jakoci artefaktów (25) Aby przedstawi pewne dane charakteryzujce pracochłonno inspekcji i mogce pomóc w prawidłowym jej zaplanowaniu odwołam si do inspekcji Fagana. Był to historycznie pierwszy rodzaj inspekcji przeprowadzanych w odniesieniu do oprogramowania. Koncepcja ta narodziła si w połowie lat 70-tych w firmie IBM. W tamtych czasach cykl ycia oprogramowania był w firmie IBM podzielony na trzy fazy: projekt, kod i testy. Projekt obejmował tzw. specyfikacje zewntrzne (dzisiaj nazywamy to specyfikacj wymaga), specyfikacje wewntrzne dotyczce interfejsów modułów kodu i specyfikacje logiki przetwarzania. Oznaczmy przez I1 inspekcje projektu, czyli inspekcje specyfikacji logiki przetwarzania. Jeszcze bdziemy si do nich odwoływa. Kodowanie było podzielone na dwie fazy: samo kodowanie w sensie pisania programu i testowanie jednostkowe. Niech I2 oznacza inspekcje kodu. 25

26 Inspekcje Fagana Design Unit I 1 Code I 2 I test 3 Kontrola jakoci artefaktów (26) Fagan wprowadził inspekcje dotyczce projektu rozumianego jako specyfikacja logiki przetwarzania (Design) i przeprowadzane zaraz po tej fazie (I1 oznacza t włanie inspekcj), inspekcje kodu (Code) oznaczone na slajdzie przez I2 i dodatkowe inspekcje oprogramowania przeprowadzane po testowaniu jednostkowym (na slajdzie oznaczone jako I3). 26

27 Inspekcje Fagana Design Unit I 1 Code I 2 I test 3 Oszczdnoci (godz/kloc): I 1 : 94 I 2 : 51 I 3 : -20 Kontrola jakoci artefaktów (27) Z zebranych przez Fagana danych wynika, e wprowadzenie inspekcji projektu (I1) pozwoliło zaoszczdzirednio 94 godziny na kadym tysicu linii kodu. Inspekcje kodu (I2) dały oszczdnoci w wysokoci 51 godzin na tysic linii kodu. Natomiast inspekcje przeprowadzane po testach jednostkowych spowodowały dodatkowe obcienie w wysokoci 20 godzin na tysic linii kodu. Zatem nie warto prowadzi inspekcji po testach jednostkowych. 27

28 Inspekcje Fagana Prdko (loc/h) I 1 I 2 1. Omówienie (zespół) 500 niepotrzebne 2. Przygotowanie (indyw.) Inspekcja (zespół) Naprawa Sprawdzenie - - Spotkanie inspekcyjne <= 2 godz 1-2 spotkania na dzie Kontrola jakoci artefaktów (28) Ciekawe s te dane dotyczce wydajnoci inspekcji. Krok omówienia był wykonywany w inspekcjach dotyczcych projektu (I1) z prdkoci 500 linii kodu na godzin. Przy drugiej inspekcji (I2) to omówienie było ju zbdne, bo inspektorzy znali produkt. Przygotowanie do inspekcji przebiegało z prdkoci około 100 linii kodu na godzin w przypadku pierwszej inspekcji i 125 linii kodu na godzin jeli chodzi o drug inspekcj. W trakcie samego spotkania inspekcyjnego prdko inspekcji wynosiła 130 linii kodu na godzin dla inspekcji I1 i 150 dla inspekcji I2. Ponadto Fagan zaobserwował, e spotkanie inspekcyjne nie powinno trwa dłuej ni 2 godziny, bo wtedy bardzo mocno spada wydajno. Jeli chodzi o liczb spotka, to nie powinno by ich wicej ni 2 dziennie. 28

29 Inspekcje Fagana Lista kontrolna dla inspekcji projektu Ex Wr Missing 1, + H 1, ( (+ +I H "E( % ( # H 1, + E H 1, ( + 8 ( G 3!H 1, + ( % / G I + G ( H 1, G ( 2 + G Kontrola jakoci artefaktów (29) Inspekcje mog by wspomagane listami kontrolnymi. Przykładow list kontroln pokazano na slajdzie. Na tej licie pytania podzielono na 3 kategorie. Missing oznacza pytanie o rzeczy, których by moe brakuje. Kategoria Wr (Wrong) oznacza rzeczy, o których co prawda nie zapomniano, ale które sle zapisane. Ostatnia kategoria Ex (Extra) oznacza rzeczy nadmiarowe. 29

30 Plan wykładu 1! % 1 & 1! " 1 # ' Kontrola jakoci artefaktów (30) Przegldy nigdy nie s idealne zawsze pozostanie jaka liczba defektów, które pozostan niezauwaone na etapie przegldu i ujawni si dopiero w póniejszych fazach. Dobrze byłoby zatem umie oszacowa liczb defektów, które nie zostały wykryte. 30

31 Szacowanie liczby nie wykrytych defektów + 0G Kontrola jakoci artefaktów (31) Generalnie s dwie metody szacowania liczby nie wykrytych defektów: wstrzykiwanie defektów i tzw. 2-krotne łowienie (po angielsku ta ostatnia metoda nazywa si capture-recapture). 31

32 Wstrzykiwanie defektów /= 3 0! 3 =. / 0 5 = 3+ H. 4 3 I ' D Kontrola jakoci artefaktów (32) Zacznijmy od wstrzykiwania defektów koncepcja tej metody jest bardzo prosta. W pierwszym kroku do artefaktu, który chcemy podda kontroli jakoci dodajemy n defektów. W drugim kroku przekazujemy tak spreparowany artefakt do kontroli jakoci. Inspektorzy, na przykład korzystajc z wczeniej przedstawionej procedury, szukaj w tym artefakcie defektów. Po zakoczeniu ich pracy dostajemy raport, który zawiera cał list znalezionych defektów. Przegldamy t list i stwierdzamy, e k sporód wszystkich znalezionych defektów s to defekty przez nas dodane, natomiast m defektów jest zupełnie nowych. Zakładajc, e wykrycie kadego z n przez nas wstawionych defektów jest tak samo trudne jak wykrycie pozostałych, moemy oszacowa liczb wszystkich defektów (nie liczc defektów przez nas wstawionych) na podstawie przedstawionego, prostego wzoru: liczba defektów jest w przyblieniu równa liczbie nowo wykrytych defektów, m, pomnoonej przez liczb dodanych przez nas defektów, n, i podzielonej przez liczbie naszych defektów, jakie udało si wykry inspektorom. Oczywicie, ten wzór mona stosowa, o ile liczba k > 0. Przy k = 0 inspekcj (czy inn form kontroli jakoci) naleałoby powtórzy. 32

33 Szacowanie liczby nie wykrytych defektów + 0G Kontrola jakoci artefaktów (33) Przejd teraz do omówienia metody 2-krotnego łowienia. 33

34 2-krotne łowienie '( G H Kontrola jakoci artefaktów (34) Metoda ta została opracowana w latach 50-tych przez biologów i dopiero w połowie lat 90-tych została przeniesiona na grunt inynierii oprogramowania. Załómy, e chcemy oszacowa liczb ryb w stawie. Moglibymy wówczas zastosowa nastpujc procedur. 34

35 3 /G # G 2-krotne łowienie Kontrola jakoci artefaktów (35) Najpierw łowimy pewn próbk ryb. 35

36 3 /G # G 5 < 2-krotne łowienie Kontrola jakoci artefaktów (36) Potem złowione ryby oznaczamy w jaki sposób. 36

37 3 /G # G 5 < J * EI 2-krotne łowienie Kontrola jakoci artefaktów (37) Nastpnie je wszystkie wypuszczamy z powrotem do wody. 37

38 2-krotne łowienie 3 /G # G 5 < J * EI K + # Kontrola jakoci artefaktów (38) Po pewnym czasie jeszcze raz łowimy ryby. 38

39 2-krotne łowienie 3 /G # G 5 < J * EI K + # L '( 2 H Kontrola jakoci artefaktów (39) I teraz liczymy ile wród złowionych ryb jest ryb, które wczeniej oznakowalimy. 39

40 & ) 01 J5 1 D8 ) /01 2-krotne łowienie 3 /G # G 5 < J * EI K + # L '( 2 H Kontrola jakoci artefaktów (40) Załómy, e za pierwszym razem złapalimy 20 ryb, a za drugim 30, z czego 5 było oznakowanych. Oznacza to, e wszystkich ryb jest 6 razy wicej ni oznakowanych. A poniewa oznaczylimy 20 ryb, std wniosek, e wszystkich ryb w stawie powinno by około

41 2-krotne łowienie Artefakt > * K I ' >JKD* A *)1 333 Kontrola jakoci artefaktów (41) Rozumowanie to mona łatwo przenie na grunt kontroli jakoci. Rybami bd w tym przypadku defekty, których liczb chcielibymy oszacowa. Załómy, e mamy dwóch recenzentów danego artefaktu. Kady z nich bdzie łowił defekty, podobnie jak poprzednio łowilimy ryby. Niech zbiór A reprezentuje defekty znalezione przez lewego recenzenta. I analogicznie, niech zbiór B reprezentuje defekty znalezione przez prawego recenzenta. Cz wspóln tych zbiorów oznaczmy przez C. W tej sytuacji zbiór A odpowiada rybom złowionym za pierwszym razem, które zostały przez nas oznaczone. Natomiast zbiór B jest jakby drugim połowem. Zatem, rozumujc podobnie jak poprzednio, liczb wszystkich defektów mona oszacowa mnoc liczno zbioru A przez stosunek licznoci zbioru B do licznoci czci wspólnej, oznaczonej tutaj jako C. Oczywicie, wzór ten mona stosowa tylko wtedy, gdy cz wspólna nie jest pusta. 41

42 2-krotne łowienie + % F 0 > K % I ' )>JKD*! Kontrola jakoci artefaktów (42) Jeli mielibymy wicej ni dwóch recenzentów, to moglibymy postpi nastpujco. Znajdujemy recenzenta, który znalazł najwicej unikatowych defektów i znalezione przez niego defekty traktujemy jako zbiór A. Natomiast defekty wykryte przez wszystkich pozostałych recenzentów traktujemy jako zbiór B. I dalej obliczenia s prowadzone jak poprzednio. 42

43 Plan wykładu! Kontrola jakoci artefaktów (43) Czas na podsumowanie wykładu. 43

44 Jako oprogramowania ( ) ( ) 2 ( * ' ! Kontrola jakoci artefaktów (44) Na pocztku wykładu podałem definicj jakoci. Według Crosby ego jako jest to zgodno z wymaganiami. Takie rozumienie jakoci zostało przeniesione do standardu ISO 9001:

45 Cztery filary zapewniania jakoci Jako oprogramowania C ) (+ B & + Kontrola jakoci artefaktów (45) Powiedziałem te, e testowanie i przegldy nale do głównych filarów, na których opiera si jako oprogramowania. 45

46 Rodzaje testowania Testy Wykonanie automat. Wykonanie rczne Dane automat. Dane rczne E! Kontrola jakoci artefaktów (46) Omawiajc testowanie powiedziałem, e z praktycznego punktu widzenie najwiksze znaczenie ma rczne przygotowywanie danych testowych. Jeli chodzi o wykonywanie testów, to s dwie szkoły: jedni twierdz, e nie opłaca si automatyzowa wykonywania testów, a drudzy wrcz przeciwnie. 46

47 Inspekcje zgodne z IEEE 1028 Prezenter Moderator Inspektor Autor Sekretarz 1. Omówienie (cały zespół) 2. Przygot. (indywidualnie) 3. Inspekcja (cały zespół) 4. Naprawa 5. Sprawdzenie Kontrola jakoci artefaktów (47) Przedstawiłem te inspekcje zgodne ze standardem IEEE 1028 i omówiłem krótko wyniki pomiarów inspekcji dokonanych przez Fagana w połowie lat 70-tych w firmie IBM. 47

48 Wstrzykiwanie defektów =. / 0 /= 3 0! 3 5 = 3+ H. 4 3 I ' D Kontrola jakoci artefaktów (48) W ostatniej czci wykładu omówiłem dwie metody szacowania liczby nie wykrytych defektów. Pierwsza metoda polegała na wstrzykiwaniu defektów i liczeniu jak ich cz udało si wykry w czasie kontroli jakoci. 48

49 2-krotne łowienie Artefakt > * K I ' >JKD* Kontrola jakoci artefaktów (49) Druga metoda nie wymaga modyfikowania artefaktów. Jeli mamy przynajmniej dwóch recenzentów, to liczb defektów mona oszacowa na podstawie liczby wykrytych przez nich defektów, A i B, oraz liczebnoci czci wspólnej, C. 49

50 = % % % % %( Dzikuj za uwag Kontrola jakoci artefaktów (50) Dzikuj za uwag i radz zawsze pamita o kontroli jakoci. 50