Collaborative Modeling: Software-Architektur mit den Stakeholdern gestalten

Entwicklungsteams erhalten in den vergangenen Jahren mehr Verantwortung: Als crossfunktionale Teams oder Produktteams entwerfen sie Softwarearchitekturen und ermitteln Anforderungen. Dazu brauchen sie Hilfsmittel, um ihre Stakeholder zu verstehen, gemeinsam Entwurfsentscheidungen zu treffen und diese zu kommunizieren. Für diese Zwecke geeignete Workshop-Methoden werden unter dem Begriff "Collaborative Modeling" (im Weiteren "CoMo") zusammengefasst. CoMo gehört auch in den Werkzeugkoffer von Business Analysts und Requirements Engineers, weil sie damit Geschäftsprozesse und Anforderungen klären können.

Was ist Collaborative Modeling?

Gemeinsames Modellieren von Anforderungen, Architektur und Geschäftsprozessen – das zeichnet CoMo aus. Dabei schließt "gemeinsam" oft mehr ein als nur die Mitglieder eines Entwicklungsteams. Da für die Teilnahme an CoMo-Workshops kein Informatik-Spezialwissen notwendig ist, können Fachleute, das Management und andere Personen ohne IT-Hintergrund aktiv zur Modellierung beitragen. Das ist auch notwendig, denn Entwicklungsteams müssen die Domäne verstehen, also die Aufgaben und Arbeitsabläufe ihrer Anwender und Anwenderinnen kennen. Nur so können sie fachlich wertvolle Anwendungen entwickeln. CoMo soll das Fachwissen aus den Köpfen der Fachleute in die Köpfe von Entwicklerinnen, Testerinnen, Product Ownern, Produktmanagern und Business-Analysten transportieren – zu jedem, der an der Softwareentwicklung beteiligt ist. Entscheidend ist die direkte Rückkopplung zwischen allen Beteiligten. Das unterscheidet CoMo-Methoden von klassischen Techniken der Anforderungsanalyse, bei denen etwa Interviews geführt und daraus Anforderungsdokumente erstellt werden.

Besonders verbreitet ist CoMo im Domain-driven Design (DDD) – einem erfolgreichen Ansatz, der die Fachlichkeit ins Zentrum der Softwareentwicklung stellt. Fachsprache, Ereignisse, Handlungen, Arbeitsmittel und Strukturen der Domäne bilden das Domänenmodell, das die Entwicklungsteams in der Software abbilden. Ein valides Domänenmodell lässt sich nur gemeinsam von Entwicklungsteam und Fachleuten erstellen. CoMo ist keine Einbahnstraße. Das Management und die Fachleute können durch die Zusammenarbeit mit Entwicklungsteams verstehen, welche Möglichkeiten Software eröffnet und wie sich diese auf ihre Arbeit auswirken wird. Mittlerweile hat sich CoMo sogar außerhalb seines ursprünglichen Anwendungsbereichs – der Softwareentwicklung – etabliert. Einige CoMo-Methoden unterstützen beispielsweise bei der Prozessoptimierung und der Organisationsentwicklung.

Grundlegende Konzepte des Collaborative Modeling

Die ausgewählten CoMo-Methoden in diesem Artikel sind unabhängig voneinander entstanden. Sie teilen aber einige grundlegende Konzepte:

• Gruppenarbeit aller Beteiligten: Die Beteiligten auf Fach- und Entwicklungsseite klären gemeinsam Prozesse und Anforderungen, statt dass einzelne Spezialisten auf der Basis von Interviews und Dokumentanalysen diese Themen spezifizieren. CoMo-Methoden sehen gemeinsame Workshops vor; manchmal in großen Gruppen, manchmal mit wenigen Vertretern der verschiedenen Seiten.
• Geschichten erzählen: In den Workshops diskutieren die Beteiligten über konkrete Szenarien statt über abstrakte Abläufe. Szenarien werden wie Geschichten erzählt. Haben alle Beteiligten die Szenarien verstanden, folgt der Aufbau der für die Softwareentwicklung nötigen Abstraktionen und – so vollständig wie möglichen – Abbildungen von Regeln und Fallunterscheidungen.
• Über eine gemeinsame Sprache ein wechselseitiges Verständnis anstreben: Alle CoMo-Methoden stellen die Fachsprache in den Vordergrund. Die verschiedenen Workshoptechniken sollen den Beteiligten helfen, diese zu verstehen. Unschärfen und Mehrdeutigkeiten werden ausgeräumt.
• Gemeinsam visuelle Modelle erstellen: Die Beteiligten erzählen Geschichten nicht nur mündlich, sondern halten sie auch in visuellen Modellen fest. Die Notationen sind einfach; als Werkzeuge dienen (digitale) Whiteboards und Post-its. Die Modelle zeigen den Stand der Diskussion und dokumentieren die gemeinsame Sicht auf das Thema.

CoMo-Methoden im Kurzporträt

Ein Überblicksartikel wie dieser kann sich nur auf einige wenige Methoden beschränken und auch diese nicht in vollem Umfang beschreiben. Er soll dazu anregen, sich näher mit CoMo-Methoden zu beschäftigen. Es folgen Beschreibungen der Methoden und ihrer Einsatzzwecke sowie Beispiele aus der Domäne "Flughafen", wo Personen auf den Bus zum Flugzeug (oder vom Flugzeug zum Terminal) warten. Die Beispiele zeigen die Organisation des Bustransfers und welche Anforderungen an ein neu zu entwickelndes Dispositionssystem gestellt werden könnten.

Domain Storytelling

Im Domain Storytelling erzählen die Beteiligten beispielhafte Geschäftsprozesse. Satz für Satz visualisiert eine Moderatorin oder ein Moderator mit einer Bildsprache (siehe Abbildung 1). Da jede Geschichte einen konkreten Fall beschreibt, beispielsweise einen einfachen "Happy Path" oder einen wichtigen Sonderfall, kommt die Bildsprache ohne Symbole für Fallunterscheidungen aus. Wenige Domain Stories reichen, um selbst komplexe Geschäftsprozesse zu verstehen. Domain Stories eignen sich besonders gut, um zu diskutieren, wer was womit mit wem und wozu macht.

Domain Story – Ist-Prozess "Bustransfer vom Gate zum Flugzeug" mit Legacy-Dispositionssystem (Abb. 1)

Einsatzzwecke sind unter anderem:

• Prozessanalyse und -design
• Zerlegen von monolithischen Systemen
• Ableiten von Anforderungen
• Entwurf eines Domänenmodells
• Kommunizieren von Veränderungen zwischen Ist- und Soll-Prozessen

Event Storming

Beim Event Storming erarbeiten sich die Beteiligten mit Klebezetteln und Stiften ein Bild eines Geschäftsprozesses. Das Bild entsteht "bottom-up" als Folge von Domain Events, den fachlichen Ereignissen wie "Flugzeug gelandet" oder "Auftrag angenommen". Die Klebezettel erzählen eine Geschichte. Die Beteiligten können Inkonsistenzen und Reibungspunkte schnell und zuverlässig entdecken und sehen, wie das gemeinsame Verständnis nach und nach an der Wand entsteht. Namensgebend für Event Storming ist, dass im Workshop zunächst alle Beteiligten (wie im Brainstorming) unkoordiniert "herausstürmen", was in der Domäne passiert. Dazu schreiben sie, ohne sich abzusprechen, Domain Events auf gelbe Klebezettel und heften sie an eine Wand (siehe Abbildung 2). Je nach Ziel des Workshops führt die Moderatorin schrittweise weitere Farben ein, etwa Pink für Hot Spots (Probleme, Konflikte, Fragen) und Lila für Policies (Geschäftsregeln).

Event Storming – Ist-Prozess "Bustransfer vom Flugzeug zum Terminal" (Abb. 2)

Einsatzzwecke sind unter anderem:

• Prozessanalyse und -design
• Zerlegen von monolithischen Systemen
• Entwurf eines Domänenmodells
• Systementwurf

Example Mapping

Ausgangspunkt für das Example Mapping sind grobe Anforderungen, etwa in Form von User Stories. Anhand von Beispielen klären Fachleute und Mitglieder eines Entwicklungsteams die fachlichen Regeln oder Randbedingungen einer Anforderung, um daraus Akzeptanztests abzuleiten. Dazu notieren sie auf verschiedenfarbigen Karten (siehe Abbildung 3) Anforderungen (gelb), Regeln/Akzeptanzkriterien (blau), konkrete Beispiele (grün) und offene Fragen (orange). Dabei werden die Beispiele den Regeln zugeordnet (englisch "mapping" – daher der Name der Methode). Das kann sowohl top-down erfolgen (also eine Regel mit Beispielen verdeutlichen), als auch bottom-up (also aus Beispielen neue Regeln ableiten).

Example Mapping für eine Anwendung für Busfahrer (Abb. 3)

Einsatzzwecke sind unter anderem:

• Klären und Kleinschneiden von Anforderungen, zum Beispiel im Rahmen des Backlog Refinement
• Ableiten von Akzeptanzkriterien und Testfällen
• Vorbereitung auf Testautomatisierung mit der Beschreibungssprache Gherkin

User Story Mapping

User Story Mapping kommt aus der agilen Community. Eine User Story Map strukturiert Anforderungen in zwei Dimensionen – sowohl in der horizontalen als auch in der vertikalen:

• Die horizontale Dimension besteht aus Karten mit grob formulierten Prozessschritten. Von links nach rechts ergeben sie eine zusammenhängende Geschichte aus Sicht der Benutzer einer zu entwickelnden Anwendung.
• In der vertikalen Dimension sind die User Stories aufgetragen – meist nach Priorität sortiert (siehe Abbildung 4). Das hier ebenfalls erfolgende Zuordnen der User Stories zu den groben Prozessschritten ("mapping") war auch für diese Methode namensgebend.

User Story Map für eine Anwendung für Busfahrer (Abb. 4)

Einsatzzwecke sind unter anderem:

• Klären von Anforderungen beziehungsweise Backlog Refinement
• Ausarbeiten eines Minimum Viable Product
• Planung von Produktversionen