Disziplinen des OEP

Die Aktivitäten des Prozeßmodells sind zeitlich in Phasen und inhaltlich in sog. Disziplinen untergliedert. Einige dieser Disziplinen beinhalten Aktivitäten, die direkt der Softwareerstellung dienen (z.B. Subsystem-Entwicklung), diese werden Kern-Disziplinen genannt, andere fassen unterstützende Aktivitäten zusammen (z.B. Projektmanagement, QS), d.h. solche Aktivitäten die nur indirekt der Systemerstellung dienen. Diese Disziplinen werden unterstützende Disziplinen genannt.

Die Aufteilung in Disziplinen existiert hauptsächlich zur besseren Orientierung im Vorgehensmodell. Die Vielzahl der Aktivitäten wird nach inhaltlichen Gesichtspunkten in überschaubare Gruppen eingeteilt.


Geschäftsprozessmodellierung

Aufnahme, Abstimmung und Modellierung der zu berücksichtigenden und betroffenen Geschäftsprozesse.

Die Geschäftsprozesse beschreiben geschäftliche Abläufe und die betriebswirtschaftliche Sicht weitgehend unabhängig von einer möglichen systemtechnischen Umsetzung. Anforderungen an die systemtechnische Unterstützung werden dann in der Disziplin Anforderungsanalyse definiert.


  • A-237 Workshop: Modellierungsfokus festlegen und Unternehmensziele beschreiben
  • A-238 Organisationseinheiten modellieren
  • A-239 Ziel und Zweck der Geschäftsprozessmodellierung festlegen
  • A-240 Aktive Geschäftspartner identifizieren
  • A-241 Workshop: Geschäftsanwendungsfälle der aktiven Geschäftspartner identifizieren
  • A-242 Unterstützende Geschäftsanwendungsfälle identifizieren
  • A-243 Geschäftsmitarbeiter identifizieren und Akteurmodell entwickeln
  • A-244 Geschäftsprozesse definieren
  • A-245 Geschäftsprozesse dokumentieren
  • A-247 Geschäftsanwendungsfälle essenziell beschreiben
  • A-248 Geschäftsanwendungsfall-Abläufe modellieren
  • A-269 Geschäftsanwendungsfall-Abläufe optimieren und konsolidieren
  • A-270 Geschäftsanwendungsfall-Abläufe detailliert beschreiben
  • A-271 Organisatorische Einbettung identifizieren und Abhängigkeiten ggf. reorganisieren
  • A-272 Kern-Geschäftsklassenmodell entwickeln
  • A-273 Geschäftsanwendungsfallmodell erstellen
  • A-275 Geschäftliche Anforderungen und Regeln beschreiben
  • A-276 Systemanwendungsfälle ableiten und identifizieren
  • A-290 Glossar überprüfen und aktualisieren
  • Anforderungsanalyse

    Analyse und Beschreibung aller wichtigen funktionalen und nichtfunktionalen Anforderungen an das zu entwickelnde System (Was soll das System leisten?)

    Aufnahme der Anforderungen des Auftraggebers, der Anwender und anderer Fachexperten, Analyse vorhandener Unterlagen wie beispielsweise Ergebnisse der Geschäftsprozessmodellierung, evtl. Vorgängerprojekte, Beschreibungen und Dokumente bestehender (abzulösender) Systeme etc.

    Die Anforderungen sind bezüglich ihrer Konsistenz, Widerspruchsfreiheit, Vollständigkeit, Dringlichkeit, Wichtigkeit, Aufwände, Chancen und Risiken gemeinsam mit dem Auftraggeber und anderen Beteiligten zu bewerten.


  • A-15 Anforderungsspezifikation zusammenstellen
  • A-128 Vorstudie erstellen
  • A-176 Anforderungsspezifikations-Entwurf erstellen
  • A-195 Anforderungsbeitragende identifizieren
  • A-200 Systemanwendungsfälle identifizieren
  • A-201 Materialsammlung und -studie
  • A-204 Fachliches Glossar anlegen
  • A-207 Exploratives Schnittstellen-Prototyping
  • A-226 Anforderungsworkshop durchführen (Vorbereitungsphase)
  • A-228 Anforderungsworkshop durchführen
  • A-229 Systemanwendungsfall detaillieren
  • A-230 Geschäftsklassenmodell entwickeln
  • A-231 Berichte und Auswertungen identifizieren und beschreiben
  • A-233 Systemanwendungsfallmodell entwickeln
  • A-235 Nichtfunktionale Anforderungen identifizieren
  • A-236 Features identifizieren
  • A-274 Zustandsmodelle für zustandsrelevante Geschäftsklassen erstellen
  • A-289 Glossar überprüfen
  • Systemerstellung

    Konzeption und Realisierung eines funktionsfähigen Systems entsprechend den erhobenen Anforderungen unter Berücksichtigung einer konkreten Entwicklungs- und Zielumgebung bzw. -architektur. Diese Disziplin gliedert sich in weitere Unterprozesse.

    Die Systemerstellung bezieht sich auf eine Menge kleinerer, fachlich und logisch zusammenhängender Bestandteile, die möglichst unabhängig voneinander entwickelt werden, wobei die Entwicklung jeweils direkt aufeinander folgende Aktivitäten von Analyse, Design, Implementierung und Test beinhaltet.


    Systemerstellung.Fachliche Architektur

    Strukturierung des Gesamtsystems in fachliche Subsysteme und Komponenten. Erstellung allgemeiner und Komponenten übergreifender Konzepte und Systembestandteile.

    Hierzu gehören beispielsweise die Modellierung des Subsystemmodells, die Koordinierung der subsystemspezifischen Klassen- und Datenmodelle, Erstellung und Einrichtung von Datenbankschemata, Konzeption und Erstellung von Subsystem übergreifenden Vorgangs- und Ablaufsteuerungen, Abstimmung der Subsystemschnittstellen und -spezifikationen sowie globaler fachlicher Services.


  • A-28 Referenzmodelle identifizieren und beschaffen
  • A-56 Datenbankschema spezifizieren
  • A-68 Interaktionsmodelle erstellen
  • A-71 Glossar überprüfen und aktualisieren
  • A-86 Dialoge und Ablaufsteuerung entwickeln
  • A-174 Enumerationsinhalte (Schlüsseltabellen) neu definieren oder überarbeiten
  • A-206 Systemschnittstelle beschreiben
  • A-246 Subsystemmodell und grobes Geschäftsklassenmodell entwickeln
  • A-251 Geschäftsklassenmodelle konsolidieren
  • A-259 Dialogdoubletten identifizieren
  • A-260 Fachliches Architekturmodell entwickeln
  • A-284 Enumerationen (Schlüsseltabellen) identifizieren
  • A-285 Designklassenmodell restrukturieren
  • Systemerstellung.Subsysteme

    Analyse, Design, Implementierung und Test der einzelnen Subsysteme (oder Komponenten) der zu erstellenden Anwendung

    Jedes Subsystem existiert als eigene Entwicklungsdisziplin, d.h., in einem konkreten Projekt hat die Disziplin Systemerstellung Anschluss für jedes Subsystem eine konkrete Ausprägung. Die einzelnen Subsysteme werden weitgehend entkoppelt und parallel zueinander in eigenen Entwicklungsprozessen/-teams entwickelt.

    Deren Entwicklungen werden regelmäßig zum Iterationsende synchronisiert, ihre Aktivitäten werden durch ein zentrales Iterations-, Prozess- und Änderungsmanagement aufeinander abgestimmt und koordiniert. Ein übergeordneter fachlicher Zusammenhalt wird auch von Aktivitäten der Disziplin Systemerstellung Fachliche Architektur unterstützt.

    Die Anzahl der Subsysteme oder Komponenten ist abhängig von der Größe des Projektes.


  • A-26 Dialog spezifizieren
  • A-67 Zustandsmodell beschreiben
  • A-70 Berichte und Auswertungen entwickeln und testen
  • A-74 Datenbankabfragen identifizieren und spezifizieren
  • A-76 Datenbankabfragen entwickeln und testen
  • A-81 Ausnahmen und mögliche Fehler identifizieren und beschreiben
  • A-134 Fachklasse realisieren und testen
  • A-151 Datenbank-Abbildung (Persistierung) realisieren und testen
  • A-157 Datenbank-Abbildung beschreiben
  • A-165 Primitive Datentypen identifizieren
  • A-173 Enumeration (Schlüsseltabellen) integrieren
  • A-213 Subsystemabhängigkeiten identifizieren und ggf. restrukturieren
  • A-215 Sequenzdiagramm entwickeln
  • A-232 Designklassenmodell und validiertes Subsystemmodell entwickeln
  • A-258 Code-Review durchführen
  • A-286 Interaktionsmodelle erstellen
  • Systemerstellung.Umfeld und Batch

    Diese Disziplin umfasst alle Aktivitäten, die sich mit der Erstellung von Schnittstellen zu vorhandenen umliegenden Systemen befassen, sowie mit der Entwicklung von Batch-Programmen.

    Die Aktivitäten dieser Disziplin beinhalten vor allem die Analyse und Konzeption von Schnittstellen, die Erstellung von Schnittstellenprogrammen, die gekapselte Anbindung externer Systeme und die Entwicklung von Batch-Programmen (d.h. Verarbeitungsprogrammen ohne Benutzungsoberfläche und ohne Benutzerinteraktion).

    Sofern dies keine projektspezifischen, sondern eher allgemeine Schnittstellen sind (beispielsweise Ansteuerung eines zentralen Textsystems, Postkorbs u.Ä.), finden sich die entsprechenden Aktivitäten ggf. in der Disziplin
    Systemerstellung Projektextern/Übergreifend.

    Konzeption und Erstellung von Batch-Programmen werden explizit dieser Disziplin zugeordnet, da sie häufig prozedural (z.B. mit Cobol oder PL/1) entwickelt werden und somit andere Entwicklungsaktivitäten benötigen als die objektorientierten Subsysteme im Rahmen der Disziplin Systemerstellung Subsysteme.


  • A-7 Systemschnittstellen identifizieren und klassifizieren
  • A-48 Adapter für externe Schnittstellen konzipieren, entwickeln und testen
  • A-58 Stapelverarbeitungsprogramme identifizieren und spezifizieren
  • A-59 Stapelverarbeitungsprogramme realisieren und testen
  • Systemerstellung.Technische Architektur

    Konzeption und Entwicklung des Schichtenmodells, vorhandener Frameworks und der Verteilung

    Hierzu gehört beispielsweise die Bereitstellung und Integration von technischen Frameworks, von Basisdiensten und querschnittlichen, anwendungsübergreifenden Funktionalitäten. Beispielsweise Persistenzdienste, Login, Benutzer- und Rechtedienste, Anbindung an Druckstraßen, E-Mail, Client-Server-Kommunikation etc. Ebenso die Festlegung der Verteilung (Deployment), d.h. welche Dienste, Funktionen und Software auf welchen Computern läuft, wie die einzelnen Computer/Knoten verbunden sind usw.


  • A-150 Datenbanken und Datenbankschema einrichten
  • A-187 Technisches Architekturmodell definieren
  • A-287 Interaktionsmodell erstellen
  • Qualitätssicherung, Test, Abnahmen

    Zusammenfassung aller Aktivitäten zur Qualitätssicherung der Ergebnisse der anderen Diziplinen

    Mit jeder Iteration wird die Fertigstellung einer Teilfunktionalität des Gesamtsystems verfolgt. Dazu werden vor einer Iteration die zu erwartenden Ergebnisse explizit festgelegt und am Ende der Iteration die Zielerreichung gemessen bzw. bewertet.

    Diese Disziplin umfasst Aktivitäten, die Beurteilungs-, Entscheidungs- und Testkriterien zur Überprüfung der Iterationsergebnisse festlegen, ggf. Testdaten und -fälle hierzu vorbereiten, die Durchführung von Tests, (Teil-)Abnahmen und Reviews begleiten, sicherstellen und ggf. vorbereiten.

    Ebenso gehören hierzu Aktivitäten, mit denen Entwickler-, Team oder Subsystem-spezifische Tests und QS-Maßnahmen systematisch unterstützt, überwacht und zusammengefasst werden, die Anwendung und Aktualisierung von Entwicklungsrichtlinien u.Ä., Gewährleistung der Revisionsfähigkeit von Projektergebnissen usw.

    Neben der Sicherstellung und Unterstützung, dass Anforderungen und Erwartungen durch das Projekt erfüllt werden, gehört aber auch die systematische Steuerung (d.h. ggf. Ab- und Begrenzung) von Anforderungen und Erwartungen/Erwartungshaltungen seitens des Auftraggebers, Anwenders etc. auf ein für das Projekt realistisches Maß dazu.


  • A-18 Meilensteinerreichung überprüfen
  • A-39 Arbeitsauftragsreview durchführen
  • A-51 Subsystem testen
  • A-61 Testfälle erstellen
  • A-72 Entwicklungsrichtlinien überprüfen
  • A-152 Testplan erstellen
  • A-153 Anwendertest durchführen
  • A-175 Enumerationen testen
  • A-254 Testkonzept entwerfen
  • A-256 Testkonzept erstellen
  • A-257 Testkonzept überarbeiten und anpassen
  • A-261 Meilensteinreview vorbereiten
  • A-262 Produktreview vorbereiten
  • A-263 Produktreview durchführen
  • A-293 Automatischer Systemtest (Regressionstest)
  • A-300 Teststrategie festlegen
  • A-302 Release testen
  • A-303 Release abnehmen
  • Einsatz, Verteilung und Projektexternes

    Vorbereitung der Auslieferung bzw. Produktivsetzung der Software, Verteilung und Installation der Software, Vorbereitung und Durchführung von Schulungen, Unterweisung der Hotline u.Ä., Koordination aller projektexternen Aktivitäten

    Die Einführung einer neuen Software ist in der Regel mit zahlreichen Hindernissen und Widrigkeiten verbunden. Gerade die Ablösung bestehender Software durch eine neue zu einem Stichtag oder innerhalb eines sehr kurzen Zeitraumes bedarf sorgfältiger Vorbereitung. Daten aus den Altsystemen sind maschinell und bereinigt zu konvertieren. Abgesehen von sehr uniformen Netzumgebungen schlägt ein gewisser Prozentsatz der Installationen fehl und erfordert spezielle Unterstützung. Und trotz noch so guter Tests gelingt es den Anwendern leicht, Probleme und Fehler zu produzieren, die im einfachsten Fall nur Missverständnisse oder Bedienfehler darstellen.

    Die Aktivitäten in dieser Disziplin zielen deswegen auf ganz unterschiedliche Bereiche und reichen von Tätigkeiten an Hardware und Netzwerk über die Datenmigration am Wochenende vor der Einführung bis zur Erstellung von Schulungsunterlagen.

    Ebenso umfasst diese Disziplin alle Aktivitäten, die nicht direkt zum Verantwortlichkeitsbereich des Projektes gehören, sondern von anderen Projekten, Abteilungen oder externen Lieferanten zugeliefert werden müssen. Hierzu gehören beispielsweise Erweiterungen und Modifikationen in Standardanwendungen und -funktionen der Systemarchitektur (z.B. Postkorb-Anwendung, Persistenzdienst etc.), notwendige Anpassungen in existierenden Nachbarsystemen, Bereinigung existierender Datenbestände, ggf. grundsätzliche Änderungen der Softwareentwicklungsumgebung (siehe jedoch auch Disziplin
    Konfigurations- und Umgebungsmanagement) etc.


  • A-55 Entwicklung globaler Dienste und Klassen
  • A-95 Projektexterne Anforderungen identifizieren und spezifizieren
  • A-137 Migrationskonzept erstellen
  • A-138 Daten- und Systemmigration vorbereiten
  • A-139 Anwenderdokumentation entwickeln
  • A-140 Anwenderschulung vorbereiten
  • A-141 Anwender schulen
  • A-142 Hotline, Support und Multiplikatoren schulen
  • A-144 Anwendung und Daten migrieren
  • A-265 Übergabe der Projektergebnisse an das Wartungsteam
  • A-266 Projektübergabe an Wartungsteam planen
  • A-267 Roll-Out planen
  • A-268 Roll-Out durchführen
  • A-279 Anwenderfragebögen auswerten
  • A-301 Zulieferleistungen überwachen
  • A-304 Betriebskonzept und -handbuch erstellen
  • A-305 Datenschutzkonzept erstellen
  • A-306 Soziale und systemische Auswirkungen der Systemeinführung berücksichtigen
  • A-307 Change-Management-Konzept umsetzen
  • Konfigurations- und Umgebungsmanagement

    Bereitstellung der Entwicklungsumgebung für alle Projektmitarbeiter und regelmäßige technische Integration des Systems.

    Diese Disziplin umfasst Aktivitäten zur Durchführung der technischen Systemintegration (Build-Prozess), der Versionierung und Konfigurierung von Entwicklungsergebnissen und die Bereitstellung der dafür notwendigen Infrastruktur und Entwicklungsumgebung. Kleinere, vorwiegend projektspezifische Unterstützungsleistungen zur Rationalisierung des Entwicklungsprozesses gehören ebenfalls dazu (z.B. Anpassungen von Generierungsskripten, Werkzeugen etc.).


  • A-23 Architektur und Softwareentwicklungsumgebung evaluieren
  • A-63 Konfigurationsmanagement definieren
  • A-155 Mitarbeiterarbeitsplatz einrichten
  • A-168 Projektumgebung einrichten bzw. anpassen
  • A-292 Daily-Build und Smoketest
  • A-299 Release entwickeln
  • Iterations-, Prozess- und Änderungsmanagement

    Fachliche Planung der Aktivitäten des Projektes hinsichtlich ihrer Zielsetzung und Abhängigkeiten, Reaktion auf Änderungen der Anforderungen und sonstiger Projektbedingungen

    Diese Disziplin umfasst alle Aktivitäten zur inhaltlichen Steuerung und Koordination aller übrigen Projektaktivitäten. Insbesondere die sinnvolle, geordnete und realistische Verteilung der Gesamtanforderungen auf die einzelnen Iterationen, d.h. die inhaltliche Gliederung des Entwicklungsprozesses, die Bewertung tatsächlich erreichter Zwischenergebnisse und die entsprechende Nachsteuerung des Projektes bzw. regelmäßige Neuplanung.

    Im Projektverlauf von außen (Wünsche/Forderungen Auftraggebers, Anwenders oder des Gesetzgebers) oder innen (neue Erkenntnisse über fachliche und technische Zusammenhänge, Möglichkeiten, Begrenzungen etc.) hinzukommende oder entfallende Anforderungen, Risiken oder Chancen sind regelmäßig zu bewerten und ggf. in der Projektplanung zu berücksichtigen.


  • A-12 Gesamtplanung (Makroplan) erstellen bzw. aktualisieren
  • A-16 Iterationen und Builds planen
  • A-46 Arbeitsaufträge für Iteration i+1 erstellen
  • A-179 Anforderungsänderung beurteilen
  • A-193 Tätigkeitsberichte analysieren
  • A-249 Aufwandsschätzworkshop durchführen
  • A-282 Anforderungen ändern oder ergänzen
  • A-283 Anforderungsänderung genehmigen
  • A-294 Arbeitsaufträge für Iteration i+2 erstellen
  • A-295 Wöchentliches Micro-Controlling
  • A-296 Wöchentliche Micro-Steuerung
  • A-297 Arbeitsauftrags-Planungskorrektur
  • Projektmanagement

    Planung und Verwaltung der Ressourcen, Termine, Besetzung und Durchführung aller Aktivitäten des Projektes

    Die Aktivitäten des Projektmanagements sind aufgeteilt in formale, organisatorische und politische Aktivitäten (hier enthalten und beschrieben) sowie in Aktivitäten zur fachlichen und inhaltlichen Steuerung des Projektes (enthalten in der Disziplin Iterations-, Prozess- und Änderungsmanagement).

    Die Motivation zur Trennung diese beiden Teilaspekte resultiert aus der Erfahrung, dass sie zumindest in mittleren und größeren Projekten nicht mehr von einer Person wahrgenommen werden können.

    Zu dieser Disziplin gehören alle Aktivitäten zur Planung, Verwaltung und Organisation der Ressourcen (interne/externe Mitarbeiter, Werkzeuge, Räume etc.), Termine, Besetzung und Durchführung aller Aktivitäten des Projektes, Repräsentation des Projektes nach außen (gegenüber Auftraggeber, Lenkungsausschuss etc.), Wahrnehmung und Durchsetzung von Projektinteressen gegenüber dem Projektumfeld und die Gesamtverantwortung für das Projekt.


  • A-2 Projektziele und Projektauftrag formulieren und iterativ abstimmen
  • A-147 Projektabschlussbericht erstellen
  • A-158 Phasenauftaktveranstaltung
  • A-159 Iterationsauftaktveranstaltung
  • A-172 Monats- bzw. Quartalsbericht erstellen
  • A-181 Mitbestimmungsverfahren einleiten
  • A-182 Personalrat über geplante Anwendung informieren
  • A-183 Lenkungsausschusssitzung
  • A-184 Projektpräsentation vorbereiten und halten
  • A-194 Systemidee und Zielsetzung entwickeln
  • A-250 Risikomanagement-Workshop durchführen (Risiken, Erfolgskriterien)
  • A-252 Neuausrichtungsworkshop durchführen
  • A-253 Projekterfahrungsbericht erstellen
  • A-298 Lenkungsausschuss vorbereiten
  • OEP - Object Engineering Process, v3.0, 06.11.2006 11:03:00, Copyright © 2006 by oose Innovative Informatik eG