Rationaler einheitlicher Prozess - Rational Unified Process

Software-Entwicklung
Hauptaktivitäten
Paradigmen und Modelle
Methoden und Rahmenbedingungen
Unterstützende Disziplinen
Praktiken Methoden Ausübungen
Werkzeuge
Standards und Wissensdatenbanken
Glossare
Umrisse

Das Rational Unified Process ( RUP ) ist ein iterative Software - Entwicklungsprozess Rahmen , der mit der Rational Software Corporation, ein Geschäftsbereich von IBM seit 2003 RUP ist kein einziger konkreter präskriptiver Prozess, sondern ein anpassungsfähiges Prozessrahmen , bestimmt durch die zugeschnitten werden Entwicklungsorganisationen und Softwareprojektteams, die die für ihre Bedürfnisse geeigneten Elemente des Prozesses auswählen. RUP ist eine spezifische Implementierung des Unified Process .

Geschichte

Rational Software hat den rational vereinheitlichten Prozess ursprünglich als Softwareprozessprodukt entwickelt. Das Produkt enthält eine verlinkte Wissensbasis mit Beispiel Artefakte und detaillierten Beschreibungen für viele verschiedene Arten von Aktivitäten. RUP ist im Produkt IBM Rational Method Composer (RMC) enthalten, das eine Anpassung des Prozesses ermöglicht.

Philippe Kruchten , ein erfahrener technischer Vertreter von Rational, wurde mit der Leitung des ursprünglichen RUP-Teams beauftragt.

Diese ersten Versionen kombinierten die umfangreichen Felderfahrungen der Rational Software-Organisation beim Aufbau objektorientierter Systeme (von Rational-Außendienstmitarbeitern als Rational-Ansatz bezeichnet) mit Objectorys Anleitungen zu Praktiken wie Anwendungsfällen und beinhalteten umfangreiche Inhalte aus Jim Rumbaughs Object Modeling Technology (OMT .). ) Modellierungsansatz, die Booch-Methode von Grady Booch und die neu veröffentlichte UML 0.8.

Um diese wachsende Wissensbasis zugänglicher zu machen, wurde Philippe Kruchten mit der Zusammenstellung eines expliziten Prozess-Frameworks für modernes Software-Engineering beauftragt. Bei diesen Bemühungen wurde der von Objectory entwickelte HTML- basierte Prozessliefermechanismus verwendet. Der daraus resultierende „Rational Unified Process“ (RUP) vervollständigte ein strategisches Dreibein für Rational:

  • ein maßgeschneiderter Prozess , der die Entwicklung leitete
  • Tools , die die Anwendung dieses Prozesses automatisiert haben
  • Dienstleistungen , die die Einführung sowohl des Prozesses als auch der Tools beschleunigten.

Dieser Leitfaden wurde in nachfolgenden Versionen um Wissen erweitert, das auf den Erfahrungen von Unternehmen basiert, die Rational erworben hatte.

1997 wurde der Ansatz um eine Anforderungs- und Testdisziplin erweitert, wobei ein Großteil des zusätzlichen Materials aus der von Dean Leffingwell et al. entwickelten Methode des Requirements College stammt. bei Requisite, Inc., und die bei SQA Inc. entwickelte SQA-Prozessmethode, die beide von Rational Software übernommen wurden.

1998 fügte Rational Software zwei neue Disziplinen hinzu:

  1. Geschäftsmodellierung, viele dieser Inhalte waren bereits im Objectory Process
  2. eine Disziplin des Konfigurations- und Änderungsmanagements, die durch die Übernahme der Pure Atria Corporation entstanden ist.

Diese Ergänzungen führen zu einem übergreifenden Satz von Prinzipien, die von Rational definiert und innerhalb von RUP als die sechs Best Practices für modernes Software-Engineering formuliert wurden :

  1. Iterativ entwickeln, mit Risiko als primärem Iterationstreiber
  2. Anforderungen verwalten
  3. Verwenden Sie eine komponentenbasierte Architektur
  4. Software visuell modellieren
  5. Qualität kontinuierlich überprüfen
  6. Kontrolländerungen

Diese Best Practices waren eng mit der Produktlinie von Rational abgestimmt, und beide trieben die fortlaufende Entwicklung der Rational-Produkte voran und wurden von den Außendienstteams von Rational verwendet, um Kunden dabei zu helfen, die Qualität und Vorhersehbarkeit ihrer Softwareentwicklungsbemühungen zu verbessern.

Zusätzliche Techniken wie Leistungstests, UI-Design, Data Engineering und ein Update, um Änderungen in UML 1.1 widerzuspiegeln, wurden aufgenommen.

1999 wurde eine Disziplin des Projektmanagements sowie Techniken zur Unterstützung der Echtzeit-Softwareentwicklung und Aktualisierungen eingeführt, um UML 1.3 widerzuspiegeln. Außerdem wurde im selben Jahr das erste Buch veröffentlicht, das den Prozess beschreibt, The Unified Software Development Process ( ISBN  0-201-57169-2 ).

Zwischen 2000 und 2003 wurden durch eine Reihe von Änderungen neben der Toolunterstützung für die Umsetzung von RUP-Instanzen und die Anpassung des RUP-Frameworks Anleitungen aus der laufenden Rational-Felderfahrung mit iterativer Entwicklung eingeführt. Zu diesen Änderungen gehörten:

  1. die Einführung von Konzepten und Techniken aus Ansätzen wie eXtreme Programming (XP), die später zusammenfassend als agile Methoden bezeichnet werden. Dazu gehörten Techniken wie Pair Programming, Test-First-Design und Papiere, die erklärten, wie RUP es XP ermöglichte, für den Einsatz in größeren Projekten zu skalieren.
  2. eine vollständige Überarbeitung der Testdisziplin, um besser widerzuspiegeln, wie die Testarbeit in verschiedenen iterativen Entwicklungskontexten durchgeführt wurde.
  3. die Einführung unterstützender Anleitungen - bekannt als "Toolmentoren" - zur Umsetzung der RUP-Praktiken in verschiedenen Tools. Diese boten im Wesentlichen eine schrittweise Methodenunterstützung für Benutzer von Rational-Tools.
  4. Automatisierung der Anpassung von RUP in einer Weise, die es Kunden ermöglicht, Teile aus dem RUP-Prozess-Framework auszuwählen, ihre Auswahl mit ihren eigenen Ergänzungen anzupassen und dennoch Verbesserungen in nachfolgenden Releases von Rational zu integrieren.

IBM hat Rational Software im Februar 2003 übernommen.

Im Jahr 2006 erstellte IBM eine Teilmenge von RUP, die auf die Bereitstellung von Agile- Projekten zugeschnitten ist und als OpenSource-Methode namens OpenUP über die Eclipse -Website veröffentlicht wurde.

Rational vereinheitlichte Prozessthemen

RUP-Bausteine

RUP basiert auf einer Reihe von Bausteinen und Inhaltselementen, die beschreiben, was produziert werden soll, die erforderlichen Fähigkeiten und die Schritt-für-Schritt-Erklärung, die beschreibt, wie bestimmte Entwicklungsziele erreicht werden sollen. Die Hauptbausteine ​​oder Inhaltselemente sind die folgenden:

  • Rollen (wer) – Eine Rolle definiert eine Reihe verwandter Fähigkeiten, Kompetenzen und Verantwortlichkeiten.
  • Arbeitsergebnisse (was) – Ein Arbeitsprodukt stellt etwas dar, das sich aus einer Aufgabe ergibt, einschließlich aller Dokumente und Modelle, die während der Bearbeitung des Prozesses erstellt wurden.
  • Aufgaben (wie) – Eine Aufgabe beschreibt eine einer Rolle zugewiesene Arbeitseinheit, die ein sinnvolles Ergebnis liefert.

Innerhalb jeder Iteration werden die Aufgaben in neun Disziplinen kategorisiert:

Vier Projektlebenszyklusphasen

RUP Phasen und Disziplinen.

Die RUP hat einen Projektlebenszyklus festgelegt, der aus vier Phasen besteht. Diese Phasen ermöglichen es, den Prozess auf einem hohen Niveau zu präsentieren, ähnlich wie ein Projekt im Stil eines Wasserfalls, obwohl im Wesentlichen der Schlüssel zum Prozess in den Iterationen der Entwicklung liegt, die in allen Phasen liegen . Außerdem hat jede Phase ein Schlüsselziel und einen Meilenstein am Ende, der das erreichte Ziel angibt. Die Visualisierung von RUP-Phasen und -Disziplinen im Zeitverlauf wird als RUP-Hump- Chart bezeichnet.

Anfangsphase

Das primäre Ziel besteht darin, das System als Grundlage für die Validierung von Erstkalkulationen und Budgets angemessen zu skalieren. In dieser Phase wird der Business Case erstellt, der den Geschäftskontext, die Erfolgsfaktoren (erwarteter Umsatz, Markterkennung usw.) und die Finanzprognose umfasst. Um den Business Case zu ergänzen, werden ein grundlegendes Use-Case-Modell, ein Projektplan, eine anfängliche Risikobewertung und eine Projektbeschreibung (die Kernprojektanforderungen, Einschränkungen und Schlüsselmerkmale) generiert. Nachdem diese abgeschlossen sind, wird das Projekt anhand folgender Kriterien geprüft:

  • Übereinstimmung der Interessengruppen bei der Definition des Umfangs und der Kosten-/Zeitplanschätzungen.
  • Anforderungsverständnis, das durch die Treue der primären Anwendungsfälle belegt wird.
  • Glaubwürdigkeit der Kosten-/Planschätzungen, Prioritäten, Risiken und des Entwicklungsprozesses.
  • Tiefe und Breite jedes Architekturprototyps, der entwickelt wurde.
  • Erstellen einer Basislinie, anhand derer die tatsächlichen Ausgaben mit den geplanten Ausgaben verglichen werden können.

Wenn das Projekt diesen Meilenstein, den sogenannten Lebenszyklusziel-Meilenstein, nicht erreicht, kann es entweder abgebrochen oder wiederholt werden, nachdem es neu gestaltet wurde, um die Kriterien besser zu erfüllen.

Ausarbeitungsphase

Das primäre Ziel besteht darin, die bis zum Ende dieser Phase durch die Analyse identifizierten wesentlichen Risikopositionen zu mindern. In der Ausarbeitungsphase nimmt das Projekt Gestalt an. In dieser Phase wird die Problemdomänenanalyse durchgeführt und die Architektur des Projekts erhält ihre Grundform.

Das Ergebnis der Ausarbeitungsphase ist:

  • Ein Use-Case-Modell, in dem die Use-Cases und die Akteure identifiziert und die meisten Use-Case-Beschreibungen entwickelt wurden. Das Use-Case-Modell sollte zu 80 % vollständig sein.
  • Eine Beschreibung der Softwarearchitektur in einem Softwaresystementwicklungsprozess.
  • Eine ausführbare Architektur , die architektonisch bedeutsame Anwendungsfälle realisiert.
  • Business Case und Risikoliste, die überarbeitet werden.
  • Ein Entwicklungsplan für das Gesamtprojekt.
  • Prototypen, die jedes identifizierte technische Risiko nachweislich mindern.
  • Ein vorläufiges Benutzerhandbuch (optional)

Diese Phase muss die Meilensteinkriterien der Lebenszyklusarchitektur erfüllen und die folgenden Fragen beantworten:

  • Ist die Vision des Produkts stabil?
  • Ist die Architektur stabil?
  • Zeigt die ausführbare Demonstration an, dass wichtige Risikoelemente angesprochen und behoben werden?
  • Ist der Bauphasenplan ausreichend detailliert und genau?
  • Sind sich alle Stakeholder einig, dass die aktuelle Vision mit dem aktuellen Plan im Kontext der aktuellen Architektur erreicht werden kann?
  • Ist der tatsächliche vs. geplante Ressourcenaufwand akzeptabel?

Wenn das Projekt diesen Meilenstein nicht erreichen kann, bleibt noch Zeit, es abzubrechen oder neu zu gestalten. Nach Verlassen dieser Phase geht das Projekt jedoch in einen Hochrisikobetrieb über, bei dem Änderungen viel schwieriger und nachteiliger sind.

Die Schlüsseldomänenanalyse für die Ausarbeitung ist die Systemarchitektur.

Konstruktionsphase

Das primäre Ziel ist der Aufbau des Softwaresystems. In dieser Phase liegt der Schwerpunkt auf der Entwicklung von Komponenten und anderen Features des Systems. Dies ist die Phase, in der der Großteil der Codierung stattfindet. In größeren Projekten können mehrere Konstruktionsiterationen entwickelt werden, um die Anwendungsfälle in überschaubare Segmente zu unterteilen, um nachweisbare Prototypen zu erstellen.

Übergangsphase

Das Hauptziel besteht darin, das System von der Entwicklung in die Produktion zu „überführen“, um es für den Endbenutzer verfügbar und verständlich zu machen. Die Aktivitäten dieser Phase umfassen die Schulung der Endbenutzer und Betreuer sowie Betatests des Systems, um es anhand der Erwartungen der Endbenutzer zu validieren. Das System durchläuft auch eine Evaluierungsphase, jeder Entwickler, der nicht die erforderliche Arbeit leistet, wird ersetzt oder entfernt. Das Produkt wird auch gegen das in der Einführungsphase festgelegte Qualitätsniveau geprüft.

Wenn alle Ziele erreicht sind, ist der Meilenstein der Produktfreigabe erreicht und der Entwicklungszyklus abgeschlossen.

Das IBM Rational Method Composer-Produkt

Das Produkt IBM Rational Method Composer ist ein Tool zum Erstellen, Konfigurieren, Anzeigen und Veröffentlichen von Prozessen. Weitere Informationen finden Sie unter IBM Rational Method Composer und eine Open-Source-Version des Eclipse Process Framework (EPF)-Projekts.

Zertifizierung

Im Januar 2007 wurde die neue RUP-Zertifizierungsprüfung für IBM Certified Solution Designer – Rational Unified Process 7.0 veröffentlicht, die die vorherige Version des Kurses namens IBM Rational Certified Specialist – Rational Unified Process ersetzt . In der neuen Prüfung werden nicht nur Kenntnisse zu den RUP-Inhalten, sondern auch zu den Prozessstrukturelementen geprüft.

Um die neue RUP-Zertifizierungsprüfung zu bestehen, muss eine Person den IBM Test 839: Rational Unified Process v7.0 ablegen . Für die Prüfung mit 52 Fragen haben Sie 75 Minuten Zeit. Der bestandene Wert beträgt 62 %.

Sechs Best Practices

Für Softwareprojekte werden sechs bewährte Software-Engineering- Praktiken definiert, um Fehler zu minimieren und die Produktivität zu steigern. Diese sind:

Iterativ entwickeln
Es ist am besten, alle Anforderungen im Voraus zu kennen; dies ist jedoch häufig nicht der Fall. Es gibt mehrere Softwareentwicklungsprozesse, die sich mit der Bereitstellung von Lösungen zur Kostenminimierung in Bezug auf Entwicklungsphasen befassen.
Anforderungen verwalten
Beachten Sie immer die von den Benutzern gestellten Anforderungen.
Komponenten verwenden
Das Aufbrechen eines fortgeschrittenen Projekts ist nicht nur vorgeschlagen, sondern unvermeidlich. Dies fördert die Möglichkeit, einzelne Komponenten zu testen, bevor sie in ein größeres System integriert werden. Auch die Wiederverwendung von Code ist ein großes Plus und kann durch den Einsatz objektorientierter Programmierung einfacher erreicht werden .
Optisch modellieren
Verwenden Sie Diagramme, um alle wichtigen Komponenten, Benutzer und deren Interaktion darzustellen. "UML", kurz für Unified Modeling Language , ist ein Werkzeug, das verwendet werden kann, um diese Aufgabe machbarer zu machen.
Qualität überprüfen
Machen Sie das Testen zu jedem Zeitpunkt zu einem wichtigen Teil des Projekts. Das Testen wird im Laufe des Projekts schwieriger, sollte aber ein konstanter Faktor bei jeder Softwareprodukterstellung sein.
Kontrolländerungen
Viele Projekte werden von vielen Teams erstellt, manchmal an verschiedenen Standorten, es können unterschiedliche Plattformen verwendet werden usw. Daher ist es wichtig sicherzustellen, dass Änderungen an einem System ständig synchronisiert und überprüft werden. (Siehe Kontinuierliche Integration ).

Siehe auch

Verweise

Weiterlesen

  • Ivar Jacobson , Grady Booch und James Rumbaugh (1999). Der einheitliche Softwareentwicklungsprozess
  • Gary Pollice , Liz Augustine , Chris Lowe und Jas Madhur (2003). Softwareentwicklung für kleine Teams: Ein RUP-zentrierter Ansatz
  • Per Kroll, Philippe Kruchten (2003). Rational Unified Process leicht gemacht, The: Ein Leitfaden für Praktiker zum RUP
  • Per Kroll, Bruce MacIsaac (2006). Agilität und Disziplin leicht gemacht: Praktiken von OpenUP und RUP
  • Philippe Kruchten (1998). Der Rational Unified Process: Eine Einführung
  • Ahmad Shuja, Jochen Krebs (2007). RUP Referenz- und Zertifizierungsleitfaden
  • Walker Royce, Software-Projektmanagement, ein einheitliches Framework

Externe Links