5 PM – Aspekte für die agile Softwareentwicklung

Im ersten Abschnitt dieser Arbeit wurde in das Gebiet Offshore eingeführt. Da ein Schwerpunkt dieser Arbeit auf dem Software Development Offshoring liegt, befasst sich dieses Kapitel mit den grundlegenden Projektmanagement - Methoden und - Prozessen im Bereich der Softwareentwicklung. Zunächst wird jedoch das klassische Phasenmodell im Projektmanagement vorgestellt und anschliessend die klassischen und agilen Vorgehensmodelle der Softwareentwicklung gegenüber gestellt. In Kapitel 6 wird anschliessend untersucht, wie agile Methoden in einem Offshore – Projekt eingesetzt werden können.

5.1 Einführung: Ein klassisches Phasenmodell

Heute arbeiten die meisten Unternehmen innerhalb des Projektmanagements nach PMI - oder IPMA - Richtlinien. Das heisst konkret, dass das phasenorientierte Arbeiten in Projekten allgemein bekannt ist. Die Projektphasen nach PMI teilen sich in folgende fünf ein:

  Initialisierung

  Planung

  Durchführung

  Überwachung und Steuerung

  Abschluss

In der Initialisierungsphase werden die Anforderungen eines Auftraggebers formal festgehalten, ausserdem wird entschieden, ob es überhaupt zu einem Projekt kommt (vgl. Jenny, 2003, S. 49). Die Ergebnisse aus dieser Phase sind der Projektauftrag, in dem der Projektmanager mit dem Projekt beauftragt wird, und das sog. ‚vorläufige Scope Statement’ (Rahmenvereinbarung), ein Dokument, in dem der Rahmen und der Handlungsspielraum formuliert werden.

In der Planungsphase wird der Projektumfang festgelegt das Ergebnis ist das Scope Statement (Rahmenvertrag). Es werden ausserdem weitere Detailpläne, wie Projektstrukturplan, Termin- und Kostenpläne erstellt.

In der Durchführungsphase soll sichergestellt werden, dass die geplanten Aktivitäten ausgeführt werden. Wichtigste Ergebnisse sind die eigentlichen Lieferobjekte des Projekts. Auch Prozesse wie die Qualitätssicherung, das Projektteam aufbauen und den Anbieter auswählen zählen zu dieser Phase.

In der Überwachungs- und Steuerungsphase werden Projekt - Prozesse überwacht und die bisher erhaltenen Lieferergebnisse und Informationen bewertet und entsprechend mit der schriftlich festgehaltenen Planung kontrolliert. Die Risikoüberwachung und Massnahmenplanung gehört ebenfalls dazu. Die als Prozess integrierte Änderungssteuerung regelt die Abwicklung von Änderungsanträgen (Change Requests).

In der Abschlussphase wird das Projekt aufgelöst. In dieser Phase werden Verträge beendet und der Projektauftrag als geschlossen erklärt.

(vgl. Wikipedia, Projektmanagement).

5.2 Klassische Vorgehensmodelle der Softwareentwicklung

Auf dem Gebiet des Projektmanagements gibt es verschiedene Strukturen und Methoden zur Führung und Durchführung von Softwareentwicklungs - Projekten. Die Wahl des jeweiligen Vorgehensmodells richtet sich nicht nur nach Branchentyp und den internen Richtlinien eines Unternehmens, sondern auch nach der Komplexität und Grösse eines Projekts (vgl. Oestereich, 2008, S.30).

Im Folgenden sollen vier klassische Vorgehensmodelle aus dem Bereich der Softwareentwicklung grob vorgestellt werden:

  Wasserfall

  RUP

  Spiralmodell

  V-Modell

5.2.1 Wasserfallmodell

Das wohl bekannteste Modell ist das Wasserfallmodell (Abbildung 10, Quelle: Kruchten, 1999, S. 6). Der Softwareentwicklungsprozess wird phasenweise organisiert und der Prozess der Entwicklung wird linear durchlaufen, d.h. die Ergebnisse der vorherigen Phase gehen „immer als bindende Vorgaben in die nächst tiefere Phase ein“ (Zitat: Wikipedia, Wasserfallmodell). Im Gegensatz zu einer agilen Methode, hat das Wasserfallmodell feste Start- und Endpunkte mit eindeutig definierten Abnahmepunkten, den Meilensteinen. Die Problematik bei einer Entwicklung nach Wasserfallmodell liegt darin, dass Risiken in die Zukunft verschoben werden. Die Konsequenz daraus ist, dass Fehler durch alle Phasen mitgeschleppt werden und so höhere Kosten für ein Projekt entstehen. (vgl. Kruchten, 1999, S. 6)

Abbildung 10: Das Wasserfallmodell der Softwareentwicklung

5.2.2 RUP

Ein anderes Modell für die Softwareentwicklung ist RUP (Rational Unified Process). RUP ist ein iterativer und objektorientierter Softwareentwicklungsprozess. Entscheidend ist, dass RUP die Rahmenbedingungen liefert, um die Entwicklung einer Software auf die Bedürfnisse der Entwicklungsorganisation und der Entwicklerteams anpassen zu können.

Abbildung 11: Die Phasen des Rational Unified Process

Abbildung 11 (Wikipedia, IBM-RUP) zeigt die Phasen und Iterationen des RUP. In der horizontalen Achse werden die wesentlichen Prozessabläufe hinsichtlich der Zeit und die Aspekte des Projektlebenszyklus aufgezeigt. Die vertikale Achse veranschaulicht die Kernprozesse.

Das iterative Vorgehen, d.h. das Vorgehen in kleinen Schritten dient dazu, Risiken innerhalb des Projektlebenszyklus frühzeitig zu erkennen und eingreifen zu können. Dies bedeutet, dass Entwickler den Softwareentwicklungsprozess ständig analysieren, neu planen und implementieren müssen. Jede Iteration liefert ausführbare Releases, sog. Artefakte (Lieferobjekte). Der iterative Prozess ist in Abbildung 12 dargestellt (Quelle: Krucker, 1999, S.7).

Abbildung 12: Der iterative und inkrementelle Prozess

Der Projektlebenslauf teilt sich in die Phasen Konzeptionalisierung (Inception), Entwurf (Elaboration), Konstruktion (Construction) und Übergang (Transition) aus.

In der Konzeptionalisierungsphase werden aktuelle Aufwendungen den geplanten gegenübergestellt. Passiert das Projekt nicht den Meilenstein dieser Phase, kann es gestopped werden oder es muss neu konzipiert werden, um die Phase nochmals durchlaufen zu können.

In der Entwurfsphase nimmt das Projekt langsam Formen an, denn in dieser Phase wird die Software - Architektur beschrieben, Entwicklungspläne werden erstellt und Prototypen entworfen.

In der Konstruktionsphase werden die Hauptsystemkomponenten designed. In dieser Phase wird hauptsächlich programmiert mit dem Resultat, dass am Ende ein erster Release (eine erste Ausgabe) der Software stattfinden kann.

In der Übergangsphase geht das Produkt vom Entwickler zum Kunden über. In dieser Phase wird der Endkunde und der spätere Verantwortliche für die Software - Instandhaltung geschult. Es finden sog. Beta – Tests statt und das Resultat wird mit dem geplanten Qualitätslevel aus Iteration ‚Konzeption’ verglichen, um sicherzustellen, dass das Endprodukt auch wirklich die Erwartungen des Kunden treffen. Ist der Kunde nicht mit dem Ergebnis zufrieden, wird eine Iteration nochmals durchlaufen. Ist der Kunde mit dem Produkt zufrieden, wird der Produkt – Freigabe – Meilenstein erreicht und der Projektlebenszyklus ist damit beendet (vgl. Wikipedia, IBM-RUP).

In jeder Iteration werden die Aufgaben in Disziplinen (insgesamt neun) unterteilt, welche wiederum in Entwicklungs- und Support - (unterstützende) Disziplinen unterschieden werden.

Zu den Entwicklungsdisziplinen gehören:

  die Geschäftsprozessmodellierung (Business Modelling): es beschreibt die Vision einer Organisation, in der das System laufen und wie dieses genutzt werden soll.

  die Anforderungen (Requirements): beschreiben, wie Anfragen ausgelöst werden und mit ihnen umgegangen werden soll.

  Analyse und Design (Analysis & Design): Ziel ist zu zeigen, wie das System in Bezug auf Performanz und Änderungen entwickelt werden kann. Ergebnis ist ein Design - Modell (blueprint) und ein Analyse – Modell.

  die Implementation: beschreibt durch welche Komponenten das System entwickelt wird.

  Test und Entwicklung (Deployment): beschreiben, dass während des ganzen Entwicklungsprojekts anhand von Funktionalität, Verfügbarkeit, Applikations- und Systemleistung getestet wird.

Zu den Support – Disziplinen gehören:

  das Konfigurations- und Änderungsmanagement (Configuration & Change Management): beschreiben die systematische Strukturierung des...