Richtlinie: Wichtige Entscheidungen bei Analyse und Design
Diese Richtlinie beschreibt wichtige Punkte, die bei der Anpassung der Aspekte von Analyse und Design des Prozesses zu berücksichtigen sind.
Beziehungen
Hauptbeschreibung

Verwendung der Arbeitsergebnisse festlegen

Sie müssen entscheiden, welche Arbeitsergebnisse verwendet werden sollen und wie. Außerdem müssen Sie jedes Arbeitsergebnis so anpassen, dass es den Anforderungen des Projekts entspricht.  

Die folgende Tabelle enthält eine Liste der empfohlenen und optionalen (die nur in bestimmten Fällen verwendet werden können) Arbeitsergebnisse aus der Disziplin Analyse & Design. Weitere Hinweise zur Anpassung finden Sie im Abschnitt "Anpassen" auf der Seite mit der Beschreibung des jeweiligen Arbeitsergebnisses.

Arbeitsergebnis Zweck

Anpassen (optional, empfohlen)

Analysemodell (Analyseklasse) Ein Analysemodell ist hilfreich, um die Anforderungen besser zu verstehen, bevor Designentscheidungen getroffen werden. In komplexen Systemen kann das Analysemodell als konzeptionelle Übersicht über das System gepflegt.

Optional

In vielen Projekten wird anstelle des Analysemodells ein erstes Designmodell verwendet.

In Projekten, die ein Analysemodell erstellen, ist es in der Regel ein temporäres Artefakt, aus dem sich das Designmodell entwickelt.

Navigationsübersicht, Benutzerschnittstellenprototyp

Projekte mit einer großen und komplexen Benutzerschnittstelle sollten sich für ein Benutzerschnittstellendesign entscheiden.

Optional

In kleineren Entwicklungsprojekten kann ein eher formloses Benutzerschnittstellendesign ausreichend sein.

Designmodell

Für die meisten Systeme, selbst kleinere sollte vor der Implementierung ein Design erstellt werden, um kostenintensive Nacharbeiten aufgrund von Designfehlern zu vermeiden. Mit visuellen Modellen lässt sich das Design einfach kommunizieren. Tools für Entwicklung (Forward-Engineering) und Rückentwicklung (Reverse-Engineering) können die Konsistenz mit dem Implementierungsmodell sicherstellen und Aufwand sparen.

Empfohlen für die meisten Projekte.

In kleineren Projekten ist die Verwendung automatisierter Tools kein kritischer Faktor, können aber langfristig die Produktivität verbessern.

Designklasse; Designpaket

Klassen und Pakete sind ein grundlegender Baustein jedes objektorientierten Designs. Objektorientiertes Design ist der Standarddesignansatz, der in den meisten Projekten verwendet wird.

Empfohlen für die meisten Projekte.

Ein wichtigste Anpassungsaspekt ist die Entscheidung, welche Stereotypen verwendet werden (diese Entscheidung kann in den Designrichtlinien erfasst werden).

Anwendungsfallrealisierung

Die Brücke von Anwendungsfällen zum Design.

Empfohlen für die meisten Projekte.

Schnittstelle

Schnittstellen werden normalerweise verwendet, um Verhalten unabhängig von größeren Komponenten zu definieren, die das Verhalten realisieren.

Empfohlen für die meisten Projekte.

Komponentenbasiertes Design wird langsam zu einem Standarddesignansatz.

Designsubsystem

Designsubsysteme werden verwendet, um Verhalten in einer Komponente zu kapseln, die Schnittstellen bereitstellt. In ihnen werden die Interaktionen von Klassen und/oder anderen Subsystemen gekapselt.

Empfohlen für die meisten Projekte.

Subsysteme sind häufig hilfreich, um eine höhere Abstraktionsstufe zu erreichen. Sie machen Systeme verständlicher.

Ereignis

Kann für Systeme hilfreich sein, die auf viele externe Ereignisse reagieren. Empfohlen für Echtzeitsysteme.

 Protokoll

Erforderlich für Echtzeitsysteme. Empfohlen für Echtzeitsysteme.

Signal

Kann hilfreich für Systeme sein, die Parallelität voraussetzen und ereignisgesteuert sind.

Erforderlich für Echtzeitsysteme.

Kann hilfreich für Systeme sein, die Parallelität voraussetzen und ereignisgesteuert sind.

Empfohlen für Echtzeitsysteme.

 Kapsel

Ist eigentlich für Echtzeitsysteme bestimmt, kann aber hilfreich für die Modellierung und das Design jedes Systems sein, das ein hohes Maß an Parallelität erfordert.

Empfohlen für Echtzeitsysteme.

Datenmodell Wird verwendet, um die logische und möglicherweise physische Struktur der persistenten Informationen zu beschreiben.

Empfohlen für Projekte, die eine Datenbank verwenden.

Deployment-Modell Zeigt die Konfiguration der Verarbeitungsknoten zur Laufzeit, die Kommunikationsverbindungen zwischen diesen Knoten sowie die Komponenteninstanzen und Objekte auf diesen Knoten.

Optional.

Viele Systeme haben mehrere Verarbeitungsknoten und müssen deshalb das Deployment-Modell berücksichtigen. Es kann jedoch als Abschnitt des Softwarearchitekturdokuments erfasst werden und muss nicht als separates Artefakt geführt werden.

Architekturmachbarkeitsstudie Wird verwendet, um festzustellen, ob eine Lösung vorhanden ist, die die architektonisch relevanten Anforderungen erfüllt. Empfohlen für die meisten Projekte.

Viele Projekte verwenden eine Architekturmachbarkeitsstudie, um die Realisierbarkeit der Anforderungen zu prüfen. Eine Architekturmachbarkeitsstudie kann unter anderem folgende Formen annehmen:

  • Liste bekannter Technologien, die für die Lösung geeignet zu sein scheinen
  • Skizze eines konzeptionellen Modells einer Lösung
  • Simulation einer Lösung
  • Ausführbarer Prototyp
Referenzarchitektur Referenzarchitekturen beschleunigen die Entwicklung und Mindern Risiken durch Wiederverwendung bewährter Lösungen.

Empfohlen für die meisten Projekte.

Wenn eine geeignete Referenzarchitektur vorhanden ist, kann sie die Entwicklung drastisch beschleunigen und Risiken minimieren.

Softwarearchitekturdokument (SAD) Das Softwarearchitekturdokument wird als umfassende Übersicht über die Architektur des Systems verwendet. Diese Übersicht ist hilfreich, um das System zu verstehen und die wichtigsten Entscheidungen in Bezug auf die Architektur zu erfassen.

Empfohlen für die meisten Projekte.

Eine Übersicht über die Softwarearchitektur auf hoher Ebene ist hilfreich, selbst für die kleinsten Systeme. Komplexe Systeme erfordern in der Regel einen höheren Detaillierungsgrad und mehr Sichten als kleinere Systeme.

Benutzerschnittstellenprototyp Wird verwendet, um Funktionalität und Benutzerfreundlichkeit vor dem Beginn der eigentlichen Entwicklung offen zu legen und zu testen. Es ist ein wirksames Mittel zur Validierung des Designs, bevor zu viel Zeit verschwendet wird.

Empfohlen für die meisten Projekte.



Zu verwendenden Berichte festlegen

Welche Berichte verwendet werden, richtet sich nach den Berichtstools, die dem Projekt zur Verfügung stehen. Wenn Tools für Berichterstellung verfügbar sind, wird empfohlen, Berichte für modellorientierte Arbeitsergebnisse wie Designklassen und Anwendungsfallrealisierungen zu generieren. Vorhandene Berichte in Ihrer RUP-Konfiguration werden auf den Beschreibungsseiten für Arbeitsergebnisse bereitgestellt und unter dem jeweiligen Arbeitsergebnis im Baumstrukturbrowser gruppiert.

Vorgehensweise bei der Überprüfung festlegen

Legen Sie die Prüfebene für jedes zu verwendende Arbeitsergebnis fest. Legen Sie insbesondere fest, wie und in welchem Ausmaß die Ergebnisse von Analyse & Design geprüft und abgenommen werden.   

Die Durchführung von Prüfungen während Analyse & Design hat die folgenden Vorteile:

  • Es werden Probleme erkannt, die bei Tests unmöglich oder nur sehr schwer feststellbar sind. Dies betrifft beispielsweise Probleme mit dem Stil und mit dem Layout.  
  • Sie ist ein Mittel, um einen einheitlichen Modellierungsstil durchzusetzen, und gibt den Mitarbeitern die Möglichkeit, voneinander zu lernen.  
  • Es werden Mängel erkannt, die ansonsten erst sehr viel später im Projekt während der Tests festgestellt werden.

Die Durchführung von Prüfungen während Analyse & Design hat die folgenden Nachteile:

  • Sie nimmt Zeit und Ressourcen in Anspruch.  
  • Wenn sie nicht sorgfältig verwaltet wird, kann sich leicht zu falschen Zwecken eingesetzt werden

Die Faktoren, für Prüfungen während Analyse & Design geändert werden können, sind Prüftechniken, Ressourcen und Umfang. Sie können beispielsweise Folgendes für Ihr Projekt entscheiden:

  • Lokale Änderungen an einem Subsystem werden nur von einem Partner geprüft, der die Ergebnisse auf Papier übergibt.
  • Einige Teile des Designs werden gar nicht geprüft. Die Überprüfung wird auf einige Klassen jedes Mitarbeiters des Projekts beschränkt, und es wird darauf vertraut, dass damit sichergestellt ist, dass der Stil der übrigen von ähnlicher Qualität ist.
  • Das Softwarearchitekturdokument wird vom Kunden in einer separaten Besprechung geprüft.
  • Es werden formale Überprüfungsbesprechungen bezüglich Änderungen in wichtigen Schnittstellen abgehalten, d. h. Schnittstellen, die sich auf die Arbeit mehrerer Projektmitarbeiter auswirken.

Weitere Informationen finden Sie in der Anleitung: Prüfebenen.  

Entscheidung bezüglich der Codegenerierung treffen

Die Gestaltung des Designs richtet sich danach, ob Sie aus dem Designmodell Code generieren oder nicht. Wenn Sie Code generieren, muss das Design sehr detailliert sein. Wenn Sie aus dem Design keinen Code generieren, ist es nicht erforderlich, sehr detailliert zu sein. Ganz im Gegenteil, wenn Sie zu detailliert sind, müssen die Details im Design manuell mit dem Code synchronisiert werden.