(2004). Eksperymentalne porównanie inspekcji UML

Transkrypt

Wersja postprint artykułu opublikowanego na VI Krajowej Konferencji Inżynierii Oprogramowania.
KKIO'2004, Gdańsk, 5-8 października 2004, Wydawnictwo WNT, str. 269-284.
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
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 UMLHAZOP 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.
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
•
•
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
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
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ą UMLHAZOP, 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ę.
4.2. 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
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.
4.3. 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 4.3.1 - 4.3.6.
8
Dokumentacja
źródłowa
Plan
eksperymentu
Materiały
szkoleniowe
PRZYGOTOWANIA
Dokumentacja
projektowa
Ankiety
PRZETWORZENIE
I ANALIZA
WYNIKÓW
SZKOLENIE
STUDIOWANIE
DOKUMENTACJI
Dokumentacja
do analizy
ANKIETOWANIE
ANALIZA I
REJESTRACJA
DEFEKTÓW
Rejestry
defektów
Pomiary czasu
Rys.3. Przebieg eksperymentu
4.3.1. 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
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.
4.3.2. 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ł.
4.3.3. 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
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.
4.3.4. 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.
4.3.5. 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
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ń.
4.3.6. 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
Defekty obecne:
Defekty znane:
57
37
Wszystkie defekty:
72
Defekty zasiane:
Defekty nieznane:
15
35
Defekty z zakresu
UML-HAZOP:
Defekty spoza zakresu
UML-HAZOP:
26
46
Rys.4. Klasyfikacja defektów zawartych w analizowanym diagramie.
Tabela 1. Wyniki eksperymentu
Przegląd
Inspekcja
Wartość
średnia
Odchyl.
standard.
Wartość
średnia
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
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
Skuteczność
0,3
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
10
9
8
7
6
5
4
3
2
1
0
Wydajność
(defekt/godz.)
Przegląd
Przegląd (defekty z
zakresu UMLHAZOP)
Inspekcja
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 UMLHAZOP (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
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
POWAŻNE
- błędne liczności
- błędne atrybuty
związków
- błędne operacje
- brakujące atrybuty - błędne agregacje
- brakujące operacje
- nieadekwatne
nazwy
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 UMLHAZOP 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.
Czy w Twoim odczuciu przegląd byłby
skuteczniejszy gdyby sterowano uwagą
uczestników (np. poprzez listy kontrolne,
narzuconą system atykę procesu przeglądu)?
15
Czy w Twoim odczuciu wykorzystanie list
kontrolnych stanowi nadm ierne ograniczenie dla
uczestnika inspekcji?
z decy dow anie
tak
z decy dow anie
tak
rac z ej tak
trudno
pow iedz ieć
trudno
pow iedz ieć
rac z ej nie
rac z ej nie
z decy dow 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
raczej
duża
średni
ś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
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]
[FRWE1990]
[GIGR1993]
[GJLM2003]
[GOJA2002]
[UKMD2000]
[WGJN2002]
Fagan, M., Design and Code Inspections to Reduce Errors in Program Development, IBM
Systems Journal 8, 1976.
Freeedman D., Weinberg G., Handbook of Walkthroughs, Inspections, and Technical
Reviews: Evaluating Programs, Projects, and Products (Third Edition), Dorset House, 1990.
Gilb T., Graham D., Software Inspections, Addison-Wesley, 1993.
Górski J., Jarzębowicz A., Leszczyna R., Miler J., Olszewski M., Tool support for detecting
defects in object-oriented models, Proc. of 10th International Multi-Conference on Advanced
Computer Systems, 22-24 X 2003, Międzyzdroje.
Górski J., Jarzębowicz A., Wykrywanie anomalii w modelach obiektowych za pomocą metody
UML-HAZOP, IV Krajowa Konferencja Inżynierii Oprogramowania, 16-18 X 2002.
UK Ministry of Defence, Defence Standard 00-58, HAZOP Studies on Systems Containing
Programmable Electronics (Part 1&2), Issue 2, 2000.
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, 16-18 X 2002.
Wersja postprint artykułu opublikowanego na VI Krajowej Konferencji Inżynierii
Oprogramowania. KKIO'2004, Gdańsk, 5-8 października 2004, Wydawnictwo WNT, str. 269-284.

(2004). Eksperymentalne porównanie inspekcji UML

Transkrypt

Podobne dokumenty

Pobierz - Sea-Line

Dermatologia II - kosmetyka.edu.pl

Wady lakiernicze: Jak ich uniknąć (I dlaczego jest to tak ważne)

1. List poparcia

Plakat - Wydział Chemii

Mini kamera do inspekcji Midi ISP 2 Kamera do - APG

Struktura krystaliczna metali Zagadnienia

Chemia ciała stałego