Inżynieria Oprogramowania Laboratorium mgr inż. Michał Bukowski randam@interia.eu

Laboratorium nr 4 Temat: Inspekcja kodu źródłowego Informacje wstępne Jest wiele definicji jakości. Dużą popularność zyskała definicja jakości 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ę umiejętnością wydobycia wymagań, których klient początkowo nie jest świadom, a na których tak naprawdę bardzo mu zależy. 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ę więc dziwić, że klient nie ma klarownego poglądu na wymagania, bo nikt – łącznie z nim – takiego systemu jeszcze nie widział.

Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Rola przeglądów kodu Warto zadać sobie pytanie jaki jest koszt naprawy błędu i czy w związku z tym warto przeprowadzać przeglądy kodu? Z danych zebranych w różnych firmach informatycznych wynika, że zdecydowanie tak. Z danych opublikowanych przez firmę IBM wynika, że średni czas identyfikacji błędu na poziomie przeglądu projektu oprogramowania wynosi 1 godz. Wykrycie tego samego błędu na poziomie inspekcji kodu będzie już kosztowało 20 godzin. A jeśli ten błąd zostałby wykryty na poziomie testów maszynowych, to jego identyfikacja kosztowałaby już 82 godziny. Jak więc widać, im szybciej jakiś błąd zostanie wykryty, tym mniejsze są koszty z nim związane. Zatem warto dbać o jakość od samego początku, już na etapie specyfikacji wymagań. Ale jak mamy tylko specyfikację wymagań, to o testowaniu nie może być mowy. Stąd tak duża rola przeglądów, które są tematem dzisiejszych zajęć.

Rola przeglądów kodu c.d. Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Rola przeglądów kodu c.d. Na użytek zajęć przyjmiemy definicję anomalii zaproponowaną w standardzie IEEE 1028 dotyczącym przeglądów. Przez anomalię rozumie się sytuację różną od oczekiwanej, przy czym oczekiwania opierają się na specyfikacji, standardach lub na czyimś doświadczeniu. Ta definicja pasuje zarówno do anomalii anatomicznych, jak i do anomalii dotyczących oprogramowania. Zgodnie ze standardem IEEE 1028 przegląd (po angielsku „review”) jest to proces lub spotkanie, w trakcie którego artefakt związany z oprogramowaniem (np. kod) jest prezentowany różnym osobom w celu skomentowania lub uzyskania jego zatwierdzenia. Inaczej mówiąc, przegląd jest to ocena artefaktu (np. kodu lub specyfikacji) realizowana przez grupę osób.

Rola przeglądów kodu c.d. Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Rola przeglądów kodu c.d. Inspekcja (po angielsku „inspection”) jest to wizualne sprawdzenie artefaktu celem wykrycia lub zidentyfikowania anomalii dotyczących oprogramowania. Inspekcje są przeprowadzane przez osoby z tego samego szczebla zarządzania (szefowie nie biorą w nich udziału), a prowadzą je specjalnie przeszkoleni (niezależni) moderatorzy (po angielsku „facilitators” lub „Inspection leaders”). Przeglądy i inspekcje spełniają dwie funkcje: z jednej strony służą zapewnieniu jakości, a z drugiej są sposobem przekazywania informacji o tworzonym oprogramowaniu. Jeśli nawet ktoś nie tworzył danego modułu, ale brał udział w jego inspekcji, to na pewno będzie więcej wiedział na temat tego modułu niż ktoś, kto w ogóle nie miał styczności z tym modułem. Podobnie jest z inspekcją specyfikacji. Ponadto, jeśli programista w trakcie inspekcji specyfikacji nie wykrył jakiegoś błędu, to później z większym zrozumieniem odniesie się do tego błędu, gdy go wykryje na etapie np. kodowania.

Inspekcja zgodnie z IEE1028 Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Inspekcja zgodnie z IEE1028 Zostaną teraz przedstawione inspekcje w wersji zgodnej ze standardem IEEE 1028 z 1997 roku. Jak już wspomniano, spotkanie inspekcyjne jest prowadzone przez moderatora. Jego zadaniem jest zaplanowanie inspekcji, sprawne jej przeprowadzenie i zebranie danych związanych 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 podkreślenie najistotniejszych elementów. Zadaniem autora artefaktu jest przygotowanie go do inspekcji, wyjaśnienie ewentualnych wątpliwości, jakie mogą się pojawić się w trakcie inspekcji i usunięcie defektów wykrytych w trakcie inspekcji. Inspektor jest to główna rola. Zadaniem inspektora jest wykrycie anomalii, jakie być może zakradły się do badanego artefaktu. Zazwyczaj w inspekcji bierze udział kilku inspektorów reprezentujących różne punkty widzenia. W roli inspektora może być analityk, reprezentant klienta, specjalista od bezpieczeństwa systemów informatycznych itp. Ostatnią, piątą rolą jest rola sekretarza. Sekretarz ma dokumentować wykryte anomalie, podjęte decyzje, rekomendacje itp. Rolę sekretarza i moderatora może pełnić ta sama osoba. Każda inspekcja powinna być poprzedzona działaniami przygotowawczymi ze strony kierownictwa oraz czynnościami o charakterze planistyczno-organizacyjnymi, za które odpowiada moderator.

Inspekcja zgodnie z IEE1028 c.d. Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Inspekcja zgodnie z IEE1028 c.d. Cały proces składa się z pięciu kroków: 1) Najpierw ma miejsce omówienie. Spotyka się cały zespół biorący udział w inspekcji i autor przedstawia ogólne omówienie artefaktu, natomiast moderator podaje – dla orientacji – dane dotyczące minimalnego czasu, jaki będzie potrzebny na przygotowanie się inspektorów do inspekcji oraz jak wiele anomalii wykryto we wcześniejszych tego typu przedsięwzięciach. 2) Potem każdy z inspektorów pracuje indywidualnie i ocenia dany artefakt (tzn. czyta kod, czy też specyfikację). Oczywiście, w trakcie czytania zauważa 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 dotyczące artefaktu. Następnie prezenter przedstawia artefakt i zaczyna się omawianie dostrzeżonych anomalii. Na końcu podejmowana jest decyzja w sprawie artefaktu. Są trzy możliwości: - Artefakt może być w pełni zaakceptowany. Może być akceptacja warunkowa, co oznacza, że są potrzebne pewne korekty ale skala poprawek jest na tyle mała, że sprawdzenie poprawności wykonania tych korekt powierza się moderatorowi lub innemu członkowi zespołu inspekcyjnego. Może też być wykrytych tyle poważnych anomalii, że zespół inspekcyjny może dojść do wniosku, iż po dokonaniu poprawek przez autora potrzebna będzie jeszcze jedna inspekcja.

Inspekcja zgodnie z IEE1028 c.d. Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Inspekcja zgodnie z IEE1028 c.d. W czwartym kroku ma miejsce korekta wykrytych anomalii. 5) Na końcu dochodzi do sprawdzenia, przez moderatora lub inną wyznaczoną osobę, czy korekty zostały poprawnie wprowadzone. Jeśli nie wykryto żadnych anomalii, to ten krok jest pusty. Jeśli była decyzja, że potrzebna jest jeszcze jedna inspekcja, to ten krok zamienia się w kolejną inspekcję.

Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Inspekcja Fagana Aby przedstawić pewne dane charakteryzujące pracochłonność inspekcji i mogące pomóc w prawidłowym jej zaplanowaniu odniesiemy 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 zewnętrzne (dzisiaj nazywamy to specyfikacją wymagań), specyfikacje wewnętrzne dotyczące interfejsów modułów kodu i specyfikacje logiki przetwarzania. Oznaczmy przez I1 inspekcje projektu, czyli inspekcje specyfikacji logiki przetwarzania. Jeszcze będziemy 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.

Design ⇒ l1 ⇒ Code ⇒ l2 ⇒ Unit test ⇒ l3 Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Inspekcja Fagana c.d. Fagan wprowadził inspekcje dotyczące projektu rozumianego jako specyfikacja logiki przetwarzania (Design) i przeprowadzane zaraz po tej fazie (I1 oznacza tę właśnie inspekcję), inspekcje kodu (Code) oznaczone przez I2 i dodatkowe inspekcje oprogramowania przeprowadzane po testowaniu jednostkowym (na slajdzie oznaczone jako I3).  Design  ⇒  l1  ⇒  Code  ⇒  l2  ⇒  Unit test  ⇒  l3 Z zebranych przez Fagana danych wynika, że wprowadzenie inspekcji projektu (I1) pozwoliło zaoszczędzić średnio 94 godziny na każdym tysiącu linii kodu. Inspekcje kodu (I2) dały oszczędności w wysokości 51 godzin na tysiąc linii kodu. Natomiast inspekcje przeprowadzane po testach jednostkowych spowodowały dodatkowe obciążenie w wysokości 20 godzin na tysiąc linii kodu. Zatem nie warto prowadzić inspekcji po testach jednostkowych.  

Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Inspekcja Fagana c.d. Ciekawe są też dane dotyczące wydajności inspekcji. Krok omówienia był wykonywany w inspekcjach dotyczących projektu (I1) z prędkością 500 linii kodu na godzinę. Przy drugiej inspekcji (I2) to omówienie było już zbędne, bo inspektorzy znali produkt. Przygotowanie do inspekcji przebiegało z prędkością około 100 linii kodu na godzinę w przypadku pierwszej inspekcji i 125 linii kodu na godzinę jeśli chodzi o drugą inspekcję. W trakcie samego spotkania inspekcyjnego prędkość 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łużej niż 2 godziny, bo wtedy bardzo mocno spada wydajność. Jeśli chodzi o liczbę spotkań, to nie powinno być ich więcej niż 2 dziennie.

Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Inspekcja Fagana c.d. Inspekcje mogą być wspomagane listami kontrolnymi. Przykładowa lista kontrolna może mieć następującą postać: Missing: Czy wszystkie stałe są zdefiniowane? Czy w trakcie manipulacji kolejką może wystąpić przerwanie? Czy jeśli tak, to czy kolejka jest ujęta w rejon krytyczny? Czy rejestry są odtwarzane przy wyjściu? Czy wszystkie liczniki są odpowiednio inicjowane (0 lub 1)? Wrong: Czy są literały numeryczne, które powinny być zastąpione stałymi symbolicznymi? Extra: Czy wszystkie bloki na schemacie są potrzebne? Na tej liście pytania podzielono na 3 kategorie. Missing oznacza pytanie o rzeczy, których być może brakuje. Kategoria Wrong oznacza rzeczy, o których co prawda nie zapomniano, ale które są źle zapisane. Ostatnia kategoria Extra oznacza rzeczy nadmiarowe.

Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Materiały dodatkowe Helion 2008:  "Sztuka testowania oprogramowana". Glenford J. Myers i inni. [Na stronie wydawnictwa Helion dostępny jest przykładowy rozdział w formacie PDF: "Inspekcja programów, wędrówka po kodzie źródłowym i przegląd kodu"] "Inspekcje kodu jako skuteczna metoda weryfikacji oprogramowania". Mariusz Chrapko "Była sobie inspekcja - Określenie, przygotowanie i definicja procesu inspekcji". Arkadiusz Merta "Była sobie inspekcja - Aplikacja procesu inspekcji". Arkadiusz Merta "Formalne Inspekcje - Sprawdzony sposób na poprawę jakości kodu". Mariusz Chrapko

Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Ćwiczenia Należy przeprowadzić inspekcję kodu programu AIED, w grupach 2-3 osobowych. Zadanie podzielone zostało na mniejsze podzadania, z których większość można wykonać indywidualnie (w przypadku, gdy nie ma możliwości stworzenia grup) Program AIED, służy do losowania próbek z populacji o różnych rozkładach. Kod programu (zip). http://www.randam.pl/cw4.zip Jako podsumowanie wykonania ćwiczenia, należy stworzyć raport według wzoru (doc). http://www.randam.pl/cw4.doc

Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Ćwiczenia c.d. 1) Ustalenie składu zespołu: Należy skład oraz role pełnione w zespole, a także opisać przyjęty model przeglądu (agendę dla poszczególnych faz) Opis zespołu i agendę należy umieścić w raporcie. 2) Wybranie fragmentu kodu do inspekcji: Należy przeanalizować kod źródłowy programu AIED i wybrać fragment kodu do inspekcji. Wybrany fragment, na potrzeby zadania powinien się mieścić w przedziale od 100 do 125 źródłowych linii kodu (według szacunków w fazie przygotowania prędkość wynosi 100-125 SLOC / h). Należy uzasadnić, dlaczego zdecydowano się na inspekcję wskazanego fragmentu kodu. Uzasadnienie należy umieścić w raporcie.

Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Ćwiczenia c.d. 3) Stworzenie listy kontrolnej: Przed przystąpieniem do indywidualnego przygotowania do inspekcji, należy stworzyć listę kontrolną, która ułatwi i usystematyzuje proces przeglądu. Można stworzyć listę specjalnie dedykowaną dla języka Java lub ogólną dla wszystkich języków programowania. Listę kontrolną należy umieścić w raporcie. 4) Indywidualne przygotowanie do przeglądu: Należy przejrzeć wybrany do inspekcji fragment kodu i wyszczególnić znalezione błędy (indywidualnie). Grupy błędów oraz wzór formularza ich rejestracji znajduje się w szablonie. Raporty z przygotowania poszczególnych uczestników, należy umieścić w raporcie końcowym

Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Ćwiczenia c.d. 5) Przeprowadzenie inspekcji kodu: Należy przeprowadzić inspekcje zgodnie z przyjętym modelem i przydzielonymi rolami, a następnie zamieścić wyniki do raportu końcowego.

Raport proszę przesłać na randam@interia.eu Laboratorium nr 4 c.d. Temat: Inspekcja kodu źródłowego Ćwiczenia c.d. Raport proszę przesłać na randam@interia.eu