Architecture Analyse-Methode
Klärt Qualitätsziele, schätzt Risiken ein und untersucht wichtige Fragen zur Software gezielt.
LASR von Stefan Toth und Stefan Zörner führt in vier Schritten durch ein Software-Review. Zuerst klärt das Team den Zweck der Software und legt Qualitätsziele fest, etwa für Verfügbarkeit oder Änderbarkeit. Danach werden Risiken eingeschätzt. Ein Lückenprofil zeigt, wo der eingeschätzte Systemstand von den Zielen abweicht. Auffällige oder umstrittene Einschätzungen werden anschließend genauer untersucht.
Wie gut erreicht unsere Software ihre Qualitätsziele und welche Risiken sollten wir genauer untersuchen?
Die ersten drei Schritte liefern eine begründete Einschätzung. Im vierten Schritt untersucht ihr auffällige Qualitätsmerkmale genauer. Zusätzliche Messungen und Tests liefern die noch benötigten technischen Nachweise.
Auftrag
Ihr beschreibt, welchen Nutzen die Software bieten soll und welche Teile ihr betrachtet.
Maßstäbe
Ihr übersetzt den Systemzweck in wenige wichtige Qualitätsziele und ein gemeinsames Zielprofil.
Risiken
Ihr sammelt mögliche Ursachen für Probleme und schätzt deren Folgen für die Qualitätsziele ein.
Vertiefen
Ihr untersucht ausgewählte Qualitätsmerkmale genauer und aktualisiert das Profil anhand der Ergebnisse.
Aktualisiere Risiken und Lückenprofil nach jeder vertiefenden Analyse. Wiederhole das Review bei wesentlichen Änderungen am System oder an seinen Qualitätszielen.
Für Entwicklungsteams, die ihre Software kennen und gemeinsam die wichtigsten Qualitätsrisiken klären wollen. Du kannst LASR auch allein anwenden. Halte dabei fest, welche Annahmen und Perspektiven du anschließend mit anderen prüfen möchtest.
Eine Übersicht über Qualitätsziele, den eingeschätzten Systemstand und begründete Abweichungen.
Befunde zu den untersuchten Risiken, ihren Ursachen und noch offenen Fragen.
Fiktives Lehrbeispiel
Dokumentvorlage als Ergänzung zum LASR-Ergebnisdiagramm. Ein separates fiktives Beispiel zeigt das Review eines Portals.
System, Umfang und drei bis vier Kernaussagen zum Nutzen festhalten.
B2B-Portal: Bestellungen verlässlich annehmen; Partneradapter einbezogen, Warenwirtschaft ausgenommen.
Drei bis fünf Qualitätsmerkmale, Erwartungen, Skalen und Link zum Zielprofil dokumentieren.
Verfügbarkeit, Änderbarkeit, Sicherheit; das Portal soll auch bei Partnerausfall Bestellungen annehmen.
Risiken den Qualitätszielen zuordnen. Wahrscheinlichkeit, Auswirkungen und Unsicherheit festhalten und mit dem Lückenprofil verknüpfen.
Die Auftragsannahme könnte auf die Antwort des Partners warten müssen; Einschätzung des Teams, technische Prüfung steht aus.
Untersuchtes Qualitätsmerkmal, genaue Erwartungen, Ursachen, Befunde und Änderungen am Profil festhalten.
Die Ablaufanalyse zeigt: Die Auftragsannahme wartet auf den Partner. Das Team ergänzt eine begründete Lücke bei der Verfügbarkeit.
Weitere Prüfungen und mögliche Verbesserungen mit Verantwortlichen festhalten. Ergebnisse später im Profil ergänzen.
Ausfalltest planen; Queue zum Zwischenspeichern der Aufträge prüfen; Wirksamkeit nach Umsetzung testen.
Das Beispiel veranschaulicht die Methode mit erfundenen Angaben.
Lege fest, welches System ihr betrachtet und wozu es dient. Lade Personen ein, die Software und Entwicklung gut kennen.
LASR hilft Entwicklungsteams zu erkennen, wo ihre Software hinter wichtigen Qualitätszielen zurückbleibt und welche Verbesserungen sie prüfen sollten. Mit vorhandenem Systemwissen kann ein kleiner Kreis eine erste Einschätzung erarbeiten und offene Fragen gezielt untersuchen.
Fasse den Zweck der Software im Lean Mission Statement zusammen. Leite daraus die wichtigsten Qualitätsziele und Bewertungskriterien ab: die Evaluation Criteria. Sammle und bewerte Risiken im Risk-based Review. Stelle im Ergebnisdiagramm die Ziele und den eingeschätzten Stand gegenüber. Untersuche auffällige oder strittige Bewertungen in der Quality-focused Analysis genauer und aktualisiere das Profil.
LASR lässt sich allein oder im kleinen Team durchführen. Besonders geeignet sind drei bis vier Personen, die das System gut kennen. Die Produktverantwortlichen helfen in den ersten beiden Schritten, den Zweck der Software und die Qualitätsziele zu klären. Das Ergebnisdiagramm zeigt die Ziele und die eingeschätzten Lücken. Seine Werte beruhen auf qualitativen Bewertungen. Im vierten Schritt untersucht das Team strittige oder unplausible Einschätzungen genauer: Welche Qualität wird erwartet, welche Risiken bestehen und welche Ursachen kommen infrage? Diese Arbeit kann weitere Termine erfordern. Plane benötigte Codeanalysen oder Laufzeitmessungen als zusätzliche Untersuchungen und dokumentiere deren Ergebnisse gesondert.
Kläre den Anlass des Reviews und sorge für Zugang zu Systemwissen und Unterlagen. Formuliere wenige Qualitätsziele, die für das Geschäft wichtig sind. Begründe jede Bewertung mit Beobachtungen oder Annahmen. Nutze unterschiedliche Einschätzungen, um offene Fragen genauer zu untersuchen. Halte bei der Arbeit allein fest, welche Perspektiven noch fehlen, und hole sie gezielt ein. Schließe mit einem aktualisierten Qualitätsprofil ab und benenne Verantwortliche für die offenen Untersuchungen.
Die Methodenanleitung führt mit 4 Phasen, Zeitrahmen, 4 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.
Methodenanleitung öffnenDeine Einschätzung
Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.
Plane zunächst eine erste Einschätzung. Nutze das Lückenprofil, um vertiefende Analysen auszuwählen und Zeit dafür einzuplanen.
Noch zu klären
Noch zu klären
Gesamtes Review Zeit: Für eine erste Einschätzung reichen oft wenige Stunden oder ein halber Tag. Plane zusätzliche Zeit für die ausgewählten vertiefenden Analysen ein.
Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.
System, Umfang und drei bis vier Kernaussagen zum Nutzen festhalten.
...
Drei bis fünf Qualitätsmerkmale, Erwartungen, Skalen und Link zum Zielprofil dokumentieren.
...
Risiken den Qualitätszielen zuordnen. Wahrscheinlichkeit, Auswirkungen und Unsicherheit festhalten und mit dem Lückenprofil verknüpfen.
...
Untersuchtes Qualitätsmerkmal, genaue Erwartungen, Ursachen, Befunde und Änderungen am Profil festhalten.
...
Weitere Prüfungen und mögliche Verbesserungen mit Verantwortlichen festhalten. Ergebnisse später im Profil ergänzen.
...
Reale Angaben und Belege ergänzen. Ungeklärtes ausdrücklich markieren.
Erwartetes Artefakt: Lean Mission Statement mit Review-Grenzen
Die Kernaussagen geben die Richtung für die folgenden Qualitätsziele vor.
Eintrag:
...
Erwartetes Artefakt: Qualitätsziele und Zielprofil
Ergänze im Diagramm, was die Skalenwerte für eure Software konkret bedeuten.
Eintrag:
...
Erwartetes Artefakt: Erstes Risiko- und Lückenprofil mit Unsicherheiten
Verknüpfe jede eingeschätzte Lücke mit den zugehörigen Risiken und Annahmen.
Eintrag:
...
Erwartetes Artefakt: Vertieftes Lückenprofil und gezielte Folgeprüfungen
Halte fest, warum sich eine Einschätzung geändert hat und welche Fragen noch zu prüfen sind.
Eintrag:
...
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/lasr/run-sheet
Passende Alternativen mit Entscheidungshilfe, danach weitere verwandte Methoden.
Wähle ATAM für eine Bewertung in mehreren Phasen mit vielen Beteiligten, die empfindliche Architekturentscheidungen und Zielkonflikte ausdrücklich untersucht.
Zeigt anhand konkreter Aufgaben, wie gut sich eine Architektur nutzen und ändern lässt.
Dokumentiert eine Architekturentscheidung mit Kontext, Alternativen und Konsequenzen, damit spätere Reviews nachvollziehbar bleiben.
Sammelt Systemziele, Constraints und Bausteine in einer kompakten Sicht für frühe Architekturentscheidungen.
Sammelt Risiken direkt auf einem Architekturdiagramm und macht Priorität, Wirkung und nächste Schritte sichtbar.
Bereitet Stakeholder, Kernbotschaften und Artefakte so auf, dass Architekturkommunikation gezielt anschließt.
