Software-Evolution

Es gibt noch eine weitere Phase zwischen Development und Maintenance: die „Software-Evolution“. Zwar haben sich die Begriffe des Developments und der Maintenance bereits in den Siebzigerjahren etabliert, jedoch täuschen sie darüber hinweg, dass sich damals herausstellte, dass sie nicht ausreichen, um die Besonderheiten zu beschreiben, die sich daraus ergeben, wenn Software bereits genutzt wird, obwohl ihre Entwicklung noch nicht abgeschlossen ist.

Selbst wenn also beispielsweise eine Lohnabrechnungs-Software über alle Merkmale wie automatisiertes Umsetzen von Arbeitsprozessen, Datenexporte, Validierungen und Datenspeicherung verfügt, so muss sie angepasst werden, sobald gesetzliche Regelungen geändert werden. Geschieht das nicht, arbeitet sie falsch. Wenn dies also nicht als Wartung bezeichnet werden kann, ist es dann mit der reinen Entwicklung gleichzusetzen? Im Alltag wäre diese Frage höchstwahrscheinlich mit Ja zu beantworten, weil wir tatsächlich meist unbewusst die Phasen der reinen Entwicklung und die der Evolution miteinander vermischen.

Tatsächlich sind Entwickler im Development-Prozess so lange sicher, wie ihr Produkt noch nicht ausserhalb des Teams verwendet wird. Unter diesen Laborbedingungen muss weder auf Breaking Changes geachtet werden noch sind Hot­fixes zu erstellen, um kritische Laufzeitfehler zu beseitigen. Das Team kann seinem Zeitplan folgen und ist fast frei von unangenehmen externen Einflüssen. In dem Moment, in dem das System jedoch veröffentlicht wird, muss es sich in der realen Welt behaupten. Dann ist plötzlich darauf zu achten, wie die Software bisher verwendet wurde. Sie wird mit tatsächlichen Arbeitsabläufen konfrontiert, und dies kann nicht nur zu Fehlern, sondern auch zu Änderungen bei den Anforderungen, also Change Requests, führen. Wie wichtig dabei die Priorisierung und Definition von Fehlern, Anforderungsänderungen und Merkmalen ist, zeigt sich in den Gerichtsprozessen, die sich nur um die Frage drehen, welche Schadenssummen sich ergeben, weil ein Zulieferer vermeintlich nicht adäquat auf ein gemeldetes Fehlverhalten reagiert hat.

Software entwickelt sich nach dem ersten Release evolutio­när entlang den tatsächlichen Gegebenheiten. Über die Jahre hinweg nimmt der Anteil der Umsetzung von Merkmalen und Funktionen immer weniger Raum ein. Damit sinkt die wertsteigernde Arbeit und wird durch werterhaltende Tätigkeiten wie Stabilisierung, Optimierung und sogar Sanierungen ersetzt. Je nachdem wie geordnet der Entwicklungsprozess auch nach einem Release noch verläuft, ergibt sich da­raus, wie stabil die internen Strukturen der Software sind und wie schnell sich diese an neue Gegebenheiten anpassen kann. Darüber hinaus steigen aber auch die fixen Betriebskosten im Vergleich zu den laufenden Entwicklungskosten. Die Unterscheidung zwischen der Entwicklungs- und der Evolutionsphase ist daher gerade aus Sicht der Kosten sehr wichtig. Während die Entwicklung am Anfang gern als einmaliger Kostenblock angesehen wird, sind die Kosten des Betriebs schlecht einzuschätzen. Das Bereitstellen von Servern, ein Support, der Kundenanfragen bearbeitet, das Vorhalten von Entwicklerkapazitäten, um kritische Fehler zu beseitigen, und Ähnliches können sich auf Dauer zu einem weitaus grösseren Posten entwickeln, als es die ursprüngliche Entwicklung war.

An dieser Stelle lassen sich dann auch nur schwer Einsparungen gegenüber der Entwicklung erzielen. Während sich ein Entwicklungsprojekt im schlimmsten Fall stoppen lässt und sich die Kosten somit schlagartig verringern, bedeutet der Stopp während der Evolutionsphase einen Close Down mit all seinen Folgen. Das heisst: Mit dem Übergang von der Entwicklungsphase hin zur Evolution geht der Betreiber Verpflichtungen ein, denen er zumindest zeitweise noch folgen muss, selbst wenn es sich finanziell eigentlich schon nicht mehr rechnet.

Wenn die Phase der Software-Evolution so bedeutend ist und ihre Definition nun schon über vierzig Jahre zurückliegt, wie kommt es, dass sie so unbekannt ist? Einer der Hauptgründe dafür liegt wahrscheinlich in einer besonderen Ausprägung der Theorien hinter der Software-Evolution: der agilen Software-Entwicklung. Scrum, Kanban und andere Methodiken bewirken, dass sich Entwickler den besonderen Gegebenheiten nach einem Software-Release aktiv stellen, indem man sie durch die direkte Beteiligung der Fachbereiche möglichst früh herausfordert.

Gerade das iterativ inkrementelle Vorgehen von Scrum-Teams spiegelt einen zentralen Gedanken der Software-Evolution wider. Die Idee dahinter ist, dass am Ende jeder Iteration ein Inkrement der Software steht, das theoretisch auch produktiv eingesetzt werden könnte. Während der Iterationen durchläuft die Software eine Form der Evolution, die kontinuierlich überwacht wird. Mutiert sie bei diesem Prozess in eine ungewollte Richtung, kann dieser Mutation entgegengewirkt werden, bevor sie sich schädlich auswirkt.