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.

27.02.1987 - 

Daumenschrauben für den Benutzer tragen nicht zum Erfolg bei (Teil 1):

Tool-Einführung erfordert didaktische Klugheit

In der täglichen DV-Praxis läßt sich erfahrungsgemäß kein Werkzeug allein durch "Druck von oben" durchsetzen. Wichtig für eine reibungslose Einführung ist es deshalb, den betroffenen Mitarbeitern das neue Hilfsmittel rechtzeitig schmackhaft zu machen. So die Erfahrung der Börsen-Daten-Zentrale (BDZ), Frankfurt, bei der Implementierung einer Software-Produktions-Umgebung.

Im Zuge der internationalen Anstrengungen zur Computerisierung des Wertpapiergeschäfts, zum Beispiel internationale Vernetzung, Rund-um-die-Uhr-Börse sowie elektronische Handels- und Abwicklungssysteme, hat sich die BDZ Anfang der 80er Jahre entschlossen, die bestehenden Anwendungen im Sinne einer Re-Investition an die neuen Technologien anzupassen, sowie um neue Funktionen zu erweitern. Sinn dieser Maßnahmen ist es, mit der internationalen Entwicklung Schritt halten zu können.

Dazu wurden die Zielsetzungen wie folgt formuliert:

- Umsetzung der vorhandenen Batch- und Online-Systeme in integrierte Realtime-Systeme,

- Aufbau von Datenbanksystemen und Steuerung des IBM-Produktes IMS-DB/DC,

- Vernetzung im Bereich der Datenfernverarbeitung zwischen nationalen und internationalen Anwendungsgruppen beziehungsweise Anwendungsgebieten sowie

- Einsatz neuester technologischer Hilfsmittel zur Software-Erstellung.

Zur Erreichung dieser Ziele mußten zunächst zwei wesentliche Voraussetzungen geschaffen werden: Durchführung einer Datenbedarfs- und Informations-Struktur-Analyse für das gesamte Unternehmen sowie Entwicklung eines Software-Engineering-Konzepts und Aufbau einer Software-Produktions-Umgebung.

Bis Ende 1982 war die Informations-Struktur-Analyse so weit vorangeschritten, daß sich eine Aussage über den Integrationsgrad und die Komplexität verschiedener Einzelmaßnahmen treffen ließ. Aufgrund dieser Untersuchung entschlossen wir uns, zunächst die zentralen Informationen des Wertpapierbereichs auf ein neues Datenhaltungskonzept umzustellen und zeitversetzt die operativen Systeme zu entwickeln. Etwa gleichzeitig wurde der erste Entwurf eines Software-Engineering-Konzepts in Form eines Projekthandbuches vorgelegt.

Beim Aufbau eines Vorgehensmodells und einer Software-Produktions-Umgebung sind grundsätzlich zwei Wege denkbar: zum einen die Installation eines integrierten oder mehrerer Einzelwerkzeuge und die Übernahme der hierin verwendeten Konzepte und Methoden; zum anderen die Entwicklung eines Phasenkonzepts (Vorgehensmodell), Zuordnung geeigneter Methoden zur Erreichung der im Phasenkonzept vorgegebenen Ziele und Auswahl eines oder mehrerer Werkzeuge zur maschinellen Unterstützung der methodischen Vorgehensweise.

Kein Werkzeug läßt sich nur durch "Druck von oben" durchsetzen. Eine wesentliche Voraussetzung für den erfolgreichen Einsatz von Tools ist die Akzeptanz bei den Mitarbeitern sowie das Verständnis für die Ziele und methodischen Grundlagen. Diese Basis mußte bei der jungen Entwicklungsmannschaft der BDZ mit einem Durchschnittsalter unter 30 Jahren erst einmal geschaffen werden. Die Mitarbeiter haben zwar eine hochqualifizierte Ausbildung - überwiegend Akademiker mathematisch-technischer Fachrichtungen-, waren aber mit den Methoden des Software-Engineerings und moderner Datenhaltungskonzepte nicht vertraut.

So fiel die Entscheidung zwangsläufig für den zweiten Ansatz. Zunächst wurde also gemeinsam mit den Entwicklern ein ergebnisorientiertes Vorgehensmodell erarbeitet. Im Gegensatz zu checklistenorientierten Phasenkonzepten werden hierbei nur die gewünschten Ergebnisse einer Phase vorgegeben - die Art und Weise, wie ein Mitarbeiter zu diesen Ergebnissen gelangt, bleibt offen. Auf diesem Wege wurde den Mitarbeitern das Prinzip der stufenweise Entwicklung und des Software-Life-Cycle nahegelegt. Parallel dazu wurden geeignete Methoden den Entwicklungsphasen zugeordnet und als verbindliche Norm verabschiedet (siehe Kasten: Phasenaufteilung und ihr zugrunde liegende Methoden").

In dieser Auflage sind zwei Punkte bei den "Methoden" hervorzuheben, die zunächst nur eine ausschließlich technische Bedeutung zu haben schienen:

- das konzeptionelle Datenbank-Design (KDBD) in er Phase 2 und

- Modularisierung der Software nach dem Schichtenmodell.

Unter konzeptionellen Datenbank-Design versteht man den Entwurf eines Datenmodells nach den Regeln der Normalisierung und der kanonischen Synthese - unabhängig vom physischen Datenbank-System (siehe Abbildung 1). Ein überflüssiger Schritt für viele, deren Datenhaltungsstruktur durch das DBMS jeweils vorgegeben ist: zum Beispiel hierarchische Strukturen bei IMS oder Netzwerkstrukturen bei UDS.

Als wir uns 1983 zu dieser Vorgehensweise entschlossen, bestand die Überzeugung, daß wir in absehbarer Zeit kein zweites DBMS neben IMS einsetzen, geschweige denn eine vorhandene Anwendung auf ein zum Beispiel relationales DBMS konvertiert wurden; der klassische Fall, in dem ein KDBD von unschätzbarem Wert ist. Wir glaubten, daß Datenmodellierung, und damit Datentransparenz sowie Verständnis der Datenzusammenhänge, bei den Entwicklern zum Design jeder Datenbank in jedem DBMS notwendige Voraussetzung sei.

Anwendungssystem wird in drei Ebenen aufgeteilt

Heute haben wir neben den IBM-Großrechnern mit MVS und IMS auch einen Siemens-Großrechner installiert. Wir entwerfen zur Zeit eine komplexe neue Anwendung unter UTM und UDS und werden eine Verbindung zwischen den Rechnern sowohl auf der DC-Seite (Transit-CD) als auch auf der Daten- beziehungsweise Programmebene herstellen (LU6). Dazu dürfte es notwendig sein, einige Daten entweder logisch oder physisch redundant zu halten; es handelt sich also um ein Problem, das anwendungstechnisch, wenn überhaupt, nur über einen konzeptionellen Datenansatz zu lösen ist.

Unter Modularisierung nach dem Schichtenmodell verstehen wir die Aufteilung eines Anwendungssystems auf die drei Ebenen Kommunikation, Anwendung und Daten (Abbildung 2).

Es wäre sicher vermessen zu behaupten, daß wir mit dem KDBD und dem Schichtenmodell eine Portabilität der Anwendung erreicht hätten. So müssen wir für die Siemens-Welt zunächst einmal eine IBM-IMS-analoge Schnittstelle entwickeln, um Unterschiede der DC-Monitore zu minimieren. Auch auf der Datenebene stehen noch Investitionen an, um zum Beispiel unterschiedliches Restart und Synchronisationshandling auszugleichen. Eine gewisse Unabhängigkeit vom Zielrechner ist jedoch erreicht und vor allem bei Management und Mitarbeitern die Bestätigung, daß der 1983 eingeschlagene Weg richtig gewesen ist.

Über den Nutzen eines Data Dictionary als Entwicklungswerkzeug ist in der Vergangenheit viel diskutiert worden. Die Praxis hat gezeigt daß die Aufnahme bestehender Anwendungen in ein Dictionary ein fast aussichtsloses Unterfangen ist. Steht man jedoch wie die BDZ am Anfang eines Entwicklungsprozesses und baut des Dictionary auf den Neuentwicklungen auf, hat man gute Chancen auf Effizienzverbesserung und Steigerung der Produktqualität.

Dazu ist es aber absolut erforderlich, das Dictionary nicht nur in der Phase "Codierung und Modul-Test" zur Generierung von Kontrollblöcken oder Copy-Strecken einzusetzen, sondern es ab dem "Fachkonzept" phasenübergreifend zu benutzen. Auf diese Weise können zum Beispiel logische Datenobjekte und ihre Elemente, die im "Fachkonzept" zunächst dokumentarisch im Dictionary gespeichert sind, ohne viel Mehraufwand im "DV-Konzept" in Dateien, Datenbanken und Felder umgewandelt werden. Daraus lassen sich in der Codierphase Copy-Strecken und Kontrollblöcke generieren - und alles bei garantierter Datenkonsistenz:

Die Rahmenbedingung "Dictionary ja, aber phasenbegleitender Einsatz muß möglich sein" wurde auch von der Entwicklungsmannschaft mitgetragen und war gleichzeitig das K.O.-Kriterium für dezentrale Entwicklungssysteme. Zudem wurde der Ruf nach weiterer maschineller Unterstützung des Entwicklungsprozesses laut. Es galt also zu diesem Zeitpunkt (Mitte 1983) die Frage zu beantworten: "Ein integriertes Produkt oder verschiedene Einzelwerkzeuge?".

Bei der Beantwortung dieser Frage, hinter der sich immerhin ein Volumen von 300 000 bis 500 000 Mark für die Software und noch einmal dieselbe Summe für Integration und Schulung verbirgt, ist man leicht geneigt, aufwendige Produktivitäts- und Qualitätsvergleiche anzustellen. Wer will sich schon nachsagen lassen, für dieses Geld "Schrankware" gekauft zu haben? Wir behaupten jedoch, daß während einer vier- bis achtwöchigen Probeinstallation kaum mehr möglich ist, als die Funktionalität eines Produkts nachzuweisen. Produktivitätssteigerungen gegenüber dem Status quo nachzuweisen, dürfte mit vertretbarem Aufwand unmöglich sein, zumal zum letzteren normalerweise auch die Produktivitätszahlen des Status quo fehlen.

Also erstellten wir auf Basis der technischen Rahmenbedingungen und dem vorgegebenen Software-Engineering-Konzept mit seinen Methoden einen Kriterienkatalog und verglichen die Software theoretisch. Begleitend wurde bei Referenz-Installationen und über Fachzeitschriften weiteres Informationsmaterial herangezogen. Das Ergebnis war, obwohl fast erwartet, ziemlich frustrierend: Es gibt keine in allen Punkten zufriedenstellenden Softwareprodukte.

Trotzdem haben wir die Entscheidung getroffen, eine maschinengestützte Produktions-Umgebung aufzubauen, getreu nach dem Motto "Lieber eine 80prozentige Lösung implementieren, als auf die 100prozentige Lösung warten".

Dazu war jedoch ein erneutes Ranking der Kriterien notwendig. An die erste Stelle rückte der Wunsch nach einem phasenübergreifenden Dictionary. Damit waren alle zu diesem Zeitpunkt angebotenen integrierten Software-Entwicklungs-Systeme aus dem Rennen, da keines über ein leistungsfähiges Dictionary verfügte. Auch von den reinrassigen Dictionary-Systemen hielten nur zwei den K.-O.-Kriterien Stand: das IBM-Data-Dictionary und der Data-Manager von msp. Wir haben uns für die Installation des Data-Manager entschieden, der als aktives Dictionary und mit vom Benutzer definierbaren Strukturen eher auf phasenbegleitende Unterstützung ausgelegt ist.

Die dynamische Weiterentwicklung des Data-Manager - stellvertretend für die vielen Verbesserungen und Erweiterungen seit der Installation in unserem Hause 1983 sei hier das Panel-Driven-Processing (PDP) genannt - bestätigt im nachhinein ein weiteres Entscheidungskriterium: ein Produkt zu nehmen, das auf der Mainlinie des Herstellers liegt.

Die Einführung und organisatorische Einbettung des Data-Manager geschah im Rahmen eines Pilotprojektes und anschließender Breitenschulung. Anfang 1984 wurde die Benutzung für alle Neuentwicklungen verbindlich erklärt. Wir haben heute 30 Member-Typen und etwa 10 000 Eintragungen im Data-Dictionary. Damit stoßen wir bei komplexen Auswertungen auf erhebliche Performance-Probleme, da ein Command unter Umständen 60 000 und mehr I/Os verursacht.

Kritisch anzumerken sind auch die unzureichenden Möglichkeiten, variable Dokumentation aus dem Dictionary zu erstellen. Hier haben wir inzwischen zur Selbsthilfe gegriffen und bereiten die Standard-Ausgabe mit eigenentwickelten Programmen anforderungsgerecht auf. Dennoch würden wir dieselbe Entscheidung heute wieder treffen, denn nach anfänglicher Skepsis möchte inzwischen kein Mitarbeiter den Data-Manager missen.

*Thomas Gebert ist Leiter Anwendungsprogrammierung bei der Börsen-Daten-Zentrale (BDZ), Frankfurt.