Quality Attributes
Qualitätsziele als Maßstab für Entscheidungen
Die Idee und ihr Nutzen
Eine Versicherung plant ein neues Schadenportal, über das Kunden ihre Schäden melden und den Bearbeitungsstand abfragen. Alle Beteiligten wünschen sich ein Portal, das „schnell und zuverlässig“ ist. Dieser Wunsch ist zu ungenau, um technische Entwürfe miteinander zu vergleichen. Ein Qualitätsziel macht daraus eine überprüfbare Aussage, zum Beispiel: „Wenn 500 Nutzer gleichzeitig im Portal arbeiten, liefern mindestens 95 von 100 Suchanfragen ihr Ergebnis in höchstens zwei Sekunden.“ Mit 500 Nutzern gleichzeitig rechnet die Versicherung nach einem großen Unwetter, und länger als zwei Sekunden warten Kunden ungern auf ein Suchergebnis. Andere Qualitätsziele betreffen das Verhalten bei Ausfällen, den Schutz von Daten oder den Aufwand für spätere Änderungen. Mit solchen Zielen erkennt ein Team auch, wo zwei Ziele einander widersprechen, etwa wenn ein besserer Schutz der Daten bei Ausfällen jede Änderung langsamer macht. Die Eigenschaften, die ein Qualitätsziel messbar macht, heißen Quality Attributes, auf Deutsch Qualitätsmerkmale. Im Ziel für die Suchanfragen ist das Qualitätsmerkmal die Antwortzeit.
Wie funktioniert es?
Das Architekturteam, das die technischen Entwürfe des Schadenportals verantwortet, soll zwischen zwei Entwürfen wählen. Entwurf A ist ein einzelner, leistungsstarker Portalserver. Entwurf B besteht aus drei kleineren Portalservern und einer Lastverteilung, einem Programm, das eingehende Anfragen auf die drei Server aufteilt. Auf allen drei Portalservern läuft dasselbe Portalprogramm, deshalb kann jeder der drei Server jede Anfrage beantworten. Zuerst legt das Architekturteam zwei Ziele fest. Ziel 1 betrifft die Antwortzeit: Wenn 500 Nutzer gleichzeitig aktiv sind, liefern mindestens 95 Prozent der Suchanfragen ihr Ergebnis in höchstens zwei Sekunden, gemessen am Portal über eine Stunde. Das Architekturteam wählt bewusst 95 Prozent und keinen Durchschnitt, weil ein Durchschnitt einzelne sehr langsame Anfragen verdecken würde. Volle 100 Prozent verlangt das Architekturteam nicht, weil einzelne Anfragen immer einmal länger dauern, etwa bei einer kurzen Störung im Netz. Ziel 2 betrifft den Ausfall: Fällt ein Portalserver aus, können Kunden innerhalb einer Minute wieder neue Anfragen stellen. Eine Unterbrechung von einer Minute nimmt ein Kunde beim Melden eines Schadens nach Erfahrung der Fachabteilung noch hin; bei längeren Unterbrechungen rufen viele Kunden im Kundenservice an.
Für die Prüfung nutzt das Architekturteam einen Lasttest, ein Programm, das 500 gleichzeitige Nutzer nachahmt. Der Lasttest schickt zuerst Suchanfragen an Entwurf A. Ist der Portalserver stark genug, erreicht Entwurf A Ziel 1. Beim anschließenden Ausfallversuch schaltet das Architekturteam den Portalserver von Entwurf A absichtlich ab. Weil es keinen Ersatz gibt, steht das Portal still, bis der Portalserver repariert oder neu gestartet ist. Entwurf A verfehlt also Ziel 2. Danach schickt der Lasttest dieselben Anfragen an die Lastverteilung von Entwurf B, und die Lastverteilung teilt sie auf die drei Server von Entwurf B auf. Beim Ausfallversuch schaltet das Architekturteam einen der Server von Entwurf B ab. Nun muss die Lastverteilung den Ausfall innerhalb der Minute aus Ziel 2 erkennen, und die zwei übrigen Server müssen alle 500 Nutzer ohne den dritten Server bedienen können. Erst das Messergebnis zeigt dem Architekturteam, dass Entwurf B beide Ziele erfüllt.
Antwortzeit und Ausfallsicherheit sind Qualitätsmerkmale, also Eigenschaften, die man an einem laufenden System beobachten und messen kann. Qualitätsmerkmale sind keine Bauteile, die man in ein System einbaut, sondern Maßstäbe, an denen man einen Entwurf misst. Ein Qualitätsziel, das eine konkrete Situation und eine messbare Grenze nennt, heißt Qualitätsszenario. Ein Qualitätsszenario nennt zuerst die Eigenschaft, um die es geht, etwa die Antwortzeit. Dazu kommt eine Situation mit Auslöser und Bedingungen. Beispiele sind 500 gleichzeitige Nutzer oder der Ausfall eines Portalservers. Das Qualitätsszenario beschreibt außerdem, wie das System reagieren soll. Zuletzt legt es eine messbare Grenze mit Messort und Zeitraum fest, etwa höchstens zwei Sekunden, gemessen am Portal über eine Stunde. Erst mit allen vier Teilen lässt sich ein Entwurf an dem Qualitätsszenario prüfen.
Das Architekturteam legt die Qualitätsszenarien gemeinsam mit der Fachabteilung und dem Betriebsteam fest. In der Fachabteilung bearbeiten Sachbearbeiter die Schäden, das Betriebsteam verwaltet die Server. Die Fachabteilung weiß zum Beispiel, wie lange Kunden beim Melden eines Schadens eine Unterbrechung hinnehmen, und das Betriebsteam weiß, wie oft ein Server ausfällt. Zusammen wählen die drei Gruppen zuerst die Eigenschaften aus, auf die es besonders ankommt, zum Beispiel Antwortzeit, Ausfallsicherheit und Schutz der Kundendaten. Damit dabei keine Eigenschaft vergessen wird, können sich die drei Gruppen auf eine allgemeine Liste von Qualitätsmerkmalen stützen, etwa die Norm ISO/IEC 25010. Eine solche Liste nennt aber weder eine Situation noch eine Zahl für das eigene System und ersetzt die Qualitätsszenarien deshalb nicht.
Qualitätsziele widersprechen sich oft teilweise. Bestätigt eine Datenbank jede Änderung erst, nachdem ein zweiter Server die Änderung ebenfalls gespeichert hat, sind die Daten bei einem Ausfall besser geschützt. Jede Änderung dauert dafür aber länger, weil die Datenbank auf den zweiten Server wartet. In solchen Fällen legt das Architekturteam ausdrücklich fest, welches Ziel Vorrang hat. Ein Qualitätsziel sorgt nicht dafür, dass ein Entwurf das Ziel erreicht. Ob ein Entwurf ein Ziel tatsächlich erfüllt, zeigt erst eine Berechnung, ein Lasttest oder ein Ausfallversuch. Nach dem Start des Portals misst das Architekturteam im laufenden Betrieb, ob die Ziele erreicht werden. Zeigt diese Messung, dass ein Ziel verfehlt wird oder unnötig streng war, passt das Architekturteam das Ziel gemeinsam mit Fachabteilung und Betriebsteam an.
Qualitätsmerkmale: zwei Entwürfe, zwei messbare Ziele
Wann ist es sinnvoll und wann nicht?
Qualitätsziele helfen
- Eine Entscheidung lässt sich später nur rückgängig machen, wenn große Teile des Systems umgebaut werden. Beispiele sind die Wahl der Datenbank, die Verteilung auf mehrere Server und der Schutz gegen Ausfälle. Ohne Qualitätsziel zeigt sich womöglich erst nach dem Start, dass die gewählte Datenbank 500 gleichzeitige Nutzer nicht bewältigt, und dann muss das Architekturteam große Teile des Systems umbauen.
- Zwei oder mehr technische Entwürfe sollen verglichen werden. Das Architekturteam misst Entwurf A und Entwurf B an denselben zwei Grenzen, statt über die Bedeutung von „schnell“ zu streiten.
- Die Beteiligten verstehen unter „schnell“ verschiedene Dinge. Die Kunden erwarten, dass eine Suche nach ihrem Schaden in zwei Sekunden ein Ergebnis zeigt. Das Betriebsteam hält zehn Sekunden für akzeptabel. Die Fachabteilung denkt an ganz andere Vorgänge, etwa das Laden einer großen Schadenakte. Ohne gemeinsames Qualitätsziel misst jede Gruppe den Entwurf an ihrer eigenen Vorstellung. Ziel 1 legt für alle dieselbe Grenze von zwei Sekunden für die Suche fest.
- Die Beteiligten verstehen unter „zuverlässig“ verschiedene Dinge. Manche erwarten, dass das Portal einen Serverausfall ohne Unterbrechung übersteht. Anderen reicht es, wenn das Portal nach einer Stunde wieder läuft. Ohne gemeinsames Qualitätsziel merken die Beteiligten erst beim ersten echten Serverausfall, dass sie Verschiedenes erwartet haben. Ziel 2 legt eine Minute fest.
- Ein Entwurf soll geprüft werden, bevor er gebaut ist. Solange keine konkrete Situation und keine Zahl feststehen, kann niemand sagen, ob ein Entwurf gut genug ist. Das Architekturteam streitet dann über Meinungen und entdeckt erst nach dem Start, dass das Portal die Erwartungen verfehlt.
Qualitätsziele helfen nicht
- Auf eine Eigenschaft kommt es beim Zweck eines Programms nicht an. Ein internes Auswertungsprogramm läuft zum Beispiel einmal im Monat, und niemand wartet auf sein Ergebnis. Für ein Qualitätsszenario zur Antwortzeit müssten Architekturteam, Fachabteilung und Betriebsteam trotzdem eine Grenze abstimmen und einen Lasttest durchführen, obwohl keine Entscheidung von dieser Grenze abhängt. Das Architekturteam legt deshalb nur für die Eigenschaften Qualitätsszenarien fest, auf die es beim Auswertungsprogramm ankommt, etwa den Schutz der Kundendaten. Die Abstimmung und der Lasttest für die Antwortzeit entfallen.
- Eine Entscheidung lässt sich mit einer Änderung der Einstellungen rückgängig machen, etwa die Zahl der Treffer, die die Suche im Schadenportal auf einer Seite anzeigt. Für ein Qualitätsszenario müssten Architekturteam, Fachabteilung und Betriebsteam erst eine Situation und eine Grenze abstimmen. Stattdessen baut das Architekturteam einen kleinen Prototyp und misst, wie lange die Suche mit 20 und mit 50 Treffern je Seite dauert. Nach dem Messergebnis wählt das Architekturteam den Wert. Ein falscher Wert ist später mit einer weiteren Änderung der Einstellung behoben, und die Abstimmung über ein Qualitätsszenario entfällt.
Nachteile und typische Fehler
Qualitätsziele brauchen Zeit für Abstimmungen, weil Fachabteilung, Betriebsteam und Architekturteam sie gemeinsam festlegen. Lasttests und Ausfallversuche brauchen eine eigene Testumgebung und Vorbereitung. Die Messung im laufenden Betrieb braucht Werkzeuge, die die Antwortzeiten am Portal erfassen.
Typische Fehler und woran man sie erkennt:
- Wunsch statt Ziel: Ein Ziel nennt keine Situation und keine Zahl, etwa „das Portal soll zuverlässig sein“. An einem solchen Ziel kann das Architekturteam Entwurf A und Entwurf B nicht vergleichen. Erkennbar ist das an Zielen, deren Erfüllung sich mit keinem Lasttest und keinem Ausfallversuch prüfen lässt.
- Falsche Messgröße: Das Architekturteam misst einen Durchschnitt. Dauern neun von zehn Anfragen eine halbe Sekunde und jede zehnte Anfrage 15 Sekunden, liegt der Durchschnitt bei knapp zwei Sekunden. Der Durchschnitt verbirgt so die langsamen Anfragen. Erkennbar ist das an Beschwerden über langsame Suchen, obwohl der gemessene Durchschnitt im Ziel liegt.
- Zu strenges Ziel: Ein Ziel verlangt mehr, als die Nutzer brauchen. Um das Ziel zu erreichen, wählt das Architekturteam größere oder mehr Server, als nötig wären, und die Versicherung bezahlt diese Server. Erkennbar ist das an Entwürfen mit großen Servern für Vorgänge, bei denen niemand auf das Ergebnis wartet.
- Zu lockeres Ziel: Das Architekturteam übernimmt die zehn Sekunden, die das Betriebsteam für akzeptabel hält. Die Erwartungen der Kunden werden dann verfehlt. Erkennbar ist das an Kunden, die sich über Wartezeiten beschweren, obwohl das Ziel erfüllt ist.
- Einseitig festgelegt: Nur das Architekturteam legt die Ziele fest und übersieht, was Fachabteilung und Betriebsteam brauchen. Erkennbar ist das an Zielen, die Fachabteilung oder Betriebsteam erst nach dem Start infrage stellen.
- Nie gemessen: Die Ziele stehen in einem Dokument, im laufenden Betrieb misst sie aber niemand. Erkennbar ist das, wenn niemand sagen kann, ob die 95 Prozent im letzten Monat erreicht wurden.
- Ungeprüfte Annahme: Das Architekturteam nimmt an, dass Entwurf B beide Ziele erfüllt, und verzichtet auf den Ausfallversuch. Erkennbar ist das erst beim echten Ausfall, wenn die zwei übrigen Server die 500 Nutzer nicht bewältigen.
Weiterführend
Verwandte Ansätze
- Architecture Decision Records: halten fest, warum ein Entwurf gewählt wurde. Die Qualitätsziele, an denen der Entwurf gemessen wurde, gehören in diese Begründung.
- Redundancy and Failover: beschreibt mehrere gleichartige Server und das Umschalten bei einem Ausfall, wie in Entwurf B. Ob das genügt, zeigt die Prüfung an einem Ziel wie „nach einer Minute wieder nutzbar“.
- Load Balancing: verteilt Anfragen auf mehrere Server, wie die Lastverteilung in Entwurf B.
- Chaos Engineering: schaltet Teile eines Systems absichtlich ab, um zu prüfen, ob Ziele für Ausfälle erreicht werden, wie beim Ausfallversuch mit Entwurf B.
- CAP Theorem: beschreibt, warum verteilte Daten bei einer Unterbrechung des Netzes zwischen den Servern nicht zugleich übereinstimmen und verfügbar sein können.
Quellen
- Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, 4. Auflage: Standardwerk, das Qualitätsmerkmale wie Geschwindigkeit, Änderbarkeit und Sicherheit behandelt und im dritten Kapitel beschreibt, wie man sie als Qualitätsszenarien festlegt.
- ISO/IEC 25010:2023: Product quality model: internationale Norm mit einem Modell aus neun Qualitätsmerkmalen und ihren Untermerkmalen, an dem sich die Auswahl der wichtigen Eigenschaften ausrichten kann.