Das Wasserfallmodell, und die in Deutschland Anfang der 90er Jahre erfolgte Weiterentwicklung hin zum V-Modell, versuchen den Software-Lebenszyklus umzusetzen. Der Software-Lebenszyklus wird definiert als Abfolge folgender Phasen:
Im Wasserfallmodell ist deshalb eine
Rückkoppelung zur vorherigen Phase
vorgesehen. Damit ergibt sich das klassische Bild wie in Abbildung
7 auf Seite
gezeigt. Das V-Modell wurde aus
dem Wasserfallmodell abgeleitet. Prinzipiell ist es sowohl zur
Bearbeitung von Softwareprojekten aber auch für die
Bearbeitung anderer Projekte ausgelegt. Das V-Modell entstand im Bereich der Rüstungsindustrie und die
Anwendung des V-Modell war zeitweise Voraussetzung bei der Vergabe
von Rüstungsaufträgen. Allerdings wird das V-Modell heute
nicht mehr weiterentwickelt.33
Das V-Modell, an dieser Stelle wird nur das Submodell Systementwicklung betrachtet, gliedert die Entwicklung in folgende sechs Phasen:
gezeigte Bild. Phase 4
(Modultest) überprüft das Artefakt der Phase 3
(Feinentwurf und Implementierung), Phase 5 (Systemintegration)
überprüft das Artefakt der Phase 2 (Systementwurf) und
Phase 6 (Systemabnahme) überprüft das Artefakt der Phase
1 (Anforderungsanalyse). Sollte sich bei diesen
Überprüfungen eine Unstimmigkeit ergeben, muss zur
überprüften Phase zurückgekehrt werden. Bei einem
gescheiterten Modultest ist der Rückschritt zu Phase 3 kein
größeres Problem. Wird allerdings in Phase 6 bei der
Abnahmeprüfung festgestellt, dass die Anforderungen in Phase 1
unzureichend verstanden wurden, dürfte dies in den meisten
Fällen zum Projektabbruch und damit zum Scheitern des
Projektes führen. Es ist dabei zu beachten, dass in
großen Projekten zwischen Analyse (Phase 1) und Systemabnahme
(Phase 6) durchaus mehrere Jahre liegen können.
Wasserfallmodell und V-Modell stellen einen entscheidenden Vorteil gegenüber dem ,,Code and Fix`` Vorgehen dar. Die klare Strukturierung in Phasen sowie die Festlegung der von den Phasen zu erzeugenden Outputs (Artefakte) sorgt z. B. für eine Dokumentation des Vorgehens. Weiterhin ist eine Koordinierung mehrerer Entwickler und Projektanten möglich. Als Nachteil ist die mangelnde Flexibilität anzusehen. Auf ändernde Anforderungen kann nur schlecht reagiert werden, was hohe Kosten verursacht. (vlg. ZBGK01, S. 47)