Kolumne: Knigge für Softwarearchitekten

Qualität

Peter Hruschka und Gernot Starke

Im Lehrplan des iSAQB e.V. besitzt Qualität einen hohen Stellenwert – der Lehrplan widmet ihr ein eigenes Kapitel. Grund genug, Ihnen das Thema näher zu bringen.

My Way

In manchen Projekten beschränken sich die Abnahmekriterien auf rein funktionale Eigenschaften. Sicherlich gibt es Fälle, in denen die reine Funktion von Software den Kunden, Auftraggebern und Anwendern bereits genügt. Wir vermuten jedoch, dass in vielen Fällen zusätzliche Anforderungen an die Systeme bestehen. Qualität ist mehr als nur Funktion! Merkmale wie Sicherheit, Robustheit, Zuverlässigkeit, Bedienbarkeit oder Effizienz setzen Kunden oder Auftraggeber oft als selbstverständlich voraus, ohne sie ausdrücklich zu fordern oder gar zu spezifizieren. Daraus leiten (schlechte) Projektleiter, Softwarearchitekten oder Entwickler dann die (schlechte) These ab: „Hauptsache, es läuft“.

Von X-heiten und Y-keiten

Um Sie auf den Einfallsreichtum typischer Stakeholder jenseits der Funktionalität vorzubereiten, möchten wir Ihnen einige weitere Qualitätsanforderungen aufzählen (Kasten: „Qualitätsanforderungen“). Sie werden zwei Dinge feststellen: Erstens gibt es viele davon, zweitens enden die meisten auf *heiten oder *keiten (im englischen *ilities).

Qualitätsanforderungen

 
Absturzsicherheit, Administrierbarkeit, Angemessenheit, Anpassbarkeit, Antwortzeit, Auditierbarkeit, Ausfallsicherheit, Austauschbarkeit, Bedienbarkeit, Benutzbarkeit, Betreibbarkeit, Datensicherheit, Durchsatz, Effizienz, Erlernbarkeit, Erweiterbarkeit, Fehlertoleranz, Flexibilität, Genauigkeit, Installierbarkeit, Integrität, Interoperabilität, Kompatibilität, Konfigurierbarkeit, Konsistenz, Korrektheit, Lokalisierbarkeit, Modifizierbarkeit, Nichtabstreitbarkeit, Nichtangreifbarkeit, Normgerechtigkeit, Ordnungsmäßigkeit, Personalisierbarkeit, Prüfbarkeit, Reaktionszeit, Reife, Richtigkeit, Robustheit, Sicherheit, Skalierbarkeit, Startup-Zeit, Testbarkeit, Überprüfbarkeit, Verfügbarkeit, Verständlichkeit, Wartbarkeit, Wiederherstellbarkeit, Zugriffsschutz, Zuverlässigkeit
Qualität hat viele Gesichter

Von vielen Qualitätsmodellen für Software hat sich insbesondere DIN/ISO 9126 in der Praxis durchgesetzt. Es unterteilt die Qualität von Software in sechs große Bereiche, die jeweils durch so genannte Teilmerkmale noch weiter differenziert werden. Das zentrale Konzept lautet also schrittweise Verfeinerung: ein großes Problem (hier: die Definition der Qualität eines Softwareprodukts) in viele kleine Probleme (hier: Teilmerkmale) zu zerlegen, die einzeln leichter lösbar sind. Der Standard gibt prägnante Definitionen dieser Begriffe vor, sodass auch Nicht-IT-ler damit leicht arbeiten können. Wikipedia hilft weiter [1].

Abb. 1: Teil des Qualitätsbaumes von ISO 9126
Qualität ist Geschmackssache

Endbenutzer haben meist andere Wünsche als Manager, und Betreiber oder Administratoren fordern wiederum ganz andere Dinge. Nun bietet das ISO-9126-Modell schon eine gute Grundlage, diese vielfältigen und teilweise widersprüchlichen Ziele zu erfassen. Organisationen oder Menschen verwenden allerdings für ihre spezifischen Qualitätsanforderungen auch eigene Bezeichnungen, die von der ISO-Norm oft abweichen:

  • Viele bevorzugen den Begriff Performance gegenüber der (standardkonformen) Effizienz. Darunter fallen oftmals Verfeinerungen wie Durchsatz, Daten- oder Transaktionsvolumen, Maskenwechselzeit oder Durchlauf- und Startzeiten.
  • Die (ISO-)Übertragbarkeit heißt in der Praxis meistens Portabilität – und bezieht sich ganz konkret auf die Möglichkeit, das betreffende System unter verschiedenen Betriebssystemen oder Hardwareumgebungen verwenden zu können.
  • Kosten als Qualitätsmerkmal sind insbesondere für Management-Stakeholder oftmals von zentraler Bedeutung – wichtiger als Benutzbarkeit oder Übertragbarkeit.
  • Das (ISO-)Submerkmal Sicherheit gilt bei Informationssystemen vieler Branchen als eine Top-Level-Qualitätsanforderung, die ihrerseits wieder in Zugriffsschutz, Unverfälschbarkeit, Nichtangreifbarkeit und/oder Nichtabstreitbarkeit verfeinert wird.

Wir empfehlen, zuerst diese Anforderungen explizit zu machen. Unserer Erfahrung nach hapert es in der Praxis meistens an den nicht funktionalen Anforderungen. Die wichtigsten Abläufe (Use Cases, Funktionen) des Systems bekommen Sie in der Regel in brauchbarer Form vorgegeben.

Architekturbewertung als Daueraufgabe

Die Qualitätsanforderungen bilden nur eine Seite der Medaille: Sie müssen diese Anforderungen auch durch konstruktive Maßnahmen erreichen! Ob diese die gewünschten Effekte auf die Qualität Ihrer Systeme zeigen, müssen Sie kontinuierlich überprüfen. Wir haben qualitative Bewertungsmethoden, insbesondere ATAM (Architecture Tradeoff Analysis Method [2], [4]) dafür kennen und schätzen gelernt. Sie sollten von Zeit zu Zeit gemeinsam mit dem Entwicklungsteam solche Qualitäts-Reviews durchführen.

Fazit

Erklären Sie Qualität im Team zum obersten Ziel (sofern nicht bereits geschehen!). Definieren Sie zuerst mit Unterstützung der maßgeblichen Stakeholder möglichst spezifische Qualitätsziele auf Basis eines spezifischen Qualitätsbaumes und davon abgeleiteter Szenarien. Entwickeln Sie anschließend für alle Szenarien konkrete Maßnahmen, die diese Qualitätsanforderungen erfüllen helfen. Meist werden Sie mehrere Maßnahmen benötigen, um ein einzelnes Qualitätsmerkmal zu erreichen. Achten Sie darauf, welche Qualitätsmerkmale sich gegenseitig negativ beeinflussen.

Es gibt keinen Algorithmus zum Entwurf von Software. An einige erprobte, methodische Ansätze haben wir Sie in diesem Artikel erinnert. Kaum einer davon funktioniert immer, aber die Ansätze können sich gegenseitig wunderbar ergänzen. Wir sind Fans des Domain-driven Design – ergänzen es aber mit einem besonderen Augenmerk auf die notwendigen Qualitätsziele.

Der iSAQB-Lehrplan

Kapitel 4 des iSAQB-Lehrplans handelt einerseits von Maßnahmen zur Erreichung bestimmter Qualitätsmerkmale in Softwaresystemen, andererseits vom methodischen Vorgehen zur qualitativen Bewertung von Softwarearchitekturen. Es gibt folgende Lernziele vor:

Können:

  • Trennung fachlicher und technischer Bestandteile in Architekturen begründen und den Begriff der Qualität (angelehnt an DIN/ISO 9126) erklären, ebenso Qualitätsmerkmale, Zusammenhänge und Wechselwirkungen von Qualitätsmerkmalen erläutern.
  • Qualitative Bewertung von Softwarearchitekturen nach ATAM durchführen, insbesondere Erstellen von Qualitätsbäumen und Szenarien. Selbständige Analyse von Softwarearchitekturen hinsichtlich Szenarien und Identifikation entsprechender Risiken.
  • Bewertung von Softwarearchitekturen hinsichtlich ihrer Umsetzung in Quellcode (wurden Architekturvorgaben eingehalten)
Verstehen:

  • Zur Einschätzung und Bewertung können mehrere Artefakte und Medien herangezogen werden (etwa: Quellcode, Bugtracker, Dokumentation).
  • Taktiken, Praktiken und technische Maßnahmen können zur Erreichung der Qualitätsmerkmale verwendet werden.
  • Durch Prototypen kann die Erreichung von Qualitätsmerkmalen abgesichert werden.
Peter Hruschka (http://www.systemsguild.com) und Gernot Starke (innoQ-Fellow, http://www.gernotstarke.de) haben vor einigen Jahren www.arc42.de ins Leben gerufen, das freie Portal für Softwarearchitekten. Sie sind Gründungsmitglieder des International Software Architecture Qualification Board (http://www.iSAQB.org) sowie Autoren mehrerer Bücher rund um Softwarearchitektur, Softwareentwurf und Entwicklungsprozesse.
Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.