Klassische Vorgehensmodelle
Unter den „klassischen Vorgehensmodellen“ verstehen wir detailliert ausgearbeitete Vorgehensweisen, die den Projektbeteiligten konkrete Arbeitsanweisungen an die Hand geben. Der Prozess ist dabei stark in einzelne Phasen unterteilt, welche auch u. U. mehrmals durchlaufen werden können. Die Aktivitäten innerhalb der Phasen werden bei iterativ ausgelegten Vorgehensmodellen mehrmals durchlaufen und verfeinern so die Ergebnisse. Die klassischen Vorgehensmodelle grenzen sich von den agilen Vorgehensmodellen dadurch ab, dass sie sehr „statisch“ sind und sehr genaue Vorgaben machen, wann und auf welche Weise Artefakte der Entwicklung zu erstellen sind.
Im Folgenden gehen wir auf die zwei bekanntesten Vertreter der klassischen Vorgehensmodelle ein.
V-Modell XT
Das V-Modell XT (Nachfolge-Modell des V-Modell '97) ist ein behördenspezifischer, prozessorientierter Standard für das Planen und Durchführen von Projekten, wie z. B. die Entwicklung von Hardware- und Software-Systemen. Neben dem RUP® dürfte es der mit am weitesten verbreitete Standard in Deutschland sein.
Was es zu beachten gilt:
> Das V-Modell XT ist eher generisch geschrieben, so dass es von Projekten mit den unterschiedlichsten Rahmenbedingungen (Projektgegenstand, Auftraggeber oder Auftragnehmer im Projekt, Kritikalität usw.) eingesetzt werden kann. Deshalb ist es notwendig, das V-Modell an die konkreten Bedürfnisse eines Projektes anzupassen.
> Mehr Informationen zum V-Modell XT finden Sie hier:
www.v-modell.iabg.de und hier www.v-modell-xt.de
RUP (Rational Unified Process®)
Der RUP ist ein von der Firma Rational entwickeltes, methodenabhängiges Vorgehensmodell, das sehr stark mit der UML verbunden ist. 1997 veröffentlicht, wurde der Standard seitdem kontinuierlich weiterentwickelt.
Die Hauptbereiche des Rational Unified Process stellen Phasen, Workflows und Iterationen dar. Jede der vier Phasen wird in mehreren Iterationen durchgeführt, wobei bei jeder Iteration jeder Workflow mit unterschiedlicher Intensität durchlaufen wird. Die Workflows teilen sich dabei in eine oder mehrere Einzelaktivitäten auf. Zu den Aktivitäten wiederum gibt es Detailbeschreibungen in Bezug auf die anzuwendende Vorgehensweise, beteiligte Rollen, resultierende Artefakte, SW-Module, Komponenten und Schnittstellen.
Was es zu beachten gilt:
> Der RUP behandelt nicht alle Aspekte der Softwareentwicklung gleich stark. An vielen Stellen muss sich der Anwender mit allgemeinen Aussagen zufrieden geben.
> Deckt nur den Softwareentwicklungszyklus ab und ist daher für Systeme, die mehr als Software umfassen, nicht direkt einsetzbar.
> Mehr Informationen zu RUP finden Sie hier:
http://www-306.ibm.com