Vorgehensmodelle und Standards

Ein Vorgehensmodell gibt einen Rahmen fü r die Systementwicklung vor, an dem Sie sich orientieren kö nnen. Es definiert, welche Rollen welche Aktivitä ten durchfü hren, in welcher Reihenfolge die Bearbeitung geschehen kann und welche Artefakte Sie dabei erstellen. Das Ziel eines Vorgehensmodells ist es7dieTQualitiU? des entstehenden Systems durch eine gut durchdachte Systementwicklung sicherzustellen. Wie viele Vorgaben ein Vorgehensmodell macht und wie einfach Sie es an Ihre Situation anpassen kö nnen, unterscheidet sich je nach Art des Vorgehensmodells erheblich.

„In den 90er Jahren begannen wir, unsere Vorgehensmodelle zu perfektionieren. Wirwollten nicht nur jeden einzelnen Schritt perfekt machen, sondern auch noch den | Gesamtablauf genau vorhersagen kö nnen. [...] Das ist Vorgehen in der Tradition von 'y CMM und ISO-9000: 2000. [...] Einige Firmen waren erfolgreicher als andere in der Perfektionierung ihrer Vorgehensmodelle. Aber eigenartigerweise waren die Firmen, die es am besten schafften, nicht immer die erfolgreichsten am Markt. In unseren turbulenten Zeiten wurden meist nicht die Firmen belohnt, die ihre Vorgehensweise perfektioniert haben, sondern die, die sich am schnellsten anpassen konnten. Jeden Schritt vorhersagen zu kö nnen, ist wirklich nicht wichtig, wenn wir gar nicht wissen, wohin der Weg uns * fü hrt und was uns unterwegs begegnet."

Tom DeMarco im Vorwort zu [HruschkaO2]

Wir werden in diesem Abschnitt die Bandbreite der Vorgehensmodelle anhand des RUP, des V-Modells XT und der agilen Vorgehensweisen vorstellen. In diesem Modellen werden die benö tigten Entwicklungstä tigkeiten mit ihren Ein- und Ausgabeartefakten definiert. Es wer den jedoch k eine Aussagen darü ber gemacht, wann und fü r welchen Teil der Aufgaben­stellung ein Entwicklungsschritt durchgefü hrt werden soll. Fü r diese Festlegung existieren zahlreiche Alternativen. Drei der wichtigsten, prinzipiell unterschiedlichen Vorgehensweisen sind: Sie kö nnen Ihre Aufgabenstellung iterativ-inkrementell, wasserfallartig oder anwendungsfallgetrieben bearbeiten.

Bei iterativ-inkrementellem Vorgehen wird die gesamte Systementwicklung in zeitliche Ab­schnitte unterteilt (Iterationen) und das System in Teilen (Inkrementen) realisiert, die einen Zuwachs an Funktionalitä t bilden. Da gleiche Aktivitä ten fü r jedes Inkrement wiederholt durchlaufen werden, kö nnen gewonnene Erfahrungen direkt in die Entwicklung eingebracht werden. Bereits umgesetzte Funktionalitä t steht dem Anwender fü r eine Prü fung frü hzeitig zur Verfü gung.

Im Gegensatz dazu wird beim wasserfallartigen Vorgehen jede Tä tigkeit der Systementwick­lung vollstä ndig abgeschlossen, bevor mit der nachfolgenden Tä tigkeit begonnen wird. Dies bedeutet, dass bei dem wasserfallartigen Vorgehen Verbesserungen an bestehenden Arte­fakten nur ü ber einen definierten Change-Prozess vorgenommen werden dü rfen. Diese Art des Vorgehens wird z. B. bei ö ffentlichen Ausschreibungen eingesetzt, wo eine relativ groß e Distanz zwischen den Vertragspartnern herrschen soll, und Ä nderungen an der Spezifikation sehr genau bewertet werden mü ssen.

Anwendungsfallgetriebene Vorgehensmodelle nutzen Anwendungsfalle (Englisch: Use-Cases, siehe Abschnitt 3.3.3 „Die Durchfü hrung der Analyse") als Grundlage, um die Systement­wicklung zu strukturieren. Diese Anwendungsfä lle entsprechen Inkrementen, die nacheinan­der in der Analyse betrachtet und weiter entwickelt werden kö nnen.