11. Qualitätsszenarien
11.1 Qualitätsbaum
(engl.: Quality Tree) Erweitern und systematisieren Sie in diesem Kapitel die Architekturziele zu einem Qualitätsbaum.
Dieser gibt Ihnen zusätzlich zu den Architekturzielen von Abschnitt 1.2. präzise und systematische Anhaltspunkte für Ihre Entwurfsentscheidungen.
Nutzen Sie als Form eine baumartige Zerlegung des Begriffes "Qualität". Auf der ersten Ebene führen Sie Ihre allerwichtigsten Qualitätskategorien auf. Dann zerlegen Sie jeden Ast so weit, bis Sie bei konkreten Szenarien angelangt sind, die Ihre Architektur auf jeden Fall erfüllen sollte. Falls Sie den Qualiätsbaum auch für die Bewertung Ihrer Architektur verwenden, sollten Sie ihn mit Prioritäten ergänzen (sowohl aus Sicht der Wichtigkeit in Ihrem Geschäftsumfeld, wie auch mit dem Risikofaktor in der Umsetzung.
Mehr dazu und Bespiele finden Sie in dem Buch "Evaluating Software Architectures" von Paul Clements u.a., Addison Wesley oder im Kapitel 9 bei Gernot Starke (Effektive Software-Architekturen, Carl-Hanser-Verlag) .
11.2 Szenarien
Szenarien beschreiben, was beim Eintreffen eines Stimulus auf ein System in bestimmten Situationen geschieht. Sie charakterisieren damit das Zusammenspiel von Stakeholdern mit dem System. Szenarien operationalisieren Qualitätsmerkmale (aus den Zielen in Kap. 1.2 oder dem Qualitätsbaum in Kap. 1.3.) und machen sie messbar.
Wesentlich für die meisten Software-Architekten sind zwei Arten von Szenarien:
Als Form könne Sie entweder Tabellen verwenden oder aber Freitext. Sie sollten die Bestandteile (Quelle, Umgebung, Systembestandteil, Antwort, Antwortmetrik) explizit kenntlich machen.
Es gibt inhaltliche Zusammenhänge zwischen diesen Szenarien und der Laufzeitsicht (in Kapitel 5). Häufig können Sie die Szenarien der Laufzeitsicht für die Bewertung wieder verwenden oder zugrunde legen. In die Bewertungsszenarien fließen (im Gegensatz zu den Laufzeitszenarien) noch Antwortmetriken ein, die bei der reinen Ablaufbetrachtung der Laufzeitsichten häufig entfallen. Außerdem sind Bewertungsszenarien oft als Black-Box-Szenarien konzipiert, während bei Laufzeitszenarien das interne Zusammenspiel der Bausteine zur Laufzeit im Vordergrund steht.
11.1 Qualitätsbaum
(engl.: Quality Tree) Erweitern und systematisieren Sie in diesem Kapitel die Architekturziele zu einem Qualitätsbaum.
Dieser gibt Ihnen zusätzlich zu den Architekturzielen von Abschnitt 1.2. präzise und systematische Anhaltspunkte für Ihre Entwurfsentscheidungen.
Nutzen Sie als Form eine baumartige Zerlegung des Begriffes "Qualität". Auf der ersten Ebene führen Sie Ihre allerwichtigsten Qualitätskategorien auf. Dann zerlegen Sie jeden Ast so weit, bis Sie bei konkreten Szenarien angelangt sind, die Ihre Architektur auf jeden Fall erfüllen sollte. Falls Sie den Qualiätsbaum auch für die Bewertung Ihrer Architektur verwenden, sollten Sie ihn mit Prioritäten ergänzen (sowohl aus Sicht der Wichtigkeit in Ihrem Geschäftsumfeld, wie auch mit dem Risikofaktor in der Umsetzung.
Mehr dazu und Bespiele finden Sie in dem Buch "Evaluating Software Architectures" von Paul Clements u.a., Addison Wesley oder im Kapitel 9 bei Gernot Starke (Effektive Software-Architekturen, Carl-Hanser-Verlag) .
11.2 Szenarien
Szenarien beschreiben, was beim Eintreffen eines Stimulus auf ein System in bestimmten Situationen geschieht. Sie charakterisieren damit das Zusammenspiel von Stakeholdern mit dem System. Szenarien operationalisieren Qualitätsmerkmale (aus den Zielen in Kap. 1.2 oder dem Qualitätsbaum in Kap. 1.3.) und machen sie messbar.
Wesentlich für die meisten Software-Architekten sind zwei Arten von Szenarien:
- Nutzungsszenarien (auch genannt Anwendungs- oder Anwendungsfallszenarien) beschreiben, wie das System zur Laufzeit auf einen bestimmten Auslöser reagieren soll. Hierunter fallen auch Szenarien zur Beschreibung von Effizienz oder Performance. Beispiel: Das System beantwortet eine Benutzeranfrage innerhalb einer Sekunde.
- Änderungsszenarien beschreiben eine Modifikation des Systems oder seiner unmittelbarer Umgebung. Beispiel: Eine zusätzliche Funktionalität wird implementiert oder die Anforderung an ein Qualitätsmerkmal ändert sich.
- Grenz- oder Stress-Szenarien beschreiben, wie das System auf Extremsituationen reagiert. Beispiele: Wie reagiert das System auf einen vollständigen Stromausfall, einen gravierenden Hardwarefehler oder Ähnliches.
- Auslöser (stimulus): beschreibt eine spezifische Zusammenarbeit des (auslösenden) Stakeholders mit dem System. Beispiele: Ein Benutzer ruft eine Funktion auf, ein Entwickler programmiert eine Erweiterung, ein Administrator installiert oder konfiguriert das System.
- Quelle des Auslösers (source): beschreibt, woher der Auslöser kommt. Beispiele: intern oder extern, Benutzer, Betreiber, Angreifer, Manager.
- Umgebung (environment): beschreibt den Zustand des Systems zum Zeitpunkt des Auslösers. Befindet sich das System unter Normal- oder Höchstlast? Ist die Datenbank verfügbar oder nicht? Sind Benutzer online oder nicht? Hier sollten Sie alle Bedingungen beschreiben, die für das Verständnis des Szenarios wichtig sind.
- Systembestandteil (artifact): beschreibt, welcher Bestandteil des Systems vom Auslöser betroffen ist. Beispiele: Gesamtsystem, Datenbank, Webserver.
• Antwort (response): beschreibt wie das System durch seine Architektur auf den Auslöser reagiert. Wird die vom Benutzer aufgerufene Funktion ausgeführt? Wie lange benötigt der Entwickler zur Programmierung? Welche Systemteile sind von Installation/Konfiguration betroffen? - Antwortmetrik (response measure): beschreibt, wie die Antwort gemessen oder bewertet werden kann. Beispiele: Ausfallzeit in Stunden, Korrektheit Ja/Nein, Änderungszeit in Personentagen, Reaktionszeit in Sekunden.
Als Form könne Sie entweder Tabellen verwenden oder aber Freitext. Sie sollten die Bestandteile (Quelle, Umgebung, Systembestandteil, Antwort, Antwortmetrik) explizit kenntlich machen.
Hintergründe
Es gibt inhaltliche Zusammenhänge zwischen diesen Szenarien und der Laufzeitsicht (in Kapitel 5). Häufig können Sie die Szenarien der Laufzeitsicht für die Bewertung wieder verwenden oder zugrunde legen. In die Bewertungsszenarien fließen (im Gegensatz zu den Laufzeitszenarien) noch Antwortmetriken ein, die bei der reinen Ablaufbetrachtung der Laufzeitsichten häufig entfallen. Außerdem sind Bewertungsszenarien oft als Black-Box-Szenarien konzipiert, während bei Laufzeitszenarien das interne Zusammenspiel der Bausteine zur Laufzeit im Vordergrund steht.