QUALITY-DRIVEN SOFTWARE ARCHITECTURE

Softwarearchitektur: Pragmatisches Qualitätsmodell

Bei Entwurf und Implementierung von Systemen sollten wir auf ein vernünftiges, angemessenes Verständnis der von Stakeholdern gewünschten oder geforderten Qualität zurückgreifen können. Dafür müssen wir zwei Dimensionen klären: Welche Eigenschaften (Dimension-1) sind in jeweils welcher Ausprägung (Dimension-2) für unsere Systeme relevant? Klingt kompliziert, doch ist praktisch zum Glück recht einfach machbar.

Wir geben in diesem Artikel einen kompakten Überblick über Qualitätsmodelle. Dann finden Sie ein pragmatisches und praxistaugliches Modell, das den Weg für konkrete Qualitätsanforderungen mit Hilfe der so genannten Qualitätsszenarien bereitet.

Dr. Gernot Starke

Dr. Gernot Starke, INNOQ Fellow, ist seit vielen Jahren als Reisender in unterschiedlichen Ländern der IT-Welt tätig, hauptsächlich in Architektonien. Er besitzt das Schwimmabzeichen im Servizischen Ozean. Gernot ist des Weiteren Autor mehrerer Fachbücher und selbstständiger Berater und Coach.

Trauriger Stand der Praxis

Nach meiner Erfahrung aus mehr als 30 (dreißig!) Jahren praktischer Softwareentwicklung liegen Qualitätsanforderungen im Projektalltag aus unterschiedlichen Gründen nur selten vor. Stakeholder

wissen selbst (noch) nicht, welche Eigenschaften das System haben soll – weil es beispielsweise um eine Produktinnovation geht und niemand heute wissen kann, wie das System vom Zielpublikum aufgenommen oder verwendet werden wird,
möchten sich (noch) nicht festlegen, aus Angst, diese Entscheidung wäre irreversibel,
halten gewisse Eigenschaften für völlig selbstverständlich und sprechen diese Themen daher nicht an
übersehen, dass Entwicklungsteams manche Anforderungen kennen müssen

Als Entwicklungsteam können Sie jetzt entweder die Produktverantwortlichen (aka product owner) erziehen oder selbst Hand anlegen und die Qualitätsanforderungen aktiv erarbeiten. Das fällt Ihnen erheblich leichter, wenn Sie eine praxistaugliche Checkliste einsetzen können, und genau da kommt unsere „Dimension-1“ ins Spiel, eine Sammlung häufig geforderter Qualitätseigenschaften von Software (sprich: ein vernünftiges Qualitätsmodell).

Dimension-1: Welche Eigenschaften

Lange Zeit war es in der Branche sehr umstritten, welche Eigenschaften von Software (oder Systemen im Allgemeinen) für die Entwicklung relevant sein könnten. Als Ergebnis entstanden in der Vergangenheit unterschiedliche Qualitätsmodelle (Kasten: „Qualitätsmodelle: Der Blick in die Geschichte“) von denen der ISO-Standard 25010 (die letzte Folge dieser Kolumne hat das ausführlich vorgestellt) die wohl größte Verbreitung erreichen konnte. ISO-25010 ist jedoch einerseits ziemlich in die Jahre gekommen (der Standard wurde 2011 nach jahrelanger Gremienarbeit veröffentlicht) und wirkt andererseits mit über 40 Begriffen auf zwei Ebenen überladen. Essenzielle Merkmale (wie Time-to-market, Energieeffizienz oder Deploybarkeit) fehlen, und die Begriffsdefinitionen sind teilweise sehr sperrig.

Da möchte ich konstruktiv nachlegen und das arc42-Qualitätsmodell vorstellen, das methodisch neue Wege geht (Abb. 1, englische Version in Abb. 2). Der erste Unterschied zu bekannten Modellen ist die Wahl von Adjektiven (statt Substantiven wie alle übrigen Q-Modelle) auf der obersten Ebene. Mir war seit Jahren unklar, warum die Verantwortlichen von ISO und anderen Qualitätsmodellen zwar über „Qualitätseigenschaften“ schreiben, dafür aber stets Substantive verwenden.

Ein zweiter grundlegender Unterschied besteht im Verzicht einer festen Hierarchie: In bestehenden Modellen (z. B. ISO-25010) besteht häufig die Schwierigkeit, zu welchem der Top-Level-Merkmale eine bestimmte Qualitätsanforderung gehört. Nehmen Sie beispielsweise die Anforderung „Suche nach Sonderangeboten muss während der Kernzeit 9-17 Uhr ständig verfügbar sein“. Gehört diese zu Verfügbarkeit oder Benutzbarkeit? Meiner Ansicht nach zu beidem – das ist im starren ISO-Modell aber nicht vorgesehen.

Das arc42-Modell Q42 (gesprochen „Kju-Fortytwo“ oder „Kju-Four-Two“) geht hier einen anderen Weg: Statt sich auf eine feste Hierarchie von Begriffen zu fixieren, setzt arc42 auf (zurzeit) acht „Tags“ (Etiketten). Das ermöglicht es, eine konkrete Qualitätsanforderung mit mehreren dieser Tags auszuzeichnen.

Einstieg: Das bedeuten diese „Tags“

Die Tags des arc42-Qualitätsmodells sollten nahezu selbsterklärend sein, dennoch versuche ich in Kurzform mal eine Klärung durch Beispiele:

#zuverlässig: verfügbar, robust, ausfallsicher, fehlerfrei, wiederherstellbar, konsistent
#flexibel: Zur Entwicklungs- und Laufzeit leicht änderbar, anpassbar, skalierbar, wiederverwendbar, modular
#effizient: schnell, energie-, speicher- und überhaupt ressourceneffizient, mit angemessener Kapazität
#benutzbar: leicht erlernbar, hilfreich, selbsterklärend, attraktiv, fehlervermeidend
#gefahrlos: Erfüllt Safety-Anforderungen (Kasten: „Das Übersetzungsproblem mit Safety und Security“), erkennt und warnt vor Risiken und Gefahren
#sicher: Erfüllt Anforderungen an Datenschutz und -sicherheit, vertraulich, authentisch, integer, verantwortlich
#testbar: prüfbar, analysierbar, automatisiert und manuell angemessen einfach zu testen
#betreibbar: installierbar, überwachbar, administrierbar

Funktioniert das in der Praxis?

Das arc42-Qualitätsmodell habe ich einer umfangreichen Validierung unterzogen: Möglichst viele mögliche Qualitätseigenschaften müssen sich mit den Tags des arc42-Qualitätsmodells zuordnen lassen. Dazu habe ich circa 100 Namen und Definitionen von Qualitätseigenschaften gesammelt (Basis dafür war [7]) – danke dem Wortreichtum der deutschen Sprache. Die Zuordnung funktioniert nahezu perfekt – die Details finde Sie online bei [8]. Tabelle 1 zeigt einen kurzen Auszug davon. Sie können [8] als Checkliste für eigene Qualitätsanforderungen verwenden.

Das Übersetzungsproblem mit Safety und Security

Die englische Sprache differenziert zwischen den Begriffen Safety und Security – die leider im Deutschen beide mit „Sicherheit“ übersetzt werden:

Safety: Vermeidung von Schäden, Verletzungen oder Gefahren für Menschen und Systeme
Security: Vertraulichkeit, Integrität und Konsistenz von Daten oder Prozessen

Die einfache Übersetzung „Sicherheit“ verliert damit einen Teil der möglichen Bedeutung. Eine treffendere Übersetzung wäre „Gefahrlosigkeit“ (oder „Harmlosigkeit“). Erstere Version habe ich auch im arc42-Qualitätsmodell gewählt.

Qualitätseigenschaft	Erklärung	Q42-Tags
Administrierbarkeit	Notwendiger Aufwand zur Administration (Verwaltung, Überwachung) einer Software im laufenden Betrieb	#betreibbar
Änderbarkeit	Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist. Änderungen sind Korrekturen, Anpassungen der Umgebung und Infrastruktur, der Anforderungen, der internen Struktur, der Implementierung o. ä.	#flexibel, #effizient
Autonomie	Fähigkeit eines Systems, sein Leistungsniveau unabhängig von anderen Systemen zu erbringen	#betreibbar, #zuverlässig
Durchsatz	Menge an Daten oder Ereignissen, die das System in gegebener Zeit verarbeiten kann	#effizient, #benutzbar
Latenz	Synonym: Verzögerungszeit; Zeit vom Ende eines Ereignisses bis zum Beginn der Reaktion auf dieses Ereignis	#effizient, #benutzbar
Modularität	Zerlegung eines Systems in Einzelteile mit definierten Schnittstellen und Aufgaben	#flexibel, #effizient
Portabilität	Plattformunabhängigkeit, auch: Übertragbarkeit	#flexibel
Wiederherstellbarkeit	Fähigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenen Daten wiederzugewinnen	#zuverlässig

Tabelle 1: Qualitätseigenschaften und ihre Zuordnung zu arc42-Tags

Qualitätsmodelle: Der Blick in die Geschichte

Seit circa 1977 streiten sich die (wissenschaftlichen) Geister um eine Begriffsordnung rund um das Thema Softwarequalität [2]. McCall schlug 1977 eine Hierarchie vor, deren erste Ebene die drei Elemente Operation, Revision und Transition umfasst. Zu Revision zählte er z. B. Maintainbility, Flexibility und Testability.

Danach gab’s eine Reihe alternative Vorschläge, von denen aus meiner Sicht der Ansatz FURPS [4] und dessen Erweiterung FURPS+ von IBM [5] in der Praxis ordentlich Anklang fand. Die ISO-Organisation hat sich dann des Themas angenommen, und veröffentlicht seit 1991 hersteller- und produktneutrale Standards, beginnend mit ISO-9126. Dieser hat 20 Jahre lang „gehalten“ und wurde 2011 durch den noch heute gültigen ISO-25010 abgelöst. Beide galten jeweils als begriffliche Referenz für Softwarequalität und haben erhebliche Verbreitung in der Praxis gefunden. Meiner bescheidenen Meinung nach liegt das in erheblichem Maße daran, dass die ISO-Gremien die verwendeten Begriffe allesamt recht ordentlich definieren. Deswegen sei ihnen auch verziehen, dass sie einige wirklich relevante Qualitätsmerkmale schlichtweg ignoriert (oder vergessen?) haben.

Gut gefallen haben mir auch Qualitätseigenschaften des VOLERE Requirements Template [6], die jedoch im deutschsprachigen Raum weniger Akzeptanz gefunden haben als die ISO-Standards.

Mein Fazit: Die Erklärung von 30-40 Untereigenschaften der ISO- oder FURPS+-Modelle braucht mehr Zeit, als die meisten Entwicklungsteams dafür aufbringen möchten. Einfachere Modelle sind gefragt, am liebsten Open Source (das bietet arc42 ja schon lange).

Autor:innen,	Jahr	Art	Anzahl der Eigenschaften	Eigenschaften
McCall	1977	Hierarchisches Modell, zwei Ebenen Einstiegspunkte Operation, Revision, Transition	11	Kaum Unterschied zwischen Revision und Transition
Barry Boehm	1978	Hierarchisches Modell, drei Ebenen Einstiegspunkte Utility, Maintainability, Portability	23
ISO 9126	1991	Zweistufiges Modell, sechs Top-Level-Eigenschaften	27	Security nur nachgelagert
R. Grady, „FURPS“	1992	Einstufiges Modell, Functionality, Usability, Reliability, Performance, Supportability	5
IBM FURPS+	1999	Erweitert das FURPS-Modell um zahlreiche Untermerkmale	ca. 30	Teil des (zu) umfangreichen Rational-Unified Process
VOLERE	1999	In umfassendes Requirements Template integriert	8	Kombiniert Q-Anforderungen mit Constraints
ISO 25010	2011	Hierarchie mit zwei Ebenen, acht Top-Level-Merkmale	32	Teils unpraktikable Begriffsdefinitionen, nicht mehr zeitgemäß
SEI	2022	Eine Ebene, siehe [1]	10	Manche Details zu hoch priorisiert
ISO 25010-2022 (Draft-Version)	2022	Erweitert auf neun Top-Level-Merkmale	9	39 Sub-Merkmale, teils überschneidend

Tabelle 2: Qualitätsmodelle im Quick-Check

Fazit

Sie haben ein pragmatisches Qualitätsmodell gesehen, das mit nur neun Qualitätseigenschaften („Tags“) auskommt. Das ist für Architektur und Entwicklung relevant großer IT-Systeme meiner Meinung die minimale Menge. Statt auf große und schwer verständliche Hierarchien von Begriffen zu setzen (wie ISO-25010), geht das arc42-Qualitätsmodell den Weg über „Tags“, die als echte Eigenschaften formuliert sind. Damit haben wir (endlich!) ein praktisches Modell für die Frage nach Dimension-1 („Welche Eigenschaften?“).

Links & Literatur

[1] Bass et. Al: „Software Architecture in Practice“, Fourth Edition, Addison-Wesley 2022 (hier ist wirklich die vierte Auflage wichtig, weil darin das Thema Qualität signifikant gegenüber vorigen Auflagen erweitert wurde).

[2] Jamwal et al.: „Comparative Analysis of Different Software Quality Models. Proceedings of the 3rd National Conference“; INDIACom-2009; https://enos.itcollege.ee/~nafurs/suvi2019/huvitavat/alternatiivid_FURPSile.pdf

[3] Grady, L. R. B.: „Practical Software Metrics for Project Management and Process Improvement“, enthält das FURPS-Modell Prentice Hall, 1992

[4] ISO-25010: https://www.iso.org/standard/35733.html

[5] Eeles, Peter: „Non-functional Requirements“: https://pdfs.semanticscholar.org/f3bb/91080c4573f6f78f30bc5b48bda3ef252bf2.pdf

[6] VOLERE Requirements Template: https://www.volere.org/

[7] arc42 Quality Requirements: Beispiele konkreter Qualitätsanforderungen. Wird mittelfristig durch [8] ersetzt: https://github.com/arc42/quality-requirements.

[8] arc42 Quality Model: https://quality.arc42.org (Draft) Definitionen wesentlicher Qualitätseigenschaften, Mapping zu den arc42-Quality-Tags