Wartung von Software

Laut Statistik (z.B. SWEBOK – Software Engineering Body of Knowledge) fliessen 70-90% der Lebenszykluskosten von Software in die Wartung. Und 40-60% des Wartungsaufwands wird dafür benötigt, die Software, die geändert werden soll, überhaupt zu verstehen. Über 80% der Wartungskosten werden nicht für Fehlerkorrektur, sondern für Erweiterungen und Verbesserungen aufgewendet.

Wir „Softwerker“ verbringen anscheinend den größten Teil unseres beruflichen Lebens in Wartungsprojeken. Warum findet man dann so wenig nützliche Informationen zu diesem Thema? Und vor allem dann, wenn man auch noch agil unterwegs ist.

Ich möchte in dieser Serie einige Fragen aus diesem Bereich aufgreifen, Informationen teilen, die mir nützlich erscheinen, Erfahrungen weitergeben und auch gerne Feedback und Erfahrungen der Leser aufgreifen.

Eine Qualitätsanforderung bei der Entwicklung einer neuen Software lautet oft:

Die neue Software muss leicht wartbar sein.

Wie oft haben Sie schon eine Ableitung dieser Anforderung gesehen? – Eben.

Und weiter: Wie oft haben Sie z.B. User Stories gesehen, die sich mit der Implementierung und Qualitätssicherung dieser abgeleiteten Anforderungen befassen? Was bedeutet das Ganze für die Nachverfolgbarkeit?

Aktuelle und gültige Anforderungen, eine aktuelle Design-Spezifikation, das Ganze untereinander verlinkt und auch noch mit dem Code, das würde den Wartungsentwicklern die Arbeit wahrscheinlich erheblich erleichtern. Nur, wie oft findet man eine solche Situation vor? Und das im agilen Umfeld? Die Wahrheit ist und bleibt wohl eher der Code. Um leicht wartbare Software zu bekommen, müssen wir zunächst einmal leicht wartbaren Code schreiben. Und das ist durchaus möglich.

Roedy Green gibt auf der Seite (How to write unmaintainable code)

http://www.thc.org/root/phun/unmaintain.html

eine Fülle von Tips, wie man unwartbaren Code schreiben kann. Solche Antipatterns sind meist sehr lehrreich und in diesem Fall auch noch recht unterhaltsam.