Richtlinie: RUP anpassen
Diese Richtlinie enthält Empfehlungen für die Anpassung von RUP für eine Organisation oder ein Projekt.
Hauptbeschreibung

Diese Richtlinien beschreiben verschiedene Punkte, die beim Anpassen von RUP zu beachten sind.

Eine Beschreibung des Gesamtprozesses für die Anpassung von RUP finden Sie in Konzept: RUP anpassen

Eine Beschreibung einige allgemeiner Best Practices für die Prozessanpassung finden Sie in Richtlinie: Verfahren für die Prozessanpassung.

Umfang der Anpassungen definieren

Bei der Definition des Anpassungsumfangs geben Sie an, was Sie ändern möchten und wie.

Damit Sie den Umfang effektiv definieren können, müssen Sie sich unbedingt mit RUP vertraut machen. Weitere Informationen hierzu finden Sie in Einführung in RUP.

Wie viel des Prozesses Sie sich entschließen anzupassen und auf welcher Ebene richtet sich nach verschiedenen Faktoren. Diese Faktoren sind in der Richtlinie: Prozessdiskriminanten beschrieben.   

Variable Elemente in Software-Engineering-Prozessen

Dieser Abschnitt beschreibt die Bausteine eines Prozesses, die während der Anpassung von RUP geändert, angepasst, hinzugefügt oder unterdrückt werden können.

  • Disziplinen
    In einem Softwareprojekt werden Disziplinen (z. B. Analyse und Design, Implementierung usw.) im Allgemeinen nicht komplett weggelassen. In seltenen Fällen können einige Disziplinen wie Anforderungen oder Deployment von anderen Organisationen ausgeführt werden. Wahrscheinlicher ist jedoch, dass bestimmte Workflows innerhalb oder zwischen Disziplinen modifiziert werden.   
  • Arbeitsergebnisse
    Projekte unterscheiden sich in der Regel eher in den Arbeitsergebnissen, die produziert, aktualisiert und bereitgestellt werden müssen. Stellen Sie sich auf der einen Seite ein vollständig papierloses Projekt vor, das lediglich eine kleine Anzahl von Arbeitsergebnissen verwaltet, von Tools wie Spreadsheets, Designtools, Programmiertools und Testtools unterstützt wird und Software und Dokumentation nur elektronisch auf einer Festplatte, CD oder im World-Wide Web bereitstellt. Und jetzt stellen Sie sich auf der anderen Seite des Extrems Projekte vor, die aus vertraglichen, gesetzlichen oder organisatorischen Gründen große Mengen gedruckter Dokumente produzieren und verwalten müssen. In manchen Fällen können ganze Modelle weggelassen werden.
  • Aufgaben
    Aufgaben variieren in der Regel. Hierfür gibt es mindestens zwei Gründe. Aufgaben, die Arbeitsergebnisse als Eingabe verwenden, und Arbeitsergebnisse als Ausgabe produzieren oder aktualisieren, sind von der Änderung dieser Arbeitsergebnisse betroffen. Wenn ein Arbeitsergebnis oder ein Informationselement eines Arbeitsergebnisses nicht mehr benötigt wird, können die entsprechenden Schritte unterdrückt oder signifikant geändert werden. Aufgaben werden auch geändert, um spezielle Techniken, Methoden und Tools für die jeweilige Anwendungsdomäne bzw. das spezielle Entwicklungs-Know-how einzuführen, z. B. Designschritte, programmiersprachen, Tools für automatische Codegenerierung, Messverfahren usw.

Auf detaillierterer Ebene können Methodenelemente geändert, hinzugefügt oder unterdrückt werden:

  • Rollen
  • Schritte in Aufgaben
  • Richtlinien und Anleitungen für Aufgaben
  • Notationen, z. B. die Verwendung von Teilen von UML oder Stereotypen, um bestimmte Anforderungen für einige oder alle Modelle zu unterstützen
  • Prüflisten für Prüfungen
  • Toolunterstützung für die Automatisierung einiger Aufgaben
  • Terminologieänderungen, z. B. um den Prozess an die Struktur einer Organisation anzupassen

Zusammenfassend gesagt, der Prozessentwickler muss weitreichende Entscheidungen treffen, wenn er RUP anpasst. RUP muss möglicherweise auch angepasst werden, um bestimmte etablierte Unternehmensverfahren und -standards wie Dokumente, Terminologie usw. zu nutzen.



 

Komplizierte Anpassungsszenarios

Bestimmte Anpassungsszenarios sind schwierig zu implementieren und müssen sorgfältig überlegt werden. Beispiel:

  • Änderung der Prozessarchitektur
    Wenn Aufgaben in großem Stil in andere Disziplinen gepackt werden, um einen vorhandenen Prozess oder eine vorhandenen Organisation zu berücksichtigen, steht manchmal der Aufwand in keinem Verhältnis zum erzielten Nutzen. Häufiger ist es pragmatischer, einfach eine Übersicht zu erstellen, um einschätzen zu können, ob alle Aspekte von RUP abgedeckt werden. Bedenken Sie, dass die Disziplinen keine Phasen sind, die nacheinander ausgeführt werden, sondern Container für Aufgaben, die in jeder Iteration wieder und wieder ausgeführt werden, häufig parallel in einer Iteration.
  • Änderungen an der Terminologie
    Die Ersetzung eines Worts durch ein anderes mag trivial klingen, sollte jedoch wohl überdacht werden. In der Domäne des Software-Engineering verwenden Organisationen häufig dasselbe Wort in geringfügig anderer Bedeutung oder unterschiedliche Wörter, die jedoch dasselbe bedeuten. Isolierte Änderungen in RUP vorzunehmen, kann das Verständnis eines Prozesses erheblich erschweren. Eine Lösung ist die Erstellung einer "Übersetzungstabelle" für die Terminologie, die die RUP-Terminologie und die Terminologie der Organisation gegenüberstellt.

Beispiele für kritische Wörter sind System, Phase, Rolle, Aktivität, Aufgabe, Modell und Dokument.

Wenn die Prozessergebnisse in einer anderen Sprache als der Muttersprache dokumentiert werden, sind die Terminologieprobleme noch komplexer, weil die Beschreibungen der Arbeitsergebnisse, Dokumente, Berichte und möglicherweise anderer RUP-Komponenten in diese Sprache übersetzt werden müssen.