Vorgehensmodelle

Vorgehensmodelle (engl. life cycle models) dienen zur Benennung und Ordnung von Aktivitäten bei der Software-Entwicklung. Eine umfassende Diskussion findet sich beispielsweise in [McDermid 91] und in [Pomberger 04]. In der wissenschaftlichen Diskussion werden oft deskriptive Modelle vorgestellt, die sich mit den verschiedenen Aktivitäten (z.B. Codieren, Dokumentieren, Testen) und ihren logischen Bezügen befassen. Wesentlich verbreiteter und in der Praxis genutzt werden normative Modelle, die Handlungs- und Organisationsrichtlinien für die Projektarbeit vorgeben.

Phasenmodelle

Traditionell besteht ein Vorgehensmodell aus sogenannten Phasen, in denen im Wesentlichen eine Projektaktivität bis zu einem vordefinierten Ergebnis verfolgt wird. Die Anordnung der Phasen ist üblicherweise sequentiell, d.h. zeitlich folgt eine Phase auf die andere. Im Folgenden wird auf einige phasenorientierten Vorgehensmodelle näher eingegangen.

Wasserfallmodell. Das in Bild 1 illustrierte Wasserfallmodell ([Royce 70] populär gemacht durch [Boehm 76]) war historisch das erste sequentielle Vorgehensmodell für die Software-Entwicklung. Es prägt heute noch das Denken vieler Softwareentwickler und -manager. Die zahlreichen Variationen fordern benannte und standardisierte Entwicklungsschritte, die nacheinander durchlaufen werden sollen. Diese führen zu einer Menge von Dokumenten (sogenannte Meilensteindokumente), die in der Form möglichst festgelegt sind. Rückgriffe auf vorangegangene Phasen sind zwar erlaubt und in der Praxis die Regel. Aber diese Rückgriffe werden als Fehler und Unzulänglichkeiten betrachtet, die bei optimalem Projektverlauf nicht nötig wären und damit minimiert werden sollen.

Bild 1: Wasserfall-Modell mit typischer Phasenauslegung

Wasserfallmodelle werden heute weitgehend kritisch betrachtet. Trotz ihrer weiten Verbreitung wird die Bedeutung von Phasenmodellen für die wissenschaftliche Behandlung und die betriebliche Praxis nicht einheitlich gesehen. Während sie als logisches Verständnismodell weiterhin anerkannt sind, werden für eine praxisgerechte Organisation von Softwareprojekten inzwischen Alternativen vorgeschlagen.

Spiralmodell. Die Weiterentwicklung des Phasenmodells durch das flexiblere Spiralmodell [Boehm 88] bietet auch benannte und standardisierte Entwicklungsschritte. Diese werden jedoch in einem zyklisch angeordneten Prozeß mehrfach durchlaufen, bis das Produkt fertig gestellt ist (siehe Bild 2).

Das Spiralmodell berücksichtigt, daß Anforderungen schwer vorweg zu ermitteln sind, und daß der Software-Entwicklungsprozeß zu neuen Einsichten führt. Ziel ist wie beim Wasserfallmodell ein fest vorgegebenes Produkt. Die verschiedenen softwaretechnisch ausgerichteten Tätigkeiten werden nacheinander und nicht parallel erledigt. Die Trennung von Herstellung und Einsatz bzw. Wartung bleibt erhalten, Versionen werden nur während der Herstellung berücksichtigt.

Iterativ zyklische Modelle

Bei iterativ zyklischen Modellen wird Software nicht mehr als ein Produkt im klassischen Sinne, sondern als eine Folge von Versionen verstanden (siehe Bild 3 in Anlehnung an [Floyd 89]).

Anwendungsorientierte Modelle

In jüngster Zeit werden vielfach anwendungsorientierte Vorgehensmodelle als Ausprägung von zyklisch iterativen Vorgehensmodellen vorgeschlagen (z.B. [Züllighoven 04]).

Rational Unified Process und Unified Process

Der Autorenkreis der UML [Booch 02] hat neben den Darstellungsformen und Modellierungstechniken der UML auch eine dazu passende Vorgehensweise vorgeschlagen. Die generelle und in der wissenschaftlichen Diskussion meist behandelte Version dieser Vorgehensweise wird UP – Unified Process [Booch 02] genannt. Die von der Firma Rational vertriebene, wesentlich differenziertere und werkzeuggestützte Version heißt Rational Unified Process (RUP) – sie wird von vielen Unternehmen eingesetzt.

UP/RUP ist in Zyklen und Iterationen aufgeteilt (siehe Bild 4).

Seit Ende der 1990er Jahre haben UP/RUP ihren festen Platz in der Methodendiskussion um Vorgehensmodelle. Die vielfältige Werkzeugunterstützung und die detaillierte Ausarbeitung haben die Akzeptanz dieser Vorgehensweise in der Praxis unterstützt. Besonders UP ist so allgemein, daß es unterschiedliche Interpretationen gibt, von denen sich die einen eher einem schwergewichtigen Wasserfallmodell annähern, während andere die Prinzipien agiler Methoden integrieren.

Agile Vorgehensweisen

Alternativ zu den schwergewichtigen Vorgehensweisen werden leichtgewichtige oder agile Vorgehensweisen vorgeschlagen. Neben dem bis heute bekanntesten Vertreter, dem eXtreme Programming, gehören dazu z.B. SCRUM und Chrystal [Martin 02], [Larman 03].

Agilen Vorgehensweisen ist gemeinsam, daß sie ein gebrauchstaugliches Softwaresystem und seine anwendungsorientierte Konstruktion in den Vordergrund stellen sowie weitestgehend auf alle zusätzlichen Managementdokumente und technischen Modelle verzichten.

Agile Vorgehensweisen wurden zunächst für kleine Anwendungsprojekte eingesetzt. Seit Anfang des neuen Jahrhunderts werden aus der Praxis und der wissenschaftlichen Methodendiskussion Vorschläge für den Einsatz in großen Projekten gemacht. Es bleibt abzuwarten, ob agile Methoden ihren Platz neben schwergewichtigen Vorgehensweisen wie UP/RUP behaupten oder ob sich eine Konvergenz zeigen wird.

Evolutionäre und Prototyping-orientierte Modelle

Alle iterativ zyklischen Vorgehensweisen und Methoden orientieren sich am evolutionären Charakter von Software: daher muß Software-Entwicklung mit Änderungen sinnvoll umgehen können. Das wechselseitige Lernen zwischen Entwicklern und Anwendern muß methodisch unterstützt, Veränderungen im technischen und im Einsatzkontext berücksichtigt, und letztlich müssen die durch den Einsatz des Systems motivierten neuen Anforderungen aufgegriffen werden.

Der eigentliche Entwicklungsprozeß wird deshalb unabhängig von seiner methodischen Ausrichtung häufig prototypinggestützt durchgeführt.

Prototyping ist ein Verfahren bei der Software-Entwicklung, bei dem Prototypen entworfen, konstruiert, bewertet und revidiert werden [Budde 92]. Prototyping schafft eine Kommunikationsbasis für alle beteiligten Gruppen, vermittelt experimentelle und praktische Erfahrungen für die Auswahl zwischen Designalternativen und ist eine dynamische Beschreibung des sich entwickelnden Softwaresystems. Die folgende Einteilung des Prototyping von [Floyd 84] hat sich durchgesetzt:

Exploratives Prototyping soll helfen, die Problemstellung aus Anwendersicht zu klären. Experimentelles Prototyping unterstützt die konstruktive Umsetzung der Anforderungen an ein System, indem Risiken des Projektes durch entsprechende Prototypen untersucht und damit vermindert werden. Evolutionäres Prototyping ist Teil eines kontinuierlichen Verfahrens, in dem Anwendungssoftware schrittweise entwickelt und innerhalb einer Organisation an die sich ändernden Randbedingungen angepaßt wird.