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.

1. 1

   Vorbereiten

   Entwickler einladen und Unterlagen vorbereiten

   

   Ziel

   Entwickler können mit den Unterlagen eine typische Aufgabe beginnen.

   Voraussetzungen für diesen Schritt

   • Abgegrenzter Teilentwurf
   • Entwurfsverantwortliche und Entwickler, die den Entwurf nutzen werden

   Durchführung

   • Lade Entwickler ein, die den Entwurf später nutzen sollen. Sie übernehmen die Prüfung als Reviewer. Verteile Moderation, Protokoll und Unterstützung bei Szenariofragen.
   • Beschreibe Schnittstellen, Datentypen und erwartetes Verhalten anhand kurzer Beispiele. Probe die Präsentation mit der Moderation.
   • Erstelle erste Szenarien als Anregung und teile Einladung, Unterlagen und Agenda.

   Ergebnis

   Nutzbare Unterlagen und verteilte Rollen

   Prüfe, ob Unterlagen, Beispiel und Rollen für den Termin bereitstehen.

   Qualitätscheck

   Können Entwickler mit den Unterlagen eine typische Aufgabe beginnen?

   Stolperfalle

   Die Präsentation zeigt nur interne Architekturdiagramme. Ergänze nutzbare Schnittstellen und Beispiele aus Sicht der aufrufenden Anwendung.

   Zeitlicher Rahmen: Vor dem Termin vorbereiten; Zeit nach Umfang einplanen.

2. 2

   Einführen

   Methode und Entwurf vorstellen

   

   Ziel

   Alle kennen das Vorgehen und den angebotenen Entwurf.

   Voraussetzungen für diesen Schritt

   • Entwurfsunterlagen und erste Szenarien

   Durchführung

   • Erkläre, dass Reviewer den Entwurf aktiv verwenden und dabei Befunde festhalten.
   • Lass die Entwurfsverantwortlichen Schnittstellen und Beispiele zeigen. Kläre Verständnisfragen und protokolliere fehlende Informationen.
   • Sammle Fragen zur internen Umsetzung, zu Entwurfsentscheidungen und zu Alternativen für die Nacharbeit.

   Ergebnis

   Gemeinsames Verständnis und offene Fragen

   Halte Verständnisfragen fest und kennzeichne Angaben, die noch ergänzt werden müssen.

   Qualitätscheck

   Sind die Schnittstellen und ihr erwartetes Verhalten verständlich?

   Stolperfalle

   Die Sitzung springt direkt zu einem Alternativentwurf. Lenke die Diskussion auf die Frage, wie die Entwickler die vorliegenden Schnittstellen nutzen können.

   Zeitlicher Rahmen: Zeit für die Einführung nach Umfang des Entwurfs planen.

3. 3

   Auswählen

   Anwendungsszenarien sammeln und priorisieren

   

   Ziel

   Die Entwickler bestimmen die relevanten Aufgaben für das Review.

   Voraussetzungen für diesen Schritt

   • Verstandener Entwurf
   • Erste Szenarien als Anregung

   Durchführung

   • Sammle Aufgaben, die Entwickler mit dem Entwurf lösen müssen, einschließlich Fehler- und Grenzfällen.
   • Fasse doppelte Szenarien zusammen. Lass die Reviewer bestimmen, welche Aufgaben für ihre Arbeit am wichtigsten sind.
   • Halte fest, welche Szenarien ihr auswählt und welche für spätere Reviews offenbleiben.

   Ergebnis

   Priorisierte Anwendungsszenarien

   Notiere zu jeder ausgewählten Aufgabe, warum sie für die spätere Nutzung wichtig ist.

   Qualitätscheck

   Stammen die priorisierten Aufgaben von Entwicklern, die den Entwurf später nutzen?

   Stolperfalle

   Nur die vorbereiteten Erfolgsbeispiele werden bewertet. Lass die Reviewer eigene Aufgaben ergänzen und die Auswahl selbst gewichten.

   Zeitlicher Rahmen: Gemeinsamer Terminabschnitt für die Auswahl.

4. 4

   Anwenden

   Szenarien gemeinsam in Code durchspielen

   

   Ziel

   Konkrete Nutzungshürden werden bei der Anwendung sichtbar.

   Voraussetzungen für diesen Schritt

   • Priorisierte Szenarien
   • Schnittstellen und Beispiele

   Durchführung

   • Beginne mit dem höchst priorisierten Szenario und lass die Reviewer gemeinsam Code oder Pseudocode verfassen.
   • Verwende die angebotenen Schnittstellen und halte Rückfragen, Annahmen, fehlende Dienste und unklare Fehlerbehandlung direkt an der betroffenen Stelle fest.
   • Lass die Entwurfsverantwortlichen Sachfragen klären. Die Reviewer schreiben selbst die nötigen Aufrufe. Bearbeite so die weiteren priorisierten Szenarien.

   Ergebnis

   Code oder Pseudocode mit Befunden

   Ordne jede Frage oder Hürde der betroffenen Stelle im Code oder Pseudocode zu.

   Qualitätscheck

   Lösen die Reviewer die Aufgabe mit den angebotenen Schnittstellen?

   Stolperfalle

   Die Entwurfsverantwortlichen schreiben die Lösung für die Reviewer. Lass die Reviewer selbst weiterarbeiten und halte fest, welche Unterstützung sie benötigen.

   Zeitlicher Rahmen: Hier liegt der Schwerpunkt; komplexe Szenarien können Stunden dauern.

5. 5

   Sichern

   Befunde und nächste Überarbeitung vereinbaren

   

   Ziel

   Die Entwurfsverantwortlichen erhalten nachvollziehbare Ergebnisse.

   Voraussetzungen für diesen Schritt

   • Code oder Pseudocode und Befunde

   Durchführung

   • Fasse bearbeitete Szenarien, erfolgreiche Wege und Hindernisse zusammen. Bestätige die Formulierung der Befunde mit das Reviewern.
   • Benenne Verantwortliche für jede Überarbeitung, fachliche Klärung und technische Prüfung.
   • Dokumentiere offene Szenarien und vereinbare die erneute Erprobung geänderter Schnittstellen.

   Ergebnis

   Review-Protokoll mit Überarbeitung und erneuter Prüfung

   Verknüpfe Überarbeitungen mit den betroffenen Szenarien und vereinbare deren erneute Prüfung.

   Qualitätscheck

   Zeigt jeder Befund, bei welcher Aufgabe und an welcher Stelle er entstanden ist?

   Stolperfalle

   Ein gelöstes Szenario wird als Freigabe für alle Qualitätsziele verstanden. Benenne die erfolgreich bearbeiteten Szenarien und die Qualitätsziele, die weitere technische Prüfungen erfordern.

   Zeitlicher Rahmen: Abschlussblock und spätere erneute Prüfung.