Rational Unified Process (RUP) ist ein wiederholendes Softwareentwicklungsprozess-Fachwerk, das von Rational Software Corporation, einer Abteilung von IBM seit 2003 geschaffen ist. RUP ist kein einziger konkreter verordnender Prozess, aber eher ein anpassungsfähiges Prozess-Fachwerk, beabsichtigt, um von den Entwicklungsorganisationen und Softwareprojektmannschaften geschneidert zu werden, die die Elemente des Prozesses auswählen werden, die für ihre Bedürfnisse passend sind. RUP ist eine spezifische Durchführung des Vereinigten Prozesses.

Geschichte

Rational Unified Process (RUP) ist ein Softwareprozess-Produkt, das ursprünglich durch die Vernünftige Software entwickelt ist, die von IBM im Februar 2003 erworben wurde. Das Produkt schließt verbundene Kenntnisse-Basis eines hyper mit Beispielkunsterzeugnissen und Detaillieren für viele verschiedene Typen von Tätigkeiten ein. RUP wird in IBM Rational Method Composer (RM C) Produkt eingeschlossen, das Anpassung des Prozesses erlaubt.

Das Kombinieren der Erfahrungsbasis von Gesellschaften hat zur Aussprache von sechs besten Methoden für die moderne Softwaretechnik geführt:

1. Entwickeln Sie sich wiederholend, mit der Gefahr als der primäre Wiederholungsfahrer
2. Führen Sie Voraussetzungen
3. Verwenden Sie eine teilbasierte Architektur
4. Mustersoftware visuell
5. Prüfen Sie unaufhörlich Qualität nach
6. Kontrolle ändert

Diese besten Methoden sowohl haben die Entwicklung der Produkte von Rational gesteuert, als auch wurden von den Feldmannschaften von Rational verwendet, um Kunden zu helfen, die Qualität und Voraussagbarkeit ihres Softwareentwicklungsaufwandes zu verbessern. Um diese Kenntnisse zugänglicher zu machen, wurde Philippe Kruchten, ein Vernünftiger techrep, mit dem Zusammenbau eines ausführlichen Prozess-Fachwerks für die moderne Softwaretechnik beschäftigt. Diese Anstrengung hat den HTML-BASIERTEN von Objectory entwickelten Prozess-Liefermechanismus verwendet. Der resultierende "Vernünftige Vereinigte Prozess" (RUP) hat einen strategischen Dreifuß für den Vernünftigen vollendet:

• ein Tailorable-Prozess, der Entwicklung geführt

hat

• Werkzeuge, die die Anwendung dieses Prozesses automatisiert

haben

• Dienstleistungen, die Adoption sowohl des Prozesses als auch der Werkzeuge beschleunigt haben.

RUP wurde 1996 geschaffen, als Vernünftig den Objectory-Prozess erworben hat, der von Ivar Jacobson geschrieben worden war.

Die ursprüngliche Version hat sich größtenteils zufrieden von der Annäherung von Object Modeling Technology (OMT) von Jim Rumbaugh bis das Modellieren, die Annäherung und UML von Booch von Grady Booch 1.0 vereinigt.

1997 wurden Voraussetzungen und Testdisziplin zur Annäherung hinzugefügt.

1998 haben sie zwei neue Disziplinen hinzugefügt: Das Geschäftsmodellieren, von dem viel bereits im Objectory-Prozess und einer Konfigurations- und Änderungsverwaltungsdisziplin gewesen war. Sie haben auch mehr Techniken einschließlich der Leistungsprüfung, des UI Designs, der Datentechnik hinzugefügt und haben RUP zu UML 1.1 aktualisiert.

1999 haben sie eine Projektverwaltungsdisziplin hinzugefügt und haben Techniken für die Echtzeitsoftwareentwicklung hinzugefügt. Sie haben auch RUP zu UML 1.3 aktualisiert

Von 2000 auf waren die meisten Modifizierungen um das Hinzufügen von Techniken, "Werkzeug-Mentoren" mit nach und nach Handbüchern zum Verwenden Vernünftiger Werkzeuge und im Automatisieren der Anpassung von RUP in einem Weg hinzufügend, der Kunden erlauben würde, ihre Version, aber noch amtlich eingetragene Verbesserungen in nachfolgenden Ausgaben vom Vernünftigen kundengerecht anzufertigen.

Vernünftige Vereinigte Prozess-Themen

RUP Bausteine

RUP basiert auf einer Reihe von Bausteinen oder zufriedenen Elementen, beschreibend, was, die notwendigen Sachkenntnisse erforderlich und die schrittweise Erklärung erzeugt werden soll, die beschreibt, wie spezifische Entwicklungsziele erreicht werden sollen. Die Hauptgebäude-Blöcke oder zufriedene Elemente, sind der folgende:

• Rollen (wer) - Eine Rolle eine Reihe zusammenhängender Sachkenntnisse, Befähigung und Verantwortungen definiert.
• Arbeitsprodukte (was) - Ein Arbeitsprodukt etwas vertritt, sich aus einer Aufgabe, einschließlich aller Dokumente und erzeugter Modelle ergebend, während es durch den Prozess arbeitet.
• Beansprucht stark (wie) - Eine Aufgabe eine Einheit der Arbeit beschreibt, die einer Rolle zugeteilt ist, die ein bedeutungsvolles Ergebnis zur Verfügung stellt.

Innerhalb jeder Wiederholung werden die Aufgaben in neun Disziplinen kategorisiert:

• Sechs "Technikdisziplinen"
• Geschäft, modellierend
• Voraussetzungen
• Analyse und Design
• Durchführung
• Test
• Aufstellung
• Drei Unterstützen-Disziplinen
• Konfiguration und Änderungsverwaltung
• Projektmanagement
• Umgebung

Vier Projektlebenszyklus-Phasen

Der RUP hat einen Projektlebenszyklus bestimmt, der aus vier Phasen besteht. Diese Phasen erlauben dem Prozess, an einem hohen Niveau auf eine ähnliche Weise dazu präsentiert zu werden, wie ein 'Wasserfall '-styled Projekt präsentiert werden könnte, obwohl hauptsächlich der Schlüssel zum Prozess in den Wiederholungen der Entwicklung liegt, die innerhalb von allen Phasen liegen. Außerdem hat jede Phase ein Schlüsselziel und Meilenstein am Ende, das das Ziel anzeigt, das wird vollbringt. Die Vergegenwärtigung von RUP Phasen und Disziplinen wird mit der Zeit die RUP-Buckel-Karte genannt.

Beginn-Phase

Das primäre Ziel ist zum Spielraum das System entsprechend als eine Basis, um Initiale kostbar und Budgets gültig zu machen.

In dieser Phase wird der Geschäftsfall, der Geschäftszusammenhang, Erfolg-Faktoren (erwartete Einnahmen, Marktanerkennung, usw.), und Finanzvorhersage einschließt, gegründet. Um den Geschäftsfall zu ergänzen, werden ein grundlegendes Gebrauch-Fall-Modell, Projektplan, anfängliche Risikobewertung und Projektbeschreibung (die Kernprojektvoraussetzungen, Einschränkungen und Hauptmerkmale) erzeugt.

Nachdem diese vollendet werden, wird das Projekt gegen die folgenden Kriterien überprüft:

• Miteigentümer-Zusammentreffen auf der Spielraum-Definition und den Schätzungen der Kosten/Liste.
• Voraussetzungen, wie gezeigt, durch die Treue der primären Gebrauch-Fälle verstehend.
• Vertrauenswürdigkeit der Schätzungen der Kosten/Liste, der Prioritäten, der Gefahren und des Entwicklungsprozesses.
• Tiefe und Breite jedes architektonischen Prototyps, der entwickelt wurde.
• Das Herstellen einer Grundlinie, durch die man wirkliche Ausgaben gegen geplante Ausgaben vergleicht.

Wenn das Projekt diesen Meilenstein, genannt den Lebenszyklus-Ziel-Meilenstein, es nicht passiert entweder annulliert oder wiederholt werden kann neu entworfen, um den Kriterien besser zu entsprechen.

Weiterentwicklungsphase

Das primäre Ziel ist, die Schlüsselrisikosachen zu lindern, die durch die Analyse bis zum Ende dieser Phase identifiziert sind.

Die Weiterentwicklungsphase ist, wo das Projekt anfängt, Gestalt zu nehmen. In dieser Phase wird die Problem-Bereichsanalyse gemacht, und die Architektur des Projektes bekommt seine grundlegende Form.

Das Ergebnis der Weiterentwicklungsphase ist:

• Ein Modell des Gebrauch-Falls, in dem die Gebrauch-Fälle und die Schauspieler identifiziert worden sind und die meisten Beschreibungen des Gebrauch-Falls, wird entwickelt. Das Modell des Gebrauch-Falls sollte um 80 % abgeschlossen sein.
• Eine Beschreibung der Softwarearchitektur in einem Softwaresystementwicklungsprozess.
• Eine rechtskräftige Architektur, die architektonisch bedeutende Gebrauch-Fälle begreift.
• Geschäftsfall und Risikoliste, die revidiert werden.
• Ein Entwicklungsplan für das gesamte Projekt.
• Prototypen, die beweisbar jede identifizierte technische Gefahr lindern.
• Ein einleitendes Benutzerhandbuch (fakultativer)

Diese Phase muss die Lebenszyklus-Architektur-Meilenstein-Kriterien passieren, auf die folgenden Fragen antwortend:

• Ist die Vision vom stabilen Produkt?

Ist

• die Architektur stabil?
• Zeigt die rechtskräftige Demonstration an, dass Hauptrisikoelemente gerichtet und aufgelöst werden?
• Wird über den Bauphase-Plan genug ausführlich berichtet und genau?
• Geben alle Miteigentümer zu, dass die aktuelle Vision mit dem aktuellen Plan im Zusammenhang der aktuellen Architektur erreicht werden kann?
• Ist das wirkliche gegen den geplanten annehmbaren Quellenverbrauch?

Wenn das Projekt diesen Meilenstein nicht passieren kann, gibt es noch Zeit dafür, um annulliert oder neu entworfen zu werden. Jedoch, nach dem Verlassen dieser Phase, der Projektübergänge in eine risikoreiche Operation, wo Änderungen viel schwieriger und wenn gemacht, schädlich sind.

Die Schlüsselbereichsanalyse für die Weiterentwicklung ist die Systemarchitektur.

Bauphase

Das primäre Ziel ist, das Softwaresystem zu bauen.

In dieser Phase ist der Hauptfokus auf der Entwicklung von Bestandteilen und den anderen Eigenschaften des Systems. Das ist die Phase, wenn der Hauptteil des Codierens stattfindet. In größeren Projekten können mehrere Bauwiederholungen entwickelt werden, um die Gebrauch-Fälle in lenksame Segmente zu teilen, die beweisbare Prototypen erzeugen.

Diese Phase erzeugt die erste Außenausgabe der Software. Sein Beschluss wird durch den Anfänglichen Betrieblichen Fähigkeitsmeilenstein gekennzeichnet.

Übergang-Phase

Das primäre Ziel ist, das System von der Entwicklung in die Produktion 'durchzuqueren', es zu und verstanden vom Endbenutzer bereitstellend.

Die Tätigkeiten dieser Phase schließen Ausbildung die Endbenutzer und maintainers und das Beta ein, das das System prüft, um es gegen die Erwartungen der Endbenutzer gültig zu machen. Das Produkt wird auch gegen den Qualitätsniveau-Satz in der Beginn-Phase überprüft.

Wenn alle Ziele entsprochen werden, wird der Produktausgabe-Meilenstein erreicht, und der Entwicklungszyklus wird beendet.

Das Produkt von IBM Rational Method Composer

Das Produkt von IBM Rational Method Composer ist ein Werkzeug für authoring, das Konfigurieren, die Betrachtung und das Veröffentlichen von Prozessen. Sieh IBM Rational Method Composer und eine offene Quellversion Projekt von Eclipse Process Framework (EPF) für mehr Details.

Zertifikat

Im Januar 2007, die neue RUP Zertifikat-Überprüfung für IBM Certified Solution Designer - Vernünftiger Vereinigter Prozess 7.0 wurde veröffentlicht, der die vorherige Version des Kurses genannt der Fachmann von IBM Rational Certified - Vernünftiger Vereinigter Prozess ersetzt. Die neue Überprüfung wird Kenntnisse nicht nur prüfen, die mit dem RUP Inhalt sondern auch mit den Prozess-Struktur-Elementen verbunden sind.

Um die neue RUP Zertifikat-Prüfung zu bestehen, muss sich eine Person der Prüfung von IBM 839 unterziehen: Vernünftiger Vereinigter Prozess v7.0. Ihnen werden 75 Minuten gegeben, um die 52 Frage-Prüfung abzulegen. Die vorübergehende Kerbe ist 62 %.

Sechs beste Methoden

Sechs Beste Methoden, wie beschrieben, im Vernünftigen Vereinigten Prozess sind ein Paradigma in der Softwaretechnik, die sechs Ideen verzeichnet zu folgen, wenn sie jedes Softwareprojekt entwirft, Schulden und Zunahme-Produktivität zu minimieren. Diese Methoden sind:

Entwickeln Sie sich wiederholend: Es ist am besten, alle Voraussetzungen im Voraus zu wissen; jedoch häufig ist das nicht der Fall. Mehrere Softwareentwicklungsprozesse bestehen, die sich mit Versorgung der Lösung darauf befassen, wie man Kosten in Bezug auf Entwicklungsphasen minimiert.

Führen Sie Voraussetzungen: Beachten Sie immer die von Benutzern gesetzten Voraussetzungen.

Gebrauch-Bestandteile: Das Brechen eines fortgeschrittenen Projektes wird nicht nur angedeutet, aber tatsächlich unvermeidlich. Das fördert Fähigkeit, individuelle Bestandteile zu prüfen, bevor sie in ein größeres System integriert werden. Außerdem ist Codewiedergebrauch ein großer plus und kann leichter durch den Gebrauch der objektorientierten Programmierung vollbracht werden.

Modellieren Sie visuell: Verwenden Sie Diagramme, um alle Hauptbestandteile, Benutzer und ihre Wechselwirkung zu vertreten. "UML", der für die Vereinigte modellierende Sprache kurz ist, ist ein Werkzeug, das verwendet werden kann, um diese Aufgabe mehr ausführbar zu machen.

Prüfen Sie Qualität nach: Machen Sie immer Prüfung eines Hauptteils des Projektes an jedem Punkt der Zeit. Prüfung wird schwerer, als das Projekt fortschreitet, aber ein unveränderlicher Faktor in jeder Softwareproduktentwicklung sein sollte.

Kontrolländerungen: Viele Projekte werden von vielen Mannschaften manchmal in verschiedenen Positionen geschaffen, verschiedene Plattformen können usw. verwendet werden. Infolgedessen ist es notwendig sicherzustellen, dass mit einem System vorgenommene Änderungen synchronisiert und ständig nachgeprüft werden. (Sieh Dauernde Integration).

Siehe auch

• Makrospielraum (Methodik-Gefolge)
• Das flinke Modellieren
• Flinke Softwareentwicklung
• Integrierter vereinigter Prozess
• Computer, programmierend
• Äußerste Programmierung
• Zeigen Sie gesteuerte Entwicklung
• Projektlebenszyklus
• Qualitätssicherung
• Softwarearchitektur
• Softwarebestandteil
• Softwareentwicklung bearbeitet
• Softwaretechnik
• Probegefahrene Entwicklung

Weiterführende Literatur

• Ivar Jacobson, Grady Booch und James Rumbaugh (1999). Die vereinigte Softwareentwicklung bearbeitet
• Pro Kroll, Philippe Kruchten (2003). Vernünftiger vereinigter Prozess gemacht leicht: Ein Handbuch eines Praktikers zum RUP
• Pro Kroll, Bruce Mac Isaac (2006). Behändigkeit und Disziplin gemacht leicht: Methoden von OpenUP und RUP
• Philippe Kruchten (1998). Der vernünftige vereinigte Prozess: Eine Einführung
• Ahmad Shuja, Jochen Krebs (2007). RUP Verweisung und Zertifikat-Führer
• Walker Royce, Softwareprojektmanagement, ein vereinigtes Fachwerk

Außenverbindungen

• IBM Rational Unified Process Web Site
• Vernünftige Software an IBM
• Globale vernünftige Benutzergruppe-Gemeinschaft