Walidacja konstrukcji

Na etapie przygotowywania danych do eksperymentu trzeba było rozwiązać problem odtworzenia powiązania pomiędzy defektami a klasami. Do tego celu wykorzystywano informacje pochodzące z systemów śledzenia defektów oraz z systemów kontroli wersji, co jest powszechnie przyjętą praktyką [26], [42], [120]. Jak jednak również powszechnie wiadomo [26], [35], [112], [120] podejście takie wiąże się z pewnymi problemami. Najpierw należy w systemie śledzenia defektów odróżnić te zgłoszenia, które reprezentują defekty od tych, które są powiązane z opracowywaniem nowych funkcjonalności. To czasami może być trudnym zadaniem i może stać się źródłem pomyłek [112]. Następnie defekty te są łączone z klasami na podstawie komentarzy z systemu kontroli wersji. Wykonanie tego manualnie dla dużych projektów nie jest możliwe, natomiast wykonanie tego automatycznie wiąże się z możliwo-ścią wystąpienia błędów [35]. Tu posłużono się metodą zautomatyzowaną, mianowicie wykorzystano opracowany do tego celu programem BugInfo. Program ten został szczegółowo opisany w Rozdziale 3.4.

Reguły określające co należy interpretować jako defekt mogą się różnić pomiędzy projektami. Antoniol i in. [1] pokazali, analizując projekty Eclipse, JBoss oraz Mozilla, że znaczna część zgło-szeń z systemu śledzenia defektów nie reprezentuje defektów. Kompletna eliminacja tych zgłozgło-szeń z danych wykorzystanych w opisanym w tym rozdziale eksperymencie nie była możliwa z uwagi na zbyt dużą liczbę analizowanych projektów. Ograniczono się jedynie do automatycznej eliminacji tych zgłoszeń, które były w systemie śledzenia defektów zaklasyfikowane do jednej z kategorii używanych zazwyczaj do obsługi zgłoszeń nie związanych z defektami. Działanie takie nie gwarantuje niestety wyeliminowania wszystkich zgłoszeń nie będących defektami.

Istotny problem sprawiają również klasy anonimowe i wewnętrzne. Język programowania Java wymaga aby klasy takie były definiowane w tym samym pliku co klasa zewnętrzna. Z drugiej nato-miast strony systemy kontroli wersji (SubVersion, CVS ) działają na poziomie pliku. Trudno zatem rozstrzygnąć czy defekt odnotowany w logach systemu kontroli wersji pochodzi z klasy wewnętrznej czy zewnętrznej. Problemy te spowodowały, że zaleca się ignorowanie tych klas [1], [16], [17]. Istotność tego problemu jest bardzo łatwa do oszacowania, ponieważ liczba klas anonimowych i wewnętrznych jest możliwa do wyliczenia. W danych wykorzystanych do opisanego w tym rozdziale eksperymentu klasy te stanowiły 8, 84% wszystkich klas.

Źródłem podobnych problemów są operacje takie jak zmiana nazwy klasy oraz przeniesienie klasy pomiędzy pakietami. Operacje te powodują przerwanie historii klasy i tym samym uniemożliwiają zidentyfikowanie powiązania pomiędzy stanem klasy przed i po operacji. W efekcie powoduje to, że po

4.4. PODSUMOWANIE 67

takiej operacji klasa jest interpretowana jako nowa, co ma negatywny wpływ zarówno na poprawność identyfikowania powiązań takiej klasy z defektami jak i na związane z nią metryki procesu.

Defekty były przypisywane do zgłoszeń na podstawie daty naprawienia zgłoszenia. Rozwiąza-nie takie było podyktowane czynnikami natury technicznej. Niezbędny do zidentyfikowania defektu komentarz z systemu śledzenia defektów jest wprowadzany dopiero w chwili zatwierdzania zmian rozwiązujących problem. Zdecydowanie ciekawszy byłby eksperyment, w którym udałoby się defekty łączyć z tymi wydaniami projektów, w których defekty te były wprowadzane.

W opisanym w tym rozdziale eksperymencie stosowano jedną konkretną metodę konstrukcji modeli predykcji defektów, mianowicie postępującą regresję liniową. W związku z tym trudno zawyrokować na ile wyniki tu uzyskane mają zastosowanie do eksperymentów, w których stosuje się inne meto-dy konstrukcji modeli. Z drugiej jednak strony zastosowana metoda jest najmniej skomplikowana pod względem struktury uzyskiwanego modelu. Jeżeli więc możliwe jest generalizowanie wyników uzyskanych dla jednej metody na pozostałe, to zdecydowanie większe szanse na powodzenie ma gene-ralizacja wychodząca od metod prostych (takich jak tu zastosowana postępująca regresja liniowa) niż od skomplikowanych (np. sieci neuronowe, regresja logistyczna). Wydaje się zatem, że dobór metody konstrukcji modelu predykcji defektów był optymalny pod kątem możliwości uogólniania uzyska-nych wyników. Niemniej rozstrzygnięcie kwestii możliwości generalizowania wyników na inne metody wymaga replikacji eksperymentu z wykorzystaniem innej metody konstruowania modelu predykcji defektów.

4.4 Podsumowanie

Tabela 4.28: Ocena metryk

Metryka Metoda I Metoda II Number of Revisions (NR) – –

Number of Distinct Commiters (NDC) ր –

Number of Modified Lines (NML) ր –

Is New (IN) nie ma zastosowania ց

Number of Defects in Previous Version (NDPV) – –

Number of Evening Revisions (NER) ր? ?

Number of Pre–code–freeze Revisions (NPR) ? ?

Weighted Methods per Class (WMC) nie ma zastosowania –

Lines of Code (LOC) nie ma zastosowania ր

Kombinacja czterech metryk procesu – nie ma zastosowania ’ր’ – istotna statystycznie poprawa predykcji;

’ց’ – pogorszenie predykcji; ’–’ – różnica nie była istotna statystycznie;

’ ?’ – zbyt mała próbka by uzyskać wyniki istotne statystycznie.

Przeanalizowano wpływ dziewięciu różnych czynników na dokładność predykcji dostarczanej przez modele predykcji defektów. Siedem z przeanalizowanych czynników to metryki procesu. Tylko dwa spośród wszystkich analizowanych czynników były analizowane dla tak małej liczby projektów pro-gramistycznych, że utrudniało to analizę statystyczną uzyskanych wyników. Analizowano dwie różne metody wprowadzania metryki do modelu. Podsumowanie uzyskanych wyników umieszczono w Tabeli 4.28.

68 ROZDZIAŁ 4. CZYNNIKI WPŁYWAJĄCE NA DOKŁADNOŚĆ PREDYKCJI DEFEKTÓW

Wprowadzenie do modelu metryk NDC, NML (obu metodą I) oraz LOC (metodą II) dało w efek-cie statystycznie istotną poprawę dokładności predykcji. Dla modeli, w których wprowadzenie którejś z powyższych metryk dało poprawę, wyliczono również siłę efektu. Zgodnie ze wzorcem zapropono-wanym przez Kampenensa [56] uzyskano słaby efekt dla modeli wykorzystujących metryki NML oraz

LOC. Natomiast dla modeli wykorzystujących metrykę NDC średni efekt. W świetle powyższych

wyników nie ma większych wątpliwości co do użyteczności metryki NDC wprowadzanej metodą I. Jej wartość potwierdzają zarówno testy statystyczne jak i siła efektu. W przypadku metryk NML,

LOC wyniki nie są już tak jednoznaczne. Uzyskano słaby efekt, ale mimo tego wyniki były istotne

statystycznie na poziomie α = 0, 05. W związku z tym użyteczność tych metryk jest trudna do za-negowania i w sytuacji, w której metryka NDC nie jest dostępna, warto skorzystać z którejś z tych dwóch metryk.

Dla metryk NR, NDPV, NER, NPR oraz WMC nie uzyskano wyników istotnych statystycznie. Jedynie w przypadku metryk NER oraz NPR fakt ten można tłumaczyć małym rozmiarem prób-ki. W przypadku pozostałych metryk próbka była stosunkowo duża, a brak istotnych statystycznie wyników jest efektem małej zmiany dokładności predykcji. Spośród tych metryk najlepsze wyniki uzyskiwano dla metryki NR. Średnia różnica w ocenie modeli wykorzystujących tą metrykę i modeli referencyjnych wyniosła 5, 05%, a w przypadku mediany aż 8, 99%. Prawdopodobieństwo testowe, przy weryfikacji hipotezy dotyczącej użyteczności metryki NR, wyniosło p = 0, 075, co jest wartością bliską zastosowanemu poziomowi istotności. Można więc, z pewną dozą ostrożności, zarekomendować metrykę NR, przynajmniej w takich sytuacjach, gdy żadna z dających lepsze wyniki metryk nie jest dostępna.

Metryki NER oraz NPR były analizowane w zaledwie kilku wydaniach projektu. W związku z tym nie było wystarczających danych do zweryfikowania hipotez dotyczących tych metryk. Niemniej poczynione obserwacje pozwalają wyciągnąć wstępne wnioski dotyczące tych metryk. Wprowadzanie metryki NER do modelu metodą I pozwoliło na uzyskanie ocen lepszych średnio o 2, 70%. W przypad-ku mediany różnica ta wyniosła aż 10, 25%. Wyniki takie są jak najbardziej zachęcające i skłaniają do przebadania tej metryki w kolejnych projektach. Zupełnie inne wyniki uzyskano dla metryki NPR.

4.4. PODSUMOWANIE 69

Rysunek 4.2: Częstość występowania metryk w modelach prostych.

Wprowadzanie jej do modelu spowodowało pogorszenie dokładności predykcji. Wynik taki stawia pod znakiem zapytania zasadność dalszych badań nad tą metryką.

Istotne statystycznie wyniki uzyskano dla metryki IN. Wprowadzenie tej metryki spowodowało jednak pogorszenie a nie poprawienie dokładności predykcji. Istnieją zatem przesłanki do sformuło-wania rekomendacji odradzającej stosowanie tej metryki w modelach predykcji defektów.

W przeprowadzanych eksperymentach badano wpływ każdej z metryk z osobna. Dodatkowo prze-analizowano również kombinację czterech metryk wprowadzanych do modelu predykcji defektów łącz-nie. Metryki te to NR, NDC, NML, NDPV. Są to metryki procesu wyliczone dla największej liczby wydań projektów. Spośród tych czterech metryk dwie (NDC i NML) wprowadzane z osobna popra-wiały dokładność predykcji w sposób istotny statystycznie. Okazało się, że wprowadzenie kombinacji metryk dało poprawę predykcji na tyle niewielką, że nie była ona istotna statystycznie. Wyniki ta-kie wskazują, że proces selekcji metryk zawsze powinien być przeprowadzony bardzo ostrożnie, gdyż wykorzystywanie zbyt dużej liczby metryk może czasami pogorszyć uzyskiwane wyniki.

Pomimo faktu, że modele wykorzystujące kombinację metryk nie okazały się być istotnie lepsze od modeli prostych, to ich budowa wewnętrzna może być bardzo ciekawa z uwagi na dużą liczbę wyko-rzystywanych metryk. Na Rysunku 4.1 pokazano ile razy poszczególne metryki były wykorzystywane w różnych modelach. Z uwagi na zastosowanie postępującej regresji, poszczególne modele wykorzy-stywały nie dość, że różne metryki to jeszcze różną ich liczbę. Jak można na Rysunku 4.1 zauważyć, najczęściej wykorzystywaną metryką była NDPV. Co jest szczególnie ciekawe z uwagi na fakt, że me-tryka ta nie została wskazana we wcześniejszych eksperymentach jako poprawiająca jakość predykcji. Metryki, które dokładność predykcji poprawiały, były wykorzystywane zdecydowanie rzadziej. Me-tryka NDC została użyta w pięciu modelach, a meMe-tryka NML w zaledwie trzech. W eksperymencie tym skonstruowano łącznie 12 modeli.

Na Rysunku 4.2 przedstawiono częstość występowania metryk w poszczególnych modelach pro-stych. Wyniki te dotyczą więc tylko metryk produktu, a są efektem skonstruowania łącznej liczby 51 modeli. Zdecydowanie najczęściej wykorzystywaną metryką jest tu RFC, nieco rzadziej używane były metryki CBO oraz LOC.

70 ROZDZIAŁ 4. CZYNNIKI WPŁYWAJĄCE NA DOKŁADNOŚĆ PREDYKCJI DEFEKTÓW

W Rozdziale 3 przedstawiono statystyki opisowe metryk. Między innymi podano tam również korelacje poszczególnych metryk z liczbą defektów. Ciekawą obserwacją jest rozbieżność pomiędzy wartościami korelacji a ocenami użyteczności metryk uzyskanymi z opisanych w tym rozdziale ekspe-rymentów. Najmocniej skorelowane z liczbą defektów, spośród metryk procesu, były NR oraz NDPV. Natomiast eksperymenty pokazały, że metryki NDC oraz NML poprawiły dokładność predykcji w sposób istotny statystycznie. Wynik taki pokazuje, że ograniczanie analizy do zbadania korelacji jest zdecydowanie niewystarczające w pracach dotyczących predykcji defektów. Wyniki uzyskane z analizy korelacji mogą się nie potwierdzić podczas konstrukcji modelu, w na przykład wyniku występowania kolinearności pomiędzy zmiennymi.

Rozdział 5