Ein Data-Dictionary kostet von 40 000 bis über 200 000 Mark, die Einführung oft noch ein Mehrfaches des Kaufpreises. Die DV-Abteilungen machen sich Kaufentscheidung und Einführung durchaus nicht leicht. Trotzdem erweisen sich die meisten der heute installierten Data-Dictionaries als Fehlinvestition.
Kernstück eines jeden Software-Werkzeugkastens müßte eigentlich ein Data-Dictionary sein - darüber sind sich fast alle Fachleute einig. Aber kaum eine DV-Abteilung hat eins; und die wenigen installierten Systeme werden kaum genutzt.
Eine neue Generation von Data-Dictionaries, die die Erfahrungen der Vergangenheit, die Entwicklungen im Methodenbereich und die neuesten Erkenntnisse der Software-Ergonomie berücksichtigt, kann dies ändern und endlich die alten Versprechen einlösen: höhere Produktivität und bessere Software.
Entscheidend für den Erfolg eines Data-Dictionary (DD) ist zuerst die Akzeptanz bei den Software-Entwicklern. Ein Werkzeug, mit dem niemand arbeitet, bringt keinen Nutzen. Erfolgreicher DD-Einsatz erfordert Mitdenken und Engagement - beides kann man nicht erzwingen. Und auch die umfangreichsten Verfahrenshandbücher und Anwendungsvorschriften lassen einem "DD-Benutzer wider Willen" genügend Freiraum, das System - auch ohne jede böse Absicht - gründlich zu torpedieren.
Bedienung gleicht einem Geduldsspiel
Der DD-Neuling hat zunächst zwei Probleme. Zum einen muß er sich an einige Beschreibungs- und Namensregeln gewöhnen, ohne die es einfach nicht geht. Zum anderen muß er seine Dokumentation ins DD einbringen, sie dort pflegen, und auf der Grundlage von Ergebnissen aus dem Dictionary arbeiten.
Fast jeder Software-Entwickler läßt sich heute leicht davon überzeugen, daß Namens- und Beschreibungskonventionen unerläßlich sind, um Ordnung und Überblick zu gewinnen. Und in vielen DV-Abteilungen sind solche Konventionen auch ohne DD schon lange üblich.
Aber niemand läßt sich bei seiner Arbeit gerne behindern. Genau das tun jedoch viele DD-Systeme. Unnötig komplizierte Beschreibungs- und Kommandosprachen, die gegen jeden Benutzerfehler empfindlich sind machen Eingabe und Änderung zum Geduldspiel. Für den Neuling besteht die einzige Hilfe oft nur aus umfangreichen Referenzkarten.
Beschreibungs- und Kommandosprache, Dokumentation und Fehlermeldungen sind in vielen Fällen nur in Englisch verfügbar. Und wenn ein DD dann auch noch wegen Bedienungsfehlern einfach "zusammenbricht", braucht man sich über Akzeptanzprobleme nicht mehr zu wundern.
Die Akzeptanzprobleme, die sich aus diesen Mängeln zwangsläufig ergeben, kann man natürlich dadurch umgehen, daß man auf Akzeptanz einfach verzichtet: nur der Datenadministrator "darf" mit dem DD arbeiten. Die Software-Entwickler liefern Erfassungsbelege und erhalten Ergebnislisten.
Das Akzeptanzproblem ist dann - zumindest teilweise - "gelöst", aber die Probleme, die zu beseitigen das DD ja eigentliche angeschafft wurde, tauchen sofort wieder auf. Zentrale Speicherung der Dokumentation, Aktualität, dauernde Auskunftsbereitschaft werden bei einem solchen Vorgehen aufgegeben. Auch durch die schönsten "organisatorischen Lösungen" für das Erfassen der Eingaben und Änderungen und das Verteilen der Ergebnisse sollte sich da niemand täuschen lassen.
Ein DD, auf das nicht jeder Software-Entwickler Zugriff hat, mit dem nicht jeder - natürlich in strengen aufgabenbezogenen Grenzen - selbst arbeiten kann, ist nutzlos und überflüssig.
Alle DD-Systeme erlauben es, zumindest die Informationen wiederzugewinnen, die einmal eingebracht wurden, obgleich die Form der Darstellung oft zu wünschen übrig läßt. Auch Inhaltsverzeichnisse und Cross-Referenzen lassen sich meist noch erzeugen. Wenn dann auch noch der Zugriff über Schlüsselbegriffe möglich ist, wird das schon als großer Vorteil dargestellt.
Die wirklichen wichtigen Auswertungen, wie Datenflußdiagramme, Strukturdiagramme oder (Ein- /Ausgabe) Matrizen, die in der Anwendungsentwicklung laufend gebraucht werden, die es dem Entwickler erlauben, mit seinem System wirklich kreativ zu sein, die das Versprechen von der gesteigerten Produktivität auch tatsächlich einlösen könnten, diese Auswertungen bietet kaum ein Dictionary.
Jedem DD-System liegt ein sogenanntes Dokumentationsmodell zugrunde. Darin wird festgelegt, was überhaupt im DD beschrieben wird (zum Beispiel JOB; PROGRAMM DATEI; LISTE; DATENFELD) wie diese Beschreibungen gegliedert sind und wie Beschreibungseinheiten verknüpft werden.
Bis vor kurzem waren die Dokumentationsmodelle in den DD-Systemen "fest verdrahtet". Der Anwender kaufte das Dokumentationsmodell mit dem Data-Dictionary.
Jede DV-Abteilung braucht eigenes Modell
Heute weiß man, daß es das Dokumentationsmodell schlechthin gar nicht gibt. Jede DV-Abteilung braucht ihr eigenes Modell in Abhängigkeit von der Anzahl der Mitarbeiter, der Art der Arbeitsteilung dem Reifegrad der DV, dem Ausbildungsstand der Mitarbeiter, dem Integrationsgrad der Anwendungen, um nur einige der Einflußfaktoren zu nennen.
Deshalb werden inzwischen sogenannte flexible DD-Systeme mit anpaßbaren Strukturen angeboten. Aber wie anpaßbar sind sie wirklich?
Wenn jede Anpassung umfangreiche Reorganisation - vielleicht sogar Rückgriff auf den DD-Hersteller - erfordert, kann von Flexibilität keine Rede mehr sein. Sind Änderungen am Dokumentationsmodell mit Wartezeiten und Kosten verbunden verliert man daran bald die Lust. Und folglich auch die Lust am DD, weil es den Anforderungen nicht mehr entspricht.
"Barocke" Konzepte schrecken Benutzer ab
Nicht zuletzt deshalb wird der DD-Neuling oft aufgefordert, schon vor der Installation sein Dokumentationsmodell festzulegen, und zwar eins, das möglichst bis zum Jüngsten Tag gültig bleiben soll. Die Folge sind überladene, "barocke" Modelle, die jeden Benutzer abschrecken.
Die Praxis zeigt, daß kein Dokumentationsmodell auf Anhieb gelingt. Schon und gerade die ersten Erfahrungen mit einem DD führen regelmäßig zu Änderungswünschen am Dokumentationsmodell. Und dann ist es entscheidend, daß solche Änderungen sofort und ohne großen Aufwand selbst durchgeführt und diese auch einmal ausprobiert werden können.
Die Liste der Gründe für den bisherigen Mißerfolg der DD-Systeme ließe sich noch erheblich erweitern; interessanter ist aber die Frage, wie ein erfolgreiches Data-Dictionary aussehen sollte.
Die Benutzer eines jeden DV-Systems gliedern sich in drei Gruppen: Anfänger, gelegentliche (und somit wenig geübte) Benutzer und Experten. Bei einem DD ist das nicht anders.
Ein komfortables System muß für alle Benutzer gleichermaßen geeignet sein. Anfänger werden am besten mit einer Menüsteuerung bedient, für gelegentliche Benutzer sollten neben Menüs auch schon einfache Kommandos zur Verfügung stehen, und zwar fehlertolerante Kommandos, die Parameter bei Bedarf nachfordern, Korrekturen zulassen und auch jederzeit abgebrochen werden können. Experten brauchen möglichst "intelligente" Kommandos, "die "mitdenken" und aus dem Arbeitskontext heraus fehlende Parameter einsetzen - also nur knappe Quittungen und Meldungen geben.
Daneben müssen alle Benutzer die Möglichkeit haben, jederzeit Erläuterungen (sogenannte Help-Texte) am Bildschirm anzufordern, die sich automatisch auf den Kontext, also die jeweiligen Kommandos oder Parameter beziehen. Und eine Help-Funktion, die jederzeit einen allgemeinen Überblick und auf Anfrage auch Detailinformationen liefert, gehört natürlich ebenso dazu.
Zur reinen Kommando-Eingabe kommen bei einem DD-System auch noch Textbearbeitungsfunktionen. Dazu wird ein Editor benötigt. Software-Entwickler sind normalerweise mit einem Dateiaufbereiter vertraut. Und genau diesen sollte das DD auch zur Verfügung stellen. Denn für zusätzliche Editoren besteht heute wirklich kein Bedarf mehr.
System mit "Intelligenz" zeigt auch die Lücken
Auswertungen sind gefragt, die über die reinen Speicherungs- und Editierfunktionen hinaus dem Software-Entwickler einen sofortigen überzeugenden Nutzen bieten. Dazu gehören einerseits Strukturdiagramme, Datenflußdiagramme, Matrizen, oder Verwendungsnachweise, die den Entwickler bei Analyse, Entwurf und Implementierung sofort unterstützen und spürbar entlasten. Andererseits Funktionen zum Erzeugen von fertigen Arbeitsergebnissen wie Fachspezifikationen, Programmvorgaben oder RZ-Hanbücher, mit denen dann jederzeit auch "probeweise" solche Ergebnisse erzeugt werden können, die es erlauben den "Redaktionsschluß" für die endgültige Fassung bis zum Liefertermin auszudehnen.
Mit ein bißchen "Intelligenz" ausgestattet, weisen solche Auswertungen zum Beispiel auch auf Lücken hin, stellen Verteiler bereit, und zeigen, wo und wie der Inhalt eines Arbeitsergebnisses im DD geändert oder ergänzt werden kann.
Praxis erfordert projektbezogene Strukturen
Unternehmerspezifische Dokumentationsmodelle sind sicher schon ein Fortschritt, aber noch keineswegs ausreichend. Die Praxis zeigt daß häufig projektbezogene Strukturen erforderlich sind. Darüber hinaus wünscht man sich natürlich sogenannte Benutzersichten auf die Dokumentation; das heißt, ein DD-Benutzer "sieht" immer nur das, was ihn wirklich interessiert.
Entscheidend ist dabei, daß das DD unterschiedliche Dokumentationsmodelle gleichzeitig im gleichen Dictionary unterstützt und daß die verschiedenen Dokumentationen weiterhin miteinander verknüpft bleiben.
Der Anwendungsentwicklung liegt nicht nur ein Dokumentations-, sondern auch ein Vorgehensmodell zugrunde. Während das Dokumentationsmodell festlegt, was dokumentiert wird, bestimmt das Vorgehensmodell, wie das geschieht. Ähnlich wie beim Dokumentationsmodell müssen auch beim Vorgehensmodell projektspezifische Varianten möglich sein.
Ein Data-Dictionary ist aufgrund seiner Stellung im Software-Entwicklungsprozeß ein ideales Trägersystem für ein Vorgehensmodell. Und ein DD-gestütztes Vorgehenssystem bringt erhebliche Vorteile: Benutzerführung, Einführung von Richtlinien, Konventionen und Standards auf "natürliche" Weise mit eingebauter Überprüfung. Viele der abschreckenden Routinearbeiten bei manuellen Vorgehenssystemen kann ein computergestütztes System dem Benutzer abnehmen.
Wird aber das Data-Dictionary zum Trägersystem für ein integriertes flexibles Dokumentations- und Vorgehenssystem, kommen weitere Anforderungen hinzu. Solche Systeme werden im allgemeinen verbessert und weiterentwickelt. Neue Projekte bringen zusätzliche Anforderungen, neue Methoden und Verfahren kommen hinzu oder ersetzen die früheren.
Außerdem werden zur Methodenunterstützung auch andere Werkzeuge eingesetzt: Generatoren aller Art, Bibliothekssysteme, (Pre-)Compiler und Formatierer. Und gerade im Methodenbereich ist in den nächsten Jahren mit interessanten zusätzlichen Werkzeugen zu rechnen.
Für ein natürliches und durchgängiges Arbeiten muß das DD die Möglichkeit bieten, bereits vorhandene, vor allem aber auch zukünftige Werkzeuge anzuschließen. Und das gilt für Dialog-Tools ebenso wie für Batch-Tools.
Aus dem Dictionary heraus müssen zum Beispiel Compilerläufe angestoßen werden können. Darüber hinaus sollte es während der Arbeit mit dem Dictionary möglich sein, ein Quellenprogramm aus einer Bibliothek zu entnehmen, zu editieren und wieder abzulegen.
Mächtige Sprache befreit von lästiger Kleinarbeit
Das erfordert einen direkten Durchgriff aus dem DD auf das Betriebssystem und zur Steuerung solcher Abläufe eine mächtige, DD-eigene Prozedursprache, die dem Software-Entwickler die lästige "Kleinarbeit" abnimmt.
Vor allem aber erleichtert Erweiterbarkeit die Einführung. "Endgültige" Dokumentationsmodelle sind überflüssig, langwierige Vorüberlegungen entfallen, wenn keine Gefahr mehr besteht, daß ein Fehler in der Einführungsphase später verheerende Folgen haben kann.
Viele Data-Dictionaries, die zwar installiert, aber dann nicht genutzt wurden, scheiterten bereits während der Einführungsphase, weil sie eine "Alles-oder-Nichts" -Strategie verlangen - wenn "alles" nicht geht, dann geht eben gar nichts.
*Christoph Röttger ist Geschäftsführer der Röttger & Osterberg Software-Technik GmbH Germering