Entwicklungsphasen des OEP

Die Projektdurchführung erfolgt in verschiedenen Phasen, die jeweils unterschiedlichen Zielsetzungen folgen. Eine Phase ist ein zeitlicher bzw. sachlogischer Gliederungsabschnitt eines Projektes.

Eine Phase faßt eine Menge von Aktivitäten und Ergebnissen zu einer Planungs- und Kontrolleinheit zusammen. Am Ende jeder Phase steht ein Meilenstein, der die in der Phase zu erzielenden Ergebnisse definiert.

Ein Meilenstein definiert einen Termin, zu dem eine Menge von Ergebnissen in vorgegebener Detaillierung vollständig, nachprüfbar und formal dokumentiert vorliegen soll.

Die einzelnen Phasen können wiederum in Iterationen bzw. Timeboxen unterteilt werden, um so ein iteratives Vorgehen zu erzielen.

Folgende Phasen sind definiert:







Vorbereitungsphase

Die Vorbereitungsphase dient der grundlegenden Orientierung und Grobplanung für das Projekt.


Zweck der Vorbereitungsphase ist es, Inhalte und Ziele des Projektes entscheidbar und planbar zu machen. Die Phase könnte auch Auftragsklärungsphase oder Angebotserstellungsphase genannt werden.

Die Anforderungen an das zu entwickelnde System werden so weit erhoben, dass damit Aussagen zu Aufwand, Projektdauer, benötigten Ressourcen, Meilensteinen und eine grobe Aufteilung in einzelne Iterationen möglich sind. Und zwar in einer solchen Genauigkeit bzw. Zuverlässigkeit, wie sie in der aktuellen Situation minimal notwendig ist.

Wenn also der Auftraggeber nur eine sehr grobe Schätzung benötigt und die tatsächlichen Kosten und Termine erheblich abweichen dür-fen, ist die Vorbereitungsphase schnell abzuschließen. Dies ist oftmals in internen Softwareentwicklungsprojekten der Fall, wenn also Auftraggeber und Auftragnehmer zum gleichen Unternehmen gehören und die fachliche Notwendigkeit des Projektes außer Frage steht. Oder es liegt beispielsweise bereits ein komplettes und gutes Pflichtenheft vor.

Das andere Extrem ist sicherlich eine Situation mit einem externen Auftraggeber, der einen Festpreis benötigt, einem Auftragnehmer, der eine bestimmte Mindestrendite erzielen möchte, und ausreichend Zeit, um die Vorbereitungsphase auch gründlich genug durchführen zu können. Existieren außergewöhnlich viele Risiken, wird dies sicherlich eine längere Vorbereitungsphase erfordern.

Wann also genau die Vorbereitungsphase erfolgreich abgeschlossen werden kann, lässt sich nicht pauschal definieren, sondern ist projektspezifisch. Letztendlich sind es drei wichtige Faktoren, die das Phasenende bestimmen: Wie viel Zeit steht überhaupt zur Verfügung und welche Genauigkeit der Ergebnisse fordert der Auftraggeber und wel-che der Auftragnehmer?

Für die Dauer der Vorbereitungsphase kann als Richtwert etwa fünf bis zehn Prozent vom gesamten Zeitbedarf (über alle vier Phasen) angenommen werden.

Die Vorbereitungsphase wird durchgeführt

Wenn dem Projekt eine eigenständige Geschäftsprozessmodellierung voranging und es von Änderungen der Organisation und der Geschäftsprozesse betroffen ist, fließen die Ergebnisse der Geschäftsprozessmodellierung in diese Vorbereitungsphase ein.

Unsicherheiten in der Machbarkeit von Produktanforderungen können in dieser Phase durch experimentelle Prototypen beantwortet werden. Wenn die Durchführung des gesamten Projektes noch nicht entschieden ist oder noch sehr große Unsicherheit darüber besteht, rückt die Vorstudie in den Mittelpunkt der Vorbereitungsphase, mit der die Machbarkeit, Zweckmäßigkeit und die Alternativen geklärt werden sollen.

Sofern die Durchführung des gesamten Projektes unterstellt wird oder es hierzu eine klare Entscheidung gibt, konzentrieren sich die Aktivitäten der Vorbereitungsphase mehr auf die Konkretisierung und Abgrenzung der Projektinhalte.

Die wichtigsten Ergebnisse der Vorbereitungsphase sind: Die Vorstudie ist Entscheidungsgrundlage für die Durchführung der Entwurfsphase.

Meilensteine der Vorbereitungsphase: Statt Projektauftrag vereinbart ist möglicherweise auch Projektauftrag abgestimmt oder Angebot abgegeben ein sinnvoller Meilenstein. Projektauftrag vereinbart bezieht sich eher auf eine interne Auftragssituation. Bei einem externen Auftraggeber ist normalerweise ein Angebot mit einer Bindefrist abzugeben. Innerhalb der Bindefrist kann der Auftragnehmer das Angebot annehmen, und der Auftragnehmer hat das Projekt dann entsprechend des Angebotes umzusetzen. In diesem Fall wäre das Ende der Vorbereitungsphase durch die Abgabe des Angebotes gekennzeichnet. Dies ist ein sehr einfaches und klares Kriterium. Die Vorbereitungsphase wäre in diesem Fall auch dann zu Ende, wenn die Frist zur Angebotsabgabe verstrichen ist und noch kein Angebot abgegeben wurde.

Unabhängig davon, ob es eine interne oder externe Auftraggebersituation ist, kann zwischen dem Ende der Vorbereitungsphase und dem Beginn der nächsten Projektphase unter Umständen eine sehr lange Pause entstehen. Bei externen Aufträgen ist die Pause gewöhnlich begrenzt durch die Bindefrist des Angebotes. Aber auch bei internen Aufträgen kann es ggf. eine Weile dauern, bis das entsprechende Gremium oder die Geschäftsführung die Projektdurchführung beschließt. Auch bei internen Auftragssituationen kann es zu einer Ablehnung kommen.

Streng genommen ist die Vorbereitungsphase noch keine Projektphase, denn das eigentliche Projekt wird erst mit der Beauftragung, also mit Beginn der nächsten Phase, ins Leben gerufen. Oftmals sind zumindest einige Personen, die an der Vorbereitungsphase, d.h. Angebotserstellung beteiligt sind, auch im späteren Projekt dabei. Es können aber auch völlig andere Personen sein.

Geschäftsprozessmodellierung erstreckt sich gewöhnlich nicht nur über DV-relevante Abläufe und Prozesselemente, sondern beinhaltet auch organisatorische und manuelle Aspekte. In vielen Unternehmen ist nicht die Informatik, sondern eine eigene Abteilung (z.B. Betriebsorganisation) für die Geschäftsprozessanalyse zuständig. Im Rahmen von Geschäftsprozessanalysen wird zwar häufig Bedarf für neue Software oder für Änderungen an vorhandener Software erkannt, dennoch hat die Geschäftsprozessmodellierung einen anderen Fokus und etwas andere Ziele als die Softwareentwicklung. Geschäftsorganisatoren und Informatiker arbeiten mit unterschiedlichen Modellen, Methoden und Werkzeugen und an unterschiedlichen Aufgaben.

Die Analyse und Modellierung von Geschäftsprozessen kann deshalb aus dem Vorgehensmodell zur Softwareentwicklung ausgeklammert werden. Bei der Softwareentwicklung müssen jedoch Ergebnisse der Geschäftsprozessmodellierung beachtet werden. Zum einen hinsichtlich der inhaltlichen Ausrichtung (erkannte Schwachstellen und Lücken im Geschäftsprozess reduzieren), zum anderen, um eine möglichst effektive und sinnvolle Integration des neuen Anwendungssystems zu erzielen. Ebenso können sich aus neu eingeführter Software wieder neue Ansatzpunkte für die Geschäftsprozessanalyse ergeben.

Der OEP enthält eine eigene Disziplin Geschäftsprozessmodellierung, um den Bezug und die Abhängigkeiten von Geschäftsprozessmodellierung und der Entwicklung von Softwaresystemen darzustellen. Diese Disziplin kann also einerseits eigenständig, d.h. losgelöst von der Softwareentwicklung betrachtet und praktiziert werden, andererseits aber auch als integraler Bestandteil von IT-Projekten angesehen werden.

Aktiviäten der Vorbereitungsphase (Übersicht)

Meilenstein:





Entwurf-/Architekturphase (Startphase)

Die Entwurfs- und Architekturphase dient der Analyse des Anwendungsbereiches und der Erfassung aller wichtigen funktionalen und nichtfunktionalen Anforderungen an das Produkt.


Zweck der Entwurfsphase ist es, auf dieser Basis die grundsätzliche technische und fachliche Architektur festzulegen und alle grundsätzlichen Entscheidungen abzusichern.

Die fachlichen Zusammenhänge und Anforderungen sind detailliert zu ermitteln, die fachliche Architektur und die Anwendungsarchitektur sind zu erarbeiten und die Projektplanung ist zu detaillieren. Erste Lösungskonzepte werden entwickelt.

Zu Beginn des Projektes werden einige ganz grundlegende Entscheidungen getroffen. Wenn diese im Laufe des Projektes geändert werden müssten, könnte dies ganz erhebliche Kosten- und Terminüberschreitungen verursachen. Alle Entscheidungen mit einer solchen Tragweite sind gut abzusichern und gründlich zu überprüfen. Dies ist die vorrangige Aufgabe der Entwurfs- und Architekturphase. Die Entscheidung für eine bestimmte zu verwendende Datenbank, für ein bestimmtes Framework oder für eine bestimmte Programmiersprache ist in den meisten Fällen so grundlegend, dass eine spätere Änderung das Projekt dramatisch zurückwerfen oder gar sein Scheitern aus-lösen kann.

Wenn also zu befürchten ist, dass das verwendete Framework nicht leistungsfähig genug sein wird, ist es dringend geboten, die Entscheidung für das Framework abzusichern. Beispielsweise durch die Erstellung eines Performance-Prototyps, mit dem der Nachweis erbracht werden kann, dass das Framework leistungsfähig genug ist. Werden Risiken dieser Art ignoriert, kann dies unter Umständen als fahrlässig angesehen werden.

Selbstverständlich lassen sich nicht alle Risiken perfekt absichern. Hundertprozentige Sicherheit von Entscheidungen wird es in Projekten nie geben. Wichtig ist jedoch, dass alle zu diesem Zeitpunkt bekannten Risiken identifiziert und bewertet (d.h. priorisiert) werden. Anschließend ist dann, ggf. gemeinsam mit dem Auftraggeber, zu entscheiden, wie viel Risiko das Projekt tragen soll oder kann. Daraus ergibt sich, welche Risiken frühzeitig, also in der Entwurfs- und Architekturphase, untersucht und berechenbar werden sollen.

Die Frage, wie viel Risiken das Projekt auf sich nehmen kann oder muss, ist normalerweise keine willkürliche oder freie Entscheidung, sondern durch Rahmenbedingungen vorgegeben. Die Absicherung von Risiken kostet gewöhnlich Geld und Zeit, und da diese Ressourcen in aller Regel begrenzt sind, lassen sich eben auch nur die allerwichtigsten Risiken berechenbar machen. Kriterien für den erfolgreichen Abschluss der Entwurfs- und Architekturphase können also nicht allgemein gültig definiert werden, sondern sind wiederum projektspezifisch festzulegen. Letztendlich bestimmt der Auftraggeber, wie viel Sicherheit er benötigt oder sich (terminlich und finanziell) leisten kann.

Den meisten Risiken stehen entsprechende Chancen gegenüber. Wenn beispielsweise der Einführungstermin aufgrund einer Wettbewerbssituation extrem wichtig ist, müssen bestimmte Unsicherheiten in Kauf genommen werden, weil deren Absicherung ansonsten bereits dazu führen würde, den Einführungstermin nicht zu halten und somit den Nutzen des Gesamtvorhabens zu verfehlen. Steht hingegen Zeit zur Verfügung und ein wirtschaftlicher Projekterfolg im Vordergrund, kann die Entwurfs- und Architekturphase möglicherweise erheblich ausgedehnt werden.

In jedem Fall sollten die Kriterien für den erfolgreichen Abschluss der Phase vor Beginn der Phase festgelegt werden.

Die wichtigsten Ergebnisse der Entwurfsphase sind gewöhnlich:

Anwendungsfallübersicht. Alle, d.h. 100 Prozent der zu diesem Zeitpunkt bekannten, Anwendungsfälle sind zu identifizieren. Identifizieren bedeutet, dass die Anwendungsfälle einen eindeutigen Namen haben und ihre Auslöser und Ergebnisse beschrieben sind. Die Erfahrung hat gezeigt, dass Anwendungsfälle, die nur durch ihren Namen definiert werden, zu viele Verwechslungen, Missverständnisse oder In-terpretationsspielräume zulassen. Obwohl der Mehraufwand nur sehr gering ist, führt die Definition des Auslösers und der Ergebnisse eines jeden Anwendungsfalles dazu, diese Probleme nahezu vollständig auszuschließen.

Wenn wir für die Entwurfs- und Architekturphase fordern, alle Anwendungsfälle (d.h. 100 Prozent) zu identifizieren, so erfolgt dies in dem Wissen, dass im Nachhinein weitere Anwendungsfälle erkannt werden. Bezogen auf den gesamten Projektverlauf liegt die Quote typischerweise bei 65 - 85 Prozent. Es liegt in der Natur der Sache, dass wir nicht alle Anforderungen am Anfang identifizieren können und im Projektverlauf Erkenntnisse über weitere Anforderungen gewinnen werden.

Zu beachten ist jedoch, dass dies keine Rückkehr zum Wasserfallmodell darstellt. Ziel ist nicht, alle Anforderungen vollständig und detailliert zu erheben und zu beschreiben. Ziel ist es vielmehr, einen möglichst vollständigen Überblick zu erhalten. Vor allem werden die Anwendungsfälle nicht oder nur teilweise detailliert. Auch bei großen Vorhaben wird die Liste der identifizierten Anwendungsfälle (Name, Auslöser, Ergebnis) auf wenige Seiten passen.

Neben den Anwendungsfällen sind allerdings weitere Anforderungen zu definieren. Vor allem müssen alle wichtigen nichtfunktionalen An-forderungen festgelegt werden, da diese oftmals ganz erhebliche Auswirkungen auf die Systemarchitektur haben. Anforderungen zur Performance, zur Wartbarkeit oder zur Sicherheit des Systems beeinflussen ganz erheblich Entscheidungen zu den verwendeten Techno-logien, Frameworks, Architekturprinzipien und -mustern.

Zusätzlich oder alternativ zu Anwendungsfällen kann die Identifizie-rung von Features sinnvoll oder notwendig sein. Unter Features verstehen wir eine anfangs bewusst unscharfe und später in konkrete An-forderungen zu untergliedernde Zusammenfassung von Anforderungen.

Am Ende der Entwurfsphase kann ein externes Review durchgeführt werden. Neben der angestrebten Entscheidung, die Entwurfs- und Architektur-phase erfolgreich abzuschließen und in die Konstruktionsphase überzugehen, kann eine sinnvolle Entscheidung auch der Abbruch des Projektes sein. Hat die Untersuchung der Risiken beispielsweise gezeigt, dass diese nicht ausreichend eingegrenzt werden können, die Risiken inakzeptabel hoch bleiben oder die Projektziele nicht mehr erreicht werden können, wäre dies eine mögliche und sinnvolle Konsequenz. Eine andere Alternative wäre eine Neuformulierung des Projektauftrages mit beispielsweise veränderten Rahmenbedingungen (Änderung der Termine, Kosten, Funktionalität oder Qualität).

Mit Beginn der Entwurfs- und Architekturphase wird das Projekt auch personell, organisatorisch und in seiner Infrastruktur langsam aufgebaut. Es beginnt damit, dass entsprechende Räume und Arbeitsplätze herzurichten oder bereitzustellen sind, Entwicklungsumgebung und Konfigurationsmanagement aufgebaut werden, dass Projektgremien und Verantwortlichkeiten definiert und etabliert werden etc. Am Ende der Phase sollte der Nachweis erbracht sein, dass das Projekt vollumfänglich arbeitsfähig ist.

Es gehören hierzu grundlegende Sachverhalte wie die Vergabe von Be-rechtigungen, die Verfügbarkeit von Besprechungsräumen oder eine Telefonliste wichtiger Stakeholder. Ebenso sind auch die Berichtswege und Kommunikationsabläufe zu erproben. Steht die Fachabteilung qualitativ und quantitativ in ausreichender Weise zur Verfügung? Ist die Fachabteilung fähig, Entscheidungen beispielsweise über Anforderungen zu treffen? Haben sich die Abläufe zur Änderung von Anforde-rungen bewährt?

Auch hieraus ergeben sich möglicherweise weitere Risiken. Wurde beispielsweise mit dem Auftraggeber vereinbart, dass Anfragen zur Anforderungsklärung im Normalfall innerhalb von 48 Stunden beantwortet werden sollen, tatsächlich aber Antwortzeiten von über einer Woche üblich sind, kann das die gesamte Zeit- und Kostenplanung Maku-latur werden lassen. Die Entwurfs- und Architekturphase dient also auch dazu, die Zusammenarbeit mit Projektexternen, mit der Fachabteilung, dem Auftraggeber und anderen Zulieferern zu etablieren, zu prüfen und abzusichern. Entsprechendes gilt auch für die projektinternen Abläufe. Beispielsweise wenn ein Generierungsprozess nicht wie erwartet in wenigen Minuten oder Stunden abgeschlossen werden kann, sondern typischerweise erheblich länger dauert.

Insofern werden in dieser Phase nicht nur erste risikobehaftete oder hoch priorisierte Anforderungen umgesetzt, sondern in angemessenem Umfang auch ganz durchschnittliche Anforderungen und Abläufe angegangen.

Je nach geplanter Dauer der Phase sollte diese in mehrere Iterationen aufgeteilt werden. Typischerweise nimmt die Entwurfs- und Architekturphase etwa 12 - 20 Prozent der Gesamtzeit der ersten vier Phasen in Anspruch. Je nach Risikolage sowie Sicherheits- und Klärungsbedürfnis kann die Dauer jedoch auch ganz anders sein. Wenn eine Phasendauer von deutlich mehr als vier Wochen erwartet wird, ist eine Untergliederung in einzelne Iterationen sinnvoll.

Meilensteine der Phase: Nicht jedes mögliche oder größere Zwischenergebnis sollte als Meilenstein definiert werden, sondern nur wirklich wichtige Zwischenschritte. Auf jeden Fall sollte der unterschiedliche Charakter von Meilensteinen und Iterationen/Timeboxen erhalten bleiben und beachtet werden. Das heißt, die Unterteilung in Iterationen erfolgt durchaus unabhängig von der Definition zusätzlicher Meilensteine.

Aktiviäten der Entwurf-/Architekturphase (Startphase) (Übersicht)

Meilenstein:





Konstruktionsphase (Hauptphase)

Die Konstruktionsphase dient der inkrementellen Entwicklung des Systems bzw. der Subsysteme und ihrer Integration zu einem Produkt.


Die einzelnen Subsysteme werden spätestens jetzt in parallel arbeitenden Entwicklungsteams implementiert. Änderungen in den Anforderungen können nach Bewertung auch jetzt noch in den Entwicklungsprozess einfließen.

Die Konstruktionsphase hat bei Projekten von normaler Größe zwei bis sieben Iterationen. Je nach angesetzter Dauer einer Iteration erstreckt sich die Konstruktionsphase über zwei bis 14 Monate. Innerhalb einer Iteration werden die Anforderungen mit der jeweils höchsten Priorität in Analyse, Design, Implementation und Test umgesetzt. Der Funktionsumfang und die Qualität des Produktes wachsen inkrementell von Iteration zu Iteration.

Grundsätzlich unterstützt der OEP eine möglichst agile Entwicklung. Das heißt beispielsweise, dass der Zeitraum vom Erkennen einer Anforderung bis zum Nachweis der korrekten Umsetzung möglichst kurz sein soll. Es werden also nicht im Sinne eines Wasserfallprozesses zunächst alle Anforderungen im Detail geklärt. Stattdessen werden jeweils einzelne Anforderungen, kleine Pakete von Anforderungen oder überschaubare Features entsprechend ihrer Priorität angepackt und möglichst zügig umgesetzt. Im Idealfall wird bereits wenige Tage nach der Abstimmung einer Anforderung mit der Fachabteilung das Ergebnis präsentiert und eine Teilabnahme hierfür erzielt.

Die wichtigsten Ergebnisse dieser Phase sind:

Die Konstruktionsphase ist der zeitlich und aufwandsmäßig größte Abschnitt, er wird typischerweise ca. 60 Prozent des Zeitbedarfes aller vier Phasen ausmachen.

Am Ende der Konstruktionsphase steht das vollständige Produkt. Meilensteine der Konstruktionsphase:

Aktiviäten der Konstruktionsphase (Hauptphase) (Übersicht)

Meilenstein:





Einführungsphase

Die Einführungsphase dient dem Test und der Abnahme der kompletten Anwendung, der Auslieferung und Installation sowie der Schulung der Anwender.


Das Produkt wird in der Testumgebung installiert und unter realistischen Bedingungen getestet.

Die Anwender können im Umgang mit dem Produkt geschult werden. Hierzu müssen zunächst Schulungsunterlagen geschaffen und Schulungsleiter ausgebildet werden.

Die Entwicklungsdokumentation des Projektes wird abgeschlossen. Unter Umständen wird weiteres Personal ausgebildet, das die Wartung des Produktes übernehmen soll.

Wenn die Einführung mit einem komplizierten technischen oder organisatorischen Prozess verbunden ist, kann die Einführungsphase in mehreren Iterationen durchgeführt werden. Die Dauer der Phase kann demnach zwischen einem und fünf Monaten liegen.

Die Einführungsphase ist beendet, wenn das Produkt in der Produktionsumgebung installiert und betriebsfähig ist.

Meilenstein der Einführungsphase:



Aktiviäten der Einführungsphase (Übersicht)

Meilenstein:





Betriebsphase

Die Betriebsphase dient der Anwendung des fertig gestellten Produktes.


Die Betriebsphase ist das eigentliche Ziel des Projektes. Konfigurationen und sehr kleine Anpassungen des Produktes können ggf. als Ad-hoc-Wartung durchgeführt werden. Die Schulung und Betreuung der Anwender werden fortgesetzt.

Größere Änderungen in den Anforderungen werden getrennt von dem Projekt aufgenommen, bewertet und für einen Nachfolgeauftrag gesammelt.

Die Verantwortung für die Wartung des Produktes kann in dieser Phase von den Entwicklern in andere Hände übergehen.

Die Betriebsphase ist zwar formaler Bestandteil des OEP, inhaltlich jedoch kaum ausgeprägt, da der OEP die Unterstützung des Entwicklungsprojektes und nicht der anschließenden Wartung und Weiterentwicklung verfolgt.

Aktiviäten der Betriebsphase (Übersicht)

Meilenstein:






OEP - Object Engineering Process, v3.0, 06.11.2006 11:03:01, Copyright © 2006 by oose Innovative Informatik GmbH