Gibt es irgendeine Arbeit in der Anwendung der Halstead-Komplexitätsmaße, um die Softwarequalität zu bestimmen?

1977 stellte Maurice Howard Halstead seine Komplexitätsmessungen für Softwaresysteme vor , die Messungen des Programmvokabulars, der Programmlänge, des Volumens, des Schwierigkeitsgrades, des Aufwands und der geschätzten Anzahl von Fehlern in einem Modul umfassten. Laut Wikipedia bezieht sich die Schwierigkeit auf die Schwierigkeit, das Programm beim Lesen oder Schreiben zu verstehen, und der Aufwand kann in die Zeit übersetzt werden, die zum Codieren einer Anwendung mit Time = (Effort / 18) Sekunden benötigt wird.

Eine Messung ist nutzlos, es sei denn, die Daten und Berechnungen beziehen sich auf einen Aspekt der Softwareentwicklung. Ich habe jedoch keine Arbeit gefunden, die besagt, dass eine Schwierigkeit mit einem bestimmten Wert oder höher zu einer statistisch signifikanten Zunahme von Fehlern oder einem Zusammenhang zwischen Schwierigkeit und Zeit zum Lesen von Code neigt (eine Schwierigkeit mit N ergibt einen Durchschnitt von M Stunden, die verbracht wurden) Verständnis der Codebasis) oder jede Analyse der Fähigkeit, die Zeit nach der Tatsache zu berechnen, die für die Bestimmung der Qualität nützlich ist (zumal die Zeit zum Schreiben bereits als Maß aufgezeichnet werden sollte). Ich interessiere mich besonders für Halsteads Fehlerabschätzung (die in Wikipedia nicht erwähnt wird) - die Anzahl der Fehler in einer Anwendung kann mit Volume / 3000 oder Effort ^ (2/3) / 3000 abgeschätzt werden.

Ich suche zwei Dinge:

Hat jemand die Software-Komplexitätsmessungen von Halstead in einer realen Anwendung verwendet, um die Softwarequalität zu bewerten? Wenn ja, wie haben Sie sie angewendet und sie haben sich als nützliche, gültige und / oder zuverlässige Messung erwiesen?
Gibt es eine akademische Forschung in Form von Umfragen, Analysen oder Fallstudien, die die Gültigkeit (oder Ungültigkeit) von Halstead-Komplexitätsmaßen in Bezug auf die Softwarequalität erörtern?
Gibt es eine akademische Forschung in Form von Umfragen, Analysen oder Fallstudien, die die Verwendung von Source Lines of Code (SLOC) zur Berechnung ähnlicher Größen wie Volumen, Schwierigkeit, Aufwand, Zeit und Fehler belegen? Ich würde vermuten, dass das Volumen möglicherweise nur einer SLOC-Anzahl entspricht und die Schwierigkeit möglicherweise der zyklomatischen Komplexität (und möglicherweise anderen Maßnahmen) entspricht. Mir ist auch bewusst, dass das Messen des Aufwands, der Produktivität oder der Zeit in SLOC möglicherweise irreführend ist.

quality metrics measurement

— Thomas Owens
quelle

Sie werden in den letzten 15 Jahren einige Probleme haben, Ergebnisse zu finden, da Halsteads Metriken eher vor 30 bis 40 Jahren erstellt wurden und die starke Korrelation mit dem SLOC fast sofort entdeckt wurde. (Dies ist aus dem Gedächtnis, nach einem Vortrag eines neuen Doktoranden an der UT Austin um 1977.)

— John R. Strohm

Dank dafür. Ich werde die Frage aktualisieren und meine Suchanstrengungen auf ältere Artikel konzentrieren.

— Thomas Owens

Antworten:

Microsoft Research hat in diesem Bereich einige Arbeiten durchgeführt. Schauen Sie sich diese Seite an: http://research.microsoft.com/en-us/people/nachin/ . Obwohl nicht speziell auf Halstead basierend, haben Nachi und sein Team einige Untersuchungen unter Verwendung von Halstead, zyklomatischer Komplexität, Codeabwanderung und anderen Maßnahmen durchgeführt, um das relative Risiko und die Fragilität für Änderungen in Codebereichen zu bewerten. Es gibt auch ein interessantes Papier darüber, wie organisatorische Effektivität ebenfalls eine große Rolle spielt, aber das ist kein Thema. :)

— Nithine
quelle

Ich muss einige davon lesen. Auf jeden Fall etwas, das mich interessiert, aber ich bin (zumindest im Moment) besonders an Halstead interessiert, also werde ich mich dort konzentrieren. Ich habe die Site mit einem Lesezeichen versehen, damit ich sie lesen kann, wenn ich mehr Zeit habe, aber hier ist vorerst eine +1.

— Thomas Owens

Es hat sich gezeigt, dass McCabes zyklomatische Komplexität im realen Code sehr stark mit dem rohen SLOC korreliert.

— John R. Strohm

Es gibt eine ganze Reihe solcher Studien. Google ist dein Freund.

Die Metriken von Halstead gerieten in Ungnade, als gezeigt wurde, dass sie alle stark mit dem rohen SLOC (Quellcodezeilen) korrelierten. An diesem Punkt wird es einfacher, den SLOC zu messen und damit fertig zu werden.

Hier ist ein Ergebnis von Google Books .

— John R. Strohm
quelle

Ich habe gegoogelt, seitdem ich diese Frage gestellt habe und noch keine veröffentlichten Artikel oder andere seriöse Quellen gefunden habe. Außerdem verstehe ich nicht, wie schlecht eine mit SLOC verbundene Metrik sein kann. SLOC / Zeit ist ein schlechtes Maß für die Produktivität, aber andere SLOC-basierte Metriken werden normalerweise als gültig angesehen, beispielsweise Defekte / SLOC.

— Thomas Owens

@Thomas: Es ist nicht so, dass Halsteads Metriken mit SLOC "verwandt" sind, sondern dass sie stark korrelieren. Statistik 102. Wenn man sagt, dass Y und X stark korreliert sind, bedeutet dies, dass das Verhältnis Y / X für alle Datensätze im Wesentlichen konstant ist. Wenn das der Fall ist, gibt es keinen Punkt Y in der Messung , wenn es einfacher ist , X zu messen, weil Y nicht wirklich Sie etwas sagen , Sie wissen nicht , schon von X.

— John R. Strohm

Das macht Sinn. Die Halstead-Metriken basieren auf der Anzahl der verschiedenen und der Gesamtzahl der Operatoren und Operanden. Es ist normal, dass ein längeres Programm mehr Operatoren / Operanden insgesamt und mit größerer Wahrscheinlichkeit mehr verschiedene Operatoren / Operanden aufweist. Die Metriken für Volumen und Schwierigkeit können mit SLOC anstelle von Operatoren / Operanden ermittelt werden. Hierbei werden jedoch nicht die Gültigkeit, die Anwendungen und die Bedeutung (oder die Bedeutungslosigkeit) der Messdaten für Aufwand, Zeit und Fehler berücksichtigt. Sagen diese Metriken, selbst wenn sie mit SLOC anstelle von Operatoren / Operanden berechnet werden, etwas Sinnvolles über das System aus?

— Thomas Owens

SLOC ist einfacher zu zählen und wahrscheinlich nützlicher. SLOC-Schätzungen werden von mehreren Kostenschätzungstechniken verwendet, die in PSP und TSP verfolgt werden, und können in anderen Metriken wie der Defektdichte verwendet werden. Für mich könnte das Zählen von SLOC besser sein als das Zählen von Operatoren / Operanden. Zweitens ist die Gültigkeit der Messwerte für Aufwand, Zeit und Fehler unbeantwortet, unabhängig davon, welche Messwerte verwendet werden, um sie zu berechnen. Ich bin damit einverstanden, dass die Berechnung mit SLOC möglicherweise besser ist, aber selbst wenn, würden sie irgendetwas bedeuten?

— Thomas Owens

@ThomasOwens: Wahrscheinlich nicht. Wenn Aufwand, Zeit und Fehler stark mit SLOC korrelieren, bedeutet dies, dass alle Programme einer bestimmten Größe ungefähr den gleichen Aufwand und die gleiche Anzahl von Fehlern erfordern. Die ersten beiden sind das, worauf SLOC-basierte Schätzen (z. B. COCOMO) basiert, und bedeuten, dass Wasser nass ist. Der dritte hilft dir nicht wirklich.

— John R. Strohm

Dass das Halstead-Volumen mit dem SLOC korreliert, ist interessant, aber begrenzt. Grundlegende Statistik: Die lineare Korrelation ist nicht transitiv. X korreliert mit Y, Y korreliert mit Z BEDEUTET NICHT, dass X mit Z korreliert ist.

— user1704475
quelle

Wenn X und Y lediglich korreliert sind und Y und Z lediglich korreliert sind, sind X und Z aufgrund des relativ hohen Rauschpegels in den ersten beiden Korrelationen nicht unbedingt korreliert. Wenn X und Y stark korreliert sind und Y und Z stark korreliert sind, liegt sehr, sehr wenig Rauschen vor, und es ist in jedem Fall sehr wahrscheinlich, dass X und Z korreliert sind.

— John R. Strohm