Zweck:
|
Den Umfang und die Ziele der Überprüfung definieren.
Die Ansätze, die für jede Kombination aus Umfang und Ziel verwendet wurden, definieren.
|
Für die Überprüfung können verschiedene Ansätze verwendet werden:
-
Darstellungsgesteuert
-
Informationsgesteuert
-
Szenariogesteuert.
Darstellungsgesteuerte Überprüfung
Beschaffen Sie sich eine Darstellung der Architektur (oder erstellen Sie sie), stellen Sie dann Fragen, und diskutieren
Sie basierend auf dieser Darstellung.
Es gibt hier ein breites Spektrum möglicher Situationen, angefangen bei der Organisation, die sich sehr gut mit
Architekturen auskennt und eine verständliche Beschreibung liefert, mit der man die Arbeit beginnen kann, über
Organisationen, bei denen Sie feststellen müssen, wer der Softwarearchitekt ist (möglicherweise ist er verdeckt unter
einem anderen Namen angegeben), und die benötigten Informationen dann von dieser Person anfordern müssen, bis hin zu
Organisationen, für die Softwarearchitektur ein vollkommen unbekanntes Konzept ist. Dieser Prozess wird als
Architektur-Mining bezeichnet und bedeutet in der Praxis, dass man die Architektur aus der Software oder deren
Dokumentation buchstäblich herausbricht und den Quellcode, die Schnittstellen, die Konfigurationsdaten etc. untersucht.
Ein Modell, das verwendet werden kann, um die Darstellung zu organisieren, hat das Format der Architektursichten im
Softwarearchitekturdokument: die logische Sicht organisiert die Hauptklassen (das Objektmodell), die Prozesssicht
beschreibt die Haupt-Threads der Steuerung und deren Kommunikation, die Entwicklungssicht zeigt die verschiedenen
Subsysteme und deren Abhängigkeiten, die physische Sicht beschreibt die Zuordnung der Elemente der anderen Sichten zu
einer oder mehreren physischen Konfigurationen. Organisieren Sie Fragen entlang der verschiedenen Sichten.
Informationsgesteuerte Überprüfung
Erstellen Sie die Liste mit den Informationen - Daten, Messwerte - die für die Begründung erforderlich sind, rufen Sie
die Informationen ab und vergleichen Sie sie mit den Anforderungen oder einem akzeptierten Referenzstandard. Dies gilt
für die Untersuchung bestimmter Qualitätsattribute, z. B. der Leistung oder der Zuverlässigkeit.
Szenariogesteuerte Überprüfung
Dies ist der systematische Was-wäre-wenn-Ansatz. Setzen sie die allgemeinen Fragen in eine Gruppe von Szenarios um, die
das System bearbeiten muss, und stellen Sie - basierend auf den Szenarios - Fragen. Beispiele für Szenarios:
-
Das System wird auf den Plattformen X und Y ausgeführt. (Das reale Qualitätsattribut, das untersucht wird, ist die
Portabilität.)
-
Das System führt diese (zusätzliche) Funktion F aus. (Das reale Qualitätsattribut ist die Erweiterbarkeit.)
-
Das System verarbeitet 200 Anforderungen pro Stunde. (Das reale Qualitätsattribut ist die Skalierbarkeit.)
-
Das System wird vom Benutzer auf dieser Site installiert. (Das reale Qualitätsattribut ist die Vollständigkeit oder
Benutzerfreundlichkeit.)
Die Vorteil dieses Ansatzes ist, dass er die Aufgabe in eine sehr konkrete Perspektive setzt, die für alle
Vertragspartner verständlich ist. Er bietet auch die Möglichkeit, Auslassungen oder Fehler in den Anforderungen
festzustellen, insbesondere, wenn die Anforderungen informell sind, nicht schriftlich erfasst wurden oder sehr
allgemein und knapp gehalten sind. Der Nachteil besteht darin, dass das zu überprüfende Objekt nicht die Architektur
selbst ist, sondern dass das System als Blackbox behandelt wird, in die nur einige Untersuchungen gesendet werden.
In der Praxis sind die Ansätze nicht so klar voneinander getrennt, und es wird eine Mischform praktiziert.
Problemstellungen identifizieren
Die Ermittlung potenzieller Probleme basiert hauptsächlich auf der Einschätzung erfahrener Fachleute. Bestimmte
Fehlermuster werden von Projekt zu Projekt und von Organisation zu Organisation wiederholt. Bestimmte heuristische
Daten können zur Bestimmung von Problemfeldern verwendet werden. Prüflisten können nützlich sein (einige sehr
generische Liste werden später vorgeschlagen), Ergebnisse vorheriger Überprüfungen auch, falls vorhanden.
Erfassen Sie potenzielle Fragen, wenn sie sich ergeben, und beschreiben sie sie in einem neutralen Tonfall, ohne
zu belehren oder zu dramatisieren. Sie können kleine Karteikarten verwenden. Das hilft, Fragen nach Priorität zu
ordnen, zu organisieren und unnötige zu entfernen.
Sortieren Sie die geeigneten Fragen anschließend absteigend nach Umfang oder Auswirkung. Wenn es viele Fragen sind,
berücksichtigen Sie zunächst diejenigen, die direkt mit der Frage in Zusammenhang stehen, und klammern Sie die anderen
Vorschläge zunächst aus, um sie eventuell später zu bearbeiten. Bewerten Sie dann die reale Situation des Problems: Oft
kann man ein Problem wahrnehmen, das vielleicht gar keins ist. Möglicherweise haben Sie nicht mit der richtigen Person
gesprochen, nicht die richtigen Informationen zur Rate gezogen. Sortieren Sie erneut. Stellen Sie sicher, dass es
mehrere Datenpunkte gibt, um die reale Situation eines Problems zu überprüfen. (Unerfahrene Bewerter neigen dazu, sich
zu sehr auf einzelne Threads zu konzentrieren.)
Wenn das Problem bestätigt wurde, sollten Sie schnell feststellen, wie Sie es beheben können. Das heißt nicht, dass Sie
notwendigerweise versuchen müssen, eine Überarbeitung während des Betriebs durchzuführen. Notieren Sie potenzielle
Vereinfachungen, Wiederverwendung und Alternativen (z. B. Kaufen vs. Erstellen).
|