Rational Unified Process

Der Rational Unified Process (RUP) ist ein kommerzielles Produkt der Firma Rational Software, die seit 2003 Teil des IBM-Konzerns ist. Es beinhaltet sowohl ein Vorgehensmodell zur Softwareentwicklung als auch die dazugehörigen Softwareentwicklungsprogramme. IBM entwickelt den RUP und die zugehörige Software weiter. Die 9. Version ist die seit 2006 aktuelle Version. Der RUP benutzt die Unified Modeling Language (UML) als Notationssprache. Der RUP wurde von Philippe Kruchten in seiner Urform erstmals 1998 vorgestellt.

Entstehungsgeschichte[Bearbeiten | Quelltext bearbeiten]

Der Grundstein für RUP wurde gelegt, als sich die bekannten Programmierer Grady Booch, Ivar Jacobson und James Rumbaugh („Die drei Amigos“) des Unternehmens Rational Inc. auf ein einheitliches Notationssystem einigten. Als Resultat dieser Bemühungen entstand die UML. Die Standardisierung und Weiterentwicklung der Sprache wurde an die Object Management Group (OMG) übergeben. Mit einer gemeinsamen Sprache konnte nun eine gemeinsame objektorientierte Methode entwickelt werden. Der Unified Process ist dabei ein Metamodell für Vorgehensmodelle zur Softwareentwicklung. Der Unified Process wurde parallel zur Unified Modelling Language von Ivar Jacobson, Grady Booch und James Rumbaugh entwickelt und veröffentlicht.

Der Unified Process basiert auf den folgenden Prinzipien:

• Anwendungsfälle
• Architektur im Zentrum der Planung
• inkrementelles und iteratives Vorgehen

Eine konkrete Implementierung des Unified Process ist der Rational Unified Process. Die erste Version des RUP aus dem Jahre 1999 führte die Vorschläge dieser drei Begründer für eine einheitliche Modellierungsmethode zusammen.

Statische Aspekte[Bearbeiten | Quelltext bearbeiten]

Die Arbeitsschritte werden für jede Iteration in neun Disziplinen eingeteilt:

Kernarbeitsschritte (engineering disciplines):

• Unternehmensplan/Geschäftsmodell: Aufgabe, Ziel und Strategie des Geschäfts sowie eine abgeleitete Geschäftsprozessmodellierung (Business Modeling)
• Spezifikation des Anwendungsmodells: Anwendungsfunktionen zur Umsetzung von Workflows/Vorgänge bzw. formalisierte Geschäftsprozesse (Requirements)
• Spezifikation der Software-Architektur: Grobe Architektur: Teilsysteme für Oberfläche, Funktionalität und Datenverwaltung sowie Nutzer- und Basismaschinen; Feine Architektur: Objektklassen, Softwarekomponenten und Beziehungen (Analysis & Design)
• Realisierung von Softwareschichten: (Computer-)Programme (Implementation)
• Durchführung von Programm-, Modul- und Integrationstests (Tests)
• Abnahmetest, Installation, Schulung und Einweisung (Deployment)

Unterstützende Arbeitsschritte (supporting disciplines):

• Konfigurations- und Änderungsmanagement (Configuration & Change Management)
• Projektmanagement (Project Management)
• Entwicklungsumgebung, Werkzeugunterstützung und qualitätssichernde Maßnahmen(Environment & Quality Management)

Dynamische Aspekte[Bearbeiten | Quelltext bearbeiten]

Orthogonal dazu gibt es im RUP vier Phasen, in denen jeder der oben genannten Arbeitsschritte mehr oder weniger intensiv zur Anwendung kommt. Jede dieser Phasen ist in eine oder mehrere Iterationen unterteilt und resultiert in einem Meilenstein (englisch milestone).

Inception[Bearbeiten | Quelltext bearbeiten]

Diese erste Konzeptionsphase dient dem Ausformulieren einer Vision, eines klaren Zieles sowie der Erstellung eines rudimentären Anwendungsfallmodells, das die wesentliche Funktionalität beschreibt sowie einer tentativen/provisorischen Architektur. Darüber hinaus werden die wesentlichsten Risiken identifiziert und die Ausarbeitungsphase geplant. Sie resultiert im Lifecycle Objective Milestone.

Elaboration[Bearbeiten | Quelltext bearbeiten]

In dieser Phase werden der Architekturprototyp sowie eine detaillierte Beschreibung für etwa 80 Prozent der Anwendungsfälle^[1] ausgearbeitet. Hier erfolgt die Planung der Konstruktionsphase. Ergebnis dieser Entwurfsphase ist der Lifecycle Architecture Milestone.

Construction[Bearbeiten | Quelltext bearbeiten]

Nachdem die Architektur ausgearbeitet wurde, konzentriert sich diese Phase auf die Entwicklung und das Testen des Produktes. Hier entsteht die erste lauffähige Version der Software und schließt mit dem Initial Operational Capability Milestone ab.

Transition[Bearbeiten | Quelltext bearbeiten]

Übergabephase und Auslieferung der Software an den Kunden. Der Prozess endet mit dem Product Release Milestone.

Best Practices[Bearbeiten | Quelltext bearbeiten]

Der Rational Unified Process greift auf in der Praxis bewährte Vorgehensweisen und Erfahrungswerte zurück.^[2] Diese werden in den folgenden sechs Best Practices formuliert:

• Iterative Softwareentwicklung, wodurch im Gegensatz zu linearen Vorgehensmodellen (wie etwa dem Wasserfallmodell) sich ändernde Anforderungen auch zu einem späteren Zeitpunkt noch berücksichtigt werden können.
• Projektbegleitendes Qualitätsmanagement mit dem Ziel der frühzeitigen Fehlererkennung.
• Komponentenbasierte Architektur: Komponenten werden sowohl isoliert entwickelt als auch getestet und tragen so zur Wiederverwendbarkeit des Produkts und der Produktivitäts- und Qualitätssteigerung bei.
• Visuelle Modellierung für ein besseres Problemverständnis. Meist unter Einsatz der standardisierten Modellierungssprache UML. Dadurch wird eine parallele Entwicklung in verschiedenen Fachbereichen ermöglicht.
• Kontrolliertes Änderungsmanagement: um Änderungen zu verwalten und Altstände reproduzierbar zu machen.
• Anforderungsmanagement: Anforderungen sind die Grundlage des Systems. Ansatz um Änderungen zu erkennen, organisieren und durchzuführen. Dient der besseren Kontrolle, verbesserter Qualität und Kundenzufriedenheit.

Siehe auch[Bearbeiten | Quelltext bearbeiten]

• Wasserfallmodell
• V-Modell
• Open Unified Process

Literatur[Bearbeiten | Quelltext bearbeiten]

• Jim Arlow, Ila Neustadt: UML 2 and the Unified Process. Practical object-oriented Analysis and Design. 2nd edition. Addison-Wesley Professional, Upper Saddle River NJ u. a. 2005, ISBN 0-321-32127-8.
• Andreas Essigkrug, Thomas Mey: Rational Unified Process kompakt. Spektrum Akademischer Verlag, Heidelberg u. a. 2003, ISBN 3-8274-1440-7.
• Peter Hruschka, Chris Rupp, Gernot Starke: Agility kompakt. Tipps für erfolgreiche Systementwicklung. Spektrum Akademischer Verlag, Heidelberg u. a. 2004, ISBN 3-8274-1483-0.
• Ivar Jacobson, Grady Booch, James Rumbaugh: The unified software development process. UML. Addison-Wesley, Reading MA u. a. 1999, ISBN 0-201-57169-2.
• Per Kroll, Philippe Kruchten: The Rational Unified Process Made Easy. A Practitioner's Guide to the RUP. Addison-Wesley, Boston MA u. a. 2003, ISBN 0-321-16609-4.
• Philippe Kruchten: The rational unified process. (An introduction). Addison-Wesley, Reading MA u. a. 1998, ISBN 0-201-60459-0.
• Markus Reinhold: Rational Unified Process 2000 versus V-Modell'97: A Comparison of the two most common used Process Models in Germany. In: Ralf Kneuper, Manuela Wiemers (Hrsg.): Leichte Vorgehensmodelle. Workshop der Fachgruppe 5.11 der Gesellschaft für Informatik e.V. (GI) 8. Shaker, Aachen 2001, ISBN 3-8265-8577-1, S. 111ff.
• Gerhard Versteegen: Projektmanagement mit dem Rational Unified Process. Springer, Berlin u. a. 2000, ISBN 3-540-66755-5.
• Wolfgang Zuser, Thomas Grechenig, Monika Köhle: Software Engineering mit UML und dem Unified Process. 2. überarbeitete Auflage. Pearson Studium, München u. a. 2004, ISBN 3-8273-7090-6.

Weblinks[Bearbeiten | Quelltext bearbeiten]

• Rational Software Corporation Homepage (englisch)
• Rational Unified Process (englisch)
• IBM Redbooks publication: Rational Business Driven Development for Compliance (englisch)

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

1. ↑ Andreas Essigkrug, Thomas Mey: Rational Unified Process kompakt, S. 15
2. ↑ Andreas Essigkrug, Thomas Mey: Rational Unified Process kompakt, S. 3