next up previous contents index
Nächste Seite: 6.3.3 Iterativ inkrementelle und Aufwärts: 6.3 Vorgehensmodelle der Klassischen Vorherige Seite: 6.3.1 Vorgehensmodell ,,Code and   Inhalt   Index

6.3.2 Vorgehensmodell Wasserfallmodell und V-Modell

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:

  1. Anforderungen
  2. Analyse
  3. Entwurf (Design)
  4. Implementierung
  5. Test
  6. Inbetriebnahme
  7. Wartung
Treten neue oder geänderte Anforderungen an die Software auf, müssen diese in einem komplett neuen Zyklus umgesetzt werden. Dies ist ein sehr starres Vorgehen, welches wenig Flexibilität bietet. Kritisch wird dieses Vorgehen, wenn in einer Phase erkannt wird, dass die vorherige Phase unvollständige Ergebnisse geliefert hat. (vgl. ZBGK01, S. 45f)

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

Abbildung 7: Wasserfallmodell
Image modell

Das V-Modell, an dieser Stelle wird nur das Submodell Systementwicklung betrachtet, gliedert die Entwicklung in folgende sechs Phasen:

  1. Analyse (der Anforderungen)
  2. Systementwurf
  3. Feinentwurf und Implementierung
  4. Modultest
  5. Systemintegration
  6. Systemabnahme
Die Phasen 1 bis 3 stehen auf der linken Seite des imaginären Buchstabens ,,V``, die Phasen 4 bis 6 auf der rechten Seite. Es ergibt sich das in Abbildung 8 auf Seite [*] 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.
Abbildung 8: Schichten des V-Modell
Image vmodell

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)


next up previous contents index
Nächste Seite: 6.3.3 Iterativ inkrementelle und Aufwärts: 6.3 Vorgehensmodelle der Klassischen Vorherige Seite: 6.3.1 Vorgehensmodell ,,Code and   Inhalt   Index
Sebastian Stein 2004-08-30