Beim "Wasserfall-Modell" werden alle Schritte, die bei einem Softwareentwicklungsprojekt erforderlich sind, nacheinander durchlaufen. Im ersten Augenblick scheint dies vernünftig und richtig zu sein, bei weiterem Nachdenken (oder Ausprobieren) stellt man jedoch fest, das es sich bei dem Wasserfall-Modell um eine Idealisierung handelt. Kein Projekt läuft wirklich so ab!

"Aber sobald mit der Umsetzung begonnen wird, zeigt sich irgendwo eine Unstimmigkeit, die sich mit der Spezifikation nicht klären lässt. Ein praktisch denkender Mensch würde jetzt vielleicht einfach den Kunden anrufen und ein paar Fragen stellen, was aber peinlich ist, wenn der Kunde bereits eine Rechnung über »1 Stck. Vollständige Leistungsbeschreibung« erhalten hat." [B4]

Erst am Ende der Entwicklung wird getestet, d.h. das wahre Ende des Projekts ist terminlich nicht vorhersehbar, weil kein Mensch ahnen kann, wie viele Fehler auftreten werden und wie lange deren Korrektur dauern wird. Dieses Modell hat Ähnlichkeiten mit einem echten Wasserfall, der das Wasser (in unserem Fall die Probleme) von Stufe zu Stufe weiter reicht und am Ende in einem See sammelt.

Das "Prototypen-Modell" heißt auch Casey-Modell, womit ein junger Entwicklungsleiter geehrt wird. Dieser kam auf die Idee, einen Prototypen zu bauen, der bereits die gesamte Funktionalität enthält, aber nicht getestet ist, keine Hilfen und keine Plausibilitätskontrollen sowie keine Fehlerbehandlung enthält, weder kommentiert noch dokumentiert ist und auch unter optischen Aspekten völlig anspruchslos ist - also noch kein Produkt ist!

Es geht ganz einfach darum, möglichst schnell ein Stück Software zu haben, das dem Kunden als Basis für weitere Diskussionen dienen kann und den Entwickler spüren lässt, wo die größten technischen Probleme verborgen sind. Ein Prototyp zeigt sehr deutlich, ob der Anbieten seinen Kunden verstanden hat und der Kunde wirklich weiß, was er will.

Heute ist das Prototypen-Modell weiter entwickelt und erzeugt evtl. sogar ein Pilotsystem, das mit den Anwendern des Kunden getestet werden kann. Parallel dazu erfolgt heute auf jeden Fall die Entwicklung des Echtsystems nach einem anderen Modell, denn der Prototyp wird halt weggeworfen (schließlich ist es ein Prototyp und kein Echtsystem!). Mehr zur Prototypen-Entwicklung in meinem Kapitel Prototyp.

Die Modelle "USDP" ("Unified Software Development Process") bzw. "RUP" ("Rational Unified Prozess") gehen auf die drei Amigos Grady Booch, Jim Rumbaugh und Ivar Jacobson von der Firma Rational Software [L7] zurück. Grady Booch ist der Papst der Objektorientierung und Ivar Jacobson der Vater der Anwendungsfälle. In Deutschland ist die Firma oose [L4] ("OOSE" = Object Orientied Software Engineering) rund um Bernd Oesterreich sehr aktiv in der Verbreitung des objektorientierten Ansatzes.

Beim USDP-Modell stelle ich gerne die Unterscheidung zwischen der Managementsicht und der technischen Sicht gemäß nebenstehendem Diagramm heraus: Die Managementsicht besteht aus Projektphasen mit Meilensteinen für Konzept, Entwurf, Konstruktion und Übergabe. Die technische Sicht besteht aus Prototypen und Produktversionen. Bei jeder Versionsstufe werden die Prozesse Anforderung, Analyse, Design, Implementierung und Test durchlaufen (iterative Vorgehensweise). Das Produkt wächst dadurch inkrementell in seinem Leistungsumfang.

Es wird dabei gerne auch vom "Lebenszyklus" des Softwareentwicklungsprojektes gesprochen (engl. "Software Development Life Cycle"). Die vier Phasen werden von Rational im RUP als "Etablierung" (engl. "Inception"), "Ausarbeitung" (engl. "Elaboration"), "Konstruktion" (engl. "Construction") und "Übergang" (engl. "Transition") bezeichnet. Wenn Sie sich am RUP orientieren, sollten Sie beachten, dass Rational ein Copyright auf den Prozess hat und die Anwendung des RUP über die Knowledge Base Lizenzgebühren kostet. Weitere Infos dazu erhalten Sie natürlich bei dem Unternehmen und in dem Dokument TP026B, Rev 11/01 ("IBM Rational Unified Process: Best Practices for Software Development Teams").

Ich meine, dass dieses Modell sehr gut um weitere Sichten (Rollen) des Projekts ergänzt werden kann, denn neben der technischen Versionssicht und der Management-Phasensicht gibt es mindestens noch eine Produktsicht, die für Marketing, QS, Training und Support relevant ist, sowie eine kaufmännische Sicht (Verträge, Zahlungen und Strafen), die für den Vertrieb sehr wichtig ist.

Sie können an der Breite der Dreiecke sehen, welche Prozesse wie intensiv iteriert werden. So reicht die Konzeptphase der Projektleitersicht beispielsweise vom Anforderungsprozess bis zum Designprozess, wobei ein Schwerpunkt auf dem Anforderungsprozess liegt. Die Version 1.0 der Marketingsicht hingegen hat ihren Schwerpunkt bei der Übergabe.

Im Prinzip war das Wasserfallmodell gar nicht so verkehrt, denn es ist sicherlich immer gut, einen Schritt nach dem anderen zu tun (auch wenn es heute modern zu sein scheint, alles auf einmal zu versuchen). Ein ganzes Software-Projekt strikt stufig durchzuführen geht aber auf jeden Fall schief. Wie ist es denn bei einem echten Wasserfall? Am Ende wird man doch nass, oder? Im Ernst: Das Problem beim Wasserfallmodell ist, dass man am Anfang noch gar nicht alle Eventualitäten abschätzen kann, während der Entwicklungszeit viele neue Änderungsanforderungen (engl.: Change Requests) eintreten und am Ende weder zeitlich (engl.: in time) noch preislich (engl.: in budget) noch qualitativ (engl.: in quality) das herauskommt, was sich der Auftraggeber vorgestellt hat. Damit ist eigentlich nur der Ärger sicher vorprogrammiert.