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

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

• Czy błędy znajdują się w złożonym kodzie? - tylko slajdy z prezentacji.
• Zmiany i błędy: eksploracja i przewidywanie działań programistycznych - po prostu slajdy z prezentacji. Podsumowując, im więcej zależności, tym większe szanse na błędy (myślę, że jest to dość ogólna zasada).
• Niepowodzenie to czteroliterowe słowo - parada na temat korelacji między błędami a miernikami.

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 .

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!

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.