Ein Review verbindet eine konkrete Frage mit einer nachvollziehbaren Untersuchung und begründeten nächsten Schritten.
Kurzüberblick
- Welche Art von Review passt zu deiner Frage? Der Artikel ordnet vier Ansätze anhand einer fiktiven Auftragssoftware ein.
- Du siehst, was die Beteiligten konkret untersuchen und wie sie aus Beobachtungen Empfehlungen ableiten.
- Eine Auswahlhilfe und eine kurze Vorbereitung helfen dir, die Untersuchung für dein eigenes System einzugrenzen.
Die Auftragssoftware läuft. Jeden Tag werden Angebote erstellt, Preise berechnet und Bestellungen verarbeitet. Gleichzeitig braucht eine neue Preisregel inzwischen Änderungen an mehreren Stellen. Der nächste Vertriebskanal soll angebunden werden. Und im kommenden Jahr soll die Software deutlich mehr Aufträge gleichzeitig verarbeiten.
Das Team fragt sich: Können wir diese Anforderungen mit der bestehenden Architektur erfüllen? Wo sollten wir zuerst investieren? Reicht eine gezielte Überarbeitung, oder müssen wir die Aufgaben zwischen größeren Softwarebausteinen neu verteilen?
In einem Architektur-Review untersuchen die Beteiligten, wie gut der Aufbau der Software diese Anforderungen unterstützt. Dazu beschreiben sie konkrete Nutzungs- oder Änderungssituationen, sogenannte Szenarien, und prüfen die betroffenen Architekturentscheidungen.
Was muss das System künftig leisten?
Architektur legt fest, welche Softwarebausteine für welche Aufgaben zuständig sind und wie sie zusammenarbeiten. Ein Review prüft die Folgen dieser Entscheidungen für Betrieb und Weiterentwicklung.
Für das Review legen die Beteiligten fest, welche Anforderungen besonders wichtig sind. Davon hängt ab, welche Teile und Abläufe sie genauer untersuchen.
Die Qualität einer Architektur zeigt sich daran, wie gut das System seine Anforderungen erfüllt und wie aufwendig notwendige Änderungen sind.
Ein System, mehrere Fragen
Unser Beispiel ist eine fiktive Software, die über mehrere Jahre weiterentwickelt wurde. Auftragsverwaltung und Preisberechnung sind ihre zentralen Komponenten, also Softwarebausteine mit jeweils eigenen Aufgaben. Über Schnittstellen tauscht sie Informationen mit Lager und Abrechnung aus. Eine Schnittstelle legt fest, welche Angaben eine Anfrage enthalten muss und wie das angesprochene System antwortet, etwa bei einer Bestandsabfrage. Ein bestehender Vertriebskanal übermittelt bereits Aufträge; ein weiterer soll angebunden werden.
Architektur, Entwurf und Code untersuchen
Bei einem Architektur-Review betrachten wir mehrere zusammenhängende Fragen:
- Verantwortungsgrenzen: Welche Komponente übernimmt welche Aufgabe? Die Preisberechnung wendet Preisregeln an; die Auftragsverwaltung erfasst und bearbeitet Aufträge. Wir prüfen, ob der Code dieser Zuordnung entspricht.
- Abhängigkeiten: Welche andere Komponente braucht die Auftragsverwaltung für eine Aufgabe? Zur Preisermittlung nutzt sie die Preisberechnung. Änderungen dort können deshalb auch die Auftragsverwaltung betreffen.
- Datenflüsse: Welche Informationen werden zwischen den Komponenten übertragen? Die Auftragsverwaltung übergibt beispielsweise Auftragsdaten an die Abrechnung.
- Kommunikation: Wie erfolgt dieser Austausch? Wartet die Auftragsverwaltung bei einer Bestandsabfrage auf die Antwort des Lagersystems, oder kann sie zunächst weiterarbeiten?
- Qualitätsziele: Wie gut soll das System seine Aufgaben erfüllen? Beispielsweise soll es auch bei einer gestörten Lageranbindung Aufträge annehmen können. Das Team legt dafür Bedingungen und eine erforderliche Dauer fest.
Diese Fragen lassen sich sowohl an bestehende Software als auch an eine geplante Architektur stellen.
Ein Design-Review untersucht einen konkreteren Entwurf, etwa eine geplante Schnittstelle. Entwickler prüfen, ob sie damit ihre Aufgaben umsetzen können und welche Angaben ihnen fehlen.
Eine Codeanalyse untersucht die tatsächliche Umsetzung. Sie kann beispielsweise gegenseitige Abhängigkeiten oder mehrfach vorhandenen Code zeigen. Die aufgezeichnete Änderungsgeschichte des Codes, die Versionshistorie, liefert zusätzliche Hinweise: Welche Teile wurden häufig gemeinsam geändert? Das hilft, aufwendige Änderungen zu untersuchen.
Vier Ansätze und ihre Einsatzsituationen
Die Beispiele zeigen, für welche Fragestellungen sich die vier Ansätze eignen, wie die Beteiligten vorgehen und welche Ergebnisse sie erhalten.
SAAM: Wie gut lässt sich das System ändern?
Die Software Architecture Analysis Method, kurz SAAM, untersucht eine Architektur anhand konkreter Szenarien. Bei unserer Auftragssoftware verfolgen wir geplante Änderungen durch die Komponenten und schätzen den notwendigen Aufwand.
Was macht das Team konkret? Zunächst beschreibt es die Aufgaben der Software und ihre Verteilung auf Komponenten. Dann wählt es wichtige Änderungswünsche aus und untersucht sie einzeln:
- Änderung beschreiben: Ein neuer Kundentyp soll eine eigene Rabattregel erhalten.
- Betroffene Komponenten bestimmen: Das Team prüft, ob sich diese Regel über die Einstellungen der Preisberechnung umsetzen lässt. Falls Anpassungen nötig sind, hält es fest, welche Komponenten und Schnittstellen geändert werden müssten, und schätzt den Aufwand.
- Weitere Änderungen vergleichen: Danach untersucht es beispielsweise zeitlich begrenzte Sonderpreise. Betreffen beide Änderungen dieselben Komponenten? Das Team prüft, ob dies zu deren Aufgaben passt oder auf ungünstig verteilte Preislogik hinweist.
Was kommt heraus? Eine Übersicht der untersuchten Änderungen: was die Architektur bereits unterstützt, welche Anpassungen erforderlich wären und wo sich Änderungsaufwand konzentriert. Mit denselben Szenarien lassen sich auch Architekturvarianten vergleichen.
Für unser Beispiel könnte der Befund lauten: Eine neue Rabattregel erfordert Anpassungen sowohl in der Preisberechnung als auch in der Auftragsverwaltung. Das wäre ein konkreter Anlass, die tatsächliche Verteilung der Preislogik zu prüfen. SAAM beim SEI
ATAM: Welche Qualitätsziele beeinflussen sich gegenseitig?
Die Architecture Tradeoff Analysis Method, kurz ATAM, untersucht, wie Architekturentscheidungen wichtige Qualitätsziele unterstützen und welche Risiken oder Zielkonflikte dabei entstehen.
Was machen die Beteiligten konkret? Fachverantwortliche, Entwicklung und Betrieb erläutern die Geschäftsziele und die Architektur. Gemeinsam mit dem Bewertungsteam beschreiben und priorisieren sie konkrete Situationen. Anschließend geht das Bewertungsteam die betroffenen Abläufe durch. Es hält fest, welches Verhalten erwartet wird und was dafür vorausgesetzt wird, etwa eine bestimmte Antwortzeit des Lagersystems.
Wie wird das untersucht? In unserem fiktiven Beispiel antwortet die Lageranbindung zeitweise langsam. Die Beteiligten legen als beispielhaftes Ziel fest: Ein Auftrag soll innerhalb von zwei Sekunden angenommen werden. Eine verbindliche Lieferzusage setzt aktuelle Bestandsdaten voraus. Anhand der Ablaufbeschreibung verfolgen sie einen Auftrag von der Erfassung bis zur Lagerabfrage. Sie prüfen, welche Schritte auf die Lagerantwort warten, wann die Abfrage abbricht und wie der Auftrag danach behandelt wird.
Ein möglicher Befund: Der beschriebene Ablauf wartet bis zu fünf Sekunden auf das Lager. Erst danach wird der Auftrag gespeichert. Bei einer langsamen Lagerantwort widerspricht dieser Ablauf dem Zwei-Sekunden-Ziel. Kürzeres Warten beschleunigt die Reaktion, kann aber dazu führen, dass die Bestandsprüfung beim Annehmen des Auftrags aussteht. Dieser Zielkonflikt heißt Trade-off. Die Wartezeit ist zugleich ein Sensitivitätspunkt, weil ihre Änderung die Antwortzeit stark beeinflusst.
Was folgt daraus? Das Bewertungsteam dokumentiert das Risiko samt betroffenem Qualitätsziel und den Annahmen über den Ablauf. Eine zu prüfende Option wäre, den Auftrag zunächst mit dem Status „Bestandsprüfung ausstehend“ anzunehmen und die Lieferzusage nach erfolgreicher Prüfung zu ergänzen. Die Fachverantwortlichen klären, ob dieser Ablauf akzeptabel ist. Anschließend kann das Team mit vielen gleichzeitigen Aufträgen und verzögerten Lagerantworten testen, ob die gewählte Lösung die geforderten Antwortzeiten erreicht. Das Review hält damit fest, warum der Ablauf geändert werden sollte und was vor einer Umsetzung zu klären ist. ATAM beim SEI
ARID: Können Entwickler mit dem Teilentwurf arbeiten?
Active Reviews for Intermediate Designs, kurz ARID, untersucht konkretere Teilentwürfe während ihrer Ausarbeitung. Künftige Nutzer des Entwurfs, hier Entwickler anderer Komponenten, erproben dessen Verwendung anhand ausgewählter Aufgaben.
Was machen die Beteiligten konkret? Die Entwurfsverantwortlichen stellen die vorgesehene Schnittstelle vor. Die Entwickler sammeln und priorisieren Aufgaben, die sie damit lösen müssen. Anschließend arbeiten sie gemeinsam durch, welche Aufrufe und Verarbeitungsschritte dafür erforderlich wären, etwa in Form von Pseudocode: einer vereinfachten Beschreibung des Programmablaufs.
In unserem Beispiel soll der neue Vertriebskanal einen Auftrag anlegen. Nach einer unterbrochenen Verbindung sendet er denselben Auftrag erneut. Die Entwickler beschreiben anhand des Schnittstellenentwurfs, wie sie diesen Fall behandeln würden. Dabei prüfen sie: Welche Kennung identifiziert den Auftrag eindeutig? Wie erfahren sie, ob der erste Versuch erfolgreich war? Wie verhindert der vorgesehene Ablauf eine doppelte Bestellung?
Was kommt heraus? Eine dokumentierte Liste der Schwierigkeiten beim Anwenden des Entwurfs, etwa fehlende Angaben, unklare Fehlerantworten oder widersprüchliche Erwartungen. Im Beispiel könnte eine eindeutige Auftragskennung fehlen. Die Entwurfsverantwortlichen erhalten damit konkrete Hinweise für die Überarbeitung, bevor weitere Entwickler die Schnittstelle verwenden. ARID beim SEI
LASR: Wo liegen Risiken und Vertiefungsbedarf?
Mit dem Lightweight Approach for Software Reviews, kurz LASR, bewertet das Team gemeinsam die Software und bestimmt, welche Risiken genauer untersucht werden sollen.
Was macht das Team konkret? Es beschreibt zunächst knapp, wem die Software bei welchen Aufgaben hilft. Danach legt es die wichtigsten Bewertungskriterien fest und vergleicht die gewünschten Eigenschaften mit seiner Einschätzung des aktuellen Systems. Die Beteiligten begründen ihre Bewertungen, sammeln Risiken und untersuchen relevante oder strittige Punkte genauer.
Wie wird das untersucht? Für unsere Auftragssoftware vereinbart das Team ein konkretes Kriterium für einfache Änderbarkeit: Eine neue Rabattregel soll mit überschaubarem Aufwand eingeführt werden können, während bestehende Regeln weiterhin korrekt funktionieren. Das Team legt dazu einen akzeptablen Aufwand und Testfälle für neue sowie bestehende Regeln fest. Entwicklung und fachliche Anwender bewerten zunächst, wie gut das heute gelingt. Um unterschiedliche Einschätzungen zu klären, untersuchen sie eine bereits umgesetzte Änderung. Während wir bei SAAM geplante Änderungen durchgespielt haben, prüfen wir hier eine kürzlich eingeführte Rabattregel: Welche Dateien wurden geändert? Welche Tests wurden ausgeführt? Welche Fehler wurden anschließend gemeldet?
Ein möglicher Befund: Bei dieser Änderung wurde die Rabattgrenze in der Preisberechnung angepasst. Eine zusätzliche Prüfung in der Auftragsverwaltung verwendete weiterhin den alten Wert und lehnte dadurch gültige Aufträge ab. Die Änderungsübersicht und der Fehlerbericht belegen, dass dieselbe fachliche Regel an zwei Stellen gepflegt werden musste. Damit lässt sich die zunächst unterschiedliche Einschätzung konkret erklären.
Was folgt daraus? Das Team dokumentiert die Abweichung vom vereinbarten Kriterium und das Risiko widersprüchlicher Preisregeln. Für die untersuchte Regel empfiehlt es, die Rabattgrenze in der Preisberechnung zu pflegen und die Auftragsverwaltung deren Ergebnis verwenden zu lassen. Ein gemeinsamer Test beider Komponenten soll prüfen, ob gültige Aufträge damit korrekt verarbeitet werden. Ob weitere Regeln ebenfalls doppelt gepflegt werden, bleibt ein gezielter Prüfauftrag. Das Ergebnis ist eine begründete Systembewertung mit konkreten Verbesserungen und offenen Prüfpunkten. LASR
Welcher Ansatz passt zu deiner Frage?
| Deine Frage | Passender Ansatz | Was du als Ergebnis erwarten kannst |
|---|---|---|
| Welche Anpassungen erfordern geplante Änderungen? | SAAM | Betroffene Komponenten, notwendige Änderungen und eine Einschätzung des Aufwands |
| Wie wirken Architekturentscheidungen auf mehrere Qualitätsziele? | ATAM | Risiken, Zielkonflikte und Entscheidungen, von denen wichtige Eigenschaften abhängen |
| Können Entwickler mit einem Teilentwurf ihre Aufgaben lösen? | ARID | Konkrete Schwierigkeiten und fehlende Angaben als Grundlage für die Überarbeitung |
| Wie bewerten wir unser System gemeinsam, und was prüfen wir genauer? | LASR | Begründete Bewertung, erkannte Risiken und Ergebnisse gezielter Vertiefungen |
Die Tabelle hilft bei der ersten Auswahl. Für die Durchführung zählen außerdem die verfügbaren Unterlagen, die Beteiligten und der erforderliche Prüfumfang.
Was brauchen die Beteiligten für ein Review?
Vor der Untersuchung sollten fünf Dinge geklärt sein:
- Entscheidung: Was soll anschließend entschieden werden, etwa die Anbindung eines Vertriebskanals oder die Überarbeitung der Preisberechnung?
- Anforderungen: Welche Situationen soll das System unter welchen Bedingungen bewältigen?
- Beteiligte: Wer kennt die fachlichen Anforderungen, den Code und den Betrieb?
- Unterlagen: Welche Architekturübersichten, Schnittstellenbeschreibungen, Fehlerberichte und Messungen liegen vor?
- Prüfumfang: Welche Aussagen müssen durch Codeprüfung, Tests oder Messungen abgesichert werden?
Welche Rolle spielen Analysewerkzeuge?
Analysewerkzeuge können zeigen, welche Komponenten die Preisberechnung aufrufen oder eigene Preisregeln enthalten. Das Team vergleicht diese Ergebnisse mit der vorgesehenen Aufgabenverteilung. So lässt sich prüfen, warum eine neue Rabattregel Änderungen an mehreren Stellen erfordert.
Dabei dokumentiert das Team, welche Teile des Codes untersucht wurden und welche Fragen weitere Prüfungen brauchen. Ein eigener Artikel soll die Auswahl und Anwendung solcher Werkzeuge vertiefen.
Das kannst du mitnehmen
- Die Entscheidung bestimmt die Untersuchung. Kläre zuerst, wofür du das Ergebnis brauchst, etwa für die Anbindung eines Vertriebskanals oder eine Änderung der Preisberechnung.
- Konkrete Situationen machen Anforderungen prüfbar. „Einen Auftrag innerhalb von zwei Sekunden annehmen“ lässt sich gezielter untersuchen als „Das System soll schnell sein“.
- Empfehlungen brauchen nachvollziehbare Befunde. Halte fest, was tatsächlich untersucht wurde, welche Annahmen verwendet wurden und welche Prüfungen noch ausstehen.
- Gezielte Verbesserungen können ausreichen. Im Beispiel könnte das Team die Aufteilung in Komponenten beibehalten, eine doppelt gepflegte Preisregel zusammenführen und das Verhalten bei gestörter Lageranbindung testen.
Dein nächster Schritt
Wähle eine anstehende Änderung oder ein wiederkehrendes Problem in deiner Software. Notiere, was das System in dieser Situation leisten soll und welche Entscheidung du mit der Untersuchung vorbereiten möchtest. Nutze anschließend die Auswahlhilfe, um einen passenden Ansatz zu bestimmen.
Für mich liegt darin der praktische Wert eines Reviews: Das Team kann erklären, warum es eine Änderung empfiehlt und welche Verbesserung es davon erwartet. Die Verantwortlichen können auf dieser Grundlage entscheiden, was als Nächstes umgesetzt wird.
So geht die Artikelserie weiter
Dieser Artikel eröffnet die Serie „Softwarearchitektur gezielt untersuchen“. In den nächsten Teilen gehen wir die vier Review-Ansätze an unserer fiktiven Auftragssoftware genauer durch. Anschließend schauen wir uns an, welche Befunde Codeanalyse-Werkzeuge liefern und wie aus den Ergebnissen konkrete Verbesserungen werden.
Als Nächstes geht es um SAAM: Wir verfolgen eine neue Preisregel durch die Software und halten fest, welche Komponenten angepasst werden müssten und welcher Aufwand dabei entsteht.