| Typ | Konzept |
|---|---|
| Quellen | Quelle - Effektive Softwarearchitekturen Quelle - Recherche - Softwarearchitektur heute 2026 |
| Erstellt | 2026-09-27 |
| Aktualisiert | 2026-09-27 |
| Tags | softwarearchitektur, qualität, iso-9126, iso-25010, szenario, qualitätsbaum |
Qualität von Software bezieht sich immer auf einzelne Merkmale wie Effizienz, Zuverlässigkeit oder Änderbarkeit. Normen wie ISO 9126 und ISO 25010 ordnen sie hierarchisch. Prüfbar werden sie erst durch konkrete Qualitätsszenarien, die in einem Qualitätsbaum priorisiert werden.
Qualitätsmerkmale nach DIN/ISO 9126
Die Tabelle stammt aus dem Buch (Quelle - Effektive Softwarearchitekturen, S. 41–42). „Performance“ heisst im Normdeutsch Effizienz.
| Merkmal | Untermerkmale |
|---|---|
| Funktionalität | Angemessenheit, Richtigkeit, Interoperabilität, Ordnungsmässigkeit, Sicherheit |
| Zuverlässigkeit | Reife, Fehlertoleranz, Wiederherstellbarkeit |
| Benutzbarkeit | Verständlichkeit, Erlernbarkeit, Bedienbarkeit |
| Effizienz | Zeitverhalten, Verbrauchsverhalten |
| Änderbarkeit | Analysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit |
| Übertragbarkeit | Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit |
Egal welches Modell: Innerhalb eines Projekts sollte die Terminologie einheitlich sein (S. 41). „Benutzbarkeit“ ist das, was die UX-Seite Usability nennt.
ISO 9126 wurde am 1. März 2011 durch ISO/IEC 25010 (Teil der ISO-25000-Reihe „SQuaRE“) ersetzt. Das Buch nennt 25010 nur im iSAQB-Kapitel (S. 419). Schon 2011 kamen Sicherheit und Kompatibilität als Hauptmerkmale hinzu (Quelle - Recherche - Softwarearchitektur heute 2026). Die UX-Quelle erwähnt die ISO-25000-Reihe ebenfalls (Usability).
ISO/IEC 25010:2023
Die aktuelle Ausgabe vom November 2023 hat neun Merkmale (Quelle - Recherche - Softwarearchitektur heute 2026, nach Wikipedia und Fachblogs):
| Merkmal 2023 | Entspricht in ISO 9126 |
|---|---|
| Funktionale Eignung | Funktionalität |
| Leistungseffizienz | Effizienz |
| Kompatibilität | neu seit 2011 (Teil von Interoperabilität) |
| Interaktionsfähigkeit | Benutzbarkeit |
| Zuverlässigkeit (mit „Fehlerfreiheit“ statt „Reife“) | Zuverlässigkeit |
| Sicherheit (Security) | Teil von Funktionalität, seit 2011 eigenständig |
| Wartbarkeit | Änderbarkeit |
| Flexibilität (u. a. mit Skalierbarkeit) | Übertragbarkeit |
| Safety (Betriebssicherheit) | neu 2023 |
Neu sind ausserdem Untermerkmale wie Inklusivität und Selbstbeschreibungsfähigkeit bei der Interaktionsfähigkeit sowie Widerstandsfähigkeit bei der Sicherheit.
Dass Benutzbarkeit jetzt „Interaktionsfähigkeit“ heisst und Inklusivität enthält, rückt die Norm näher an Barrierefreiheit und User Experience. Die Tabellenzuordnung zu ISO 9126 ist eine Vereinfachung von Claude.
Qualitätsszenarien
Merkmale allein sind zu abstrakt. Szenarien nach Bass, Clements und Kazman beschreiben, was geschieht, wenn ein Stimulus in einer bestimmten Situation auf das System trifft (S. 43). Bestandteile: Quelle des Stimulus, Stimulus, Umgebung, betroffenes Artefakt, Antwort und Antwortmass.
- Anwendungsszenario: „Die Antwort auf eine Angebotsanfrage muss im Regelbetrieb in weniger als fünf Sekunden erscheinen, unter Hochlast in höchstens 15 Sekunden mit Hinweis.“
- Änderungsszenario: „Neue Versicherungstarife lassen sich in weniger als 30 Personentagen programmieren.“
- Stress- oder Grenzszenario: Verhalten bei Ausfall oder Überlast, z. B. „Bei Ausfall einer CPU ist das Ersatzsystem in 15 Minuten online.“
Qualitätsbaum
Die Merkmale werden als Baum (oder Mindmap) verfeinert, die Blätter sind Szenarien. Die Stakeholder priorisieren sie nach geschäftlichem Nutzen (A, B, C). Beispiel Foto-App: „Beim Upload einer unbekannten Dateiart meldet das System dies ohne Absturz“ (Zuverlässigkeit/Robustheit, Priorität A) (S. 92–93). Schon für mittlere Systeme findet man 30–50 Szenarien. Das freie arc42-Projekt „quality-requirements“ sammelt über 50 Beispiele (S. 312).
Qualitätsgetriebener Entwurf
Bei der Quality-Driven Software Architecture stehen die Qualitätsziele am Anfang. Die Phasen heissen Aim (Ziele konkretisieren), Plan (Massnahmen sammeln), Build und Check (S. 91–94). Für jedes Szenario sammelt das Team mögliche Taktiken, also Massnahmen, die ein Merkmal verbessern. Eine Tabelle oder ein Flipchart genügt. Viele Entwurfsmuster sind solche Taktiken, etwa für Flexibilität, Robustheit, Performance oder Sicherheit (S. 94). Das Buch nennt Strategien für Performance, Anpassbarkeit, Flexibilität und Verfügbarkeit. Bei der Performance heisst das zuerst: Profiler einsetzen und Lasttests fahren (S. 95).
„There is no free lunch“: Eine Massnahme für ein Merkmal schadet oft einem anderen. Mehr Performance kann mehr Speicher, weniger Robustheit oder weniger Einfachheit bedeuten. Deshalb vor der Umsetzung eine Konsequenzanalyse machen und die Folgen mitdokumentieren (S. 94). Auch Konfigurierbarkeit hat ihren Preis: Sie macht Systeme schwerer testbar (S. 64).
Beispiel aus dem Buch: Ein Auftraggeber verlangte eine Sekunde Antwortzeit für alle Operationen, verbot aber jeden Zwischenspeicher neben dem Mainframe. Ein Prototyp zeigte, dass schon die Mainframe-Zugriffe länger dauerten. Die Anforderung wurde neu formuliert: höchstens eine Sekunde plus die Antwortzeit der Mainframes (S. 95). Wie Merkmale sich gegenseitig beeinflussen, zeigt die Architekturbewertung.
Verwandt
- Softwarearchitektur – Qualität als Hauptziel der Architektur
- Architekturbewertung – ATAM prüft die Architektur gegen die Szenarien
- Usability – Benutzbarkeit aus Sicht der UX, ISO 9241
- Softwaretest – Qualität des Codes prüfen
- Skalierung – Effizienz unter wachsender Last
- Informationssicherheit – Sicherheit als Qualitätsmerkmal