Neil Maiden ist Professor für Digitale Kreativität an der Cass Business School, Fakultät für Management, und Mitbegründer des Centre for Creativity in Professional Practice an der City, University of London. Er initiiert und leitet interdisziplinäre Forschung in den Bereichen Software Engineering, Kreativitätswissenschaft sowie integrierte Gesundheits- und Sozialversorgung.
Als Keynote Speaker auf der ReConf 2017 sprach er über kreatives Denken in agilen Anforderungsprozessen.online ansehen). Auf der Konferenz sprach Michael Jastram mit Neil über zielebasierte Systementwicklung.
Ich entwickle Systeme, indem ich von den übergeordneten Zielen ausgehe. Zuerst definiere ich die allgemeinen Anforderungen und Ziele des Systems. Dann zerlege ich diese in detailliertere funktionale und nicht-funktionale Anforderungen. Basierend darauf entwerfe ich die Architektur des Systems, wähle geeignete Technologien aus und plane die Umsetzung. Anschließend wird das System entwickelt, getestet, bereitgestellt und gewartet, wobei während des gesamten Prozesses die ursprünglichen Ziele im Auge behalten und bei Bedarf Anpassungen vorgenommen werden.
Wir übernehmen einen Ansatz, der auf i* (i-Stern) Rahmenwerk für Ziel- und Absichtsmodellierung. Das Schlüsselelement ist, zunächst zu verstehen, wer Ihre Stakeholder und Akteure sind. Es geht nicht um Ziele an sich, sondern um die Ziele, die die verschiedenen Stakeholder und Akteure haben. Dies können die Ziele einer Organisation, von Personen mit bestimmten Rollen oder sogar Ziele sein, die einem System zugeschrieben werden. Wenn Sie versuchen, hierarchische Zielmodelle zu erstellen, werden Sie fast immer scheitern, denn zwangsläufig haben unterschiedliche Akteure unterschiedliche, widersprüchliche Ziele. Es gibt immer noch Abhängigkeiten zwischen den Zielen, und letztendlich geht es darum, den richtigen Kompromiss zu finden und zu versuchen, so viele Stakeholder und ihre Ziele wie möglich zu erfüllen.
Normalerweise beginnen wir mit Akteuren und erstellen für jeden einzelnen Akteur ein zielbasiertes Modell. In einem komplexen System, wie einem Flugverkehrsmanagementsystem, könnten dies 30 bis 40 verschiedene Akteure sein. Dies könnte eine Organisation, wie eine Fluggesellschaft, oder eine menschliche Rolle, wie ein Pilot, oder beliebig viele Systeme, wie ein Radarsystem, sein. Aber unserer Erfahrung nach müssen Sie von unten nach oben oder zumindest “von der Mitte aus” aufbauen und alle Ziele, Aufgaben, Einschränkungen und Qualitätsanforderungen verstehen, die jeder Akteur wünscht. Dann müssen Sie die komplexen Abhängigkeiten zwischen ihnen aufbauen.
Sie müssen von unten nach oben, oder zumindest von innen nach außen aufbauen. Dann können Sie die komplexen Abhängigkeiten aufbauen.
Sie sagten, dass Sie i* verwenden, was nicht sehr verbreitet ist. Können Sie diese Ideen mit den heute gängigen Modellierungstechniken umsetzen?
Das Problem ist, dass man diese Modelle mit bestehenden Methoden einfach nicht erstellen kann, und deshalb halte ich sie für schwach. Bei i* geht es um strategisches Zielmodellierung, es geht nicht darum, jedes Ziel zu modellieren. Daher muss der Ingenieur oder Analyst entscheiden, was überhaupt strategisch ist. Wenn man sich alle Ziele und Aufgaben vorstellt, die ein Fluglotse bei seiner Arbeit zu erreichen versucht, werden nur wenige davon strategisch sein. Aber einige davon sind es. Der Schlüssel liegt darin, sich ausschließlich auf die strategischsten systemspezifischen Ziele, Aufgaben und Qualitäten zu konzentrieren, um diese Modelle zu erstellen. Daher kann es sein, dass man mit einem Modell von 300 bis 400 Elementen endet, die sich auf 30 bis 40 Akteure verteilen. Aber das ist immer noch auf einer recht hohen Ebene.
Wir gehen dann von diesen Zielen und Aufgaben aus, indem wir Anwendungsfälle erstellen. Wir haben mit einem halbautomatischen Mittel zur Generierung von Anwendungsfallbeschreibungen aus diesen Modellen experimentiert, stellten aber fest, dass dies zu deskriptiv war und keine Kreativität oder Flexibilität zuließ. Stattdessen geben wir eine Reihe von Richtlinien für die Detaillierung an. Sie nehmen also die strategischen Ziele und strategischen Akteure, betrachten die Aufgaben, die sie erreichen wollen, und verwenden diese als Bausteine, um eine konkretere Anwendungsfallspezifikation zu erstellen. Wir neigen dazu, keine Anwendungsfallmodelle, die Kartoffel-und-Strichmännchen-Diagramme, zu verwenden, da ich denke, dass die Semantik immer schwach war. Wir ziehen es vor, die deskriptivere Vorlagenversion einer Anwendungsfallspezifikation zu verwenden.
Aber das Problem ist, dass nicht genügend Leute diese fortgeschrittenen Zielmodelle verwenden. Ich glaube nicht, dass es ein Problem mit der Notation ist, ich glaube, es ist ein Problem mit den Fähigkeiten von Analysten und Benutzer haben Schwierigkeiten, diese Modelle vollständig zu verstehen, es sei denn, man ist in Modellierung und Abstraktion ausgebildet. Es ist schwierig! Wir verwenden sie als interne Modelle und zeigen sie vielleicht Ingenieuren und geschulten Stakeholdern. Stattdessen verwenden wir Darstellungen, die von diesen internen Modellen abgeleitet sind. Zum Beispiel haben wir eine Reihe von Vorlagen entwickelt, die semi-automatisch generierte Anforderungsaussagen produzieren, zum Beispiel. Mit einem Knopfdruck, mehr oder weniger, kann man also 200-300 grundlegende Anforderungsaussagen erstellen. Das schien einen erheblichen Produktivitätsgewinn gebracht zu haben.
Wir zeigen normalerweise eine abgeleitete Version und nicht das Modell selbst. Das ist ziemlich effektiv in der Kommunikation mit Stakeholdern.
Das scheint ein großartiger Ansatz zu sein, um konsistente Anwendungsfälle zu finden, die mit den Zielen übereinstimmen. Was passiert mit ihnen im Laufe der Zeit?
Das ist ein valider Punkt, und wir sind immer davon ausgegangen, dass eine bidirektionale Rückverfolgbarkeit ein relativ einfacher Aspekt des Änderungsmanagements sein würde. Aber ehrlich gesagt, ich stimme zu, dass es ein Problem gibt. Man könnte argumentieren, dass das Modell ein Ausgangspunkt ist. Das Modell ist nur zu einem bestimmten Zeitpunkt gültig. Unmittelbar nach seiner Validierung ist das Modell potenziell wieder ungültig. Wir müssen vorsichtig sein, wie viel uns ein Modell hier wirklich geben kann. Sie befinden sich in einem iterativen Prozess, per Definition versuchen Sie zu ändern, zu verbessern. Das Modell ist lediglich eine Momentaufnahme zu einem Punkt in diesem Prozess.
Für uns ist das Modell nicht das Ziel, sondern das Mittel zu etwas anderem.
Das Modell dreht sich darum, die richtigen Fragen zu stellen und die richtigen Entscheidungen zu treffen, was tatsächlich ohne Bezug auf das Modell geschehen könnte. Aber das Modell hat die zu treffenden Entscheidungen auf die richtige Weise formuliert. Wir präsentieren das Modell nicht oft als Teil der Spezifikation. Es ist ein internes Werkzeug, aber nichts, was man den Stakeholdern normalerweise zeigt.
Das Modell ist also eine dynamische Entität. Es ist kein statisches Diagramm. Viele Leute denken, ein Modell müsse ein statisches Diagramm sein, das man als Ganzes sehen kann. Aber man schaltet ständig verschiedene Dinge ab und an, mit unterschiedlichen Annahmen erhält man ein anderes Modell. Ein Modell ist ein viel komplexeres Artefakt und wird auch Teil des zugrundeliegenden Domänenmodells. Was wir am Ende bauen, ist ein kombiniertes Ziel- und Domänenmodell für einen bestimmten Sektor.
Wer sollte zielbasiertes Modellieren verwenden und worauf sollte man achten?
Um Ziele gut modellieren zu können, braucht man ein hohes Maß an analytischen Fähigkeiten. Ich schaue mir wissenschaftliche Arbeiten an und sehe, was Unternehmen tun, und ich denke, vieles davon ist falsch, ohne richtiges Verständnis der Semantik. Aber man verlässt sich darauf, um Entscheidungen zu treffen, und das kann zu falschen Entscheidungen führen. Als Gemeinschaft brauchen wir also mehr richtige analytische Fähigkeiten. Wir brauchen Menschen, die fähig und willens sind, lange und gründlich über die Probleme nachzudenken. Agil entbindet einen davon ein wenig, da es dazu ermutigt, nur ein wenig nachzudenken und dann etwas zu bauen und zu sehen, was passiert.
Das ist eine langatmige Art zu sagen: Sie benötigen die richtigen Fähigkeiten, die mit der Entwicklung dieser Modelle verbunden sind. Sie benötigen genügend anfängliche Problemanalyse und müssen sich bewusst sein, dass im Zielmodell ein Domänenmodell enthalten ist, was entsprechende Domänenerfahrung erfordert. Sie müssen sich bewusst sein, dass es einen Kompromiss gibt, nichts ist umsonst. Ohne die richtige Investition wird sich Ihre Mühe in Luft auflösen. Diese Dinge sind hart und komplex. Deshalb sind sie so interessant.
Bild: Neil Maiden / BigStock
