Bibtex

@InCollection{,
  Year    = "2019", 
  Title    = "Rational Unified Process (RUP)", 
  Author    = "Kuhrmann, Prof. Dr. Marco", 
  Booktitle    = "Gronau, Norbert ; Becker, Jörg ; Kliewer, Natalia ; Leimeister, Jan Marco ; Overhage, Sven (Herausgeber): Enzyklopädie der Wirtschaftsinformatik – Online-Lexikon",
  Publisher    = "Berlin : GITO",
  Url    = "https://wi-lex.de/index.php/lexikon/entwicklung-und-management-von-informationssystemen/systementwicklung/vorgehensmodell/rational-unified-process-rup/", 
  Note    = "[Online; Stand 7. October 2024]",
}

Rational Unified Process (RUP)

Marco Kuhrmann


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 Phasen

RUP 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:

  • RUP ist Anwendungsfall-getrieben.
  • Die Architektur steht im Zentrum der Planung.
  • Das Vorgehen zur Entwicklungszeit ist iterativ/inkrementell.

Phasen und Meilensteine

Abschnitte im Lebenszyklus eines Projekts bezeichnet RUP als Phasen. RUP untergliedert ein Projekt in die folgenden vier Phasen:

  • Inception (Konzeptionsphase)
  • Elaboration (Entwurfsphase)
  • Construction (Konstruktionsphase)
  • Transition (Übergabephase)

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:

  • Lifecycle Objectives 
  • Lifecycle Architecture 
  • Initial Operational Capability (Entwurfsmodelle und Beta-Release der Software)
  • Product Release 

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.

Disziplinen

RUP definiert die folgenden Disziplinen:

  • Business Modeling (Geschäftsprozessmodellierung) – Ziel ist das Erreichen des Verständnisses für die Geschäftsprozesse zu erreichen.
  • Requirements (Anforderungsanalyse) – Die Anforderungen werden erfasst, dokumentiert, organisiert und im Projekt nachverfolgt.
  • Analysis & Design – Die fachliche Architektur wird in ein technisches Design überführt.
  • Implementation (Implementierung) – Es wird iterativ ein lauffähiges Softwaresystem erstellt
  • Test – Das Softwaresystem wird getestet.
  • Deployment (Auslieferung) – Das Softwaresystem wird an den Kunden ausgeliefert.

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:

  • Configuration & Change Management (Konfigurations- und Änderungsmanagement) – Alle Projektartefakte, Änderungsforderungen und so weiter werden im System organisiert und verwaltet.
  • Project Management – Das Projektmanagement wird im Projekt installiert und durchgesetzt.
  • Environment (Infrastruktur) – Die Infrastruktur für das Projekt wird bereitgestellt und gepflegt.

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 Rollen

RUP 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.

OpenUP Roles

Abb. 1: Rollen und Artefakte im Unified Process (Beispiel: OpenUP)

Open Unified Process

Der 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:

  • Inkrementell/interative Softwareentwicklung
  • Anwendungsfall- und szenariobasierte Entwicklung
  • Architekturgetriebenes Vorgehen

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.

OpenUP EPF

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.


Literatur

Kruchten, 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.

Hier weiterverbreiten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert