Eksperymenty korelujące miary kodu z gęstością błędów

16

Zastanawiam się, czy ktoś przeprowadził jakieś eksperymenty korelujące metryki kodu (SLOC, cykliczność złożoności itp.) Z gęstością błędów w aplikacjach obiektowych.

Nie szukam eksperymentów, które tylko dowodzą lub obalają korelację, ale na obu. Nie próbuję znaleźć srebrnej kuli, ponieważ uważam, że gęstość błędów w projekcie może korelować z co najmniej jedną metryką dla danego projektu lub zespołu, a korelacja może się zmienić w czasie trwania projektu / zespołu.

Moim celem jest

  1. Mierz wszystkie interesujące pomiary przez 2-3 miesiące (mamy już sporo z sonaru).
  2. Znajdź jedną metrykę, która koreluje z liczbą nowych błędów.
  3. Wykonaj analizę pierwotnej przyczyny, aby sprawdzić, dlaczego tak się dzieje (np. Czy brakuje nam pewnych umiejętności projektowania?).
  4. Popraw umiejętności i zmień zmianę dla kilku iteracji.
  5. Opłucz i powtórz od 2.

Jeśli nie masz doświadczenia w tym zakresie, ale pamiętasz, jak zobaczyłeś artykuł / blog na ten temat, byłbym wdzięczny, jeśli możesz się nim podzielić.


Do tej pory znalazłem poniższe linki z pewnymi informacjami na ten temat

Augusto
źródło
1
Jeśli chcesz uniknąć zamknięcia, powinieneś przeformułować swoje pytanie. Witryny Stack Exchange niewyszukiwarkami, a użytkownicy nieosobistymi asystentami badawczymi . Zamiast pytać o linki do artykułów, należy położyć nacisk na pytanie, jakie rodzaje wskaźników zostały skorelowane z defektami i gęstością defektów.
Thomas Owens
1
Przykro mi, że pytanie pojawiło się jako prośba o zostanie moim osobistym asystentem wyszukiwania , zdecydowanie nie to chciałem zrobić, ale znalezienie tego rodzaju dokumentów nie jest czymś bardzo częstym. Zmieniłem tytuł, aby inni ludzie nie mieli tego samego wrażenia.
Augusto

Odpowiedzi:

11

Ilekroć słyszę o próbach powiązania pewnego rodzaju metryki opartej na kodzie z defektami oprogramowania, pierwszą rzeczą, o której myślę, jest cykliczność złożoności McCabe . Różne badania wykazały, że istnieje związek między wysoką złożonością cykliczną a liczbą wad. Jednak inne badania, w których analizowano moduły o podobnej wielkości (pod względem linii kodu), wykazały, że może nie istnieć korelacja.

Dla mnie zarówno liczba linii w module, jak i złożoność cykliczna mogą służyć jako dobre wskaźniki możliwych defektów, a może większe prawdopodobieństwo, że defekty zostaną wstrzyknięte, jeśli zostaną dokonane modyfikacje modułu. Moduł (szczególnie na poziomie klasy lub metody) o dużej złożoności cyklicznej jest trudniejszy do zrozumienia, ponieważ w kodzie znajduje się duża liczba niezależnych ścieżek. Moduł (ponownie, zwłaszcza na poziomie klasy lub metody) z dużą liczbą linii jest również trudny do zrozumienia, ponieważ wzrost linii oznacza, że ​​dzieje się więcej rzeczy. Istnieje wiele narzędzi do analizy statycznej, które obsługują obliczanie obu linii kodu źródłowego w oparciu o określone reguły i złożoność cykliczną, wydaje się, że uchwycenie ich pochwyciłoby nisko wiszący owoc.

Te środki złożoność Halstead może również być interesujące. Niestety ich ważność wydaje się nieco dyskutowana, więc nie musiałbym na nich polegać. Jednym z mierników Halsteada jest oszacowanie defektów na podstawie nakładu pracy lub objętości (związek między długością programu pod względem całkowitej liczby operatorów i operandów a słownictwem programu pod względem różnych operatorów i operatorów).

Istnieje również grupa metryk znanych jako Metryki CK. Pierwsza definicja tego pakietu metryk wydaje się być w dokumencie zatytułowanym A Metrics Suite for Object Oriented Design autorstwa Chidamber i Kemerer. Definiują metody ważone według klasy, głębokość drzewa dziedziczenia, liczbę dzieci, sprzężenie między klasami obiektów, reakcję na klasę i brak spójności metod. Ich praca zawiera metody obliczeniowe, a także opis sposobu ich analizy.

Jeśli chodzi o literaturę akademicką analizującą te metryki, być może zainteresuje Cię analiza empiryczna metryk CK dla złożoności projektowania obiektowego: implikacje defektów oprogramowania, autor: Ramanath Subramanyam i MS Krishna. Przeanalizowali trzy z sześciu wskaźników CK (metody ważone na klasę, sprzężenie między sklasyfikowanym obiektem i głębokość drzewa dziedziczenia). Przeglądając gazetę, wydaje się, że okazało się, że są to potencjalnie prawidłowe wskaźniki, ale należy je interpretować ostrożnie jako „poprawę”, która może prowadzić do innych zmian, które również prowadzą do większego prawdopodobieństwa wystąpienia wad.

Analiza empiryczna zorientowanych obiektowo wskaźników projektowych do prognozowania błędów o wysokim i niskim poziomie ważności, opracowana przez Yuminga Zhou i Haretona Leunga, również analizuje wskaźniki CK. Ich podejście polegało na ustaleniu, czy potrafią przewidzieć defekty na podstawie tych wskaźników. Odkryli, że wiele wskaźników CK, z wyjątkiem głębokości drzewa dziedziczenia i liczby dzieci) miało pewien poziom istotności statystycznej w przewidywaniu obszarów, w których można zlokalizować defekty.

Jeśli masz członkostwo w IEEE, polecam wyszukiwanie w Transakcjach IEEE dotyczących inżynierii oprogramowania w celu uzyskania dalszych publikacji naukowych i oprogramowania IEEE w celu uzyskania bardziej realistycznych i stosowanych raportów. ACM może również mieć odpowiednie publikacje w swojej bibliotece cyfrowej .

Thomas Owens
źródło
Wykazano, że wszystkie pomiary Halstead są silnie skorelowane z nieprzetworzonym SLOC (liczba linii kodu źródłowego). W tym momencie wszystko, co jest skorelowane z dowolną metryką Halstead, stało się znane z korelacji z nieprzetworzonym SLOC, i łatwiej jest zmierzyć SLOC niż jakikolwiek wskaźnik Halstead.
John R. Strohm
@ JohnR.Strohm Nie zgadzam się, że łatwiej jest liczyć SLOC niż obliczać miary Halsteada, gdy używasz narzędzi do obliczeń. Zakładając, że metryki Halsteada są prawidłowe (co jest faktycznie dyskutowane, ale nic nie ma znaczenia dla nieprawidłowej metryki), znajomość czasu potrzebnego do opracowania kodu lub przewidywanej liczby defektów w systemie jest bardziej przydatną wartością niż znajomość kwoty linii. Potrafię budować harmonogramy z danymi czasu, plany jakości z danymi wad lub z trudem przeznaczyć wystarczającą ilość czasu na przegląd kodu. Do tych rzeczy trudniej jest używać surowego SLOC.
Thomas Owens
@ JohnR.Strohm Jestem pewien, że wykonanie programu obliczeniowego Halstead zajmuje trochę więcej czasu niż program zliczający SLOC. Ale zakładając, że prawidłowe dane wyjściowe stają się prawidłowymi danymi wejściowymi do podejmowania decyzji, wolałbym mieć sensowny czas, wysiłek i defekty danych niż surową liczbę SLOC. Wartość dodana bardziej złożonej metryki jest często warta dodatkowego czasu obliczeniowego, ponownie zakładając prawidłowe dane wejściowe i prawidłowe dane wyjściowe obliczeń.
Thomas Owens
@ThomasOwens, pytanie, czy wysiłek związany z oprogramowaniem, a co za tym idzie koszt i harmonogram, można oszacować bezpośrednio na podstawie szacunków surowego SLOC, dokonano na śmierć. Po dogłębnych badaniach rzeczywistych danych projektowych pytanie zostało rozstrzygnięte twierdząco. Patrz „Software Engineering Economics”, autor: Barry Boehm, 1981.
John R. Strohm
@ThomasOwens: Ponadto należy uznać, że wskaźniki Halstead są z natury retrospektywne. Nie można zmierzyć metryk Halstead oprogramowania, które nie zostało jeszcze napisane. Z drugiej strony, możliwe jest oszacowanie surowego SLOC dla danego zadania, a biorąc pod uwagę wystarczająco szczegółowe specyfikacje i trochę doświadczenia, stosunkowo łatwo jest zbliżyć się do oszacowania. Co więcej, BARDZO łatwo jest porównać szacunki z rzeczywistymi, dostroić heurystykę szacunkową i skalibrować estymator kosztów. General Dynamics / Fort Worth wykonał na tym wiele pracy na początku lat osiemdziesiątych.
John R. Strohm
7

Omówiłem możliwe korelacje w jednym z moich postów na blogu :

Korelacja między złożonością cykliczną a gęstością błędów: czy to jest prawdziwy problem?

Odpowiedź brzmi nie. Utrzymując stały rozmiar, badania nie wykazały korelacji między CC a gęstością defektów. Istnieją jednak dwie inne interesujące korelacje do zbadania:

Pierwszym z nich jest: Czy CC silnie koreluje z czasem trwania wykrywania i usuwania defektów? Innymi słowy, jeśli CC jest niższe, czy spędzilibyśmy mniej czasu na debugowaniu i naprawianiu wad?

Drugi to: Czy CC silnie koreluje ze współczynnikiem sprzężenia zwrotnego błędu (FFR, średnia liczba defektów wynikająca z zastosowania jednej zmiany lub usunięcia jednej wady)?

Potrzebuje więcej badań, aby sprawdzić, czy ktoś kiedykolwiek badał tę korelację empirycznie. Ale moje przeczucie i informacje zwrotne, które otrzymuję od zespołów, z którymi pracuję, są takie, że istnieje silna dodatnia korelacja między złożonością cykliczną z jednej strony a czasem wykrycia i usunięcia usterki lub wpływu zmiany z drugiej strony.

To dobry eksperyment do zrobienia. Uważaj na wyniki!

Amr Noaman
źródło
Nie jest warte oceny negatywnej, ale powinno to brzmieć: „niektóre badania nie wykazują korelacji”, ponieważ inne badania wykazują korelację.
David Hammen
3

W książce Code Complete, str. 457, Steve McConnell mówi, że „złożoność sterowania przepływem jest ważna, ponieważ została skorelowana z niską niezawodnością i częstymi błędami”. Następnie wspomina o kilku referencjach, które wspierają tę korelację, w tym o samym McCabe (któremu przypisuje się opracowanie metryki złożoności cyklicznej). Większość z nich poprzedza powszechne użycie języków zorientowanych obiektowo, ale ponieważ ta metryka dotyczy metod w tych językach, odniesienia mogą być tym, czego szukasz.

Odniesienia te to:

  • McCabe, Tom. 1976. „Miara złożoności”. Transakcje IEEE dotyczące inżynierii oprogramowania, SE-2, nr. 4 (grudzień): 308-20
  • Shen, Vincent Y. i in. 1985. „Identyfikacja podatnego na błędy oprogramowania - badanie empiryczne”. Transakcje IEEE dotyczące inżynierii oprogramowania SE-11, nr 4 (kwiecień): 317-24.
  • Ward, William T. 1989. „Zapobieganie defektom oprogramowania za pomocą metryki złożoności McCabe”. Hewlett-Packard Journal, 64–68 kwietnia.

Z mojego doświadczenia wynika, że ​​metryka McCabe, ponieważ może być obliczona przez program w wielu sekcjach kodu, jest przydatna w znajdowaniu metod i funkcji, które są nadmiernie skomplikowane i które mają duże prawdopodobieństwo zawierania błędów. Chociaż nie obliczałem, rozkład błędów w funkcjach o wysokiej złożoności cyklicznej w porównaniu do funkcji o niskiej złożoności cyklicznej, badanie tych funkcji pozwoliło mi odkryć przeoczone błędy programistyczne.

QuantumOmega
źródło