Management in der UML-Falle

Der Titel ist provokant. Das ist mir bewusst. Ich möchte zeigen, dass der unreflektierte Glaube in UML-Modelle zu einem echten Problem im Projekt führen kann. Und das droht besonders bei einem zeitlich engen Projektplan. Also genau dann, wenn man geneigt ist, es bei UML-Diagrammen zu belassen.

Der Werkzeugkasten UML

Die Unified Modelling Language –kurz UML- ist an sich gar nicht schlecht. Ganz im Gegenteil. Sie fasst verschiedene grafische Werkzeuge und Notationen für die Spezifikation von Software zusammen. Dazu gehören sehr unterschiedliche Diagrammtypen wie beispielsweise Aktivitäts- und Sequenzdiagramme zur grafischen Darstellung von Abläufen oder unterschiedliche Klassenmodelle zur Zerlegung der realen Welt in handhabbare Objekte. Und wie das bei Modellen eben so ist, haben sie Vor- und Nachteile. Einerseits machen sie die schier unvorstellbare Komplexität der echten Welt fassbar, andererseits laufen sie aber auch Gefahr, die Realität zu sehr zu vereinfachen oder zu oberflächlich zu betrachten. Wie hilfreich ein Modell wirklich ist, hängt letztlich von dem Modellierer ab – und der Fähigkeit des Empfängers, es richtig zu lesen und zu interpretieren.

Die UML definiert einen sehr guten Werkzeugkasten. Leider ist aber eine gut eingerichtete Tischlerwerkstatt kein Garant dafür, dass dort auch gute Möbel entstehen. UML verhindert eben nicht, dass man einen Stuhl mit vier Beinen entwirft aber nur drei Beine anfertigt. Das wird wackelig!

Ich möchte nicht auf all die verschiedenen Werkzeuge des UML eingehen. Die Vor- und Nachteile der diversen Modelltypen und Notationen mögen andere diskutieren. Mir geht es vielmehr um ein prinzipielles Problem, das mir in IT-Projekten immer wieder begegnet. Es sind der ungebrochene Glaube an diese Modelle und die Ansicht, man brauche für eine gute Fachspezifikation lediglich genug UML-Modelle und alles sei umfassend spezifiziert. Rein theoretisch reichen die richtigen Modelle in der richtigen Detaillierung. Praktisch habe ich das noch nicht angetroffen. Sich auf grafische Diagramme mit halbherzigen Beschreibungen zu verlassen, betrachte ich gelinde gesagt als abwegig.

In der UseCase-Falle

Ich möchte das stellvertretungsweise an Use Cases festmachen. Es gibt bestimmt noch andere UML-Modelle, die jenseits des UML ergänzt werden sollten. Sehr schnell werden flugs ein paar UseCase-Modelle gemalt, um sich einen Überblick der erforderlichen Funktionalitäten des zu entwickelnden Systems zu machen. Das könnte dann beispielsweise wie folgt aussehen (Arbeitsaufwand ca. 20 Minuten):

UseCase-Modell für ein fiktives OnlineBanking

Wir haben als Akteur den Kunden in der Mitte. Und darum ranken sich die verschiedenen Anwendungsfälle, die in diesem Fall ein OnlineBanking-System bereitstellen soll. Links unten (rot eingefärbt) ist der Use Case “Konto anlegen”, für den ich in einem anderen Artikel ein exemplarisches Storyboard vorgestellt habe. Für einen ersten Überblick ist das auch gut geeignet. Um etwas genauer zu beschreiben, was die einzelnen Blasen bedeuten sollen, werden sie mit kurzen Anmerkungen versehen. Wenn es sich um halbwegs gewissenhafte Modellierer handelt, werden noch Vor- und Nachbedingungen festgehalten. Die gängigen Modellierungwerkzeuge bieten solche Möglichkeiten. Häufig bleibt es aber genau dabei. Was wirklich Schritt für Schritt in dem einzelnen Use Case geschieht, wird meistens nicht beschrieben – obwohl die meisten Modellierungswerkzeuge auch diese Möglichkeit bieten. Und genau dort setzt meine Kritik an. Es gibt sehr gute Techniken, um Use Cases effektiv zu beschreiben. Ich möchte da mal wieder auf textliche Use Cases verweisen, wie sie von Alistair Cockburn entwickelt wurden. Und dafür braucht man keine Software-Entwicklungsumgebung. Ein schlichter Texteditor reicht vollkommen aus. Und das ganze noch als Wiki ins Intranet gestellt, ist wirklich charmant: Jeder vom Projektteam kann es ohne Installation komplexer Werkzeuge lesen, und die textlichen Use Cases sind einfach allgemeinverständlicher als bisweilen esoterisch anmutende Diagramme.

Zwang zur Genauigkeit

Derart verfasste textliche Use Cases zwingen den Autor förmlich genau nachzudenken, wie die einzelnen Schritte eines Ablaufs sind und welche Ausnahmen bzw. Alternativabläufe es dafür gibt. Keine Chance, sich hinter Blasen und Pfeilen zu verstecken! Letztendlich steht da Wort für Wort genau, was das System leisten soll. Ich meine, es gibt mehrere Gründe, warum häufig auf textliche Use Cases verzichtet wird. Zuerst einmal erfordert es Übung, Use Cases gut und verständlich zu schreiben. Obwohl die Technik sehr einfach ist, dauert es wirklich seine Zeit, bis präzise und brauchbare Ergebnisse erzielt werden. Das kann auch unter Anleitung mal zwei, drei Monate dauern. Ich habe Projekte erlebt, in denen Fachanwender für diese Aufgabe vorgesehen waren. Das führte erwartungsgemäß nicht zu dem gewünschten Ergebnis. Auch ein erfahrener Versicherungskaufmann ist nicht notwendigerweise ein guter Analytiker. Und den braucht es eben zur UseCase-Beschreibung.

Kleiner Einschub: Ursprünglich ist SQL (also diese Datenbankabfragesprache) mit der Hoffnung verbunden gewesen, Fachanwender könnten so selbst die gewünschten Informationen aus der Datenbank herausziehen. SQL ist eine strukturierte Programmiersprache, die der normalen Alltagssprache ähnelt. “Select Blogbeitrag from WordPress where Blog = “lohmy.de” and date = 20100504” könnte ein Statement sein, welches (sehr vereinfacht) zu diesem Artikel führt. Es hat sich aber gezeigt, dass Fachanwender nicht in der Lage sind, SQL produktiv zu nutzen. SQL ist einfach zu komplex. Warum schreibe ich das? Was von IT-Strategen zur Einbindung von Fachexperten in den Spezifikationsprozess entwickelt worden ist, führt nicht immer zum Ziel. Das stellt wohl auch ein Usability-Problem dar, welches sich aber jenseits von Software-Oberflächen bewegt.

Zurück zum Thema. Zum anderen ist das Schreiben von textlichen Use Cases dem ersten Anschein nach zu zeitaufwendig. Das Schreiben eines etwas komplexeren Uses Cases kann zwei Tage dauern. Dazu kommt der Abnahmeprozess mit anschließender Überarbeitung. Alles in allem kann man für einen Use Case auch mal eine Arbeitswoche oder auch noch mehr aufwenden. Und da man ja im Projekt immer unter Zeitdruck steht, möchte man darauf gerne verzichten. Ein weiterer Grund, warum solche textlichen Use Cases gerne mal nicht in die Liste der Projektergebnistypen aufgenommen werden, ist die Tatsache, dass sie wenig Interpretationsspielraum übrig lassen. Wenn der Kunde nun also einen Use Case abnimmt, legt er sich fest. Genau so soll es sein! Das mögen Kunden manchmal nicht so gerne tun. Man lässt sich gerne immer noch einen Schlupfwinkel offen, ala: “Das haben wir aber ganz anders verstanden.”

Viele UML-UseCase-Modelle, die mir in Projekten begegnet sind, lassen einen derart großen Interpretationsspielraum, dass ich es als fahrlässig betrachte, dass damit millionenschwere Projekte betrieben werden. Irgendwann rächt sich diese fehlende Verbindlichkeit. Schlimmstenfalls nach Einführung der Software, wenn die Anwender die Hände über dem Kopf zusammen werfen. Aber dann ist das Kind bereits in den Brunnen gefallen. Jetzige Rettungsversuche sind immens teuer (siehe hierzu ROI-Berechnung am Beispiel einer Fachapplikation). Ach, hätten wir doch vor einem Jahr etwas mehr in textliche Use Cases investiert.

Kernkonzepte – ein weiteres Opfer auf dem UML-Altar

Es sind nicht nur die textlichen Use Cases, die den UML-Diagrammen voll Frömmigkeit oder Unwissenheit geopfert werden. Da gibt es noch andere Kandidaten. In einem sehr umfangreichen und politisch sehr anspruchsvollen Projekt haben wir zuvorderst begonnen, im Rahmen von Kernkonzepten die allgemeine Problemlage zu identifizieren und grobe Lösungsansätze zu entwickeln. Ha, das war dem Kunden – ich gebe zu, es war ein sehr IT-naher Kunde- gar nicht recht. Der Kunde wollte endlich Ablauf- und Klassendiagramme sehen. Und das bevor uns überhaupt die Problemlage klar war! Wenn man zu früh mit solchen Diagrammen beginnt, läuft man Gefahr, sich zu schnell in das Detail zu verlieben. Da hat man Diagramme, die alle ganz toll aussehen – aber leider falsch sind. In meinem Studium habe ich gelernt, dass die erste Idee selten die beste sei. Wenn man nun zu früh in detaillierte Ergebnistypen wie Ablauf- und Klassendiagramme einsteigt, besteht die Möglichkeit, dass man etwas mit aller Detailverliebtheit darstellt, was niemand braucht. Wie groß sind die Kosten, wenn das erst Monate später im Projekt auffällt. Richtig: immens!

Es ist sehr viel sinnvoller zu Beginn mit groben Werkzeugen wie Texten (unterstützt von schnellen Skizzen) dem Problem zu Leibe zu rücken. Wir beginnen einen Produktentwurf für ein Auto ja auch nicht mit dem Rapidographen sondern mit dem Bleistift 6B oder fettem Edding. Was der Bleistift 6B für den Produktentwurf ist, ist das Kernkonzept für das IT-Problem. Leider werden Kernkonzepte häufig aufgrund ihrer Vogelperspektive vom Tisch gewischt. Aber genau diese Perspektive braucht es zu Beginn eines Projekts. Diagramme, wie ich sie andauernd erlebe, sind meines Erachtens nicht dazu in der Lage, diese Perspektive dem Kunden zu verdeutlichen.

Vogelperspektive des Managements

Das Projektmanagement kann sich nicht in alle Detailfragen vertiefen. Das ist nicht seine Aufgabe und zeitlich auch gar nicht möglich. Selbst der IT-Projektleiter, der früher selbst Software entwickelt hat, sollte sich nicht mit den Details verschiedener Funktionen beschäftigen. Er verlöre den Überblick. Er würde während er sich mit dem Detail A beschäftigt nicht merken, dass es im Rest des Alphabets brennt. Der Manager muss die Vogelperspektive einnehmen, um das Projekt durch den Sturm zu manövrieren.

Mein Eindruck ist: Aus der Management-Perspektive geht es mehr um das Vorhandensein von Ergebnistypen als um deren Inhalt. Und wenn die halbwegs plausibel sind, ist alles gut. Und da man als informierter Projektmanager regelmäßig das Managermagazin und Computer-Woche liest, setzt man die Werkzeuge ein, die da beschrieben werden. Dazu gehört ganz bestimmt auch UML, der meines Erachtens nach beizeiten eine zu große Management Attention zuteil wird. Wenn man das macht, macht man also vermutlich nicht allzu viel falsch. Doch wie gut sind die Inhalte der Ergebnistypen? Das sehen Manager häufig nicht.

Definition verbindlicher Ergebnistypen

Wenn man sich auf das bloße Vorhandensein von Ergebnistypen verlässt, ist man verlassen. Welche Chance hat das Management der hier beschriebenen und provokant benannten UML-Falle zu entgehen? Es muss dafür sorgen, dass neben den verschiedenen UML-Ergebnistypen (sie erfahren schon hinreichende Management Attention) auch solche erstellt werden, die die Diagramme erforderlichenfalls detaillierter beschreiben und mit allgemein verständlichen Inhalten untermauern. Und dazu gehören m.E. textliche Use Cases, Kernkonzepte und auch Storyboards (siehe hierzu auch Storyboards: Eine Erfolgsgeschichte). Für alle Ergebnistypen sollten Beispiele erstellt und mit den Betroffenen abgestimmt werden. Diese Ergebnistypen müssen vom Projektmanagement abgesegnet werden. Und wenn das noch nicht möglich ist, müssen die Ergebnistypen in einer weiteren Schleife dahin gebracht werden, dass sie den Projektanforderungen entsprechen. Diese Beispielergebnistypen sind dann die Grundlage für die projektbegleitende Qualitätssicherung. Anmerkung: In einem großen Projekt darf nicht nur der Quellcode getestet werden. Es müssen alle Ergebnisse -auch die aus frühen Projektphasen- geprüft werden. Erst dann kann das Management ruhigen Gewissens die ihm zugedachte Vogelperspektive einnehmen. Wenn ihm dann gemeldet wird, dass die vorgesehenen Ergebnistypen vorliegen, kann es davon ausgehen, das auch die notwendigen Inhalte bereitstehen. Nur so lässt sich die UML-Falle vermeiden.

Fazit

In vielen Projekten beschränkt sich die Spezifikation auf die Erstellung von UML-Diagrammen. Es ist theoretisch möglich, mit UML-Diagrammen eine vollständige Spezifikation zu erstellen. Zumeist bewegen sich UML-Diagramme aber ausschließlich auf der grafischen Ebene ohne mit textlichen Beschreibungen hinreichend unterfüttert zu sein. Die textlichen Beschreibungen sind aber zwingend erforderlich, um allzu großen Interpretationsspielraum zu vermeiden. Hierfür bieten sich textliche Use Cases, Kernkonzepte und Storyboards an. Erst wenn das Portfolio der Projektergebnistypen wie hier beschrieben syntaktisch und inhaltlich definiert ist, kann sich der Projektmanager seiner Aufgabe, dem Management, widmen. Ansonsten droht die UML-Falle!

#ManagementAttention #Fachspezifikation #Storyboard #UMLDiagramm #UseCase