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
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:
- Anforderungen
- Analyse
- Entwurf (Design)
- Implementierung
- Test
- Inbetriebnahme
- 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
|
Das V-Modell, an dieser Stelle wird nur das Submodell
Systementwicklung betrachtet, gliedert die Entwicklung in folgende
sechs Phasen:
- Analyse (der Anforderungen)
- Systementwurf
- Feinentwurf und Implementierung
- Modultest
- Systemintegration
- 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
|
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)
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