Active Design Reviews
Architekturen existieren nicht als Selbstzweck, sondern geben für die Implementierung ein hoffentlich tragfähiges Gerüst vor. Um die Tauglichkeit von Entwürfen zu verifizieren, sollten die späteren Nutzer der Architektur ihre Rückmeldung geben. Lässt sich dieser Prozess strukturieren?
- Dr. Michael Stal
Architekturen existieren nicht als Selbstzweck, sondern geben für die Implementierung ein hoffentlich tragfähiges Gerüst vor. Um die Tauglichkeit von Entwürfen zu verifizieren, sollten die späteren Nutzer der Architektur ihre Rückmeldung geben. Lässt sich dieser Prozess strukturieren?
Für eine neue Bibliothek beziehungsweise Programmierschnittstelle zum Zugriff auf Embedded-Systeme über das Internet haben Architekten einen konzeptionellen Entwurf und auch schon eine rudimentäre Implementierung erstellt. Aber lässt sich die Bibliothek von Entwicklern überhaupt angemessen nutzen, und hält sich der Lernaufwand in Grenzen?
Um solche Fragen zu beantworten, empfiehlt sich die Methodik der Active Design Reviews (ADR), die schon vor vielen Jahren Parnas konzipiert hat.
Bestandteile einer Active Design Review
Die Auftraggeber der Review, meistens Entwickler oder Architekten, stellen dabei Folgendes zusammen:
- Die Implementierung der Software
- Eine zumindest rudimentäre Dokumentation der Software
- Eine konkrete Aufgabenstellung fĂĽr den Reviewer, zum Beispiel:
- Baue mittels der Bibliothek eine Verbindung zum Embedded-System auf
- Ermittle die Konfiguration des Systems
- Fordere die Messdaten eines Sensors an
- FĂĽhre eine Aktion an einem angeschlossenen Aktor aus
- Hole Zustandsinformation vom Gerät
- Einen Fragebogen fĂĽr die Reviewer, zum Beispiel:
- Wie verständlich ist die Dokumentation?
- Wie lange hat die Einarbeitung benötigt?
- Ließen sich die Aufgaben mithilfe der Bibliothek gut oder weniger gut bewältigen?
- Wie lange hat die Umsetzung gedauert?
- Setzt die Bibliothek gewünschte Qualitäten wie Performanz, einfache Handhabung und Konfigurierbarkeit um?
- Was sind die drei größten Stärken der Bibliothek?
- Wo gibt es Verbesserungspotenzial?
Eine ADR ist üblicherweise so gestaltet, dass Reviewer die Aufgaben an einem Tag durchführen können. Auftraggeber sollten als eigenen Aufwand normalerweise ebenfalls einen Tag pro Reviewer einkalkulieren.
Pragmatisches Vorgehen
Das Schöne an ADRs sind deren pragmatisches Vorgehen und das relativ schnelle, effektive Feedback. Es lassen sich auch verschiedene Rollen als Review-Partner adressieren, unter anderem auch Tester oder Endbenutzer. Neben der Implementierung können Architekten oder Entwickler auch Rückschlüsse auf die Qualität der Dokumentation ziehen. Im Gegensatz zu üblichen Reviews handelt es sich um eine Eins-zu-eins-Konstellation zwischen Review-Initiator und Reviewer. Dafür können mehrere und/oder verschiedene ADRs gleichzeitig durchgeführt werden.
Voraussetzungen fĂĽr den Einsatz von ADRs sind die Existenz einer Implementierung, eine ĂĽbersichtliche und an einem Tag machbare Aufgabenstellung und natĂĽrlich ein durchdachter Fragebogen.
Vorteile der Methodik
Ich nutze diese Methodik bereits seit vielen Jahren und halte sie für eine praktikable Lösung mit überschaubarem Aufwand, um effizient effektives Feedback zu erhalten. Ganz im Gegensatz zu den sonst üblichen Ad-hoc-Verfahren.
Die Grenzen von ADRs liegen dort, wo sich ihre Eingangsvoraussetzungen nicht erfüllen lassen. Beispielsweise bei größeren architektonischen Problemen wie mangelnder Wartbarkeit, gravierenden Mängeln bei nichtfunktionalen Eigenschaften, architektonischer Drift oder Nichterfüllung von Geschäftszielen. Dazu eignen sich dann eher aufwendigere Review-Methoden.
Im Übrigen nutzen Ergo-Labs im Prinzip den gleichen Ansatz wie ADRs. ADRs haben weitere Vorteile: Schon beim Zusammenstellen der ADRs lässt sich gut über die eigene Software reflektieren. Und Reviewern können ADRs sogar viel Freude machen.
Ein Unternehmen, dass derartige Verfahren bei der Softwareentwicklung erfolgreich nutzt, ist zum Beispiel Microsoft fĂĽr die Entwicklung des .NET Framework. ()
