Mit Spinnweben zur qualitätssicheren Anwendung

| Angie E.

Wer kennt es nicht? Eine*r freut sich auf den nächsten Restaurantbesuch, hat im Vorfeld Google-Reviews zur Qualität des Essens und dazugehörige Fotos für einen Eindruck des Ambientes genauestens inspiziert und ist dann dennoch vor Ort bitter enttäuscht: die Akustik ist so schlecht, dass der Lautstärkepegel buchstäblich ohrenbetäubend ist, die Stühle sind unbequem und das heiß-ersehnte Steak ist ausverkauft. 

Was dieses Beispiel aus dem Leben mit Qualität zu tun hat? Folgendes:

Genauso wie die gut recherchierte Restaurantauswahl, die nach den naheliegenden Kriterien erfolgte, können eher versteckte Anforderungen unter der Haube für den Erfolg oder Misserfolg einer Situation ausschlaggebend sein, wie z.B. die Möglichkeit sich während des Essens zu unterhalten, ohne am Folgetag heiser zu sein. Im Softwarekontext heißt dies, dass auch Anwendungen nichtfunktionalen (also gar selbstverständlichen) Qualitätsmängeln ausgesetzt sind. Es gilt bei der Softwareentwicklung ebenso nicht nur auf das Offensichtliche zu achten, sondern zusätzlich die Qualität von dem Selbstverständlichen im Auge zu behalten (wie z.B. dass bei Klick in kürzester Zeit etwas passiert und nicht erst nach 10 Sekunden). Die Qualitätsspinne ist in diesem Kontext genau solch eine Methode, um nichtfunktionalen Anforderungen aus der DIN-Welt zu integrieren.

Aber was bedeutet Qualität eigentlich und um welche Spinne geht es? 

In der Theorie ist Qualität nach der DIN EN ISO 9000:2015-11 der „Grad, in dem ein Satz inhärenter Merkmale eines Objekts Anforderungen erfüllt“. In der Praxis ist “Qualität bei der Arbeit” ein Begriff, der meist sinnbildlich für viele Prozesse steht, die versuchen, den besagten Grad zu messen. 

Sind die Anforderungen, die es zu erfüllen gilt, funktionaler Natur, gestaltet sich diese Messung relativ simpel. Oder in den Worten der Scrum-Welt ausgedrückt: sind die Definition of Done und Akzeptanzkriterien einer User Story erfüllt, ist der Anspruch an fachlicher Qualität erfüllt. Aber was ist mit den Selbstverständlichkeitsanforderungen oder den Anforderungen, die zwischen den Zeilen bzw. sich in dem Gesamtbild des Haufens von User Stories im Backlog verstecken?

Bereits bei der (nicht einheitlich vorhandenen) Definition der nichtfunktionalen Anforderungen sind Unterschiede ersichtlich. Es gibt viele Kategorien (siehe DIN EN ISO 25010:2011), die sinnbildlich die nichtfunktionalen Ziele widerspiegeln, die gerade in der Welt der Softwareentwicklung als besonders sinnvoll erscheinen. Folgende sechs Kategorien wurden dafür in diesem Praxisbeispiel herangezogen: 

  • Änderbarkeit: Wie schwer oder leicht ist es, die Software anzupassen (z.B. ein selbst konfigurierbares Dashboard so dass Änderungen ohne Programmieraufwände möglich sind, oder eine gut erweiterbare generische Codebasis)?
  • Benutzbarkeit: Wie sehr soll die Anwendung die Nutzer*in unterstützen, bestimmte Aufgaben erledigen zu können (z.B. das klassische Hinzufügen von Nutzer*innen: Die technisch einfach Lösung ist, dass ein Admin Nutzer*innen über INSERT-Anfragen einpflegt. Aufwändiger ist eine Weboberfläche, mit dessen Hilfe die Nutzer*innen selbst weitere Nutzer*innen hinzufügen können)?
  • Effizienz: Welche Antwortzeiten, Ressourcennutzung und welches Lastgerüst soll die Anwendung standhalten (z.B. Echtzeitergebnisse während eines WM-Spiels vs. Statistik über vergangene Spiele für eine Firma)? 
  • Sicherheit:  Welche Sicherheitsanforderungen gelten (z.B. Vertraulichkeit der Daten, Anonymität, Unversehrtheit und Nutzungsbeschränkung der Daten, gesetzliche Auflagen usw.)?
  • Zuverlässigkeit: Welcher Funktionen wie Ausgereiftheit, Verfügbarkeit, Fehlertoleranz und Wiederherstellbarkeit sollen unter welchen Bedingungen erfüllt sein (z.B. wenn das System nicht verfügbar ist, sind die Kernarbeitsprozesse nur gering eingeschränkt)? 

Werden diese fünf Dimensionen nun aus der Sicht “Wichtigkeit” (wie wichtig ist dies für den Kunden?) und “Herausforderung” (Wie leicht oder schwer gestaltet sich die Umsetzung?) betrachtet und bewertet, sind diese nicht nur hübsch visualisiert, sondern spannen ein Netz von bewerteten Qualitätszielen auf – die Qualitätsspinne ist geboren. 

Die Spinne ist jedoch kein störender Schädling, sondern hilft dabei nichtfunktionale Anforderungen zu erheben, die wiederum die technischen Herausforderungen eines Projektes bestimmen und dessen Zielarchitektur definieren. 

Wie sieht das Ganze in der Realität aus? 

Im Idealfall werden die Qualitätsziele in Absprache mit dem Kunden vor dem Projektstart besprochen, sodass das Fundament der Anwendung direkt auf die Ziele ausgelegt ist. Aber es geht auch anders, nämlich während eines (über mehrere Jahre) laufenden Projektes: 

Als Experiment hat sich ein Team die besagten Qualitätsziele vorgeknöpft, sie aus der Sicht des Kunden (Wichtigkeit) bewertet und daraus die Herausforderung für die Umsetzung abgeleitet. Und zwar nicht nur ein Mal, sondern für alle Projekte, die das Team betreut. Das Team hat sich dafür 2 Stunden zusammengesetzt, ein Teammitglied hat eine Wertigkeit für die Wichtigkeit zwischen 1 – “spielt überhaupt keine Rolle” bis 5 – “Höchste Priorität/KO-Kriterium/Showstopper” vorgeschlagen. Im Team wurde dann diskutiert, was das gemeinsame Verständnis von der Zahl im Bezug auf die Dimension ist und sich auf eine Zahl geeinigt. Das nächste Teammitglied hat sich eine Zahl für die entsprechende Herausforderung überlegt (von 1 – “trivial” bis 5 – “sehr anspruchsvoll”) und auch dies wurde diskutiert, bis eine gemeinsame Einigung stattgefunden hat. So ging es von Dimension zu Dimension und von Projekt zu Projekt. Neben einem gemeinsamen Verständnis der nichtfunktionalen Anforderungen wurden auch 4 Spinnennetze ins Leben gerufen, die die unterschiedliche Komplexität und unterschiedlichen Herausforderungen je Projekt visualisieren.

Im nächsten Schritt wurde der Kunde hinzugezogen. Auch mit ihm wurden die einzelnen Projekte durchgegangen. Jedoch beschränkte sich hier der Fokus auf die Wichtigkeit. Der Kunde bewertete die von uns vorgegebene Skala. Überraschend war, dass nicht nur Zahlen erhöht wurden (also die Wichtigkeit um ein, zwei Faktoren gesteigert wurde – auf dem Bild in Rot visualisiert), sondern auch einige Qualitätsziele vom Wert verringert wurden (Werte in orange).

Die Erarbeitung der Wichtigkeit mit dem Kunden hat im Team sogar für größere “AHHH”-Effekte gesorgt, da so nochmal der Fokus und die Priorität einzelner Funktionen verdeutlicht wurde, was dem Team in diesem Grad so nicht bewusst war. So wurde z.B. deutlich, dass die Offlinefähigkeit der einen Anwendung ein so enorm starkes Feature für die Endnutzer*innen ist, dass das gesamte Projekt eine höhere Priorität im Team angenommen hat, als es vor der Durchführung der Methode der Fall war. Dies spiegelte sich dann auch an Faktoren wie eine höhere Testabdeckung für diese Bereiche wieder. Es wurde durch die Reduktion mancher Werte seitens des Kunden im Team auch deutlich, was im Prioritätenkontext zu vernachlässigen ist, sodass sich der Fokus auch hier änderte.

Die neuen Netze zeigten nur noch deutlicher, was sich im mit der Einstufung vom Team bereits abgezeichnet hat: in fast allen Projekten (abgesehen von Projekt 1) ist die Wichtigkeit der größere Ring (Blau) und Herausforderung der kleinere Ring (orange). Das ist nicht nur gut für das Projekt, sondern auch für das Budget des Kunden, da sich der Aufwand zur Einhaltung des Qualitätsziels in Grenzen hält. 

Mit den Informationen der finalen Wichtigkeit vom Kunden wurde im Team noch einmal geprüft, ob diese Änderungen Auswirkungen auf die Herausforderungen haben. Das Ergebnis: vier finale Qualitätsspinnen.

Was hat man jetzt davon?

Der letzte und wichtigste Schritt ist der Schritt, der auch die Qualität von bereits laufenden Projekten enorm verbessern kann. In dem Praxisbeispiel wurde die Qualitätsspinne tatsächlich für das Ableiten von Maßnahmen genutzt. Gemeinsam überlegte das Team, wie z.B. die höchste Priorität von der Zuverlässigkeit bei Projekt 1 gewährleistet werden kann bzw. ob dies überhaupt bereits der Fall ist. Es wurde klar, dass z.B der Punkt Ausfallzeiten von Cloudbetreibern bzw. Drittanbietern nie geprüft wurde und dies entsprechend als Qualitässicherungsstrategie erfolgen sollte.

Diese Maßnahmen wurden wiederum zurück an den Kunden gespiegelt, der ebenso die Wichtigkeit der Maßnahmen erkannte und dafür Zeit und Budget bereitstellte, um die Maßnahmen zu ergreifen (wie z.B besagte Ausfallzeiten mit einer budgetierten TimeBox zu analysieren und auf das Analyseergebnis zu reagieren).

Das Werkzeug Qualitätsspinne mit den 5 Qualitätszielen hat dafür gesorgt, dass, zugeschnitten auf die nichtfunktionalen Anforderungen des Kunden, angemessen reagiert werden kann, um diese Ziele mit entsprechender Budgetbereitstellung zu gewährleisten. Spinnweben bringen also nicht nur Ärger, sondern helfen auch Insekten wie Fruchtfliegen und nichtfunktionale Anforderungen wie Zuverlässigkeit, Änderbarkeit, Effizienz und Sicherheit einzufangen.