Architecture Analyse-Methode

ARID (Active Reviews for Intermediate Designs)

Prüft, wie gut Entwickler einen vorläufigen Entwurf für ihre Aufgaben nutzen können.

ARID hilft, Schnittstellen zu erproben, während sich ein Entwurf noch ändern lässt. Die Entwickler, die später damit arbeiten sollen, wählen typische Aufgaben aus und lösen sie gemeinsam. Dafür schreiben sie Code oder Pseudocode, also einen vereinfachten Programmablauf. So zeigt sich, welche Schnittstellen gut nutzbar sind und wo Angaben zum Verhalten fehlen oder sich widersprechen.

Kernfrage

Können Entwickler ihre wichtigen Aufgaben mit diesem vorläufigen Entwurf lösen?

Arbeitsplan erstellen Methodenanleitung

Vergleich starten

Feedback gebenHilft dir diese Methode?

Teilnehmende: Entwurfsverantwortliche, Entwickler als Anwender und Moderation
Zeit: Für einen begrenzten Review-Termin dienen 2 bis 4 Stunden als Planungsrahmen. Plane Vorbereitung und Auswertung zusätzlich; der Gesamtaufwand richtet sich nach Entwurf und Szenarien.

Die fünf Arbeitsabschnitte fassen die neun Originalschritte zusammen: Vorbereitung und gemeinsames Review. Du kannst die Unterlagen allein vorbereiten. Im Review erproben die künftigen Nutzer den Entwurf gemeinsam.

Entwurfsblätter und Schnittstellenkarten werden durch gemeinsam erarbeiteten Pseudocode mit markierten offenen Fragen verbunden.

Vorbereiten
Entwickler einladen und Unterlagen vorbereiten
Die Entwurfsverantwortlichen bereiten Schnittstellen und Beispiele für die gemeinsame Arbeit vor.
Einführen
Methode und Entwurf vorstellen
Die Gruppe lernt die Schnittstellen kennen und klärt, wie das aktive Review abläuft.
Auswählen
Anwendungsszenarien sammeln und priorisieren
Die Reviewer bringen Aufgaben aus ihrer Arbeit ein und wählen gemeinsam die wichtigsten aus.
Anwenden
Szenarien gemeinsam in Code durchspielen
Die Reviewer schreiben gemeinsam Aufrufe der angebotenen Schnittstellen und protokollieren ihre Beobachtungen.
Sichern
Befunde und nächste Überarbeitung vereinbaren
Die Gruppe bestätigt die Befunde und vereinbart, wer die nächsten Schritte übernimmt.

Erprobe die betroffenen Szenarien nach der Überarbeitung erneut. Halte gelöste Probleme und noch offene Szenarien fest.

Geeignet, wenn

Für den vorläufigen Entwurf eines Services, einer Bibliothek oder einer Komponente. Die Entwickler, die ihn später nutzen sollen, nehmen am Review teil. Das Ergebnis zeigt, wie gut sie die ausgewählten Aufgaben damit lösen können.

Ideal für

Vorläufige APIs und Entwürfe einzelner Systemteile
Frühes Feedback von Entwicklern, die den Entwurf später nutzen
Erprobung typischer Entwicklungsaufgaben vor der detaillierten Spezifikation

Nicht gut für

Vollständige Bewertung der Gesamtarchitektur
Abnahme durch eine einzelne Person ohne Beteiligung der späteren Anwender
Messnachweis für Performance oder Sicherheit

Ergebnisse

Erprobte Anwendungsszenarien
Gemeinsam erarbeiteter Code oder Pseudocode mit sichtbaren offenen Stellen.
Befunde zum Entwurf
Konkrete Nutzungshürden und offene Schnittstellenregeln, jeweils mit Zuständigkeit für die Klärung.

ARID-Review-Protokoll

Fiktives Lehrbeispiel

Dokumentvorlage für das eigene Review. Ein separates fiktives Beispiel zeigt die Arbeit an einer Reservierungsbibliothek.

Entwurf und Reviewer

Entwurfsversion, Grenzen, beteiligte Entwickler und Review-Rollen eintragen.

Reservierungsbibliothek v0.3; zwei aufrufende Teams; Moderation Alex.

Szenarien und Auswahl

Aufgaben, Prioritäten, Auswahlgründe und noch offene Szenarien dokumentieren.

Sichere Wiederholung nach Timeout hat höchste Priorität; Stornierung bleibt offen.

Code und Beobachtungen

Code oder Pseudocode mit verwendeten Schnittstellen, Rückfragen und Annahmen verknüpfen.

Nach einem Timeout bleibt offen, ob reserve(request) erfolgreich war; ein erneuter Aufruf könnte doppelt reservieren.

Befunde und Überarbeitung

Nutzungshürde, betroffene Stelle, Verantwortliche und erneute Prüfung erfassen.

Auftrag durch Idempotency-Key eindeutig kennzeichnen und Statusabfrage ergänzen; anschließend das Szenario erneut erproben.

Das Beispiel veranschaulicht die Methode mit erfundenen Angaben.

Paul C. Clements: Active Reviews for Intermediate Designs (SEI, 2000)

Erster Schritt

Wähle den Teilentwurf und lade seine künftigen Nutzer ein. Bereite Schnittstellen, Datentypen, erwartetes Verhalten und Beispiele vor.

Zur Methodenanleitung

Davor sinnvoll

Architecture

C4 Model

Grenzt den technischen Teilentwurf und seine aufrufenden Systeme ein.

Wie geht es weiter?

Agile

Specification by Example

Überführt geklärte Szenarien und Schnittstellenregeln in konkrete Verhaltensbeispiele.

Architecture

Request for Comments

Strukturiert nötige Entwurfsänderungen als Vorschlag mit Optionen und offenen Fragen für das nächste Review.

Vertiefung

Zweck

ARID prüft, wie gut Entwickler mit einem technischen Entwurf arbeiten können. Betrachtet wird ein noch veränderbarer Teil des Systems zwischen der Architekturübersicht und der detaillierten Spezifikation.

Funktionsweise

Bereite eine Einführung, ein funktionierendes Anwendungsbeispiel und mögliche Aufgaben für den Entwurf vor. Die Entwickler ergänzen eigene Szenarien und wählen die wichtigsten aus. Anhand der verfügbaren Schnittstellen und Unterlagen erarbeiten sie gemeinsam Code oder Pseudocode für diese Aufgaben. Halte ihre Fragen und Schwierigkeiten als Ergebnisse des Reviews fest.

Im Detail

ARID braucht einen vorläufigen Entwurf mit ausreichend beschriebenen Schnittstellen, Beispielen und Erklärungen für konkrete Entwicklungsaufgaben. Die Entwurfsverantwortlichen bereiten die Unterlagen vor. Die Entwickler, die später mit dem Entwurf arbeiten, erproben ihn aus ihrer Anwendungssicht. Dabei wird sichtbar, welche Informationen oder Funktionen fehlen und welche Abläufe umständlich sind. Moderation und Protokoll halten die Beobachtungen fest. Die Ergebnisse zeigen, wie gut sich der Entwurf für die untersuchten Aufgaben nutzen lässt. Performance, Sicherheit und die Gesamtarchitektur werden in eigenen Analysen geprüft.

Durchführung

Wähle Aufgaben aus der späteren Arbeit mit dem Entwurf. Erprobe Einführung und Beispiel vorab. Lass die Entwickler eigene Szenarien ergänzen und beobachte ihre Lösungswege. Halte Eingriffe der Entwurfsverantwortlichen knapp. Dokumentiere jede zusätzlich nötige Erklärung als Hinweis für die Überarbeitung. Eine Person kann das Review vorbereiten. Das aktive Review braucht die späteren Anwender, die Entwurfsverantwortlichen und eine Moderation. Plane anschließend Zeit für die Auswertung ein.

Die Methodenanleitung führt mit 5 Phasen, Zeitrahmen, 5 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.

Methodenanleitung öffnen

Deine Einschätzung

Hilft dir diese Methode für dein Vorhaben?

Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.

Quellen und Themen

Themen

Architektur Engineering Feedback Validierung Aufgaben

Quellen

Paul C. Clements: Active Reviews for Intermediate Designs (SEI, 2000)sei.cmu.eduOriginalbericht CMU/SEI-2000-TN-009: Zielgruppe, zwei Phasen mit neun Schritten und gemeinsame Anwendung von Entwurfsschnittstellen durch Code oder Pseudocode.Active Reviews for Intermediate Designs: Original report (PDF)sei.cmu.eduDer vollständige Bericht vertieft Rollen, neun Schritte, gemeinsame Codeübung und Grenzen anhand der Originalpilotierung.

Artefakt-Vorlagen

ARID (Active Reviews for Intermediate Designs): ArbeitsvorlagePlane Zeit für die Vorbereitung und einen gemeinsamen Review-Termin ein. Richte den Umfang an den wichtigsten Anwendungsszenarien aus.

markdown

arid-markdown.md

Plane Zeit für die Vorbereitung und einen gemeinsamen Review-Termin ein. Richte den Umfang an den wichtigsten Anwendungsszenarien aus.

ARID (Active Reviews for Intermediate Designs): Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Gesamtes Review Zeit: Für einen begrenzten Review-Termin dienen 2 bis 4 Stunden als Planungsrahmen. Plane Vorbereitung und Auswertung zusätzlich; der Gesamtaufwand richtet sich nach Entwurf und Szenarien.

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

Materialien: Versionierter Teilentwurf mit Schnittstellen, Datentypen, erwartetem Verhalten und Beispielen; Szenarioliste, gemeinsamer Editor und Befundprotokoll.
Rollen: Entwurfsverantwortliche, künftige Nutzer als Reviewer, Moderation und Protokoll. Kläre, wer Szenariofragen beantwortet. Die Reviewer brauchen Programmier- und Fachkenntnisse.
Vorab-Infos: Teile Zweck und Grenzen des Entwurfs, Schnittstellen sowie Beispiele. Erläutere die aktive Rolle der Reviewer.
Gesamter Zeitbedarf: Für einen begrenzten Review-Termin dienen 2 bis 4 Stunden als Planungsrahmen. Plane Vorbereitung und Auswertung zusätzlich; der Gesamtaufwand richtet sich nach Entwurf und Szenarien.
Setup: Halte Code oder Pseudocode und Befunde gleichzeitig sichtbar. Trenne Verständnisfragen von Diskussionen über neue Entwurfsoptionen.

Für die Arbeitsschritte bereitstellen

Vorbereiten: Entwickler einladen und Unterlagen vorbereiten

Abgegrenzter Teilentwurf
Entwurfsverantwortliche und Entwickler, die den Entwurf nutzen werden

Einführen: Methode und Entwurf vorstellen

Entwurfsunterlagen und erste Szenarien

Auswählen: Anwendungsszenarien sammeln und priorisieren

Verstandener Entwurf
Erste Szenarien als Anregung

Anwenden: Szenarien gemeinsam in Code durchspielen

Priorisierte Szenarien
Schnittstellen und Beispiele

Sichern: Befunde und nächste Überarbeitung vereinbaren

Code oder Pseudocode und Befunde