Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

31.10.1986

Data Dictionary - strategisches Muß für Informationskonzepte

Das Scheuklappen-Verhalten bei der Software-Entwicklung hat ein Ende: Die immer drängenderen Forderungen der Fachbereiche an die Systementwickler lassen die Standard-Ausrede, man sei bereits mit

dem aktuellen Tagesgeschehen überfordert, nicht mehr zu. "Gedrängt durch immer komplexere Anforderungen seitens der Fachbereiche begannen wir 1983 ein Projekt zur Erarbeitung eines EDV-gestützten Systementwicklungssystems", schildert Hermann Müller, Ressortleiter Werkzeuge und Methoden bei der GDVG in Frankfurt. "Starkes Ansteigen der Projektarbeit" waren für Erwin Weber, Leiter

Systemtechnik der Münchner Osram GmbH Anlaß, "die Software-Entwicklung straffer zu planen und zu steuern". "Ständig neue Wünsche der Fachabteilungen nach individuellen Auswertungen" waren auch für Karl-Heinz Renz, Informations-Manager bei der Ravensburger Havera Probst GmbH der Grund, die "reine Datenverarbeitung" zu überdenken. Alle befragten drei Software-Spezialisten kamen bei der Neukonzeption künftiger Informationsverarbeitung zu dem Schluß, daß "zur Lösung dieser Probleme ein benutzerfreundliches Data Dictionary strategisches Muß" sei. hö

Erwin Weber, Leiter Systemtechnik, Osram GmbH, München

Anfang 1985 implementierten wir eine Standard-Orgware zur Abwicklung von Software-Entwicklungsvorhaben, ein Projekt-Abwicklungs- und Steuerungssystem. Ausgangssituation dazu war ein starkes Ansteigen der Projektarbeit, zum Teil Neuentwicklungen, insbesondere im Bereich CAI, zum Teil auch Ablösung von Alt(...)rfahren durch Dialogsysteme. Der erhöhte Mitarbeitereinsatz einschließlich externer Berater und der damit verbundene Zwang zu einer strafferen Planung und Steuerung ergab für uns das "strategische Muß", zuerst unser Vorgehen neu zu ordnen. Mit Hilfe des Vorgehensmodells konnten wir festlegen, in welcher Phase welche Ergebnisse zustande kommen müssen und welche Aktivitäten zu den Ergebnissen führen. Ein wesentliches Element des Systems ist auch, daß es Zeitpunkt und Art der projektbegleitenden Dokumentation regelt. Sehr schnell wurde der Bedarf an einem DV-gestützten Werkzeug zur Unterstützung der Projektdokumentation deutlich. Wir entschieden uns deshalb für den Einsatz eines Data Dictionary.

Bei der Systemauswahl stellten wir fest, daß im DD das gesamte Vorgehensmodell abgebildet werden konnte. Ab Ende 1985 wurde das ausgewählte System stufenweise implementiert. Heute nutzen wir das DD schwerpunktmäßig in drei Hauptanwendungsbereichen, die - jede für sich zwar autonom funktionsfähig - in der Praxis aber stark verzahnt zusammenwirken.

Der erste Bereich umfaßt die klassischen DD-Funktionen wie Feld- und Datensatzbeschreibungen, Generierung von Datenstrukturen, Verwendungsnachweise etc. Äußerst wichtig ist für uns die Nachdokumentation der vorhandenen "Altverfahren", der zweite Anwendungsbereich. Dazu setzen wir ein Analyseprogramm ein, das aus allen Cobol-Programmen die für uns relevanten Informationen herausholt und im Data Dictionary ablegt. Somit wurde transparent, wo Programm-Module verwendet werden, auf welche Dateien in welchem Modus zugegriffen wird, welche Satzstrukturen verwendet werden etc. Ebenfalls analysiert wird die Job-Control, so daß die gesamte produktive Verfahrenslandschaft und die Verknüpfung ihrer Elemente zueinander dargestellt werden. Der Effekt: Wir haben praktisch "mit einem Schlag" ein umfassendes Informationssystem über alle Programme, Jobs und Dateien. Die Benutzer können umgehend persönlichen Nutzen ziehen, was letztlich auch der Akzeptanz des Systems dient.

Für den dritten Anwendungsbereich, die Projektdokumentation, haben wir eine völlig neue Benutzeroberfläche entwickelt, die das Projektteam über zwei getrennte Funktionsbereiche durch das Vorgehensmodell führt: die Steuerungsfunktionen des Projektleiters (Projektmanagement) sowie die Verfahrensdokumentation. Das System führt den Projektmitarbeiter durch alle Phasen des Vorgehensmodells, verwaltet deren einzelne Ergebnisse und stellt nötige Verknüpfungen her:

Ein Data Dictionary ist ein Kernstück der Software- Entwicklungswerkzeuge. Eine gründlich ausgearbeitete Einführungsstrategie ist unabdingbar.

Entscheidend für den erfolgreichen Einsatz ist jedoch die Akzeptanz seitens der Benutzer. Akzeptanzhürden zu überwinden ist dann wesentlich leichter, wenn das Dokumentationsmodell den vorhandenen Festlegungen entspricht beziehungsweise angepaßt werden kann und wenn die Terminologie des Data Dictionary mit dem Vorgehensmodell identisch ist. Ein modernes DD-System läßt solche Anpassungen zu; allerdings muß man sich darüber im klaren sein, daß so etwas nicht ohne nennenswerte Eigenleistung möglich ist. Wir haben ein halbes Jahr gebraucht, um den Probebetrieb mit einem Pilotprojekt aufnehmen zu können. Heute sind wir so weit, daß alle neuen Projekte mit dem System arbeiten können. Eine weitere Voraussetzung für den erfolgreichen Einsatz ist die "Installation" eines Systemadministrators: Er führt Systemanpassungen durch, schult die Benutzer, überprüft die Einhaltung von Konventionen und fördert die Akzeptanz durch Beratung und Unterstützung.

Hermann Müller Ressortleiter Werkzeuge und Methoden, GDVG, Frankfurt

Die Gemeinwirtschaftliche Datenverarbeitungsgesellschaft mbH (GDVG) betreibt Systementwicklung und EDV-Produktion für die Bank für Gemeinwirtschaft (BfG), sonstige gemeinwirtschaftliche Unternehmen sowie einige Gewerkschaften des DGB.

Aufgrund der immer komplexer werdenden Anforderungen an die Systementwicklung begannen wir 1983 - mit Unterstützung eines Beratungsunternehmens - ein Projekt zur Erarbeitung eines EDV-unterstützten Systementwicklungssystems. Dieses Konzept soll zukünftig als Leitfaden für Entwurf und Realisierung von DV-Anwendungen in unserem Hause dienen.

Auf der Grundlage eines ersten groben Rahmenkonzeptes haben wir zunächst uns geeignet erscheinende Systementwicklungsmethoden und -werkzeuge untersucht. Dabei sind wir unter anderem auch zu der Auffassung gelangt, daß der Einsatz eines Data Dictionary-Systems im Rahmen eines modernen Systementwicklungskonzeptes unterläßlich ist.

Der Auswahlprozeß erwies sich als problematisch, da für unsere Anlage - eine Honeywell-Bull DPS-8 - kein uns geeignet erscheinendes Data-Dictionary-System auf dem Markt verfügbar war und wir gezwungen waren, mit potentiellen Anbietern erst über die Schaffung einer Honeywell Bull-Version ihres Produktes zu verhandeln. Ende 1983 stand das von uns ausgewählte System, nach entsprechender Modifizierung durch den Anbieter, auf unserer Anlage zur Verfügung.

Nun begann der sehr zeitaufwendige Prozeß der Schaffung unserer individuellen Dokumentations-Infrastruktur. Es mußte festgestellt werden, welche Ergebnisse des Systementwicklungsprozesses im Data Dictionary zu hinterlegen sind und auf welche Art und Weise dies geschehen soll.

Parallel zur Erarbeitung des Systementwicklungskonzeptes starteten wir ein Pilotprojekt, mit dem wir das Konzept sowie die ausgewählten Systementwicklungsmethoden und -werkzeuge, so auch unser Data Dictionary, in der Praxis testen konnten. Das Projekt beinhaltet die Schaffung einer maschinellen Rechenzentrums-Dokumentation (für Jobs, Programme, Listen, Belege, Druckdateien, COM-Fiche) sowie darauf aufbauend ein Online-System zur Planung und Auftragsbearbeitung im Rechenzentrum, wobei neben der eigentlichen RZ-Produktion auch insbesondere die nachfolgenden Bereiche wie Druckerpool, COM-Abteilung etc., Berücksichtigung finden. Den gesamten Bereich RZ-Dokumentation konnten wir über unser Data Dictionary lösen; zur Zeit werden alle Produktiv-Jobs mit ihren für das Rechenzentrum relevanten Komponenten nachdokumentiert.

Neben der RZ-Dokumentation werden bei Neuentwicklungen künftig alle Dokumentations-Elemente (zum Beispiel Pflichtenheft, Funktionsbeschreibungen, Programm- und Modulbeschreibungen, Datenbeschreibungen, Benutzerhandbücher) im Data Dictionary hinterlegt. Alle Datenstrukturen (Copy-Strecken), die von Anwendungsprogrammen benötigt werden, können über eine Zusatzfunktion aus dem Data Dictionary generiert werden. Unsere Source-Programme werden zur Zeit noch über die entsprechenden Systemprogramme von Honeywell Bull (Time-Sharing, Bibliotheks-System) verwaltet und gepflegt. Auch Grafiken können zur Zeit noch nicht sinnvoll im Data Dictionary erstellt werden.

Das bei uns installierte Data Dictionary ist in der jetzt eingesetzten Version ein echtes Dialogsystem und besteht im wesentlichen aus den Teilen Elementverwaltung und Online-Auskunftssystem, wobei Auskünfte nach unterschiedlichsten Kriterien möglich sind (Übersichten, Einstieg über Katalogworte etc.). Daneben existiert auch ein Batch-Auskunftssystem, über das zum Beispiel Handbücher erstellt werden können. Die firmenindividuelle Infrastruktur kann beliebig gestaltet werden. Von der Arbeit, die in sie investiert wird, hängt wesentlich auch die spätere Benutzerfreundlichkeit des Systems ab.

Karl-Heinz Renz Leiter Organisation und Informationsverarbeitung, Hawera Probst GmbH, Ravensburg

Durch zunehmende Anforderungen aus den Fachbereichen nach individuellen Ad-hoc-Auswertungen waren wir veranlaßt, unsere damalige Form der reinen Datenverarbeitung zu überdenken, da wir mit den vorhandenen Möglichkeiten, sprich: Datenverwaltung unter VSAM und Programmierung in Cobol, weder die notwendige Flexibilität innerhalb der DV noch ein für den Endbenutzer geeignetes Instrumentarium zur Verfügung hatten.

Wir entschlossen uns deshalb, die Möglichkeiten der Einführung der Informationsverarbeitung in unserem Haus zu untersuchen.

Die Lösung dieser Aufgabe war nur mit dem Einsatz eines Datenbanksystems möglich. Vorgaben für dieses Projekt waren die Einhaltung eines entsprechenden Kostenrahmens, die Beibehaltung der Systemumgebung (DOS/VSE mit CICS, IBM 4361), die Lauffähigkeit der installierten Anwendungssysteme und die volle Integration aller Teilsysteme unserer zukünftigen Datenbank.

Der Begriff Datenbank stand bei diesen Überlegungen nicht nur für die rein operationale Verwaltung der Daten, sondern für die Einheit aus den von uns definierten Komponenten

- Data Dictionary

- Datenbankmanagement-System,

- Abfragesprache/Reportgenerator,

- PC-Host-Anbindung

- S4G-Entwicklungstool,

- Emulation/Transparenz VSAM.

Die Forderung nach redundanzfreien normalisierten Datenbeständen konnte nur durch ein relationales System erfüllt werden. Tragendes Element mußte unserer Meinung nach das integrierte, möglichst aktive Data Dictionary sein, das aus seiner zentralen Stelle alle Teilsysteme sowie alle Bestände kontrolliert, die Unabhängigkeit der logischen Sicht von der physischen Datenspeicherung gewährleistet und die Belange des Datenschutzes mitabdeckt.

Hier stießen wir auf zwei unterschiedliche Philosophien. Die eine benützt das DD als Inhaltsverzeichnis, läßt unter anderem Programme ohne Eintragungen darin zu, wobei die Security-Verwaltung ebenfalls außerhalb liegt. Bei den anderen "geht ohne DD gar nichts".

Da wir, wie erwähnt, durch den Einsatz der "Datenbank" mit den dadurch verfügbaren Möglichkeiten auch den Weg zu IIV ebnen wollten, mußten wir uns für die mächtigere Lösung entscheiden. Eine der Konsequenzen war die Schaffung der Funktion Datenbankadministration, die organisatorisch außerhalb der Anwendungsentwicklung liegt. Daten administration haben wir dagegen in die Entwicklungsabteilung eingebunden.

IIV-Anwender, mit PCs oder Querys, profitieren heute von dieser Entscheidung. So liefert das DD zum Beispiel Spalten-Überschriften auf Reports so selbstverständlich, wie es den PC-Produkten (zum Beispiel Symphony) alle Feldinformationen übergibt.

Unsere Erfahrung hat gezeigt, daß die Einführung von Informationsverarbeitung in einem Unternehmen eine klare Zieldefinition erfordert, daraus ein Strategie-Konzept entwickelt werden muß, das zukunftsgerichtet einen Zeitraum von acht bis zehn Jahren abdecken sollte, nicht zuletzt vor dem Hintergrund sich wandelnder Speichertechnologien.