Änderungskostenkurve

Der Grund liegt in der Menge an Arbeit, die auf einer Festlegung aufbaut. Solange eine Anforderung nur im Konzept steht, betrifft eine Änderung ein Dokument. Steht sie im Entwurf, betrifft sie den Entwurf und alles, was daraus abgeleitet wurde. Ist sie umgesetzt und abgenommen, kommen Nacharbeit, erneute Prüfung, Dokumentation und Kommunikation hinzu. Die Kurve steigt deshalb nicht linear, sondern etwa exponentiell.

Die Zahlen gehen auf Barry Boehm zurück, der sie 1981 in „Software Engineering Economics" aus Projektdaten abgeleitet hat. Für klassische Vorhaben mit teurer Ausführung, etwa im Bau, im Anlagenbau oder bei Veranstaltungen, gilt der Zusammenhang unverändert. Was auf der Baustelle geändert wird, kostet ein Vielfaches dessen, was die Änderung in der Planung gekostet hätte.

In der Softwareentwicklung ist die Kurve deutlich flacher geworden. Automatisierte Tests, Continuous Integration und kleine Releases senken die Kosten einer späten Änderung erheblich. Kent Beck hat daraus die Gegenthese formuliert: Wenn die Kurve flach ist, lohnt sich frühe Festlegung nicht mehr, weil man die Entscheidung dann treffen kann, wenn man am meisten weiß.

Welche Form die Kurve annimmt, hängt damit am Vorhaben, nicht an der Methode. Sie steigt steil, wo die Ausführung teuer ist und Ergebnisse aufeinander aufbauen, etwa im Bau oder bei Migrationen. Sie bleibt flach, wo Korrekturen billig sind und sich automatisiert prüfen lassen. Der Verlauf bestimmt, in welcher Phase des Projektlebenszyklus eine Festlegung ihren Wert hat.