Landkarten als Analysewerkzeug

Achtung, jetzt kommt wieder einmal ein Beitrag, der auf den ersten Blick ziemlich schräg daherkommt, aber lassen Sie ihn auf sich wirken. Ich denke, dass Folgendes beim Entwurf und bei der Strukturierung komplexer (Software-) Systeme sehr wertvoll ist.

Ich habe in einem älteren Beitrag schon einmal beschrieben, wie die Form Einfluss auf den Inhalt hat – in der Kunst, wo Einheit von Form und Inhalt als Grundprinzip gilt, würde man darüber lachen. Aber es ist nun mal so: Excel-Listen nimmt man anders war als Diagramme und seitenlange Prosa anders als formale Spezifikationen. Wer die Software für eine Einparkhilfe entwickelt, benutzt hoffentlich andere konzeptionelle Techniken als die Entwickler eines Reiseportals.

Weiterhin suche ich immer nach Methoden, die unser Gehirn nativ unterstützt. Unser Gehirn besitzt einen relativ langsamen sequentiellen Prozessor, der z.B. mathematische Gleichungen lösen, aber auch lange Listen durchlesen kann. Dagegen unterstützt unser Hirn eine enorme Parallelverarbeitung von Farben, Formen oder Größen. (Randnotiz: das Buch “Introduction to Information Visualization” von Riccardo Mazza ist sehr empfehlenswert). Oft nutzen unsere Techniken in der Softwareentwicklung diese Parallelverarbeitung im Hirn aber nicht aus.

Zuletzt ging mir immer wieder die Verwendung von Metaphern zur Systemanalyse durch den Kopf. Als Metapher verstehe ich hier eine Technik, die jedem normalen Bürger bekannt ist, die jedoch auf einen anderen Kontext umgedeutet wird.

Landkarten sollten jedermann bekannt sein, der eine deutsche Schule mit Geografieunterricht besucht hat. Landkarten sind eine wundervolle Technik, die exzellent die massiv parallele Verarbeitung von Informationen unterstützt. Es gibt politische Landkarten, Landkarten mit Visualisierung der Industrien, der Einwohnerzahlen oder der Kriminalitätsrate.

Ländergrenzen, Stadtanordnungen, Regionen wie Sumpfgebiete oder militärische Sperrgebiete werden durch Merkmale wie Form, Größe, Farbe und Füllform (z.B. Schraffur) leicht wahrnehmbar.

Verallgemeinert kann man sagen, dass auf eine Formfläche immer wieder andere Visualisierungen aufgetragen werden können.

Wie kann man dies als Metapher nun in der Systemanalyse adaptieren? Hier haben wir das Problem, dass eine solche natürliche Form eben erst einmal nicht gegeben ist. Auch haben wir noch keine Notation.

Am Beispiel von Quality Spy habe ich eine vollständige Karte nachgebildet. Los geht’s.

Formbildung

Software ist meist mehrdimensional und komplex. Wie man sie (als Entwickler) wahrnimmt, wird durch die interne Informationsarchitektur bestimmt. Man könnte es auch einfach als hierarchische Gliederung bezeichnen.

Wenn man diese hierarchische Gliederung nun als Formen einer Landkartenmetapher auswalzt, kam bei Quality Spy nach einigem Probieren eine Form einer kleinen Inselgruppe heraus: (anklicken zum Vergrößern)

Ländergrenzen

Um das zu verstehen, muss man sich natürlich schon sehr intensiv mit dem Programmaufbau und den Features von Quality Spy beschäftigen.

Glücklicherweise stimmt die interne Informationsarchitektur in hohem Maße mit der externen überein. Auf der “Hauptinsel” befinden sich die vier Hauptfunktionen Test Strategy, Test Plan, Test Runs und Summaries. Die “Länder”, hier als Metapher für Hauptfunktionsbereich benutzt, sind nebeneinander angeordnet und ein Land hat jeweils nur einen Nachbar. Das mag banal oder willkürlich erscheinen, drückt aber für diese Anwendung sehr gut die realen Beziehungen ab.

Die Insel “Shell” wirkt wie eine Sandbank, die der Hauptinsel vorgelagert ist. Shell hat kein Pendant in der externen Informationsarchitektur. Es ist eine Art Fundament, aber auch der Kleber, der alle Teile zusammenhält.

Der STE-Modus ist als eine Art abtrünniger Bruder von “Test Runs” auf einer separaten Insel dargestellt.

Zum Schluss sind die Plugins als kleines Archipel ausgedrückt, denn die einzelnen Plugins sind wirklich sehr klein und gehören zudem nicht zum Hauptprogramm.

Nochmal: die Formbildung drückt die interne Informationsarchitektur aus und ist für Außenstehende nicht gedacht, daher grübeln Sie nicht was “Shell” oder “STE” hier jetzt genau zu bedeuten hat.

Welche Form hat die Software, an der Sie gerade arbeiten? Ist es eine große Landmasse? Gibt es viele kleine Länder, oder einzelne sehr große? Gibt es vielleicht eher große gerade Grenzen wie in Afrika oder zerklüftete wie in Europa?

Städte

Als nächstes möchte ich einzelne Funktionen in die Karte eintragen. Hierfür benutze ich die Stadt als Metapher. Zumindest im großen Diercke Atlas waren Städte immer als rote Punkte bzw. rote Rechtecke dargestellt, daher benutze ich dies auch als Notation:

Map_mit_Städten

Hier sieht man sehr schön, dass einige “Länder” dicht und andere eher dünn besiedelt sind. Das ist für mich wiederum eine hervorragende Metapher, um die “Breite” bzw. “Tiefe” einer Software auszudrücken. Es gibt z.B. Software, die deckt ein breites Funktionsspektrum ab, bietet dafür aber in den einzelnen Funktionen weniger. Andere Software ist vielleicht in der Breite reduziert, bietet dafür aber in der Tiefe ein unheimliches Funktionsfüllhorn.

Bei Quality Spy sieht man sehr schön, dass die Hauptzahl der internen Funktionen in “Test Plan” und “Test Runs” liegt und dass es sich bei “Protocol” wohl um eine enorme Megacity handelt.

Auch sehr interessant sind die bläulichen Punkte, die als “Wurmlöcher” das Einschleusen von Funktionen via Plugins ermöglichen!

Geplante Erweiterungen

Als dritten Schritt stelle ich nun noch geplante Erweiterungen in der Karte dar:

Map_with_planned

Dies kennzeichne ich durch eine entsprechende Schraffur. Einiges sind Erweiterungen auf “neuen Inseln”, andere erweitern vorhandene Länder bzw. erfordern die Neuordnung der Ländergrenzen.

Möglichkeiten ohne Ende

Wenn einmal die Grundform der Ländergrenzen festgelegt ist, kann man die Flächen mit diversen Statistiken füllen. Wie wäre es mit der Fehlerrate, der internen Qualität, z.B. ermittelt durch automatisierte statische Codeanalyse, oder der Nutzungsintensität, z.B. ermittelt durch Tools wie KnowMyUsers, als Heatmap visualisiert?

Oder man könnte Abhängigkeiten als Straßenmetapher ausdrücken. Die Abhängigkeitsintensität könnte man z.B. durch die Form der Straße (Autobahn, Landstraße) ausdrücken.

Manche Funktionen sind so komplex, dass sie evtl. Unterkarten – also quasi Stadtkarten – benötigen. Je mehr ich drüber nachdenke, desto mehr Ideen fallen mir ein.

Techniken

Falls ich jetzt bei Ihnen den Wunsch geweckt habe, dies auch einmal auszuprobieren, würde ich sehr empfehlen dies zunächst mit Stift und Papier zu tun. Die hier gezeigten Grafiken habe ich mit Inkscape als Vektorgrafik (SVG) gezeichnet, was aber schon recht aufwendig war.

Ich würde mir natürlich einen noch komfortableren Editor wünschen, aber außer Landmassegeneratoren für Phantasiewelten habe ich noch nicht das Richtige gefunden. Hat nicht mal ein Diktator oder Feldmarshall ein gescheites Programm entwickeln lassen, wo man die politischen Ländergrenzen leicht verschieben kann?

Fazit

Eingangs habe ich Inhalt und Form erwähnt. Diese etwas schräge Kartenform ist wohl eher für bestehende und nicht für neu zu entwickelnde Systeme als Inhalt geeignet. Weiterhin sollte das System über eine unklare oder überkomplexe Informationsarchitektur verfügen, damit die Kartenmetapher hier eine Ordnung schafft.