Qualitätsmerkmale

Lesezeit: 13 Minuten

Eine Tür dient dem Betreten und Verlassen eines Raumes oder Gebäudes. Sie kann geöffnet und geschlossen werden. An eine Außentür werden andere Anforderung gestellt, als an eine Innentür, die zwei angrenzende Räume in einem Wohnbereich verbindet. Eine Außentür muss bestimmten Witterungsbedingungen standhalten. Sie schützt vor Wind und Regen. Sie hält im Winter die Wärme drinnen und im Sommer die Hitze draußen. Sie bietet einen gewissen Schutz vor Unbefugten und lässt sich mit verschiedenen Schlössern verwenden. Sie kann mit Türspion oder Briefschlitz ausgestattet sein, automatisch ins Schloss fallen oder sich per Näherungssensor öffnen. Sie erlaubt es kleinen Kindern und auch besonders großen Menschen, hindurch zu schreiten, Menschen im Rollstuhl, mit Fahrrad, Kinderwagen oder auch einem großen Paket in den Händen.

Die Anforderungen an eine Tür können vielfältig sein, sie sind aber immer auf den vorgesehenen Zweck zugeschnitten. Eine gewöhnliche Haustür schützt nicht vor Hochwasser, vor Außentemperaturen über hundert oder unter minus hundert Grad. Auch einer Bearbeitung mit professionellen Werkzeugen halten gewöhnliche Haustüren nicht stand. Der Grund ist offensichtlich: Die „perfekte“ Tür würde jeglichen Kostenrahmen sprengen.

Bei Software sieht das oft anders aus. Die Software soll natürlich fehlerfrei sein. Sie soll sehr schnell und ausfallsicher sein. Selbstverständlich muss sie sicher und gut bedienbar sein. Bei Bedarf muss sie beliebig skalieren und zweifelsohne langlebig sein. Natürlich wird sie in den nächsten Jahren vielfältig erweitert, dabei sollen die Entwicklungs- und Wartungskosten gering bleiben.

Dass solche universellen Anforderungen an Software gestellt werden, aber üblicherweise nicht an eine Haustür, liegt auch daran, dass Software abstrakt ist. Es leuchtet jedem ein, dass eine Haustür, die einen sich mit Ortsgeschwindigkeit nähernden Bus aufhalten kann, ungewöhnlich und sehr sehr teuer ist. Dabei ist auch jedem klar, dass die Tür alleine sinnlos ist, wenn das Mauerwerk und die Verankerung der Einwirkung nicht standhalten. Wie aber wird z.B. eine hohe Ausfallsicherheit einer Software erreicht und welche Implikationen bringt das mit sich? Wie kann der Grad an Ausfallsicherheit überhaupt gemessen werden? Diese Fragen sind schwerer zu beantworten und gerade deshalb ist es entscheidend, sich um Qualitätsmerkmale von vornherein Gedanken zu machen, denn sie beeinflussen die Architektur maßgeblich – und Architektur ist derjenige Teil einer Software, dessen Änderung einen hohen zeitlichen und monetären Invest bedeutet.

Welche Qualitätsmerkmale gibt es?

Dem ISO/IEC 9126 und seinem Nachfolger ISO/IEC 25010:2011 sei dank, dass bei dieser Frage niemand bei null anfangen muss. Der besagte Standard definiert 8 übergeordnete Qualitätsmerkmale mit 31 untergeordneten Qualitätsmerkmalen, die möglichst allgemein auf Softwaresysteme anwendbar sind:

Funktionale Eignung

Die funktionale Eignung beschreibt, inwieweit die fachlichen Anforderungen erfüllt werden. Dabei geht es um die grundsätzliche Umsetzbarkeit, ob diese auf angemessene Weise erfolgen kann und mit welcher Genauigkeit diese abgebildet werden kann:

Funktionale Vollständigkeit
Funktionale Korrektheit
Funktionale Angemessenheit

Zuverlässigkeit

Unter Zuverlässigkeit fällt die Verfügbarkeit und Stabilität des Systems, wie resilient es gegenüber Störungen und Fehlern ist und wie schnell und einfach es nach einem Ausfall wiederhergestellt werden kann:

Reife
Verfügbarkeit
Fehlertoleranz
Wiederherstellbarkeit

Performance

Performance, im Original „Performance Efficiency“, beinhaltet Aspekte wie Geschwindigkeit, Latenz und den Bedarf an Ressourcen wie Festplatten- und Arbeitsspeicher:

Zeitverhalten
Ressourcennutzung
Kapazität

Benutzbarkeit

Die Benutzbarkeit umfasst die Arbeit der Endanwender mit dem System, als wie intuitiv es wahrgenommen wird, wieviel Einarbeitungsaufwand erforderlich ist, ob Endanwender autark arbeiten können oder es ein hohes Ticketaufkommen gibt, wie angemessen das System auf Eingaben reagiert (etwa visuelles Feedback), wie angenehm die Arbeit mit dem System ist und ob es auch für Menschen mit Einschränkungen verwendbar ist:

Verständlichkeit
Erlernbarkeit
Bedienbarkeit
Eingabevalidierung
Ästethik
Barrierefreiheit

Informationssicherheit

Informationssicherheit umfasst den Schutz der im System verwalteten Informationen bzw. Daten gegen den Zugriff von Unbefugten, Sicherheitsmaßnahmen gegen Manipulation und Transparenz darüber, wer zu welchem Zeitpunkt welche Daten geändert hat:

Vertraulichkeit
Integrität
Nachvollziehbarkeit
Zurechenbarkeit
Authenzität

Kompatibilität

Die Kompatibilität beschreibt das Zusammenspiel und die Integration mit anderen Systemen, ob es auf offene Standards setzt, Plugins für die Integration mit anderen Diensten vorsieht oder uneingeschränkt neben anderen Programmen auf dem gleichen System installiert und betrieben werden kann:

Koexistenz
Interoperabilität

Wartbarkeit

Die Wartbarkeit zeigt auf, wie leicht spätere Anpassungen oder Erweiterungen möglich sind, ob Teile des Codes wiederverwendet werden können, der Code dokumentiert und durch automatische Tests abgesichert ist? Wie leicht (oder schwer) es Entwicklern fällt, sich neu in den Code einzuarbeiten und Anpassungen vorzunehmen:

Modularität
Wiederverwendbarkeit
Analysierbarkeit
Veränderbarkeit
Testbarkeit

Portabilität

Portabilität beschreibt die Übertragbarkeit einer Software in eine andere Umgebung. Kann das System in einem Container betrieben werden? Kann es leicht von On-Premises in die Cloud oder andersrum migriert werden? Ist der Betrieb an ein bestimmtes Betriebssystem oder eine Prozessorarchitektur gebunden? Kann ein Desktopprogramm leicht auf einem mobilen Endgerät lauffähig gemacht werden und andersrum? Werden externe Abhängigkeiten mitgeliefert oder müssen sie vorinstalliert sein? Die Portabilität umfasst drei Unterpunkte:

Anpassbarkeit
Installierbarkeit
Austauschbarkeit

Weitere Qualitätsmerkmale

Die oben genannten Punkte bieten eine gute Ausgangslage. Je nach Art der Software ist es aber sinnvoll, weitere Merkmale zu betrachten. Ein Embedded-System unterscheidet sich nun mal fundamental von einer Smartphone-App. Als jemand, der sich viel mit Cloud-nativen serverseitigen Systemen beschäftigt, fehlt mir z.B. der Punkt Skalierung. Zu einem gewissen Grad lässt sich dieser im Performance-Unterpunkt Kapazität unterbringen, das kommt mir bei dieser Art von Systemen aber oft zu kurz. Skalierung ist natürlich erst dann relevant, wenn die Software bereits erfolgreich ist, denn ohne viele Kunden muss man auch nicht skalieren. Betrachtet man aber ein bestehendes System mit hoher Kundenzahl, das in der Cloud neu gebaut werden soll, stellen sich zu dem Thema viele Fragen mit großem Einfluss auf die Architektur: Reicht eine vertikale Skalierung oder möchte ich von Anfang an horizontal skalieren? Welche Teile des Systems sollten zu welchem Grad skalierbar sein, ggf. unabhängig voneinander? Welche Lastspitzen, etwa das Weihnachtsgeschäft, müssen berücksichtigt werden?

Interne und externe Qualitätsmerkmale

Qualitätsmerkmale lassen sich in intern und extern unterteilen. Ist die funktionale Eignung nicht gegeben, das System unzuverlässig, die Performance dürftig oder das System nicht gut benutzbar, bemerken die Endanwender diese Unzulänglichkeiten sofort. Es handelt sich dabei also um externe, bzw. äußere Qualitätsmerkmale. Bei Sicherheit, Wartbarkeit, Kompatibilität und Portierbarkeit hingegen spricht man von internen Qualitätsmerkmalen. Diesen machen sich in der Regel nicht direkt bemerkbar und belasten vor allem diejenigen, die sich für den Betrieb, die Weiterentwicklung und die Finanzierung der Software verantwortlich zeigen. Unzureichende Sicherheit fällt unter Umständen erst bei einem Sicherheitsvorfall auf, oder wenn das öffentliche Interesse entsprechend hoch ist und Sicherheitsforscher Mängel aufdecken. Kompatibilitätsdefizite können unter der Haube adressiert werden und sich in höheren Wartungsaufwänden oder der Nicht-Umsetzbarkeit von Anforderungen niederschlagen. Es ist wichtig beide Arten von Qualitätsmerkmalen im Blick zu behalten. Während externe Qualitätsmerkmale die Software überhaupt erstmal attraktiv machen und potenzielle Kunden anziehen, sorgen die internen Qualitätsmerkmale für Nachhaltigkeit und verringern das Risiko explodierender Kosten und gefrusteter Entwickler.

Ableitung von Qualitätszielen

Mit einem guten Überblick über die relevanten Qualitätsmerkmale kann man Qualitätsziele für diese Software ableiten. Dabei ist es wichtig zu verstehen, dass nicht alle Qualitätsmerkmale perfekt erfüllt werden können, da sie in Konflikt zueinander stehen. Viele Maßnahmen, die die Sicherheit erhöhen, gehen zu Lasten der Benutzbarkeit. Eine Webanwendung, die hohe Ansprüche an Zuverlässigkeit und Performance hat, ist wahrscheinlich wartungsaufwändiger als eine, die nicht-redundant läuft und nur vertikal skaliert.

Qualitätsziele werden am besten ganz zu Beginn formuliert, da sie einen großen Einfluss auf die Architektur haben. Sie können aber auch nachträglich für Bestandssoftware bestimmt werden, um Defizite aufzudecken und die zukünftige Richtung für das Produkt festzulegen. Je nach Produkt suche ich mir eine handvoll Qualitätsmerkmale raus, die für das Produkt einen besonderen Stellenwert haben. Wenn es passt, können diese auch in eine Reihenfolge gebracht werden.

Im Folgenden führe ich die Qualitätsziele auf, die ich mir für meinen Passwortmanager PwMan3 auferlegt habe, den ich selbst intensiv auf täglicher Basis nutze:

Qualitätsziel	Beschreibung	Begründung
Zuverlässige Passwortverwaltung (Funktionale Korrektheit)	PwMan3 generiert und verwaltet sichere Passwörter. Das Programm gibt jederzeit das richtige Passwort zum gewünschten Eintrag zurück.	Passwörter müssen zuverlässig gespeichert und herausgegeben werden, da sie ansonsten nicht mehr funktionieren und damit wertlos sind.
Komfortabler Shell-Zugriff (Bedienbarkeit)	PwMan3 kann mit sehr wenigen Handgriffen gestartet werden und Passwörter preisgeben. Der Einsatz einer Maus oder graphischen Benutzeroberfläche ist nicht erforderlich.	Die Zielgruppe (ich) arbeitet gerne auf der Kommandozeile ohne Einsatz einer Maus. Damit das Programm als nützlich wahrgenommen wird, sollte die Eingabe entsprechender Befehle sehr schnell von der Hand gehen.
Leichte Neuinstallation (Wiederherstellbarkeit)	PwMan3 kann, auch auf einem neuen System, schnell und unkompliziert aufgesetzt und mit einer bestehenden Passwortdatenbank verwendet werden.	Steht der Passwortmanager nicht zur Verfügung, kann auf wichtige Dienste nicht mehr zugegriffen werden. Bei Ausfall eines Endgerätes oder versehentlichem Löschen muss die Software möglichst einfach auf einem anderen Gerät zum Laufen gebracht werden können.
Angemessener Zugriffsschutz (Vertraulichkeit)	PwMan3 legt Passwörter verschlüsselt ab und gewährt den Zugriff erst nach erfolgreicher Authentifizierung.	Passwörter dürfen nicht an Dritte preisgegeben werden, da diese ansonsten Zugriff auf persönliche Konten erhalten, was auch finanzielle Folgen haben kann.
Einfache Weiterentwicklung (Wartbarkeit)	PwMan3 kann leicht geändert oder um weitere Funktionen ergänzt werden.	PwMan3 wird von einer Person entwickelt, die nur einen geringen Teil ihrer Freizeit dafür aufbringen kann. Damit trotzdem neue Funktionen implementiert werden können, sollte der Aufwand dafür so gering wie möglich sein.

Wir sollten vermeiden, bei der Formulierung von Qualitätszielen Lösungen vorzugeben. Stattdessen sollten wir uns bewusst machen, welches Ziel wir verfolgen, wenn wir eine bestimmte Lösung im Kopf haben und diese in den Mittelpunkt stellen. Konkrete Lösungen können veralten, auch kann es sein, dass es bessere Alternativen gibt, die man bei der Formulierung der Qualitätsziele nicht im Blick hat. Die Ziele in den Mittelpunkt zu stellen erleichtert es allen Beteiligten besser zu verstehen, was wirklich wichtig ist.

Ableitung von Entscheidungen

Auf Basis der formulierten Qualitätsziele lassen sich (Architektur-)Entscheidungen treffen. Gleichzeitig stellen sie sicher, dass getroffene Entscheidungen zu den Qualitätszielen des Produktes passen und können als Argumentationsgrundlage für fundierte und langlebige Entscheidungen genutzt werden. Allen Projekt- bzw. Produktbeteiligten geben Qualitätsziele Klarheit bzgl. der Ausrichtung des Produktes. Früher oder später kommt es in jedem Projekt zu Fluktuation. Entscheidungen können deutlich stabiler und langlebiger sein, wenn auch neuen Mitgliedern transparent ist, warum bestimmte Entscheidungen getroffen wurden. So lässt sich auch leichter bewerten, ob eine Entscheidung zu einem späteren Zeitpunkt noch beibehalten werden soll, oder sich die Sachlage geändert hat. Unterstützend können Architecture Decision Records angefertigt werden.

Zur Veranschaulichung führe ich hier einige Entscheidungen auf, die ich für das Produkt PwMan3 auf Basis meiner formulierten Qualitätsziele getroffen habe:

PwMan3 wird mit der Java-Platform umgesetzt (Wartbarkeit und Wiederherstellbarkeit)
PwMan3 verwendet für den Zugriff ein System aus Kurzbegriffen, üblicherweise ist nur eine einzelne Interaktion notwendig, um eine Aktion durchzuführen (Bedienbarkeit)
PwMan3 sichert unwiderrufliche Aktionen bei Bedarf durch eine Sicherheitsabfrage ab (Bedienbarkeit)
PwMan3 legt sensible Daten nur möglichst kurz im Arbeitsspeicher ab (Vertraulichkeit)
PwMan3 legt Passwörter lokal verschlüsselt ab und verwendet zur Authentifizierung einen Java-Keystore (Vertraulichkeit)
PwMan3 bietet keine Möglichkeit zur Passwortwiederherstellung (Vertraulichkeit)
PwMan3 ist 100% offline, es gibt keine automatische Aktualisierung, Synchronisation oder Schnittstelle zu anderen Diensten (Vertraulichkeit und Wartbarkeit)
PwMan3 bietet keine Integration in andere Software, etwa als Webbrowser-Plugin (Vertraulichkeit und Wartbarkeit)
PwMan3 ist modular aufgebaut und orientiert sich an hexagonaler Architektur (Wartbarkeit)
PwMan3 hat eine hohe Testabdeckung und sichert seine Architektur mit ArchUnit ab (Wartbarkeit)
PwMan3 verwendet nur dort Abhängigkeiten, wo der Mehrwert gegenüber des Risikos als sehr hoch angesehen wird (Vertraulichkeit und Wartbarkeit)
PwMan3 kann durch den simplen Austausch einer Jar-Datei aktualisiert werden (Wiederherstellung und Wartbarkeit)

Fazit

Qualitätsmerkmale geben die grobe Richtung vor und liefern Orientierungspunkte für alle Projek-/Produktbeteiligten, sie geben aber keine Antworten auf Detailfragen. Welche Ausfallszenarien etwa werden berücksichtigt und wie sehen die Wiederherstellungsmaßnahmen aus? Um auf dieser Ebene Klarheit zu schaffen und Entscheidungen zu treffen, bietet es sich an, Qualitätsszenarien zu entwickeln. Mit diesem Thema werde ich mich im nächsten Beitrag in der Kategorie Architektur auseinandersetzen.