Quality-driven Software Architecture stellt einen praxisorientierten Ansatz dar, um die wesentlichen Qualitätseigenschaften zielsicher zu erreichen. Mit bewährten Ansätzen wie Domain-driven Design bekommen wir die Fachlichkeit von Systemen gut strukturiert, aber Performance, Robustheit, Flexibilität, Sicherheit und andere wichtige Eigenschaften bleiben dabei außen vor. Qualität gehört dabei zu den zentralen Themen von Entwicklungsteams.

Was bedeutet „Qualität“?

Wir verwenden „Qualität“ umgangssprachlich, um etwas Gutes oder Positives in Bezug auf Produkte oder Leistungen auszudrücken. Ein Kleidungsstück etwa, ein besonderes Essen oder auch ein technisches Gadget versehen wir mit dem Label „hohe Qualität“. Leider bleiben wir dabei in der Regel unspezifisch, was wir denn in diesen Fällen genau mit dem Begriff Qualität meinen.

Bei einem geschätzten Kollegen durfte ich vor einiger Zeit dessen (ziemlich teuren) Over-Ear-Kopfhörer eines britischen Nobelherstellers probehören. Daraufhin entspann sich eine lebhafte Diskussion, was denn genau die Qualität von Kopfhörern ausmacht: Ist es das Frequenzspektrum, die maximal erreichbare Lautstärke, die Bequemlichkeit und Tragekomfort, das Gewicht, die Art und Zahl möglicher Anschlüsse, originalgetreue oder auf spezifische Musikrichtungen optimierte Wiedergabe, die Dämpfung von Außengeräuschen (Noise Cancelling), die saubere Kanaltrennung oder die Bedienbarkeit über Gesten oder Tasten? Gehört der nachhaltige und umweltoptimierte Herstellungsprozess auch dazu? Muss die Produktion frei von Kinderarbeit sein? Oder sollen die Ohrpolster gar austauschbar sein? Und wie steht es um die Haltbarkeit/Langlebigkeit?

Sie merken schon – bei einer Diskussion um Qualität kommen fast zwangsläufig persönliche Vorlieben und Interessen ins Spiel (Kasten: „Qualität: Die (unbrauchbare) Definition“). Damit haben wir schon ein interessantes Merkmal von Qualität angesprochen: Sie ist hochgradig subjektiv.

Versuchen Sie im Kreis ihrer Bekannten mal, die Qualität alltäglicher Dinge zu konkretisieren: Tee, Kaffee, Käse, Schuhe, Hosen oder gar das Smartphone: Welche Eigenschaften genau die Qualität dieser Dinge ausmachen, kann schon zu Debatten führen (Kasten: „Unzureichender Standard“).

Zwei Dimensionen …

Jetzt wird’s langsam kompliziert, denn der Begriff „Qualität“ erhält damit zwei verschiedene Dimensionen:

1. welche Eigenschaften zu Qualität zählen (im Beispiel: Lautstärke, Frequenzumfang, Bequemlichkeit, Gewicht, Anschlüsse, Noise Cancelling, Kanaltrennung, Nachhaltigkeit, Austauschbarkeit von Teilen)

2. die Ausprägung dieser Eigenschaften (etwa Frequenzgang von 15 bis 25 000 Hz, Gewicht unter 400 g, Ohrmuscheln aus weichem Leder, Anschluss Wireless, mit Klinke und USB usw.)

Um in der Praxis an „Qualität“ arbeiten zu können, müssen wir diese beiden Dimensionen in den Griff bekommen. Versuchen wir an dieser Stelle den Übergang zur Softwareentwicklung: Bereits bei der Dimension 1 („Welche Eigenschaften gehören zu Qualität?“) fällt Ihnen sicherlich eine Vielzahl solcher Eigenschaften ein, die Sie oder andere Beteiligte (aka Stakeholder) zur Qualität zählen: Performance, Sicherheit, Robustheit und ein paar Dutzend weitere (Abb.  1). Die Wortwolke habe ich übrigens mit Jason Davies’ Generator [4] erzeugt.

… und ein Haufen Probleme

An dieser Stelle trifft uns die Subjektivität von Qualität: Unser IT-Security-Officer oder die Datenschutzbeauftragten priorisieren garantiert das Thema IT-Sicherheit deutlich höher als den Bedienkomfort, die Reaktionsfreudigkeit (Snappiness) oder die Robustheit, die sich End-User sehnlichst wünschen. Ach ja – das Entwicklungsteam hätte gerne Verständlichkeit des Quellcodes und Nachvollziehbarkeit der Architekturentscheidungen sowie die Verwendung interessanter und moderner Technologien (die wiederum die Securityleute gar nicht gerne sehen, weil in modernen Technologien möglicherweise noch Securityrisiken schlummern, die in „langweiligen“ Old-School-Frameworks längst behoben sind). Zu guter Letzt fordert das Management dann für Entwicklung und Betrieb möglichst geringe Kosten …

Mit diesen unterschiedlichen Prioritäten und Wünschen ist es aber noch nicht genug: Die einen sagen Wartbarkeit, die nächsten Änderbarkeit oder Modifizierbarkeit. Dann kommt Anpassbarkeit ins Spiel – und Erweiterbarkeit. Und zu guter Letzt sagt noch jemand „Flexibilität“ dazu. Meinen jetzt alle das Gleiche, obwohl Sie unterschiedliche Begriffe verwendet haben? Sie sehen – selbst diese Diskussion kann schwierig werden.

Haben wir uns dann schließlich mit Stakeholdern auf eine Menge relevanter Eigenschaften (also die Dimension 1 von Qualität) geeinigt, so müssen wir jetzt die notwendigen oder gewünschten Ausprägungen (Dimension 2) festlegen – also diese Qualitätsanforderungen explizit und konkret formulieren. Wie das mit Hilfe von Qualitätsszenarien (Quality Attribute Scenarios [3]) funktioniert, zeige ich ausführlich in der nächsten Ausgabe dieser Kolumne. Leider liegen konkrete Qualitätsanforderungen im Projektalltag aus unterschiedlichen Gründen nur selten vor.

Kompromisse und Wunder

Ein auf niedrigen Energieverbrauch (etwa 5 kWh pro 100 km, oder 3 l Kraftstoff pro 100 km) optimiertes Fahrzeug kann nicht gleichzeitig auf eine hohe Anzahl von Sitzplätzen (etwa acht Personen) oder hohe Nutzlast (acht Tonnen Zuladung) ausgelegt sein. Tee ist entweder aromatisiert oder nicht. Im strikt limitierten Speicher eines Embedded-Onboard-Controllers kann ich keine langen Audiosequenzen mit hoher Abtastrate unterbringen. Ganz allgemein: Manche Kombinationen von Qualitätseigenschaften erschweren sich oder schließen sich sogar gegenseitig aus. In der Softwareentwicklung und -architektur müssen wir oftmals Kompromisse eingehen, weil wir nicht sämtliche Merkmale für alle Stakeholder passend erreichen können (es sei denn, Sie können Wunder vollbringen).