In Teil 1 und Teil 2 meiner Serie über Softwarearchitektur habe ich den Kern der Architektur und ihre Kommunikation via Sichten behandelt. Im abschliessenden Teil möchte ich auf die Bewertung von Softwarearchitekturen zu sprechen kommen. Audits oder Reviews finden in vielen Softwareprojekten erst gegen Ende der Umsetzung statt – viel zu spät also. Es lohnt sich meines Erachtens, bereits in frühen Entwicklungsphasen in die Bewertung zu investieren.
Das sich in Entwicklung befindende System kann auf zwei Arten bewertet werden: quantitativ (z.B. anhand des Sourcecodes) und qualitativ (z.B. anhand von Merkmalen der Architektur).
Quantitative Bewertung
Betrachten wir zuerst die quantitative Bewertung mittels Metriken:
- Statische Metriken: Der Quellcode kann unter anderem auf Kopplung (Grad der Verbundenheit der Systemkomponenten untereinander), Komplexität (cyclomatic complexity) oder Vererbungstiefe geprüft werden.
- Testmetrik: Die Testabdeckung kann ermittelt werden.
- Laufzeitmetrik: Performance-Eigenschaften (zum Beispiel Zeitbedarf und Ressourcenverbrauch) können gemessen werden.
- Prozess-Sicht: Der Änderungsaufwand, die Bugfix-Zeit sowie die Anzahl Bugs pro Baustein können quantifiziert werden.
Pragmatisch angewendet kann die Erhebung dieser Metriken durchaus sinnvoll sein und Hinweise geben, um die Qualität des Systems verbessern. Aus Erfahrung empfehle ich aber, nur wenige Metriken zu erheben – diese dafür kontinuierlich, um Veränderungen über die Zeit beobachten zu können. Ein besonderes Augenmerk verdient meiner Meinung nach die oben erwähnte Laufzeitmetrik: Performancezahlen und Ressourcenverbrauch liefern wertvolle Hinweise auf mögliche Probleme im System.
Qualitative Bewertung
Die qualitative Bewertung der Architektur dient einerseits zur Identifikation von Risiken, anderseits zeigt sie, inwiefern die Architektur das Erreichen von Qualitätsanforderungen ermöglicht oder – im schlechtesten Fall – behindert.
Bereits während der Anforderungsanalyse und der Entwurfsphase sollte man sich Gedanken zu den Qualitätsanforderungen machen. Denn deren Erreichung fallen nicht gratis als Nebenprodukt ab. Sie müssen explizite Entwurfsziele sein!
Die Norm DIN/ISO 9126 führt eine Reihe von Qualitätsmerkmalen auf:
.svg){kind=link}
Diese Qualitätsmerkmale alleine sagen allerdings noch wenig aus über das zu bauende System. Mit Hilfe von Szenarien können die Qualitätsanforderungen hingegen konkretisiert und präzisiert werden. Die ausformulierten Szenarien sind darüber hinaus auch noch geeignete Kommunikationsmittel gegenüber den diversen Stakeholdern.
Szenarien für das qualitative Bewerten
Es gibt zwei Haupttypen von Szenarien, für die ich kurze Beispiele gebe: Anwendungs- und Änderungsszenarien.
Anwendungsszenarien
- Merkmal Bedienbarkeit: «Der Benutzer oder die Benutzerin wird auf fehlerhafte Eingaben hingewiesen. Im Falle von Fehleingaben weist das System diese zurück und gibt eine passende Meldung dazu aus.»
- Merkmal Erlernbarkeit: «Ein Benutzer oder ein Benutzerin ohne Vorkenntnisse muss sich innerhalb von 15 Minuten soweit in der Applikation zurechtfinden, dass er bzw. sie die gewünschten Quartalsberichte erstellen kann.»
Änderungsszenarien
- Merkmal Anpassbarkeit: «Das System muss ohne Anpassungen am Code auch unter Windows betrieben werden können.»
- Merkmal Modifizierbarkeit: «Der Austausch des Payment-Moduls muss in weniger als 5 Personentagen umgesetzt werden können.»
Eine ausführliche Szenarienliste bietet arc42 an. Ich verwende sie gerne als Inspirationsquelle.
Die Szenarien und die Qualitätsanforderungen können in Konkurrenz zueinander stehen: Optimierungen der Performance des Systems können zum Beispiel zu Lasten von dessen Änderbarkeit gehen. Es ist daher wichtig, die Qualitätsanforderungen zusammen mit den Stakeholdern zu priorisieren und in der Dokumentation festzuhalten (Punkt 10 im arc42 Baukasten).
Die Bewertung der Architektur mit Einbezug von Szenarien findet nun wie folgt statt: Die priorisierten Szenarien und die Architekturziele bilden die Basis für den Bewertungsmassstab der betrachteten Softwarearchitektur. Die bewertende Person versucht unter anderem folgende Fragen zu beantworten um zu einer qualitativen Bewertung zu gelangen:
- Welche Vorkehrungen wurden in der Architektur getroffen, um Szenario X umsetzen zu können?
- Welche Kompromisse sind eingegangen worden?
- Welches sind die neuralgischen Punkte der Architektur (Elemente, die einen prägenden Einfluss auf die Qualitätsmerkmale haben)?
- Welche Risiken gefährden des Erreichen des Szenarios X?
- Welche Analysen (Proofs-of-Concept/POCs, Prototypen etc.) stützen die getroffenen Entscheidungen?
Im Anschluss an eine derart fundierte Bewertung können Massnahmen ergriffen werden, um die Risiken zu minimieren. Die Bewertung hat somit direkten Einfluss auf die Qualität der Architektur.
Mit diesem Blogpost kommt mein Exkurs zu Softwarearchitektur zum Ende. Hier die drei Beiträge nochmals in der Übersicht:
- Teil 1: Überblick, die «Gretchenfrage», das Ausgleichen von Zielkonflikten sowie die Rolle und die nötigen Kompetenzen des Softwarearchitekten bzw. der -architektin
- Teil 2: Handwerkliche Punkte und geeignete Werkzeuge, Verwenden von Sichten für die Kommunikation über Softwarearchitektur
- Teil 3: Diesen haben sie soeben gelesen
Leider konnte ich im Rahmen dieser kurzen Blogserie nicht alle Themen in der dafür notwendigen Tiefe behandeln – das gibt das Format einfach nicht her. Ich hoffe aber, dass ich Ihnen, einem potenziellen Neo-Softwarearchitekten oder -architektin, Impulse geben konnte, sich vertiefter mit dem Thema auseinanderzusetzen. Es lohnt sich!
Falls Sie noch Fragen rund um Softwarearchitektur oder andere IT-Themen haben, freue ich mich über eine Nachricht!