Teil 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | Kapitelauszug aus "Software-Qualität in PHP-Projekten", 2. Auflage. Erschienen im Hanser-Verlag, April 2013.
Kalkulation testbasierter Entwicklung
Der initiale Mehraufwand für das Erstellen von Tests erhöht den Aufwand. Dem gegenüber steht ein geringerer Arbeitsaufwand im Regelbetrieb – sowohl im Bereich der Wartung (also für Fehlerkorrekturen) als auch für Erweiterungen des Systems.
Risiken als Argumentationshilfe berechnen
Durch eine testbasierte Entwicklung lassen sich Risiken für bestimmte Fehlerfälle stark mi-nimieren. Dieses Wissen können Sie ebenfalls für eine betriebswirtschaftliche Betrachtung nutzen.
Die nachfolgende Betrachtung zur Risikokalkulation kann Teil des ATAM-Entscheidungs-prozesses sein – werden hier doch initiale Kosten gegen laufende Aufwände gemessen. Für die Erweiterung bestehender kleinerer Systeme oder Systeme, die sie durch marginale Anpassungen und Konfiguration eines Standardsystems erzeugen, genügt die nachfolgende einfache Kalkulation.
Betrachten Sie sowohl bekannte technische Schulden als auch bekannte Risiken. Überlegen Sie, welche konkreten Szenarien durch diese Risiken entstehen könnten. Ermitteln Sie für diese die monetären Auswirkungen. Gegebenenfalls können Sie auch eine Spalte für fachliche Folgen beziehungsweise Öffentlichkeitsarbeit einfügen. Für bestimmte Branchen ist ein direkt eingetretenes Risiko in der Auswirkung weniger fatal als die Öffentlichkeitswirkung, die sich aus diesem Fall ergibt.
Stellen Sie den technischen Schulden beziehungsweise Risiken eine Behebungsstrategie entgegen und beziffern Sie die Aufwände hierfür. Um Auswirkung und Behebung entge- genstellen zu können, ist die Umrechnung der Behebungsaufwände in Tagen in die Behebungskosten (über die durchschnittlichen Mitarbeiterkosten am Tag) notwendig. Tabelle 4 zeigt eine beispielhafte Risikoberechnung.
| Risiko | Szenario | Schaden | Behebung | Kosten |
| Login nicht unter Tests | Login für 2 Stunden nicht nutzbar → Umsatzausfall | 1.000 EUR | Login in Unit-, Int.- test aufnehmen | 400 EUR |
| Serverseitige Komprimierung JavaScript fehlt | Auslieferungzeit von mehr als 0.5 Sek. reduziert Conversi- on (2.5% → 2% pro Woche) | 15.000 EUR | Iterative Reduktion der Auslieferungs- zeit | 8.000 EUR |
Tabelle 4: Beispielhafte Risikoberechnung
Die Praxis zeigt, dass in vielen Fällen der Ausschluss eines Risikos mehrere mögliche Schadensfälle ausschließt beziehungsweise die Eintrittswahrscheinlichkeit vermindert.
Für das Software-Team ergibt sich die Möglichkeit, gemeinschaftlich mit dem Auftraggeber beziehungsweise der Auftraggeberin auszuhandeln, welcher Qualitätsanspruch für das Projekt angemessen und richtig ist.
Langsamere Entwicklung bei höherer Qualität
Für die Abschätzung der Entwicklungsaufwände wird im Folgenden eine Überschlagsrechnung angegeben. Um Unsicherheiten in der Aussage zu vermeiden, sind Nutzen und Aufwände jeweils in konservativer Schätzung (also Aufwände maximal und Nutzen im Regelbetrieb minimal) zu schätzen. Durch dieses Vorgehen sichert sich das Software-Team sich vor Aussagefehlern ab. Genauere betriebswirtschaftliche Modelle werden an dieser Stelle nicht diskutiert.
Testbasierte Entwicklung dauert länger als das „einfache“ Entwickeln von Code. Die erhaltende Code-Qualität rechtfertigt den initialen Mehraufwand, da für den Regelbetrieb weniger Fehlerkorrekturen anfallen. Die Entwickler und Entwicklerinnen werden insgesamt produktiver – selbst, wenn sie wie im untersuchten Fall Pair Programming als Methode nutzen [George 2003]:
„On average, the TDD pairs produced higher quality code. However, they took longer time, on average, to complete this work. [...] However, one must consider that all pairs turned in their programs when they felt it would run correctly. The TDD pairs did not feel they were done until they wrote higher quality code with a good set of automated test cases. The control group pairs felt they were done with lower quality code, prima- rily without any worthwhile automated test cases.“
Überprüfen Sie in Projekten, welche in Ihrem Umfeld nicht testbasiert durchgeführt wer- den, den Anteil von Fehlerkorrekturen im Regelbetrieb. Stellen Sie diese Aufwände den- jenigen gegenüber, die für die Integration von Tests in der Entwicklungsphase notwendig sind.
In vielen Projekten findet sich die Maßzahl von 50 bis 60 Prozent Arbeitsanteil, welcher für Fehlerkorrekturen – und damit nicht für Erweiterungen des Systems – genutzt wird. Diese Zahl lässt sich beim Umstieg auf testbasierte Entwicklung auf 20 Prozent reduzieren. Gleichzeitig erhöht sich der initiale Aufwand für das Projekt um 20 bis 50 Prozentpunkte. Je länger also ein Projekt im Regelbetrieb laufen wird, desto mehr lohnt sich die testbasierte Entwicklung aus betriebswirtschaftlicher Sicht.
Um die Erstellungsaufwände den Aufwänden im Regelbetrieb gegenüberzustellen, sind die Mitarbeiterkosten der Entwickler und Entwicklerinnen im Team gegenzurechnen. Sofern diese Kennzahl dem Software-Team nicht bekannt ist, sollten Sie diese in der Buchhaltung beziehungsweise im Controlling erfragen. Diese Kennzahl liegt allen Angebotskalkulationen zugrunde.
Die Forderung nach einer hohen Softwarequalität ist also kein Selbstzweck, sondern das Ergebnis einer betriebswirtschaftlichen Betrachtung. Im Umkehrschluss kann das aber auch bedeuten, dass sich zeitliche (und damit monetäre) Investition in eine hohe Testautomatisierung und -abdeckung nicht rechnet.
Mit einer betriebswirtschaftlichen Kalkulation lässt sich eine Veränderung der Teammotivation nicht messen. Es gibt hierfür einen indirekten Weg. Verminderte Arbeitsmotivati- on wird zu einem schlechteren Ergebnis, womöglich zu einer erhöhten Fluktuationsrate, führen. Die Mehraufwände, die sich durch Minderleistungen ergeben, sind schwer kalkulierbar. Die Einarbeitungskosten für neue Mitarbeiter und Mitarbeiterinnen sind dagegen bestimmbar. Mit diesem Umweg lassen sich auch Motivation und Zufriedenheit am Arbeitsplatz in betriebswirtschaftliche Zahlen übertragen.
Dieses Argument ist vorsichtig zu nutzen. Ist die Stimmung zwischen dem Software-Team, den Vorgesetzten beziehungsweise dem Auftraggeber beziehungsweise der Auftraggebe-rin gereizt, könnte das Vorrechnen von Fluktuationsraten als interne Kündigungsandrohung verstanden werden. Tritt dieses Missverständnis auf, werden bestehende Konflikte verschärft.
Automatisierungs- und Abdeckungsgrad durch Tests bestimmen
Wenn Softwarequalität als solches das Maß aller Dinge ist, ist eine maximale Automatisierung der Tests mit einer maximalen Abdeckung anzustreben. Sichert doch die maximale Abdeckung das Systems am meisten gegen Fehler ab. Dabei werden nicht nur Fehler im laufenden Betrieb vermieden, sondern gerade bei Erweiterungen und Änderungen des Systems kann das Software-Team sicherstellen, keine ungewollten Seiteneffekte auszulösen.
Im Kontext einer betriebswirtschaftlichen Betrachtung stellt sich die Frage, ob sich ein maximaler Automatisierungs- und Abdeckungsgrad im betreffenden Projekt rechnen.
Um sicherzustellen, dass die Tests maximal wirksam werden, sind als Erstes diejenigen Funktionen unter Tests zu stellen, welche einen hohen Ertrag für das Unternehmen bringen.
Damit dies dem Software-Team gelingen kann, müssen dem Software-Team die Geschäftsziele und die resultierenden Maßnahmen (das heißt das geschäftliche Wirkprinzip der Software-Funktionen) bekannt sein. Hat das Software-Team gemeinsam mit dem Auftrag- geber beziehungsweise der Auftraggeberin das architektonische und Vorgehensmodell mittels ATAM bestimmt, können alle in dieser Phase auf dieses Wissen um die Geschäfts- ziele zurückgreifen. Je stärker eine Software-Funktion beziehungsweise ein erkanntes Risiko den geschäftlichen Erfolg beeinflusst beziehungsweise beeinflussen kann, desto höher wird die Bewertung ausfallen.
Gerade komplexe, stark integrierte Software-Funktionen lassen sich nur mit einem sehr hohen Aufwand automatisiert testen. Auch sind Oberflächentests in einem Marktsegment, das einem hohen Kampagnentakt unterliegt, nur schwer zu realisieren. Gerade in diesen Fällen ist eine Kalkulation der möglichen Risiken und das Einschätzen der Erstellungs- und Wartungskosten für die Tests erforderlich. Die Entscheidung, ob und in welcher Form automatisiert getestet werden soll, erfolgt gemeinschaftlich mit dem Auftraggeber bezie- hungsweise der Auftraggeberin. Teil dieser Entscheidung ist es auch festzulegen, an welchen Stellen auf automatisierte Tests zugunsten von manuellen Tests (in zu definierender Form) verzichtet werden kann.
Quellenhinweise
[George2003]
An initial investigation oft estdriven development industry, BobyGeorge and Laurie Williams, Proceedings of the 2003 ACM symposium on Applied Computing, Pages: 1135–1139, ISBN 1-58113-624-2
Kommentar schreiben