Vorgehensmodelle dienen dem Projektleiter als Leitgerüst und Orientierung für die Planung und Durchführung eines Projekts. Dabei bietet das inkrementorientierte Vorgehensmodell als Kernelement der so genannten "agilen Methoden" handfeste Entwicklungsvorteile (Reinhard P. Oechtering, "Best Practice im Projektmanagement"). Allerdings zeigen Umfragen, dass das Wasserfallmodell als prominenter Vertreter der sequenziellen Vorgehensweise immer noch eine dominante Stellung unter den Vorgehensmodellen einnimmt (Colin J. Neill, Phillip A. Laplante).
Dieser Artikel beschäftigt sich ausführlich mit der risikoreduzierenden Wirkung inkrementorientierter Vorgehensweisen. Den Ausgangspunkt bilden die von Capers Jones empirisch ermittelten Daten zur Abbruchquote von Softwareentwicklungsprojekten in Abhängigkeit vom Leistungsumfang - die mit meiner eigenen Erfahrung übereinstimmen. Im weiteren geht der Artikel dem "Scheinargument" der mangelnden Planungssicherheit auf den Grund, das immer wieder gegen die inkrementorientierten Vorgehensweise vorgebracht wird.
Um die grundsätzlichen Unterschiede zwischen dem Wasserfallmodell als dem prominentesten Vertreter der sequenziellen Vorgehensmodelle und dem inkrementorientierten Vorgehensmodell besser zu verstehen, werden die beiden Ansätze im Folgenden einander kurz gegenübergestellt.
Das Wasserfallmodell zeichnet sich dadurch aus, dass gleiche Aktivitäten in einer Phase zusammengefasst sind und möglichst in voller Breite durchgeführt werden. Die Phasen werden sequenziell, also strikt nacheinander abgewickelt und die Ergebnisse schriftlich dokumentiert. Man spricht deshalb auch von einem dokument- bzw. spezifikationsgetriebenen Vorgehensmodell. Jede Phase soll möglichst nur einmal durchlaufen werden, etwaige Rückkopplungen sind auf die unmittelbar benachbarte Phase zu beschränken. Das wesentliche Merkmal ist aber, dass die eigentliche Programmierung und der Test entsprechend der Philosophie der schrittweisen Verfeinerung zeitlich erst am Ende des Konstruktionsprozesses angesiedelt sind. Dies führt dazu, dass ein hoher Aufwand für die Korrekturen der Fehler aus vorgelagerten Phasen getrieben werden muss. Ein weiterer schwerwiegender Nachteil liegt darin, dass das Finalziel zu Beginn des Entwicklungsprozesses möglichst vollständig und für alle Beteiligten eindeutig spezifiziert werden muss - für größere Projekte ein nahezu unmögliches Unterfangen.
Bild 1: Das Wasserfallmodell.
Die inkrementale Entwicklung von Software eignet sich besonders, wenn die zukünftigen Anwender nicht genau spezifizierbare Vorstellungen über die Funktionalität des Endprodukts (Finalziel) haben. Die folgende Aussage mag das illustrieren: "Ich kann Ihnen nicht genau sagen, was ich benötige, aber wenn ich es sehe, dann weiß ich es". Man sollte sich allerdings davor hüten, dies generell dem Unvermögen der Anwender zuzuschreiben, denn gerade wenn kreative Akte gefordert sind, hat selbst der Spezialist selten eine konkrete Anforderungsspezifikation vor Augen bzw. in der Hinterhand.
Die inkrementorientierte Vorgehensweise zielt darauf ab, dem Anwender sehr früh im Entwicklungszyklus lauffähige Versionen für den Test bereitzustellen. Damit muss keine Produktionsübergabe verbunden sein. Der Vorteil ist, dass der Anwender seine Vorstellung über das Produkt (typische Inkrementdauern liegen je nach Projekttyp zwischen ein und sechs Monaten) anhand eines ersten lauffähigen Inkrements überprüfen kann. Aufgrund seiner konkreten Erfahrung, die er beim Test des ersten Inkrements gewinnt, wird in Absprache mit dem Entwicklungsteam die Funktionalität des nächsten Inkrements geplant. Zusätzlich besteht nach jeder Inkrementfertigstellung die Möglichkeit, Änderungen des Umfelds oder der hauseigenen Strategie in die Planung für das nächste Inkrement aufzunehmen.
Ein weiterer unbestrittener Vorteil der Methode ist, dass vermutete technische Risiken zusammen mit den Anwenderfunktionen in den ersten Inkrementen adressiert werden können, um die unangenehme Überraschung zu vermeiden, dass man am Ende eines langen Konzeptionswegs vor unüberwindlichen technischen Problemen steht und die ganze Investition abgeschrieben werden muss. Ein Problem des rein inkrementalen Vorgehens tritt dann auf, wenn die Softwarearchitektur mit der Weiterentwicklung nicht Schritt halten kann und eine komplette Überarbeitung der bis zu diesem Zeitpunkt erstellten Inkremente notwendig wird. In diesem Fall haben die bisher erstellten Inkremente den Status eines Wegwerfprototyps, der allerdings den großen Vorteil hat, dass er die verifizierten und sehr wahrscheinlich auch die validierten, funktionalen Anforderungen auf dem konkretesten aller möglichen Level enthält.
Bild 2: Das inkrementorientierte Modell.
…
