Der Einfluss vernachlässigter QS auf die Produktivität

Die Produktivität eines Entwicklungsprojektes kann (kurzfristig) dadurch gesteigert werden, dass man die Qualitätssicherung vernachlässigt und eine mangelhaft getestete Anwendung in den Produktionsbetrieb übergibt. Ein Grund dafür kann Termindruck sein. Eine scheinbar positive Auswirkung: Die höhere Neuentwicklungsproduktivität gegenüber anderen Projekten mit höherem Testaufwand.

Über die Laufzeit des Entwicklungsprojektes hinaus sind die Auswirkungen jedoch:

• Eine höhere Fehlerrate gegenüber anderen Systemen
• Eine geringere Produktivität bei der Entwicklung künftiger Releases oder Inkremente, bedingt durch den hohen Aufwand für Fehleranalysen und Korrekturen

Diese Auswirkungen sind meist nicht von Dauer, da die Fehleranzahl aufgrund der nach Produktivsetzung notwendigen Anstrengungen auf ein "normales" Maß zurückgeführt werden kann. Dennoch ist dieses Vorgehen kurzsichtig, denn der Aufwand für Tests, Fehleranalysen und Korrekturen verlagert sich dabei vom Entwicklungsprojekt auf die anschließende Weiterentwicklung. Mitunter wird dabei auch Testaufwand auf die ersten Anwender eines Systems verlagert.

Das untenstehende Diagramm zeigt einen in solchen Fällen typischen Verlauf von Fehlerdichte und Produktivität nach der Produktivsetzung (Rel. 1.0). Im Gegensatz zu den Auswirkungen Technischer Schulden "erholen" sich solche Projekte über einen längeren Zeitraum betrachtet meist wieder, d.h. die Fehlerdichte wird aufgrund der inzwischen gefundenen und korrigierten Fehler sukzessive niedriger und die Produktivität aufgrund des geringer gewordenenen Korrekturaufwands wieder höher.

Verlauf von Fehlerdichte und Produktivität bei vernachlässigter QS (Beispiel)

Anzeichen vernachlässigter QS werden durch Messungen der Testabdeckung erkennbar.

Für bessere Maßnahmen zur Steigerung der Produktivität siehe Maßnahmen zur Produktivitätssteigerung.

Der Einfluss technischer Schulden auf die Produktivität

Es gibt Maßnahmen, mit denen die Produktivität von Neuentwicklungen gesteigert werden kann, die dennoch wenig empfehlenswert sind. Beispiele:

• Unvollständige Umsetzung von Anforderungen
• Aufgeschobene Korrekturen bekannter Fehler
• Vernachlässigung von Kommentierung und technischem Design
• Unzureichende oder fehlende Dokumentation
• Unzureichende Testabdeckung 
• Komplexe und daher nicht automatisierbare Build- und Deploy-Prozesse

Ein Entwicklungsprojekt, das dadurch seine Produktivität erhöht, nimmt sogenannte technische Schulden auf, die im Rahmen der späteren Weiterentwicklung mit Zinsen zurückgezahlt werden müssen. Die Zinsen beziehen sich darauf, dass

• der Aufwand für Weiterentwicklungen steigt und somit die Produktivität künftiger Releases oder Inkremente geringer wird,
• der Aufwand für Fehleranalysen und Korrekturen überdurchschnittlich hoch ist.

Die Auswirkungen technischer Schulden sind meist sehr langwierig und sehen etwa so aus, wie es das untenstehende Diagramm zeigt: Nach Abschluss der Entwicklung und Produktivsetzung der Anwendung (Rel 1.0) stellt man für die Weiterentwicklung (Releases 1.1, 1.2, usw.) eine immer schlechter werdende Produktivität fest (siehe: Messung der Produktivität in der Softwareentwicklung). Vorausgesetzt, der Aufwand für Fehleranalysen und -korrekturen geht in den Input der Produktivitätsmessungen mit ein. 

Verlauf von Fehlerdichte und Produktivität bei technischen Schulden (Beispiel)

Durch regelmäßige Codeanalysen werden viele Anzeichen technischer Schulden frühzeitig, schon während früher Phasen der Neuentwicklung, erkennbar (siehe: Regelmäßige Analyse der Codequalität mit Sonar). 

Für bessere Maßnahmen zur Steigerung der Produktivität: siehe Maßnahmen zur Produktivitätssteigerung.

Regelmäßige Analyse der Codequalität mit Sonar

Mit der Plattform Sonar können unterschiedliche Projekte einer statischen Codeanalyse unterzogen und die Ergebnisse in einer einheitlichen Form präsentiert werden. Sonar selbst verfügt über eigene Prüfregeln, ergänzt diese jedoch durch Integration zusätzlicher Analysetools wie (in der Java-Welt) FindBugs, Checkstyle oder PMD.

Die Erfahrungen mit dem Einsatz in einem großen Portfolio unterschiedlicher Anwendungen sind gut. Die für Java mehr als 800 verfügbaren Regeln sind gut beschrieben, lassen sich aktivieren und deaktivieren und können bezüglich der Schwere von Regelverletzungen (Blocker, Critical, usw.) sowie Parametern konfiguriert werden. Die Erfahrung hat gezeigt, dass es sich lohnt, nicht die Standardeinstellungen zu verwenden sondern diese Konfiguration mit erfahrenen Entwicklern durchzusprechen und eher weniger als mehr Regeln als kritisch einzustufen (Blocker). Dafür sollte im Vorgehensmodell bzw. in den Quality Gates für die Softwareentwicklung klar festgelegt sein, dass beispielsweise ein Release nicht eingesetzt werden darf, solange es Blocker enthält. Immerhin handelt es sich dabei mit hoher Wahrscheinlichkeit um potentielle Laufzeitfehler.

Zusammenfassung der Ergebnisse einer Codeanalyse mit Sonar (Beispiel)

Zusätzlich zu diesen Regeln misst Sonar die Kommentardichte, den Anteil auskommentierten oder duplizierten Codes, die zyklomatische Komplexität, den Grad des Methoden-Zusammenhalts (LCOM4) und die Klassen-Komplexität (RFC), die sich als Indikatoren für die Code-Qualität bewährt haben. Basierend auf den eigenen Programmierrichtlinien, in denen unter Anderem Richtwerte für diese Metriken festgelegt sein sollten, kann in einem Profl definiert werden, ab welchem Schwellenwert für eine Metrik die Über-/Unterschreitung in Sonar als Warning oder als Error angezeigt wird. So kann man sicherstellen, dass alle mit diesem Profil analysierten Anwendungen nach dem gleichen Maßstab gemessen werden.

Die Codeanalyse kann gut in den Build-Prozess einer Anwendungen integriert werden, so dass nach jedem neuen Build, je nach Konfiguration also beispielsweise jede Nacht oder auch kontinuierlich, auch ein neues Analyseergebnis zur Verfügung steht.

Ein Webclient stellt die Analyseergebnisse in Dashboards dar. Die Möglichkeiten zur Strukturierung auch großer Anwendungsportfolios sind sehr gut. Es stehen zahlreiche Werkzeuge zur Verfügung um beispielsweise Zeitverläufe zu analysieren oder Hotspots zu erkennen. Per Drill-down kann man jede Regelverletzung bis auf Code-Ebene verfolgen und diese, je nach Berechtigung, ggf. als „false positive“ deklarieren.

Mit einem Werkzeug wie Sonar können Programmierrichtlinien nicht nur festgelegt sondern auch überprüft werden. Und dies ohne großen Zeitaufwand und in kurzen Zyklen.

Informationen zu Sonar findet man unter http://www.sonarqube.org/ oder http://docs.codehaus.org/display/SONAR/Documentation.