informationsmodellierung (stefan berner)

STEFAn BErnEr

Informationsmodellierung

Durch Verstehen zu besserer Software

Inhaltsverzeichnis

Vorwort 5

Einleitung 7Gute Software . . . . . . . . . . . . . . . . . . . . . . . . . 7Verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Das Informationsmodell 15Was ist ein Informationsmodell? . . . . . . . . . . . . . . 15Elemente des Informationsmodells . . . . . . . . . . . . . 24Qualität des Informationsmodells . . . . . . . . . . . . . . 35Review des Informationsmodells . . . . . . . . . . . . . . 47

Einsatz des Informationsmodells 53Arbeiten mit dem Modell . . . . . . . . . . . . . . . . . . 53Informations- und Prozessmodell . . . . . . . . . . . . . . 63Einsatz in verschiedenen Szenarien . . . . . . . . . . . . . 68

Erfahrungen mit dem Informationsmodell 75Widerstände . . . . . . . . . . . . . . . . . . . . . . . . . 77Gewinn . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Schlusswort . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Anhang 89Informationsmodell des Informationsmodells . . . . . . . . 89Erweiterungen des Informationsmodells . . . . . . . . . . 90Transformation Informationsmodell – Datenmodell . . . . 94Beispiel eines umgesetzten Informationsmodells . . . . . . 98

Literaturverzeichnis 100

Index 101

3

Vorwort

Nach der Präsentation eines Informationsmodells war die Reakti-on des CEO: «Dafür habt ihr vier Wochen gebraucht. Das ist soklar und offensichtlich, das hätte ich ihnen an einem Nachmittagaufzeichnen können.» Diese Aussage betrachte ich als das grössteLob, das ich je für meine Arbeit als Informationsmodellierer erhal-ten habe. Die Mühe, die wir hatten, die Informationen in Erfahrungzu bringen, den Aufwand, den wir betrieben hatten, treffende Na-men zu (er)finden, die Diskussionen, die wir geführt hatten, um Un-klarheiten und Widersprüchlichkeiten zu beseitigen, all dies war imEndergebnis nicht mehr sichtbar. Wir hatten die Informationsweltdieser Firma – gemäss Aussage des Chefs – klar, treffend und richtigbeschrieben. Der Chef verstand die Aussagen auf dem Diagramm.Darum geht es in diesem Buch. Wie wird gemeinsames Verständ-

nis über alle Ebenen hinweg erreicht? Und wie kann etwas, das ver-standen wurde, dokumentiert werden? Welche Dokumentationsformermöglicht, dass andere möglichst rasch dasselbe Verständnis vonder Sache haben? Es geht in diesem Buch nicht um die technischenBelange von Wissen (Speicherung, Daten, Darstellung). Es geht umInhalte, Essenz und Semantik von Informationen.Dieses Buch richtet sich an alle, die mit der Verwaltung von Da-

ten und Informationen zu tun haben. Seien es nun IT-Fachleute,Business-Analysten, Personen aus der IT-Organisation oder demManagement oder die Nutzenden aus den Fachabteilungen.

IT-Fachleute erfahren, was der Unterschied zwischen Daten-und Informationsmodellierung ist und welchen Nutzen sie damit inder Kommunikation mit den IT-Laien erzielen können.

Personen aus der IT-Organisation erhalten eine Methodeund eine Sprache, mit deren Hilfe sie exakt und verbindlich sowohlmit den IT-Fachleuten als auch mit den künftigen Nutzenden ausihren Fachabteilungen kommunizieren können.

5Leseprobe aus: Stefan Berner, Informationsmodellierung © vdf Hochschulverlag 2016

http://vdf.ch/informationsmodellierung.html

Vorwort

Business-Analysten erhalten eine Methode und eine Sprache,mit der sie die Ergebnisse ihrer Analyse- und Modellierungsarbeitsehr einfach und für alle Beteiligten verständlich darstellen können.

Personen aus dem Management lernen eine Methode kennen,die es ihnen erlaubt, in kürzester Zeit einen Überblick über die An-forderungen und deren Lösung zu gewinnen. Ohne auf technischeDetails eingehen zu müssen, erlangen sie Einsicht in die vorgesehe-ne Lösung. Dies erlaubt ihnen, die richtigen Fragen zu stellen undfrühzeitig Fehlentwicklungen zu erkennen und zu korrigieren.

Benutzerinnen und Benutzer erhalten die Chance, ihre Bei-träge in den umgesetzten Lösungen wiederzufinden und zu verifizie-ren. Die verständliche Darstellung des eigentlichen Benutzerwissenslässt sie am Projekt teilhaben. Sie können mit den IT-Fachleutenauf Augenhöhe kommunizieren und werden in der künftigen Soft-ware ihre Sicht auf die Informationswelt erkennen.

Stefan BernerJuli 2016




Einleitung

Gute SoftwareSoftwarekrise ist ein Dauerthema, seit es Software gibt. Verschiede-ne Studien nennen Zahlen von 40–80 % der IT-Projekte, die in denSand gesetzt wurden. Es werden (schwer überprüfbare) Zahlen vonMilliarden von Franken genannt, die mit falsch laufenden Software-projekten verloren gehen. Eigenentwicklung von Software ist riskantund meist zu teuer. Der Einsatz von Standardsoftware verursachthäufig mehr Kosten als angenommen, und die Einsparungen beider Anschaffung werden durch die Mehraufwände bei der Einfüh-rung mehr als kompensiert. Softwaresysteme passen nicht zusam-men. Schnittstellen sind komplex und fehleranfällig. Viele Beispielezeigen auf, dass die riesigen Fortschritte der Informatik viel mehrim technischen Bereich (Speicher, Taktraten, Vernetzung) liegen alsim inhaltlichen oder qualitativen.Methoden für die Erstellung von guter Software sind bekannt

und erprobt. Warum gibt es so viele Negativbeispiele, die von aus-gebildeten Fachleuten nach erprobten Methoden erstellt wurden?Anwenderinnen und Anwender beschreiben mit Unterstützung vonBusiness-Analysten Anforderungen und Konzepte, die ihre Wünscheaus ihrer Sicht korrekt und vollständig wiedergeben. Gut ausgebil-dete Informatikerinnen und Informatiker schreiben mit modernenMethoden und Werkzeugen Software aufgrund dieser Anforderun-gen. Trotzdem sind die Kunden unzufrieden. Auch abgesehen vonden üblichen Fehlerquellen wie Nachlässigkeit, Unfähigkeit, Schlen-drian, schlechte Arbeitsmoral, schlechte Teamkonstellation etc., pas-siert es zu häufig, dass gute Leute gute Arbeit leisten und trotzdemein inakzeptables Ergebnis resultiert.Unter Softwarequalität versteht man die Gesamtheit der Merk-

male und Merkmalswerte eines Softwareprodukts, die sich auf des-sen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse



Einleitung

zu erfüllen [1]. Auftraggeber empfinden Software demnach als gut,wenn sie die Anforderungen in ihrem Sinne erfüllt.IT-Fachleute kennen ihre Methoden und -Werkzeuge, sie beherr-

schen ihr Metier. Personen der Fachabteilungen und des Manage-ments wissen, was sie brauchen. Sie wissen um die fachlichen Ab-läufe, sie haben Wünsche oder Vorstellungen, wie sie gern arbei-ten möchten. Umsysteme sind normalerweise bekannt. Die Frage istnicht, ob dieses Wissen vorhanden ist, sondern wie es in die künftigeSoftware transferiert wird. Nicht fehlendes Wissen führt zu schlech-ter Software. Es ist der ineffiziente Einsatz des bestehenden Wissens.Es ist die mangelhafte Kommunikation an den Schnittstellen zwi-schen realer und abstrakter Welt. Verstärkt wird das Problem durchden Umstand, dass alle Beteiligten im guten Glauben handeln, siehätten sich gegenseitig verstanden.Motivation für dieses Buch ist die These:

Mangelndes gegenseitiges Verständnis istdie Hauptursache schlechter Software.

Wie kommt es zu Missverständnissen? Warum reden zu viele Leuteaneinander vorbei, obwohl sie die gleiche (natürliche) Sprache spre-chen? In jeder Umgebung (Firma, Bereich, Sprachregion, Kulturetc.) gibt es Begriffe, die verwendet und von allen verstanden wer-den. Es ist die täglich benutzte Umgangssprache. Sie ist häufig nichtexakt und wer sie verwendet, der geht davon aus, dass die Empfan-genden der Botschaft die verwendeten Begriffe gleich interpretierenwie die Sendenden. Woher sollen Informatikerinnen und Informati-ker, die häufig nicht aus derselben Umgebung wie die Auftraggeberstammen, den internen Sprachgebrauch einer Firma kennen? Wiesollen sie die Anforderungsdefinitionen und Wünsche der Kundenverstehen? Wie können sie deren umgebungsspezifische Sprache ler-nen?Häufig glauben die Leute, etwas gleich zu verstehen. Sie gehen

davon aus, dass andere ähnliche Voraussetzungen haben. Wenn alleBeteiligten einer Kommunikationsrunde behaupten, sie hätten dasGesagte verstanden, ist noch nicht garantiert, dass alle das Gleicheverstanden haben. Verstehen hängt von der Sichtweise, dem Hand-



lungszusammenhang, dem Vorwissen, der Umgebung oder kurz vomKontext1 ab.In Softwareprojekten arbeiten häufig Leute zusammen, die nicht

das gleiche Kontextwissen haben: externe Berater, externe Program-mierende, Lieferanten, Leute aus Management, Fachabteilung unddem IT-Bereich, Leute unterschiedlichster Ausbildungsrichtung und-tiefe.Für eine unmissverständliche Kommunikation in heterogen zu-

sammengesetzten Gruppen braucht es zwingend einen gemeinsamenKontext. Dieser Kontext muss in einer Form dokumentiert sein, dievon allen Beteiligten verstanden wird. Als (eine) Voraussetzung fürgute Kommunikation und damit gute Software braucht es klar undeindeutig definierte Begriffe sowie eine klar und eindeutig definierteVerwendung derselben. Kurz, alle Beteiligten müssen sich verstehen.

Stimmen die Namen und Begriffe nicht, so ist die Sprache konfus.Ist die Sprache konfus, so entstehen Unordnung und Misserfolg.Gibt es Unordnung und Misserfolg, so geraten Anstand und guteSitten in Verfall.

Konfuzius (551–479 v. Chr.)

VerstehenErlauben Sie mir, mich mit drei Attributwerten aus unserer Perso-naldatenbank vorzustellen:

Stefan Berner 1955

Damit bin ich bereits mitten im Thema dieses Abschnitts: Warumverstehen Sie das? Anders gefragt, hätten Sie

Martin Peter 8472

auch verstanden? Warum nicht?Beim ersten Beispiel haben Sie vermutlich Vor- und Nachnamen,

aufgrund ihres kulturellen und sprachlichen Wissens, als solche er-1 Kontext sei hier umfassend verstanden als Mischung aus Sprache, Kultur,

Ausbildung, Erfahrung, Einstellung, Interesse etc.



Einleitung

kannt. Diese Annahme basiert darauf, dass Sie dieses Buch aufdeutsch lesen und damit ist es wahrscheinlich, dass Sie deutschspra-chige Vornamen wie Stefan, Martin oder Peter als solche erkennen.Der Wert der Zahl sowie der einleitende Hinweis auf die Vorstellungdes Autors plus vielleicht ein Foto, das Sie von mir gesehen haben,haben einen Kontext geschaffen. Ich vermute, Sie haben auf einenJahrgang geschlossen.Ohne explizites Zusatzwissen können Sie den zweiten Datensatz

nicht eindeutig verstehen. Aus der Reihenfolge des ersten Beispielsund der im Deutschen üblichen Reihenfolge Vorname – Nachnamekann Martin mit einiger Wahrscheinlichkeit als Vorname interpre-tiert werden. Sicher ist das aber nicht. Wäre zufällig das zweiteBeispiel zuerst aufgeführt gewesen, hätten Sie es vielleicht andersinterpretiert. Sie brauchen Struktur- oder Kontextinformation (wel-ches ist Vor-, welches Nachname), um sicher zu sein, dass Sie dieDatenwerte richtig, d.h. im Sinne des Autors, der Autorin verste-hen.Die Zahl im zweiten Beispiel ist im aktuellen Kontext offensicht-

lich kein Jahrgang. Vom Wert her könnte es ein Monatssalär (zu-mindest in der Schweiz) oder ein Kontostand sein. Tatsächlich istes eine Schweizer Postleitzahl. In der Schweiz lebende Leserinnenund Leser haben dies möglicherweise erkannt. Damit wird die Ver-mutung im ersten Beispiel, 1955 sei ein Jahrgang, infrage gestellt.Der Kontext (gleiche Position, gleiche Ziffernanzahl) lässt vermuten,dass die beiden Zahlen die gleiche Bedeutung haben. Tatsächlich ist1955 (nebst meinem Jahrgang) die Postleitzahl von Chamoson imKanton Wallis.Gehen wir mit der Interpretation noch einen Schritt weiter. Der

Hinweis auf die Personaldatenbank lässt vermuten, dass Vor- undNachname einen Angestellten bezeichnen. Was zum eindeutigenVerständnis der Aussage fehlt, ist die Bedeutung der Postleitzahl.Was hat ein Ort (das wird in der Schweiz normalerweise mit ei-ner PLZ assoziiert) mit dem Angestellten zu tun? Wohnt er dort,arbeitet er dort, wurde er dort geboren?Wir können das Kontextwissen, das zum Verstehen der Daten-

werte notwendig ist, als Tabelle dokumentieren (siehe Abbildung 1auf der nächsten Seite). Die Kontextbeschreibung in den beiden ers-ten Zeilen ist ergänzt um obige Beispieldaten. Eine grafische Dar-



stellung des Kontextwissens allein (ohne Datenwerte) sehen Sie inAbbildung 2).2

BernerStefan 1955

PeterMartin 8794

Vorname Name Postleitzahl

Angestellter Ortwohnt in

Abbildung 1: Tabellarische Darstellung des Eingangsbeispiels.

Angestellter Vorname

Name

wohnt in

Ort Postleitzahl

Abbildung 2: Grafische Darstellung des Kontextes des Ein-gangsbeispiels.

Kehren wir noch einmal zu den Datenwerten zurück.

Martin Peter 8472

Ohne Kontextwissen können Sie diese drei Werte nicht im Sin-ne des Autors interpretieren. Daten(-Werte) allein machen keinenSinn. Sie sind buchstäblich sinnlos. Erst die Interpretation durchdie Leserin, den Leser erzeugt einen Sinn. Aus den Datenwertenallein kann nie eindeutig herausgelesen werden, was die Werte be-deuten. Die Werte Martin und Peter werden von den meisten Le-senden als männliche Vornamen erkannt. Dass es auch Nachnamensein können, zeigt bereits auf, dass Werte allein keinen eindeutigenSinn ergeben. Nehmen Sie als weiteres Beispiel die folgenden Werte:Zürich, Bern, Basel, Genf. Alles klar? Sind es Schweizer Städten-amen? Oder Kantonsnamen? Oder die Namen der Sitzungszimmereiner Firma? Oder die Namen von Lokomotiven der SchweizerischenBundesbahn?2 Diese Darstellungsform wird im Kapitel Elemente des Informationsmodells

ab Seite 24 beschrieben.



Einleitung

Jede Kommunikation (verbal, grafisch, textuell) braucht Kon-textinformation. Diesen Kontext verwenden wir immer. Er ist dieGrundlage für die Interpretation und damit das Verständnis des-sen, was wir sehen oder hören. Wird er nicht explizit in Form einesModells, einer Syntax oder Grammatik gegeben, nutzt jede Personimplizit und situativ ihr ganz persönliches Kontextwissen. Diesessetzt sich aus Sozialisation, Umgebung, Ausbildung und persönli-chem Wissensstand zusammen. Damit zwei Personen die gleichenDatenwerte gleich interpretieren, müssen sie den gleichen Kontextauf diese Daten anwenden. Dies setzt voraus, dass beide diesen ge-meinsamen Kontext kennen und dass sie sich für diese Aufgabe aufdie Verwendung genau dieses Kontextes geeinigt haben. Nur unterdiesen Voraussetzungen können Missverständnisse vermieden wer-den. Nur so gelangt man zu einer einheitlichen Interpretation. Nurso versteht man sich.

Verstehen heisst nichts anderes, als dass mehrere Kom-munikationspartner dieselben Datenwerte unter An-wendung desselben Kontextes interpretieren.

Diese Überlegungen gelten nicht nur für die Informatik. Sie gel-ten für alle Gebiete, in denen eine eindeutige, unmissverständlicheKommunikation erwünscht oder notwendig ist. Dass es Gebiete gibt,in denen Unmissverständlichkeit nicht erwünscht ist, soll uns hiernicht weiter beschäftigen. Witze z.B. leben davon, dass Begriffe inunerwarteten Kontexten verwendet werden. Literatur wäre ohne In-terpretationsspielraum eine trockene Angelegenheit. Persönliche Ge-spräche und künstlerische Darstellungen vermitteln Informationenteilweise durch Körpersprache, Melodie, Farbe, Form etc. In diesemBuch geht es nur um Kommunikation mittels Sprache und Sym-bolen, bei der personen- und situationsunabhängige Eindeutigkeitverlangt wird.Der angestrebte, gemeinsame Kontext erlaubt allen Beteiligten in

einem Projekt eine eindeutige Kommunikation an der Schnittstellezwischen der realen und der technischen Welt.



gemeinsamer

Kontext

Abbildung 3: Kontext als Bindeglied zwischen realer Welt und IT.

