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.

Ist Software mit Null-Fehler-Qualität möglich?

Der Begriff einer Null-Fehler-Produktion wurde Anfang der 60er Jahre von Philip B. Crosby geprägt. Sowohl TQM (Total Quality Management) als auch Six Sigma sehen eine Null-Fehler-Produktion als Ziel an.

In der Softwareentwicklung würde eine Null-Fehler-Qualität (je nach Definition des Fehler-Begriffs) bedeuten, dass alle expliziten, also beispielsweise die in der Anforderungsspezifikation formulierten, und alle impliziten Anforderungen,  beispielsweise gängige Erwartungen an nicht-funktionale Eigenschaften wie die Robustheit, Usability, usw., erfüllt sind. Schon aufgrund des Umfangs und der Komplexität von Software, aber oft auch den Unschärfen einer Anforderungsspezifikation geschuldet, ist es in der Praxis mit ökonomisch vertretbarem Aufwand nicht möglich, die Fehlerfreiheit von Software nachzuweisen.

Null-Fehler-Qualität sollte jedoch als ein ideelles Ziel angesehen werden. Es geht dabei um das Qualitätsverständnis aller an der Entwicklung beteiligten Personen: Fehler an der Software dürfen nicht als „normal“ betrachtet werden, d.h. eine Fehlerrate ungleich Null ist nicht akzeptabel. Dies sollte nicht zu einer „Bestrafung“ der Verursacher führen sondern dazu, dass jeder Fehler einer Ursachenanalyse unterzogen und nach Maßnahmen gesucht wird, vergleichbare Fehler zukünftig zu vermeiden. Hierin liegt der Schlüssel zur kontinuierlichen Verbesserung aller an der Entwicklung beteiligten Bereiche, durch die man sich dem Ziel einer Null-Fehler-Qualität auf jeden Fall annähern kann.