Die Auswahl eines Prozessmodells für das Projektmanagement bei Software-Entwicklungsprojekten

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Anlagenverzeichnis

Abkürzungsverzeichnis

1 Einführung, Zielsetzung und Aufbau der Arbeit

2 Grundlagen des Projektmanagements im Softwarebereich
2.1 Begriffe und Definitionen
2.1.1 Projekt und Software-Entwicklungsprojekt
2.1.2 Projektmanagement im Entwicklungsumfeld
2.1.3 Prozess und Projekt
2.2 Was ist ein Prozessmodell?
2.3 Prozessmodell und Projektmanagement

3 Prozessmodelle für die Erstellung von Software
3.1 Abgrenzung des Untersuchungsbereichs
3.2 Das V-Modell XT
3.3 PITPM
3.4 Scrum
3.5 Extreme Programming
3.6 Crystal Clear
3.7 Übersicht der Prozessmodelle

4 Die praktische Auswahl eines Prozessmodells
4.1 Einführung
4.2 Grundüberlegungen und Entscheidungsfaktoren
4.2.1 Projekteigenschaften zur Auswahl der Prozessmodellmethodik
4.2.2 Projektbedingungen für die Auswahl eines Prozessmodells
4.2.3 Faktoren zur Prozessmodellbewertung
4.3 Bewertung der Prozessmodelle
4.4 Prozessmodellwahl
4.4.1 Projektbedingungen - Situationsbeschreibung Beispielprojekt
4.4.2 Modellprämissen - Kriteriengewichtung
4.4.3 Nutzwertanalyse
4.4.4 Ergebnis - Welches Prozessmodell ist geeignet?

5 Resümee und Erkenntnisse
5.1 Zusammenfassung
5.2 Weitergehende Überlegungen zur Auswahl eines Prozessmodells
5.3 Ausblick

Literaturverzeichnis

Anlagen

Abbildungsverzeichnis

Abbildung 1: Das Umfeld von Projektmanagement und Software-Realisierung

Abbildung 2: Der Prozess im Projekt

Abbildung 3: Zusammenhang zwischen Prozessmodell und Projektmanagement.

Abbildung 4: Das V-Modell

Abbildung 5: Schema eines Vorgehensbausteins

Abbildung 6: Die PITPM-Prozesse

Abbildung 7: Der Scrum-Prozess

Abbildung 8: Der Extreme-Programming-Prozess

Abbildung 9: Die Prozesszyklen bei Crystal Clear

Abbildung 10: Basisentscheidungsfaktoren zur Wahl der Prozessmodellmethodik

Tabellenverzeichnis

Tabelle 1: Nutzwerte der Prozessmodelle

Anlagenverzeichnis

Anlage 1: Übersicht Prozessmodelle

Anlage 2: Bewertungsmatrix der Prozessmodelle

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einführung, Zielsetzung und Aufbau der Arbeit

Das Projektmanagement dient der systematischen Planung, Durchführung und Kontrolle von Projekten. Ein methodisches und systematisches Vorgehen ermög- licht eine erfolgreiche Projektabwicklung. Wenn methodisches Vorgehen und betriebliche Prozesse der Softwareentwicklung in einem organisatorischen Mo- dell definiert sind, nennt man dies ein Prozessmodell oder auch Vorgehens- modell. Für das Projektmanagement für Softwareprodukte, dem Software- Projektmanagement, gibt es zahlreiche Prozessmodelle, die mehr oder weniger speziell für die Anwendung im Softwarebereich entwickelt wurden.

Das Ziel dieser Arbeit ist die systematische Ermittlung eines geeigneten Pro- zessmodells oder einer Prozessmodellkombination für das Projektmanagement eines Software-Entwicklungsprojekts. Die Ermittlung erfolgt innerhalb einer vorausgewählten Anzahl von fünf Modellen. Die gewählten Prozessmodelle sind grundsätzlich für Software-Entwicklungsprojekte geeignet, sind aber nicht auf eine bestimmte Programmiertechnologie, Programmierart oder einen bestimmten Softwarehersteller beschränkt.

Im zweiten Kapitel werden Grundlagen und Begrifflichkeiten des Projektmanagements und der Prozessthematik erläutert, sowie der Zusammenhang zwischen Prozessmodell und Projektmanagement erklärt.

Das nächste Kapitel stellt die Prozessmodelle vor. Die Abgrenzung des Untersu- chungsbereichs für die Wahl der in der Arbeit verwendeten Modelle wird zu- nächst erläutert. Die grundsätzlichen Ziele und die Konzeption der einzelnen Prozessmodelle werden kurz beschrieben. Für jedes Prozessmodell werden die charakteristischen prinzipiellen Prozesszyklen in einer grafischen Übersicht dargestellt. Eine Zusammenfassung der Prozessmodellkennzeichen schließt das Kapitel ab.

Das vierte Kapitel befasst sich mit der praktischen Auswahl eines Prozessmo- dells. Zunächst werden grundlegende Projekteigenschaften definiert und erläu- tert, die als Basisentscheidungsfaktoren für die Wahl der Prozessmodellmethodik gelten. Konkrete praktische Projektbedingungen vervollständigen die Entschei- dungsfaktoren für eine systematische Auswahl eines Prozessmodells.

In einer Bewertungsmatrix werden für jedes Prozessmodell Modelleigenschaften und Modellprämissen analysiert und qualitativ bewertet. Die Erfassung und Bewertung der Modelleigenschaften bzw. Modellprämissen erfolgt anhand der Kriterienkategorien Praxistauglichkeit, Kompetenzbedarf, Flexibilität / Standardisierung, Qualität, Kosten, Risiko und Projektgröße. Die Differenzierung in Unterkategorien mit geeigneten Prozessmodellkriterien bildet die Bewertungsebene. Jedes Modellkriterium wird durch eine Punktzahl bewertet.

Der Grad der Eignung der Prozessmodelle für ein Projekt wird durch eine Nutz- wertanalyse bestimmt. Basierend auf den Daten eines Beispielprojekts und des- sen Projektbedingungen, wird eine Nutzwertermittlung der Prozessmodelle durchgeführt und ein geeignetes Prozessmodell empfohlen. Eine Zusammenfas- sung der Erkenntnisse und ein Resümee bilden den Abschluss der Arbeit.

2 Grundlagen des Projektmanagements im Soft- warebereich

2.1 Begriffe und Definitionen

2.1.1 Projekt und Software-Entwicklungsprojekt

Ein Projekt ist nach der Definition des Deutschen Instituts für Normung ein "Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist" (DIN 69901-5:2009-01). Projekte können nach ihrer Art aufgrund ihres Projektgegenstands differenziert werden. Projektarten sind beispielsweise Forschungs-, Entwicklungs- und Organisationsprojekte. Wenn ein Projekt ein neues Softwareprodukt oder -teilprodukt liefert, nennt man dies ein Software-Entwicklungsprojekt. Entwicklungsprojekte haben eine zeitliche und kostenmäßige Begrenzung (vgl. Sneed 2005: 9-10).

2.1.2 Projektmanagement im Entwicklungsumfeld

Projektmanagement ist die "Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Initiierung, Definition, Planung, Steuerung und den Abschluss von Projekten" (DIN 69901-5:2009-01).

Dem Projektmanagement übergeordnet ist das Entwicklungsmanagement, das die Entwicklungsplanung durchführt und dem Projektmanagement entscheidende Eckdaten für die Software-Realisierung vorgibt. Technologieplanung, Einführungsplanung und Entwicklungsdienste wie bspw. Qualitätssicherung unterstützen das Projektmanagement (vgl. Burghardt 2008: 14).

Die Eingliederung des Projektmanagements und der Software-Realisierung ins Unternehmensumfeld ist in Abbildung 1 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Das Umfeld von Projektmanagement und Software-Realisierung. Quelle: in Anlehnung an Burghardt 2008: 14.

2.1.3 Prozess und Projekt

Zu Beginn eines Projekts bestehen die Idee und das Projektziel der Erzeugung eines Produkts. Das Produkt entsteht durch die sequenzielle oder parallele Folge von Aktivitäten, genannt Prozess. Ein Prozess bestimmt das Vorgehen im Projekt und den Realisierungsverlauf. Der gesamte Prozess wird in mehrere Phasen oder Abschnitte eingeteilt. Ein Software-Entwicklungsprozess mit einer sequenzi- ellen Aktivitätenfolge ist in Abbildung 2 schematisch dargestellt. Dieser exemp- larische Prozess besteht aus den Phasen Definition, Entwurf, Realisierung, Er- probung und Einsatz (vgl. Hindel et al. 2009: 10; Burghardt 2008: 21-22).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Der Prozess im Projekt.

Quelle: in Anlehnung an Burghardt 2008: 21.

2.2 Was ist ein Prozessmodell?

Allgemein betrachtet definiert ein Prozessmodell einen organisatorischen Rahmen und unterstützt die systematische und methodische Projektdurchführung. Prozessmodelle werden im Softwarebereich auch Vorgehensmodelle genannt (vgl. Balzert 2008: 449-450).

Ein Prozessmodell für die Softwareentwicklung kombiniert organisatorische Elemente der Softwareerstellung mit den Methoden des Projektmanagements, um einen standardisierten Projektverlauf zu erreichen. Das Modell definiert an- wendbare Entwicklungsprozesse und hilft Projekte erfolgreich umzusetzen (vgl. Hindel et al. 2009: 8, 14).

Die Software-Prozessmodelle lassen sich nach der Art der Prozessmethodik in zwei Gruppen einteilen, die traditionellen deterministischen Modelle - die auch phasenorientierte oder sequenzielle Modelle genannt werden - und die Gruppe der agilen Modelle.

Die Softwareprozesse der determinierten Methodik sind stark planungs- und dokumentationsorientiert und finden häufig Anwendung bei Softwarelösungen für hochwertige oder kritische Produkte mit mittleren bis hohen Zuverlässigkeitsanforderungen.¹ Ein Prozess wird Schritt für Schritt frühzeitig geplant und spezifiziert. Derartige Prozesse nennt man stringente Prozesse (vgl. Boehm, Turner 2008: 55; Lehmbach 2007: 213; Hirzel 2008: 77).

Agile Softwareprozesse sind überwiegend gekennzeichnet durch flexibles (agiles) und iteratives Vorgehen, sowie einer weitgehenden Gestaltungsfreiheit des Teams für die Projektabwicklung. Die Softwareentwicklung erfolgt inkre- mentell (stufenweise) und in zeitlich befristeten Prozesszyklen, den sogenannten Iterationen. Das Ergebnis einer Iteration ist ein funktionsfähiger Teil eines Soft- wareprodukts. Ein zufriedener Kunde und periodisch verfügbare Softwarelösun- gen stehen im Mittelpunkt (vgl. Tiemeyer 2010: 83, 87; Beck et al. 2001).

2.3 Prozessmodell und Projektmanagement

Der Standardisierungsgrad der Projektdurchführung lässt sich in drei Entwick- lungsstufen einteilen. In der ersten Stufe wird Projektmanagement mit einer standardisierter Vorgehensweise angewendet. In der zweiten Stufe erfolgt die Projektabwicklung zusätzlich mit Prozessmodellen und in der dritten Entwick- lungsstufe besteht ein ganzheitliches Prozessmanagement für Kernprozesse mit Unterstützung durch Informationssysteme und die Anbindung an Manage- mentprozesse und übergreifende Stützprozesse (vgl. Muchowski 2001: 25-26; VDA 2004: 17; Hirzel 2008: 76). Der prinzipielle Zusammenhang zwischen Pro- zessmodell und Projektmanagement ist in Abbildung 3 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Zusammenhang zwischen Prozessmodell und Projektmanagement. Quelle: in Anlehnung an Hindel et al. 2009: 15.

Das Management beauftragt eine Prozessgruppe, die ein Prozessmodell auf Grundlage einer Prozessarchitektur erstellt. Die Architektur könnte beispielsweise aus Projektphasen, Projektrollen, Methoden und Dokumenten bestehen. Des- weiteren beauftragt das Management Projektleiter, die Projekte betreuen und durchführen. Der Projektleiter leitet die Projektvorgehensweise aus dem Pro- zessmodell ab und erstellt einen Projektplan. Im Detail erfolgen Zuweisungen von konkreten Terminen zu Projektphasen, die Bestimmung von verantwortlichen Personen für Projektrollen und der Einsatz der nötigen Werkzeuge und Doku- mentvorlagen. Gewonnene Erkenntnisse und Verbesserungen fließen in einem Feedback-Zyklus in das Prozessmodell zurück (vgl. Hindel et al. 2009: 16).

3 Prozessmodelle für die Erstellung von Software

3.1 Abgrenzung des Untersuchungsbereichs

Es gibt zahlreiche Prozessmodelle für die Softwareerstellung. Die in dieser Arbeit verwendeten Prozessmodelle wurden anhand ihrer zugrundeliegenden Methodik und der zeitlichen Modellaktualität ausgewählt. Als methodisch relevant wurden Modelle mit hohem praktischen Konkretisierungsgrad eingestuft, die wirtschaftlich und relativ unmittelbar für kleine Projektgrößen eingesetzt werden können.² Eine pragmatische und praxisorientierte Modellmethodik mit einer Illustration der Prozesse und der Bereitstellung von Dokumentvorlagen begünstigt die direkte und effiziente Verwendung im betrieblichen Projektgeschäft.

Allgemeine Basismodelle und eher abstrakte oder komplexe Referenzmodelle, die umfangreiche Vorarbeiten bis zum konkreten betrieblichen Einsatz benötigen, wie bspw. CMMI wurden nicht betrachtet.³ Ebenso wurden keine Modelle gewählt, die ausschließlich für eine spezifische Art der Softwareentwicklung konzipiert wurden, wie z. B. das Rational-Unified-Process-Modell, das speziell für objektorientierte Programmierung entwickelt wurde.

3.2 Das V-Modell XT

Was ist das V-Modell XT?

Das V-Modell XT ist eine Weiterentwicklung des V-Modells 97, herausgegeben durch das deutsche Bundesministerium des Innern. Im nachfolgenden Text wird das V-Modell XT als „V-Modell“ bezeichnet. Das V-Modell ist ein sequenzielles Vorgehensmodell zum Planen und Durchführen von Software- und Hardware- Entwicklungsprojekten unter Berücksichtigung des gesamten Projektlebens- zyklusses (vgl. BMI 2009: 1/6, 1/13).⁴ Das V-Modell kann sowohl vom Projekt- Auftraggeber als auch vom Projekt-Auftragnehmer genutzt werden (vgl. BMI 2009: 1/8). Die phasenorientierte Grundstruktur des Projektverlaufs auf Basis des V-Modells ist in Abbildung 4 ersichtlich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Das V-Modell. Quelle: Balzert 2008: 554.

Zielsetzung und Konzeption des V-Modells

- Die Projektrisiken mit standardisierten Vorgehensweisen minimieren, um als Resultat erhöhte Projekttransparenz und bessere Planbarkeit zu erhalten. Vorgehensbausteine sind die wesentlichen Inhalte des V-Mo- dells. Ein Vorgehensbaustein umfasst die Bestandteile, die im Rahmen eines Projekts für die Bearbeitung einer bestimmten Aufgabenstellung nötig sind. Mögliche Bestandteile eines Vorgehensbausteins sind Pro- dukte, Aktivitäten, Arbeitsschritte und Rollendefinitionen (vgl. BMI 2009: 1/7, 1/15). Der schematische Aufbau eines Vorgehensbausteins ist in Abbildung 5 (S. 13) dargestellt.
- Die Ergebnisqualität verbessern und gewährleisten durch frühzeitig überprüfte Zwischenergebnisse. Die Qualitätsverifikation bzw. -validierung erfolgt auf jeder Entwicklungsstufe. Methoden der Verifikation sind Tests und sogenannte Peer Reviews. Die Validierung zeigt, ob das Produkt in der Zielumgebung ordnungsgemäß funktioniert (vgl. BMI 2009: 1/7, 1/35, 7/20, 7/21).
- Kosten eindämmen über den gesamten Projektlebenszyklus durch gezielte Projektplanung und -steuerung und einer Wirtschaftlichkeitsbetrachtung. Lebenszykluskosten sind Planungskosten, Projektkosten, Herstellkosten, Nutzungskosten und Aussonderungskosten (vgl. BMI 2009: 1/8, 3/120, 5/46, 5/187).

[...]

¹ Eine mittlere Zuverlässigkeitsanforderung liegt vor, wenn ein potenzieller Softwarefehler hohe wirtschaftliche Schäden verursachen könnte. Eine hohe Zuverlässigkeitsanforderung besteht bei möglicher Gefährdung von Menschenleben im Falle eines Softwarefehlers (vgl. Boehm, Turner

2008: 56).

² Als Kleinprojekte gelten Projekte mit 3 bis 10 Mitarbeitern, einem Aufwand von 0,4 bis 5 Personenjahren und 50.000 bis 500.000 € Projektkosten (vgl. Tiemeyer 2010: 3).

³ CMMI = Capability Maturity Model Integration

⁴ Die Seitennummerierung in der Literaturquelle erfolgt mit einem Kürzel bestehend aus Kapitel und Seite. Die Angabe „1/6“ bedeutet bspw. Kapitel 1, Seite 6.