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

Recap Teil 2

Im zweiten Teil dieser Serie mit dem Thema Architecting for Quality ging es zu Beginn um Qualitätsmodelle (u.a. ISO 25010). Die Auswahl eines Qualitätsmodells ist Grundlage für das gesamte weitere methodische Vorgehen und daher entsprechend bedeutend. Im Anschluss daran haben wir uns mit aufgesetzter Architektenbrille den gesamten Softwareentwicklungszyklus angeschaut und eine zeitgemäße Methodik für den Systementwurf vorgestellt.

Dieser dritte Teil soll nun die Anforderungsseite etwas genauer beleuchten: Wir schauen uns zuerst an, wie wir Qualität bei der Anforderungsanalyse berücksichtigen können. Der zweite Abschnitt soll dann der Einflussfaktorenanalyse gewidmet sein, die eine zentrale Rolle in der methodischen Architekturarbeit einnimmt.

Qualität in der Anforderungsanalyse

Wie in Teil 2 schon beschrieben, müssen wir auch als Architekten beim Thema Anforderungsanalyse ein gehöriges Wörtchen mitreden können. Und wenn wir Qualität als treibenden Faktor betrachten, so müssen wir wissen, wie wir dies anforderungsseitig tun.

„Nichtfunktionale“ Anforderungen“ → Qualitätsanforderungen

Anforderungen werden gerne unterteilt in funktionale und nichtfunktionale Anforderungen. Zumindest letztere Bezeichnung finde ich extrem unglücklich. Ich bin mir sicher, dass manches Unterbewusstsein damit etwas Unnützes, Negatives assoziiert, denn begrifflich liegen die Wörter funktional und funktionell ziemlich eng beeinander. Der Wichtigkeit dieser „nichtfunktionalen Anforderungen“ ist die potenzielle Assoziationskette „nichtfunktional“ → „nicht funktionell“ → „nicht die eigentliche Funktion erfüllend (also nicht funktionierend)“ leider alles andere als dienlich.

Ich schlage also vor, den Begriff „nichtfunktionale Anforderungen“ ein für allemal zu streichen. Stattdessen reden wir ab sofort nur noch über Qualitätsanforderungen.

Qualitätsszenarien

Wie können wir Qualitätsanforderungen nun formulieren?

In der Realität sehen wir regelmäßig Aussagen im Stil von „Der Code soll erweiterbar sein“. Allerdings sind solche Anforderungen, die lediglich ein Qualitätsattribut nennen, maximal vage und unspezifisch. Qualitätsszenarien sind stattdessen das Mittel der Wahl – vergleiche ATAM (Architecture Tradeoff Analysis Method), arc42, etc.

Qualitätsszenarien sind kurze Beschreibungen, welche Qualitätsanforderungen konkretisieren. Sie folgen dem EVA-Prinzip, wie die folgende Abbildung schematisch veranschaulicht:

Das Ganze wird greifbarer, wenn wir uns ein konkretes Szenario anschauen:

Das konkrete Änderungsszenario aus dem Beispiel könnte etwas verknappt folgendermaßen formuliert werden: „Eine Änderung der Beitragsberechnung ist mit < 1 PT Aufwand realisierbar.“

In der Praxis zeigt sich, dass das Schreiben guter Szenarien meist nicht auf Anhieb gelingt, sondern Übung verlangt. Es sollte uns am Herzen liegen, in die Qualität von Qualitätsanforderungen (no pun intended) zu investieren, da diese letztendlich den Kern qualitätsgetriebener Architekturarbeit bilden und Architecting for Quality erst ermöglichen.

Quality Storming

Quality Storming ist eine Workshop-basierte Methode, um Qualitätsanforderungen zu erheben. Sie gehört zu den kollaborativen Modellierungstechniken, die vor allem im Bereich des Domain-driven Design sehr beliebt sind. In einem mehrstündigen Workshop erarbeitet eine heterogene Gruppe von Stakeholdern eine Liste konsolidierter, priorisierter Qualitätsanforderungen, idealerweise in Form von Qualitätsszenarien (Grundlage ist auch hierfür wieder ein vernünftiges Qualitätsmodell). Ganz im Sinne von Domain-driven Design dreht es sich bei Quality Storming also darum, ein gemeinsames Verständnis an das zu bauende System zu entwickeln – in diesem Fall eben mit besonderem Fokus auf den Qualitätsanforderungen.

Einflussfaktorenanalyse

Mittlerweile sollte deutlich geworden sein, dass zu den Einflussfaktoren auf eine Architektur nicht nur die funktionalen Anforderungen gehören. In Teil 1 haben wir festgestellt, dass Randbedingungen und ganz besonders die Qualitätsanforderungen an das System häufig einen stärkeren Einfluss haben. Letztere haben wir gerade genauer unter die Lupe genommen, mit Qualitätsszenarien als passendem Werkzeug.

Bei der Einflussfaktorenanalyse nutzen wir nun genau dieses Werkzeug, um kritische Faktoren zu präzisieren und messbar zu machen. Weiterhin werden diese Faktoren hinsichtlich Flexibilität, Veränderlichkeit und Einfluss analysiert, um sie anschließend zu priorisieren und passende Entwurfsstrategien abzuleiten. Nach der Implementierung kann schließlich gegen die (in den Qualitätsszenarien) definierten Metriken validiert werden. Diese Methodik beschreiben Hofmeister et al. unter dem Namen Globale Analyse.

Identifizieren

Zu Beginn sind die kritischen Einflussfaktoren zu identifizieren. Es geht also nicht darum, eine vollumfängliche Liste zu erstellen, sondern sich auf die wesentlichen Faktoren zu konzentrieren. Als Quelle dienen, wie in Teil 2 (Abbildung ‚Eine zeitgemäße Methodik für den Systementwurf‘) dargestellt, Geschäfts- und Qualitätsziele, Anforderungen, Constraints – sowie des Weiteren die Erfahrung des Entwicklungsteams.

Spezifizieren

Im Anschluss daran werden die kritischen Faktoren präzisiert und messbar gemacht; und zwar mit Hilfe von Qualitätsszenarien, wie im vorigen Abschnitt beschrieben. Die Globale Analyse schlägt auch eine Kategorisierung in technologische, organisatorische und Produktfaktoren vor. Dies entspricht mehr oder weniger der in Teil 1 vorgenommenen Kategorisierung (Abbildung ‚Einflüsse auf die Architektur eines Softwaresystems‘), wobei funktionale Anforderungen und Qualitätsanforderungen bei Hofmeister zu den Produktfaktoren zusammengefasst sind.

Analysieren

Nun geht es darum, die Faktoren hinsichtlich Flexibilität, Veränderlichkeit und Einfluss zu analysieren: Ist der Faktor verhandelbar? Welche Spielräume gibt es bei der Umsetzung? Muss mit Änderungen bei dem Faktor gerechnet werden, z.B. durch neue Anforderungen oder Technologien? Und wirkt der Faktor auf einen oder mehrere Bausteine oder auf andere Faktoren? Betrachtet man die verschiedenen Einflussfaktoren, so sind diese nicht alle komplett unabhängig voneinander: Manche dieser Faktoren unterstützen sich, andere stehen im Widerspruch zueinander. Bei der Strategieentwicklung müssen wir dies mit berücksichtigen.

Priorisieren

Davor macht es allerdings Sinn, die Einflussfaktoren zu priorisieren. Denn auch dieses Ergebnis sollten wir bei der nachfolgenden Strategieentwicklung mit einbeziehen.

ATAM schlägt die Priorisierung auf Basis eines Quality- bzw. Utility Trees vor. Für jedes Blatt des Baums (hier stehen die Qualitätsszenarien) werden zwei Dimensionen betrachtet:  Die Wichtigkeit der Qualitätsanforderung für den Erfolg des Systems und die Höhe des Risikos für deren Umsetzung. Eine Anforderung, die enorm wichtig für den Erfolg ist und deren Erfüllung gleichzeitig mit einem hohen Risiko verbunden ist, wird dementsprechend hoch priorisiert.

Obwohl ATAM eine Methode zur Architekturbewertung ist, zeitlich gesehen also erst später im Prozess eine Rolle spielt, können wir dieses Vorgehen natürlich wunderbar auf eine Einflussfaktorenanalyse übertragen (im Detail ist hier alles schön nachzulesen).

Strategien entwickeln

Aus der Gesamtbetrachtung kristallisieren sich zentrale Architekturthemen heraus, für welche wir Entwurfsstrategien entwickeln müssen. Dies ist die eigentliche Entwurfsarbeit. Dabei ist es entscheidend, rechtzeitig Konflikte transparent zu machen und mit den verschiedenen Stakeholdern zu thematisieren – mit dem Ziel, sie zu entschärfen und Kompromisse zu finden.

 

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