Vorgehensmodell

Bedeutung

In der Systementwicklung und im Softwareengineering sind die Vorgehensmodelle von zentraler Bedeutung. Vorgehensmodelle werden meist zu den Referenzmodellen gezählt, die eine modellhafte, abstrahierende Beschreibung von Vorgehensweisen, Richtlinien, Empfehlungen oder Prozessen für abgegrenzte Problembereiche und auch für eine möglichst große Anzahl von Einzelfällen liefern. Insbesondere beschreibt ein Vorgehensmodell die Folge  bzw. das Bündel  aller Aktivitäten  (in Phasen), die zur Durchführung eines Projekts erforderlich sind. Vorgehensmodelle für die Systementwicklung von Informationssystemen und allgemein von Anwendungssystemen beschreiben, wie die Prinzipien, Methoden, Verfahren und Werkzeuge der System- und Software-Entwicklung einzusetzen sind. Vorgehensmodelle dienen in der Systementwicklung und im Softwareengineering z. B.

• zur Entwicklung von Informations- und Anwendungssystemen, z. B. das V-Modell XT oder PRINCE2
• zur Entwicklung von webbasierten oder allgemein Client/Server-basierten Informations- und Anwendungssystemen
• für die Systemintegration, Systemmigration und Systemeinführung
• für das Management des Lebenszyklus von Informations- und Anwendungssystemen und allgemein eines organisatorischen Wandels
• zum IT-(Multi)Projektmanagement, z. B. das V-Modell XT oder PRINCE2
• zum IT-Servicemanagement, z. B. auf Basis der "best-practices" ITIL
• zum Qualitätsmanagement, z. B. das EFQM-Modell für ein Total-Quality-Management (European Foundation for Quality Management)

(vgl. auch [Balzert 2008]).

Sinn und Zweck

Üblich ist eine Gliederung  in Phasen, Arbeitsabschnitte  und Aktivitätenblöcke, durch die der Entwicklungsprozess in planbare und kontrollierbare Einheiten zerlegt wird. Dazwischen liegen Meilensteine, an denen definierte (Zwischen-)Ergebnisse „abgenommen“ bzw. genehmigt werden müssen. Zwischen Auftraggebern und -nehmern muss Konsens herrschen oder oft mühsam erzielt werden, bevor der nächste Arbeitsblock frei gegeben werden kann. Die Einteilung des Entwicklungsprozesses in Projektphasen (vgl. Abbildung 1)

• verringert die Komplexität des IT-Projekts durch die Zerlegung in überschaubare, zeitlich aufeinander folgende Teilaufgaben und
• ermöglicht durch die Vorgabe von Phasenzielen ("Meilensteinen") Änderungen, die sich während der Systementwicklung noch ergeben, rechtzeitig zu berücksichtigen sowie Fehler in einem frühen Stadium zu erkennen und zu beseitigen.

Für jede einzelne Phase ist festzulegen,

• was zu tun ist und
• wie etwas zu tun ist, d. h. welche Prinzipien, Methoden und Verfahren anzuwenden und welche Werkzeuge evtl. einzusetzen sind.

Abb. 1: Strengeres Phasenmodell, vgl. auch [Stahlknecht, Hasenkamp 2004, S. 218] 

Strenge Projektkontrolle erfordert eindeutige Rollen, d.h. Verantwortungsabgrenzungen (evtl. phasenweise)

• wann etwas zu tun ist (Zeitplan),
• wer etwas zu tun hat (Aufgabenverteilung) und
• welche Kosten dabei höchstens entstehen dürfen (Budgetvorgabe).

Erst durch die Phaseneinteilung wird es möglich, in inhaltlich wie zeitlich begründeten Schritten

• die Einhaltung aller Vorgaben zu überprüfen,
• den Entwicklungsaufwand zu überwachen und
• bei Erfordernis kurzfristig steuernde Maßnahmen einzuleiten.

Vorgehensmodelle dienen der Planung, Steuerung und Kontrolle der Systementwicklung, d. h. dem Controlling. Ableitbar sind z. B. folgende Komponenten eines Organisationshandbuchs  der System- und Softwareentwicklung:

• Pro Phase durchzuführende Tätigkeiten,
• pro Phase zu erstellende Teilprodukte bzw. Zwischenergebnisse,
• pro Phase bzw. pro Tätigkeit anzuwendende Standards, Richtlinien, Methoden, Techniken und computer-gestützte Werkzeuge (Softwaretools),
• pro Phase bzw. pro Tätigkeit verantwortliche Mitarbeiter(-Kapazitäten),
• pro Tätigkeit notwendige Mitarbeiter-Qualifikationen,
• und pro Phase zuständige Lenkungsorgane

(vgl. auch [Balzert 2008]).

Auswahl und Anpassung

Ein Vorgehensmodell muss für den einzelnen Entwicklungsprozess angepasst, am besten maß-geschneidert, werden (sogenanntes „Tayloring“). Dieses ist nur dann erreichbar, wenn es an die jeweilige Projekt-, System- und Unternehmensumgebung sorgfältig angepasst wird. Zweckmäßigerweise sollte

• ein strengeres Phasenmodell, z. B. ein klassisches, wasserfallartiges Modell, bei "wohl strukturierten" Problemen, d. h. Informationssystemen mit a priori eindeutigem Anforderungsprofil, z. B. Finanzbuchhaltung, Personalabrechnung, usw., und
• ein flexibleres Zyklenmodell, z. B. das V-Modell XT oder ein Prototyping, bei "schlecht strukturierten" Problemen, z. B. Führungsinformationssysteme, Expertensysteme usw.,

eingesetzt werden (siehe auch [Stahlknecht, Hasenkamp 2004, S. 218 ff.] und [Balzert 2008, S. 445 – 688]). Das inzwischen weitverbreitete und anerkannte V-Modell XT  ist z. B. ein um-fassendes Prozessmodell für die Planung und Durchführung der Systementwicklung in IT-Projekten.

Für die Einführung von Standardsoftware  gibt es spezielle Vorgehensmodelle, Checklisten und Referenzmodelle, denen typische Referenzgeschäftsprozesse zugrunde liegen und die i. d. R. vom Standardsoftwarehersteller, z. B. SAP oder ORACLE, mitgeliefert werden.

Literatur

Balzert, Helmut: Lehrbuch der Softwaretechnik – Softwaremanagement. 2. Auflage. Heidelberg : Spektrum Akademischer Verlag, 2008.

Stahlknecht, Peter; Hasenkamp, Ulrich: Einführung in die Wirtschaftsinformatik. 11. Auflage. Berlin : Springer, 2004.

Autor