In meinem vorherigen Beitrag in der Kategorie Architektur habe ich mich mit Qualitätsmerkmalen befasst. Nun soll es, wie damals angekündigt, um Qualitätsszenarien gehen. Ich arbeite in diesem Artikel wieder mit dem Beispiel meines Passwortmanagers. Dieser hat nun endlich einen neuen Namen gefunden! Zum Zeitpunkt des vorherigen Beitrags trug er noch den Namen PwMan3. Ich werde den alten Artikel so belassen, von nun aber den neuen Namen Passbird verwenden.
Qualitätsszenarien sind konkrete Beispiele, wie sich Software in einer bestimmten Situation verhält. Dabei zahlen sie auf ein oder mehrere Qualitätsmerkmale ein. Das aus meiner Sicht wesentlichste Merkmal eines Qualitätsszenarios ist die direkte Messbarkeit. Während unter Zuverlässigkeit verschiedene Leute verschiedene Dinge verstehen, sollte ein Qualitätsszenario idealerweise so formuliert sein, dass es objektiv als erfüllt oder nicht erfüllt gewertet werden kann.
Jedes Qualitätsszenario hat einen Stimulus d.h. ein Ereignis, das auf ein System einwirkt und eine Metrik, die das Verhalten des Systems, also die Reaktion auf das Ereignis, messbar macht. Qualitätsszenarien werden in drei Kategorien unterteilt:
Benutzungsszenarien beschreiben das Verhalten des Systems in Bezug auf die gestellten fachlichen Anforderungen. Diese zahlen oftmals auf das Qualitätsmerkmal der funktionalen Eignung ein. Weiter unten liste ich am Beispiel von Passbird diverse Benutzungsszenarien auf.
Änderungsszenarien beschreiben das Verhalten in Bezug auf Änderungen, Erweiterungen oder Konfigurationen. Für ein Warenwirtschaftssystem kann ein relevantes Änderungsszenario beispielsweise die Anpassung des Systems auf einen geänderten Umsatzsteuersatz sein, wie es ihn zuletzt im Zuge des Corona-Konjunkturpakets gegeben hat. Eine Reaktion auf dieses Ereignis könnte sein, dass sich der Steuersatz konfigurativ ändern lässt, oder sich die Änderung mit einem Entwicklungsaufwand von X Tagen umsetzen lässt.
Ausfallszenarien beschreiben das Verhalten im Fall von Fehlern und Störungen. In komplexen Systemen können hier verschiedenste Szenarien wie der Ausfall eines externen Dienstes, einer Datenbank, eines Netzes, ein Stromausfall oder Fehleinstellungen in Infrastrukturdiensten wie einer Firewall betrachtet werden. Eine Differenzierung nach Zeitpunkt kann sinnvoll sein, da bestimmte Systeme über Nacht oder an Feiertagen vieleicht nicht genutzt werden müssen und eine kurze Wiederherstellungszeit zu jedem Zeitpunkt in der Konsequenz unnötig teuer sein würde.
Qualitätsszenarien sind Beispiele und erheben keinen Anspruch auf Vollständigkeit. Sie entstehen in Kollaboration zwischen Domänenexperten, Product Ownern und Architekten bzw. Entwicklern. Qualitätsszenarien fördern die Zusammenarbeit und stellen ein klares, gemeinsames Bild über die wesentlichen Anforderungen an ein Produkt oder System her.
Qualitätsszenarien sind eine gute Basis, um informierte und nachhaltige Architekturentscheidungen treffen zu können, Risiken zu erfassen und Prioritäten festzulegen. Wichtig ist, bei der Formulierung der Szenarien und gerade beim Verhalten des Systems Anforderungen und Lösungen nicht miteinander zu verwechseln. Ein horizontal skalierbares System kann eine gute Antwort auf hohe Lastspitzen darstellen, muss aber nicht zwingend über Microservices realisiert werden.
Die Anzahl der Qualitätsszenarien variiert je nach System. Für Passbird habe ich zur Demonstration 23 Qualitätsszenarien formuliert. Ein großes, komplexes System kann leicht ein Vielfaches davon haben. Da es ab einer gewissen Anzahl nicht mehr möglich ist, alle Szenarien gleichzeitig im Kopf zu haben und den Überblick zu behalten, sollten diese strukturiert heruntergeschrieben werden. Als Minimum würde ich jedem Szenario eine festes Kürzel geben, mit dem ich mich eindeutig darauf beziehen kann, und in diesem Kürzel kenntlich machen, auf welches Qualitätsmerkmal sich das Szenario vorrangig bezieht.
Qualitätsszenarien für Passbird
Für Passbird habe ich folgende Qualitätsmerkmale herangezogen:
- Funktionale Eignung
- Zuverlässigkeit
- Performance
- Benutzbarkeit
- Informationssicherheit
- Wartbarkeit
- Übertragbarkeit
Die nachfolgenden Qualitätsszenarien habe ich als wesentlich erachtet. Diese sind natürlich nicht in Stein gemeißelt und können zu einem späteren Zeitpunkt reduziert, angepasst oder erweitert werden. Da es sich bei Passbird um eine leicht installier- und portierbare reine Client-Anwendung handelt, stehen für mich die Benutzungsszenarien klar im Vordergrund. Gegenüber einer komplexen Cloud-Anwendung kommen die Ausfallszenarien hier also sehr kurz.
| ID | Qualitätsszenario |
| F1 | Ein Benutzer möchte für die Registrierung auf einer Webseite ein sicheres Passwort generieren. Er verwendet dafür den Set-Password-Befehl. |
| F2 | Ein Benutzer möchte den PIN seiner SIM-Karte in Passbird ablegen. Er verwendet dafür den Custom-Set-Password-Befehl. |
| F3 | Ein Benutzer möchte den Passworteintrag zu einem gelöschten Konto entfernen. Er verwendet dafür den Delete-Password-Befehl. |
| F4 | Ein Benutzer möchte sich an einem Dienst anmelden und das in Passbird abgelegte Passwort dafür in die Zwischenablage kopieren. Er verwendet dafür den Get-Password-Befehl. |
| F5 | Ein Benutzer möchte sich das Passwort zu einem Eintrag auf der Kommandozeile anzeigen lassen. Er verwendet dafür den View-Password-Befehl. |
| F6 | Ein Benutzer möchte seine Passwörter aus der geschützten Passwortdatenbank in maschinenverständlicher Form exportieren. Er verwendet den Export-Passwords-Befehl, mit dem alle Einträge in eine strukturierte Klartextdatei geschrieben werden. |
| F7 | Ein Benutzer möchte Passbird für mehrere voneinander getrennte Benutzer auf einem Computer konfigurieren. Er legt für die Konfigurationen verschiedene Verzeichnisse an und übergibt diese bei Programmstart an Passbird, so dass jeder Benutzer seine eigene Passwortdatenbank mit eigenem Masterpasswort verwendet. |
| F8 | Ein Benutzer möchte nachschauen, wie er einen Passworteintrag löschen kann. Er lässt sich mit dem Help-Befehl alle Befehle ausgeben, worin enthalten auch der Befehl zum Löschen eines Eintrags ist. |
| P1 | Ein Benutzer startet Passbird und gibt das Masterpasswort ein. Nach weniger als einer Sekunde kann er weitere Befehle eingeben. |
| P2 | Ein Benutzer hat 500 Passwörter in der Passwortdatenbank abgelegt. Passbird startet nach Eingabe des Masterpasswortes in weniger als einer Sekunde. |
| P3 | Ein Benutzer gibt den Befehl ein um ein Passwort in die Zwischenablage zu kopieren. Nach weniger als einer Sekunde ist der Befehl umgesetzt. |
| Z1 | Ein Bug in Passbird korrumpiert die Passwortdatenbank. Durch das automatische Backup kann der Benutzer den letzten gültigen Stand der Datenbank wiederherstellen und auf seine Passwörter zugreifen. |
| Z2 | Ein Entwickler nimmt eine Änderung am Quellcode vor und führt eine Regression ein. Durch die hohe Testabdeckung wird der Fehler automatisch entdeckt, bevor die Änderung in ein neues Release aufgenommen wird. |
| B1 | Ein Benutzer möchte ein Passwort anzeigen oder in die Zwischenablage kopieren. Er muss dafür nur einen Befehl eingeben. |
| B2 | Ein Benutzer probiert alle Befehle von Passbird einmal aus. Er benötigt dafür keine Maus. |
| B3 | Ein Benutzer möchte Passbird aktualisieren. Er muss dafür lediglich eine Datei austauschen. |
| I1 | Ein bösartiges Programm auf dem Benutzergerät fertigt einen Abzug des Hauptspeichers an, während Passbird aktiv verwendet wird. In dem Abzug sind keine unverschlüsselten Passwörter enthalten. |
| I2 | Ein Unbefugter erhält Zugriff auf die Passwortdatenbank. Da der Benutzer bei Einrichtung von Passbird ein sicheres Passwort gewählt hat, schafft der Unbefugte es nicht, durch Brute-Force-Vorgehen Zugriff auf die Passwörter zu erhalten. |
| I3 | Ein Benutzer gibt einen Befehl ein um ein Passwort in die Zwischenablage zu kopieren. Nach kurzer Zeit wird das Passwort wieder automatisch aus der Zwischenablage entfernt. |
| W1 | Ein Entwickler möchte als Backend eine relationale Datenbank einsetzen. Er muss dafür lediglich ein neues Modul schreiben und die bestehende Schnittstelle implementieren. |
| W2 | Ein Entwickler möchte als Frontend eine graphische Benutzeroberfläche umsetzen. Er muss dafür lediglich ein neues Modul schreiben und die bestehende Schnittstelle implementieren. |
| W3 | Ein Entwickler möchte die Geschäftslogik übernehmen und das technische Grundgerüst komplett neu machen. Durch die strikte Trennung von Fachlichkeit und Technik kann er einfach das Domänenmodul unverändert übernehmen. |
| Ü1 | Ein Benutzer möchte Passbird auf seinem privaten Windows-Computer und beruflich genutzten MacBook mit der gleichen Passwortdatenbank einsetzen. Passbird ist auf beiden Geräten mit gleichem Funktionsumfang lauffähig und kann unter Zuhilfenahme eines Synchronisationsdienstes auf die gleiche Passwortdatenbank zugreifen. |
Wie man an den Qualitätsszenarien von Passbird erkennt, besteht ein Ereignis meist aus einem Akteur und einer Aktion, die dieser Akteur ausführt. Auch zeigt sich hier, dass das Verhalten des Gesamtsystems nicht das Verhalten der programmierten Software alleine ist, sondern den Umgang damit und das Umfeld mit einbeziehen kann. Passbird forciert kein sicheres Masterpasswort, hat aber den Anspruch, die Passwörter gut zu schützen, wenn der Benutzer sich für ein sicheres Passwort entscheidet. Passbird stellt ebenfalls keine Funktion bereit, um die Passwortdatenbank automatisch zwischen mehreren Computern zu synchronisieren. Durch die Abbildung der Datenbank als schlanke, einzelne Datei, die nach jeder Änderung sofort aktualisiert wird, bietet es aber die Möglichkeit, auf diese Arbeit spezialisierte Dienste leicht in das Gesamtökosystem einzubinden.
Fazit
Qualitätsszenarien machen ein System greifbar, zeigen auf, was wirklich wichtig ist, und festigen getroffene Architekturentscheidungen. In Bezug auf Ausfälle haben Qualitätsszenarien für mich das große Potential aufzuzeigen, welche Fehlerszenarien aktiv berücksichtigt wurden, welcher Stellenwert diesen eingeräumt wird (Risikoanalyse) und welche Szenarien ausgelassen wurden.
Qualitätsszenarien halten einem ständig vor Augen, wie die Qualitätsansprüche an ein System aussehen und ob diese auch tatsächlich eingehalten werden. Entwickler können diese auch als Argumentshilfe nutzen, wenn die Qualität aus ihrer Sicht zu kurz kommt, oder um sich Klarheit zu geänderten Qualitätsvorstellungen zu verschaffen.