Experimente, die Codemetriken mit der Fehlerdichte in Beziehung setzen


16

Ich frage mich, ob jemand einige Experimente durchgeführt hat, bei denen Codemetriken (SLOC, zyklomatische Komplexität usw.) mit der Fehlerdichte in objektorientierten Anwendungen in Beziehung gesetzt wurden.

Ich suche keine Experimente, die nur eine Korrelation beweisen oder widerlegen, sondern beides. Ich versuche nicht , einen Königsweg zu finden , wie ich , dass die Bug Dichte eines Projektes glauben könnte , um eine oder mehr Metriken für ein bestimmtes Projekt oder Team korrelieren und die Korrelation kann während der Laufzeit des Projektes / Teams ändern.

Mein Ziel ist es,

  1. Messen Sie alle interessanten Messdaten für 2-3 Monate (wir haben bereits einige vom Sonar).
  2. Suchen Sie eine Metrik, die mit der Anzahl der neuen Fehler korreliert.
  3. Führen Sie eine Ursachenanalyse durch, um zu überprüfen, warum dies passiert (z. B. fehlt uns eine bestimmte Konstruktionskompetenz?).
  4. Verbessern Sie die Fertigkeit und messen Sie Änderungen für ein paar Wiederholungen.
  5. Abspülen und wiederholen 2.

Wenn Sie hierzu noch keine Erfahrung haben, sich aber an eine Veröffentlichung / einen Blog zu diesem Thema erinnern, würde ich mich freuen, wenn Sie uns diese mitteilen können.


Bisher habe ich die folgenden Links mit einigen Informationen zu diesem Thema gefunden


1
Wenn Sie eine Schließung vermeiden möchten, sollten Sie Ihre Frage umstellen. Stack Exchange-Sites sind keine Suchmaschinen und Benutzer sind keine persönlichen Rechercheassistenten . Anstatt nach Links zu Artikeln zu fragen, sollte der Schwerpunkt auf der Frage liegen, welche Arten von Metriken mit Defekten und Defektdichte korreliert wurden.
Thomas Owens

1
Es tut mir leid, dass die Frage als Anfrage auftauchte, mein persönlicher Suchassistent zu werden. Es ist definitiv nicht das, was ich tun wollte, aber diese Art von Papieren zu finden, ist nicht alltäglich. Ich habe den Titel geändert, damit andere Menschen nicht den gleichen Eindruck haben.
Augusto

Antworten:


11

Immer wenn ich von Versuchen höre, eine Art codebasierte Metrik mit Softwarefehlern in Verbindung zu bringen, denke ich zuerst an McCabes zyklomatische Komplexität . Verschiedene Studien haben ergeben, dass ein Zusammenhang zwischen einer hohen zyklomatischen Komplexität und der Anzahl der Defekte besteht. Andere Studien, die Module mit einer ähnlichen Größe (in Bezug auf Codezeilen) untersuchten, stellten jedoch möglicherweise keine Korrelation fest.

Für mich könnten sowohl die Anzahl der Zeilen in einem Modul als auch die zyklomatische Komplexität als gute Indikatoren für mögliche Fehler dienen oder möglicherweise die Wahrscheinlichkeit erhöhen, dass Fehler auftreten, wenn Änderungen an einem Modul vorgenommen werden. Ein Modul (insbesondere auf Klassen- oder Methodenebene) mit hoher zyklomatischer Komplexität ist schwerer zu verstehen, da es eine große Anzahl unabhängiger Pfade durch den Code gibt. Ein Modul (wiederum insbesondere auf Klassen- oder Methodenebene) mit einer großen Anzahl von Zeilen ist ebenfalls schwer zu verstehen, da die Zunahme der Zeilen bedeutet, dass mehr Dinge geschehen. Es gibt viele statische Analysewerkzeuge, die die Berechnung beider Quellcodezeilen anhand festgelegter Regeln und der zyklomatischen Komplexität unterstützen. Es scheint, als würde das Erfassen dieser Regeln die gering hängenden Früchte packen.

Die Halstead-Metrik könnte auch interessant sein. Leider scheint ihre Gültigkeit etwas umstritten zu sein, sodass ich mich nicht unbedingt auf sie verlassen müsste. Eine von Halsteads Maßnahmen ist die Schätzung von Fehlern auf der Grundlage des Aufwands oder des Volumens (ein Verhältnis zwischen der Programmlänge in Bezug auf die Gesamtzahl der Operatoren und Operanden und dem Programmvokabular in Bezug auf die einzelnen Operatoren und Operatoren).

Es gibt auch eine Gruppe von Metriken, die als CK-Metriken bezeichnet werden. Die erste Definition dieser Metrik-Suite befindet sich in einem Artikel mit dem Titel Eine Metrik-Suite für objektorientiertes Design von Chidamber und Kemerer. Sie definieren gewichtete Methoden pro Klasse, Tiefe des Vererbungsbaums, Anzahl der Kinder, Kopplung zwischen Objektklassen, Antwort für eine Klasse und mangelnde Kohäsion in Methoden. Ihr Artikel enthält die Berechnungsmethoden sowie eine Beschreibung der Analyse der einzelnen Methoden.

In Bezug auf die wissenschaftliche Literatur, die diese Metriken analysiert, könnte Sie die empirische Analyse von CK-Metriken auf objektorientierte Entwurfskomplexität: Implikationen für Softwarefehler interessieren, die von Ramanath Subramanyam und MS Krishna verfasst wurde. Sie analysierten drei der sechs CK-Metriken (gewichtete Methoden pro Klasse, Kopplung zwischen Objektklasse und Tiefe des Vererbungsbaums). Ein Blick durch das Papier zeigt, dass es sich um potenziell gültige Messgrößen handelt, die jedoch mit Vorsicht interpretiert werden müssen, da eine "Verbesserung" zu anderen Änderungen führen kann, die ebenfalls zu einer höheren Wahrscheinlichkeit von Fehlern führen.

Die von Yuming Zhou und Hareton Leung verfasste empirische Analyse objektorientierter Entwurfsmetriken zur Vorhersage von Fehlern mit hohem und niedrigem Schweregrad untersucht auch die CK-Metriken. Ihr Ansatz bestand darin, zu bestimmen, ob sie Fehler basierend auf diesen Metriken vorhersagen können. Sie stellten fest, dass viele der CK-Metriken (mit Ausnahme der Tiefe des Vererbungsbaums und der Anzahl der Kinder) ein gewisses Maß an statistischer Signifikanz bei der Vorhersage von Bereichen haben, in denen Fehler lokalisiert werden könnten.

Wenn Sie eine IEEE-Mitgliedschaft haben, würde ich empfehlen, in den IEEE-Transaktionen zur Softwareentwicklung nach mehr wissenschaftlichen Veröffentlichungen und in der IEEE-Software nach realistischeren und angewandten Berichten zu suchen . Der ACM verfügt möglicherweise auch über relevante Veröffentlichungen in seiner digitalen Bibliothek .


Es wurde gezeigt, dass die Halstead-Metriken stark mit dem unformatierten SLOC (Anzahl der Quellcodezeilen) korrelieren. Zu diesem Zeitpunkt wurde bekannt, dass alles, was mit einer Halstead-Metrik korreliert ist, mit dem unformatierten SLOC korreliert ist, und es ist einfacher, den SLOC zu messen als jede der Halstead-Metriken.
John R. Strohm

@ JohnR.Strohm Ich bin nicht der Meinung, dass es einfacher ist, SLOC zu zählen, als die Halstead-Metriken zu berechnen, wenn Sie Tools für die Berechnung verwenden. Unter der Annahme, dass die Halstead-Metriken gültig sind (was tatsächlich diskutiert wird, aber für eine ungültige Metrik nichts ausmacht), ist die Kenntnis der zum Entwickeln des Codes erforderlichen Zeit oder der projizierten Anzahl von Fehlern im System ein nützlicherer Wert als die Kenntnis der Menge von Linien. Ich kann Zeitpläne mit Zeitdaten erstellen, Qualitätspläne mit fehlerhaften Daten erstellen oder einer Codeüberprüfung nur schwer genug Zeit widmen. Es ist schwieriger, für diese Dinge SLOC-Rohdaten zu verwenden.
Thomas Owens

@ JohnR.Strohm Ich bin sicher, dass die Ausführung eines Halstead-Metrik-Berechnungsprogramms etwas länger dauert als die eines SLOC-Zählprogramms. Unter der Annahme, dass eine gültige Ausgabe eine gültige Eingabe in eine Entscheidungsfindung wird, hätte ich lieber sinnvolle Zeit-, Arbeits- und Fehlerdaten als eine unformatierte SLOC-Zählung. Der Mehrwert der komplexeren Metrik ist häufig die zusätzliche Berechnungszeit wert, wobei wiederum gültige Eingaben und gültige Berechnungsausgaben vorausgesetzt werden.
Thomas Owens

@ThomasOwens, die Frage, ob der Softwareaufwand und damit die Kosten und der Zeitplan direkt aus den Schätzungen des unbehandelten SLOC geschätzt werden können, wurde hinfällig. Nach eingehender Recherche der realen Projektdaten wurde die Frage bejaht. Siehe "Software Engineering Economics", von Barry Boehm, 1981.
John R. Strohm

@ThomasOwens: Außerdem muss man erkennen, dass die Halstead-Metriken von Natur aus retrospektiv sind. Sie können die Halstead-Metriken von Software, die Sie noch nicht geschrieben haben, nicht messen. Auf der anderen Seite ist es möglich, den Roh-SLOC für eine bestimmte Aufgabe abzuschätzen, und bei ausreichenden Spezifikationen und ein wenig Erfahrung ist es relativ einfach, der Schätzung ziemlich nahe zu kommen. Darüber hinaus ist es SEHR einfach, Schätzungen mit Ist-Werten zu vergleichen, die geschätzten Heuristiken abzustimmen und den Kostenschätzer zu kalibrieren. General Dynamics / Fort Worth haben in den frühen 1980er Jahren viel daran gearbeitet.
John R. Strohm

7

Ich habe mögliche Zusammenhänge in einem meiner Blog-Beiträge besprochen :

Korrelation zwischen zyklomatischer Komplexität und Fehlerdichte: Ist dies das eigentliche Problem?

Die Antwort ist nein. Studien , die die Größe konstant halten, zeigen keine Korrelation zwischen CC und Defektdichte. Es gibt jedoch zwei weitere interessante Zusammenhänge:

Die erste lautet: Korreliert CC stark mit der Dauer der Erkennung und Behebung von Fehlern? Mit anderen Worten, wenn CC niedriger ist, würden wir weniger Zeit für das Debuggen und Beheben von Fehlern aufwenden?

Die zweite lautet: Korreliert CC stark mit dem Fehler-Feedback-Verhältnis (FFR, die durchschnittliche Anzahl von Fehlern, die sich aus der Anwendung einer Änderung oder der Behebung eines Fehlers ergibt)?

Es bedarf weiterer Untersuchungen, um festzustellen, ob jemand diese Korrelation jemals empirisch untersucht hat. Mein Bauchgefühl und das Feedback der Teams, mit denen ich zusammenarbeite, ist jedoch, dass eine starke positive Korrelation zwischen der zyklomatischen Komplexität auf der einen Seite und der Dauer der Erkennung und Behebung eines Fehlers oder der Auswirkung von Änderungen auf der anderen Seite besteht.

Dies ist ein gutes Experiment. Achten Sie auf die Ergebnisse!


Keine negative Bewertung, aber das sollte lauten: "Einige Studien zeigen keine Korrelation", da andere Studien eine Korrelation aufweisen.
David Hammen

3

In dem Buch Code Complete, S. 457, sagt Steve McConnell, dass "die Komplexität des Kontrollflusses wichtig ist, weil sie mit geringer Zuverlässigkeit und häufigen Fehlern korreliert wurde". Anschließend erwähnt er einige Referenzen, die diese Korrelation stützen, einschließlich McCabe selbst (dem zugeschrieben wird, die zyklomatische Komplexitätsmetrik entwickelt zu haben). Die meisten dieser Kriterien datieren auf die weit verbreitete Verwendung objektorientierter Sprachen zurück. Da diese Metrik jedoch für Methoden in diesen Sprachen gilt, sind die Referenzen möglicherweise genau das, wonach Sie suchen.

Diese Referenzen sind:

  • McCabe, Tom. 1976. "Ein Komplexitätsmaß." IEEE Transactions on Software Engineering, SE-2, No. 4 (Dezember): 308-20
  • Shen, Vincent Y. et al. 1985. "Identifizierung fehleranfälliger Software - Eine empirische Studie." IEEE Transactions on Software Engineering SE-11, Nr. 4 (April): 317-24.
  • Ward, William T. 1989. "Software Defect Prevention Using McCabes Complexity Metric." Hewlett-Packard Journal, April 64-68.

Aus eigener Erfahrung ist McCabes Metrik, wie sie von einem Programm in vielen Codeabschnitten berechnet werden kann, nützlich, um Methoden und Funktionen zu finden, die überkompliziert sind und mit hoher Wahrscheinlichkeit Fehler enthalten. Obwohl ich nicht gerechnet habe, hat die Verteilung der Fehler in Funktionen mit hoher zyklomatischer Komplexität im Vergleich zu Funktionen mit niedriger zyklomatischer Komplexität es mir ermöglicht, übersehene Programmierfehler zu entdecken, wenn ich diese Funktionen untersuche.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.