Vorgehensmodelle in der Softwareentwicklung

Für die Planung von Softwareprojekten stehen eine Reihe von klassischen bis agilen Phasen- und Vorgehensmodellen zur Verfügung. Welche Vorgehensmodelle gibt es und wie werden sie geplant?

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Eine der wichtigen Aufgaben bei der Planung von Softwareprojekten ist die Erarbeitung einer Projektorganisation im Rahmen eines Take-Off-Workshops. Unter Projektorganisation wird sowohl die Ablauforganisation verstanden, also z.B. wie das Projekt in einzelne Phasen unterteilt wird oder welche Hauptmeilensteine definiert werden, als auch die Aufbauorganisation.

Für die Ablauforganisation stehen eine Reihe von klassischen bis agilen Phasen- und Vorgehensmodellen zur Verfügung. Ein Phasenmodell gruppiert logisch und zeitlich verknüpfte Projektvorgänge in einzelne Projektphasen, die durch Meilensteine getrennt werden. Meilensteine dienen u.a. dazu, festzustellen, ob und wann eine Projektphase als abgeschlossen gelten kann. Ein Vorgehensmodell beinhaltet üblicherweise ein Phasenmodell, definiert dazu aber noch weitere Regeln und Vorgaben, wie zum Beispiel ein Rollenmodell, Dokumentvorlagen und Checklisten sowie Methodenbeschreibungen.

Wasserfallmodell, V-Modell, Scrum: Von klassisch bis modern

Ein Beispiel für Phasen- und Vorgehensmodelle ist das klassische Wasserfallmodel. Es gibt einen stringenten Ablauf von fünf Phasen vor. Das Risiko liegt hier bei allen größeren Projekten darin, dass Fehler erst sehr spät erkannt werden, sprich: während der Tests, wenn Design und Implementierung im schlimmsten Fall bereits abgeschlossen sind.

Nur bei wenigen Projekten, zum Beispiel bei Projekten mit einem Aufwand von nur wenigen Personentagen und fest vorgegebenen Anforderungen ist das klassische Wasserfallmodell noch das Mittel der Wahl. In den meisten Fällen ist es jedoch nicht mehr adäquat.

Viele Vorgehensmodelle, die für große und komplexe Projekte geeignet sind, orientieren sich am sogenannten V-Modell. Mit der frühzeitigen Definition der Testfälle verfolgt man das Ziel, das Projektrisiko zu minimieren und gleichzeitig die Software-Qualität und die Transparenz im Projekt zu erhöhen. Im Idealfall wird dieses Phasenmodell in mehreren Durchläufen (Iterationen) durchschritten, bei denen das zu erstellende System Schritt für Schritt (inkrementell) entwickelt wird.

Agile Vorgehensweisen wie SCRUM gehen von der Grundannahme aus, dass Entwicklungsprojekte so komplex sind, dass sie im Voraus nicht bis ins Detail geplant werden können. Es ist daher besser, ein Team organisiert sich in einem gewissen Rahmen selbst und übernimmt Verantwortung für die Fertigstellung der einzelnen Ergebnisse. Aus Sicht der Phasenmodelle wird in SCRUM das zeitliche Vorgehen im Projekt in kurze Iterationszyklen (den sogenannten „Sprints“, meist ca. 30 Tage) unterteilt und regelmäßig mit Feedback des „Product Owner“ am Ende eines Sprints gepaart.

Welche Art von Phasen- und Vorgehensmodell zum Einsatz kommt, hängt letztlich von den Eigenschaften des Projektes und auch vom Auftraggeber ab. Handelt es sich um eine Entwicklung mit sicherheitskritischen Funktionen, so wird sich das Vorgehen am V-Modell orientieren. Bei umfangreicheren Projekten wird man zudem in mehreren Durchläufen die einzelnen Phasen des V-Modells durchlaufen, um so das System Schritt für Schritt zu entwickeln und Probleme möglichst frühzeitig zu identifizieren.

Gerade agile Vorgehensweisen bedürfen einer intensiven Kommunikation zwischen Auftraggeber und Auftragnehmer mit kurzen Entscheidungswegen. Lange Entscheidungswege auf Seiten des Auftraggebers machen den Einsatz agiler Vorgehensweisen problematisch.

Tailoring der Vorgehens- und Phasenmodelle

Gerade umfangreiche Vorgehens- und Phasenmodelle wie das V-Modell XT müssen vor ihrem Einsatz an das Projekt angepasst werden. Während des sogenannten Tailoring werden die Teile des Modells entfernt, die aufgrund der Projekteigenschaften nicht benötigt werden. Beinhaltet ein Projekt z.B. keine sicherheitsrelevanten Bestandteile, so können alle entsprechenden Tätigkeiten und Ergebnisdokumente entfallen.

Beim Tailoring bietet sich die Unterstützung durch den Projekt-Coach an. Dieser kennt ein Phasen- und Vorgehensmodell viel besser und kann die entsprechenden Anpassungen am Vorgehensmodell in Abstimmung mit dem Projektleiter vornehmen. Der Projekt-Coach hat auch die Aufgabe sicherzustellen, dass wichtige Bestandteile z.B. von Projekt- und Konfigurationsmanagement oder Qualitätssicherung nicht versehentlich einem Tailoring zum Opfer fallen.

Es ist wichtig zu verstehen, dass Tailoring in einem Projekt nie Mittel der Wahl sein darf, um Tätigkeiten oder Zwischenergebnisse wegen Zeitmangel wegfallen zu lassen! Ziel des Tailoring ist eine pragmatische Vorgehensweise. Das bedeutet, dass man nur so viele Regeln und Vorgaben definiert, wie auch wirklich benötigt werden. Aber notwendige Regeln werden auch tatsächlich eingehalten.

Casting ohne Show: Rollen richtig besetzen

Neben der zeitlichen Strukturierung von Projekten in einzelne Phasen werden Projekte auf der organisatorischen Ebene geplant. Ergänzend zu einem Phasenmodell beinhalten daher Vorgehensmodelle auch die Definition von Rollen, z.B. eines Software-Architekten, die für Ergebnisse bzw. Aufgaben verantwortlich sind. Darüber hinaus wirken Rollen bei der Erstellung von Dokumenten bzw. der Durchführung von Aktivitäten mit, geben Entscheidungen vor oder werden über Ergebnisse informiert. Je nach Vorgehensmodell sind noch weitere Zuordnungen möglich.

Zu jeder Rolle findet sich im Vorgehensmodell eine Beschreibung der Aufgaben, welche von der Rolle durchgeführt werden müssen, aber auch die Fähigkeiten, die ein Mitarbeiter zur Ausfüllung dieser Rolle mitbringen sollte. Aufgabe ist es nun, die passenden Mitarbeiter für die zu vergebene Rolle zu finden und diese zu besetzen.

Hier ist es meist problematisch, dass Mitarbeiter in mehreren Projekten zum Einsatz kommen. An dieser Stelle muss man nun mithilfe des Phasenmodells einen ersten zeitlichen Rahmen stecken, in dem einzelne Mitarbeiter für Rollen benötigt werden. Im Folgenden gilt es, diese Zeiten mit den Mitarbeitern abzustimmen. Da sich auf Anhieb kaum eine Übereinstimmung erzielen lässt, muss der Mitarbeitereinsatz in der Regel mehrfach überarbeitet werden.

Bei der Rollenbesetzung kann der Projekt-Coach unterstützen, indem er gemeinsam mit dem Projektleiter über Qualifikation und Verfügbarkeit der Mitarbeiter diskutiert und, sofern notwendig, mit dem Projektleiter geeignete Qualifizierungsmaßnahmen für das Projektteam auswählt und plant bzw. selbst als Trainer fungiert.

Meilensteine sind nicht nur einfach Wegbegleiter

Ein Resultat des Take-Off-Workshops ist eine Liste mit Projektergebnissen. Dies können Dokumente oder (Teil-)Systeme sein, die zu festgelegten Terminen fertig gestellt sein müssen. Häufig werden diese Projektergebnisse mit den zugehörigen Fertigstellungsterminen vom Auftraggeber vorgegeben. Damit stehen nun die ersten Hauptmeilensteine fest. Wie man unschwer erkennt, markiert ein Meilenstein ein wichtiges Ereignis im Projektverlauf, das mit einem bestimmten Ergebnis, z.B. abgenommenen Dokumenten, verbunden ist.

Ein gewähltes Phasenmodell enthält seinerseits Schnittstellen zwischen den einzelnen Phasen. Auch hier müssen bestimmte Ergebnisse fertig und meist auch durch ein Review abgenommen vorliegen. Auf Basis der Hauptmeilensteine gilt es nun, diese internen Meilensteine ebenfalls zu planen. Meilensteine sind z.B. der Abschluss der Anforderungsanalyse, Fertigstellung von Architektur und Design, von Implementierung, von Modul- oder Systemtest.

Es ist empfehlenswert, gerade diese internen Meilensteine möglichst gleichmäßig über den Projektverlauf zu verteilen und dabei die Abstände zwischen den einzelnen Meilensteinen nicht größer als einen Monat werden zu lassen. Dies unterstützt eine objektive Ermittlung und Darstellung des Projektstatus. Verzögerungen innerhalb einer Phase sind aus der Außensicht nur schwer zu erkennen.

Interne Meilensteine in kürzeren Abständen helfen, etwaige Verzögerungen schneller aufzudecken und entsprechende Maßnahmen frühzeitig ergreifen zu können. Eine geeignete Methode zur Erkennung von Projektverzögerungen ist z.B. die Meilenstein-Trendanalyse. Hier zeigt sich ein weiterer wichtiger Zweck von Meilensteinen: die Entscheidung über den weiteren Projektfortgang.

Mögliche Hauptmeilensteine, die gleichzeitig als Synchronisationspunkte mit dem Auftraggeber und möglichen eigenen Unterauftragnehmern dienen, können z. B. sein:

• Kick-off Meeting bzw. Projektstart-Workshop

• abgestimmte Projektdefinition

• Ende Phase „Projektstart“, Beginn „Projektdurchführung“

• abgestimmte Anforderungen, Version 1.0

• abgestimmte Systemarchitektur, Version 1.0

• Beginn und Ende „Implementierung“

• Beginn und Ende „Systemtest“

• Ende „Abnahme“

Kein Meilenstein ohne Ergebnisse und Verantwortlichkeiten

Erfolgreiche Projektleiter haben immer die für den nächsten Meilenstein notwendigen Ergebnisse im Blick. Eine sehr hilfreiche Grundlage ist eine kombinierte Ergebnis- und Rollenplanung:

• In einer Tabelle werden alle zu erstellenden Ergebnisse aufgelistet, z.B.: Anforderungsanalyse, Systemarchitektur, Software-Architektur, …

• Komplexe und umfangreiche Ergebnisse, wie z.B. Quellcode oder Tests, werden als Module, Funktionsblöcke oder Sammelpunkte aufgeführt.

• Für jeden Meilenstein wird eine Spalte eingeführt.

• Zu jedem Meilenstein wird der Termin eingetragen.

• An den Kreuzungspunkten wird nun markiert, welches Ergebnis zu welchem Meilenstein fertig sein muss. Darüber hinaus können hier verschiedene Versionsstände, wie z.B. „erster Entwurf“, „freigegebene Version“ usw. eingeführt werden.

• Zu jedem Ergebnis wird die verantwortliche Person aufgenommen.

• Alternativ können Ablageort oder Werkzeug zum Abruf eines Berichtes, z.B. bei Werkzeugen zur Erfassung und Verwaltung von Anforderungen, pro Ergebnis aufgeführt werden.

Agile Projekte mit Scrum effizient und einfach starten

5 Gründe, warum Scrum und Agile scheitern

Take-Off-Workshops im Projektmanagement

* Dr. Karlheinz Morgenroth studierte Wirtschaftsinformatik. Seit 2009 hält Morgenroth Vorlesungen an der Universität Bamberg zum Thema Projektmanagement in IT-Projekten. Seit 2016 zeichnet er bei der LEONI Boardnetz-Systeme GmbH verantwortlich für den Bereich Funktionale Sicherheit.

* Dr. Jürgen Schmied studierte und promovierte am Lehrstuhl für Informatik der Universität Würzburg. Dort ist er auch Lehrbeauftragter und hält Vorlesungen zum Thema „Management im Software Engineering“. Seit 2018 ist er Geschäftsführer bei der Process Fellows GmbH.

(ID:45846418)