Akwizycja danych do badań
3.4 Narzędzia
Rysunek 3.23: Number of Defects in Previous Version
Number of Evening Revisions (NER). Motywacją stojącą za tą metryką jest presja jaką wywołuje zbliżający się koniec dnia roboczego. Programista wiedząc, że pozostaje mu niewiele czasu do wyjścia z pracy, może zatwierdzić modyfikacje, których mając więcej dostępnego czasu by nie zaakceptował. Szczegóły dotyczące metryki NER znajdują się w załączniku w Tabeli B.6. Metryka ta była badana tylko w jednym projekcie w związku z tym w Tabeli B.6 podano jej charakterystykę w poszczegól-nych wersjach tego projektu. Nie podano rysunku opartego o mediany metryki NER, ponieważ we wszystkich przebadanych wersjach projektu mediana była równa zero. Metryka ta przyjmuje niezbyt wysokie wartości. Wyliczone korelacje z liczbą defektów również nie wyglądają nazbyt zachęcająco, najwyższa uzyskana wartość to 0,38.
Number of Pre-code-freeze Revisions (NPR). Jest to druga z kolei metryka mająca za zadanie una-ocznić wykonywanie zadań programistycznych pod presją. W przypadku tej metryki presja wynika ze zbliżającego się terminu zakończenia prac związanych z przygotowywaniem kolejnego wydania rozwi-janego systemu. Szczegóły dotyczące metryki NPR znajdują się w załączniku w Tabeli B.7. Metryka ta była badana tylko w jednym projekcie w związku z tym w Tabeli B.7 podano jej charakterystykę w poszczególnych wersjach tego projektu. Nie podano rysunku opartego o mediany metryki NPR, ponieważ we wszystkich przebadanych wersjach projektu mediana była równa zero. Metryka ta przyj-muje jeszcze mniejsze wartości niż opisana powyżej NER. Metrykę tą analizowano w zaledwie dwóch wersjach jednego projektu. Zebrane dane mogą być zatem niewystarczające i niemiarodajne. Niemniej jednak, nie dają one mocnych przesłanek ku temu, że metryka ta może być dobrym predykatorem liczby defektów – wyliczone korelacje są stosunkowo niskie.
3.4 Narzędzia
W ramach prac związanych z wyliczaniem, gromadzeniem oraz zarządzaniem metrykami powstało kilka narzędzi, które zostały następnie opublikowane w internecie i mogą być wykorzystywane zarówno w dalszych badaniach jak i w zarządzaniu jakością rzeczywistych projektów programistycznych.
50 ROZDZIAŁ 3. AKWIZYCJA DANYCH DO BADAŃ
3.4.1 Ckjm
Ckjm to narzędzie wyliczające metryki produktu z kodu binarnego Javy. W początkowym zamyśle
narzędzie to miało wyliczać sześć metryk z zestawu CK. Z czasem zostało jednak rozszerzone i jego aktualna wersja wylicza wszystkie badane tu metryki produktu.
W celu zgromadzenia danych do opisanych w kolejnych rozdziałach eksperymentów opracowa-no opracowa-nową wersję narzędzia Ckjm. Podstawę staopracowa-nowiła wersja 1.8∗. Wersja ta potrafiła wyliczyć sześć metryk z zestawu CK oraz metryki Ce i NPM. Na podstawie tej wersji opracowano rozszerzoną wer-sję programu†, która wylicza kolejnych jedenaście metryk wymienionych w Rozdziale 3.2, co daje w sumie dziewiętnaście różnych metryk oprogramowania. Mimo stosunkowo dużej liczby metryk pro-gram zachował swoje początkowe zalety, czyli prostotę i szybkość działania. Propro-gram integruje się z
Apache Ant co umożliwia łatwe jego wdrożenie w środowiskach programistycznych opartych
zarów-no na Apache Ant jak i Apache Maven. Działanie programu zostało szczegółowo przeanalizowane i zweryfikowane pod kątem możliwości zastosowania w modelach predykcji defektów [55].
3.4.2 BugInfo
W celu zgromadzenia danych dotyczących metryk procesu i liczby defektów opracowano narzędzie
BugInfo‡. Narzędzie to analizuje zawartość systemu kontroli wersji (aktualna wersja BugInfo współ-pracuje z CVS oraz SubVersion) ze szczególnym uwzględnieniem komentarzy wstawianych podczas zatwierdzania modyfikacji. Interpretacja komentarzy była konieczna do wykrywania defektów, me-tryki produktu są albo niemal bezpośrednio dostępne w systemie kontroli wersji albo opierają się na defektach, jak na przykład NDPV. Jeżeli komentarz wskazuje, że zatwierdzane zmiany dotyczą naprawiania defektu, przyjmuje się, że modyfikowane klasy zawierały defekt przed zatwierdzeniem tych zmian.
Każdy z badanych projektów został przeanalizowany pod kątem reguł, według których komen-towano modyfikacje powiązane z naprawianiem defektów. W niemal wszystkich przypadkach tego typu modyfikacje było komentowane przy pomocy identyfikatora (lub adresu url) defektu w systemie śledzenia defektów albo przy pomocy pewnych słów kluczowych, takich jak na przykład bugfix. Na podstawie tych analiz, dla każdego z projektów skonstruowano wyrażenie regularne, które następnie zostało przekazane jako parametr do programu BugInfo. Jeżeli komentarz towarzyszący modyfika-cji pasował do przekazanego wyrażenia regularnego, BugInfo identyfikował modyfikację jako zmianę naprawiającą defekt i tym samym zwiększał licznik defektów dla modyfikowanej klasy. Tego typu podejście jest powszechnie uznawane i rekomendowane w pracach dotyczących predykcji defektów, na przykład w [42].
Poprawność działania narzędzia została zweryfikowana przy pomocy wyczerpujących testów funk-cjonalnych i jednostkowych. Testy te zostały zautomatyzowane do postaci testów JUnit i zostały opublikowane w internecie wraz z wersją wykonywalną programu. BugInfo został już wykorzystany w szeregu prac naukowych: [46], [47], [48], [49] oraz [55].
3.4.3 Metrics Repository
Na potrzeby opisanych w kolejnych rozdziałach eksperymentów zostały zebrane dane z 92 wersji 38 projektów. Jest to ilość niebagatelna jeżeli zwrócić uwagę na fakt, że w największym ogólnodostępnym repozytorium metryk – Promise§ zestawy metryk opisują od 1 do 9 wersji projektów, a wszystkie
∗http://www.spinellis.gr/sw/ckjm/
†http://gromit.iiar.pwr.wroc.pl/p inf/ckjm/ ‡http://kenai.com/projects/buginfo §http://promisedata.org/
3.4. NARZĘDZIA 51
zestawy łącznie zawierają informacje o 57 wersjach projektów (stan po konferencji PROMISE’09). W repozytorium Promise w poszczególnych zestawach wyliczano różne metryki, więc w ramach jednego eksperymentu trzeba się zazwyczaj ograniczać do jednego zestawu, co daje maksymalnie 9 wersji projektów.
Duża część z zebranych na potrzeby tej pracy metryk została wykorzystana w pracy przyjętej na konferencję PROMISE’10 [47] i w związku z tym zostanie w niedalekiej przyszłości dołączona do repozytorium Promise. Natomiast już teraz działa witryna internetowa¶, na której zebrano me-tryki dotyczące wszystkich wersji wszystkich projektów analizowanych w ramach któregokolwiek z eksperymentów opisanych w kolejnych rozdziałach.