Mit welchen Softwaremetriken kann man Wartbarkeit messen?

Hallo,

ich arbeite gerade an einer wissenschaftlichen Projektarbeit für meine Hochschule. Meine Aufgabe ist: Ich muss für eine Programmiersprache eine geeignete Software-Metrik finden, mit der man den Quellcode auf Wartbarkeit analysieren kann. Und dann herausfinden, wie man das Ergebnis der Metrik interpretiert.

Die Programmiersprache ist eine DSL, die nur in einer einzigen Firma existiert und eingesetzt wird.

Mein Problem ist jetzt folgendes:
Die Firma hat bereits die McCabe-Metrik implementiert. Mein Chef ist aber der Meinung, dass McCabe nicht genug mit der Wartbarkeit korreliert. Ich soll jetzt z.B. sowas wie Halstead implementieren.

In meine Arbeit kann ich aber nicht einfach schreiben, dass ich Halstead nehme, sondern ich muss begründen warum und andere Metriken vergleichen.
Aber welche Metriken gibt es überhaupt, die mit Halstead vergleichbar sind?
McCabe oder LOC sind ja beispielsweise viel weniger komplex als Halstead und daher nicht direkt vergleichbar.

Meine Literaturrecherche zu dem Thema ist bisher extrem schwierig. Die Meiste Literatur, die ich finde ist Kostenpflichtig und nicht ganz billig.

(Ich habe beispielsweise in einem Buch gelesen, dass R. Watts 40 Metriken beschreibt, die sich mit Wartbarkeit beschäftigen. Das Buch von R. Watts kann ich leider nicht kostenlos ansehen.)

Ich wäre schon bereit etwas Geld für das ein oder andere Buch auszugeben. Aber ich weis ja leider nicht, wenn ich mir jetzt ein Buch kaufe, ob mir das dann wirklich einen Nutzen bringt.

Was mich auch verwirrt:
Mein Chef hat gemeint, dass Halstead gut wäre.
Jetzt gibt es Beispielsweise auch den "Maintainability-Index", der sich aus McCabe und Halstead berechnet.
Ist das jetzt eine eigene Metrik. Oder gehört das noch zu Halstead dazu?

Hat jemand ein paar Tipps für mich?

Wenn das der Maintainability-Index ist, der hier beschrieben wird, dann ist das quasi eine Meta-Metrik, die sich aus mehreren verschiedenen Metriken errechnet.

Ansonsten fällt mir auch nur noch NPath Complexity als weitere Metrik ein.

ok... dankeschön schonmal

Allein die Existenz von 40 Metriken deutet darauf hin dass es keine Universallösung gibt.
Vielleicht baut man sowas wie einen Compiler der den Code selbst zerlegt, analysiert und Rückschlüsse zieht.
So arbeitet McCabe ja auch, zählt Knoten und Kanten usw...

Aus Erfahrung sage ich mal, die Wartbarkeit ist zwischen Programmierern extrem unterschiedlich
Z.b. die Kryptiker, die versuchen 20 Zeilen in eine Zeile zu quetschen sind am schlimmsten.
Mehrere Semikolons in einer Zeile wären also schlecht. Extrem viele Klammern ebenso usw.
Im Baum heißt dies, es gibt an einem Knoten viele Kinder. Umso weniger es gäbe, umso besser (und schneller) da der Baum dann logarithmisch wäre (jedes Level halbiert den Baum), weniger Berechnungen pro Level == weniger Komplexität im Source Code = lesbarer = wartbarer.

Dann könnte man noch auf DRY prüfen, also Ähnlichkeiten im Code an verschiedenen Stellen, auch schlecht.
Viele Sprünge zu Methoden deuten eher auf einfach gehaltenen Code und Einhaltung von DRY.
Globale Variablen bekommen extra Abzüge. Die Anzahl Kommentare:Codezeilen sollte eine gesunde Ratio haben.

Den Kram kannst ja mal in Bezug zu den bekannten Metriken setzen und argumentieren wieso du es so siehst.
Am Ende wird es eine pro/kontra List mit Empfehlung auf maßgeschneiderte, bzw. selbst lernende Analyse tools

Evntl. hilft es sich mit den Optimierungsfunktionen eines C-Compilers zu beschäftigen - dieser sucht nach solchem Code nonesense und entschlackt ihn.

Allein die Existenz von 40 Metriken deutet darauf hin dass es keine Universallösung gibt.

Zum Vergrößern anklicken....

Das muss es ja auch nicht geben. Ich will ja nur die Metriken vergleichen, die es gibt und die beste für unsere Sprache auswählen.
Mein Problem... aber wie finde ich heraus, welche es gibt. Ich les nur immer wieder, dass es viele gibt. Ich finde dann aber doch immer wieder die gleichen.

Aus Erfahrung sage ich mal, die Wartbarkeit ist zwischen Programmierern extrem unterschiedlich

Zum Vergrößern anklicken....

Jop. Genau das soll ja durch die Metrik sichtbar werden.

Dann könnte man noch auf DRY prüfen, also Ähnlichkeiten im Code an verschiedenen Stellen, auch schlecht.
Viele Sprünge zu Methoden deuten eher auf einfach gehaltenen Code...

Zum Vergrößern anklicken....

Da hast zu zwar vollkommen Recht. Aber das wäre ja dann eine selbst erfundene Metrik und ich habe für die Arbeit eine stark begrenzte Zeit. Und wenn ich eine Metrik selbst entwickle, dann müsste ich ja richtig viel Arbeit rein stecken.
Beispielsweise müsste ich ermitteln welche Eigenschaften wie bewertet werden. Z.B ist eine Verletzung gegen das DRY-Prinzip schlimmer als keine Kommentare zu verwenden? Und ich muss ja nicht nur wissen welche Eigenschaften schlechter oder besser sind, sondern ich muss alles genau Quantifizieren. Und ich denke sowas sprengt meinen Rahmen total.

Oder habe ich dich falsch verstanden?

Achso, ist keine Abschlussarbeit ? Na dann...

Fehlende Kommentare sind ein K.O. Kriterium, ohne geht gar nix.
Wie du das bestimmst? Indem du es selbst ausprobierst und die Zeit stoppst
Dann gibt es noch Unit Tests, die vereinfachen auch die Wartbarkeit extrem, werden aber von den Alogrithmen nicht erfasst.

Ansonsten findet man Dinge heraus indem man sie vergleicht, kannst nicht einfach paar praktisch durchlaufen lassen ? Der Output hat sicherlich eine gewissen Schnittmenge, also Dinge die von allen Alogrithmen als schlecht bewertet werden. Dies wären dann deine Kriterien, je nachdem wie oft sie auftreten. Auf dem Papier müsstest dann grübeln was die Algorithmen mit Kante+Knoten meinen und wie diese zustande kommen (if Verzweigungen usw.). Evntl. paar davon beleuchten und auf die Alogrithmen beziehen ?

Stichworte dafür: Automatentheorie, Graphentheorie, Compilerbau

Nein... ist nur eine "halbe Bachelorarbeit"

Dass ich das durch ausprobieren herausfinden könnte ist klar.
ich wollte damit nur sagen, dass es viel Arbeit wäre und zeitlich so nicht klappt.

Ich habe 2 Monate Zeit und darf 5000 Wörter schreiben

Ich finds cool, dass man das wissenschaftlich erfassen kann, aber die beste Aussagekraft haben immer noch die Flüche und WTFs von Entwicklern. Sorry für den Offtopic, aber ich hab hier gerade 15 Jahre alten VB6-Code vor mir, der sämtliche Kriterien verletzt, die hier genannt wurden. Entsprechend hoch ist das Maß an Flüchen. Für zahlengetriebene Qualitätssicherung taugt sowas freilich nur wenig.

aber eine interessante idee....
man könnte ja von den Entwicklern den Ton aufnehmen und die Anzahl der Flüche zählen.

Jup einzig sinnvolle Metrik ist das altebekannte wtf/min
Spass beiseite: Visual Studio gibt einem als Kennzahlen folgendes:
Maintainability Index (schätze mal irgendwas von msoft)
Cyclomatic Complexity
Depth of Inheritance
Class Coupling
Lines of Code

Hoffe das hilft.

hey,

ein bisschen hilfts auf jeden Fall - danke!
aber der Maintainability Index berechnet sich aus Halstead und McCabe.
Die Cyclomatic Complexity ist doch McCabe - oder ?
Lines of Code denke ich mal, brauche ich kaum in meiner Arbeit erwähnen, das ist ja nicht wirklich mit Halstead vergleichbar.

Und Depth of Inheritance und Class Coupling sind soweit ich verstanden habe Objektorientierte Metriken.
Die Sprache, um die es geht ist aber eine Modellgetriebene DSL und nicht Objektorientiert.

Naja, Vererbungstiefe lässt sich auch ummünzen auf "Aufrufe von eigenen Methoden".
Was man sonst als Objekt schreibt, wird dann eine Funktion oder ein Struct.

Oder anders gesagt, umso weniger Sprünge man im Assembler Code hat, umso schlechter ist der Code.
Viele Sprünge vermeiden Redundanzen. Viele Referenzen auf Strings auch. Viele neu erzeugte Strings sind auch nix.