Qualitätsmodelle: ISO/IEC 25010 und wie man es nutzt

Wozu ein Qualitätsmodell dient

Abschnitt 2.1 hat dargelegt, dass Qualitätsmerkmale den größten Teil einer Architektur bestimmen. Die naheliegende nächste Frage lautet: welche Qualitäten? Sich selbst überlassen, nennen Stakeholder die zwei oder drei, die ihnen zuletzt wehgetan haben, meist Geschwindigkeit und Verfügbarkeit, und vergessen den Rest, bis es zu spät ist. Ein Qualitätsmodell ist eine strukturierte Liste von Qualitätsmerkmalen, jeweils in engere Teilmerkmale gegliedert, mit vereinbarten Namen und Definitionen. Es erfüllt zwei Aufgaben. Es gibt allen ein gemeinsames Vokabular, sodass „Zuverlässigkeit“ für den Product Owner, das Testteam und den Lieferanten dasselbe bedeutet. Und es dient als Checkliste, die Sie auf Qualitäten aufmerksam macht, die noch niemand angesprochen hat.

Ein Modell sagt Ihnen nicht, welche Qualitäten für Ihr System wichtig sind oder wie viel Sie von jeder brauchen. Das ergibt sich aus Stakeholdern und Geschäftszielen (Abschnitt 2.8). Es sagt Ihnen auch nicht, wie Sie sie erreichen; das ist die Aufgabe von Taktiken, Mustern und dem Rest dieses Kurses. Es ist eine Karte des Geländes, kein Weg hindurch.

ISO/IEC 25010:2023: das Produktqualitätsmodell

Das am häufigsten zitierte Modell ist ISO/IEC 25010, Teil der Normenfamilie SQuaRE (Systems and software Quality Requirements and Evaluation). Die zweite Ausgabe, veröffentlicht im November 2023, definiert ein Produktqualitätsmodell mit neun Merkmalen. Es gilt für Softwareprodukte und für ICT-Produkte im weiteren Sinn, und die Norm nennt seine Einsatzzwecke: Anforderungen spezifizieren, Anforderungen auf Vollständigkeit prüfen, Design- und Testziele festlegen, Abnahmekriterien definieren und Qualitätsmaße festlegen. Verwandte Normen der Familie legen fest, wie jedes Teilmerkmal gemessen (ISO/IEC 25023) und wie ein Produkt bewertet wird.

Die neun Merkmale sind funktionale Eignung, Leistungseffizienz, Kompatibilität, Interaktionsfähigkeit, Zuverlässigkeit, Sicherheit, Wartbarkeit, Flexibilität und Betriebssicherheit. Das erste beschreibt, ob das System die richtigen Dinge korrekt tut; die anderen acht beschreiben, wie gut es sie tut und wie gut es sich betreiben, schützen und ändern lässt. Das Diagramm unten zeigt die Struktur; die Tabelle danach listet jedes Teilmerkmal mit einer Beispielfrage auf, die ein Architekt stellen könnte.

Einige Definitionen sollte man genau kennen, weil sie vom Alltagsgebrauch abweichen. In ISO/IEC 25010 ist Verfügbarkeit ein Teilmerkmal der Zuverlässigkeit: der Grad, in dem ein System bei Bedarf betriebsbereit und zugänglich ist. Fehlerfreiheit ist der Grad, in dem ein System seine Funktionen im Normalbetrieb ohne Fehler erfüllt. Kapazität unter Leistungseffizienz ist die Höchstgrenze eines Parameters, etwa gleichzeitiger Nutzer oder Transaktionen pro Sekunde, bei der die Anforderungen noch erfüllt werden. Skalierbarkeit steht unter Flexibilität; darin zeigt sich eine Sicht auf Skalierung als Fähigkeit, sich an wechselnde Last anzupassen, statt als Frage roher Geschwindigkeit. Widerstandsfähigkeit, neu unter Sicherheit, ist die Fähigkeit, den Betrieb unter einem Angriff aufrechtzuerhalten. Die Abschnitte 2.4 bis 2.7 greifen diese Qualitäten vertieft auf; Abschnitt 2.5 zeigt, wie man Verfügbarkeit berechnet.

Was sich gegenüber der Ausgabe von 2011 geändert hat

Die erste Ausgabe, ISO/IEC 25010:2011, löste das ältere Modell ISO/IEC 9126 ab und war ein Jahrzehnt lang die Standardreferenz. Viele Lehrbücher, Ausschreibungsunterlagen und Vorlagen verwenden noch ihre acht Merkmale, daher lohnt es sich zu wissen, was sich verschoben hat.

Die Umbenennungen sind mehr als Kosmetik. „Interaktionsfähigkeit“ weitet den Blick von der einfachen Bedienung auf den gesamten Informationsaustausch zwischen Nutzern und Produkt in verschiedenen Nutzungskontexten, und das neue Teilmerkmal Inklusivität rückt Barrierefreiheit für Menschen unterschiedlichen Alters und unterschiedlicher Fähigkeiten vom Rand ins Zentrum. „Flexibilität“ bündelt die Qualitäten, mit denen ein Produkt Veränderungen in seiner Umgebung bewältigt: neue Plattformen, neue Installationsziele und mehr oder weniger Last. Dass Betriebssicherheit als Produktmerkmal hinzukam, spiegelt wider, wie viel Software heute physische Dinge steuert, von Autos bis zu Medizinprodukten.

Die zweite strukturelle Änderung: Die Nutzungsqualität, also die Qualität, die Menschen bei der Nutzung des Produkts in einem realen Kontext erleben, hat nun eine eigene Norm, ISO/IEC 25019:2023. Ihre drei Merkmale sind Nutzen (Benutzbarkeit, Barrierefreiheit und Eignung in der Nutzung), Risikofreiheit (wirtschaftliche Risiken, Risiken für Gesundheit und Menschenleben sowie Umwelt- und gesellschaftliche Risiken) und Akzeptanz (Erfahrung, Vertrauenswürdigkeit und Konformität). Die Trennung verdeutlicht eine für Architekten nützliche Unterscheidung: Produktqualität ist das, was Sie bauen und am Produkt testen können; Nutzungsqualität ist das Ergebnis für echte Menschen, das auch von Schulung, Kontext und der Art abhängt, wie das Produkt eingesetzt wird.

Andere Listen, denen Sie begegnen werden

ISO/IEC 25010 ist nicht die einzige Taxonomie, und in der Praxis werden oft einfachere oder anders geschnittene Listen verwendet. FURPS+ ging aus FURPS hervor, einer bei Hewlett-Packard entwickelten Klassifikation, die Robert Grady und Deborah Caswell in Software Metrics: Establishing a Company-Wide Program (1987) darlegten. FURPS gruppiert Anforderungen in Funktionalität (Functionality), Benutzbarkeit (Usability), Zuverlässigkeit (Reliability), Performance und Supportfähigkeit (Supportability); die spätere Erweiterung „+“ ergänzt Randbedingungen: Design-, Implementierungs-, Schnittstellen- und physische Randbedingungen sowie in manchen Fassungen Geschäftsregeln. Bekannt wurde FURPS+ durch den Rational Unified Process und seine Nachfolger. Seine Stärke ist die Kürze; seine Schwäche, dass „Supportfähigkeit“ Wartbarkeit, Testbarkeit, Konfigurierbarkeit, Installierbarkeit und Lokalisierung in einen Topf wirft.

Bass, Clements und Kazman erheben in der vierten Auflage von Software Architecture in Practice (2021) keinen Anspruch auf Vollständigkeit. Sie widmen je ein Kapitel den Qualitäten, die Architekturen am häufigsten treiben: Verfügbarkeit, Deploybarkeit, Energieeffizienz, Integrierbarkeit, Änderbarkeit, Performance, Betriebssicherheit, Sicherheit, Testbarkeit und Benutzbarkeit, gefolgt von einem Kapitel über den Umgang mit weiteren Qualitäten. Zu jeder geben sie ein allgemeines Szenario und einen Katalog von Taktiken an. Ihre Liste ist am Design statt an der Bewertung ausgerichtet, was sie für Architekten besonders nützlich macht.

Mark Richards und Neal Ford verwenden in Fundamentals of Software Architecture den Begriff Architekturmerkmale und ordnen sie in Gruppen wie betriebliche (Verfügbarkeit, Performance, Skalierbarkeit), strukturelle (Änderbarkeit, Erweiterbarkeit, Übertragbarkeit) und übergreifende (Sicherheit, Barrierefreiheit, Recht). Das offene Q42-Modell von Gernot Starke, gepflegt neben der arc42-Vorlage, wählt wieder einen anderen Ansatz: Es versieht weit über hundert benannte Qualitäten mit neun Dimensionen (effizient, flexibel, wartbar, betreibbar, zuverlässig, betriebssicher, sicher, geeignet, benutzbar) und bietet für jede Beispielanforderungen.

Diese Listen unterscheiden sich im Detail, überschneiden sich aber stark. Die Uneinigkeit ist selbst lehrreich: Es gibt keine einzig richtige Zerlegung von „Qualität“, nur für einen Zweck mehr oder weniger nützliche. Ein Standardmodell hilft, wenn Sie mit dem Einkauf, mit Prüfern oder anderen Organisationen kommunizieren müssen; einem Produktteam dient im Alltag vielleicht eine schlankere Liste besser.

Ein Modell als Checkliste nutzen, ohne Bürokratie zu schaffen

Die große Gefahr eines Qualitätsmodells ist, dass es zum Formular wird. Eine Anforderungsvorlage mit einer Überschrift für jedes der 40 Teilmerkmale verleitet dazu, jedes Feld zu füllen, und heraus kommt ein Dokument voller Aussagen wie „Das System soll wartbar sein“, das niemand liest und niemand testet. Der Aufwand verteilt sich gleichmäßig auf Qualitäten, die sehr ungleich wichtig sind, und die zwei oder drei Qualitäten, die die Architektur wirklich entscheiden, gehen im Rest unter.

Besser ist es, das Modell als Anstoß für ein Gespräch zu behandeln. Gehen Sie die Merkmale einmal zügig mit den Stakeholdern durch und fragen Sie bei jedem: Ist das für unser System wichtig, und wenn ja, wie sähe ein Versagen aus? Verwerfen Sie die irrelevanten ausdrücklich (zu schreiben „Betriebssicherheit: nicht zutreffend, die App kann keinen physischen Schaden verursachen“ ist nützlich, weil es eine Entscheidung festhält). Machen Sie aus den relevanten eine kleine Zahl konkreter, messbarer Szenarien (Abschnitt 2.3). Gewichten Sie sie (Abschnitt 2.8). Dann legen Sie das Modell bis zum nächsten Review beiseite.