Softwarequalität

Lesetipps

1. Softwaremetriken
2. pDepend – Eine kurze Einführung
3. Softwarequalität in PHP Projekten

Irgendwann muss jeder Softwareentwickler mal Rechenschaft darüber ablegen, wie gut die Qualität des Softwareprojektes ist, an dem er gerade arbeitet. Aber wie misst man Qualität bei etwas abstrakten, wie Software?
Leicht ist es garantiert nicht, aber es gibt ein paar Ansätze, die man fahren kann und zwei davon will ich heute mal kurz einreißen (weitere folgen). Ich weiß nicht, ob es die besten sind, aber sie haben zumindest mir in den letzten Jahren geholfen gute Software zu produzieren. Fangen wir also an.

1. Softwaremetriken
   Softwaremetriken gehören wohl zur ersten Wahl, will man Software in Zahlen fassen, denn genau dafür wurden sie gemacht. Die meisten Metriken können berechnet werden, ohne das man aktiv werden muss. Als Input bekommen sie den Quellcode und geben einen berechneten Wert zurück. Dieser bewertet die Qualität des Projektes. Metriken, die wir derzeit einsetzen sind zum Beispiel n-path Complexity, die McCabe Metrik (Cyclomatic Complexity) und der CRAP Index. Klingt relativ kompliziert, kann es auch sein, aber eigentlich ist es ganz einfach. Die n-path Complexity berechnet nicht mehr, als die möglichen Pfade durch eine Methode. Je höher die Anzahl ist, desto komplizierter ist die Methode. Wenn der Wert einen bestimmten Bereich übersteigt, sollte man sich die Methode noch mal genauer ansehen.
   Metriken können aber auch viel einfacher sein. Die Länge einer Funktion, genau so wie die Anzahl der Parameter, kann auch ausschlaggebend für die Qualität sein, sind also auch Metriken.
   Wenn es um Software Metriken im PHP Umfeld geht, dann kommt man nicht um Manuel Pichler rum. Er ist verantwortlich für phpUnderControl und phpDepends. Wenn ihr die zwei Projekte noch nicht kennt, dann schaut sie euch auf jeden Fall mal an. Ich kann euch versprechen, dass es sich lohnt.
2. Aufwandsverhältnisse
   Aufwände buchen ist wohl eine der nervigsten Beschäftigungen, die ein Softwareentwickler machen muss. Und das jeden verdammten Tag. Was wir gemacht haben, ist das Runterbrechen der Aufwände in drei Teile. Entwicklung, Testen und Bugfixing. Mehr mehr Aufwände in die Entwicklung gesteckt werden, desto besser ist das Projekt. Das gleiche gilt natürlich umgekehrt für das Bugfixing. Das Testen ist häufig ein Index für Komplexität der Features. Wenn man den Gewinn, den man mit dem sammeln dieser Zahlen hat erstmal sieht, ist es vielleicht nicht mehr ganz so schrecklich die Zahlen jeden Tag aufs neue einzutragen.

Ich weiss, dass es noch viele weitere messbare Faktoren gibt, ich werde auch noch in einem späteren Beitrag darauf eingehen. Für heute will ich es aber mal bei diesen belassen. Ich habe ja schließlich Morgen einen großen Tag.

3 Kommentare »

• 
  

  kb

  am 16. Februar 2009 um 08:35 Uhr

  Wie will man die Aufwandsverhältnisse konkret messen?
  Oft ist es ja so, dass man was implementiert, dass ein wenig testet und dann ans bugfixen geht. Das geht ja so ineinander über. Vor jedem Aufruf des Browsers vorher zu notieren, dass man jetzt testet, ist etwas unbequem.

  Oder meinst du das auf das Gesamtprojekt bezogen? Also die ersten Wochen wird implementiert, dann läuft der Betatest einige Tage/Wochen und dann die zu fixenden Listen abarbeiten?

• 
  

  admin

  am 16. Februar 2009 um 08:45 Uhr

  Bugfixen geht ja erst los, wenn das Produkt/Feature abgenommen wurde. Während der Entwicklung sind es ja keine Bugs, denn der Code ist noch nicht fertig. Ich will ganz bestimmt nicht, dass jeder Entwickler 3 Stoppuhren auf seinem Schreibtisch stehen hat, keine Sorge.

• 
  

  Tom Schultz

  am 16. Februar 2009 um 16:17 Uhr

  Bei der qualitativen Bewertung von Software könnte man vielleicht auch noch das vorgebene Ziel und das erreichte Ziel miteinander vergleichen. Denn leider stimmen diese beiden “Zustände” nicht immer miteinander überein.

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar