Historie der frühen Softwareentwicklungs-Methoden und Notationen von 1990 bis 2005.
Der Rational Unified Process (RUP) war ein kommerzielles Produkt der Firma Rational Software, die 2003 von IBMübernommen wurde. Es beinhaltete sowohl ein Vorgehensmodell zur Softwareentwicklung als auch die dazugehörigen Anwenderprogramme zur Entwicklung von Software. Einzelne Rational-Produkte werden von IBM bis heute weiterentwickelt (Wartung) oder in andere Produkte integriert, teilweise mit anderem Namen. Nach 2021 finden sich die Rational-Werkzeuge in den sogenannten IBM DevOps solutions.
Der RUP selbst besitzt abstrakte Ähnlichkeiten mit dem V-Modell XT, ist aber auf die Nutzung von der Unified Modeling Language (UML) ausgerichtet, welche im Zuge der Entwicklung der Methode entstanden ist. Der iterative Prozess gehört zu den konventionellen Vorgehensweisen und setzt beispielsweise eine stabile Basis der Anforderungen voraus. Er war somit nicht „agil“ und wurde durch den Agile Unified Process (AUP) – unabhängig von IBM – ergänzt. Die Produkte von IBM können jedoch die Entwicklungsmethoden der modernen Softwaretechnik abbilden. RUP wurde durch IBM bis Mitte der 2010er Jahre beworben.
Geschichte
Rückblick: Das Rational R1000 Development System war ein Computer mit einer Ada-basierten Entwicklungsumgebung. Es war der Zeitpunkt Null der modernen Softwareentwicklung. Die Entwicklung von Großrechnern zusammen mit Software fand jedoch bereits früher statt, siehe auch die Geschichte der Rechnerarchitektur. (Foto von 1985)
Der Rational Unified Process (RUP) wurde in seiner Urform erstmals 1998 von Philippe Kruchten vorgestellt. Wenig später begannen drei Softwareentwickler des Unternehmens Rational Software, „die drei Amigos“ Grady Booch, Ivar Jacobson und James Rumbaugh, sich auf ein einheitliches Notationssystem für Entwicklungsprozesse zu einigen. Als Resultat dieser Bemühungen wurde die Unified Modeling Language (UML) erfunden.
Die Standardisierung und Weiterentwicklung der neuen Modellierungssprache UML wurde folglich 1995 bei einem Treffen im Silicon Valley an die Fachorganisation Object Management Group (OMG) übergeben. Mit einer gemeinsamen Sprache konnte nun eine gemeinsame (objektorientierte) Methode entwickelt werden.
Der Unified Process (UP) gilt dabei als ein Metamodell für Vorgehensmodelle zur Softwareentwicklung und ist aus diesen frühen Bemühungen entstanden. Er wurde parallel zu UML von den drei Amigos entwickelt und veröffentlicht. UP war die Grundlage des Rational Unified Process (RUP), einer Adaption bzw. einem Derivat von Rational Software und ihren Softwareprodukten. Noch weiter zurück (1988) liegt jedoch der Objectory-Prozess von Ivar Jacobson. Er ging im „RUP 5.0“ als Teil von Rational auf. Der RUP konkurrierte damals z. B. mit dem V-Modell.
Ein weiterer Ableger der UP-Methode ist der Open Unified Process (OpenUP) für Open-Source-Software-Projekte (OSS), die außerhalb des kommerziellen Umfelds von Rational oder IBM stattfinden.
IBM entwickelt nach der Übernahme von Rational Software den Rational Unified Process (RUP) zunächst weiter. Der Prozess war bis Mitte der 2010er Jahre verfügbar und danach stillgelegt. RUP benutzt die Unified Modeling Language(UML) als Notationssprache, welche sich weltweit bis heute behauptet hat. Die ursprünglichen Rational-Programme sind teilweise weiterhin unter den Namen „Rational NNN“, z. B. Rational ClearQuest, bei IBM verfügbar und bieten einen integrierten Entwicklungsumgebung an. Weitere Werkzeuge, wie Rational Rapshody oder Rational DOORS, zählen zu der IBM Engineering Lifecycle Management Suite. Prozessuale Aspekte wurden Teil des IBM Engineering Workflow Management.
Prozesse
Unified Process
Der Unified Process (UP) basiert auf den folgenden Prinzipien:
Eine konkrete Implementierung des UP war der Rational Unified Process (RUP). Die erste Version des RUP aus dem Jahre 1999 überführte die drei Vorschläge in eine einheitliche Modellierungsmethode, die Unified Modeling Language (UML).
Rational Unified Process
Statische Aspekte
Die Arbeitsschritte werden für jede Iteration in neun Disziplinen eingeteilt:
Entwicklungsumgebung, Werkzeugunterstützung und qualitätssichernde Maßnahmen (Environment & Quality Management)
Dynamische Aspekte
RUP-Elemente in einem Chart: Die temporalen Aspekte sind horizontal, die fixen vertikal dargestellt. Der Prozess beginnt bei I1 und endet bei T2. In Phase I1 liegt der Fokus auf dem Projektauftrag und den Anforderungen. Die gezeigten Phasen sind auch in modernen Entwicklungsprojekten noch relevant, wobei Risiken und Änderungen der Anforderungen laufend nachgezogen werden (Agilität).
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:
Initialisierung (I1): In dieser ersten Konzeptionsphase wird eine Vision bzw. ein Ziel ausgearbeitet und ein oder mehrere rudimentäre Anwendungsfälle erstellt, die die wesentlichen Funktionalitäten der Software beschreiben. Außerdem wird eine vorläufige Softwarearchitektur entworfen. Darüber hinaus werden die wesentlichsten Risiken identifiziert und die Ausarbeitungsphase geplant. Sie resultiert im Lifecycle Objective Milestone.
Ausarbeitung (E1–E2): In dieser Phase werden der Architekturprototyp sowie eine detaillierte Beschreibung für etwa 80 Prozent der Anwendungsfälle ausgearbeitet. Hier erfolgt die Planung der Konstruktionsphase. Ergebnis dieser Entwurfsphase ist der Lifecycle Architecture Milestone.
Konstruktion (C1–C4): Nachdem die Architektur ausgearbeitet wurde, konzentriert sich diese Phase auf die Softwareentwicklung und das Testen der Software. Hier entsteht die erste lauffähige Version der Software und schließt mit dem Initial Operational Capability Milestone ab.
Übergang (T1–T2): Übergabephase und Auslieferung der Software an den Kunden. Der Prozess endet mit dem Product Release Milestone.
Best Practices
Der Rational Unified Process (RUP) greift auf in der Praxis bewährte Vorgehensweisen und Erfahrungswerte zurück. Diese werden in den folgenden sechs Best Practices formuliert:
Projektbegleitendes Qualitätsmanagement mit dem Ziel der frühzeitigen Fehlererkennung.
KomponentenbasierteArchitektur: Komponenten oder Module 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 Softwaresystems. Es ist eine Managementdisziplin um Änderungen zu erkennen, organisieren und durchzuführen. Es dient der besseren Kontrolle über Veränderungen, einer verbesserter Softwarequalität und höherer Kundenzufriedenheit.
Kontroversen
Selbst umfangreiche Prozesse wie der RUP wurden von Softwareexperten kritisch hinterfragt.
Rational Unified Process: Best Practices for Software Development Teams. Rational Software / IBM, Cupertino, CA 1998 (englisch, archive.org[PDF]).
Ivar Jacobson, Stefan Bylund:The Road to the Unified Software Development Process (=SIGS Reference Library Series). Rev. Auflage. Cambridge University Press SIGS books, Cambridge 2000, ISBN 978-0-521-78774-1 (englisch, archive.org).
Wolfgang Zuser, Thomas Grechenig, Monika di Angelo:Software Engineering mit UML und dem Unified Process (=Informatik Softwaretechnik). 2. Auflage. Pearson Studium, München 2004, ISBN 978-3-8273-7090-7.
Per Kroll, Philippe Kruchten:The Rational Unified Process Made Easy: A Practitioner’s Guide to the RUP (=The Addison-Wesley Object Technology Series). Addison-Wesley, Boston, MA 2005, ISBN 978-0-321-16609-8 (archive.org).
IBM:Rational Business Driven Development for Compliance (now archived) (=An IBM Redbooks publication). Finale Auflage. IBM, 2006, ISBN 0-7384-9657-X (englisch, ibm.com).
Andreas Essigkrug, Thomas Mey:Rational Unified Process kompakt. 2. Auflage. Spektrum, Akademischer Verlag, Heidelberg 2009, ISBN 978-3-8274-1836-4.
Jim Arlow, Ila Neustadt:UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (=The Addison-Wesley Object Technology Series). 2. Auflage. Addison-Wesley, Upper Saddle River, NJ 2013, ISBN 978-0-321-32127-5 (englisch, archive.org).
Stephan Kleuker:Grundkurs Software-Engineering mit UML: Der pragmatische Weg zu erfolgreichen Softwareprojekten. 5. Auflage. Springer Fachmedien Wiesbaden, Wiesbaden 2025, ISBN 978-3-658-46533-9, doi:10.1007/978-3-658-46534-6.
↑Gerhard Versteegen:Einführung des Rational Unified Process. In: Projektmanagement mit dem Rational Unified Process. Springer Berlin Heidelberg, Berlin, Heidelberg 2000, ISBN 978-3-642-63092-7, S.223–237, doi:10.1007/978-3-642-56954-8_8 (springer.com[abgerufen am 22.August 2026]).
↑Stephan Kleuker:Grundkurs Software-Engineering mit UML: Der pragmatische Weg zu erfolgreichen Softwareprojekten. 5. Auflage. Springer Fachmedien Wiesbaden, Wiesbaden 2025, ISBN 978-3-658-46533-9, doi:10.1007/978-3-658-46534-6 (springer.com[abgerufen am 22.August 2026]).
↑John Hunt:An Introduction to the UML and the Unified Process. In: Guide to the Unified Process featuring UML, Java and Design Patterns. Springer-Verlag, London 2003, ISBN 978-1-85233-721-6, S.21–37, doi:10.1007/1-85233-856-3_3 (englisch, springer.com[abgerufen am 22.August 2026]).
↑Wolfgang Hesse:Software-Projektmanagement braucht klare Strukturen - Kritische Anmerkungen zum "Rational Unified Process". In: Jürgen Ebert, Ulrich Frank (Hrsg.): Modelle und Modellierungssprachen in Informatik und Wirtschaftsinformatik: Beiträge des Workshops "Modellierung 2000" St. Goar. Fölbach, Koblenz 2000, ISBN 978-3-934795-15-0, S.143–150 (uni-marburg.de[PDF; abgerufen am 22.August 2026]).
