Die für die Systementwicklung benötigten Daten sind hochgradig miteinander vernetzt. Ein vernünftiger Ansatz zur rechnergestützten Vorgehensweise muß deshalb datenbankorientiert sein. Am Beispiel des Dialog-Vorgehens- und Methodensystems "Guide" zeigt Hans-Jürgen Mährländer*, daß DB-Konzepte auch für die "Fachabteilung Systementwicklung" unerläßlich sind.

Jeder DV-Profi hat umfassende Kenntnisse über moderne Anwendungssoftware: So wird zum Beispiel für integrierte Systeme ein Datenbanksystem verwendet, weil bekannt ist, daß Daten in logischer Beziehung zueinander stehen und ein Datenbanksystem diese Beziehungen automatisch verwaltet. Außerdem sind Daten unabhängig von Verarbeitungsprogrammen zu halten und vielfältig verarbeitbar. Daten müssen sorgfältig, zum Beispiel nach der Methode der logischen Datenanalyse, analysiert und strukturiert sein.

Es wäre nämlich tödlich, Daten nur aus einer einzigen Verarbeitungssicht heraus zu strukturieren, da dann nicht gewährleistet ist, daß die gleichen Daten auch für andere Sichten Verwendung finden können. Die verschiedenen Benutzersichten müssen allerdings auf einer redundanzfreien Speicherung basieren, da nur so die Konsistenz und Wartbarkeit auf Dauer sichergestellt werden kann.

Katalog vertuscht Chaos

Das ist jedem DV-Fachmann sehr geläufig; nur nicht, wenn es um die eigenen Daten geht, nämlich diejenigen, die als Grundlage der Systementwicklung nötig sind. Diese Daten werden nämlich in Gebilde wie Partitioned Data Sets oder Projektbibliotheken gesteckt, die so tun, als hätten die vielen beziehungslosen "Members", die darin stehen, tatsächlich nichts miteinander zu tun. Ein sogenannter "Katalog" versucht, das sich bald anbahnende Chaos zu vertuschen.

Komfortabel heißt ein solches System, wenn der Katalog wie zum Beispiel bei VM, "Pet/Maestro" oder "Unix/PWB" hierarchisch gegliedert werden kann, um wenigstens ein bißchen Ordnung in das Ganze zu bekommen. Damit kann wenigstens eine Anwendungssicht fest "verdrahtet" werden, was jedem logischen Datenanalytiker kalte Schauer über den Rücken jagt.

Man stelle sich vor, die gesamte Anwendungssoftware würde mit einem solchen Datenkonzept an den Endanwender ausgeliefert. Dann gabe es längst keine DV mehr.

Entscheidende Daten sind hochgradig vernetzt

Trotzdem ist die beschriebene Situation "State of the Art". Die Daten, wie Funktions- und Datenbeschreibungen, Maskenlayouts, Modulstrukturen, Programmcode oder Testdaten verschwinden als "Members" in einer Bibliothek in einem bestimmten Fach. Die einzige Verarbeitungsform besteht darin, daß man die Daten so wieder herausholen kann, wie sie hineingestellt wurden, vielleicht noch in einer festen, hierarchischen Struktur. Dann kann man noch daran herumeditieren.

Wenn das Verarbeitungsproblem so simpel wäre wie die einfachen Mittel, die dafür zum Einsatz kommen, wäre alles gut. Aber die Daten, um die es bei der Systementwicklung geht, sind hochgradig miteinander vernetzt. Es ist zu unterscheiden zwischen Daten und Funktionen (Verarbeitungsprozesse) und das fein säuberlich getrennt nach fachlicher Sicht und DV-technischer Sicht. Die wichtigsten Informationen liegen in der Verknüpfung der Daten als mehrstufige Verwendungsnachweise oder Schnittstellenbetrachtungen, zum Beispiel" welche betrieblichen Funktionen werden durch welche Programm-Module mit welchen Bildschirmmasken abgedeckt ".

DB-Produkte gehen oft an Systementwicklung vorbei

Ein vernünftiger Ansatz zur rechnerunterstützten Systementwicklung kann daher nur ein datenbankorientierter sein. Das Wissen über die Realisierung betrieblicher Informationssysteme ist auch für die Systementwicklung anzuwenden: Wir konzipieren eine Datenbank nach sorgfältiger Datenanalyse und entwickeln Funktionen zur Verarbeitung der Datenbankinhalte.

Daß dies bisher in den wenigsten Produkten beherzigt wurde, liegt daran, daß die Möglichkeiten normaler Datenbanksysteme die Erfordernisse der Systementwicklung nicht optimal abdecken. Das fängt bei den Datentypen an, die wegen der beschriebenen Aufgabenstellung der Systementwicklung meist textlich orientiert sind.

Auch die gewünschten Ergebnisse weichen von kommerziellen Anwendungswünschen erheblich ab: Sie sind einerseits Dokumente wie Phasenergebnisse bis hin zu Handbüchern, andererseits Strukturinformationen, die sich besser als Baum- und Einrückdiagramme oder Matrizen darstellen lassen.

Wenige DDs unterstützen benötigte Textdatentypen

Die Verknüpfungen haben für die Systementwicklung eine andere Qualität als bei normalen Datenbanksystemen. Sie tragen nämlich Informationen; im Minimum dergestalt, ob eine Verknüpfung zwischen zwei bestimmten Ausprägungen eines Objektes vorhanden ist odernicht (zum Beispiel zwischen Maske und Modul).

Data-Dictionaries sind mögliche Datenbanksysteme für die Systementwicklung, da sie die Verknüpfung der Systemelemente automatisch verwalten. Aber nur wenige unterstützen auch genügend die benötigten Textdatentypen und verfügen über eine eigene Implementierungssprache, um eine Unterstützung über alle Phasen realisieren zu können. Ein solches System wurde daher von der GMO als Trägersystem für "Guide" ausgewählt. Damit bildet das Herz der Systementwicklung eine Entwicklungsdatenbank.

Bock wird leicht zum Gärtner gemacht

Die, Anbieter traditioneller Projektbibliothekssysteme mit starren Hierarchien von Texten sind sich natürlich der Schwäche ihrer Produkte für eine integrierte Software-Produktions-Umgebung bewußt. Sie bieten daher eine Data-Dictionary über einen "Tool-Anschluß" an. Da wird nun endgültig der "Bock zum Gärtner" gemacht. Dies ist genauso, als wenn man die "Integrierte Finanzbuchhaltung" - um bei diesem Beispiel zu bleiben - in kleinen, unabhängigen, sequentiellen Dateien organisieren und dem unzufriedenen Anwender anbieten würde, über eine Schnittstelle eine Datenbank zur Verfügung zu stellen, in die er dieselben Daten noch einmal laden soll. Das wird doch wohl keiner vorschlagen? Umgekehrt wohl schon eher, nämlich die aktuelle Datenbank zur Archivierung in ein Bibliothekssystem zu laden und dabei zum Beispiel die Funktionen der Versionsführung zu nutzen.

Ein universelles Data-Dictionary - das heißt nicht nur der Data-Dictionary-Rucksack eines bestimmten Datenbanksystems - ist nicht ein x-beliebiges Tool im umfangreichen Werkzeugkasten, sondern das Herz der rechnergestützten Systementwicklung schlechthin. Und wo das Herz nicht gesund ist, nützen auch lackierte Fingernägel nichts.