Meine IT-Firefighter Werkzeugkiste – Softwarequalität nach ISO 25010

vor 4 Jahren

Natürlich kostet Qualität, aber fehlende Qualität kostet mehr.
Hans-Jürgen Quadbeck-Seeger

Eine wichtige Grundlage für Softwarequalität in der agilen Softwareentwicklung sind Transparenz und Nachvollziehbarkeit. Es gibt unterschiedliche Varianten wie diese Werte realisiert oder leider auch vorgetäuscht werden können.

Die Auswirkungen auf die Zusammenarbeit ist in diesem Zusammenhang nicht zu unterschätzen. Die Einstellung entscheidet, ob Transparenz und Nachvollziehbarkeit als Grundlage der kontinuierlichen Verbesserung oder als Kontrolle angesehen werden. Bei letzterem ist es bei einem Review zum Beispiel sehr schwierig, an Informationen zu gelangen. Kommunikation findet dann zu einem Grossteil über methodische Floskeln und Verallgemeinerungen statt.

In meinem früheren Blog schrieb ich bereits zu diesem Thema. Ich selbst habe den Beitrag in einer alten MySql-Datenbank, einsehbar ist dieser über archive.org.

Merkmale der Softwarequalität: von DIN ISO 9126 zu ISO 25010

Seit der Veröffentlichung sind 10 Jahre vergangen. Es ist ersichtlich, dass ich vor 10 Jahren von der DIN ISO 9126 als Grundlage sprach. Zwischenzeitlich ist diese Norm in die ISO 25010 übergegangen. Der Hauptunterschied liegt in einer eigenen Kategorie Sicherheit.

Hier ein älteres Mindmap zur Verdeutlichung:

Softwarequalitätsmerkmale (DIN ISO 9126) von Rene Leupold

Transparenz und Nachvollziehbarkeit der Softwarequalität mit Arc42

In diesem Zusammenhang fallen häufig die Begriffe «nichtfunktionale Anforderungen» bzw. «Qualitätskriterien». Die Arc42-Schablone behandelt die Aspekte in Kapitel 10 Qualitätsszenarien und kann so als Hilfsmittel zu mehr Transparenz und Nachvollziehbarkeit beitragen.

Eine einfache Gewichtung der einzelnen Kriterien kann Aufschluss über die Dimensionierung geben. Dies kann in einem Backlog auf Stufe Epic, Feature oder User Story erfolgen. Die Wirtschaftlichkeit des Gesamtsystems lässt sich so besser überblicken. So ist es beispielsweise denkbar, dass ein Hintergrundprozess im Effizienzverhalten mehr Zeit in Anspruch nehmen darf, als die Reaktionszeiten einer Benutzerobfläche. Würden wir in diesem Fall das Effizienzverhalten der Benutzeroberfläche auf das komplette Softwaresystem anwenden, so hätte das einen erheblichen Einfluss auf die Dimensionierung des Systems und auf das dafür benötigte Budget.

Skala für die Priorisierung

Mit einer Skala lässt sich die Wichtigkeit visualisieren, die Aufschluss über die Dimensionierung und mögliche Risiken geben kann. In einem Projekt oder Produkt kann das Team pro Skala-Stufe definieren, was es bedeutet, diese zu erfüllen. Ein Ansatz kann die Erfüllung dieser Kriterien als Definition of Done für die jeweilige Aufgabe sein. Andere Formen und Ansätze sind natürlich auch möglich.