Aufgabe: Design prüfen
Diese Aufgabe bestimmt, wie eine Überprüfung des Designs durchgeführt werden soll und wie mit den Ergebnissen der Überprüfungen umzugehen ist.
Zweck
  • Sicherstellen, dass das Designmodell die Anforderungen an das System erfüllt und eine taugliche Basis für die Implementierung des Systems darstellt.
  • Sicherstellen, dass das Designmodell mit den allgemeinen Designrichtlinien konsistent ist.
  • Sicherstellen, dass die Designrichtlinien ihre Zielsetzungen erfüllen.
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Schritte
Allgemeine Empfehlungen
Zweck Allgemeine Empfehlungen für jede Überprüfung.

Der "Partner"-Prüfer hat dasselbe Mitarbeiterprofil wie der Softwarearchitekt, konzentriert sich allerdings stärker auf technische Fragen. Führungsqualität, Reife, Pragmatismus und Ergebnisorientierung sind ebenfalls zu einem gewissen Grad notwendig, denn ein Prüfer kann Designmängel aufdecken, die wahrscheinlich unpopulär sind, wenn sie den Zeitplan des Projekt bedrohen. Dennoch ist es besser, kritische Punkte früh zur Sprache zu bringen, so dass Lösungen gefunden werden können, als blind einem Plan zu folgen, der das Projektteam auf den falschen Weg bringt. Der Designprüfer muss Risiken und Kosten in ein Gleichgewicht bringen. Die Kosten bleiben ein heikler Punkt bei den allgemeinen Fragen, die den Projekterfolg bestimmen. Der Designprüfer muss auch ein überzeugender Kommunikator sein, der in der Lage ist, heikle Fragen zur Sprache zu bringen und zu diskutieren. Vom technischen Standpunkt aus gesehen muss der Designprüfer Erfahrungen in der Rolle eines Designers haben.
Designmodell als Ganzes prüfen
Zweck:  Sicherstellen, dass die Gesamtstruktur des Designmodells klar gestaltet ist.
Weitreichende Qualitätsmängel aufdecken, die bei Sichtung der Elemente auf unterer Ebene nicht zu Tage treten. 


Das Designmodell muss als Ganzes geprüft werden, um deutliche Fehler in der Schichtung und in der Verteilung der Zuständigkeiten aufzudecken. Bei der Überprüfung des vollständigen Designmodells sollen weitreichende Probleme aufgedeckt werden, die bei einer Detailprüfung nicht erkannt werden können.

In der Konzeptionsphase und in einem frühen Stadium der Ausarbeitungsphase konzentriert sich diese Überprüfung auf die Gesamtstruktur des Modells mit besonderem Schwerpunkt auf die Schichtung und auf die Schnittstellen. Paket- und Subsystemabhängigkeiten müssen untersucht werden, um eine lose Kopplung zwischen Paketelementen sicherzustellen. Der Inhalt der Pakete und Subsysteme muss untersucht werden, um eine hohe Kohäsion innerhalb der Paketelemente zu gewährleisten. Es müssen generell alle Elemente untersucht werden, um sicherzustellen, dass sie klare und angemessene Zuordnungen haben und dass ihre Namen diese Zuständigkeiten widerspiegeln.

Nachdem die Architekturprototypen entwickelt wurden, muss eine umfassendere Überprüfung des Designs erfolgen. Das Modell muss zunächst auf Vollständigkeit insgesamt und dann sorgfältiger auf Mängel hin untersucht werden.

Alle Designanwendungsfallrealisierungen prüfen
Zweck Sicherstellen, dass das Verhalten des Systems (das in den Designanwendungsfallrealisierungen beschrieben ist) dem vom System geforderten Verhalten (das in Anwendungsfällen beschrieben ist) entspricht, d. h. dass es vollständig ist.
Sicherstellen, dass das Verhalten angemessen auf die Modellelemente verteilt worden ist, d. h. korrekt ist.  


Nachdem Sie die Struktur des Designmodelle geprüft haben, muss das Verhalten des Modells geprüft werden. Stellen Sie zunächst sicher, dass kein Verhalten fehlt. Vergewissern Sie sich, dass alle Szenarios für die aktuelle Iteration durch die Designanwendungsfallrealisierungen vollständig abgedeckt sind. Das gesamte Verhalten der Unterabläufe der relevanten Anwendungsfälle muss in den fertig gestellten Designanwendungsfallrealisierungen beschrieben sein.

Wenn das Verhalten des Systems ereignisgesteuert ist, haben Sie möglicherweise Zustandsdiagramme verwendet, um das Verhalten des Anwendungsfalls zu beschreiben. Wenn Zustandsdiagramme vorhanden sind, müssen diese untersucht werden, um sicherzustellen, dass sie das korrekte Verhalten beschreiben. Einzelheiten hierzu finden Sie in Technik: Zustandsdiagramm. In Echtzeitsystemen, in denen  Protokolle verwendet werden, um interagierende  Kapseln zu beschreiben, müssen diese Arbeitsergebnisse geprüft werden, um sicherzustellen, dass sie das korrekte Verhalten erbringen.

Stellen Sie anschließend sicher, dass das Verhalten der Designanwendungsfallrealisierung korrekt auf die Modellelemente in den Realisierungen verteilt wurde. Vergewissern Sie sich, dass die Operationen korrekt verwendet werden, dass alle Parameter übergeben werden und dass die Rückgabewerte den korrekten Typ haben.

Designelemente prüfen
Zweck:  Sicherstellen, dass die interne Implementierung des Designelements das von ihm geforderte Verhalten erbringt.  

Sie müssen für jedes Designelement (d. h. Designklasse oder Designsubsystem), dem Verhalten zugeordnet ist, das interne Design prüfen. Für Designsubsysteme bedeutet dies, dass sichergestellt werden muss, dass das in den offen gelegten Schnittstellen spezifizierte Verhalten einem oder mehreren der enthaltenen Designelemente zugeordnet wurde. Für Designklassen bedeutet es, dass die Beschreibung jeder Operation so definiert ist, dass eine eindeutige Implementierung möglich ist.

Designrichtlinien prüfen
Zweck Sicherstellen, dass die designbezogenen projektspezifischen Richtlinien stets aktuell sind, und eventuell in den Richtlinien vorhandene Mängel beseitigen. 


Suchen Sie auf der Basis der Designüberprüfung nach Mängeln in den Designrichtlinien.

  • Wurden die Richtlinien befolgt? Wenn nicht, warum?
  • Sind sie korrekt? Wurden systematische Mängel gefunden, die auf fehlerhafte Richtlinien zurückzuführen sind?
  • Sind sie vollständig? Hätten systematische Mängel verringert werden können, wenn die Anleitung bereitgestellt worden wäre?
Prüfunterlagen vorbereiten und Mängel dokumentieren
Zweck Prüfergebnisse dokumentieren.
Sicherstellen, dass aufgedeckte Mängel dokumentiert wurden. 


Nach jeder Prüfbesprechung werden die Ergebnisse der Besprechung in Prüfunterlagen dokumentiert. Zusätzlich werden alle Mängel in Übereinstimmung mit dem Änderungsmanagementprozess des Projekts dokumentiert.



Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen