Beispiel: Ein kleines Projekt mit RUP
Dieses Beispiel beschreibt ein Szenario, in dem ein kleines Projekt entschieden hat, RUP anzuwenden.
Beziehungen
Beschreibung
Hauptbeschreibung

Weitere Informationen zum Anpassen von RUP für ein kleines Projekt finden Sie in Prozess für ein kleines Projekt anpassen. Weitere Informationen zum Anpassen von RUP im Allgemeinen finden Sie in RUP anpassen.

Projektübersicht

Das folgende Szenario beschreibt ein Projekt einer Firma ABC mit dem Namen Projekt X. Projekt X ist ein Team, das sich aus dem Projektleiter Paul und den vier Programmierern Dietmar, Hartmut, Claire und Jens zusammensetzt. Die Dauer des Projekts beträgt vier Monate.  

Paul überlegt, RUP als Basis für den Softwareentwicklungsprozess seines Projekts einzusetzen. Er installiert RUP, standardmäßig mit der Prozesskonfiguration "Klassischer RUP". Er schaut sich die Teile der Konfiguration "Klassischer RUP" an, die für die Anpassung eines Prozesses für ein Projekt relevant sind.

Er beginnt in Absprache mit dem Team mit der Auswertung der Prozessanforderungen für das Projekt. Sein Fazit ist wie folgt:

  • Der vorhandene Prozess und die Tools für das Konfigurationsmanagement funktionieren gut, deshalb kann dieser Aspekt des Prozesses unverändert bleiben.
  • Das Team hat gewisse Erfahrung mit Anwendungsfällen und Komponentenarchitekturen, könnte aber mehr Anleitung in diesen Bereichen brauchen.
  • Das Projekt würde insofern von einem iterativen Entwicklungsansatz profitieren, als die Schlüsselrisiken für das Projekt schnell gemindert werden könnten.
  • Die Stakeholder haben eine gute und ungezwungene Beziehung zum Entwicklungsteam, und deshalb besteht kein Bedarf an formalen Verträgen oder Überprüfungen. Die Stakeholder können ständig Einblick in die Entwicklung nehmen. Das Team ist sehr gut ausgebildet, diszipliniert und hat in der Vergangenheit gezeigt, dass es auch ohne formalen Prozess qualitativ hochwertige Produkte produzieren kann.
  • In Anbetracht des kurzen Projektzeitrahmens werden nur geringfügige Änderungen am Toolset vorgenommen.
  • Es wird eine gesonderte parallele Aktivität eingeführt, um Toolleistungen und Wiederverwendungschancen zu untersuchen und den Prozess für künftige Projekte zu verfeinern.

Paul geht dann die Aufgabe an, einen passenden Prozess für das Team anzupassen.

Allgemeine Anpassung

Projektspezifische Assets in ein Plug-in packen

Der vorhandene RUP-Prozess kommt relativ nahe an die Projektanforderungen heran, aber nicht ganz. Paul präzisiert den Prozess, indem er ein projektspezifisches Plug-in erstellt, das die projektspezifischen Assets enthält.

Paul startet den Rational Method Composer (RMC) und erstellt ein neues Methoden-Plug-in, das Folgendes enthält:

  • Richtlinien für die im Projekt zu verwendenden Tools,
  • Richtlinien, die aus einem vorherigen Projekt übernommen werden, einschließlich Designrichtlinien und Richtlinien für das Konfigurations- und Änderungsmanagement,
  • Richtlinien für Überprüfungen und Bewertung.

Zusätzlich zur Zuordnung dieser Anleitung zu den entsprechenden RUP-Methodenelementen fügt Paul diese Anleitung in die RUP-Prozesssichten ein.

Er fügt außerdem eine Seite "Einführung in den Prozess für Projekt X" zur Sicht "Erste Schritte" hinzu, auf der er die Grundphilosophie des konfigurierten Prozesses beschreibt. Beispielsweise erläutert er, dass die enthaltenen Vorlagen als Anleitung für den Inhalt zu verwenden sind, aber dass das Format optional ist. Er gibt außerdem an, wo aktuelle Versionen der Schlüsselarbeitsergebnisse des Projekts gespeichert werden.

Weitere Informationen zum Erstellen eines Methoden-Plug-in mit RMC finden Sie in Methoden-Plug-In mit Rational Method Composer erstellen. Informationen zum Füllen des Plug-in mit Inhalt finden Sie in Methodeninhalt mit Rational Method Composer entwickeln.

Prozessspezifische Konfiguration und Veröffentlichung definieren

Nachdem Paul die projektspezifischen Assets in ein Plug-in gepackt hat, kann er eine RUP-Konfiguration entwickeln, die das projektspezifische Plug-in enthält.

Paul startet Rational Method Composer (RMC) und wählt die Konfiguration "Kleine Konfiguration" als Ausgangspunkt. Er kopiert die Konfiguration "Kleine Konfiguration" in eine neue Konfiguration, die er "ABC Projekt X" nennt. 

Paul öffnet die neue Konfiguration und wählt einige Methodenpakete und Plug-ins aus und einige ab, um eine grobe Konfiguration der gewünschten Konfiguration vorzunehmen. Er wählt beispielsweise das Methodenpaket "Datenbankdesign" ab, weil das Team in diesem Projekt keine Datenmodellierung beabsichtigt, und er wählt das projektspezifische Plug-in, das er zuvor erstellt hat, aus.

Anschließend erstellt Paul einen neuen Bereitstellungsprozess in seinem Methoden-Plug-in, indem er den Bereitstellungsprozess in der Konfiguration "Kleines Projekt" als Ausgangspunkt verwendet. Er bearbeitet den neuen Bereitstellungsprozess, fügt einige Aufgaben zu jeder Phase hinzu und entfernt andere. Anschließend veröffentlicht er die Ergebnisse.

Informationen zum Entwickeln von Prozessen mit RMC finden Sie in Prozesse mit Rational Method Composer entwickeln. Informationen zum Veröffentlichen von Prozessen mit RMC finden Sie in Toolmentor: Methodenkonfiguration mit Rational Method Composer veröffentlichen.

Rollen und Lebenszyklus

Projekt X hat ein kleines Team, deshalb ist jede Person für mehrere RUP-Rollen verantwortlich. Paul beschreibt die Zuständigkeiten jeder Person im Softwareentwicklungsplan. In Projekt X ist Paul beispielsweise für die Rollen Projektleiter und Prozessentwickler zuständig.

Überprüfung

Paul stellt dem Team und anderen Stakeholdern einen Entwurf des konfigurierten RUP und den Softwareentwicklungsplan zur Prüfung zur Verfügung. Das Team beginnt mit der Umsetzung des Prozesses. Es werden einige Fehler gemacht, und der Prozess wird abgeändert. Am Ende ist das Projekt erfolgreich, und das Team hat einen optimierten Prozess, der auf künftige Projekte angewendet werden kann.