Was strukturiert das Qualitätsmodell nach ISO/IEC 25010?
Ein Rahmenwerk für objektive Softwarequalität
Stell dir vor, du entwickelst eine neue App. Für dich als Fachinformatiker:in ist die Qualität hoch, wenn die Softwarearchitektur sauber und der Code gut strukturiert ist. Für die Anwendenden zählt jedoch nur, ob die App flüssig läuft und ihr Problem löst. Um diese unterschiedlichen, oft subjektiven Sichtweisen zu vereinen, gibt es den internationalen Standard ISO/IEC 25010:2023.
Dieses Qualitätsmodell dient als gemeinsame, objektive Sprache zwischen Auftraggebenden, dem Entwicklungsteam und der Qualitätssicherung. Es strukturiert Softwarequalität ganzheitlich in zwei Hauptperspektiven:
- Produktqualität (Product Quality): Bewertet die technischen und statischen Eigenschaften der Software selbst (z. B. "Ist der Code modular aufgebaut?").
- Nutzungsqualität (Quality in Use): Bewertet die tatsächliche Wirkung der Software im realen Einsatz durch den Menschen (z. B. "Können Nutzende ihre Aufgabe effizient erledigen?").
Produktqualität Teil 1: Funktion, Leistung und Interaktion
Um technische Anforderungen vollständig zu erfassen, unterteilt die aktuelle Norm die Produktqualität in neun Hauptmerkmale. Die ersten fünf fokussieren sich auf den direkten Betrieb:
- Funktionale Eignung (Functional Suitability): Tut die Software genau das, was sie soll? Sie muss korrekte Ergebnisse liefern und alle geforderten Aufgaben abdecken (z. B. die exakte Zinsberechnung in einer Banking-App).
- Leistungseffizienz (Performance Efficiency): Wie sparsam geht das System mit Ressourcen um? Hierzu zählen schnelle Antwortzeiten, ein hoher Datendurchsatz und ein geringer Speicherbedarf (RAM/CPU).
- Kompatibilität (Compatibility): Wie gut verträgt sich die Software mit anderen Systemen? Dies umfasst die Koexistenz auf derselben Hardware sowie den reibungslosen Datenaustausch über Schnittstellen (APIs).
- Interaktionsfähigkeit (Interaction Capability): Wie gut kann ein Mensch das System bedienen? Ist die Benutzeroberfläche verständlich, leicht erlernbar und barrierefrei zugänglich?
- Zuverlässigkeit (Reliability): Läuft das System stabil? Es geht um die garantierte Verfügbarkeit (Uptime) und die Fehlertoleranz bei unerwarteten Abstürzen.
Produktqualität Teil 2: Schutz, Wartung und Anpassung
Die restlichen vier Merkmale der Produktqualität bewerten die Sicherheit, die Zukunftsfähigkeit und physische Risiken der Software:
- Informationssicherheit (Security): Sind die Daten vor Angriffen geschützt? Hier wendest du Schutzziele wie Vertraulichkeit und Integrität an, um unbefugten Zugriff konsequent zu verhindern.
- Wartbarkeit (Maintainability): Wie leicht lässt sich die Software anpassen? Ein modularer, gut analysierbarer und testbarer Code ist entscheidend, um Updates effizient und fehlerfrei einzuspielen.
- Flexibilität (Flexibility): Wie gut passt sich die Software an neue Umgebungen an? Dies betrifft die einfache Installation, die Übertragbarkeit auf andere Betriebssysteme (Portabilität) und die Skalierbarkeit bei wachsenden Nutzerzahlen.
- Sicherheit (Safety): Geht von der Software eine physische Gefahr aus? Dieses Merkmal ist essenziell für kritische Systeme (z. B. Airbag-Steuerungen oder medizinische Geräte), bei denen Softwarefehler Menschenleben gefährden oder massive Sachschäden verursachen könnten.
Wie wendet man das ISO-Modell in der Praxis an?
Konkrete Anforderungen richtig zuordnen
In Pflichtenheften oder User Stories findest du oft Anforderungen, die auf den ersten Blick unstrukturiert wirken. Mit der ISO 25010 kannst du diese präzise den passenden Merkmalen zuordnen, um sie testbar und messbar zu machen:
- Anforderung: "Das System muss auf eine Datenbankabfrage innerhalb von maximal 0,5 Sekunden reagieren."
- Zuordnung: Leistungseffizienz (Zeitverhalten).
- Anforderung: "Die Software muss auch von Menschen mit Sehbehinderung problemlos per Screenreader bedient werden können."
- Zuordnung: Interaktionsfähigkeit (Barrierefreiheit).
- Anforderung: "Neue Bezahlmethoden müssen hinzugefügt werden können, ohne den Kerncode des Shopsystems zu verändern."
- Zuordnung: Wartbarkeit (Modularität).
- Anforderung: "Bei einem Ausfall der Steuereinheit muss der Roboterarm in der Fabrik sofort stoppen."
- Zuordnung: Sicherheit / Safety (Vermeidung physischer Schäden).
Zielkonflikte (Trade-offs) erkennen und managen
In der Praxis ist es nahezu unmöglich, alle neun Qualitätsmerkmale gleichzeitig zu maximieren. Es entstehen unweigerlich Zielkonflikte (Trade-offs), bei denen die Verbesserung eines Merkmals ein anderes verschlechtert. Als Fachinformatiker:in musst du diese Konflikte analysieren und bewusste Kompromisse finden:
- Informationssicherheit vs. Leistungseffizienz: Stell dir vor, du implementierst eine extrem starke, mehrstufige Verschlüsselung für eine Datenbank (Informationssicherheit). Der Trade-off: Das ständige Ver- und Entschlüsseln benötigt enorm viel Rechenleistung, wodurch die Antwortzeiten des Systems spürbar steigen (Leistungseffizienz sinkt).
- Funktionale Eignung vs. Wartbarkeit: Die Kundschaft wünscht sich unzählige Spezialfunktionen und komplexe Ausnahmeregelungen im Programm (Funktionale Eignung steigt). Der Trade-off: Der Quellcode wird dadurch extrem verschachtelt, unübersichtlich und schwer zu testen (Wartbarkeit sinkt drastisch).
Die Perspektive der Nutzenden: Quality in Use
Selbst wenn die Software technisch perfekt programmiert ist (hohe Produktqualität), kann sie in der Praxis scheitern, wenn sie den Menschen bei ihrer eigentlichen Arbeit nicht hilft. Die Nutzungsqualität (Quality in Use) bewertet die Software daher ausschließlich im realen Nutzungskontext anhand von vier Hauptkriterien:
- Effektivität: Können die Nutzenden ihre Ziele vollständig und fehlerfrei erreichen? (z. B. Wird die Steuererklärung am Ende korrekt an das Finanzamt übermittelt?)
- Effizienz: Welchen Aufwand an Zeit und Mühe müssen sie dafür betreiben? (z. B. Braucht der Bestellvorgang 3 intuitive Klicks oder 20 unübersichtliche Schritte?)
- Zufriedenheit: Erfüllt das System die Erwartungen, ist es angenehm zu bedienen und vertrauen die Nutzenden der Software?
- Risikofreiheit: Vermeidet die Software im realen Einsatz wirtschaftliche oder gesundheitliche Schäden? (z. B. Verhindert die Navigations-App zuverlässig, dass ein LKW unter einer zu niedrigen Brücke stecken bleibt?)
Teste dein Wissen
Du diskutierst mit der Kundschaft über eine App. Das Team lobt den Code, die Kundschaft bemängelt die Bedienung. Wobei hilft die ISO/IEC 25010 hier?