Wenn Software in die Jahre kommt

Es ist so ähnlich wie beim Menschen: Der Umfang von Software nimmt immer nur zu, nie ab. Bis schließlich niemand mehr so genau weiß, was im Inneren vor sich geht. Das Tückische ist, dass kleine Bequemlichkeiten...

Es ist so ähnlich wie beim Menschen: Der Umfang von Software nimmt immer nur zu, nie ab. Bis schließlich niemand mehr so genau weiß, was im Inneren vor sich geht. Das Tückische ist, dass kleine Bequemlichkeiten beim Projektstart später große Wartungsprobleme verursachen können. Umgekehrt bedeutet das: Ein wenig mehr Aufwand am Anfang bedeutet weniger Probleme im späteren Projektverlauf.

Unter dem Titel „Software-Erosion“ veranstaltete das Schulungsinstitut Microconsult (www.microconsult.de) eine Vortragsveranstaltung in mehreren deutschen Städten. Wenn auch der Titel die im Sinne des Veranstalters „richtigen“ Assoziationen wecken mag – zutreffend ist der Begriff eigentlich nicht. Zähne können erodieren, ein Gebirge kann es oder der Boden. Denn Erosion heißt Abtragung. Bei der Software passiert aber genau das Gegenteil. Sie wird nicht ausgehöhlt oder abgewaschen, sondern sie setzt „Speck“ an. Dass es beim Menschen genauso ist, konstatierte schon der Berliner Chansonier Otto Reutter in den zwanziger Jahren: „Und die Frau nun erst, wie sieht die später aus?/Mit den Jahren geht se ganz aus sich heraus/Wir entdecken nach ner Weile gänzlich neue Körperteile,/müssen uns, wenn wir poussier’n, immer neu erst orientier’n...“

Genau dieses „neu orientieren“ ist es, das bei Software-Projekten mit der Zeit teuer wird. Am Anfang ist alles noch ganz einfach: Es existieren Anforderungen, nach denen ein Systemdesign angefertigt wird, das dann in Form von Quellcode implementiert wird. Spätestens wenn der Auftraggeber mit der ersten Version der Software in Kontakt kommt, kommen die ersten Änderungswünsche oder Zusatzanforderungen: „Könnten Sie nicht noch schnell diese Kleinigkeit...?“ – In dieser Projektphase kein Problem. Doch so reiht sich Änderung an Änderung. Schon bald hat die Software mit der ursprünglich geplanten, „sauberen“ Architektur nicht mehr viel zu tun. Wenn dann später ein Update nötig ist, steigt der Aufwand exponentiell: Schon das Verstehen dessen, was die existierende Software tut, kann doppelt so viel Aufwand verursachen wie die ursprüngliche Entwicklung (Bild 1). Oft wird dann lieber mit einem neuen Projekt begonnen.

Doch auch ein von einem weißen Blatt Papier ausgehender Projektstart ist keine Gewähr dafür, dass eine Software klar und übersichtlich wird. Die häufigste Ursache dafür, warum Software nicht besser oder besser wartbar ist, als sie ist, liegt am Mangel von Zeit. Zeit für den Entwurf, Zeit für die Verifikation der Anforderungen, Zeit für das Testen. Schon in der Planungsphase lauern gravierende Stolpersteine. Denn eine überstürzte Planung kann dazu führen, dass die Anforderungen nicht vollständig das beschreiben, was die Software später tun soll. Statt langwierige Rückfragen an Kunden oder Auftraggeber durchzuführen, stellen die Programmierer dann an unklaren Stellen ihre eigenen Vermutungen an und implementieren das, was ihnen plausibel erscheint. Deshalb werden viele Fehler erst sehr spät gefunden, obwohl die Ursachen schon in der Anfangsphase des Projekts liegen (Bild 2).

Einfach mehr Zeit für ein Projekt zu fordern, ist eine unrealistische Lösung, denn Produkte müssen möglichst schnell auf dem Markt sein, sonst ist der Wettbewerb schneller und sichert sich Kunden und Profite. Aber ein wenig mehr Aufwand beim Projektstart bringt große Zeiteinsparungen in späteren Phasen eines Projekts und kann unterm Strich zu einer Zeitverkürzung schon bei der Erstentwicklung führen. Dabei gilt es, dem Schlendrian Einhalt zu gebieten, der sich in Form von kopierten Codesegmenten, Architekturverstößen, zyklischen Abhängigkeiten und fehlender Dokumentation einschleichen kann.