Eksperymentalne porównanie inspekcji UML-HAZOP z przeglądem niestrukturalnym

Transkrypt

1 Wersja postprint artykułu opublikowanego na VI Krajowej Konferencji Inżynierii Oprogramowania. KKIO'2004, Gdańsk, 5-8 października 2004, Wydawnictwo WNT, str Eksperymentalne porównanie inspekcji UML-HAZOP z przeglądem niestrukturalnym Aleksander Jarzębowicz, Janusz Górski Katedra Inżynierii Oprogramowania Politechnika Gdańska {olek, jango}@eti.pg.gda.pl Streszczenie Artykuł opisuje eksperyment przeprowadzony w warunkach akademickich, z udziałem studentów Politechniki Gdańskiej. Celem eksperymentu było porównanie dwóch technik przeglądowych: inspekcji opartej na metodzie UML-HAZOP oraz zwykłego przeglądu niestrukturalnego. W ramach porównania obu technik dokonano oceny ich skuteczności i wydajności. Metodę UML-HAZOP poddano ponadto dodatkowej ocenie uczestników za pomocą anonimowych ankiet. W rozdziale przedstawiono plan i przebieg eksperymentu oraz uzyskane w nim wyniki, poprzedzone wprowadzeniem do tematyki przeglądów i inspekcji oraz skróconym omówieniem metody UML-HAZOP. 1. Wprowadzenie Cel każdego przedsięwzięcia informatycznego można w ogólny sposób zdefiniować jako dostarczenie, w ramach ustalonych ograniczeń czasowych i budżetowych, produktu spełniającego potrzeby i oczekiwania klienta. W praktyce niewiele przedsięwzięć osiąga jednak ten cel. Świadczą o tym statystyki pokazujące liczbę projektów przekraczających zaplanowany budżet lub harmonogram, wytwarzających produkty nie spełniające stawianych im wymagań, bądź też po prostu przerywanych w trakcie realizacji z powodu niezadowalających rezultatów. Jednym z czynników wpływających na taki stan rzeczy są błędy popełniane we wczesnych etapach prac wytwórczych (pozyskiwanie wymagań, analiza, projektowanie). Wynikiem tych błędów jest obecność w dokumentacji projektowej, w szczególności we wczesnych reprezentacjach systemu, różnego rodzaju anomalii: od defektów projektowych polegających na niewłaściwym odwzorowaniu problemu bądź jego rozwiązania, poprzez przekroczenie zakresu metryk lub heurystyk przyjmowanych za optymalne, aż do naruszenia specyficznych atrybutów systemu np. bezpieczeństwa lub ochrony. Nie wykryta anomalia przenoszona jest do kolejnych reprezentacji systemu, a jej usunięcie w każdym kolejnym etapie wytwarzania wymaga coraz większych nakładów czasowych i finansowych. Problemu tego można w znacznym stopniu uniknąć poprzez wprowadzenie dodatkowych działań ukierunkowanych na wykrywanie anomalii w dokumentacji

2 2 Aleksander Jarzębowicz, Janusz Górski wczesnych etapów cyklu wytwarzania, zanim zostanie ona wykorzystana jako podstawa dalszych prac. Wskazane jest więc opracowanie metod wspierających analityka sprawdzającego dokumentację pod kątem obecności anomalii. Widoczna jest tu potencjalna przydatność metod opartych na idei inspekcji. Spośród dokumentacji opracowywanej w projektach informatycznych, szczególnie interesującym obszarem zastosowań usystematyzowanych metod wykrywania anomalii są różnego rodzaju modele wyposażone w reprezentację graficzną i co najmniej częściowo sformalizowaną składnię. Wśród przykładów można wymienić modele obiektowe (statyczne, dynamiczne), relacyjne, czy też ontologie. Mogą one powstawać w bardzo wczesnych etapach procesu wytwarzania, zaś w porównaniu z innymi elementami dokumentacji (np. specyfikacją wymagań) charakteryzują się lepiej określoną strukturą i składnią, co umożliwia precyzyjniejsze określenie kryteriów i zasad analizy. W ramach badań prowadzonych przez autorów podjęte zostały działania ukierunkowane na opracowanie nowej metody inspekcji, dedykowanej wykrywaniu anomalii w modelach z reprezentacją graficzną. W dotychczasowych pracach skoncentrowano się na modelach obiektowych, wyrażonych w notacji UML i na defektach projektowych, które stanowią najpowszechniejszą klasę anomalii, dotyczącą praktycznie każdego przedsięwzięcia informatycznego. W wyniku tych prac powstała metoda UML-HAZOP, której skrócony opis przedstawiono w podrozdziale 3. Zaproponowane w ramach tej metody rozwiązania obejmują m.in. metodę budowy list kontrolnych, propozycje konkretnych list, strukturę procesu analizy oraz informatyczny system wspomagający. Takie propozycje, jak zresztą wszystkie z zakresu inżynierii oprogramowania, powinny zostać poddane walidacji na drodze eksperymentalnej. Jest to tym bardziej istotne, że intencją autorów jest opracowanie metody przydatnej w praktyce, możliwej do łatwego zastosowania w rzeczywistych przedsięwzięciach informatycznych. Pewne działania związane z eksperymentalną walidacją metody zostały przeprowadzone we wcześniejszych etapach prac nad metodą UML-HAZOP. Wykonano cztery studia przypadków polegające na analizie modeli systemów pochodzących z rzeczywistych, zakończonych implementacją projektów informatycznych [GOJA2002]. We wszystkich studiach przypadków znalezione zostały istotne anomalie obecne w modelach. Eksperymenty te miały jednak pewne ograniczenia. Po pierwsze, analizy modeli prowadzone były zawsze przez osoby o wysokim stopniu znajomości metody, w związku z czym nie uwzględniano kwestii nakładów na naukę metody oraz jej subiektywnego odbioru przez nowego, niewtajemniczonego użytkownika. Po drugie, otrzymywane podczas eksperymentów wyniki miały charakter wartości bezwzględnych, co uniemożliwiało ocenę w porównaniu z innymi technikami zapewniania jakości. Ze względu na powyższe ograniczenia, postanowiono przeprowadzić działania walidacyjne innego typu, o charakterze kontrolowanych eksperymentów: z udziałem większej liczby uczestników, podzielonych na dwie grupy i polegające na przeprowadzeniu przez uczestników analiz uprzednio przygotowanych modeli dwiema różnymi metodami (w tym UML-HAZOP). Oprócz porównania opracowywanej metody z innymi pod względem wybranych charakterystyk, eksperymenty w takiej formule dają również możliwość zgromadzenia danych dotyczących kwestii stosowania UML- HAZOP przez niedoświadczonych użytkowników. W pierwszej tego typu próbie zdecydowano się przyjąć przy porównaniu za punkt odniesienia zwykły przegląd, bez zdefiniowanej struktury działania ani określonych kategorii poszukiwanych defektów.

3 Eksperymentalne porównanie inspekcji UML-HAZOP z przeglądem niestrukturalnym 3 Eksperyment przeprowadzono w całości w warunkach akademickich, co może rodzić wątpliwości co do adekwatności jego wyników, jednakże tego typu doświadczenia również mogą dostarczać interesujących rezultatów [WGJN2002]. Dodatkowo należy wspomnieć, że uczestnikami eksperymentu byli studenci V roku informatyki specjalności Inżynieria Systemów i Bazy Danych, których umiejętności z zakresu inżynierii oprogramowania można uznać za porównywalne do kompetencji pracowników przemysłu. 2. Przeglądy i inspekcje Szeroko rozumiane techniki przeglądowe posiadają już stosunkowo długą historię w dziedzinie wytwarzania oprogramowania. Po raz pierwszy zaproponowane zostały w 1976 roku przez Michaela Fagana [FAGA1976]. Rezultatem szybko zauważonej skuteczności i opłacalności tego podejścia, był widoczny w kolejnych latach rozwój różnych wariantów technik przeglądowych, zróżnicowanych pod względem zakresu, celu i struktury organizacyjnej, wśród których znalazły się m.in. [FRWE1990]: przeglądy (ang. technical review), inspekcje (ang. inspection), przeglądy-prezentacje (ang. walkthrough), przeglądy rotacyjne (ang. round-robin review). Wszystkie one bazowały jednak na jednej podstawowej zasadzie mówiącej, że najtrudniej jest zauważyć własne błędy, w związku z czym warto do ich poszukiwania zatrudnić innych. Przeglądy i inspekcje opierają się na podobnym procesie. Proces ten został zilustrowany na rys. 1, na którym dodatkowo zaznaczono zakres przeprowadzonego eksperymentu. Proces rozpoczyna spotkanie inicjujące, mające na celu zapoznanie uczestników z przedmiotem analizy, zmotywowanie ich oraz, jeśli zachodzi taka potrzeba, przeszkolenie w zakresie stosowanej techniki przeglądowej. Podczas analizy indywidualnej każdy z uczestników zapoznaje się z kontrolowanym produktem oraz dodatkową dokumentacją i rejestruje wykryte defekty. Analiza grupowa ma formę spotkania całego zespołu, na którym uczestnicy zgłaszają znalezione wcześniej defekty, omawiają je, a także próbują znaleźć nowe w trakcie spotkania. Rezultaty analizy grupowej przekazywane są właścicielowi (na ogół autorowi) kontrolowanego produktu, który na tej podstawie dokonuje jego korekty. Następnie ma miejsce sprawdzenie czy korekta usunęła wszystkie defekty. Z uwagi na fakt, iż w procesie uczestniczy kilka osób i pochłania on pewne zasoby, musi on podlegać planowaniu i zarządzaniu. Mimo podobieństw, pomiędzy przeglądem a inspekcją występują jednak dość znaczne różnice. Można powiedzieć, że inspekcja stanowi dalece sformalizowaną wersję przeglądu, opartą na statystycznej kontroli procesu i powstałą w wyniku dążeń do optymalizacji efektywności. Formalizacja procesu obejmuje następujące aspekty [GIGR1993]: Sterowanie uwagą inspektorów poprzez przypisanie ich do określonych ról oraz wykorzystanie list kontrolnych zawierających sugestie poszukiwanych defektów; Uzupełnienie procesu o etapy otwarcia i zamknięcia, w których na podstawie ściśle określonych, mierzalnych kryteriów (np. gęstości defektów) podejmuje się decyzje, odpowiednio o dopuszczeniu dokumentu do inspekcji oraz o zamknięciu inspekcji połączonym z przekazaniem poprawionego produktu;

4 4 Aleksander Jarzębowicz, Janusz Górski Narzucenie ściślej określonej struktury procesu (np. kolejność studiowania dokumentów) oraz związanych z nią parametrów liczbowych (np. tempo studiowania wyrażone liczbą stron na godzinę studiowania); Zbieranie w każdym etapie metryk i wykorzystywanie ich do ciągłej optymalizacji zarówno procesów inspekcji, jak i procesów wytwórczych danej firmy. ZAKRES EKSPERYMENTU Planowanie Spotkanie inicjujące Analiza indywidualna Analiza grupowa Korekta Sprawdzenie korekty Zarządzanie Rys. 1. Ogólny schemat procesu przeglądu i inspekcji z zaznaczonym zakresem eksperymentu 3. Metoda UML-HAZOP Jednym ze sposobów opracowania nowej metody wykrywania anomalii jest skorzystanie z istniejących rozwiązań i ich adaptacja do rozpatrywanego obszaru problemowego. Do rozwiązań takich należy metoda HAZOP (ang. Hazard and Operability Study) [UKMD2000], oparta na idei inspekcji, stosowana pierwotnie w dziedzinie bezpieczeństwa (ang. safety) systemów. Jej celem jest wykrywanie szczególnego rodzaju anomalii prowadzących do sytuacji, w których system zagrozi swojemu środowisku. Metoda UML-HAZOP [GOJA2002] skupia się na innym typie anomalii defektach projektowych i stworzona została konkretnie z myślą o modelach UML. Wykorzystuje oryginalne podejście HAZOP, adaptując kluczowe mechanizmy tego podejścia: sposób tworzenia list kontrolnych oparty na słowach kluczowych i systematykę procesu analizy modelu.

5 Eksperymentalne porównanie inspekcji UML-HAZOP z przeglądem niestrukturalnym 5 Rys. 2. Metoda konstrukcji list kontrolnych UML-HAZOP Sama idea konstrukcji list kontrolnych jest prosta (patrz rys. 2.). Notacja UML zawiera szereg elementów przeznaczonych do wyrażania różnych aspektów modelowanego systemu np. klasy, przypadki użycia, asocjacje, generalizacje. Elementy charakteryzowane są przez zdefiniowane dla nich w UML atrybuty. Z użyciem tych elementów w modelowaniu wiążą się zwykle pewne typowe dla nich defekty. Do wygenerowania możliwie kompletnej listy defektów dla danego elementu, metoda wykorzystuje zestaw słów kluczowych HAZOP. Słowa kluczowe mają za zadanie w sposób ogólny sugerować wszelkie potencjalne błędy i odchylenia od prawidłowego stanu, np. NO oznacza kompletny brak czegoś, co powinno się znaleźć w modelu, OTHER THAN inny stan, odmienny od prawidłowego, PART OF prawidłowy stan jest osiągnięty jedynie częściowo, LESS zbyt niska wartość liczbowa w stosunku do prawidłowej itd. Zestawienie poszczególnych słów kluczowych z poszczególnymi atrybutami danego elementu daje sugestie defektów odnoszących się do tego elementu. Na przykładzie pokazanym na rysunku, wybranym elementem, dla którego poszukiwane są defekty jest asocjacja (ang. association). Asocjacja posiada szereg atrybutów takich jak nazwa, liczność każdego z jej końców, agregacja i kilka innych. Rysunek pokazuje przykładowe zestawienie atrybut-słowo kluczowe: odniesienie słowa kluczowego OTHER THAN do atrybutu aggregation daje w efekcie sugestię defektu polegającego na użyciu niewłaściwego typu agregacji. Nie wszystkie takie zestawienia dają sensowny rezultat, jednak te wartościowe, które po nadaniu odpowiedniej interpretacji sugerują defekty rzeczywiście często zdarzające się w modelach, zostają włączone do listy kontrolnej dotyczącej danego elementu UML. Zakres metody można określić jako te elementy, dla których opracowane zostały listy kontrolne. Z powodu pewnych uwarunkowań związanych z genezą oryginalnego HAZOPu, metoda UML-HAZOP obecnie koncentruje się na elementach mających charakter połączeń np. związkach w diagramach klas. Systematyka procesu analizy polega na tym, że w danym modelu będącym przedmiotem inspekcji, po kolei analizowane są wszystkie obecne w nim elementy, których dotyczy zakres metody. Do każdego z tych elementów stosowana jest odpowiednia dla jego typu lista kontrolna, a zadanie analityka polega na odnotowaniu, czy defekty sugerowane przez poszczególne pozycje listy rzeczywiście mają miejsce dla tego konkretnego elementu.

6 6 Aleksander Jarzębowicz, Janusz Górski Dotychczasowe prace nad metodą UML-HAZOP obejmowały opracowanie m.in.: metody budowy list kontrolnych, konkretnych list kontrolnych dla wybranych elementów, struktury procesu inspekcji oraz informatycznego systemu wspomagającego. System wspomagający pozwala na wczytanie modelu systemu stworzonego w narzędziu CASE i automatyczne wygenerowanie list kontrolnych dla tych jego elementów, które mieszczą się w zakresie metody. Udostępnia również funkcjonalność pozwalającą użytkownikowi prowadzącemu analizę modelu na zaznaczanie w uprzednio automatycznie wygenerowanych listach kontrolnych wykrytych przez niego defektów. System został opracowany jako narzędzie jest zorientowane na pracę grupową opiera się na architekturze klient-serwer i jest dostępny za pośrednictwem Internetu. Dokładny opis metody UML-HAZOP można znaleźć w [GOJA2002], zaś opis narzędzia wspomagającego metodę w [GJLM2003]. 4. Opis eksperymentu 4.1 Cel eksperymentu Najistotniejszym celem eksperymentu było porównanie inspekcji opartej na metodzie UML-HAZOP ze zwykłym przeglądem. Porównanie miało obejmować wybrane charakterystyki, takie jak skuteczność i wydajność, które z kolei miały zostać obliczone na podstawie danych liczbowych zebranych bezpośrednio z eksperymentu: czasu analizy oraz liczby i rodzaju wykrytych defektów. Poza samym porównaniem charakterystyk obu technik, spodziewano się uzyskać odpowiedzi na interesujące pytania: Czy brak sterowania uwagą uczestnika nie obniża skuteczności przeglądu? Czy formalizacja i listy kontrolne nadmiernie nie ograniczają uczestnika inspekcji? Czy potencjalnie większa dokładność inspekcji rekompensuje jej większy koszt? Drugi cel stanowiło zebranie subiektywnych ocen osób z grupy posługującej się metodą UML- HAZOP, dotyczących stopnia trudności nauki metody oraz jej przydatności w projekcie informatycznym. Podobnym ocenom (choć w mniejszym zakresie) miało zostać poddane narzędzie wspomagające metodę Przedmiot eksperymentu Realizacja sformułowanych powyżej celów wymagała praktycznego zastosowania obu porównywanych technik przeglądowych do określonej, uprzednio wybranej dokumentacji projektowej. Analizie poddano diagram klas UML. Wybór diagramu (i dodatkowej, związanej z nim dokumentacji) musiał uwzględniać następujące ograniczenia: rozmiar czas niezbędny do zapoznania z dokumentacją i jej analizy nie mógł przekraczać kilku godzin, co wynikało z zewnętrznych ograniczeń eksperymentu;

7 Eksperymentalne porównanie inspekcji UML-HAZOP z przeglądem niestrukturalnym 7 zrozumiałość dokumentacja dotycząca bardzo specyficznej, skomplikowanej dziedziny problemowej mogłaby być zbyt trudna do opanowania, co z kolei prowadziłoby do sytuacji, w której uczestnik szuka defektów w dokumentacji, której nie rozumie i, w konsekwencji, do bezsensownych wyników eksperymentu; poprawność podlegający analizie diagram klas mógł, a nawet powinien, zawierać defekty, jednak dokumentacja dodatkowa, stanowiąca punkt odniesienia nie mogła być sprzeczna, niekompletna lub obarczona innymi błędami. Wybrano system zrealizowany przez zespół studentów podczas projektów grupowych i przeznaczony do obsługi rozliczeń pomiędzy centralą telefoniczną a jej abonentami. Produkty tego projektu grupowego (zarówno działający system, jak i cała dokumentacja projektowa) były przeznaczone dla Podyplomowego Studium Inżynierii Oprogramowania prowadzonego na Politechnice Gdańskiej i służyły jako materiał szkoleniowy, ilustrujący kolejne etapy cyklu wytwarzania i powstające w nich artefakty. Edukacyjne przeznaczenie dokumentacji wymuszało na zespole projektowym jej staranne opracowanie. Te właściwości, w połączeniu ze stosunkowo niewielkim rozmiarem systemu, stanowiły argumenty przemawiające za decyzją o jego wyborze do wykorzystania w eksperymencie. Równie istotna jak pozyskanie odpowiedniej dokumentacji, była kwestia doboru uczestników eksperymentu. Ze względu na konieczność biegłej znajomości zagadnień modelowania obiektowego, w grę wchodzili jedynie studenci dwóch ostatnich lat. Wybrano grupę studentów V roku (15 osób) specjalności prowadzonej w Katedrze Inżynierii Oprogramowania Przebieg eksperymentu Eksperyment został przeprowadzony w październiku 2003 roku. W jego realizacji można wyróżnić kilka odrębnych etapów. Kolejność etapów oraz związane z nimi najważniejsze produkty i dane wejściowe przedstawiono na rys.3. Szczegółowe opisy poszczególnych etapów znajdują się w podrozdziałach

8 8 Aleksander Jarzębowicz, Janusz Górski Plan eksperymentu Dokumentacja źródłowa Materiały szkoleniowe PRZYGOTOWANIA SZKOLENIE STUDIOWANIE DOKUMENTACJI Dokumentacja projektowa Ankiety Dokumentacja do analizy PRZETWORZENIE I ANALIZA WYNIKÓW ANKIETOWANIE ANALIZA I REJESTRACJA DEFEKTÓW Rejestry defektów Pomiary czasu Rys.3. Przebieg eksperymentu Przygotowania Etap ten obejmował szeroki zakres czynności związanych ze szczegółowym planowaniem oraz z przygotowaniem zasobów takich jak: infrastruktura (pomieszczenia, sprzęt komputerowy, podstawowe oprogramowanie), narzędzia, dokumentacja. Dokumentacja udostępniana uczestnikom składała się z następujących części: Dokumentacja źródłowa służąca do zapoznania uczestników z kontekstem i wymaganiami wobec systemu będącego przedmiotem eksperymentu oraz stanowiąca punkt odniesienia pozwalający stwierdzić co jest defektem, a co nie; Dokumentacja do analizy diagram klas (wraz z opisem), w którym uczestnicy mieli poszukiwać defektów. Jako podstawa dokumentacji źródłowej przyjęta została specyfikacja wymagań systemowych. Był to dokument liczący 52 strony, napisany w języku angielskim. Cała specyfikacja, z uwagi na dużą objętość nie nadawała się do bezpośredniego zastosowania w eksperymencie, dlatego też sporządzono jej skróconą wersję. Z oryginalnej specyfikacji usunięto część zawartości (testy akceptacyjne, wymagania dot. procesu wytwórczego, dodatki) dbając jednocześnie o zapewnienie spójności pozostawionych informacji. W rezultacie tych zabiegów zredukowano objętość dokumentu do 21 stron. Dokumentację przeznaczoną do analizy stanowił diagram klas UML, będący produktem fazy analizy projektu wytwórczego. Najpierw diagram ten poddano pewnym nieznacznym modyfikacjom, nie zmieniającym jednak istotnych właściwości modelu (usunięcie klas kontenerowych). Następnie przeprowadzona została jego analiza pod kątem obecnych defektów. Ponieważ podstawowym

9 Eksperymentalne porównanie inspekcji UML-HAZOP z przeglądem niestrukturalnym 9 obiektem badań eksperymentu były defekty z zakresu wykrywalności metody UML-HAZOP, przeprowadzono kompletną inspekcję z wykorzystaniem tej metody. Dodatkowo sprawdzono defekty spoza zakresu metody i zarejestrowano wykryte. Niestety, sprawdzenie to miało dość pobieżny charakter; nie przeprowadzono kompletnego przeglądu, co jak się potem okazało miało duże znaczenie dla wyników eksperymentu. Następnie wykonano zasiewanie defektów do już obecnych w diagramie defektów dodano nowe; część mieszczącą się w zakresie UML-HAZOP, część spoza zakresu. Ostatecznie dokumentacja do analizy liczyła 16 stron i składała się z samego diagramu oraz opisu występujących w nim klas (raport wygenerowany przez narzędzie Select Enterprise). Sam diagram liczył 16 klas i 16 związków Szkolenie Szkolenie zostało przeprowadzone na tydzień przed główną częścią eksperymentu i składało się z trzech części. Podczas pierwszej części, wspólnej dla wszystkich, przedstawiono podstawowe informacje dotyczące przeglądów i inspekcji oraz poinformowano uczestników o celach eksperymentu, jego planie i poczynionych założeniach (np. praca indywidualna, bez wymiany informacji). Ponadto, uczestnicy zostali podzieleni na dwie grupy: przeglądu (8 osób) i inspekcji (7 osób). Podział ten przeprowadzono z myślą o równomiernym rozkładzie sił i kompetencji w obu grupach. Kierowano się przy nim, z braku lepszego obiektywnego kryterium, średnią ocen uzyskiwanych przez studentów podczas wcześniejszych lat studiów. Dalsze szkolenia przebiegały już oddzielnie w poszczególnych grupach. W grupie inspekcji przedstawiono ideę i podstawowe mechanizmy metody UML-HAZOP, a także konkretne listy kontrolne (z których mieli korzystać podczas eksperymentu). Uczestnicy przeszli również krótkie przeszkolenie dotyczące korzystania z narzędzia wspomagającego metodę. Przekazane informacje zostały zaraz potem wykorzystane praktycznie: przeprowadzono inspekcję niewielkiego przykładowego diagramu z użyciem narzędzia wspomagającego (początkowo wspólnie całą grupą, następnie zaś każdy z uczestników dokończył ją na własnym komputerze). Całe szkolenie zajęło w sumie ok. 45 min. W grupie przeglądu szkolenie było znacznie krótsze (15 min.). Zadanie tych uczestników miało polegać (jak zostali poinformowani) na wyszukiwaniu wszelkich możliwych defektów obecnych na diagramie, bez narzuconej systematyki procesu ani określonych kategorii defektów, których należy poszukiwać. Z uwagi na niewielkie doświadczenie uczestników w stosowaniu technik przeglądowych przedstawiono im jednak dla ułatwienia różne rodzaje defektów jakie mogą występować w diagramach klas i na jakie warto zwrócić uwagę. Nie miało to jednak charakteru obligatoryjnych reguł Studiowanie dokumentacji Studiowanie dokumentacji źródłowej (wspomnianej już skróconej specyfikacji wymagań) zostało wprowadzone jako odrębny etap z dwóch powodów. Po pierwsze, aby zagwarantować, że przeglądy i inspekcje zostaną wykonane w sposób kompletny. Bez wyróżnienia tego etapu, uczestnicy mogliby źle podzielić swój czas i za bardzo skupić się na studiowaniu, tym samym zbyt późno rozpoczynając rejestrację defektów. W efekcie przegląd lub inspekcja została by wykonana jedynie częściowo. Drugim powodem była chęć precyzyjniejszego pomiaru czasu potrzebnego każdej z grup na samą czynność analizy i rejestracji defektów.

10 10 Aleksander Jarzębowicz, Janusz Górski Każdy z uczestników otrzymał kopię dokumentacji źródłowej w postaci papierowej. Możliwe było zaznaczanie wybranych fragmentów, nanoszenie notatek itp. Praca odbywała się w trybie indywidualnym, bez konsultacji pomiędzy uczestnikami. Czas potrzebny na przestudiowanie dokumentacji oszacowany został uprzednio na 2 godziny, co okazało się nadmiarowe. Po 100 min., gdy wszyscy zadeklarowali, że zaznajomili się z dokumentacją w wystarczającym stopniu, etap studiowania został zamknięty Analiza i rejestracja defektów Etap ten odbył się bezpośrednio po etapie studiowania, nie licząc krótkiej przerwy. Uczestnicy dopiero teraz otrzymali dokumentację do analizy (nadal mieli również do dyspozycji dokumentację źródłową). Ich zadanie polegało na wykryciu i zarejestrowaniu defektów obecnych w diagramie (nie poszukiwano defektów w opisie diagramu). Grupa przeglądów mogła analizować diagram w sposób dowolny, bez jakiejkolwiek narzuconej formalizacji. Wykryte defekty odnotowywane były przez uczestników w plikach Worda z gotowymi do wypełnienia tabelami o następujących polach: Nr defektu - automatyczna numeracja, nie wypełniana przez użytkowników; Miejsce występowania element diagramu, którego dotyczy defekt (konkretna klasa, związek itp.), o ile możliwe jest wyszczególnienie pojedynczego elementu; Klasyfikacja znaczenie defektu w opinii uczestnika: poważny lub drugorzędny; Opis defektu wyjaśnienie, na czym polega znaleziony defekt. Grupa inspekcji korzystała z narzędzia wspomagającego UML-HAZOP, wypełniając wygenerowane przez narzędzie listy kontrolne. Oprócz opisu defektu zaznaczana była również jego klasyfikacja (poważny, drugorzędny). Uczestnicy mieli wyraźnie powiedziane, że należy skupić się na defektach sugerowanych przez listy kontrolne. Mogli jednak rejestrować dostrzeżone defekty spoza zakresu (w plikach z tabelami). Etap ten miał wyznaczoną górną granicę czasu, taką samą dla obu grup i wynoszącą 140 min. Uczestnicy mieli jednak możliwość wcześniejszego zakończenia analizy: w grupie inspekcji, gdy wypełnione zostaną wszystkie listy kontrolne, w grupie przeglądów, w momencie gdy od 15 min. nie znaleziono żadnego nowego defektu (i przeanalizowano cały diagram). Rzeczywisty czas analizy każdego z uczestników został zarejestrowany Ankietowanie Etap ankietowania miał miejsce tydzień po analizie i rejestracji defektów. Uczestnicy otrzymali do wypełnienia krótkie, anonimowe ankiety. Ankiety dla dwóch grup częściowo się różniły. Większość pytań miała odpowiedzi do wyboru (5 możliwości), w niektórych należało udzielić odpowiedzi opisowej. Pytania można podzielić na kilka kategorii: Pytania o organizację eksperymentu (obie grupy) miały na celu ustalenie, czy nie popełniono błędów mogących wpłynąć na wynik eksperymentu; Pytania o listy kontrolne (obie grupy) badały opinię użytkowników na temat list kontrolnych: czy są pomocne, czy też nadmiernie ograniczające;

11 Eksperymentalne porównanie inspekcji UML-HAZOP z przeglądem niestrukturalnym 11 Pytania o metodę UML-HAZOP (tylko grupa inspekcji); Pytania o narzędzie wspomagające UML-HAZOP (tylko grupa inspekcji); Ankieta przeznaczona dla grupy inspekcji zawierała łącznie 12 pytań, zaś ankieta dla grupy przeglądu 7 pytań Przetworzenie i analiza wyników Wyniki uzyskane bezpośrednio z eksperymentu obejmowały: zarejestrowane defekty (wraz z klasyfikacją znaczenia każdego z nich), czas analizy każdego uczestnika oraz opinie zebrane w ankietach. Ich przetworzenie i analiza obejmowały następujące kroki: weryfikacja zasadności defektów zarejestrowanych przez uczestników; zebranie wyników każdego uczestnika w formie nadającej się do analizy i wygenerowanie dla nich statystyk (wartości średnie, odchylenia standardowe); obliczenie i porównanie opartych na danych charakterystyk; zbadanie, jak klasyfikowane były poszczególne rodzaje defektów; analiza wyników ankiet; 5. Wyniki Zanim przedstawione zostaną uzyskane wyniki, warto najpierw omówić kwestię defektów obecnych w analizowanym diagramie. Ich całkowita liczba oraz podział z uwagi na trzy kryteria (pochodzenie, wykrywalność przez UML-HAZOP, wiedza o ich istnieniu przed eksperymentem) zostały ukazane na rys. 4. Szczególnego omówienia wymaga podział ze względu na kryterium trzecie. Podczas stanowiącej pierwszy krok przetwarzania wyników weryfikacji zarejestrowanych defektów okazało się, że w diagramie znajduje się znacznie więcej defektów niż wiadome to było organizatorom eksperymentu. Ten brak wiedzy wynikał ze wspomnianego już faktu, że skupiono się przede wszystkim na defektach z zakresu wykrywalności UML-HAZOP i nie przeprowadzono kompletnej analizy dla defektów spoza tego zakresu. Defekty te mogły jednak być (i były) wykrywane przez uczestników z grupy przeglądu. Organizatorzy spodziewali się, że uczestnicy mogą wykryć nieznane wcześniej defekty, lecz ich liczba przekroczyła wcześniejsze oczekiwania. Wyniki eksperymentu dotyczące liczby wykrytych defektów oraz zmierzonego czasu analizy zawarte zostały w tabeli 1. Otrzymane wyniki stanowiły spore zaskoczenie. Po pierwsze, wbrew przewidywaniom przegląd zaowocował wykryciem większej liczby defektów niż miało to miejsce w przypadku inspekcji. Po drugie, czas analizy był znacznie dłuższy dla przeglądów, podczas gdy wydawać by się mogło, że inspekcja ze swoją formalizacją procesu powinna być bardziej czasochłonna.

12 12 Aleksander Jarzębowicz, Janusz Górski Defekty obecne: 57 Defekty znane: 37 Wszystkie defekty: 72 Defekty zasiane: 15 Defekty nieznane: 35 Defekty z zakresu UML-HAZOP: 26 Defekty spoza zakresu UML-HAZOP: 46 Rys.4. Klasyfikacja defektów zawartych w analizowanym diagramie. Tabela 1. Wyniki eksperymentu Wartość średnia Przegląd Odchyl. standard. Wartość średnia Inspekcja Odchyl. standard. Liczba zarejestrowanych defektów 27,8 12,0 20,4 9,4 Liczba potwierdzonych defektów 20,9 10,0 13,0 8,6 Liczba potwierdzonych defektów z zakresu UML-HAZOP 6,1 3,5 11,6 6,7 Czas analizy i rejestracji (w min.) 132,9 3,5 97,9 16,8 Wyjaśnienie tych zaskakujących rezultatów wymaga bliższego przyjrzenia się realiom eksperymentu. Uczestnicy inspekcji koncentrowali się zgodnie z poleceniem na defektach wskazywanych przez listy kontrolne. Listy te pokrywały swoim zakresem jedynie część klas defektów (te dotyczące połączeń), stąd uczestnicy ci po prostu nie mieli możliwości znalezienia defektów spoza zakresu, których jak się okazało było w modelu znacznie więcej. Relatywnie krótki czas analizy wynikał zaś z zasugerowanej zasady kończenia inspekcji po wypełnieniu wszystkich list kontrolnych. Grupa przeglądu miała natomiast wolną rękę zarówno w kwestii rodzaju poszukiwanych defektów, jak również chwili zakończenia analizy. Uczestnicy z tej grupy potraktowali postawione przed nimi zadanie bardzo ambitnie; wykorzystali niemal cały dany im do dyspozycji czas i (jak zaobserwowali nadzorujący eksperyment) przepracowali go bardzo intensywnie. Mając w przydzielonym diagramie bardzo wiele możliwych do znalezienia defektów, uzyskali dobre rezultaty. Dla defektów z zakresu UML-HAZOP uzyskiwali jednak znacznie słabsze wyniki niż ich koledzy (trzeci wiersz tabeli 1). Tabela 1 pokazuje również różnicę pomiędzy liczbą wszystkich zgłoszeń defektów przez uczestników a liczbą tych, które podczas weryfikacji potwierdzono jako zasadne. Jak widać, uczestnicy często sygnalizowali obecność defektów, tam gdzie w rzeczywistości ich nie było (wiersze 1 i 2).

13 Eksperymentalne porównanie inspekcji UML-HAZOP z przeglądem niestrukturalnym 13 Zebrane dane (liczba defektów, czas) posłużyły jako podstawa do obliczenia dwóch następujących charakterystyk obu technik przeglądowych: Skuteczność iloraz liczby defektów znalezionych i liczby wszystkich defektów, Wydajność iloraz liczby znalezionych defektów do czasu analizy. 0,6 0,5 0,4 0,3 Skuteczność 0,2 0,1 0 Przegląd Inspekcja (w stos. do wszystkich defektów) Inspekcja (w stos. do defektów z zakresu) Rys. 5. Porównanie skuteczności przeglądu i inspekcji Przegląd Przegląd (defekty z zakresu UML- HAZOP) Inspekcja Wydajność (defekt/godz.) Rys. 6. Porównanie wydajności przeglądu i inspekcji Dla obliczenia skuteczności inspekcji UML-HAZOP należy poczynić pewne dodatkowe założenie: co jest rozumiane przez liczbę wszystkich defektów? Można ją rozumieć w kontekście albo jedynie defektów z zakresu tej metody, albo też wszystkich defektów obecnych w diagramie. W pierwszym przypadku byłaby to liczba 26, w drugim 72 (patrz rys.4). Dla przeglądu, który nie ma ograniczenia zakresu, nie ma wątpliwości, że należy tu przyjąć liczbę 72. Z kolei dla wydajności uwzględniono dodatkowo wydajność przeglądu dla defektów mieszczących się w zakresie UML- HAZOP (za podstawę obliczeń przyjęto część czasu analizy proporcjonalną do udziału defektów z zakresu wśród wszystkich defektów modelu). Zbiorcze charakterystyki (uśrednione dla wszystkich uczestników) przedstawiono na rysunkach 5 i 6. Warto zauważyć, że zarejestrowana (w kategoriach bezwzględnych) skuteczność obu technik jest stosunkowo niska przeciętny uczestnik przeglądu znalazł mniej niż 1/3 defektów, a uczestnik inspekcji połowę. W kwestii wydajności korzystniej wypadł przegląd; dłuższy czas analizy został w jego przypadku odpowiednio zrównoważony przez większą liczbę wykrytych defektów.

14 14 Aleksander Jarzębowicz, Janusz Górski Dla inspekcji przeprowadzona została dodatkowo analiza jakościowa, mająca na celu ustalenie, na ile jej rezultaty wynikają z samych właściwości metody, na ile zaś są zależne od kompetencji i spostrzegawczości inspektorów. Dla szczegółowo zdefiniowanej metody inspekcji pożądane byłoby uniezależnienie jej w jak największym stopniu od indywidualnych cech osób, które jej używają. Eksperyment pokazał jednak że metoda nie posiada takiej niezależności. Część defektów w ogóle nie została wykryta przez żadnego z uczestników. W niektórych przypadkach występowały dodatkowe problemy: uczestnicy identyfikowali element diagramu, w którym obecny był defekt, ale nie do końca poprawnie go wskazywali lub proponowane poprawki nie rozwiązywały do końca problemu, bądź też defekt był zgłaszany przy innym punkcie listy kontrolnej niż powinien. Prowadzona przez uczestników klasyfikacja defektów pod względem ich znaczenia pozwoliła na wyciągnięcie ogólniejszych wniosków co do tego, jakie klasy defektów uznawane są za posiadające największe znaczenie. Oczywiście, decyzje co do klasyfikacji były zróżnicowane w zależności od przekonań danego uczestnika, a także od charakteru i miejsca występowania każdego konkretnego defektu. Możliwe było jednak dostrzeżenie pewnych prawidłowości i podział klas defektów na 4 grupy (rys. 7). - brakujące klasy - brakujące związki - błędne związki - błędne liczności związków - brakujące atrybuty - brakujące operacje - błędne atrybuty - błędne operacje - błędne agregacje - nieadekwatne nazwy POWAŻNE DRUGORZĘDNE Rys. 7. Klasyfikacja klas defektów wg znaczenia (na podstawie opinii uczestników). Dodatkowe źródło informacji do przeanalizowania stanowiły ankiety wypełnione przez uczestników eksperymentu. Pierwsza grupa pytań dotyczyła organizacji eksperymentu (np. czy czas poszczególnych etapów nie był zbyt krótki, czy dokumentacja źródłowa była wystarczająca do zrozumienia kontekstu systemu, czy szkolenie było wystarczające). Odpowiedzi uczestników były w tym zakresie pozytywne tzn. nie stwierdzili oni występowania niedociągnięć organizacyjnych, które utrudniłyby im wykonanie zadań. Wśród celów eksperymentu znalazła się chęć uzyskania odpowiedzi na pytania, czy formalizacja procesu poszukiwania defektów np. poprzez listy kontrolne jest korzystna z punktu widzenia uczestników. W związku z tym ankietowani zostali poproszeni o opinię również w tej sprawie. Rezultaty przedstawiono na rys. 8. (lewa połowa rysunku pokazuje pytanie i rozkład odpowiedzi dla grupy przeglądów, prawa dla grupy inspekcji). Uczestnicy z grupy przeglądu mieli w ankiecie możliwość wpisania, jakie środki sterowania uwagą uznają za najbardziej przydatne. Większość z nich wymieniła listy kontrolne. W ankietach grupy inspekcji znajdowała się dodatkowa grupa pytań dotycząca metody UML- HAZOP i wspomagającego ją narzędzia. Odpowiedzi na dwa spośród tych pytań zostały zamieszczone na rys. 9. Uczestnicy mogli dodatkowo wpisywać propozycje modyfikacji zarówno metody jak i narzędzia. Niektóre uwagi dotyczące narzędzia okazały się przydatne i zostaną uwzględnione przy jego rozbudowie.

15 Eksperymentalne porównanie inspekcji UML-HAZOP z przeglądem niestrukturalnym 15 Czy w Twoim odczuciu przegląd byłby skuteczniejszy gdyby sterowano uwagą uczestników (np. poprzez listy kontrolne, narzuconą systematykę procesu przeglądu)? Czy w Twoim odczuciu wykorzystanie list kontrolnych stanowi nadmierne ograniczenie dla uczestnika inspekcji? zdecydow anie tak raczej tak trudno pow iedzieć raczej nie zdecydow anie tak trudno pow iedzieć raczej nie zdecydow anie nie Rys. 8. Opinie ankietowanych na temat list kontrolnych. Jak oceniasz stopień trudności opanowania (nauki) metody UML-HAZOP? Jak oceniasz przydatność metody do wykrywania defektów w modelach obiektowych? raczej w ysoki średni raczej duża średnia raczej niski raczej mała Rys.9. Opinie ankietowanych na temat metody UML-HAZOP. 6. Wnioski W kategoriach bezwzględnych (ogólna liczba wykrytych defektów) porównanie dwóch technik wypadło na korzyść przeglądu, co wynikało w znacznej mierze z warunków eksperymentu, a w szczególności z rozkładu defektów w analizowanym diagramie, których większość znajdowała się poza zakresem metody UML-HAZOP. Natomiast w swoim zakresie inspekcja UML-HAZOP uzyskała znacznie lepszą skuteczność przy wydajności bardzo zbliżonej do wydajności przeglądu. Takie rezultaty, zwłaszcza w zestawieniu z faktem, jak klasyfikowane były przez uczestników różne rodzaje defektów, sugerują potrzebę pilnego rozszerzenia zakresu metody, tak aby uwzględniała ona również inne klasy poważnych defektów modeli. Wyniki dotyczące nauki i stosowania samej metody UML-HAZOP wskazały na pewne trudności w posługiwaniu się metodą przez niedoświadczonych użytkowników. Mimo, że uczestnicy inspekcji uznali szkolenie poświęcone tej metodzie za wystarczające, to w świetle opinii na temat trudności jej

16 16 Aleksander Jarzębowicz, Janusz Górski nauki oraz zaobserwowanych problemów w prawidłowej identyfikacji defektów, pożądane wydaje się opracowanie bardziej wyczerpujących procedur szkoleniowych oraz bardziej komunikatywne sformułowanie sugestii defektów w listach kontrolnych. W przyszłości planowane jest przeprowadzenie kolejnych eksperymentów pozwalających porównać opracowywaną metodę z innymi technikami przeglądowymi (np. z konkretnymi metodami inspekcji modeli obiektowych), bądź też oszacować w jaki sposób zmiany list kontrolnych i struktury procesu metody wpływają na jej skuteczność i wydajność. Szczególnie interesujący do zbadania wydaje się również problem skali: jak wypadnie analogiczne porównanie dla znacznie większego modelu, trudniejszego do pełnego opanowania przez analityka. Podziękowania: Autorzy pragną podziękować Januszowi Czai, Rafałowi Leszczynie, Jakubowi Milerowi i Marcinowi Olszewskiemu za pomoc w przygotowaniu i nadzorowaniu eksperymentu oraz studentom V roku informatyki, specjalności Inżynieria Systemów i Bazy Danych za uczestnictwo w eksperymencie. Bibliografia [FAGA1976] Fagan, M., Design and Code Inspections to Reduce Errors in Program Development, IBM Systems Journal 8, [FRWE1990] Freeedman D., Weinberg G., Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products (Third Edition), Dorset House, [GIGR1993] Gilb T., Graham D., Software Inspections, Addison-Wesley, [GJLM2003] Górski J., Jarzębowicz A., Leszczyna R., Miler J., Olszewski M., Tool support for detecting defects in object-oriented models, Proc. of 10 th International Multi-Conference on Advanced Computer Systems, X 2003, Międzyzdroje. [GOJA2002] Górski J., Jarzębowicz A., Wykrywanie anomalii w modelach obiektowych za pomocą metody UML-HAZOP, IV Krajowa Konferencja Inżynierii Oprogramowania, X [UKMD2000] UK Ministry of Defence, Defence Standard 00-58, HAZOP Studies on Systems Containing Programmable Electronics (Part 1&2), Issue 2, [WGJN2002] Wojciechowski A., Gawron L., Jagielski M., Nawrocki J., Eksperymentalna ocena dwóch podejść do przeglądu artefaktów programowych. IV Krajowa Konferencja Inżynierii Oprogramowania, X 2002.

17

18 Wersja postprint artykułu opublikowanego na VI Krajowej Konferencji Inżynierii Oprogramowania. KKIO'2004, Gdańsk, 5-8 października 2004, Wydawnictwo WNT, str