Informationsmodellierung (eBook)

Durch Verstehen zur besseren Software

Stefan Berner (Autor)

eBook Download: PDF | EPUB

2016 | 1. Auflage
103 Seiten
vdf Hochschulverlag AG
978-3-7281-3769-2 (ISBN)

Infos

Verstehen ist der Schlüssel zu guter Software. Die Modellierung von Geschäftsprozessen und der dabei manipulierten Daten kann jedoch nur maximal so gut sein wie das zugrunde liegende Verständnis der Sache an sich. Erfahrungsgemäss liegt die Hauptursache für schlechte Software und gescheiterte IT-Projekte im mangelnden Verständnis der Fachwelt. Informatiker müssen verstehen, was die Anwender brauchen (und nicht nur, was sie wollen!). Anwender und Manager müssen verstehen, wie sie Informationen nutzen und was sie von der IT verlangen sollen. In diesem Buch wird das Vorgehen erläutert, mit dem das gegenseitige Verständnis verbessert werden kann. Es wird von Erfahrungen berichtet und auf Chancen und Schwierigkeiten bei der Umsetzung eingegangen.

Inhalt

Informationsmodellierung 1
Impressum 2
Inhaltsverzeichnis 3
Vorwort 5
Einleitung 7
Gute Software 7
Verstehen 9
Das Informationsmodell 15
Was ist ein Informationsmodell? 15
Elemente des Informationsmodells 24
Qualität des Informationsmodells 35
Review des Informationsmodells 47
Einsatz des Informationsmodells 53
Arbeiten mit dem Modell 53
Informations- und Prozessmodell 63
Einsatz in verschiedenen Szenarien 68
Erfahrungen mit dem Informationsmodell 75
Widerstände 77
Gewinn 82
Schlusswort 86
Anhang 89
Informationsmodell des Informationsmodells 89
Erweiterungen des Informationsmodells 90
Transformation Informationsmodell – Datenmodell 94
Beispiel eines umgesetzten Informationsmodells 98
Literaturverzeichnis 100
Index 101

Textauszug

Das Informationsmodell

Was ist ein Informationsmodell?

Wie lässt sich dieses, für das Verständnis unabdingbare Kontextwissen erarbeiten, wie dokumentieren? Welche Dokumente und Methoden bieten sich an?

Für die Dokumentation greifen wir auf Bewährtes zurück. Viele kennen es unter dem Begriff konzeptionelles Datenmodell oder auch als Geschäftsobjektmodell. Meine Bezeichnung dafür lautet Informationsmodell.3 Ein (unvollständiges) Beispiel sahen Sie bereits in Abbildung 2.

Typischerweise sehen durch IT-Fachleute erstellte Datenmodelle aus, wie in Abbildung 4. Selbst wenn diese Modelle richtig und vollständig sind, sie sind absolut ungeeignet als Kommunikationsmittel zwischen Fachabteilung und Informatik. Die Kritikpunkte sind

• Zu technische Darstellung, zu viele Symboltypen.

• Zu unexakte Begriffe.

• Zu viele fehlende Angaben und damit zu viel Interpretationsspielraum.

Es ist wenig erstaunlich, dass sich Fachabteilungen ausserstandesehen oder sich weigern, diese Dokumente zu lesen, zu prüfen, zu beurteilen oder zu akzeptieren. Letzteres müssen sie häufig unter Zeitdruck tun. Sie tun dies in der Hoffnung, dass alles in Ordnung sei, und weil sie sonst keine Software erhalten. Bei der Präsentation solcher Modelle kommt es häufig zum Des-Kaisers-neue-Kleider-Effekt. Niemand will der Erste sein, der zugibt, dass er das Modell nicht verstanden hat. Niemand will durch Kritik oder Bestätigungsfragen der Auslöser sein für eine erneute Überarbeitung des Modells. Dies könnte ja die jetzt schon engen Terminvorgaben gefährden. Damit sind wir bei der eingangs erwähnten These, dass Missverständnisse zu schlechter Software führen (siehe hier). Unverstandene Modelle werden umgesetzt und führen zu Software, die dem entspricht, was die IT-Fachleute verstanden haben. Die Qualität der Kommunikation zwischen IT-Fachleuten und Kunde bestimmt, wie weit dieses IT-Verständnis vom Verständnis des Kunden entfernt ist und als wie gut der Kunde die Software bewertet.

Abbildung 4: Beispiele für Datenmodelle.

Das in der Datenbankentwicklung bestens bekannte und etablierte relationale Modell kann für die Dokumentation des Wissens (des Kontextes) einer Umgebung verwendet werden. Es wird – um unten stehende Bedingungen ergänzt – zum Informationsmodell und ist das beste mir bekannte Mittel für die Dokumentation und Kommunikation von Informationsaspekten. Ein Informationsmodell ist ein relationales Datenmodell ergänzt um folgende Bedingungen:

• Sämtliche Entitäts- und Attributnamen drücken exakt aus, was gemeint ist. Sie dürfen und müssen immer wörtlich genommen werden.

• Es gibt für jeden Begriff genau eine, möglichst einschränkende Definition (vorzugsweise gemäss Wörterbuch) oder Festlegung im aktuellen Bereich oder Projekt.

• Alle Beziehungen zwischen Entitäten sind in beiden Richtungen mit einer Assoziation (= einem Verb mit ggf. Präposition) beschrieben.

• Sämtliche verwendeten Begriffe werden von allen Beteiligten vorbehaltlos verstanden und akzeptiert. Sie sind in einer (natürlichen) Sprache formuliert, die von allen Beteiligten sehr gut beherrscht wird.

• Es kommen keine informatiktechnischen Begriffe wie index, key, mutation_user, field, view, int, column, 1:m, table, varchar etc. vor.

Diese Regeln sehen auf den ersten Blick offensichtlich und nicht besonders einschränkend aus. Wenn Sie die hervorgehobenen Wörter sich anschauen und versuchen diese Einschränkungen strikte umzusetzen, werden Sie feststellen, dass dies nicht einfach ist. Sie werden feststellen, dass dies sogar sehr schwierig ist.

Meiner Erfahrung nach sind es ebendiese Ergänzungen, die massgeblich zum Verständnis und damit zu besserer Software beitragen.

Es sind diese Einschränkungen, die das Datenmodell zum Informationsmodell machen.

Diese Erkenntnis liefert den Grund für die weiter oben gemachte Bemerkung, dass trotz korrekter Anwendung bekannter Methoden inakzeptable Ergebnisse geliefert werden. Die bekannten Methoden werden formal richtig angewendet. Was fehlt, ist der semantische Bezug zur realen Welt. Es werden (technische) Datenmodelle erstellt anstatt (semantische) Informationsmodelle.

Einige Bedingungen wie «sämtliche», «alle», «keine», «jeden» sind einfach zu überprüfen. Schwieriger wird es bei «exakt», «vorbehaltlos», «wörtlich nehmen», «sehr gut». Hier geht es um Interpretation, um Bedeutung. Bedeutung kann nicht vollständig formalisiert werden. Sie hängt immer von der Betrachtungsweise die Empfangenden der Nachricht ab. Es gibt weder exakte Formeln noch überprüfbare Regeln, die garantieren können, dass alle alles richtig oder gleich verstanden haben, geschweige denn, dass die gemachten Aussagen das ursprüngliche Problem richtig und vollständig beschreiben. Hier ist das Gespräch, die Diskussion notwendig, eine Diskussion in der die Standpunkte und Betrachtungsweisen abgeglichen werden, eine Diskussion in der der gemeinsame Kontext konkretisiert und festgelegt wird. Diese Diskussion dient hauptsächlich dazu sicherzustellen, dass alle Beteiligten sich einig sind, sprich dass sie die Aussagen gleich verstehen.

Erst wenn es keine Missverständnisse mehr gibt, kann mit einiger Wahrscheinlichkeit angenommen werden, dass das Modell von guter Qualität ist. Dieser Konsens unter den Beteiligten muss erreicht und verifiziert werden. Dieser Prozess ist der schwierigste Teil der Modellierungsarbeit. Es ist harte Arbeit. Unterschiedliche Ansichten müssen harmonisiert werden, und dies nicht mittels Dekret, sondern durch Überzeugung. Es wird um einzelne Wörter und ihre Bedeutung gerungen. Eigene Interpretationen müssen hinterfragt und revidiert werden. Alle Beteiligten sind persönlich betroffen. Sie müssen ihre eigenen Vorstellungen und Interpretationen möglicherweise anpassen. Diese Betroffenheit und die weitverbreitete Abneigung gegen Streit führen allzu häufig dazu, dass man sich in Plattitüden flüchtet. Aussagen wie «Wir wissen ja, was gemeint ist.», «Das wird schon stimmen.», «Das muss ich nicht verstehen.», «Namen sind nicht so wichtig.» sind der hilflose Versuch, der entscheidenden Arbeit im Modellierungsprozess auszuweichen. Für solche Aussagen bleibt nur die Bemerkung: Wer nicht sagt, was er will, bekommt, was er verdient.

Es braucht Regeln im Modellierungsprozess, mit denen dieses Ausweichen verhindert werden kann. Es muss allen Beteiligten auf allen Stufen klar sein, dass ihre überzeugte Zustimmung zu den Angaben im Informationsmodell ein entscheidender Beitrag für die Qualität des künftigen Softwaresystems ist. Alle Bezeichnungen und Beziehungen werden erst definitiv, wenn sie von allen ohne Wenn und Aber als richtig befunden und akzeptiert wurden. Dies schliesst mit ein, dass alles verstanden wurde.

Anhand eines Beispiels soll erläutert werden, was überzeugte Zustimmung bedeutet.

Abbildung 5: Ein einfaches Informationsmodell.

Betrachten Sie das Beispiel in Abbildung 5. Was sagt es aus? Streng genommen nur, dass «Buch» etwas mit «Filiale» und etwas mit «Person» zu tun hat. Ob jemand versteht, Person liest, kauft, leiht aus, stiehlt oder schrieb das Buch, hängt von der ersten Assoziation ab, die die Betrachterin, der Betrachter beim Lesen des Diagramms hat. Diese erste Assoziation wird bestimmt durch den persönlichen Kontext, in dem sich die Person gerade befindet. Mit anderen Worten, es gibt einen fast beliebig grossen Interpretationsspielraum und damit Raum für Missverständnisse, die wahrscheinlich in dieser Phase der Projektentwicklung nicht entdeckt werden. Jede Person ist überzeugt, sie hätte das Modell verstanden. Es kann nur in Gesprächen überprüft werden, ob es alle gleich verstanden haben.

In diesem Modell fehlen die Assoziationen zwischen den Entitäten (siehe Punkt 3 in der Liste der Bedingungen). Eine Assoziation, die eine Entität mit einer anderen verknüpft, ist immer ein Verb mit ggf. einer Präposition. Sie sagt aus, was die eine Entität mit der anderen zu tun hat, in welcher Beziehung die beiden Entitäten zueinander stehen. Dies ist ein entscheidender Beitrag zum einheitlichen Verständnis.

Abbildung 6: Vermeintlich klares Informationsmodell.

Etwas exakter sind die Aussagen in Abbildung 6. Das Diagramm erfüllt bereits viele der Bedingungen, die ein Informationsmodell von einem Datenmodell unterscheiden: keine technischen Begriffe, Begriffe, die alle verstehen können. Es fehlen die Assoziationen in die Gegenrichtung. Mit grosser Wahrscheinlichkeit fehlt auch das vorbehaltlose Akzeptieren der wörtlich genommenen Begriffe und Aussagen. Überlegen Sie bitte einen kurzen Augenblick für sich selbst, wie Sie den Begriff «Buch», der in diesem Diagramm erwähnt wird, verstehen. Möglicherweise können Sie allein nicht erkennen, welche unterschiedlichen Interpretationen sonst noch möglich sind. Sie entscheiden sich beim Lesen des Diagramms unweigerlich für ein Verständnis der Sachlage. Dies ist dann Ihr Verständnis. Erst wenn Sie Ihr Verständnis in einer Diskussion...

Produkt-Details

• Erscheint lt. Verlag: 1.9.2016
• Verlagsort: Zürich
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik
• Schlagworte: Datenorganisation • Datenverwaltung • Dokumentation • Informationsmodell • IT-Kommunikation • IT-Projekt • Prozessmodell • Softwareentwicklung • Softwaresystem
• ISBN-10: 3-7281-3769-3 / 3728137693
• ISBN-13: 978-3-7281-3769-2 / 9783728137692