Die ideale Anzahl von Diagrammen und Diagrammelementen
„Wie viele Diagramme benötige ich zur Beschreibung eines Systems? Und wie viele Elemente sollte ich pro Diagramm verwenden, um noch einen guten Überblick zu behalten?“ Wer Systeme entwickelt, stellt sich häufig solche Fragen. Es gilt, möglichst vollständige und widerspruchsfreie Anforderungen zu ermitteln und Zusammenhänge zu verstehen. Zur Visualisierung dieser Zusammenhänge bieten sich bekanntermaßen Diagramme aus SysML und UML an. Die UML definiert 13 Diagrammarten, die SysML „lediglich“ 9.
Einige dieser Diagramme wurden unverändert aus der UML übernommen, wie zum Beispiel die Anwendungsfalldiagramme. Andere wurden erweitert (z.B. Aktivitätsdiagramme), umbenannt (Blockdefinitionsdiagramme als Variante des UML-Klassendiagramms) und neue Diagrammarten wie das Anforderungsdiagramm kamen hinzu.¹ Durch die verschiedenen Blickwinkel der einzelnen Diagramme entsteht ein Gesamtbild des gewünschten Systems. Dadurch steigen das gemeinsame Verständnis und somit auch die Chancen für eine erfolgreiche Systementwicklung. Aber welches ist die ideale Anzahl von Diagrammen und Diagrammelementen?
Die fehlende Formel zur Bestimmung der Diagrammanzahl
Es gibt keine Formel zu Bestimmung der sinnvollen oder gar idealen Anzahl von Diagrammen zur Beschreibung und Visualisierung von Zusammenhängen in der Systementwicklung. Somit können wir beispielsweise bei 1.000 Anforderungen nicht automatisch ableiten, dass wir (beispielsweise) 25 Anforderungsdiagramme benötigen oder bei 20 Stakeholdern 7 Zieldiagramme. Gibt es dennoch eine Möglichkeit, sich der geeigneten Menge an Diagrammen zu nähern?
Lassen Sie uns die ursprüngliche Frage einmal umdrehen und fragen, warum die Menge der Diagramme überhaupt wichtig ist. Mit der steigenden Menge der Diagramme geht nämlich häufig auch die Sorge einher, den Überblick über das System zu verlieren. Zu viele Diagramme sorgen in vielen Fällen nicht wie gewünscht für ein besseres Verständnis, sondern verwirren eher. Diese Sorge ist verständlich. Und wenn wir den Blick auf einzelne Diagramme richten, dann können wir uns fragen, welche Informationen in welchen Diagrammen stecken, welche Beziehungen es zwischen den Diagrammen gibt und welche zwischen einzelnen Diagrammelementen. Hier schwingt die Sorge mit, mit der Informationsflut nicht umgehen zu können. Gut, dass es für die Erhebung von Anforderungen und zur Erstellung von Diagrammen Tools gibt. Spezialisierte Tools, keine reinen Werkzeuge zum Zeichnen der Diagramme, sondern Datenbank-gestützte Lösungen.
Wie viele Diagramme sind ideal?
Informationen in einer Datenbank und in Diagrammen
Mit Requirements Engineering Tools legen Sie leicht tausende von Anforderungen, Testfällen, Zielen, Stakeholdern, Change Requests, etc. an. Genauer gesagt speichern Sie Informationen zu verschiedenen Objekten mit Ihren Eigenschaften und Beziehungen zu anderen Objekten in einer Datenbank. Und diese Objekte bzw. Elemente visualisieren Sie einfach bei Bedarf. So könnten Sie beispielsweise die Anforderung X aus der Liste der angelegten Anforderungen auswählen und per Drag & Drop in einem Anforderungsdiagramm A1 darstellen. Anschließend legen Sie in demselben Diagramm eine Anforderung Y an, die damit auch in der Datenbank abgespeichert wird.
Hätten die Anforderungen X und Y eine Beziehung zueinander, würden Sie diese Beziehung im Diagramm modellieren. Entsprechend würde auch diese Beziehung in der Datenbank gespeichert. Ob Sie nun die Anforderung Y mit einer Beziehung in einem Zieldiagramm Z1 anzeigen oder nicht, entscheiden Sie. Hilft es Ihrem Verständnis, dann tun Sie dies. Ihre Entscheidung beeinflusst aber nicht die grundsätzliche Existenz von Y in der Datenbank.
Die Dokumentation von Informationen
Die Frage nach der idealen Anzahl von Diagrammen in der Systementwicklung stellt sich häufig auch, weil Dokumente erzeugt werden müssen. Arbeiten Sie in einer integrierten Lösung und können somit leicht entscheiden, welche Inhalte in welche Dokumente generiert werden, dann ist die Sorge vor zu vielen Diagrammen unbegründet. Sie wäre genauso unbegründet wie die Sorge über zu viele Anforderungen. Sie würden ja auch nicht sagen, dass Sie Ihre Anforderungserhebung nach 100 Anforderungen beenden, oder? Mengenprobleme entstehen häufiger bei der Realisierung von Anforderungen, weil Aufwände nur schwer eingeschätzt werden können und am Ende der Iteration die Zeit ausgeht. Die Anforderungen an sich lassen sich aber wie die Diagramme unabhängig von der Menge einfach per Knopfdruck generieren.
Das richtige Maß für Diagrammelemente
Es gibt Faustregeln für gut lesbare Texte, denn Tests haben ergeben, dass 9 Wörter pro Satz das Textverständnis der Probanden deutlich erhöhen.² Dennoch machen nur kurze Sätze mit 9 Wörtern allein keinen guten Text, so dass eher ein Wechsel von kurzen und längeren Sätzen zu empfehlen ist. Der vorangegangene Satz hat 25 Wörter und liegt somit zwischen der Grenze der erwünschten (20 Wörter pro Satz) und der maximal erlaubten Grenze (30 Wörter pro Satz). Und was bedeutet das für die Anzahl der Elemente in einem Diagramm? Sollten Diagramme also auch ungefähr 9 Elemente beinhalten?
Sind das schon zu viele Elemente?
Erinnern Sie sich noch an Ihre Zeit in der Schule oder später während des Studiums? Häufig hatten Lehrer vor Beginn der Schulstunde die Innenseiten der aufklappbaren Tafel mit Informationen vollgeschrieben. Vermutlich wollten die Lehrer damit Zeit sparen und zusätzlich sicher gehen, dass auch alle wichtigen Informationen aufgeschrieben wurden. Und wie war die Reaktion der Schüler? „Puh!“ Sie fühlten sich erschlagen. Zu viele Informationen auf einen Schlag. Im Studium wurde es dann nur etwas besser, weil die Overhead-Projektoren lediglich vorgeschriebene DIN A4 Folien anzeigen konnten (natürlich gab es auch Folienrollen, die waren aber zum Glück selten vorgeschrieben) und so wurde immerhin die Menge der schlagartigen Informationen und der „Puhs“ ein wenig reduziert.
Wenn wir also unsere eigene Erfahrung nutzen, dann wäre es vermutlich sinnvoll, nicht mehr als ungefähr 9 Elemente pro Diagramm zu verwenden, oder? Halt. Wie war es eigentlich bei den guten Lehrern? Haben diese Lehrer die Inhalte in der Schulstunde nicht einfach nach und nach entwickelt und parallel dazu an die Tafel geschrieben? Zum Ende des Unterrichts war die Tafel ebenfalls vollgeschrieben, aber es gab weniger stöhnende Schüler. Der Inhalt wurde lediglich anders dargeboten, die Menge war nicht entscheidend. Für die Anzahl der Elemente in einem Diagramm bedeutet dies folgendes:
- Erstellen Sie ein Diagramm, fällt es Ihnen leicht, Zusammenhänge nachzuvollziehen und Sie werden auch von einer größeren Anzahl von Elementen nicht überfordert.
- Lesen Sie ein „fremdes“ Diagramm in vollem Umfang, dann werden Sie vermutlich zuerst wieder Schwierigkeiten haben, alle Informationen zu erfassen.
- Besteht für Sie als Diagrammleser die Möglichkeit, Inhalte nach und nach zu verstehen, dann wird es Ihnen leichter fallen, Zusammenhänge zu erkennen. Die Navigation im Diagramm selbst wird durch die Beziehungen zwischen den Elementen erleichtert, denn so gelangen Sie von einer Information zur nächsten. Darüber hinaus können Sie mit entsprechenden Funktionen auch in Diagramme zoomen, so dass Sie von einem Element ausgehend, das Element selbst und die Umgebung des Elements im Detail anschauen können. So gelingt es schnell, auch in großen Diagrammen Zusammenhänge sowohl im Detail als auch im großen Ganzen zu verstehen.
Fazit
Machen Sie sich keine Sorgen über die richtige Anzahl von Diagrammen. Es gibt keine allgemein gültige Formel zur Bestimmung der idealen Anzahl von Diagrammen für Ihre Systementwicklung. Auch die Anzahl der Elemente ist nicht entscheidend. Nutzen Sie einfach spezialisierte Tools, mit denen Sie die für Ihre Entwicklung relevanten Aspekte grafisch darstellen. Diese Tools unterstützen Sie mit sinnvollen Diagrammarten, die sie immer dann nutzen, wenn Sie Vorteile für Sie bieten. Und drücken Sie anschließend einfach auf einen Knopf und dokumentieren Sie Ihre 10.418 Anforderungen und Ihre 123 Diagramme mit einem Schwung.
Quellen:
[1] Tim Weilkiens, Vortrag Systems Modeling Language (SysML), http://www.sigs-datacom.de/
[2] Dr. Katrin Prüfig, Kurze Sätze, große Wirkung, http://www.bmtd.de/kurze-saetze-grosse-wirkung
Sie weisen richtig darauf hin, nur die relevanten Aspekte darzustellen Es ist wirklich nicht zwingend notwendig jedes Detail in Diagrammen festzuhalten.
Ich persönlich finde es in meiner täglichen Arbeit sehr praktisch mir bei Bedarf zu Analyse- oder kurzfristigen Präsentationszwecken ggf. Elemente in ein leeres temporäres Diagramm zu ziehen und mir mit Hilfe entsprechender Funktionen die im Modell assoziierten Elemente automatisch reinzuladen. Das Diagramm lösche ich in der Regel wieder, wenn ich die benötigten Informationen habe.
Auch bin ich ein großer Fan von Suchfunktionen, die mir helfen benötigte Informationen im Modell zu finden. Hier liegt für mich der eigentliche Wert eines modellbasierten Vorgehen.
Hallo Herr Dankers,
danke für Ihre nette Beschreibung. Wenn Sie die Diagramme nicht dokumentieren wollen/müssen, sie also nicht in Dokumente generieren, spricht nichts dagegen sie wieder zu löschen. Und da es sich ja um Datenbanksysteme handelt, ist das Objekt damit ja nicht weg, sondern lediglich die grafische Repräsentanz in dem speziellen Diagramm. Aber auch wenn Diagramme relativ schnell erzeugt werden können, warum heben Sie sie nicht dennoch auf? Gibt es kein Szenario bei Ihnen, bei dem Sie das Diagramm nochmals gebrauchen könnten?
Sonnige Grüße
Michael Schenkel