Wie Software auf Stand der Technik bringen?
Bei Verfehlungen des Standes der Technik ist eine nachträgliche Verbesserung potentiell extrem aufwändig: Es reicht meist nicht aus, sich ein, zwei Sprints oder Monate mit dem Aufräumen der Dinge zu befassen, die man in den Monaten oder Jahren davor eingebaut hat. Mängel in Softwarearchitektur, -Design oder auch bei den Tests können oft weder zeitnah noch ohne unerwünschte Nebeneffekte behoben werden.
Zur Abschätzung von Aufwand und Durchlaufzeit der Verbesserung hilft eine Bestandsaufnahme und Gliederung der Mängel. Eine Bestandsaufnahme der Mängel hinsichtlich des Standes der Technik sollte spätestens mit der Abnahmeprüfung erstellt worden sein, ansonsten muss man davon ausgehen, dass die Software diesbezüglich nicht geprüft wurde und ihr Einsatz grob fahrlässig wäre.
Eine Gliederung der Mängelbehebungen sollte hinsichtlich ihres Aufwandes und dem damit verbundenen Risiko gemacht weden. Jede Veränderung an einer Software trägt ja das Risiko mit sich, dass die Software danach nicht oder schlechter funktioniert als davor:
- Mängel, die relativ schnell und ohne große Risiken behebbar sind: Dazu gehört beispielsweise die Aktualisierung von Frameworks und Libraries auf aktuellse Minor- bzw. Hotfix Releases, aber auch die Aktualisierung etwaiger Dokumentation, die Entfernung unnötigen Codes und die Behebung diverser Mängel lt. statischer Codeanalyse mittels z.B. automatisierter Refactorings.
- Mängel, die aufwändiger bzw. mit größeren Risiken behebbar sind: Dazu gehört beispielsweise die Aktualisierung der Frameworks und Libraries auf aktuellste Major Releases, sowie Design-Refactorings z.B. zur Verbesserung des Designs oder Beseitigung von Zyklen und Dopplungen.
- Mängel, deren Behebung extrem aufwändig / risikoreich ist: Dazu gehört meist die Korrektur der Architektur oder auch der Austausch von Frameworks und Libraries
- Mängel, deren Behebung üblicherweise zu einer Verschlimmbesserung führt: Dazu gehört beispielsweise die "Dienst nach Vorschrift Behebung" von Mängel durch unintelligente Refactorings (z.B. "Beseitigung" von doppeltem Code durch Umordnung des Codes). Dazu gehört aber auch meist der nachträgliche Einbau von Unit-Tests, da diese zu diesem Zeitpunkt nur das Design "einfrieren" und kaum Fehler mehr finden können.
Mängel gemäß Kategorie 1 sollten immer sofort behoben werden - z.B. als Vorbedingung für eine Produktivsetzung und bedingte Abnahme.
Mängel der Kategorie 4 sollten niemals behoben werden - statt dessen sollte eine Alternative gefunden werden (z.B. Sicherstellung durch einen unabhängigen Dritten, dass Mängel intelligent behoben werden oder statt Unit-Tests nachweisliche Verbesserung der Qualität der automatisierten End2End- oder Akzeptanztests).
Mängel der Kategorie 2 und 3 sollten behoben werden, wenn sich der Produktivsetzungszeitpunkt (unter Vernachlässigung von Wünschen und Befindlichkeiten) hintanstellen lässt. Das könnte z.B. im Rahmen einer bedingten Abnahme geschehen.
Wenn aber mit der Inbetriebnahme der Software nicht gewartet werden kann, oder sich für Mängel der Kategorie 4 keine Alternativen finden lassen, so ist folgendes zu klären:
- wer kommt für die Kosten und rechtlichen Implikationen etwaiger durch die Mängel entstehender Schäden (z.B. Mehraufwand bei Weiterentwicklung, Nicht-Einhaltung der DSGVO Vorgaben) auf?
- wie wird sichergestellt, dass diese Mängel im Rahmen der Gewährleistung bzw. späteren Wartung behoben werden?
Empfohlen wird diesbezüglich immer - d.h. auch lange vor der Abnahme von Software - die Technik des Limbotanzens. Diese stellt sicher, dass die Verfehlungen des Standes der Technik ohne größere Aufwände und auch während etwaiger Fehlerbehebungen und Weiterentwicklungen sukzessive abgebaut werden. Siehe dazu den Blogpost Wie Technische Schulden ohne Aufwände abbauen.
Fazit: Software kann auch nachträglich auf Stand der Technik gebracht werden. Auch in Situationen, wo Software auf Grund ihrer diesbezüglichen Mängel nicht abgenommen werden kann, lassen sich Möglichkeiten finden, die Software dennoch in Einsatz und abzunehmen. Aufwändig, aber für alle Beteiligte meist dennoch weitaus besser als eine Rückabwicklung des Auftrags und Neustart.