Architekturbewertung

Prüfung, ob eine Softwarearchitektur ihre Qualitätsziele erreichen kann. Qualitativ geschieht das nach ATAM in einem Workshop: Man sucht Risiken, Nicht-Risiken und Kompromisse anhand priorisierter Szenarien. Quantitativ helfen Metriken und Codeanalyse-Werkzeuge wie SonarQube, die aber nur die Struktur des Codes sehen.

Bewerten heisst vergleichen

Bewertung ist ein Soll-Ist-Vergleich: Die Qualitätsziele der Stakeholder sind der Massstab. Architekturen eignen sich besonders gut dafür, weil ihre Entscheidungen grosse Tragweite haben und oft unter Unsicherheit getroffen werden (Quelle - Effektive Softwarearchitekturen, Kap. 8, S. 317).

ATAM

Die Architecture Tradeoff Analysis Method stammt von Bass, Clements und Kazman. Ablauf nach dem Buch (S. 309–314):

1. Massgebliche Stakeholder bestimmen, neben dem Auftraggeber auch Endanwender und Betreiber.
2. Methode vorstellen: Es geht um Risiken und Massnahmen, nicht um Noten.
3. Geschäftsziele vorstellen, am besten durch den Auftraggeber selbst. Dabei gibt es oft Aha-Erlebnisse.
4. Architektur vorstellen, mit den wichtigsten Ansätzen.
5. Qualitätsbaum erstellen und mit Szenarien verfeinern. Die Stakeholder priorisieren die Szenarien nach geschäftlichem Nutzen (A wichtig, B mittel, C weniger wichtig). Die Priorität bestimmt nur die Reihenfolge der Bewertung; auch C-Szenarien werden umgesetzt (Softwarequalität, S. 312).
6. Analyse im kleinen Kreis mit den Architekten, beginnend mit wichtigen und schwierigen Szenarien. Leitfragen: Welche Entscheidungen und Ansätze unterstützen das Szenario? Welche Kompromisse ging man ein? Welche anderen Ziele beeinflusst das? Welche Risiken entstehen? Welche Analysen oder Prototypen stützen die Entscheidung? Einen Algorithmus dafür gibt es nicht; Erfahrung und auch subjektive Einschätzung sind gefragt (S. 313).
7. Ergebnis: Risiken, Nicht-Risiken, Kompromisspunkte und Ansätze.
8. Massnahmen gegen die Risiken definieren. Das gehört offiziell nicht mehr zu ATAM, aber zu jeder echten Bewertung.

Nebenwirkungen: Die Stakeholder präzisieren ihre Ziele, Entscheidungen werden transparent, die Dokumentation wird besser. Oft merken Auftraggeber erst hier, wie riskant manche ihrer Anforderungen sind. Schon ein Workshop von wenigen Stunden deckt kritische Risiken schneller auf als eine umfangreiche Codeanalyse (S. 314).

Metriken

Quantitative Bewertung misst Eigenschaften des Codes, etwa Grösse, Komplexität, Kopplung, Kohäsion und Testabdeckung (S. 315–316). Starkes Ratschläge:

• Codemetriken sagen nichts über Funktion und Laufzeitqualität. Deshalb kontinuierlich messen und den Verlauf beobachten.
• Metriken brauchen einen fachlichen und technischen Kontext, um vergleichbar zu sein.
• Möglichst wenige Metriken verwenden, sonst verschwinden wichtige Aussagen im Zahlendschungel.
• Abhängigkeiten bei jedem Build messen.
• Nur mit Metriken zu bewerten ist riskant, weil grundlegende strukturelle Schwächen unentdeckt bleiben können.

Werkzeuge

• SonarQube: frei nutzbar, Plug-ins für viele Sprachen. Speichert Ergebnisse über die Zeit („Time Machine“), findet doppelten und ungenutzten Code, prüft Coding-Styles, misst Komplexität, lässt sich in Builds einbinden (S. 317).
• Alternativen: PMD, FindBugs, CheckStyle, Structure101, SotoGraph und andere. Aber: „Grüne Ampeln bei Werkzeugen bedeuten nicht unbedingt glückliche Benutzer.“
• CodeMaat von Adam Tornhill verbindet die Geschichte des Codes aus der Versionsverwaltung mit seiner Komplexität und findet so kritische Hotspots (S. 317).

Gemessen werden kann weit mehr als Code (S. 315): geänderte Anforderungen pro Zeit, Testfälle pro Anforderung, mittlere Zeit bis zur Fehlerbehebung, Fehler pro Subsystem, Verhältnis von geschätzten zu benötigten Arbeitstagen.

Die Analyse des Codes gehört in aim42 zur Phase „Analyze“, ebenso ATAM.

Verwandt

• Softwarequalität – Qualitätsbaum und Szenarien als Massstab
• Softwarearchitektur – Bewerten als Aufgabe des Architekten
• aim42 – Bewertung als Teil der Verbesserung
• Softwaretest – Testabdeckung als Metrik
• Sicherheitsbewertung – Bewertung aus Sicherheitssicht
• Usability-Review – Expertenbewertung aus UX-Sicht