Ein Projektkontextdiagramm zeigt den Gegenstand, der verändert wird, sowie die Menschen, Organisationen oder Systeme in seinem Umfeld. Es dient dazu, die Grenze zu klären: wofür das Projekt zuständig ist, womit es interagiert und was außerhalb des Umfangs bleibt. Es ist weder ein Aufgabenzeitplan noch eine detaillierte Prozesslandkarte.
Der Begriff braucht etwas Sorgfalt. Ein Kontextdiagramm für ein Softwaresystem konzentriert sich auf ein System und seine externen Beziehungen. Eine umfassendere Projektskizze kann außerdem Sponsoren, Lieferanten, Betriebsteams und Einschränkungen zeigen. Geben Sie an, welche Art Sie erstellen, damit das Publikum die Grenze richtig versteht.
Einen genauen Gegenstand festlegen, bevor Sie zeichnen
Schreiben Sie über das Diagramm: „Dieses Diagramm beschreibt ___ für den Zweck ___.“ Zum Beispiel: „Dieses Diagramm beschreibt den neuen Terminservice, damit Umsetzungs- und Betriebsteams Integrationszuständigkeiten abstimmen können.“
Vermeiden Sie einen mehrdeutigen Programmnamen im zentralen Kasten. „Kundentransformation“ kann ein Softwaresystem, eine Sammlung von Projekten oder ein ganzes Betriebsmodell meinen. Sind diese Grenzen vermischt, löst das Diagramm keine Unstimmigkeit im Umfang.
Die C4-Leitlinien zum Systemkontext konzentrieren sich auf ein einzelnes Softwaresystem, seine Nutzer und direkt verbundene externe Systeme. Verwenden Sie diesen Ansatz bei Fragen der Softwarearchitektur. Der breitere Projektworkshop unten ist eine Anpassung für Umfang und Koordination, kein neuer C4-Diagrammtyp.
Fragen Sie, welche Entscheidung diese Ansicht unterstützen soll. Kann niemand eine nennen, halten Sie inne, bevor Sie weitere Kästen ergänzen. Ein nützliches Diagramm kann klären, wer für eine fehlgeschlagene Benachrichtigung zuständig ist, welche Integration genehmigt werden muss oder welche Organisation die betriebliche Übergabe übernimmt.
Ausgearbeitetes Kontextbeispiel: Terminerinnerungen
Dieses Szenario ist hypothetisch. Ein Team führt einen Terminerinnerungsdienst für ein Kliniknetz ein. Der zentrale Gegenstand des Diagramms ist der Erinnerungsdienst, nicht der gesamte Klinikbetrieb.
Die umgebenden Beziehungen lassen sich vor dem Zeichnen in dieser Tabelle festhalten:
| Externer Akteur oder System | Beziehung zum Erinnerungsdienst | Frage zur Grenze |
|---|---|---|
| Terminsystem | Liefert Terminänderungen und Stornierungen | Wer bestätigt, dass Stornierungsaktualisierungen rechtzeitig eintreffen? |
| Klinikverwaltung | Richtet genehmigte Zeitpunkte für Erinnerungen ein | Wer genehmigt Änderungen an den Zeitregeln? |
| Patient | Erhält eine Erinnerung und wählt eine Antwort | Wo liegen Einwilligung und Verwaltung der Kontaktpräferenzen? |
| Messaging-Anbieter | Nimmt Nachrichtenanfragen an und meldet den Zustellstatus zurück | Wer untersucht eine abgewiesene Nachricht? |
| Betriebsteam | Überwacht den Dienstzustand und bearbeitet Eskalationen | Welche Evidenz ist vor der betrieblichen Abnahme nötig? |
Zeichnen Sie den Dienst in die Mitte und jede externe Partei darum herum. Beschriften Sie Beziehungen mit Verb und Objekt, etwa „liefert Terminaktualisierungen“. Ein unbeschrifteter Pfeil kann Daten, Befugnis, Zuständigkeit oder Reihenfolge bedeuten; Leser sollten nicht raten müssen.
Nehmen Sie keine vertraulichen Patientendaten ins Diagramm auf. Verwenden Sie Rollen, Kategorien und repräsentative Beziehungen. Spezifische Datenschutz- und Betriebsanforderungen brauchen weiterhin eigene genehmigte Dokumentation und eine fachliche Prüfung.
Die erste Fassung deckt eine offene Entscheidung auf: Das Team dachte, das Terminsystem verwalte Kontaktpräferenzen, während dessen Eigentümer die Zuständigkeit beim neuen Dienst sah. Das ist eine Lücke im Umfang. Mehr grafischer Detailreichtum löst sie nicht; nötig ist eine ausdrückliche Entscheidung über die Zuständigkeit.
Einen 35-minütigen Workshop zu Grenzen durchführen
Vorbereitung: Laden Sie jemanden ein, der jede wichtige externe Beziehung versteht. Bringen Sie den aktuellen Projektumfang und zwei realistische Anwendungsfälle mit. Bitten Sie die Teilnehmenden, Annahmen zunächst unabhängig zu notieren.
Minute 0–5: Gegenstand bestätigen. Einigen Sie sich auf Zweck, zentrale Grenze und Zielpublikum. Notieren Sie Ausschlüsse, die leicht missverstanden werden. Ein Ausschluss sollte zeigen, wohin die Zuständigkeit übergeht, und nicht nur „außerhalb des Umfangs“ sagen.
Minute 5–15: Beziehungen abbilden. Ergänzen Sie unmittelbar relevante Nutzer, Organisationen oder Systeme. Beschriften Sie die Bedeutung jeder Beziehung. Kennzeichnen Sie unsichere Beziehungen als Fragen, statt sie als gesicherte Fakten darzustellen.
Minute 15–25: Szenarien durchgehen. Verfolgen Sie einen Normalfall, eine Ausnahme und einen Betriebsfehler. Probieren Sie beim Erinnerungsdienst einen stornierten Termin, einen nicht erreichbaren Messaging-Anbieter und eine Person aus, die ihre Präferenzen ändert. Fragen Sie, wo die Zuständigkeit übergeht.
Minute 25–35: Lücken lösen oder zuweisen. Halten Sie jede Grenzentscheidung, ihre Zuständigkeit und die benötigte Evidenz fest. Lassen Sie offene Annahmen sichtbar. Behandeln Sie ein von einem Team genehmigtes Diagramm nicht als Zustimmung abwesender Stakeholder.
Diese Zeitangaben sind ein Workshopvorschlag und keine formale Modellierungsvorgabe.
Drei unterschiedliche Ansichten getrennt halten
Ein Kontextdiagramm beantwortet, wer und was mit dem Gegenstand interagiert. Ein Prozessdiagramm beantwortet, wie Arbeit durch Aktivitäten und Entscheidungen läuft. Ein Projektzeitplan beantwortet, wann Aktivitäten und Meilensteine erwartet werden.
Möglicherweise brauchen Sie alle drei, doch eine überladene Grafik erfüllt selten alle Zwecke. Dreht sich die Diskussion um die Reihenfolge von Genehmigungsschritten, halten Sie diese Frage für eine Prozesskarte fest. Geht es um Termine und Ressourcenverfügbarkeit, gehört sie in den Zeitplan.
Machen Sie aus dem Kontextdiagramm auch kein Organigramm. Eine Person, die das Projekt fördert, kann für eine Projektskizze wichtig sein, ohne direkt mit der Software zu interagieren. Zeigen Sie diese Beziehung bewusst und erklären Sie die Legende.
Bei Softwarediagrammen gehören Technologieentscheidungen wie Bibliotheken und Datenbankindizes meist in eine detailliertere Ansicht. Sie wegzulassen ist eine Entscheidung über Publikum und Umfang, keine Aussage, dass diese Details unwichtig seien.
Das Diagramm bei geänderten Grenzen überprüfen
Benennen Sie eine pflegende Person und einen Auslöser für die Prüfung. Sinnvolle Auslöser sind eine neue Integration, ein Wechsel der betrieblichen Zuständigkeit, ein neuer Lieferant oder eine neu erkannte Nutzergruppe. Ohne aktuelle Zuständigkeit kann ein Diagramm eine überzeugende Darstellung einer überholten Vereinbarung werden.
Fragen Sie bei einer Projektprüfung: „Welche Beziehung hat uns überrascht, welche Grenze verursachte Nacharbeit und welche Annahme sollten wir nächstes Mal früher prüfen?“ Das sind hilfreiche Beiträge für eine Team-Retrospektive.
Bewahren Sie das maßgebliche Diagramm im Diagramm- oder Architekturarbeitsbereich des Teams auf. NextRetro kann Diskussion und Nachverfolgung unterstützen, ist aber kein spezielles Werkzeug zur Erstellung von Kontextdiagrammen. Wählen Sie Retrospektiven-Ideen, um ein Format für die Koordinationsprobleme zu finden, die das Diagramm sichtbar macht.
Prüfliste für Kontextdiagramme
Bestätigen Sie vor dem Teilen, dass der Gegenstand genau benannt ist, Publikum und Zweck genannt werden, jede Linie eine verständliche Beschriftung hat, unsichere Beziehungen markiert sind, Ausschlüsse bei Bedarf eine andere zuständige Person nennen und die Version Datum sowie Pflegeverantwortung enthält.
Bitten Sie anschließend jemanden, der das Diagramm nicht erstellt hat, ein repräsentatives Szenario zu erklären. Die Rückfragen sind ein praktischer Verständlichkeitstest. Verwechselt die Person eine Datenbeziehung mit Genehmigungsbefugnis, ändern Sie die Beschriftung, bevor Sie das Diagramm als vereinbarte Grenze verbreiten.
Häufig gestellte Fragen
Ist ein Projektkontextdiagramm dasselbe wie ein C4-Kontextdiagramm?
Nicht immer. Ein C4-Systemkontextdiagramm beschreibt ein Softwaresystem und seine externen Nutzer und Systeme. Eine Projektskizze kann umfassendere organisatorische Beziehungen umfassen. Benennen Sie Ansicht und Zweck ausdrücklich, statt die Umfänge stillschweigend zu vermischen.
Wie viele Details gehören in ein Kontextdiagramm?
Nehmen Sie genug auf, um die Grenzentscheidung zu unterstützen und wichtige externe Beziehungen zu erkennen. Verschieben Sie Aktivitätsfolgen, Termine und interne technische Details in eigene Ansichten, wenn sie den Kontext schwer verständlich machen.
Kann ein Kontextdiagramm eine Umfangsbeschreibung ersetzen?
Nein. Es unterstützt die Diskussion über den Umfang, erfasst aber nicht jede Anforderung, jedes Abnahmekriterium, jede Verpflichtung und jeden Ausschluss. Stimmen Sie es mit den genehmigten Projektunterlagen ab und halten Sie die Entscheidungen aus der Diskussion fest.