In der SW-Szene tummeln sich neben "seriösen" Software-Päpsten auch Methoden-Gurus verschiedener Couleur. Geschickt bringen sie immer wieder ihre Produkte an den Anwender, der sie dann früher oder später zur "Schrankware" erklärt. Die Enttäuschung ist dann so groß, daß die methodengeschädigten Opfer auf Jahre hinaus für die Schaffung einer sinnvollen Software-Produktions-Umgebung verloren sind.
Allenfalls in der Basis-Kategorie der Sprachen läßt sich die Unterteilung in erste, zweite und dritte Generation weiter verwenden. Die beiden anderen Kategorien für das Informations-Center und das Entwicklungs-Center sind binär auflösbar: Zunächst gibt es die Abfragesysteme für das Informations-Center. Sie unterteilen sich in interpretative Systeme und objektive Systeme.
Die interpretativen Systeme arbeiten auf der Basis eines sogenannten "Run-Time-Monitors". Das heißt, daß die Einstellungssoftware zur Ausführungszeit verfügbar sein muß. Dadurch wird die damit erstellte Anwendungs-Software für die Dauer ihres gesamten Lebenszyklus von der Entwicklungs-Software abhängig. Die der Einfachheit halber sogenannten "objektiven Systeme" erzeugen die Anwendersoftware in Form von Objektcode einer Hochsprache, in Assembler oder direkt in Objektcode. Sie sind unabhängig von der Entwicklungs-Software .
Für beide Systeme gibt es eine weitere binäre Aufteilung, nämlich in datenbankabhängige und datenbankunabhängige Abfrage-Systeme. Die beiden Abfrage-Systeme unterscheiden sich in der Anwendung im wesentlichen dadurch, daß der Anwender mit den datenbankabhängigen Abfrage-Systemen einfacher und schneller zum gewünschten Ergebnis kommt. Denn im Gegensatz zu den datenbankunabhängigen Abfrage-Systemen kann er auf die Erklärung der Daten-Deklarationen weitestgehend verzichten, sofern ein entsprechendes Datenverzeichnis die Integration von Datenbank und Abfragesystem sicherstellt.
Wird die Richtung zum Informations-Center verlassen, befindet man sich in dem bisher so undurchsichtig gebliebenen Bereich der Software-Engineering-Werkzeuge. Heute ist mit großer Wahrscheinlichkeit anzunehmen, daß die soviel zitierte Softwarekrise, die ja immer noch nicht beseitigt ist, im wesentlichen auf die Kommunikationsschwierigkeiten
zwischen der Wissenschaft, den Herstellern und den Anwendern zurückzuführen ist.
Dabei ist die Konfiguration einer sinnvollen Software-Produktions-Umgebung heute nicht schwieriger als das Planen und Einrichten einer modernen Einbauküche bei der Altbausanierung. So, wie wir die Küche unterteilen in Schränke und Geräte, die Geräte dann weiter untergliedern in Elektrogeräte und andere, die Elektrogeräte wieder aufteilen in Heiz- und Kühlaggregate und die übrigen dann in verschiedene "Werkzeuge", so einfach ist es, eine binäre Auflösung von Werkzeugklassen in einem Software-Engineering-Environment durchzuführen.
Der Innenarchitekt, der die Küche plant ist vergleichbar mit dem Unternehmensberater, der die Anschaffung von Software-Engineering-Werkzeugen maßgeblich beeinflußt. Deshalb muß das DV-Management das "Latein" der Unternehmensberater durchschauen, damit es in der Lage ist, kritisch zu bewerten, was ihm da empfohlen wird.
Denn es ist noch gar nicht so lange her, da wurde von namhaften Vertretern der Branche die Auffassung geäußert, Softwarehäuser und Unternehmensberatungen lieferten dasselbe "Gewerk". Sehr zum Leidwesen der sich als reine Softwarehersteller verstandenen Unternehmen wurde da quasi der "Hausfrau empfohlen, sich ihre Dunstabzugshaube von einem Innenarchitekten" anfertigen zu lassen.
SW-Hersteller müssen mehr Aufklärungsarbeit leisten
Andererseits sind die Unternehmensberater natürlich darauf angewiesen, daß ihnen die Software-Industrie die Informationen liefert, durch die sie in die Lage versetzt sind, ihre Auftraggeber optimal zu beraten. Gerade die Hersteller von Software-Engineering-Tools müssen deshalb mehr Aufklärungsarbeit leisten, damit der gewünschte Erfolg eintritt.
Die binäre Auflösung der Werkzeugklassen läßt sich sinnvollerweise an der Wortschöpfung aufhängen, die den Leitbegriff unseres Strebens und Schaffens prägt. Schließlich bedient man sich des Software-Engineerings zur Schaffung von Systemen, die Daten verarbeiten. Der Begriff wird auf einfachste Weise in die zwei Teile "Daten" und "Verarbeitung" geteilt. Auf der Datenseite gibt es dann zwei weitere Kategorien: die Daten-Design-Werkzeuge und die Gruppe der Werkzeuge zur Kontrolle der Datenverwendung (Data Dictionaries).
In der "Jesuiten-Dialektik" der Softwarebranche versteht man unter Daten das was die Prozesse verarbeiten. So, als würden Daten nicht die .elementaren Bestandteile in Dokumenten sein, die ebensogut im Projekt über das Projekt anfallen. Wohl auf die Tatsache, daß die Systeme empirisch gewachsen sind, ist es zurückzuführen, daß bei der Begriffsbestimmung "Data Dictionary" unabsichtlich der Blick auf den Projektphasenplan verstellt wurde.
Denn der mündige Software-Ingenieur wird vor die Konfiguration der Software-Produktions-Umgebung den Projektphasenplan stellen, in dem die produktbezogenen Dokumente von den projektbezogenen streng getrennt sind. Schließlich nutzt es einem Nichtautor wenig, wenn er heute in eine bestehende Systemdokumentation einsteigt, um eine Wartungsaufgabe zu erfüllen und sich dabei mit Informationen darüber konfrontiert sieht, nach welchen Kriterien vor mehreren Jahren das Projektteam zusammengestellt wurde.
Kein Projektmanagement ohne Produktionsstruktur
Ein brauchbares Dictionary wird gleichermaßen für Projektdaten als auch für Produktdaten einsetzbar sein. Da ein gutes Dictionary in der Lage ist, die Produktstruktur optimal zu repräsentieren, kann es dadurch auch eine Projektstruktur und die damit zusammenhängenden Dokumente optimal verwalten. Deshalb gilt auch der Grundsatz: kein Projektmanagment ohne Produktionsstruktur. Wenn man dann noch den kleinen Gedankensprung macht, daß die Arbeit eines Projektteams gleichzusetzen ist mit einer Funktion in einem Softwareprodukt, so hat das Projektteam eine Aufgabe, die sich definieren läßt als die Transformation einer Eingabe in eine Ausgabe.
An die Stelle der Funktionsbeschreibung Input - Process - Status - Output tritt der Projektschritt, gegliedert in Vorgabe - Bearbeitungs - Zustand - Ergebnis. Solch analytisches Vorgehen bei der Schaffung einer Software-Produktions-Umgebung bewahrt vor dem "Overselling", dem man gerade in diesem Bereich fortwährend ausgesetzt ist.
System-Design bleibt eine kreative Aufgabe
Denn welchen Grund gibt es noch neben einem guten Dictionary zusätzlich ein Projektverwaltungssystem anzuschaffen? Bei Einsatz eines Dictionary ist noch die Gliederung für Projekte und Produkte nötig: der Projektphasenplan und die Systemstruktur.
Wird in Konsequenz zur binären Auflösung beim Software-Engineering der kreative Prozeß vom produktiven getrennt, dann ist Schluß damit, die Kreativität auf den Computer zu verlagern. Daten-Design bleibt wie System-Design eine kreative Aufgabe des Software-Ingenieurs. Unter anderem damit ist seine Existenz begründet. Alle bisherigen Bestrebungen, aus dem Dokument der Datenanalyse auf dem Wege des Automated-Data-Design zum Datenentwurf zu kommen, sind bisher gescheitert.
Deshalb läßt sich die Klasse der Daten-Design-Tools auf die Untermenge beschränken, die aus einem erfolgten Daten-Design mit Werkzeugunterstützung für die verschiedenen Relationen und Normalformen logische Datensätze definieren. Daß für bestimmte Datenbanksysteme auch die Funktion für den Datenzugriff daraus abgeleitet und maschinell produziert werden kann, hat sich bei den meisten sogenannten "Daten-Design-Werkzeugen" noch gar nicht herumgesprochen.
Wenn es nun darum geht, auf der Datenseite Werkzeugklassen zu definieren, so erlaubt diese Betrachtungsweise die Gliederung in Datenbankdesign-Werkzeuge und Datenbankzugriffs-Generierung, sowie Dictionaries für Produkt- und Projektdaten als Dokumentations- und Datendeklarations-Werkzeuge .
Das "Y-Syndrom" (siehe auch Abbildung im Teil 1 - die Verknüpfung von Eigenschaften, die für die Zuordnung im Y-Schema symptomatisch sind) in der Software-Produktions-Umgebung beinhaltet am Ende des rechten Balkens, welcher auf das Entwicklungs-Center weist, das Feld der prozedurbezogenen Werkzeugen.
Spätestens seit den Predigten über die strukturierte Programmierung in den siebziger Jahren hat dieses Feld erheblich an Bedeutung gewonnen. Aber hier tummeln sich neben "seriösen Software-Päpsten" auch Methoden-Gurus verschiedener Couleur. Geschickt bringen sie immer wieder ihre Produkte an den Mann, der sie dann früher oder später zur "Schrankware" erklärt. Die Enttäuschung ist dann so groß, daß die methodengeschädigten Opfer auf Jahre hinaus für die Schaffung einer sinnvollen Software-Produktions-Umgebung verloren sind.
So entspringt etwa ein ganz modern aussehendes Engineering-Produkt dem Versuch, die Produktivitäten eines Vorgehensmodells mittels strukturiertem Pseudocode zu beschreiben. Dabei scheinen den Autoren zwei ganz wesentliche Aspekte abhanden gekommen zu sein:
- Der strukturierte Pseudocode zielt im wesentlichen auf die Schachtelung von Wiederholungsstrukturen. Jede Wiederholungsstruktur ist nur dann eine solche, wenn sie eine Abbruchbedingung aufweist, welche nur am Anfang oder am Ende zu stehen hat (while, until). Die einzige Abbruchbedingung in einer Projektaktivität (im konkreten Projekt) kann nur die Beendigung aller sequentiellen Arbeitsschritte sein. So gesehen, darf innerhalb einer Projektaktivität eine Wiederholungsstruktur gar nicht auftreten, geschweige denn ihre Schachtelung.
- Die Aktivitäten eines Vorgehensmodells bilden im konkreten Projekt ein Netz, wobei die parallelen Prozesse (Arbeitsschritte, die zeitgleich mit anderen Arbeitsschritten ausgeführt werden) einen wesentlichen Anteil des Netzplanes ausmachen. Der strukturierte Pseudocode kennt aber überhaupt nicht den Konstrukt der parallelen Prozesse.
Einsatz von Pseudo-Code ist mehr als bedenklich
Die Akzeptanz dieses Vorgehensmodells bei den Netzplantechnikern dürfte dabei schon "vorprogrammiert" sein. Denn diese wissen sehr wohl, daß ein Netzplan mit Kanten und Knoten paralleler Prozesse mathematisch ein nicht gerichteter Graph ist und sich dagegen der Pseudocode nur auf gerichtete Graphen (baumstrukturierte Systeme) anwenden läßt. Mit Pseudocode den Projektablauf steuern zu wollen, heißt, auf parallele Aufgaben zu verzichten: Ein Mann - ein Projekt.
Überdies ist es schon mehr als bedenklich, den sogenannten Pseudocode überhaupt zu verwenden. Seine Erfindung war eine wohl nicht zu vermeidende Wohltat für diejenigen Software-Entwickler, welche ihre Honorarabrechnung nach Zeitaufwand vornehmen. Entstanden ist der Pseudocode bei der Bewußtseinsmachung struktureller Zusammenhänge von Ergebnissen in wissenschaftlichen Aufsätzen, wobei die Formulierung der drei Grundkonstrukte programmiersprachenneutral vonstatten gehen sollte, damit unterschiedlich gebildete Programmierer die Umsetzung der Abbildung in Code nachvollziehen konnten.
Die so formulierte Botschaft der Gelehrten muß falsch verstanden worden sein, denn wie anders ist es zu erklären, daß genau das Gegenteil von dem eintrat, was eigentlich beabsichtigt war: nämlich die Aufforderung zur Abkehr von der Sprache beim Software-Entwurf. Denn die Sprachkonstrukte im Pseudocode wurden ausschließlich auf Strukturzusammensetzungen angewendet, welche zur besseren Transparenz sämtlich grafisch dargestellt waren.
Entwicklung stagniert seit zwanzig Jahren
Der andere Aspekt -im Pseudocode ist die Trennung der Steuerungsfunktionen von den Verarbeitungsfunktionen. Dies machten sich aber auch schon die Quellcode-Generatoren der dritten Generation zu eigen, welche immerhin schon seit Anfang der sechziger Jahre existieren. Spätestens durch diese Erkenntnis wird klar, daß sich die Entwicklung seit mehr als zwanzig Jahren nicht mehr von der Stelle bewegt hat. Um wirklich weiterzukommen ist der Abschied von den Struktursprachen nötig. In der Botschaft des Pseudocodes lag der Ansatz für den Befreiungsschlag schon zum Greifen nahe: die grafische Darstellungsform - ein Dokument, zu dem Ingenieure dann greifen, wenn es darum geht, technische Konstruktionen zu visualisieren.
Die von den Insidern überlieferten Grafiken beschränken sich aber leider auf die Darstellung der Systemhierarchie, entweder als Top-down-Baum oder als Outside-in-Diagramm. Auf dieser Basis ist es bis heute nicht gelungen, ein funktionierendes Software-Werkzeug anzubieten, das aus einem Systembaum ein lauffähiges Programm erzeugt. Das Verharren in einem Systemdenken, das ausschließlich auf Hierarchien aufgebaut ist, verstellt den Blick für die relevanten Konstruktionsgrafiken, die eine neue Qualität von Softwareprodukten überhaupt erst ermöglicht.
Für die bisherigen Einzelvereinbarungen zur Überlassung digitaler Festverbindungen für Datenübertragungen werden Übergangsvorschriften erlassen, die diese Verbindungen in Direktrufverbindungen umwandeln und - sofern dies im Einzelfall für den Anwender zu finanziellen Nachteilen führt - die höheren Gebühren bis Dezember 91 in mehreren Stufen wirksam werden lassen.
Diese nennenswerte Erhöhung des Geschwindigkeitsbereiches von Direktrufverbindungen wird sich erheblich auf die Datenfernverarbeitung auswirken:
- Die Nutzung von shared resources wird insbesondere im Ortsbereich gefördert.
- Antwortzeitempfindliche Anwendungen können auf größere Datenbestände an entfernten Orten zurückgreifen.
- Eine größere Zahl von Anwendungen kann auf dieselbe Festverbindung gebündelt werden, dabei läßt sich eine bessere Ausnutzung der Leitungen bei gleichzeitiger Senkung der Antwortzeiten für Dialoganwendungen erzielen.
- Ergänzt wird das Angebot von Direktrufverbindungen für 64 kBit/s durch Kanalteiler, an die amtsseitig bis zu vier HfD-64-kBit/s angeschlossen werden können, die teilnehmerseitig in Kanäle von 1200, 2400, 4800 und 9600 Bit/s aufgespalten werden.
Unter Direktrufverbindungen besonderer Art sind von der DBP bereitgestellte Übertragungswege zu verstehen, die mit privaten Datenübertragungseinrichtungen abgeschlossen werden und mit Geschwindigkeiten von bis zu 2 MBit/s oder Vielfachen davon genutzt werden. Die Endpunkte dieser Verbindungen können in demselben oder in benachbarten Ortsnetzbereichen liegen. Pro Monat beträgt die Grundgebühr 200 Mark und die Verkehrsgebühr für die ersten zwei Megabit 120 Mark je 100 Meter, für jede weiteren zwei Megabit 30 Mark je 100 Meter.
Mit ihrer Einführung zum 1. 1. 87 können Techniken, die sich nicht an die bei CCITT festgelegten Geschwindigkeitsstufen halten (wie etwa in LANs), grundstücksüberschneidend eingesetzt werden. (CCITT kennt etwa 64 kBit/s; 2, 4, 8, 34,140,565, aber keine 10 MBit/s)
Dabei dürfen jedoch zwei Punkte nicht übersehen werden:
- "Krumme" Geschwindigkeiten, die nicht in die CCITT-Hierarchie für digitale Übertragung passen, sind auf kurze Entfernungen beschränkt.
- Die Tarife sind so gestaltet, daß die in LANs oft übliche schlechte Leitungsausnutzung rasch unwirtschaftlich wird.