Software-Weiterentwicklung: ein laufendes Produkt planbar ausbauen

Software-Weiterentwicklung bezeichnet den planmäßigen Ausbau eines Programms, das bereits im Betrieb steht und Anwender hat. Sie unterscheidet sich von einer Neuentwicklung durch drei Bedingungen: bestehende Daten, laufende Abläufe und ein vorhandenes Verhalten, das erhalten bleiben muss. Jede Änderung wird deshalb nicht nur gebaut, sondern auch gegen den Bestand geprüft.

Software-Weiterentwicklung: Abgrenzung zur Neuentwicklung

Bei einer Neuentwicklung ist das Blatt leer: Architektur, Datenmodell und Bedienung entstehen zusammen, der erste Anwender kommt später. Beim Ausbau eines Programms, das schon arbeitet, ist die Reihenfolge umgekehrt. Das Datenmodell steht, Schnittstellen hängen an fremden Systemen, und in der Datenbank liegen Sätze aus vielen Jahren, die keine Annahme des ursprünglichen Entwurfs mehr erfüllen müssen.

Daraus folgt ein anderer Aufwand je Funktion. Ein Teil der Arbeit geht in das Lesen des vorhandenen Codes, ein weiterer in die Frage, was eine Änderung an anderer Stelle auslöst. Wer den Aufwand einer Neuentwicklung als Maßstab nimmt, schätzt regelmäßig zu niedrig — nicht wegen der neuen Funktion, sondern wegen der Rücksicht auf alles, was daneben weiterlaufen muss.

Abzugrenzen ist der Ausbau von der reinen Wartung. Wartung hält einen Zustand: Fehler werden behoben, Abhängigkeiten aktuell gehalten, Störungen beseitigt. Weiterentwicklung verändert den Funktionsumfang und damit das, was Anwender im Alltag tun können. Beides in einen Topf zu werfen, macht die Planung unbrauchbar, weil der eine Teil vorhersagbar ist und der andere nicht.

Wie die Arbeit am laufenden Produkt aussieht

Am Anfang steht eine Aufnahme des betroffenen Bereichs: Welche Abläufe hängen daran, welche Systeme lesen dort mit, welche Auswertungen bauen auf diesen Daten auf. Diese Aufnahme ist keine Formalie, sie entscheidet über die Größenordnung. Dieselbe Anforderung kann eine kleine Ergänzung sein oder ein eigenes Vorhaben mit Datenumzug, je nachdem, was unter der Oberfläche daran hängt.

Danach läuft die Arbeit in kurzen Runden, von denen jede für sich in Betrieb gehen kann. Dazu gehören ein Weg zurück, wenn etwas nicht trägt, und die Möglichkeit, eine neue Funktion zunächst nur für einen kleinen Nutzerkreis einzuschalten. Der Bestand bleibt dabei die ganze Zeit benutzbar; eine Umstellung, die einen Stillstand verlangt, wird als eigene Etappe geplant und nicht nebenbei erledigt.

Ein dritter Punkt ist die Zusammenarbeit zweier Gruppen an derselben Codebasis. Zweigstrategie, Prüfung von Änderungen und eine gemeinsame Vorstellung davon, wann etwas fertig ist, gehören in die Vereinbarung, bevor die erste Zeile geschrieben wird. Ohne das entstehen zwei Baustellen, die sich gegenseitig aufhalten.

Ausbauen oder ersetzen: die Entscheidung am einzelnen Baustein

Die Frage „weiterbauen oder neu schreiben“ wird selten für ein ganzes System sinnvoll beantwortet, sondern für einen Baustein: ein Modul, eine Schnittstelle, eine Berechnung. Fünf Kriterien tragen die Entscheidung:

• Änderungsdruck: Wie oft kommen Anforderungen an genau diesen Bereich? Was jahrelang unberührt bleibt, muss nicht schön sein.
• Verständnis der Fachregeln: Kann jemand erklären, warum eine Berechnung so aussieht, wie sie aussieht? Ohne diese Antwort ist ein Ersatz ein Ratespiel mit offenem Ausgang.
• Prüfbarkeit: Hält irgendetwas das heutige Verhalten fest — Tests, Protokolle, vergleichbare Auswertungen?
• Außenkante: Lässt sich die Schnittstelle nach außen stabil halten, während innen umgebaut wird? Dann ist ein Ersatz unauffällig möglich.
• Betriebsrisiko: Was passiert im Haus, wenn dieser Bereich einen Tag lang falsch rechnet?

Fällt die Entscheidung für einen Ersatz, ist auch er eine Lieferung mit eigenem Umfang und eigener Prüfung, kein Nebeneffekt. Und er wird erst dann sinnvoll, wenn das alte Verhalten beschrieben ist: Ein Nachbau ohne Leistungsbeschreibung übernimmt alte Fehler oder verliert stillschweigend Funktionen, die jemand täglich benutzt.

Software-Weiterentwicklung in abnehmbare Etappen schneiden

Ein guter Schnitt erzeugt Stücke, die einzeln einen Nutzen haben, einzeln in Betrieb gehen und einzeln geprüft werden können. Praktisch heißt das: Jede Etappe hat eine eigene Beschreibung, eigene Kriterien für die Abnahme und einen Zeitpunkt, an dem sie den Anwendern zur Verfügung steht. Ein Stück, das erst am Ende zusammen mit allen anderen funktioniert, ist kein Stück, sondern eine Rate.

Der Schnitt entscheidet auch über die Verteilung des Risikos. Bereiche, die gut beschrieben und durch Tests abgesichert sind, lassen sich mit festem Preis vereinbaren; Bereiche, deren Zustand niemand kennt, beginnen mit einer Aufnahme und werden danach neu bewertet. Diese Reihenfolge ist der Unterschied zwischen einer Schätzung und einer Zahl, die jemand erraten hat.

Typische Fehler

• Der große Wurf ohne Zwischenstand. Ein Umbau, der erst am Schluss sichtbar wird, entzieht dem Auftraggeber die Kontrolle über Richtung und Kosten.
• Schätzen vor dem Lesen. Eine Zahl vor der Aufnahme des Bestands beschreibt die Hoffnung des Anbieters, nicht den Aufwand.
• Kein Netz. Wird auf Testautomatisierung verzichtet, weil sie im Angebot wie ein Zusatzposten aussieht, zahlt der Auftraggeber sie später in Form von Störungen im Tagesgeschäft.
• Dokumentation als Nacharbeit. Was am Ende übrig bleibt, wird nicht geschrieben; technische Dokumentation gehört in den Umfang jeder Etappe.
• Fertig ohne Maßstab. Ohne vorher vereinbarte Kriterien wird die Prüfung zur Geschmacksfrage, und der Streit beginnt bei der Rechnung.

Wie wir ein bestehendes Produkt weiterentwickeln

Kreidepfad Software kommt als zweite Mannschaft an vorhandenen Code. Wir beginnen mit der Aufnahme des betroffenen Bereichs, schneiden die Arbeit anschließend in Etappen, deren Kriterien für die Abnahme im Angebot stehen, und liefern in Stücken, die einzeln in Betrieb gehen. Repository und Zugänge bleiben beim Auftraggeber, fachliche Fragen laufen über unsere Projektleitung, und mit vollständiger Bezahlung gehen die Nutzungsrechte am eigens erstellten Code auf den Auftraggeber über. Wie wir den Zuschnitt einer solchen Softwareentwicklung am Bestand aufsetzen, steht auf der Leistungsseite.