Umfangsmodellierung

Ziel

Das Umfangsmodell dient dazu, vor jeder Erhebungsarbeit zu entscheiden, was zur Analyse gehört und was nicht. Es zieht eine Grenze und verbindet sie mit einem Urteil: jeder Prozess, jeder Akteur, jedes System und jedes Datum wird als innerhalb oder ausserhalb erklärt, mit dem Kriterium, das diese Einordnung begründet. Aus dieser Grenze folgen drei Entscheidungen, die nichts anderes so früh liefert. Sie legt eine vertragliche und schätzbezogene Grundlage fest: Aufwand wird beziffert und Pflichten werden nur gegen einen festgelegten Umfang geschrieben. Sie klärt Zugehörigkeitsstreitigkeiten: die Frage «Ist das im Umfang?» wird anhand geschriebener Kriterien entschieden statt nach der Meinung des Tages. Sie misst die Vollständigkeit: die erhobenen Anforderungen gegen den erklärten Umfang zu halten, bringt die vergessenen Zonen und die Überschreitungen zum Vorschein.

Das Ergebnis verbindet drei Formen: ein oder mehrere Diagramme der Beziehungen zwischen Elementen, eine oder mehrere Abhängigkeitsmatrizen und einen Text, der die beibehaltenen Elemente, die Einschlusskriterien und die kritischen Annahmen benennt, auf denen die Grenzziehung ruht. Erfolgt die Lieferung phasenweise, trägt es eine Grenze je Phase.

Einsatz

Wann einsetzen

• Beginn einer Initiative: die Grenze vor der Anforderungserhebung festlegen, damit die Einschluss-Entscheide eine Grundlage haben.
• Rahmung eines Vertrags oder Mandats: eine verteidigbare Linie für Pflichten, Schätzung und Änderungssteuerung geben.
• Wiederkehrende Zugehörigkeitsstreitigkeiten: ein geteiltes Modell entscheidet «Ist das im Umfang?» anhand geschriebener Kriterien.
• Mehrparteien- oder organisationsübergreifende Veränderung: die Einheiten, Systeme und externen Akteure benennen, die die Veränderung berührt.
• Phasen- oder iterative Lieferung: den Umfang je Phase beschreiben, damit jedes Inkrement seine eigene Grenze trägt.

Wann nicht einsetzen

• Grenze bereits festgelegt und stabil: bei einer kleinen, gut verstandenen Veränderung genügt eine einzeilige Umfangserklärung, das vollständige Modell ist Mehraufwand.
• Die Schwierigkeit ist die Zerlegung: die funktionale Dekomposition nutzen, um die Innenseite in Teile zu öffnen.
• Grenze im «Horizont», abhängig von der Position der Stakeholder: ein statisches Modell führt in die Irre, besser eine adaptive, meilensteinbasierte Planung.

Zwei Klassifikationsachsen

Ein Umfangsmodell liegt auf zwei unabhängigen Achsen. Die erste Achse sagt, was die Grenze zeigt. Von innen betrachtet zeigt sie die Elemente, die sie enthält; von aussen betrachtet zeigt sie die Elemente, die sie ausschliesst; von beiden Seiten betrachtet trägt sie Elemente auf beiden Seiten. Zu jeder dieser Sichten gehört eine bewährte Artefaktform.

Die zweite Achse, unabhängig von der ersten, sagt, welchen Umfang das Modell beleuchtet. Der Steuerungsumfang grenzt ab, was analysiert wird, die Rollen und Verantwortlichkeiten und was innerhalb oder ausserhalb der Organisation liegt. Der Bedarfsumfang umreisst die Bedürfnisse der Stakeholder, den zu liefernden Wert und die zu erkundenden Einheiten. Der Lösungsumfang deckt die erfüllten Anforderungen, den gelieferten Wert und die Auswirkung der Veränderung ab. Der Veränderungsumfang zählt die durchzuführenden Massnahmen, die betroffenen Stakeholder und die herbeizuführenden oder zu verhindernden Ereignisse auf. Ein und dasselbe Diagramm gehört zu beiden Achsen: es wird von einer Seite gesehen und beleuchtet einen Umfang. Die beiden Lesarten verbinden sich.

Das Modell und seine Form wählen

Die Wahl der Notation folgt daraus, was die Grenze zeigen muss. Geht es darum, zu sagen, was draussen bleibt, ist das Kontextdiagramm das Werkzeug: es setzt das System als einzelnen Prozess ins Zentrum, umgibt es mit den externen Einheiten, die mit ihm sprechen, und zeichnet nur die Flüsse, welche die Grenze überschreiten. Es ist die sparsamste Form eines Umfangs und die oberste Ebene eines Satzes von Datenflussdiagrammen. Geht es dagegen darum, zu detaillieren, was drinnen liegt, öffnet die funktionale Dekomposition die Innenseite in Funktionen und Teilfunktionen. Muss die Grenze beide Seiten zugleich zeigen, stellt das Anwendungsfallmodell die Akteure nach aussen und die Anwendungsfälle nach innen, in einen Kasten, der für das System steht. Das Venn-Diagramm wiederum stellt zwei Mengen und ihre Schnittmenge einander gegenüber.

Jede dieser Darstellungen wird durch die beiden anderen Ergebnisformen ergänzt. Der Text beschreibt die Elemente und vor allem die Kriterien, die einen Einschluss-Entscheid verteidigbar machen. Die Matrix legt die Abhängigkeiten zwischen Umfangselementen offen, jene, die ein Diagramm im Dunkeln lässt. Ein vollständiges Umfangsmodell verbindet alle drei, im Mass der Entscheidung, der es dient.

Die zu erkundenden Beziehungen

Zu prüfen, ob ein Umfang vollständig ist, läuft darauf hinaus, die Beziehungen zwischen seinen Elementen zu erkunden, denn eine vergessene Abhängigkeit verbirgt ein vergessenes Element. Fünf Beziehungsfamilien lohnen die Betrachtung, jede mit einer Diagrammfamilie verbunden. Die Eltern-Kind-Beziehung zerlegt ein Element in seine Teile, durch ein Organigramm, Teilprozesse oder ein Datenmodell. Die Funktion-Verantwortung-Beziehung knüpft eine Funktion an den Akteur, der sie ausführt, durch ein Prozessmodell, ein Sequenzdiagramm oder ein Anwendungsfallmodell. Die Lieferant-Abnehmer-Beziehung verbindet die Elemente über die Daten oder das Material, die sie austauschen, durch ein Datenflussdiagramm oder ein Prozessmodell. Die Ursache-Wirkung-Beziehung reiht die Elemente nach logischer Abhängigkeit, durch ein Ishikawa-Diagramm. Es bleiben die emergenten Eigenschaften, jene Ergebnisse, die eine Interaktion hervorbringt und die kein einzeln betrachtetes Element vorhersehen liess und die eine statische Grenzziehung nur schwer erfasst.

Der Detaillierungsgrad

Die wiederkehrende Schwierigkeit ist, zu wählen, in welcher Granularität die Elemente beschrieben werden. Der Zweck der Analyse legt diesen Grad fest. Ein und dasselbe Änderungsthema wird auf drei Arten beschrieben: durch Aufzählen der Elemente einzeln, durch das Einnehmen einer gewählten Zerlegungsebene oder durch Gruppieren der Elemente zu logischen Mengen. Ein Bündel von Prozessen erscheint so als Liste benannter Prozesse, als übergeordneter Prozess, der sie umfasst, oder als generische Funktion.

Zwei symmetrische Fehler lauern bei dieser Wahl. Zu grob, lässt das Modell die Grenzelemente in der Unschärfe. An diesen Randelementen kostet ein schlecht definierter Umfang am meisten: die Grauzone zeigt sich nach der Unterschrift, wenn sie zum Streit wird. Zu fein, kippt das Modell in die Analyseparalyse: es zerlegt über das hinaus, was der Umfangsentscheid verlangt, und die Übung hört auf, Unsicherheit zu verringern, und wird zu einer Bestandsaufnahme. Der richtige Grad verringert die Unsicherheit nützlich, ohne diese Schwelle zu überschreiten.

Die Annahmen und die Lebensdauer des Umfangs

Die Gültigkeit eines Umfangsmodells beruht auf Annahmen: der Definition der Bedürfnisse, der Kausalität der erwarteten Wirkungen, der Auswirkung der Veränderung, der Machbarkeit der Lösung. Diese Annahmen sind meist stillschweigend, und ein Modell, das akzeptiert scheint, ist es womöglich nur auf der Grundlage von Überzeugungen, die niemand ausgesprochen hat. Die Disziplin besteht darin, die kritischen Annahmen und ihre Folgen in das Modell selbst zu schreiben, neben die Grenzziehung, die sie stützen. Eine Grenze, die auf einer falschen Annahme akzeptiert wurde, ist ein aufgeschobener Streit.

Ein Umfang altert. Einmal festgelegt, wird er schwer zu ändern, aus politischen wie aus vertraglichen Gründen, selbst wenn mehrere Kräfte seine Gültigkeit untergraben: eine widerlegte Ausgangsannahme, eine Lage, die sich ändert, Bedürfnisse, die sich wandeln, eine technische Neuerung. Das Modell als starr zu behandeln, ist daher ein Fehler: es wird wieder gelesen und überarbeitet, ganz oder teilweise, jedes Mal, wenn eine dieser Kräfte auftritt. Eine Verwechslung bleibt zu vermeiden, zwischen dem Veränderungsumfang, der sagt, was verändert wird, und dem Lösungsumfang, der sagt, was die Lösung abdecken muss: ein und dieselbe Initiative unterscheidet sie, und sie zu verschmelzen erzeugt ein Modell, das über das eine oder das andere lügt.

KI-Überlegungen

Zwei Einsätze sind solide. Der erste ist der erste Entwurf: aus vorhandenen Prozessunterlagen, Akteurskarten oder Integrationsschemata schlägt ein Sprachmodell eine Liste interner und externer Elemente vor, einen Satz möglicher externer Einheiten und ein zu korrigierendes Kontextdiagramm. Es ersetzt das leere Blatt durch einen Rohentwurf, was bei einem Altsystem Wert hat, dessen tatsächlicher Fluss verloren gegangen ist. Der zweite ist der Abgleich: ein Umfangsmodell gegen die Liste der erhobenen Anforderungen zu halten, um die Elemente aufzuzeigen, die auf der einen Seite vorhanden und auf der anderen abwesend sind und die Abhängigkeitspaare vorzuschlagen, welche die Matrix speisen.

Drei Entscheidungen entziehen sich dem Werkzeug. Der Einschluss-Entscheid selbst ist eine politische und vertragliche Abwägung, die keine Eingabedaten enthalten. Die kritischen Annahmen setzen voraus, zu wissen, was die Organisation stillschweigend als gegeben hinnimmt, was ein auf generischen Texten trainiertes Modell nicht kennt. Die Grenzelemente, in denen die ganze Schwierigkeit steckt, verlangen das Urteil, zu dessen Ausübung die Technik existiert. Ein letzter Vorbehalt zu den Daten: interne Prozesskarten, auf denen die Namen von Partnern und Lieferanten stehen, einem externen Dienst vorzulegen, ist eine Frage der Vertraulichkeit und des Datenschutzes im Sinne des revidierten Datenschutzgesetzes (revDSG). Die Grenze ist der Ort, an dem diese sensiblen Namen erscheinen.

Beispiele

Ein Kanton stellt ein Portal zur Meldung eines Adresswechsels online, über das eine Einwohnerin ihren Umzug meldet, ohne an den Schalter zu gehen. Die Umfangsfrage lautet, was das Portal übernimmt und was es den bestehenden Systemen überlässt. Das Kontextdiagramm beantwortet sie mit einer einzigen Zeichnung: das Portal ist die zentrale Blase, und um es herum stehen die Einwohnerin, die meldet, der Identitätsanbieter, der sie authentifiziert, die kommunale Einwohnerkontrolle, welche die validierte Meldung erhält, und der Zahlungsdienstleister, der die Gebühr einzieht. Jeder Fluss, der die Grenze überschreitet, die eingereichte Meldung, die geprüfte Identität, die validierte Meldung, die Zahlungsbestätigung, ist eine zu untersuchende Schnittstelle.

Der Einschluss-Entscheid wird anschliessend Element für Element festgehalten, mit seinem Kriterium. Das Sortierkriterium ist der Bezug des Elements zur Veränderung: was das Portal erzeugt oder verändert, liegt drinnen, was es nur austauscht, liegt draussen. Diese Linie, vor der Erhebung gezogen und begründet, ist das, was der Vertrag beziffern und was die Abnahme prüfen wird.

Kosten

Werkzeuge

Die Wahl des Werkzeugs richtet sich nach dem erwarteten Einsatz des Modells. Für eine Grenzdiskussion unter versammelten Personen genügen das Whiteboard oder Papier, und ihr flüchtiger Charakter ist ein Vorteil, solange man noch sucht, wo die Linie verläuft. Ein Diagrammeditor (diagrams.net, Lucidchart, Visio) trägt das Kontextdiagramm und das Anwendungsfallmodell, sobald sie geteilt, versioniert und überarbeitet werden müssen. Die Tabellenkalkulation hält die Abhängigkeitsmatrix und die Tabelle der Einschluss-Entscheide, dort, wo Sortieren und Filtern besser sind als eine Zeichnung. Ein Modellierungswerkzeug (Enterprise Architect, Sparx) wird nötig, wenn das Umfangsmodell ein grösseres Modell speist, für Anforderungen oder Architektur, mit dem es kohärent bleiben muss. Ein Dokumentenraum oder ein Wiki schliesslich trägt die textuelle Umfangserklärung und das Register der Annahmen, die im Lauf ihrer Überarbeitungen lesbar und mit Zeitstempel versehen bleiben müssen.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.41 Scope Modelling: die Klassifikation von Umfangsmodellen danach, was die Grenze zeigt und welchen Umfang sie beleuchtet, die zu bestimmenden Elemente, der Detaillierungsgrad, die Annahmen und die Grenzen der Technik.
• Tom DeMarco, Structured Analysis and System Specification, Yourdon Press, 1978: der Ursprung des mehrstufigen Flussmodells, dessen oberste Ebene, das Kontextdiagramm, das System als einzelnen Prozess gegenüber seinen externen Einheiten setzt, die Umfangsgrenze von aussen betrachtet.
• Chris Gane und Trish Sarson, Structured Systems Analysis: Tools and Techniques, Prentice-Hall, 1979: die zweite Notation der strukturierten Analyse für das Kontextdiagramm, die dieselbe Grenzidee trägt.
• Ivar Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992: der Ursprung des Anwendungsfallmodells, dessen Systemkasten die Akteure nach aussen und die Anwendungsfälle nach innen stellt, ein von beiden Seiten betrachteter Umfang.
• Object Management Group, Unified Modeling Language (UML), v2.5.1: der aktuelle Standard für das Anwendungsfalldiagramm und die Grenze des Subjekts (System).