methodatlas
MethodenanleitungArchitecture

Views and Beyond

Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.

KomplexitätMittel
Zeit1-3 Tage
Teilnehmende1-4
FormatWorkshop + Async
ReifegradCanonical
Arbeit planen
01

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenKlarer Arbeitsrahmen

Liste Stakeholderfragen und den vorgesehenen Dokumentationszweck, bevor du Sichten auswählst.

Ohne abgegrenzte Frage oder prüfbare Belege wird das Ergebnis unscharf.
02

Vorbereitung

Was vor Start vorliegen muss

Materialien

Systembelege, Stakeholderanliegen, Interface- und Verhaltensaufzeichnungen, geeignete Notation und verantwortliche Person.

Personen / Rollen

Architektur · Umsetzung · Betrieb · Test/Security nach Bedarf; Nutzerinnen und Nutzer der Sichten prüfen die Verständlichkeit.

Vorabinfos

Material, Datenzugang und Teilnehmende vorab nach Forschungs- oder Entscheidungsfrage festlegen.

Zeitbedarf

Ein Vorhaben über mehrere Tage, während Sichten und Belege zusammengestellt werden.

Setup

Arbeitsfläche mit der methodenspezifischen Struktur öffnen. Fiktive Beispiele dienen nur der Orientierung; Arbeitsvorlage und eigene Befunde bleiben getrennt.

03

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche Sichten dienen diesen Stakeholdern, und welche Informationen müssen über die einzelnen Sichten hinaus dokumentiert werden?

04

Ablauf

Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle

Views and Beyond dokumentiert Softwarearchitektur über relevante Sichten für Stakeholder und ergänzt Querschnittsinformationen sowie Begründungen.

Views and Beyond Arbeitsblatt

Fiktives Beispiel

Methodenspezifische Fragen mit fiktivem ausgearbeiteten Beispiel; die Arbeitsvorlage bleibt leer.

Stakeholder und Verwendungszweck klären

Stakeholderbezogener Dokumentationsplan

Betrieb braucht Deployment- und Wiederanlaufinformationen; Entwicklung braucht Modulverantwortung und Abhängigkeiten.

Relevante Sichten auswählen

Kleine relevante Sichtenauswahl

Eine Module View kann Codeverantwortung klären; eine Allocation View den Betrieb, falls diese Fragen tatsächlich bestehen.

Sichten mit ausreichendem Inhalt dokumentieren

Nutzbare Architekturviews mit Erklärung

Eine Module View benennt das Booking-Modul, Zuständigkeit und Abhängigkeit zum Payment Adapter; Interface-Details verweisen auf gepflegte Spezifikationen.

Querschnittsinformation und Begründung ergänzen

Kohärente Architekturdokumentation

Module- und Deployment-Sicht verweisen im Beispiel auf dieselbe Service-ID; die Begründung erklärt die externe Payment-Grenze.

SEI says document relevant views for anticipated stakeholder use, then information that applies across views and rationale.

Views and Beyond Collection | CMU Software Engineering Institute

  1. 1

    Nutzung

    Stakeholder und Verwendungszweck klären

    Ziel

    Stakeholderbezogener Dokumentationsplan

    Voraussetzungen für diesen Schritt

    • Liste Stakeholderfragen und den vorgesehenen Dokumentationszweck, bevor du Sichten auswählst.
    • Systembelege, Stakeholderanliegen, Interface- und Verhaltensaufzeichnungen, geeignete Notation und verantwortliche Person.

    Durchführung

    • Benenne Stakeholder und geplante Nutzung der Architekturbeschreibung; wähle Sichten anhand der Fragen, die sie beantworten sollen.
    • Das Ergebnis „Stakeholderbezogener Dokumentationsplan“ mit Belegstatus, Quelle oder offenem Prüfbedarf festhalten.

    Ergebnis

    Stakeholderbezogener Dokumentationsplan

    Stakeholderbezogener Dokumentationsplan

    Qualitätscheck

    Dient jede geplante Sicht einer benannten Verwendung?

    Stolperfalle

    Sichten werden aus Gewohnheit oder Vollständigkeitsdrang gewählt. Sichten ohne Leserschaftsbedarf streichen und offene Anliegen erfassen.

    Zeitlicher Rahmen: Etwa 10–20 Minuten; Daten- oder Klärungsarbeit separat planen.

  2. 2

    Auswahl

    Relevante Sichten auswählen

    Ziel

    Kleine relevante Sichtenauswahl

    Voraussetzungen für diesen Schritt

    • Stakeholderbezogener Dokumentationsplan
    • Systembelege, Stakeholderanliegen, Interface- und Verhaltensaufzeichnungen, geeignete Notation und verantwortliche Person.

    Durchführung

    • Wähle passende Viewtypes und Sichten. Halte Viewpoint, Scope, Notation und Begründung fest.
    • Das Ergebnis „Kleine relevante Sichtenauswahl“ mit Belegstatus, Quelle oder offenem Prüfbedarf festhalten.

    Ergebnis

    Kleine relevante Sichtenauswahl

    Kleine relevante Sichtenauswahl

    Qualitätscheck

    Sind Sichten unterscheidbar und passend zur Frage?

    Stolperfalle

    Diagramme mischen unbekannte Elemente oder Beziehungen. Viewtype, Elemente, Beziehungen und Konventionen benennen.

    Zeitlicher Rahmen: Etwa 10–20 Minuten; Daten- oder Klärungsarbeit separat planen.

  3. 3

    Sichten

    Sichten mit ausreichendem Inhalt dokumentieren

    Ziel

    Nutzbare Architekturviews mit Erklärung

    Voraussetzungen für diesen Schritt

    • Kleine relevante Sichtenauswahl
    • Systembelege, Stakeholderanliegen, Interface- und Verhaltensaufzeichnungen, geeignete Notation und verantwortliche Person.

    Durchführung

    • Beschreibe je Sicht Elemente und Beziehungen sowie nötige Eigenschaften, Interfaces, Verhalten oder Analyse.
    • Das Ergebnis „Nutzbare Architekturviews mit Erklärung“ mit Belegstatus, Quelle oder offenem Prüfbedarf festhalten.

    Ergebnis

    Nutzbare Architekturviews mit Erklärung

    Nutzbare Architekturviews mit Erklärung

    Qualitätscheck

    Können Leserinnen und Leser damit bauen, analysieren, betreiben oder warten?

    Stolperfalle

    Box-and-line-Diagramm ohne Bedeutung oder Begründung. Legende, Randbedingungen und nötige Detailangaben ergänzen.

    Zeitlicher Rahmen: Etwa 10–20 Minuten; Daten- oder Klärungsarbeit separat planen.

  4. 4

    Querschnitt

    Querschnittsinformation und Begründung ergänzen

    Ziel

    Kohärente Architekturdokumentation

    Voraussetzungen für diesen Schritt

    • Nutzbare Architekturviews mit Erklärung
    • Systembelege, Stakeholderanliegen, Interface- und Verhaltensaufzeichnungen, geeignete Notation und verantwortliche Person.

    Durchführung

    • Dokumentiere Sichten übergreifende Informationen, Designrationale, Annahmen und Beziehungen zwischen den Sichten.
    • Das Ergebnis „Kohärente Architekturdokumentation“ mit Belegstatus, Quelle oder offenem Prüfbedarf festhalten.

    Ergebnis

    Kohärente Architekturdokumentation

    Kohärente Architekturdokumentation

    Qualitätscheck

    Sind gemeinsame Fakten und Beziehungen konsistent?

    Stolperfalle

    Kopierte Fakten verändern sich widersprüchlich. IDs und Querverweise nutzen; Reviewverantwortung festlegen.

    Zeitlicher Rahmen: Etwa 10–20 Minuten; Daten- oder Klärungsarbeit separat planen.

05

Artefakt

Was am Ende rauskommt

Skizze: so sieht das Artefakt aus

Views & Beyond · ArchitekturdokumentationArchitektur über Module, Laufzeit, Zuordnung und Beyond-Artefakte gezielt für Leser dokumentieren
Views and BeyondDas Visual zeigt drei Architekturviews und die Beyond-Artefakte Quality Scenarios, Rationale und Documentation Map.Architektur für unterschiedliche Leser strukturierenViews zeigen unterschiedliche Sichten; Beyond erklärt Qualität, Begründung und Lesepfade.ergänztordnet zuBeyondBegründungNavigationModule ViewCode-StrukturComponent & ConnectorLaufzeit und DatenflüsseAllocation ViewDeployment, Teams, HardwareQuality Scenarioswichtige -ilitiesRationalewarum entschiedenDocumentation MapLesepfade
Form

Versionierte Dokumentation mit Frage, Evidenz, Ergebnis, Unsicherheit, Verantwortlichen und nächstem Prüftermin.

Versionierung / Ownership

Datum, Scope, Quelle, Annahmen und Änderungen nachhalten; bei Praxis oder Vorhaben eine verantwortliche Person und Überprüfung festlegen.

Tool-Alternativen
  • Papier und Stifte
  • Whiteboard oder einfache Tabelle

views-and-beyond-working-template.md

Plane die Sitzung oder das Vorhaben passend zum tatsächlichen Arbeitsumfang.

Views and Beyond: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Vollständige Methode vorbereiten Zeit: Ein Vorhaben über mehrere Tage, während Sichten und Belege zusammengestellt werden.

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

Vorbereitung für diesen Umfang

Methodische Grundausstattung

  • Materialien: Systembelege, Stakeholderanliegen, Interface- und Verhaltensaufzeichnungen, geeignete Notation und verantwortliche Person.
  • Rollen: Architektur · Umsetzung · Betrieb · Test/Security nach Bedarf; Nutzerinnen und Nutzer der Sichten prüfen die Verständlichkeit.
  • Vorab-Infos: Material, Datenzugang und Teilnehmende vorab nach Forschungs- oder Entscheidungsfrage festlegen.
  • Gesamter Zeitbedarf: Ein Vorhaben über mehrere Tage, während Sichten und Belege zusammengestellt werden.
  • Setup: Arbeitsfläche mit der methodenspezifischen Struktur öffnen. Fiktive Beispiele dienen nur der Orientierung; Arbeitsvorlage und eigene Befunde bleiben getrennt.

Für die Arbeitsschritte bereitstellen

Nutzung: Stakeholder und Verwendungszweck klären

  • Liste Stakeholderfragen und den vorgesehenen Dokumentationszweck, bevor du Sichten auswählst.
  • Systembelege, Stakeholderanliegen, Interface- und Verhaltensaufzeichnungen, geeignete Notation und verantwortliche Person.

Auswahl: Relevante Sichten auswählen

  • Stakeholderbezogener Dokumentationsplan
  • Systembelege, Stakeholderanliegen, Interface- und Verhaltensaufzeichnungen, geeignete Notation und verantwortliche Person.

Sichten: Sichten mit ausreichendem Inhalt dokumentieren

  • Kleine relevante Sichtenauswahl
  • Systembelege, Stakeholderanliegen, Interface- und Verhaltensaufzeichnungen, geeignete Notation und verantwortliche Person.

Querschnitt: Querschnittsinformation und Begründung ergänzen

  • Nutzbare Architekturviews mit Erklärung
  • Systembelege, Stakeholderanliegen, Interface- und Verhaltensaufzeichnungen, geeignete Notation und verantwortliche Person.

Views and Beyond Arbeitsblatt

Stakeholder und Verwendungszweck klären

Stakeholderbezogener Dokumentationsplan

...

Relevante Sichten auswählen

Kleine relevante Sichtenauswahl

...

Sichten mit ausreichendem Inhalt dokumentieren

Nutzbare Architekturviews mit Erklärung

...

Querschnittsinformation und Begründung ergänzen

Kohärente Architekturdokumentation

...

Leere Arbeitsvorlage zeigt ausschließlich die Fragen, keine Beispieldaten.

Views and Beyond Collection | CMU Software Engineering Institute

Nutzung: Stakeholder und Verwendungszweck klären

Erwartetes Artefakt: Stakeholderbezogener Dokumentationsplan

Stakeholderbezogener Dokumentationsplan

Eintrag:

...

  • Dient jede geplante Sicht einer benannten Verwendung?

Auswahl: Relevante Sichten auswählen

Erwartetes Artefakt: Kleine relevante Sichtenauswahl

Kleine relevante Sichtenauswahl

Eintrag:

...

  • Sind Sichten unterscheidbar und passend zur Frage?

Sichten: Sichten mit ausreichendem Inhalt dokumentieren

Erwartetes Artefakt: Nutzbare Architekturviews mit Erklärung

Nutzbare Architekturviews mit Erklärung

Eintrag:

...

  • Können Leserinnen und Leser damit bauen, analysieren, betreiben oder warten?

Querschnitt: Querschnittsinformation und Begründung ergänzen

Erwartetes Artefakt: Kohärente Architekturdokumentation

Kohärente Architekturdokumentation

Eintrag:

...

  • Sind gemeinsame Fakten und Beziehungen konsistent?

Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/views-and-beyond/run-sheet

06

Beispielausgabe

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.

views-and-beyond-beispiel.md

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Beispiel: Reservierungsservice

Nutzung: Betrieb benötigt Deployment- und Wiederanlaufinformationen; Entwicklung braucht Modulverantwortung und Abhängigkeiten.

Sichten: Eine Allocation View zur Laufzeitzuordnung und eine Module View zu Implementierungsverantwortung, sofern diese Fragen bestätigt sind.

Inhalt: IDs, Beziehungen, Constraints und benötigte Interface-Details begleiten jedes Diagramm.

Übergreifend: Begründung für einen Payment Adapter sowie Annahmen und Querverweise.

Review: Betrieb und Entwicklung prüfen, ob die Dokumentation ihre Aufgaben unterstützt.

07

Stolperfallen

Symptome erkennen, gegensteuern

Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf

  1. Stakeholder und Verwendungszweck klärenSichten werden aus Gewohnheit oder Vollständigkeitsdrang gewählt.In der Phase ansehen
  2. Relevante Sichten auswählenDiagramme mischen unbekannte Elemente oder Beziehungen.In der Phase ansehen
  3. Sichten mit ausreichendem Inhalt dokumentierenBox-and-line-Diagramm ohne Bedeutung oder Begründung.In der Phase ansehen
  4. Querschnittsinformation und Begründung ergänzenKopierte Fakten verändern sich widersprüchlich.In der Phase ansehen
08

Abbruchkriterien

Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest

Sichten ohne Stakeholderbedarf weglassen. Widersprechen sich Sichten, Fakten und Verantwortung abgleichen, bevor abhängige Entscheidungen getroffen werden.

Wie geht es weiter?

Papierillustration mit zwei betrachteten Optionen, die zu einem Entscheidungsdokument mit markiertem Status und sichtbaren Konsequenzen führen.
Architecture
Architecture Decision Record

Hält die Designrationale hinter einer Sicht als eigene Entscheidung fest.

Papierillustration zu C4 Model mit den zentralen Arbeitsschritten und einem sichtbaren Ergebnis.
Architecture
C4 Model

Nutzt C4 als konkrete Notation für eine der gewählten Sichten.

Im Playbook ansehenArchitekturdokumentation aufbauenVon verstreutem Architekturwissen zu Views, Entscheidungen und kommunizierbarer Dokumentation.

Methodenanleitung durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.

Zum SteckbriefWeitere Methoden