Architecting for Quality: Qualität methodisch herbeiführen (2/4)

Recap Teil 1

In Architecting for Quality (1/4) haben wir den oft schwammig verwendeten Begriff Qualität unter die Lupe genommen.

Qualität wird von verschiedenen Stakeholdern häufig unterschiedlich betrachtet. Gleichzeitig kann objektive Qualität aber nicht einfach eine Frage des Standpunkts sein. Sie muss methodisch herbeigeführt werden. Das ist enorm wichtig, denn Qualitätsanforderungen prägen eine Architektur häufig viel stärker als funktionale Anforderungen. Welches die relevanten Qualitätskriterien sind, hängt dabei vom individuellen System ab. Diese zu bestimmen, ist (zumindest Teil-)Aufgabe der Architekturdisziplin.

Zu Beginn dieses zweiten Teils werden wir den Qualitätsbegriff noch einmal genauer beleuchten: Qualitätsmodelle bringen Struktur ins Thema und helfen dabei, die wichtigsten Aspekte im Blick zu behalten.

Im Anschluss daran schauen wir uns das Vorgehensmodell für die Softwareentwicklung und das prinzipielle methodische Vorgehen beim Systementwurf an. Dies steckt auch den Rahmen für den Rest dieser Blogserie ab: In den weiteren Teilen werden wir also etwas tiefer in die einzelnen Entwicklungsphasen hineinschauen.

Qualitätsmodelle

Wenn wir uns im Sinne von Architecting for Quality methodisch mit Qualität auseinandersetzen wollen, dann ist der erste Schritt die Auswahl eines geeigneten Qualitätsmodells.

Ein Qualitätsmodell ist eine strukturierte Sammlung der relevanten Qualitätskriterien, die üblicherweise mittels einer Baumstruktur visualisiert werden. (Ich verwende die Begriffe „Attribut“ und „Kriterium“ synonym, auch wenn einige Normen dies anders tun. Meiner Meinung nach stiftet Letzteres aber mehr Verwirrung als dass es hilft). Die Kriterien sollten dabei klar und eindeutig definiert sein.

Die Wahl des Modells

Die bekanntesten Qualitätsmodelle für die Softwareentwicklung sind wohl durch die ISO 25010 gegeben. Das heißt nicht, dass diese Modelle immer die optimale Wahl darstellen. Für bestimmte Systeme fehlen eventuell wichtige Attribute oder sie sind nicht ganz passgenau: Beispielsweise sucht ein Microserviceentwickler unter Umständen verzweifelt nach „Skalierbarkeit“. Und „Sustainability“ im Sinne von CO₂-Fußabdruck und Green Software lässt sich leider auch nicht finden.

Die ISO 25010, wie auch jedes andere generische Qualitätsmodell (beispielsweise ein von einer Firma vorgegebenes Modell), stellt daher erst einmal einen guten Startpunkt dar und kann, wenn nötig und möglich, an eigene Anforderungen angepasst werden. Das sieht die Norm auch selbst so vor – Stichwort „tailoring“.

ISO 25010

Um das Ganze nun greifbarer zu machen, folgt ein kurzer Blick auf das Product Quality Model der ISO 25010.

Wir wollen uns nicht durch die einzelnen Qualitätskriterien hangeln. Das ist Aufgabe der Norm bzw. anderer Blogartikel (und zudem ziemlich trocken). Ein Hinweis aber: Die einzelnen Qualitätskriterien sollte man nicht nach eigenem Gutdünken interpretieren, sondern in der Norm nachschlagen. Damit werden Fehlerinterpretationen und folglich Missverständnisse vermieden.

Zum Abschluss dieses Absatzes eine persönliche Empfehlung: Ich bin kein Normenfetischist, aber zumindest von der ISO 25010 sollte jeder, der die Softwerkskunst ernst nehmen möchte, ein Exemplar verfügbar haben.

Qualität im Vorgehensmodell

Jetzt haben wir also ein Qualitätsmodell. Und nun?

Es dient uns einmal als eine Art Checkliste („Haben wir an alles Nötige gedacht?“). Vor allem aber ist es die Basis für sämtliche weiteren Aktivitäten im Vorgehen, bei denen wir Qualität genauer unter die Lupe nehmen wollen.

Wo wollen wir das? Wenn wir akzeptieren, dass Qualitätsanforderungen die Softwarearchitektur maßgeblich beeinflussen und wenn wir es ernst mit Architecting for Quality meinen, wir also „Qualität methodisch herbeiführen“ wollen – dann müssen wir Qualität während aller Phasen im Vorgehensmodell auf dem Schirm haben. Nicht nur das. Konsequent zu Ende gedacht, müssen wir sie kontinuierlich während des gesamten Produktlebenszyklus betrachten und entsprechende Maßnahmen treffen.

Selbstverständlich liegen nicht alle Phasen und Bausteine in der Hauptverantwortung der Architekturdisziplin. Aber auch während beispielsweise der Implementierung sollten Architekt*innen mit Rat und Tat zur Seite stehen.

Systementwurf: Eine Methodik

Nun aber noch einmal zur Kernaufgabe der Architekturdisziplin, dem Systementwurf. Wie kommen wir zu einem Entwurf, der nicht nur die Umsetzung der funktionalen Anforderungen ermöglicht und Constraints berücksichtigt, sondern die Qualitätsanforderungen ins Zentrum rückt?

Dazu betrachten wir das Ganze zunächst aus hoher Flughöhe, veranschaulicht durch die folgende Abbildung. In den weiteren Teilen der Blogserie werden wir die einzelnen Stationen dann genauer beleuchten.

 

Anforderungen

Bevor etwas entworfen werden kann, muss (zumindest in Teilen) feststehen, was gebaut werden soll. Das herauszuarbeiten, ist im Wesentlichen Aufgabe des Requirement Engineerings. Dennoch haben wir Architekt*innen hier ein Wörtchen mitzureden. Es ist unsere Aufgabe, die aufgestellten Anforderungen zu hinterfragen, offene Punkte zu klären, Lücken zu schließen und Konflikte sowie Risiken transparent zu machen.

Einflussfaktoren

Geschäfts- und Architekturziele, Anforderungen sowie Constraints bilden zusammen mit dem Erfahrungsschatz der Architekten den Pool an Eingangsdaten, aus dem die kritischen Einflussfaktoren herausgearbeitet werden. Eine Einflussfaktorenanalyse schafft anschließend die Grundlage für die Ableitung der passenden Entwurfsstrategien.

Entwurf, Dokumentation und Bewertung

Bei der Entwurfsarbeit helfen uns Taktiken, Prinzipien und Muster, auf die wir zurückgreifen können. Bevor es dann in Richtung Implementierung und Test geht, ist es enorm wichtig, die bisherigen Arbeitsergebnisse strukturiert zu dokumentieren. Unter anderem gibt uns dies die Möglichkeit, erste qualitative Bewertungen fundamentaler Entscheidungen rechtzeitig durchzuführen, schon bevor großer Aufwand in die Implementierung geflossen ist.

Der Kreis schließt sich

Aus der Implementierung schließlich gewinnen wir wichtiges Feedback. Denn wir nutzen sie, um die bisher getroffenen Architekturentscheidungen auf den Prüfstand zu stellen. Die Erkenntnisse daraus bilden zusammen mit (eventuell) neu eintrudelnden bzw. nachgeschärften Anforderungen die Basis für die nächste Iteration.

 

Mehr Informationen zum Thema Software Engineering findest du hier in unserem Kompetenzfeld.