Qualität – was ist das?

Mathematik hat eine wunderbare Wesenscharakteristik: Sie ist äußerst logisch, und ihre Regeln sind eindeutig. Nehmen wir nur die Addition: 1 + 1 ergibt immer 2.In der Softwareentwicklung verhält es sich jedoch nicht so eindeutig. Während mathematische Regeln klar und unveränderlich sind, sind die Anforderungen und Kriterien für Softwarequalität oft vielschichtig und variabel. Die reine Implementierung eines Features bedeutet dabei nicht zwangsläufig, dass das Feature damit auch korrekt umgesetzt wurde.Dies liegt zum einen daran, dass Software-Features viel komplexer sind als einfache Additionsaufgaben. Zum anderen gibt es unterschiedliche Perspektiven, die zu berücksichtigen sind. Dieser Artikel beschäftigt sich mit diesen Arten von Anforderungen, Sichtweisen sowie Qualitätsmerkmalen und stellt parallel diverse ISO-Standards vor, die diese Sichtweisen vereinheitlichen.

Ausgangsszenario

Um das Kernproblem zu verdeutlichen, stellen wir uns folgendes Szenario vor: Wir sollen eine Software für Frau Schmidt und Herrn Müller entwickeln. Beide sind Eigentümer eines Restaurants und möchten eine bessere Übersicht darüber erhalten, zu welchen Zeiten wie viele Gäste das Res­taurant besuchen und welche Gerichte sie bevorzugen. Frau Schmidt nimmt hauptsächlich die kaufmännischen Aufgaben wahr, während Herr Müller operativ tätig ist und gerne selbst hinter dem Herd steht.Mit beiden konnten wir schnell klären, welche Informationen das System darstellen soll und welche Workflows zu implementieren sind. Zudem haben wir bereits herausgefunden, wie wir auf zusätzliche Informationen über das Kassensystem zugreifen und die Software an das Einkaufssystem anbinden können, um weitere Erkenntnisse zu gewinnen und visuell darzustellen.Da wir der Auffassung sind, dadurch bereits ein gutes Verständnis der Anforderungen zu haben, möchten wir in einem weiteren Termin mit den Kunden die wichtigsten Details klären. Dies soll sicherstellen, dass wir ihre Qualitätsansprüche korrekt erfassen und umsetzen. Was müssen wir bei der Vorbereitung dieses Termins beachten, und wie wird er sich auf das Arbeitsergebnis auswirken?

Anforderungen und Merkmale

Im Beispielszenario konnten wir sehr schnell die entsprechenden Arbeitsabläufe und externen Systeme klären. Bei Anforderungen dieser Art sprechen wir meist genauer von den funktionalen Anforderungen. Diese beziehen sich vor allem auf die konkreten Funktionen der Software – also das, was sie letztendlich tun soll. Im vorliegenden Fall ist das etwa die Anforderung, dass unsere Software eine Funktion besitzen muss, mit der man ermitteln kann, wie viele Personen das Restaurant an bestimmten Tagen besucht haben.Funktionale Anforderungen klären jedoch nicht das „Wie“. Sie geben meist keine Auskunft darüber, wie viele Informationen das System insgesamt verarbeiten können muss und ob unsere Anzeigen auch per Mobiltelefon abrufbar sein sollen oder nur auf dem Office-PC der Restaurantbesitzer. Diese Kontextinformationen sind jedoch sehr wichtig, um grundlegende Architekturentscheidungen zu treffen und zukünf­tige Fehlentwicklungen zu verhindern.Reicht es etwa aus, alle Daten auf einem Rechner abzulegen und in einer simplen WinForms-Anwendung anzuzeigen, die dafür aber ressourcensparend arbeitet? Oder haben wir es mit so vielen Daten und Nutzern zu tun, dass wir besser auf eine High-Performance-Cloud-Lösung in Azure mit Serverless Computing und passendem Webfrontend setzen?Um diese Zusammenhänge klarer zu adressieren, verwenden wir im Qualitätsmanagement von Software in diesem Kontext meist folgende Begriffe, die zugegebenermaßen durchaus etwas verwirrend sein können:

• Qualitätsmerkmale: Eigenschaften von Objekten, anhand derer eine bestimmte Qualität beurteilt werden kann. In der Softwareentwicklung können dies Merkmale wie Portabilität, Wartbarkeit, Sicherheit oder Benutzerfreundlichkeit sein.
• Qualitätsanforderungen: Erwartungen und Kriterien, die an ein Produkt gestellt werden, um es als qualitativ hochwertig einzustufen. Diese Anforderungen sind kontextabhängig und können sehr allgemein gehalten sein.
• Nichtfunktionale Anforderungen: Sie präzisieren Qualitäts­anforderungen in Bezug auf die zuvor genannten typischen Merkmale von Software. Obwohl der Begriff nicht immer selbsterklärend ist und manchmal kritisiert wird, dienen die nichtfunktionalen Anforderungen dazu, klarzustellen, dass es sich um Qualitätsanforderungen handelt, die nicht direkt mit der Funktionalität zu tun haben. Da es sich hierbei eher um eine Feinheit handelt, ist es – bedauerlicherweise – auch durchaus üblich, die Begriffe Qualitätsanforderung und nichtfunktionale Anforderungen synonym zu verwenden.

Die Definition und die Umsetzung von nichtfunktionalen Anforderungen beinhalten oft eine Priorisierung der Qualitätsmerkmale. Diese Priorisierung ist entscheidend, da Qualitätsmerkmale in Wechselwirkung zueinander stehen und sich gegenseitig beeinflussen können.

Konkrete Merkmale und Definitionen

Wie bereits klar geworden sein dürfte, sind Qualitätsmerkmale bei der Bewertung der Güte eines Produkts sehr wichtig und sollten daher möglichst eindeutig definiert sein. Andernfalls läuft man Gefahr, im Projekt zwar die gleichen Begriffe zu nutzen, darunter aber unterschiedliche Dinge zu verstehen. Genau an dieser Stelle kommen nun Standards in Spiel, wobei uns nachfolgend vor allem der ISO-Standard 25010 interessiert [1]. Er ist Teil der Standardfamilie 25000 – ihr widmen wir uns nachfolgend noch genauer – und beschreibt insgesamt neun Hauptkategorien an Anforderungen, die er über entsprechende Unterkategorien dann noch genauer spezifiziert (siehe Bild 1).

Betrachten wir nun also diese Hauptkategorien und sehen wir uns an, welche Auswirkungen ihre Ausprägungen auf unser Beispielszenario haben. Die genauen Definitionen des Standards finden sich in Tabelle 1. Wir verwenden dafür sowohl englische als auch deutsche Begriffe aus dem Standard, da die deutsche Übersetzung leider nicht immer eindeutig ist. Gleich vorweg: Die Definitionen sind im ersten Moment vielleicht nicht ganz eingängig, aber hochgradig durchdacht, da sie über lange Zeit in verschiedenen Expertengremien erarbeitet wurden, um möglichst aussagekräftig und in ihrer Summe konsistent zu sein.

Tabelle 1: Hauptkategorien der ISO 25010 von 2023 und deren Definitionen

Flexibility (Flexibilität) Fähigkeit eines Produkts, sich an veränderte Anforderungen, Nutzungskontexte oder Systemumgebungen anzupassen Maintainability (Wartbarkeit) Fähigkeit eines Produkts, von den vorgesehenen Betreuern effektiv und effizient geändert zu werden. Reliability (Zuverlässigkeit) Fähigkeit eines Produkts, bestimmte Funktionen unter bestimmten Bedingungen über einen bestimmten Zeitraum hinweg ohne Unterbrechungen und Ausfälle zu erfüllen. Security (Sicherheit im Sinne der Kriminalprävention) Fähigkeit eines Produkts, Informationen und Daten so zu schützen, dass Personen oder andere Produkte den ihrer Art und Berechtigung entsprechenden Grad des Datenzugriffs erhalten, und sich gegen Angriffsmuster böswilliger Akteure zu schützen. Performance Efficiency (Leistungseffizienz) Fähigkeit eines Produkts, seine Funktionen innerhalb bestimmter Zeit- und Durchsatzparameter zu erfüllen und unter bestimmten Bedingungen effizient mit den Ressourcen umzugehen. Compatibility (Kompatibilität) Fähigkeit eines Produkts, Informationen mit anderen Produkten auszutauschen und/oder seine erforderlichen Funktionen auszuführen, während es dieselbe gemeinsame Umgebung und Ressourcen nutzt. Functional Suitability (Funktionale Eignung) Fähigkeit eines Produkts, Funktionen zu bieten, die den erklärten und impliziten Bedürfnissen der vorgesehenen Benutzer entsprechen, wenn es unter bestimmten Bedingungen verwendet wird. Interaction Capability (Interaktionsmöglichkeiten) Fähigkeit eines Produkts, mit dem bestimmte Benutzer interagieren können, um Informationen zwischen einem Benutzer und einem System über die Benutzerschnittstelle auszutauschen, um die beabsichtigte Aufgabe zu erfüllen. Safety (Betriebssicherheit) Fähigkeit eines Produkts, unter definierten Bedingungen einen Zustand zu vermeiden, in dem das Leben von Menschen, die Gesundheit, Eigentum oder die Umwelt gefährdet sind.

Wartbarkeit

Beginnen wir bei der Betrachtung der einzelnen Qualitätsmerkmale aber zunächst mit dem für uns Entwickler einfachsten Merkmal, der Wartbarkeit beziehungsweise Maintainability. Diese umfasst vieles, womit wir uns im Alltag stärker konfrontiert sehen und das die Endanwender meist nur mittelbar wahrnehmen. Hierzu gehört beispielsweise, wie gut man den Quellcode verstehen kann, wie gut die Software getestet und verändert werden kann oder wie modular das System aufgebaut ist und dessen einzelne Bestandteile wiederverwendet werden können.In einem Szenario wie in unserem Beispiel spielt die Wartbarkeit für die Kunden nur dann tatsächlich eine direkte Rolle, wenn sie vom Auftragnehmer den Quellcode übernehmen wollen. Gerade in größeren Projekten wird dann auf qualitätssichernde Maßnahmen hingewiesen und zum Beispiel ­eine Mindestabdeckung des Quellcodes mit automatisierten Tests gefordert. Genauso häufig passiert es aber auch, dass die Wartbarkeit in den Ausschreibungsunterlagen nur eine sehr untergeordnete Rolle spielt, da Nichttechniker sich der Besonderheiten von Software auf dieser Ebene nur schwerlich bewusst sind.Frau Schmidt und Herr Müller werden also wahrscheinlich eher davon ausgehen, dass wir Code schreiben, den andere auch verstehen können. Wir als Auftragnehmer sollten aber ebenfalls darauf bedacht sein, da wir somit bei zukünftigen Änderungswünschen schneller reagieren können und unsere Kunden selbstverständlich verschnupft reagieren, wenn wir ihnen fehlerhafte Software liefern. Die Wartbarkeit können wir, außer mithilfe von Testframeworks wie XUnit.NET und Nunit, auch über eine entsprechende Architektur-Dokumentation stärken oder durch den Einsatz gängiger Analysewerkzeuge wie NDepend [2] oder SonarQube [3].

Zuverlässigkeit

Bei der Wartbarkeit gab es bereits einen Hinweis auf die Zuverlässigkeit. Denn die Fehler, die wir in Bezug auf Wartbarkeit machen, nehmen Außenstehende meist eher über die Zuverlässigkeit war. Dies zeigt uns, dass eigentlich kein Merkmal wirklich eigenständig ist. Es ist vielmehr so, dass sie eine Perspektive darstellen, und somit können Bugs, die aufgrund einer fehlenden Zielarchitektur (Thema der Wartbarkeit) ihren Weg ins System finden, durch Abstürze oder fehlerhaftes Laufzeitverhalten wahrgenommen werden. Die Kunden werden auch hierauf seltener direkte Anforderungen stellen, sondern eher darauf reagieren, wenn man sie fragt, in welchen Zeiten denn die Applikation in jedem Fall zur Verfügung stehen muss.Dies kann dann auch Auswirkungen auf mögliche Kosten und die Architektur haben. Reicht es aus, das System bei einem Fehler neu zu starten, und sind einzelne Abstürze kein Problem, dann könnte man auch einfach irgendwo einen Monolithen hosten. Soll das System hingegen möglichst 24 Stunden an sieben Tagen pro Woche verfügbar sein und auch bei einem Fehler zumindest teilweise arbeiten können, schreit es förmlich nach einer Cloud-native-Microservice-Architektur. Diese kostet dann aber eben sowohl in der Entwicklung als auch im Betrieb mehr Geld.Microsoft bietet für Azure diverse Dienste und auch eine Übersicht der möglichen Kosten [4]. Für uns ist beim Gespräch mit den Auftraggebern aber in jedem Fall wichtig, dass wir ein transparentes Erwartungsmanagement betreiben. Dazu gehört, dass wir ihnen klarmachen, dass es immer wieder Gründe für Softwarefehlverhalten geben kann und dass eine hohe Verfügbarkeit eben auch entsprechend hohe Betriebskosten nach sich zieht.

Flexibilität

Die Flexibilität ist eine Eigenschaft, die sich im Übergang vom 2011 geschaffenen hin zum 2023 aktualisierten Standard stark verändert hat. Hieß sie früher noch Portabilität, geht es jetzt generell um eine Anpassbarkeit des Gesamtsystems. Damit ist nicht nur der Quellcode gemeint, sondern auch das Zusammenspiel aller Bestandteile. Dies bezieht externe Systeme mit ein. Hierin finden sich nun auch Bereiche wie die Installierbarkeit und Skalierbarkeit, die sehr starken Einfluss auf die Architektur haben und ebenfalls mit der Wartbarkeit korrelieren können.Im Austausch mit unseren Auftraggebern besprechen wir hierzu beispielweise, ob es Zeiten gibt, in denen das System mal mehr, mal weniger Last vertragen muss. Es kann aber auch um Themen wie die Aktualisierung von Installationen gehen. Letzteres ist etwa bei der Umsetzung einer App wichtig und wird gelegentlich vergessen. Die Kunden beschweren sich dann unter Umständen, dass all ihre Daten nach einer Installation verschwunden sind und die Applikation auf Werkseinstellungen zurückgesetzt wurde.

Kompatibilität

Kompatibilität beschäftigt sich etwas weniger mit der eigenen Software, sondern vielmehr damit, wie sie mit anderen Softwareprodukten interagiert. In unserem Beispiel also geht es um die Integration mit dem Kassensystem und dem Einkaufssystem sowie deren am Ende stehenden Datenaustauschformaten. Einen weiteren Aspekt erhält die Kompatibilität durch die Koexistenz, die vor allem bei der gemeinsamen Nutzung einer Laufzeitumgebung von Interesse ist.Installiert man beispielsweise verschiedene Softwareapplikationen auf der gleichen Windows-Installation, kann es durchaus passieren, dass diese sich gegenseitig CPU-Zeit und Arbeitsspeicher streitig machen oder Änderungen an den Betriebssystemeinstellungen vornehmen, die sich nicht miteinander vertragen.Letzteres kann man durch die Verwendung von Containern verhindern, denn Docker und Co. erfreuen sich nicht zuletzt auch dadurch großer Beliebtheit, dass alle auf diese Weise gehosteten Applikationen stark voneinander getrennt sind. In Sachen Ressourcenverbrauch sind diese dann auch genügsamer als vergleichbare virtuelle Maschinen.

Effizienz

Das führt uns auch gleich zur Laufzeiteffizienz, bei der die Ressourcenausnutzung, die vorgehaltene Kapazität und das Zeitverhalten eine Rolle spielen. Diese Themen scheinen für die Entwicklung im ersten Moment vielleicht nicht allzu interessant zu sein, treiben sie doch die Entwicklungskosten nur bedingt. Ganz im Gegenteil könnte man eventuell sogar davon ausgehen, dass Effizienzoptimierungen schnell zu Overengineering führen. Nichtsdestotrotz muss die Effizienz auch schon bei der Erstellung der Architektur berücksichtigt werden, bestimmt sie doch in der späteren Phase der Applikationsnutzung sehr stark die Betriebskosten.Gerade im Kontext der Cloud kann es zu einem bösen Erwachen kommen, wenn das System im Betrieb weitaus teurer wird als zunächst gedacht, da teure Komponenten verwendet werden oder hohe Datenmengen entstehen. Dies ist beispielsweise Amazon im Zusammenhang mit ihrem Video-on-demand-Angebot geschehen, bei dem die Serverless-Architektur zu einem so hohen Traffic führte, dass sich das Entwicklungsteam zu einem radikalen Schritt entschied und die Gesamtlösung nachträglich auf einen monolithischeren Ansatz umbaute [5]. Als Ergebnis schaffte es das Team damit, die Betriebskosten um satte 90 Prozent zu reduzieren.

Funktionale Eignung

Das Amazon-Beispiel zeigt, dass man nicht unbedingt alles tun muss, was man tun kann. Die damit verbundene Frage „Wann ist es genug?“ wird leider auch im Kontext der Funktionalität von Software eher selten gestellt. Diese ist aber Gegenstand der funktionalen Eignung, welche zum Beispiel betrachtet, ab wann Rechenergebnisse genau genug sind beziehungsweise ab wann eine Funktionalität als korrekt oder angemessen angesehen werden kann.In der Restaurantsoftware stellt sich daher etwa die Frage, auf wie viele Nachkommastellen genau Geldbeträge gespeichert oder angezeigt werden sollen. Gerade in finanziellen Bereichen sollte man nicht auf float oder double als Daten­typen zurückgreifen, da diese ihrer Natur gemäß nicht alle Nachkommastellen korrekt darstellen können.Microsoft stellt deshalb schon seit den Anfangstagen des .NET Framework den Datentyp decimal bereit, der diesen Umstand behebt [6]. Er hat aber eine vergleichsweise schlechte Ressourceneffizenz und ist somit nicht geeignet, gänzlich alle Fließkommazahlen abzubilden.

Interaktionsmöglichkeiten

In früheren Versionen des ISO-Standards 25010 behandelte man die Interaktionsmöglichkeiten noch als „Benutzbarkeit“, hat aber mit der Version von 2023 den Geltungsbereich erweitert. Zwar dreht sich dieser Teil des Standards noch immer vorrangig um das Frontend einer Applikation, er kann nun aber auch leichter auf APIs angewendet werden. Grund hierfür ist, dass Dinge wie die Erlernbarkeit oder der Wiedererkennungswert nicht nur Themen für das GUI sind, sondern auch wichtige Faktoren bei der Nutzung von Schnittstellen. Zugegeben, bei Themen wie Inklusion mag der Zusammenhang dann unter Umständen nicht mehr gegeben sein.Für die Software von Frau Schmidt und Herrn Müller mag die Frage nach der Benutzbarkeit auch nicht gleich auf der Hand liegen. Rein unternehmensinterne Software wird in Bezug auf die Interaktionsmöglichkeiten gern vernachlässigt, kann man die Endnutzer doch schulen und haben sie doch ohnehin keine Wahl, etwas anderes zu verwenden (Thema User Engagement). Weiß man aber, dass Herr Müller zu den acht Prozent der deutschen Männer gehört, die farbenblind sind [7], wird einem schnell klar, dass man dies auch in der Software berücksichtigen muss. Hinzu kommen Features, die man heutzutage einfach erwarten würde und die bei der Ermittlung von Anforderungen gar nicht mehr direkt angesprochen werden, weil sie so normal scheinen. Dazu gehört beispielsweise die Validierung von Nutzereingaben, die vor Fehleingaben schützt.

Sicherheit

Das Thema Sicherheit ist im Standard gleich zweifach abgedeckt – zum einen durch Security, zum anderen durch Safety. Letztere repräsentiert die Betriebssicherheit, die in unserem Beispiel womöglich keine allzu große Rolle spielt. Dies würde sich allerdings ändern, wenn unsere Restaurantsoftware auch Einfluss auf den Schließmechanismus der Tür hat und wir als Entwickler darauf zu achten haben, dass sich niemand darin einklemmt.Die Security betrifft hingegen die Kriminalprävention. In diesem Kontext geht es darum, Fremde am Zugriff auf die Geschäftsdaten von Frau Schmidt und Herrn Müller zu hindern oder zumindest aufzuzeichnen, welche Daten gegebenenfalls abgeflossen sind. Ebenso relevant ist hierbei, dass Änderungen am System und seinen Daten eindeutig bestimmten Personen zugeordnet werden können. Das kann sogar dem einen oder anderen Streit der Nutzenden vorbeugen, wenn jene eindeutig nachvollziehen können, wer von ihnen wichtige Systemeinstellungen der Software geändert hat.

Weitere Qualitätsmodelle und Fazit

Mit unserem Ausflug in die ISO 25010 haben wir tatsächlich nur einen Teilbereich der gesamten Familie an Standards gestreift. So gibt es im gesamten Bereich der 2501x noch die 25012, welche die Datenqualität beschreibt. Die 25013 hingegen gibt Leitlinien zur Anwendung des Qualitätsmodels aus der 25010. 25014 beschäftigt sich wiederum mit den Zusammenhängen im Betrieb und geht zum Beispiel im Kontext der Sicherheit und Verfügbarkeit noch weiter in die Tiefe.Aber auch das war es noch nicht ganz. Denn neben der Standardfamilie 2501x kann man noch tiefer hinabsteigen, indem man unter anderem die ISO-2502x-Serie betrachtet, welche sich mit Messmodellen für Softwarequalität befasst, sowie die ISO-2503x-Serie, die Anforderungen an Qualitätsmodelle festlegt. Die ISO-2504x-Serie beschreibt die Vorgehensweise zur Evaluierung der Softwarequalität, und die ISO-2505x-­Serie legt Standards für die Qualität von Daten fest.Man sieht also: Das Thema ist sehr umfangreich, was nachvollziehbarerweise auch dessen Wichtigkeit unterstreicht. Ob man sich mit allen Zusammenhängen beschäftigt, ist einem natürlich selbst überlassen. Es empfiehlt sich aber, mindestens im Kopf zu behalten, dass die Qualitätswahrnehmung sehr subjektiv ist und dass Standards helfen, diese zu objektivieren.

Fussnoten

1. ISO/IEC 25010:2023, https://www.iso.org/standard/78176.html
2. Analysewerkzeug Ndepend, https://www.ndepend.com
3. Analysewerkzeug SonarQube, http://www.dotnetpro.de/SL2501SWQualitaet1
4. Microsoft-Azure-Verfügbarkeitszonen, http://www.dotnetpro.de/SL2501SWQualitaet2
5. Joab Jackson, Return of the Monolith: Amazon Dumps Microservices for Video Monitoring, http://www.dotnetpro.de/SL2501SWQualitaet3
6. Microsoft Learn, Numerische Gleitkommatypen (C#-Referenz), http://www.dotnetpro.de/SL2501SWQualitaet4
7. Netzhaut und Farbenblindheit, http://www.dotnetpro.de/SL2501SWQualitaet5
8. Online Browsing Plattform, http://www.dotnetpro.de/SL2501SWQualitaet6