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 OnlineBanking

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!

4 Kommentare
  1. Anna Brocke says:

    Dass Use Cases ohne textliche Inhalte verwendet werden, wundert mich. Was nützen die dann?? Denen das Schreiben von Use Cases zuviel Aufwand ist, sollte man mal sagen, dass sich Use Cases auch sehr schön als Dokumentation verwenden lassen oder zu Testzwecken. Tester müssen schließlich wissen, wie ein Ablauf (= Use Case) sein soll. Oder was bei Fehlern passiert (alternativer Flow im Use Case). Ohne Use Cases wäre ich mehr als einmal aufgeschmissen gewesen! Beste Grüße, Anna (die sich wundert, dass es bei Steria Mummert auch Interfaceentwicklung gibt)

  2. Bernd Lohmeyer says:

    Hi Anna,
    Du hast vollkommen Recht. Use Cases ohne detaillierten Hauptablauf, mögliche Alternativen und Ausnahmen sind wenig hilfreich. Doch habe ich viele UML-Modelle gesehen, in denen sich der textliche Inhalt der UC-Bubble wirklich auf eine dreizeilige Kontextbeschreibung beschränkte. Damit kann man dann wirklich nicht allzu viel anfangen. Und wie Du ganz richtig bemerkst, sind gute Use Cases eine hervorragende Basis für die Test Cases. Viel wichtiger finde ich aber noch den Aspekt, dass Use Cases die Fachlichkeit beschreiben, die von dem zu entwickelnden System abgedeckt werden muss. Sie sind der Punkt, auf den sich Fachabteilung (Auftraggeber) und Entwicklung (Auftragnehmer) einigen. Verzichtet man auf Use Cases als gemeinsame Verständnisbasis, kann es später zu bösen Überraschungen kommen.

    Bei Steria Mummeret Consulting machen wir nicht nur Organisations- und Prozessberatung. Es geht auch häufig um die Entwicklung konkreter Software-Systeme. Und da geht’s dann eben auch um User Interfaces, die dann teilweise von uns aber auch von anderen Unternehmen umgesetzt werden. Naja, und ich bin dann eben in der Geschäftsprozessmodellierung oder auch als Designer eingebunden.

    Beste Grüße,

    Bernd

  3. Jes Paulsen says:

    Hallo Herr Lohmeyer,

    … da kann ich Ihnen nur beipflichten: eine mit passenden Werkzeugen üppig ausgestattete Werkstatt kann den Erstellungsprozess eines Produktes zwar vereinfachen und beschleunigen, – dass das fertige Produkt damit aber auch zwangsweise die Erwartungen des Nutzers erfüllt, gehört sicher ins Reich der Fabel. (Denn einerseits kann man sich auch mit einem „Spitzen“hammer permanent auf die Finger klopfen, und andererseits dürfte der Einsatz eines Hammers – und Nagels – zur Befestigung eines gewichtigen Hängeschrankes weder auf einer Beton- noch auf einer Gipskartonwand ein brauchbares Ergebnis liefern, was man allerdings ggf. prima „verschleiern“ kann, wenn man den verbundenen Daumen versteckt und einen Belastungstest mit dem leeren Schrank zuvor erfolgreich durchführen konnte.)

    Was mir als Qualitäts- und Testmanager auch immer auffällt: Letztlich zählt die inhaltliche Qualität des Ergebnisses; egal ob es sich ein Vertragswerk, ein Plandokument, ein Use-Case-Diagramm oder ein Testergebnis handelt. Die Erfüllung formaler Qualitätskriterien hat in vielerlei Hinsicht natürlich ihre Berechtigung – sie trägt aber nur dann zur richtigen Einschätzung des Ergebnisses bei, wenn man inhaltliche Qualität als gegeben voraussetzen darf.

    Auf grafischen Darstellungen basierende Modellierungswerkzeuge haben den Charme, durch Visualisierung ein schnelleres Verständnis bestimmter Sachverhalte erreichen zu können, als dies mit textuellen Beschreibungen möglich ist. Im Regelfall ermöglichen solche Werkzeuge auch eine „sollbruchstellenfreie“ Navigation durch die Funktions- und Datenwelt komplexer Systeme, was das Zusammenwirken der Systemkomponenten grundsätzlich verdeutlichen kann. Funktioniert aber natürlich nur, wenn das Modell konform zum zu betrachtenden Kontext (Batch, Oberfläche, Datenbank, Web, etc.) aufgebaut wird und der Betrachter das Machwerk nicht nur als „abstrakte Kunst“ empfindet.
    Ich persönlich erachte (meist sträflich vernachlässigte oder „aufgeblasene“) Kontextdiagramme zur Abgrenzung des Entwicklungsgegenstandes von seiner Umwelt (Schnittstellen!) als besonders hilfreich, wohingegen ich einer grafischen Darstellung bestimmter Algorithmen im Vergleich zu einer sauber strukturierten und ausformulierten verbalen Beschreibung kaum Mehrwert beimesse.

    Es wird also wohl eine Kunst bleiben, nur die dafür geeigneten Sachverhalte grafisch zu beschreiben und dies dann noch so zu tun, dass sich der Interpretationsfreiraum bei allen am Entwicklungsprozess Beteiligten in vertretbaren Grenzen hält.

    Daher kann auf eine gewissenhaft durchgeführte inhaltliche QS auch bei Anwendung modellbasierter Entwicklungsumgebungen eigentlich kaum verzichtet werden.

    Viele Grüße
    Jes Paulsen

  4. Bernd Lohmeyer says:

    Herzlichen Dank, Herr Paulsen. Sie beleuchten das Gegenteil der UML-Falle. Nennen wir sie mal die „Word-Falle“. Und Sie haben Recht. Es ist ebenso ein Fehler, alle Informationen zu einem Projekt in Word oder Excel zu vergraben. Da findet man nichts mehr wieder. Und ein Domain Class Model in Textform ist unverständlich. Ich neige auch dazu, mir fachliche Zusammenhänge bildlich vorzustellen. Es bedarf eines riesigen Aufwands, diese Zusammenhänge aus einem Text zu extrahieren. Selbst eine Gliederung des Textes in Kapitel und Unterkapitel, hilft da nicht sonderlich.

    Es kommt also nachwievor darauf an, die richtigen Werkzeuge richtig einzusetzen. Jedes Werkzeug muss im Sinne seines Zwecks verwendet werden. Diagramme zur Darstellung komplexer Zusammenhänge, Texte zur Vorkonzeption und später zur detaillierten Beschreibung. Man muss beides nutzen. Wenn man nur ein Werkzeug kennt bzw. einsetzt, führt diese Werkzeug-Monokultur dazu, dass die Spezifikation entweder lückenhaft und/oder unverständlich ist. Beides bedeutet, dass wichtige Informationen nicht verfügbar sind.

    Über die Word-Falle muss ich mir noch mal ein paar Gedanken machen. Ich erlebe sie aktuell in einem Projekt ;-(

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.