Leichtgewichtige Software-Reviews mit LASR
Einführung in Lightweight Approach for Software Reviews (LASR)
Architektur-Reviews decken technologische Risiken und Schwächen in Software-Lösungen auf, arbeiten Stärken und Potenziale heraus und sichern Entscheidungen ab. Klassische Analyseansätze aus diesem Umfeld sind fundiert, kommen aber gerade in beweglichen Software-Vorhaben etwas schwergewichtig daher. Dieser Beitrag motiviert schlankere Review-Ansätze und stellt mit LASR ein konkretes Vorgehen vor, das Sie und Ihr Entwicklungsteam direkt anwenden können, um Ihre Situation zu bewerten – ohne große Vorbereitung und viele Beteiligte.
In der Software-Entwicklung schreiben wir eigenen, neuen Code. Wir verwenden aber auch Standard-Libraries, setzen Frameworks ein, vertrauen auf Basistechnologien und binden bestehende Lösungen an. In all diesen Elementen stecken konzeptionelle Ideen und in deren Zusammenspiel entstehen größere Muster, die ein Software-Produkt maßgeblich prägen. Will man ein zuverlässiges, performantes oder besonders sicheres System bauen, müssen die Konzepte hinter der implementierten Lösung (zueinander) passen. Diese Betrachtungsebene der Entwicklung bezeichnen wir als "Software-Architektur".
Software-Architektur ist teilweise willentlich und vorausschauend gestaltet. Teilweise entsteht sie zufällig und reaktiv. Es ist also genauso Teil Ihrer Architekturarbeit zu definieren, dass Sie und Ihr Team eine Microservice-Architektur bauen möchten, als auch zu erkennen, dass die implementierte Ausprägung davon nicht ausreichend gut funktioniert. Eventuell ist der zweite Teil – die Reflektion von eigenen Ansätzen, die Erkenntnis zu Stärken und Schwächen von eingesetzten Technologien etc. – sogar die wichtigere Architekturaufgabe. Software-Architektur ist keine reine Planungsdisziplin. Software-Architektur macht grundlegende Strukturen, Konzepte, Muster und technologische Richtungen diskutierbar und gestaltbar – begleitend zur Implementierung und als Reaktion auf Erfolge und Probleme. Bewertungsmethoden und Review-Techniken, die wiederkehrend und retrospektiv arbeiten, sind in der Software-Architektur folglich zentral.
Bekannte Methoden zur Bewertung der Software-Architektur
Methoden zur Bewertung von Software versuchen explizit anders zu arbeiten als die Implementierung der Software selbst. Während wir üblicherweise allein oder zu zweit vor einer IDE sitzen, sind Architektur-Reviews meist Gruppenprozesse. Während bei der Implementierung funktionale Anforderungen oder akute Probleme treiben, sind bei Reviews qualitative Zielsetzungen der Gesamtlösung häufigster Startpunkt. Damit soll ein "frischer" Blick gewährleistet werden und das Verlassen eingefahrener Denkmuster wird einfacher.
Die berühmteste Review-Methode ist ATAM – die Architecture Tradeoff Analysis Method. Von der Carnegie Mellon Universität in den frühen 2000er Jahren veröffentlicht [1], beschreibt sie ein workshopbasiertes Vorgehen. Fachliche Stakeholder und an der Umsetzung Beteiligte treffen sich, kondensieren die Zielsetzung und die momentane Architektur der Software in Präsentationen und brechen anschließend die Erwartungen auf qualitativer Seite detailliert herunter. Auf dieser Basis diskutieren die Teilnehmenden im Workshop, welche Konzepte hilfreich sind und welche Ansätze vielleicht Risiken oder Kompromisse mit sich bringen. Ergebnis sind Risiko-Cluster und die Erkenntnis, welche Zielsetzungen voraussichtlich erreicht werden bzw. in Gefahr sind.
Gerade im Zuge der agilen Bewegung wird ATAM häufig als schwergewichtig und verstaubt bezeichnet. Die Grundideen der Methode sind allerdings sehr stark und durchaus zeitlos. Stakeholder einzubinden, deren Erwartungen explizit zu machen und die Architektur in kleinen Häppchen unter dem Licht dieser Erwartungen zu diskutieren, ist in vielen Kontexten wertvoll. Die methodische Unterfütterung ist leider etwas "zeremoniell", die Begleitung aus Moderationssicht herausfordernd und Workshops mit vielen Beteiligten nicht unbedingt billig. Um den Methodeneinsatz zu rechtfertigen, muss folglich eine gewisse Fallhöhe vorhanden sein. Wer kleinere bis mittelgroße Software-Produkte reviewen, einen schnellen Eindruck von einer Lösung bekommen oder Reviews als stetiges Werkzeug verwenden möchte, sollte sich anderweitig umsehen.
Ein Review-Ansatz mit sehr schnellen Ergebnissen ist das Pre-Mortem[2]. Dabei blicken die Teammitglieder aus einer hypothetischen Zukunft auf das aktuelle Vorhaben zurück. In dieser Zukunft ist die Software gescheitert und die Beteiligten suchen direkt nach Gründen dafür. Ohne vorbereitete Präsentationen, analytische Aufbereitungen oder sonstige Umschweife begibt sich das Pre-Mortem also direkt auf Problemsuche. Unserer Erfahrung nach saugt das Pre-Mortem sehr schnell vorhandene Bedenken aus den Köpfen der Beteiligten und schafft mit dem spielerischen Setting ein anregendes Brainstorming-Umfeld. Die Zielorientierung leidet dabei etwas.
Tabelle 1: Die Review-Ansätze ATAM und Pre-Mortem im Vergleich
| ATAM | Pre-Mortem | |
| Urheber oder Quelle | Software Engineering Institute der Carnegie Mellon University [1] | Gamestorming Playbook (D. Gray, S. Brown, J. Macanufo) [2] |
| Stimmung oder „Tonart" | akademisch fundiert | spielerisch leicht |
| Aufhänger oder Zugang | Qualitätsziele, heruntergebrochen in Szenarien | "Zeitreise" zum gescheiterten Vorhaben |
| Typische Art und Dauer der Durchführung | Mehrere moderierte Workshops, Laufzeit 2 Tage bis mehrere Wochen | einmaliger Workshop von ca. zwei Stunden |
| Übliche Beteiligte | Entwicklungs- und separates Bewertungsteam, weitere Stakeholder | Entwicklungsteam, ggf. plus Moderation |
| Typisches Ergebnis | Risiken und Kompromisse, Einschätzung bzgl. Erreichen der Ziele., oft ein formaler Ergebnisbericht | Risiken gesammelt aus Brainstorming To-dos und erste Mitigierungs-Ideen |
Tabelle 1 stellt die beiden Review-Ansätze gegenüber. Während ATAM am fundierten Ende der Methodenskala steht, ist das Pre-Mortem eher formlos. Überraschungen sind seltener, Impulse kommen nicht durch die Methode selbst, sondern nur durch die Beteiligten und der Fokus liegt eher auf präsenten Problemen als auf grundlegenden Zielsetzungen. Damit ist das Pre-Mortem eine nette Idee für Entwicklungsteams, die ihre Arbeit reflektieren wollen, aber eher kein Instrument für kritische oder politisch schwierige Situationen.
LASR – Ein leichtgewichtiger Review-Ansatz
Eine Methode, die sich sowohl bei Pre-Mortems als auch bei ATAM Anleihen nimmt, ist LASR – der Lightweight Approach for Software Reviews [3]. Abb. 1 zeigt den Ablauf mit seinen zwei Kernaktivitäten und den zugehörigen vier Schritten. LASR erarbeitet zunächst eine schlanke, individuelle Zielsetzung für die betrachtete Software. In Schritt 3 ("Basis-Review") ist dann ein dem Pre-Mortem ähnlicher Bewertungsansatz zu finden, wobei ideengebende Risikokarten zum Einsatz kommen. Die am Review Beteiligten führen erkannte Risiken auf Qualitätsziele zurück und analysieren anschließend bei Bedarf tiefer. Dieser Schritt 4 erinnert an ATAM, wendet zielorientierte Durchsprachen allerdings nur in Bereichen mit hoher Unsicherheit an und nicht in voller Breite.
Damit schafft LASR einen Ansatz, der kostengünstig genug ist, um ihn wiederholt anzuwenden, aber doch fundierter und abwechslungsreicher arbeitet als ein Pre-Mortem. Werden aus Review-Ergebnissen große Investitionen abgeleitet, ist eine moderne Interpretation von ATAM wahrscheinlich die bessere Idee. Unserer Erfahrung nach sind jedoch 80 Prozent der Review-Anlässe anderer Natur.
LASR an einem Vormittag
Schauen wir uns LASR genauer an und stellen uns dazu ein konkretes Vorhaben vor! Das Entwicklungsteam baut innerhalb seiner Organisation ein neues Software-System. Es hat bereits einige Sprints durchgeführt und erste Erfahrungen mit (für sie) neuen Tools und Technologien gesammelt. Nun möchte es die aktuellen Architekturideen, die sich langsam festigen, im Rahmen eines Reviews absichern. Leitfrage des Teams: Sind wir auf dem richtigen Weg?
Leichtgewichtige Reviews zeichnen sich durch eine geringere Anzahl erforderlicher Beteiligter, weniger nötige Vorarbeiten und eine kürzere Dauer aus. Den letzten Punkt illustriert eine mögliche Agenda für den Review-Workshop des Teams, angesetzt auf einen Vormittag (s. Abb. 2).
Der erste Agenda-Block entspricht dabei der blauen Aktivität in Abb. 1 – "Verstehe, was Dich speziell macht". Es geht darum, das zu beleuchtende System greifbar zu machen und aus dieser Essenz – wir nennen es "Schlankes Mission-Statement" – im Anschluss einen pointierten und zugleich individuellen Bewertungsmaßstab abzuleiten.
Schlankes Mission-Statement (Schritt 1)
Gut gemachte Landing Pages porträtieren Software-Lösungen auf prägnante Art und Weise. Abb. 3 zeigt als Beispiel die Startseite des mobilen Instant-Messengers Threema[4]. Landeseiten stellen durch knackige Slogans und knappe Aussagen zentrale Features und besondere Eigenschaften heraus. Was ist unser Anspruch (Claim), was wollen wir mit dem Software-System erreichen?
In unserem Workshop stellt sich das Entwicklungsteam zum Einstieg in das Review vor, wie eine Landing Page für sein System aussähe. Es trägt Kandidaten für Claims des zu betrachtenden Systems in einem kurzen Brainstorming zusammen. Und clustert und verdichtet diese im Anschluss zu einer Liste von 7+/-2 Punkten. Was sollte auf jeden Fall auf unsere Startseite? Eine solche Session dauert straff moderiert 15 bis maximal 20 Minuten. Für Threema könnte das Ergebnis im Anschluss Punkte wie diese enthalten:
- Mobile-App verfügbar für Android und iOS-Geräte
- Schutz der Privatsphäre stets gewährleistet
- zuverlässiger Versand der Nachrichten und Medien
- Identität eines Kommunikationspartners zweifelsfrei feststellbar.
Innerhalb des Workshops verwendet das Team nicht lange auf das Ausformulieren des Mission-Statements. Wenn es den Ablauf nicht sprengen will, ist diese Zeit in den folgenden Schritten besser investiert. Gleichzeitig ist wichtig, dass alle Beteiligten unter dem Review-Gegenstand dasselbe verstehen. Im Beispiel von Threema etwa, ob wir nur die Apps betrachten wollen oder auch das Threema-Backend.
Bewertungsmaßstab (Schritt 2)
Kern des Reviews ist die Frage, ob wir mit unserem Software-System die gesetzten Ziele erreichen. Oder umgekehrt, was dem im Weg stehen könnte (Hindernisse, Risiken). Um die wichtigsten Ziele explizit zu machen, arbeiten wir im nächsten Schritt die Top 3 bis max. Top 5 inkl. eines Zielwertes als Bewertungsmaßstab heraus. Wir halten ihn in einem Netzdiagramm fest, welches später auch das Review-Ergebnis visualisiert. Abb. 4 zeigt eine solche Spinnennetzgraphik für die fünf Top-Ziele von Threema.
Wie kommt ein Entwicklungsteam an diese Ziele (die Achsen) und die Zielwerte (markiert mit der grünen Linie)? Wir gehen von den in Schritt 1 gefundenen Claims als Inspiration aus und fokussieren im Workshop auf für uns zentrale qualitative Eigenschaften der Software wie Benutzbarkeit oder Wartbarkeit.
Für die eigentliche Auswahl setzen wir auf eine spielerische Technik, die wir "Top-5-Challenger" nennen. In kleinen Gruppen bietet sie gute Anstöße für Diskussionen. Als Unterstützungsmaterial verwenden wir dabei Spielkarten mit potenziellen Zielen. Wir haben gute Erfahrungen mit einem Kartensatz aus insgesamt 14 Qualitätsmerkmalen gemacht, angelehnt an den ISO/IEC-Standard für Produktqualität von Software [5], aber erweitert um häufig benötigte Zielsetzungen.
Zu Beginn mischen wir alle Karten und decken fünf zufällig als Startset auf. Die übrigen neun Karten liegen als Kandidaten für alle sichtbar offen aus. Der Mechanismus läuft dann rundenbasiert ab: Ein Teammitglied schlägt einen Kandidaten (den Challenger) vor und argumentiert, warum es diese Karte in den Top 5 sieht und welche aktuelle Karte dafür weichen muss. Nach kurzer Diskussion entscheidet das Team: Eine der Karten bekommt bzw. behält einen Platz in den Top 5, die andere landet auf dem Ablagestapel. Abb. 5 zeigt eine mögliche Spielsituation nach zwei Runden.
Nach einigen Runden stehen die Topziele und damit die Achsen unseres Spinnennetzes fest. Die grüne Ziellinie der Grafik (s. Abb. 4) ergibt sich aus den individuellen Ziel-Levels der Achsen. Eine Achse unterteilt sich in die Werte 0 (keine Erwartungen) bis 100 (das Maximum des Machbaren) und beschreibt, angelehnt an Prozentwerte, wie hoch die Erwartungen in einem Zielbereich sind. So liegen etwa übliche Ansprüche auf der Zielachse genau mittig (50) oder hohe Ansprüche, die im eigenen Kontext durchaus Innovation erfordern, bei 75.
Basis-Review (Schritt 3)
Blicken wir nun in Richtung Lösung. In einem Review interessieren uns vor allem Schwächen der Software, die dazu führen, dass wir wichtige Ziele verfehlen werden. Die wichtigsten Zielsetzungen kennt das Team bereits, nun ist die Frage: Welche Probleme können das Erreichen der Ziele verhindern?
Ein Pre-Mortem sucht völlig frei und direkt nach potenziellen Problemen. In LASR greifen wir aus unserem Erfahrungsschatz von mehr als 100 Reviews typische Risikothemen heraus und verwenden sie als Ideengeber. Ein Kartendeck illustriert diese Risiken und unterstützt das Entwicklungsteam im Workshop bei der Anwendung der Methode. Abb. 6 zeigt die acht Risikokategorien, in denen die LASR-Risikothemen organisiert sind sowie beispielhaft Themen für eine Kategorie als Spielkarten. Wir wählen interessante Kategorien aus, greifen zufällig zwei bis vier Risikothemen heraus und verteilen sie untereinander. Mit dieser Inspiration ausgestattet definiert ein/e Workshop-Teilnehmer/in nach dem/r anderen konkrete Risiken, die sie sich für die Software vorstellen können.
Bei Threema könnte in diesem Schritt das Risikothema "Einengende Standards oder Rahmenbedingungen" aus der Risikokategorie "Organisation & Prozesse" in der Hand eines Team-Mitglieds landen. Beim Betrachten der Karte entsteht eine Idee für ein potenzielles Problem: Was, wenn die europäische Gesetzgebung Messenger-Anbieter verpflichtet, sämtliche private Kommunikation und Dateien zu durchleuchten? Threema müsste daraufhin die Lösung für private Nutzer komplett neu denken und die aktuelle Lösung könnte scheitern!
Das konkret formulierte Risiko hält das Team im Workshop auf einem Post-It fest und schätzt es anschließend gemeinsam ein: Wie wahrscheinlich ist es, dass dieses Risiko eintritt? Wie groß wäre der Schaden? LASR sieht für beide Fragen eine dreistufige Einschätzung vor, die zu einem Punktewert führt. Eine hohe Eintrittswahrscheinlichkeit mit katastrophaler Schadenshöhe ergibt z. B. 20 Punkte.
Das Threema-Team einigt sich für das vorliegende Risiko auf eine mittlere Wahrscheinlichkeit und mittlere Schadenshöhe und landet bei acht Punkten. Aus diesen Punkten lässt sich anschließend eine Lücke in der Spinnennetzgrafik ableiten. Hierfür werden Risiken den Qualitätsachsen zugeordnet, aufsummiert und die Summe als prozentuale Abweichung eingezeichnet. 36 Punkte würden also 36 Prozent negative Abweichung vom in Schritt 2 (Bewertungsmaßstab) eingezeichneten Zielwert bedeuten. Abb. 7 zeigt ein LASR-Ergebnisdiagramm mit eingezeichneten Abweichungen ("Lücken"), wie es nach dem Schritt 3 (Basis-Review) aussehen könnte.
Zielorientierte Analyse (Schritt 4)
Ein erstes Ergebnis von LASR entsteht mit Schritt 3 und durch Risikokarten unterstützt schnell. Die eingezeichneten Lücken sind jedoch recht "mechanisch" entstanden und müssen nicht korrekt sein. Mit der zielorientierten Analyse in Schritt 4 von LASR kann das Team das vorliegende Ergebnis verbessern.
Zunächst wählt es Zielachsen aus, deren Ergebnisse strittig sind oder nicht passend wirken. Im oben gezeigten Ergebnis des Basis-Reviews hat das Team offenbar keine Risiken im Bereich Kompatibilität und Benutzbarkeit erkannt. Vielleicht löst das bei einer dieser Achsen ein ungutes Bauchgefühl aus. Vielleicht wirkt die eingezeichnete Lücke bei Zuverlässigkeit zu groß oder zu klein. Bei der zielorientierten Analyse nutzen wir solche "Befindlichkeiten" als Treiber.
Sind die Zielachsen zur Analyse identifiziert, besprechen wir sie Achse für Achse:
- Schärfung der Zielachse: Konkrete Qualitätsaussagen sammeln und deren Wichtigkeit einschätzen
- Zielerreichung Top-Down prüfen: Relevante Lösungsaspekte finden und besprechen
- Bestehende Schwächen zuordnen: Relevante Probleme in Code, Test und im Kontext finden
- Lückeneinschätzung aktualisieren: Lösungsaspekte und Probleme einschätzen und auf die Zielachse mappen
Die Besprechung von Qualitätsaussagen ähnelt dem Bewertungsansatz von ATAM, allerdings sprechen wir in LASR gesammelt über die Qualitätsaspekte einer Zielsetzung und legen die Erkenntnisse direkt auf das Review-Ergebnis um. Zur Unterstützung dieses Schritts bietet LASR auch ein Besprechungstemplate an [6].
Mit LASR die Konfidenz noch weiter erhöhen
Das griffigste Resultat der LASR-Schritte 1-4 ist das Ergebnisdiagramm (Spinnennetz, s. Abb. 8) mit den Abweichungen in der Zielerreichung. Diese Lücken lassen sich auf die im Pre-Mortem und ggf. anschließend in der zielorientierten Analyse identifizierten Risiken zurückführen und erklären. Das schlanke Review konnte die Unsicherheit im Team verringern; das Ergebnis zeigt eine Richtung für weitere Entwicklungsarbeiten an der Softwarelösung auf.
An dieser Stelle kann das Team die Review-Aktivität beenden und in vielen Fällen ist das auch sinnvoll. Das Team adressiert die gefundenen Risiken und ergreift geeignete Verbesserungs- oder Minderungsmaßnahmen. Das Kern-Review von LASR liefert genügend Futter, um die Software umzubauen, technische Schulden zu beseitigen oder Lösungsansätze mit größerem Vertrauen weiterzuverfolgen.
LASR bietet jedoch auch die Möglichkeit, das Review weiter zu treiben und die Software tiefer zu analysieren. Dieser zweite Modus heißt "Konfidenzerhöhung", da er die Aussagekraft und damit das Vertrauen in das Ergebnis steigert.
Hierzu gibt es typische Anlässe:
- Gefundene Risiken sind in ihrer Natur oder Auswirkung zu wenig verstanden, um direkt hilfreiche Aktivitäten daraus abzuleiten ("Hängt da noch mehr dran?").
- Die Priorisierung der identifizierten Probleme ist schwierig, ggf. fehlt es bei kleinteiligen Ergebnissen an Überblick oder Einordnung ("Wo fangen wir an?").
- Die Architekturebene wird als zu abstrakt für die tatsächlichen Probleme des Vorhabens wahrgenommen ("Wo ist der Code?").
- Der Fokus auf max. 5 Qualitätsziele wirkt problematisch ("Ist nicht auch XY wichtig?").
- Rahmenbedingungen (z.B. Standards) oder die eigene Organisation wurden als Risikofaktor zu wenig betrachtet ("In der Theorie OK, aber was ist mit ...?").
Um die beschriebenen Unsicherheiten auszuräumen, ist ein "geordneteres" Vorgehen nötig, als in den ersten LASR-Schritten (1-4) gelebt. Gesprächspunkte müssen hergeleitet werden und dürfen nicht zufällig entstehen, Ergebnisse sind systematisch abzulegen. LASR verdichtet und ordnet die bisherigen Ergebnisse also zunächst (Schritt 5) und ergänzt diese dann analytisch fundierter in den Schritten 5 bis 8.
Tabelle 2 zeigt die Analyse-Schritte der Konfidenzerhöhung in LASR inklusive ihrer jeweiligen Anlässe, Aktivitäten und Ergebnisse.
Tabelle 2: Konfidenzerhöhung in LASR (Schritte 5-8)
| Schritt | Motivation, Anlässe ("Wann machen?") | Aktivitäten ("Was tun?") | Ergebnisse |
5. Systematisierung | bisherige Ergebnisse wirken unübersichtlich oder kleinteilig Verdacht, dass wichtige Lösungsaspekte nicht beleuchtet wurden | Ergebnisse aus LASR Schritten 1-4 systematisieren Erkenntnisse zur Software (Aufgabenstellung und Lösung) schlank aufbereiten | Qualitätsbaum, ergänzt mit neuen Qualitätsaussagen Konsolidierte Risiken prägnanter Architekturüberblick mit Lösungsstrategie |
6. Werkzeug-gestützte Prüfung | Lücken im Ergebnis, wo Messungen deutlich zur Klarheit beitragen bisher nur oberflächliche Betrachtung der Implementierung | Quelltext mit Strukturmodellen abgleichen Gezielte Messungen durchführen (z.B. Performance) Zahlen aus dem Betrieb heranziehen (z. B. Monitoring) | quantifizierte Zielabweichungen Klare Mismatches zwischen Architektur und Umsetzung |
7. Gültigkeits-Check | in früheren Schritten offenbarter Verdacht zu verletzten Vorgaben | zentrale Rahmenbedingungen erheben und bewerten Lösung bezüglich dieser Themen beleuchten | Konformität zu relevanten Rahmenbedingungen, bzw. Verletzungen derselben |
8. Fitness-Check der Organisation | Verdacht, dass die Lösung nicht zur Struktur oder Kultur der Organisation passt | Software- und Teamstruktur abgleichen ("Conway‘s Law") Eignung der Software-Architektur für die bestehende Entwicklungspraxis prüfen Übereinstimmung von Markt-/Domänendynamik mit Entwicklungsdynamik abklären | Aussagen zur Passung von Architektur und Organisation ggf. Risiken kultureller und soziotechnischer Art |
Schritt 5 von LASR heißt "Systematisierung" und macht folgende Dinge explizit (als Rohergebnisse liegen sie größtenteils bereits aus den Schritten 3 und 4 vor):
- Risikoliste: die bisher gefundenen Risiken mit Zuordnung zu den betroffenen Qualitätsmerkmalen (Liste)
- Lösungsstrategie: eine Zuordnung der wichtigsten identifizierten Lösungsansätze zu den Qualitätszielen (Tabelle)
- Qualitätsbaum: Qualitätsmerkmale (auch über die Top-5 Qualitätsziele hinaus) mit konkreten Qualitätsaussagen ergänzt
- Architektur-Überblicksdiagramm: ein Übersichtsbild, das die Software mit ihren zentralen Nutzergruppen und Fremdsystem zeigt und die Ansätze aus der Lösungsstrategie prägnant widerspiegelt (informelle Graphik).
Schon in dieser systematischen Aufarbeitung können Erkenntnisse stecken. Wichtige Qualitätsziele sind ggf. nur dürftig von Architekturansätzen unterstützt, Sie und Ihr Team entdecken relevante Basisanforderungen oder sind sich nicht einig, was die aktuelle Lösungsidee eigentlich ist. Beispiele für einige der obigen Artefakte finden Sie im Architektur-Porträt zu Threema [7].
In Schritt 6 durchleuchtet das Team die Lösung mithilfe von statischen und dynamischen Analyse-Werkzeugen. Einerseits, um Architekturideen, wichtige Konzepte und Strukturen auf Code-Ebene zu prüfen, andererseits, um Bauchgefühl aus dem Basis-Review mit belastbaren Metriken oder Messungen zu belegen.
Schritt 7 heißt "Gültigkeitscheck" und stellt sicher, dass die Lösung alle relevanten Rahmenbedingungen einhält. Der abschließende Schritt 8 "Fitness-Check der Organisation" bringt die Softwarelösung mit Struktur, Methodik und Kultur der Organisation in Verbindung. Beide Schritte sind in LASR in der Aktivität "Erkunde die Umgebung" zusammengefasst. Sie sollen sicherstellen, dass nicht nur eine gute Architekturidee oder Teillösung vorhanden ist, sondern dass Sie und Ihr Team diese auch umsetzen können.
Zusammenfassung und Ausblick
ATAM ist der bekannteste Bewertungsansatz für Software-Architektur. Er fokussiert auf die zielorientierte Analyse und bindet größere Gruppen an Beteiligten (und ggf. sogar externe Stakeholder) ein. Das wirkt schwergewichtig, kann in manchen Situationen aber auch ein guter Weg sein. Leichtgewichtige Reviews kommen im Vergleich mit weniger Beteiligten aus, benötigen geringere bis keine Aufwände in der Vorbereitung und analysieren schlanker. Speziell LASR liefert ein sehr rasches erstes Ergebnis (in Schritt 3). Im Gegensatz zum ebenfalls leichtgewichtigen Pre-Mortem liefert LASR mehr Rahmen, um auch überraschende Architekturprobleme aufzuspüren und zeigt einen klaren Weg in Richtung fundierterer Analyse. LASR schießt also in eine sehr breite Lücke, ersetzt die anderen Methoden aber nicht.
Der "Sweet Spot" für LASR sind teamgetriebene Reviews mit zwei bis vier Beteiligten, die gewonnene Ergebnisse auch selbst weiterverarbeiten wollen. Architektur- und Methodikverständnis sollten in Grundzügen bei allen vorhanden sein. Für die fundierte Bewertung großer Entwicklungsvorhaben und/oder politisch aufgeladener Situationen raten wir eher zu extern begleiteten ATAM-ähnlichen Bewertungsverfahren. Für ein wenig Abwechslung im Sprint und die Einordnung bekannter Risiken reicht ein Pre-Mortem.
Wollen Sie LASR selbst ausprobieren, dann finden Sie in [6] reichhaltiges Unterstützungsmaterial. Alle Qualitätszielkarten und Risikothemen, "Spielpläne" und Vorlagen für die LASR-Ergebnisgrafik stehen dort frei zum Download zur Verfügung. Für einen tieferen Einstieg empfiehlt sich das Buch zu LASR [3].
- Rick Kazman, Mark Klein, Paul Clements: "ATAM: Method for Architecture Evaluation", Technical Report CMU/SEI-2000-TR-004, Carnegie Mellon University 2000
- Dave Gray, Sunni Brown, James Macanufo: "Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers", O'Reilly, 1. Auflage 2010
- Homepage LASR: A Lightweight Approach for Software Reviews
Stefan Toth, Stefan Zörner: Software-Systeme reviewen mit dem Lightweight Approach for Software Reviews, E-Book, Leanpub 2023 - Webseite Threema
- International Organization for Standardization (ISO): "Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model", ISO/IEC 25010:2023(E), 2023
- Unterstützungsmaterial zu LASR, insbesondere Kartensets zum selber ausdrucken oder bestellen
- Stefan Zörner: Architektur-Porträt: Der mobile Instant-Messenger Threema, IT Spektrum, Heft 4/2023
