Rational Unified Process (RUP)Der Rational Unified Process (RUP) ist ein objektorientiertes, aktivitätsgetriebenes Vorgehensmodell, das seit 1999 von Rational (später IBM Rational) gepflegt und als kommerzielles Produkt vertrieben wird. Er ist eine konkrete Implementierung des Unified Process. RUP ist sehr stark auf die Unified Modelling Language (UML) geprägt und liefert eine Methode zur Softwareentwicklung auf Basis der UML. RUP ist somit ein spezifisches Vorgehensmodell für die UML-basierten Softwareentwicklung. Grundkonzepte und PhasenRUP deckt weite Teile des Softwarelebenszyklus ab. Er unterscheidet zwischen einzelnen Lebenszyklusabschnitten (Phasen) inkl. der Iterationen in den einzelnen Abschnitten. Orthogonal dazu sind die Disziplinen positioniert, die in einem Projekt nach RUP die Aktivitäten bündeln. Zusammen ergeben sie das bekannte RUP-Gebirge (siehe [Kruchten 2003]). Im Kern folgt der RUP den folgenden drei Grundprinzipien:
Phasen und MeilensteineAbschnitte im Lebenszyklus eines Projekts bezeichnet RUP als Phasen. RUP untergliedert ein Projekt in die folgenden vier Phasen:
In jeder der vier Phasen werden Aktivitäten (Arbeitsschritte) einzelner Disziplinen gebündelt. Weiterhin sind die einzelnen Phasen in Iterationen unterteilt. Jede Iteration schließt mit einem Meilenstein (Business Decision Point) ab:
Im ersten Meilenstein (lifecycle objectives) erwartet RUP die folgenden Ergebnisse: eine Projektvision inklusive eines rudimentären Anwendungsfallmodells, das die wesentliche Funktionalität des Zielsystems beschreibt. Zum Einsatz kommen hier üblicherweise UML-Anwendungsfalldiagramme. Weiterhin ist bereits ein erster, grober Architekturentwurf (z.B. mithilfe von UML-Komponenten- oder Klassendiagrammen) zu liefern. Organisatorisch soll hier bereits eine erste Identifikation relevanter Projektrisiken vorliegen. Im zweiten Meilenstein (lifecycle architecture) ist ein Architekturprototyp vorzulegen. Weiterhin soll das initiale Anwendungsfallmodell weiter verfeinert werden. Organisatorisch ist zu diesem Meilenstein eine detaillierte Arbeitsplanung für die folgende Konstruktionsphase vorzulegen. Aus der Architektur sind daher bereits Arbeitspakete abzuleiten. Der dritte Meilenstein (initial operational capability) fordert detaillierte Entwurfsmodelle (in verschiedenen UML-Diagrammtypen) und eine Beta-Version der Software. Während im vierten Meilenstein (product release) bereits eine produktive Software vorliegen soll. DisziplinenRUP definiert die folgenden Disziplinen:
Diesen Kerndisziplinen ordnet RUP auch die Phasen zu, in denen sie schwerpunktmäßig bearbeitet werden. Unterstützende Arbeitsschritte, die unabhängig von einzelnen Phasen und somit querschnittlich im Projekt sind, ordnet RUP wie folgt ein:
Die Disziplin Environment hat den Schwerpunkt, sicherzustellen, dass im Projekt alle benötigte Infrastruktur vorhanden ist. Unter Infrastruktur wird im RUP eine abgestimmte Kombination aus Werkzeugen, Prozessen und Methoden verstanden, die das Team benötigt, um das Projekt erfolgreich bearbeiten zu können. Aktivitäten, Artefakte und RollenRUP ist ein sog. aktivitätsgetriebener Entwicklungsprozess (im Gegensatz zum V-Modell XT, das ein produktzentrierter Entwicklungsprozess ist). Rollen, die im RUP definiert sind, sind also dafür zuständig, Aktivitäten durchzuführen, die im RUP detailliert beschrieben sind. Aktivitäten sind in festgelegten Reihenfolgen und Schritten zu absolvieren. Sie sind eindeutig bestimmten Phasen im Prozess zugeordnet. Aktivitäten erwarten bestimmte Artefakte als Eingabe und produzieren eine Menge festgelegter Artefakte als Ausgabe. Diese sind dann wieder Eingabe für Folgeaktivitäten. Die Kombination und Verknüpfung der Aktivitäten wird durch Workflows beschrieben, die gleichzeitig auch die Rollen, die mitwirken, einbinden. Abb. 1: Rollen und Artefakte im Unified Process (Beispiel: OpenUP) Open Unified ProcessDer Open Unified Process (OpenUP) ist eine Teilmenge des Rational Unified Process, die im Rahmen des Eclipse Process Frameworks [Eclipse Foundation 2009] gepflegt wird. Er enthält eine Reihe der grundlegenden Praktiken des RUP, insbesondere:
OpenUP beschränkt sich auf die wesentlichen Kernbestandteile des RUP und skaliert auch für kleine, eher agile Projekte, die durch kleinere Teams durchgeführt werden. Abb. 2: OpenUP im Eclipse Process Framework Grundlage des OpenUP und auch des RUP ist der Method Composer, der als Werkzeug das Software Process Engineering Metamodel (SPEM) implementiert. Auf dieser Basis lassen sich verschiedene neue Methoden implementieren und OpenUP bzw. RUP hinzufügen. So existieren bereits Implementierungen für Scrum und XP. LiteraturKruchten, Philippe:The Rational Unified Process. An Introduction. Addison-Wesley Longman, Amsterdam, 2003. Eclipse Foundation: Eclipse Process Framework. http://www.eclipse.org/epf/, 02.10.2009. Autor![]() Dr. Marco Kuhrmann, Technische Universität München, Institut für Informatik, Boltzmannstr. 3, 85748 Garching |