Aufgabe: Architektur prüfen
Diese Aufgabe bestimmt, wann und wie eine Überprüfung der Architektur durchgeführt werden soll und wie mit den Ergebnissen der Überprüfungen umzugehen ist.
Zweck
  • Alle unbekannten oder wahrgenommenen Risiken im Zeitplan oder im Budget aufdecken.
  • Alle Fehler im Design der Architektur ermitteln. Fehler in der Architektur sind am schwierigsten zu beheben, die meisten sind langfristig zerstörerisch.
  • Potenzielle Diskrepanzen zwischen den Anforderungen und der Architektur ermitteln: zu viel Design, unrealistische Anforderungen oder fehlende Anforderungen. Insbesondere bei der Bewertung können einige Aspekte, die in den Bereichen Bedienung, Verwaltung und Pflege häufig vernachlässigt werden, untersucht werden. Wie ist das System installiert? Wie wird es aktualisiert? Wie erfolgt der Übergang der aktuellen Datenbanken?
  • Gehen Sie wie folgt vor, wenn Sie eine oder mehrere Eigenschaften der Architektur bewerten möchten: Leistung, Zuverlässigkeit, Modifizierbarkeit, Sicherheit.
  • Chancen der Wiederverwendung identifizieren
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Schritte
Allgemeine Empfehlungen
Zweck: Allgemeine Empfehlungen für jede Überprüfung.

Bei einer sehr allgemeinen Betrachtungsweise gibt es nicht viele Unterschiede zwischen der Bewertung einer Softwarearchitektur und einer anderen Bewertung oder Überprüfung.

Ein wichtiges Merkmal der Softwarearchitektur ist der Mangel spezifischer Messwerte für viele Qualitätsattribute der Architektur. Nur einige Merkmale der Architektur können objektiv gemessen werden. Leistung ist ein Beispiel für eine Größe, die gemessen werden kann. Andere Eigenschaften sind eher qualitativ oder subjektiv, z. B. die konzeptionelle Integrität. Darüber hinaus ist es oft sehr schwierig, festzustellen, was ein Messwert bedeutet, wenn andere Daten oder Referenzdaten für den Vergleich fehlen. Wenn ein Bezugssystem verfügbar ist und von der Zielgruppe verstanden wird, ist es oft angemessen, einige der Ergebnisse der Überprüfung relativ zu diesem Bezugssystem auszudrücken. Dies kann in einem Kontext geschehen, in dem das zu entwerfende System mit einem älteren System verglichen wird.

Der Zeitpunkt, zu dem diese Bewertung stattfindet, wirkt sich ebenfalls auf ihren Zweck oder ihren Sinn aus.

Iterationsdiagramm für Projektlebenszyklus

  1. Am Ende der Konzeptionsphase in einem ersten Entwicklungszyklus ist normalerweise nur wenig konkrete Architektur vorhanden. Aber eine Überprüfung kann einige unrealistische Ziele, fehlende Teile, nicht wahrgenommene Chancen zur Wiederverwendung vorhandener Produkte etc. zu Tage fördern.
  2. Der natürlichste Zeitpunkt für die Bewertung einer Softwarearchitektur liegt am Ende der Ausarbeitungsphase. Diese Phase konzentriert sich hauptsächlich auf die Ermittlung von Details und die Referenzierung einer Architektur. RUP schreibt eine Überprüfung der Architektur an diesem Meilenstein vor. Hier wird ein breites Spektrum von Architektureigenschaften überprüft.
  3. Detaillierte Bewertungen können während der Konstruktionsphase stattfinden, um spezifische Qualitätsattribute, z. B. Leistung oder Sicherheit, zu untersuchen, oder am Ende der Konstruktionsphase, um verbleibende Fragen, die die Freigabe des Produkts noch verhindern, zu klären.
  4. Bewertungen zur Schadenskontrolle können spät in der Konstruktions- oder sogar in der Übergangsphase stattfinden, wenn tatsächlich Dinge schief gegangen sind, wenn z. B. die Konstruktion nicht abgeschlossen werden kann oder während der Übergangsphase des installierten Basisprodukts inakzeptabel viele Fehler auftreten.
  5. Am Ende der Übergangsphase schließlich findet die Bewertung statt, insbesondere, um wiederverwendbare Assets für ein eventuelles neues Produkt oder einen neuen Weiterentwicklungszyklus zu inventarisieren.

Der "Partner"-Prüfer hat dasselbe Mitarbeiterprofil wie die Rolle: 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 Mängel in der Architektur entdecken, 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 Architekturprüfer muss Risiken und Kosten in ein Gleichgewicht bringen. Die Kosten bleiben ein heikler Punkt bei den allgemeinen Fragen, die den Projekterfolg bestimmen. Der Architekturprüfer muss auch ein überzeugender Kommunikator sein, der in der Lage ist, heikle Fragen zur Sprache zu bringen und zu diskutieren.

Empfohlene Prüfbesprechungen
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).

Zuständigkeiten für die Mängelbehebung
Zweck: Maßnahmen zur Behebung der identifizierten Mängel ergreifen.  

Weisen Sie nach der Überprüfung für jeden identifizierten Mangel die Zuständigkeit zu. In diesem Kontext liegt die "Zuständigkeit" nicht unbedingt darin, den Mangel zu beheben, sondern die weitere Suche nach Alternativen bzw. die Behebung des Mangels zu koordinieren, wenn er weitreichende Konsequenzen hat oder umfangreich ist.



Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen