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.
|
|