Rational Unified Process

Datei:OO-historie-2.svg

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.<ref></ref> Es beinhaltete sowohl ein Vorgehensmodell zur Softwareentwicklung als auch die dazugehörigen Anwenderprogramme zur Entwicklung von Software.<ref name=":0">[ ] , archiviert vom Vorlage:Referrer (nicht mehr online verfügbar) am 2014-10-05; abgerufen (). </ref><ref></ref> Einzelne Rational-Produkte werden von IBM bis heute weiterentwickelt (Wartung) oder in andere Produkte integriert, teilweise mit anderem Namen.<ref> In: ; ehemals im Vorlage:Referrer (nicht mehr online verfügbar); abgerufen ().Vorlage:Toter Link/Core (Seite nicht mehr abrufbar. Suche im Internet Archive) </ref><ref> In: ; ehemals im Vorlage:Referrer (nicht mehr online verfügbar); abgerufen ().Vorlage:Toter Link/Core (Seite nicht mehr abrufbar. Suche im Internet Archive) </ref> Nach 2021 finden sich die Rational-Werkzeuge in den sogenannten IBM DevOps solutions.<ref> In: ; ehemals im Vorlage:Referrer (nicht mehr online verfügbar); abgerufen ().Vorlage:Toter Link/Core (Seite nicht mehr abrufbar. Suche im Internet Archive) </ref>

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.<ref></ref> 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.<ref name=":0" />

Geschichte

Datei:Rational R1000 Development System.jpg

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.<ref>Vgl. The Rational Unified Process: An Introduction (1. Auflage von 1998)</ref> 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.<ref> In: Ehemals im Vorlage:Referrer (nicht mehr online verfügbar); abgerufen ().Vorlage:Toter Link/Core (Seite nicht mehr abrufbar. Suche im Internet Archive) </ref> 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.<ref>Scott Ambler: ; ehemals im Vorlage:Referrer (nicht mehr online verfügbar); abgerufen ().Vorlage:Toter Link/Core (Seite nicht mehr abrufbar. Suche im Internet Archive) </ref> Er ging im „RUP 5.0“ als Teil von Rational auf. Der RUP konkurrierte damals z. B. mit dem V-Modell.<ref> In: ; ehemals im Vorlage:Referrer (nicht mehr online verfügbar); abgerufen .Vorlage:Toter Link/Core (Seite nicht mehr abrufbar. Suche im Internet Archive) </ref>

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.<ref name=":0" /><ref>Scott Ambler: ; ehemals im Vorlage:Referrer (nicht mehr online verfügbar); abgerufen ().Vorlage:Toter Link/Core (Seite nicht mehr abrufbar. Suche im Internet Archive) </ref> RUP benutzt die Unified Modeling Language (UML) als Notationssprache, welche sich weltweit bis heute behauptet hat.<ref></ref> 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.<ref> In: ; ehemals im Vorlage:Referrer (nicht mehr online verfügbar); abgerufen ().Vorlage:Toter Link/Core (Seite nicht mehr abrufbar. Suche im Internet Archive) </ref>

Prozesse

Unified Process

Der Unified Process (UP) basiert auf den folgenden Prinzipien:<ref></ref>

• Anwendungsfälle
• Architektur im Zentrum der Planung
• Inkrementelles oder iteratives Vorgehen
• Risiko-getrieben

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:

Entwicklungsarbeitsschritte (Engineering Disciplines):

1. Unternehmensplan/Geschäftsmodell: Aufgabe, Ziel und Strategie des geplanten Produkts oder Geschäfts sowie eine abgeleitete Geschäftsprozessmodellierung
2. Spezifikation des Anwendungsmodells: Anwendungsfunktionen zur Umsetzung von Workflows/Vorgänge bzw. formalisierte Geschäftsprozesse
3. Spezifikation der Softwarearchitektur: Grobarchitektur: Teilsysteme für Oberfläche, Funktionalität und Datenverwaltung sowie Nutzer- und Basismaschinen; Feinarchitektur: Objektklassen, Softwarekomponenten und Beziehungen
4. Realisierung von Softwareschichten: Implementierung der Computerprogramme
5. Durchführung von Softwaretests auf verschiedenen Ebenen (Unit, Integration, System)
6. Test für die Abnahme, Installation, Schulung und Einweisung

Unterstützende Arbeitsschritte (Supporting Disciplines):

1. Konfigurations- und Änderungsmanagement
2. Projektmanagement
3. Entwicklungsumgebung, Werkzeugunterstützung und qualitätssichernde Maßnahmen (Environment & Quality Management)

Dynamische Aspekte

Datei:Development-iterative.png

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:

1. 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.
2. 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.
3. 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.
4. Ü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:

• 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 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.<ref></ref>

Siehe auch

• Liste von Softwareentwicklungsprozessen

Weblinks

• ; ehemals im Vorlage:Referrer (nicht mehr online verfügbar); abgerufen ().Vorlage:Toter Link/Core (Seite nicht mehr abrufbar. Suche im Internet Archive) 

Einzelnachweise

<references />