Agile Vorgehensweisen erfreuen sich zunehmender Popularität. Sie gelten als das richtige Mittel, um in einem dynamischen Umfeld qualitativ hochwertige Software zu entwickeln, die die Anforderungen der Anwender erfüllt. Traditionelle Vorgehensweisen wie das Wasserfallmodell gelten hingegen als unflexibel, "von gestern" und den Erfordernissen moderner Softwareprojekte nicht mehr gewachsen. Wir meinen allerdings, dass in traditionellen Vorgehensweisen bewährte Mechanismen zur Einhaltung von Zeit und Budget entwickelt wurden, die auch bei agilen Vorgehensweisen vorteilhafte Anwendung finden können.

Wir geben zunächst einen kurzen Überblick über die charakteristischen Eigenschaften der Vorgehensweisen nach dem Wasserfallmodell und nach Scrum. Anschließend analysieren wir anhand eines einfachen Fallbeispiels mögliche Auswirkungen der beiden Vorgehensweisen auf Zeit, Budget und Qualität in einem Projekt. Schließlich betrachten wir die möglichen Risiken detaillierter und geben Handlungsempfehlungen, wie sich diese vermindern lassen.

Wasserfallmodell: In Phasen vom Lastenheft zum fertigen Produkt

Die Umsetzung eines Projekts nach dem Wasserfallmodell erfolgt in einzelnen Phasen, wie sie in Bild 1 beispielhaft dargestellt sind. Jede Phase kann erst begonnen werden, nachdem die vorherige erfolgreich abgeschlossen wurde.

Spezifikation als Vertragsgrundlage

Zu Beginn des Projekts legen Auftraggeber und Auftragnehmer den Liefergegenstand in einer Spezifikation fest, die typischerweise Bestandteil eines Werkvertrags ist. Die gemeinsam von Auftraggeber und Auftragnehmer akzeptierte Spezifikation bietet eine gute Grundlage für die im Projekt zu erbringenden Leistungen. Der Auftragnehmer muss alle in der Spezifikation enthaltenen Anforderungen innerhalb der Vorgaben von Zeit, Budget und Qualität erfüllen.

Umsetzung: Entwurf, Realisierung, Test, Inbetriebnahme

Nachdem die Spezifikation von beiden Seiten abgenommen wurde, wird das IT-System entworfen, erst dann beginnt die Realisierung. Anschließend erfolgen Test und Installation in die Betriebsumgebung, d.h. die Inbetriebnahme. Der Auftraggeber bekommt die von ihm beauftragte Software erst sehr spät zu sehen, normalerweise in der Testphase. Dadurch kann er erst zu einem sehr späten Projektzeitpunkt erkennen, ob die gelieferte Software seinen Anforderungen entspricht.

Sind die Anforderungen in der Spezifikation hinreichend genau beschrieben und nur wenigen Änderungen unterworfen, so lassen sich Projekte nach dem Wasserfallmodell erfolgreich gemäß den Vorgaben umsetzen.

Bild 1: Schematische Darstellung des Wasserfallmodells. In der Regel erfolgt der Übergang von einer Phase in die nächste von oben nach unten. Der Weg zurück ist nur in Ausnahmefällen möglich.

Regelmäßig ergibt sich während der Projektdurchführung jedoch Änderungsbedarf an der Spezifikation. Möglicherweise wurden Anforderungen übersehen, wie z.B. die Schnittstelle zu einem anderen System. Auch kommt es vor, dass Anforderungen zu Widersprüchen führen, die erst bei der Implementierung deutlich werden: Wenn zum Beispiel für eine Benutzerinteraktion sowohl eine extrem kurze Antwortzeit als auch eine aufwendige Plausibilitätsprüfung gefordert wird. Bei der Implementierung stellt sich dann möglicherweise heraus, dass die Berechnung der Plausibilitätsprüfung so lange dauert, dass die geforderte Antwortzeit nicht eingehalten werden kann.

Durch das starre Prozessmuster sind Projekte nach dem Wasserfallmodell im Anforderungsmanagement wenig flexibel. Änderungen des Leistungsumfangs können nur über formale Änderungsanträge (Request for Change = RFC) berücksichtigt werden. Es ist nicht unüblich, dass die Änderungsrate eines durchschnittlichen Projekts ca. 25% des Gesamtumfangs der Spezifikation beträgt. Bei einem traditionellen Vorgehen ist deshalb ein entsprechender Aufwand für die Erstellung und Bearbeitung von RFCs einzuplanen.

Durch die verhältnismäßig langen Phasen und die späte Auslieferung der Software wird Änderungsbedarf oft erst sehr spät erkannt. Damit ergeben sich häufig Konflikte mit Zeit- und Budgetzielen. Möglicherweise sinkt auch die Akzeptanz der Software bei den Anwendern, wenn sich erst bei der Inbetriebnahme herausstellt, dass die umgesetzten Anforderungen nicht ihren tatsächlichen Bedürfnissen entsprechen.

Agile Software-Entwicklung: Anforderungen iterativ umsetzen