Interview mit Neil Maiden: Mit Zielen ans Ziel

Neil Maiden ist Professor für Digitale Kreativität an der Faculty of Management der Cass Business School, und Mitbegründer des Centre for Creativity in Professional Practice at City, University of London. Er führt interdisziplinäre Forschung durch im Softwareengineering, Kreativwissenschaften sowie integrierte Gesundheits- und Sozialwissenschaften.

Auf der ReConf 2017 hielt er einen Vortrag über kreatives Denken bei agilen Anforderungsprozessen (anschauen). Ich sprach auf der Konferenz mit Neil über zielbasierte Systementwicklung. Dies ist eine Übersetzung des Interviews, welches in Englisch im Formal Mind Blog zu lesen ist.

Wie werden Systeme entwickelt, wenn der Ausgangspunkt Ziele auf höchster Ebene sind?

Unser Ansatz basiert auf dem i* (i-star)-Framework für zielbasierte Modellierung. Zunächst müssen die Stakeholder und Akteure identifiziert werden. Es geht ja nicht um Ziele per se, sondern um die Ziele der verschiedenen Stakeholder und Akteure. Das können die Ziele einer Organisation sein, eines Individuums (mit einer Rolle), oder sogar Ziele eines Systems. Hierarchische Ziele funktionieren nur selten, da früher oder später Akteure gegensätzliche Ziele haben. Natürlich gibt es auch Abhängigkeiten zwischen Zielen, aber letzten Endes geht es darum, die Ziele gegeneinander abzuwägen und so viele Akteure – und deren Ziele – zu befriedigen.

Daher beginnen wir normalerweise mit den Akteuren und bauen ein zielbasiertes Modell für jeden Akteur. In einem komplexen System, wie einem System zur Luftraumüberwachung, können dies 30 bis 40 Akteure sein. Dazu gehören Organisationen, wie eine Luftlinie, eine menschliche Rolle, wie ein Pilot, oder eine beliebige Anzahl von Systemen, wie einem Radarsystem. Aber unserer Erfahrung nach muss man von unten nach oben, oder zumindest „von der Mitte aus“ das Modell aufbauen, um dabei alle Ziele, Aufgaben, Beschränkungen und Qualitätsansprüche von jedem Akteur zu verstehen. Dann erst werden die komplexen Beziehungen erstellt.

Man muss von unten nach oben, oder zumindest „von der Mitte aus“ das Modell aufbauen. Erst dann werden die komplexen Beziehungen aufgebaut. Twittern

Bei Euch wird i* eingesetzt, das ja nicht wirklich verbreitet ist. Kann man diese Ideen auch mit populären Modellierungssprachen umsetzen?

Leider bekommt man solche Modelle nicht mit bestehenden Methoden, daher bezeichne ich sie als schwach. Bei i* geht es um strategische Zielmodellierung, nicht darum, jedes Ziel zu modellieren. Also muss der Ingenieur oder Analyst erst einmal entscheiden, was überhaupt strategisch ist. Die Herausforderung ist es, sich nur die wirklich strategischen, für das System wichtigen Ziele, Aufgaben und Qualitäten zu konzentrieren, um diese Modelle zu erstellen. Dadurch ergibt sich ein Modell mit 300 bis 400 Elementen, verteilt auf 30 bis 40 Akteure. Aber das ist immer noch auf einer hohen Abstraktionsebene.

Von diesen Zielen und Aufgaben arbeiten wir uns herunter, indem wir Anwendungsfälle erstellen. Wir haben mit der halbautomatischen Generierung von Use Case-Modellen experimentiert, die von den Modellen abgeleitet werden. Aber wir fanden diese zu beschreibend, es gab nicht genug Raum für Kreativität. Statt dessen haben wir eine Menge von Richtlinien zum Herunterbrechen erstellt. Man nimmt die strategischen Ziele, die strategischen Akteure, und schaut sich die Aufgaben an, die sie erfüllen müssen. Dies nutzen wir als Bausteine, um eine konkrete Spezifikation aus Anwendungsfällen zu erstellen. Dabei benutzen wir nur selten visuelle Use-Case-Modelle, also die Kartoffel-und-Strichmännchen-Darstellung, da die Semantik dieser Diagramme schon immer schwach war. Statt dessen benutzen wir die deskriptiven Anwendungsfall-Schablonen.

Aber das Problem ist einfach, dass diese anspruchsvollen Zielmodelle einfach nicht weit genug verbreitet sind. Ich glaube nicht, dass die Notation das Problem ist. Das Problem ist eher der Kenntnisstand der Analysten, und Nutzer haben Probleme, die Modelle wirklich zu verstehen, wenn sie keine Ausbildung in Modellierung und Abstraktion bekommen haben. Es ist schwierig!

Wir nutzen diese Modelle intern, und manchmal zeigen wir sie auch Ingenieuren oder entsprechend ausgebildeten Stakeholdern. Aber normalerweise benutzen wir Darstellungen, die von den internen Modellen abgeleitet wurden. Zum Beispiel haben wir eine Serie von Schablonen entwickelt, mit denen wir halbautomatisch Anforderungstexte generieren können. Mit einem einfachen Knopfdruck (mehr oder weniger), werden 200 bis 300 einfache Anforderungen generiert. Das scheint die Produktivität erheblich erhöht zu haben.

Wir zeigen normalerweise eine abgeleitete Version des Modells, statt dem eigentlichen Modell. Das ist sehr effektiv für die Kommunikation mit den Stakholdern. Twittern

Das klingt nach einem guten Ansatz, um Anwendungsfälle zu bekommen, die mit den Zielen konsistent sind. Was passiert über einen längeren Zeitraum?

Das ist ein guter Einwand. Wir haben immer angenommen, dass bidirektionale Nachverfolgbarkeit ein leicht zu lösendes Problem des Änderungsmanagements wäre. Aber um ehrlich zu sein, Dort gibt es in der Tat ein Problem. Man kann natürlich argumentieren, dass das Modell nur der Ausgangspunkt ist: Das Modell ist nur zu einem einzigen Zeitpunkt wirklich korrekt. Direkt nach dessen Validierung ist das Modell potentiell schon wieder invalide. Wir müssen auch umsichtig sein, wie viel uns das Modell wirklich geben kann. Es geht ja um einen iterativen Prozess: Per Definition versuchen wir, uns zu verändern, zu einer besseren Lösung. Das Modell ist lediglich ein Snapshot zu einem Zeitpunkt in diesem Prozess. Für uns ist das Modell nicht das Endprodukt, sondern Mittel zum Zweck. Das Modell hilft, die richtigen Fragen zu stellen und die richtigen Entscheidungen zu treffen, und das kann sogar ohne Referenz auf das Modell geschehen. Aber das Modell hat den Rahmen gesetzt, um die Entscheidungen zu finden, und diese richtig zu treffen. Nur selten machen wir das Modell zum Teil der Spezifikation. Es ist ein internes Werkzeug, welches die Stakeholder nur selten zu sehen bekommen.

Außerdem ist das Modell dynamisch, und kein statisches Diagramm. Manchmal erwarten Menschen, dass das Modell als statisches Diagramm vollständig visualisiert werden kann. Aber es werden ja ständig Dinge ein- oder ausgeschaltet, und mit geänderten Rahmenbedingungen bekommt man auch ein verändertes Modell. Ein Modell ist ein viel komplexeres Artefakt, und wird auch Teil des zugrundeliegenden Domänenmodells. Entwickelt wird ein kombiniertes Ziel- und Domänenmodell für einen bestimmten Industriesektor.

Kannst Du eine Empfehlung aussprechen? Wer sollte zielbasierte Modellierung anwenden, und worauf sollte geachtet werden?

Um Ziele gut zu modellieren, braucht man extrem gute analytische Fähigkeiten. Ich lese sowohl Forschungsergebnisse und sehe auch, was in der Industrie passiert. Und vieles, was ich sehe, halte ich für falsch, oft fehlt ein klares Verständnis der Semantik. Aber darauf basieren die Entscheidungen, und das kann zu falschen Entscheidungen führen. Was wir also eigentlich brauchen sind bessere analytische Fähigkeiten. Wir brauchen Leute, die in der Lage sind, lang und tief über Probleme nachzudenken. Agile Vorgehen, befreit uns ein wenig davon, denn dort wird in kleinen Schritten etwas konstruiert und dann beobachtet.

Aber das ist eine lange Antwort, die kurz zusammengefasst werden kann: Man braucht einfach die richtigen Kenntnisse, um solche Modelle entwickeln zu können. Man braucht ausreichend Problemanalyse vorweg. Man muss sich bewusst sein, dass das Zielmodell ein Domänenmodell enthält, welches nur mit ausreichenden Kenntnissen der Domäne entwickelt werden kann. Und man muss wissen, dass es immer Vor- und Nachteile gibt, es gibt nichts umsonst. Ohne das richtige Investment wird die Arbeit einfach verpuffen. Diese Themen sind schwierig und komplex. Das macht sie ja auch so interessant.

Bild: Neil Maiden