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.

30.11.1984 - 

Vom isolierten Tooleinsatz zur integrierten Methoden- und Werkzeugstrategie (Teil 2, Schluß):

Ideale Produktionsumgebung nicht in Sicht

Die Informationstechnik gilt als der Wirtschaftsbereich mit der höchsten Innovationsgeschwindigkeit. Gleichwohl bindet etwa die Entscheidung für ein Betriebssystem oder ein Datenbankverwaltungssystem den Anwender auf zehn bis zwanzig Jahre. Größere DV-Anwendungssysteme leben - wenn auch mit laufender Erweiterung und Anpassung - von ihrer Struktur her meist ebenfalls länger als eine Dekade. Das gleiche gilt grundsätzlich auch für Methoden und Werkzeuge in der Software-Entwicklung. Ein Data Dictionary, eine Projektmethodik oder ein Testverfahren bleiben nach einer langen Einführungsphase über viele Jahre im Einsatz. Eine Umstellung ist in allen oben erwähnten Fällen nur aus schwerwiegenden Gründen möglich und mit hohem Aufwand verbunden.

Ein wichtiges Instrumentarium der SW-Entwicklung sind die Data Dictionaries. Ein Data Dictionary/Directory ist zunächst ein Verzeichnis von Daten (Datenbanken, Dateien, Sätzen oder Feldern) mit einer Beschreibung pro Datenelement. Heute umfassen Data Dictionaries aber auch Beschreibungen von Funktionen, Programmen, Jobs, Verbindungen zwischen Funktionen und Daten und weiteren entwicklungsrelevanten Informationen. Sie werden somit zu Vorläufern von Entwicklungsdatenbanken, in denen sämtliche während der Entwicklung und des Betriebs von Software anfallenden Daten verwaltet werden.

Textbehandlung läßt zu wünschen übrig

Voraussetzung für die Verwendung eines Data Dictionarys als Entwicklungsdatenbank sind entsprechende Eigenschaften:

- Das Data Dictionary muß wie ein allgemeines Datenbankverwaltungssystem eine frei entwerfbare Datenstruktur abbilden können.

- Das Data Dictionary muß sowohl formatierte Daten (satz- und feldweise) als auch nicht formatierte Daten (Texte) verarbeiten können. Texte sind aus Sicht des Benutzers eine spezielle Form von Feldern (Attributen). Der Systementwickler muß sich somit nicht selbst um die Verknüpfung von formatierten und nicht formatierten Daten kümmern.

- Für die Eingabe und Änderung der Entwicklungsdaten müssen leistungsfähige Hilfsmittel zur Verfügung stehen. Für die formatierten Daten muß wenigstens eine formularorientierte Editierung möglich sein. Für die nicht formatierten Teile wird ein Texeditor benötigt, wie er oben besprochen worden ist.

Derartige Data-Dictionary-Systeme sind heute auf dem Markt nicht erhältlich. Zwar ist es beispielsweise in "Datamanager" möglich, die Entwicklungsdatenbank ziemlich frei zu entwerfen sowie eine formularorientierte Eingabe über den "Controlmanager" zu realisieren, doch fehlt eine auch nur einigermaßen zufriedenstellende Behandlung von Text in der geforderten integrierten Form [MSP, 1, 2].

Die bei den Texteditoren bereits festgestellte Spezialisierung auf die Softwareentwicklung ist auch bei den Data-Dictionary-Systemen im Vergleich zu allgemeinen Datenbankverwaltungssystemen erkennbar. Spezielle Funktionen sind beispielsweise die Ableitung von Dictionary-Einträgen aus dem Quellcode, Generierung von Datendefinitionsanweisungen für Programme, vorbereitete Abfragen wie etwa für Verwendungsnachweise und die dazugehörigen Berichtsformate sowie die Generierung von Prüfroutinen für Datenelemente aus der Definition ihrer Wertebereiche oder die Generierung von Testdaten.

Der Nutzen von Data-Dictionary-Systemen gegenüber Textbibliotheken liegt in der stärkeren Strukturierung der Informationen. Textbasierte Systeme haben als kleinste Informationseinheit den Textbaustein (Member). Erfaßt man also beispielsweise die Informationen, die bisher auf dem manuell geführten Formular "Filebeschreibung" geführt wurden, so geht zunächst die Information über die darin differenzierten Datenelemente für die maschinelle Weiterbearbeitung verloren. Etwa ein Verweis auf das erzeugende Programm ist nur noch als Zeichenkette vorhanden und somit vom Rechner nicht mehr in einer systemweiten Prüfung auf Konsistenz verwertbar. Data Dictionaries erlauben aber gerade derartige Auswertungen.

Perfektion bleibt unerreichtes Ziel

Der Unterschied zwischen den beiden Ansätzen betrifft eine grundsätzliche Entscheidung in der Werkzeugstrategie. Textbasierte Systeme müssen langfristig in eine Sackgasse führen, da der Grad ihrer Differenzierung von Daten für eine langfristige Integration aller Werkzeuge nicht ausreicht In vielen Unternehmungen ist eine Datenbasis anzutreffen, wie sie im einleitenden Fallbeispiel dargestellt worden ist. Endbenutzerunterstützung, Dezentralisierung, Integration und andere Entwicklungen, die heute vor den Informatik-Abteilungen der Unternehmungen stehen, sind auf dieser Grundlage kaum zu bewältigen. Aus diesem Grund laufen heute vielerorts Projekte zur umfassenden und langfristigen Planung von Anwendungen und Datenbeständen.

Im Mittelpunkt steht dabei die Bereinigung der Datenbasis in sogenannten Unternehmungsdatenbanken (subject databases). Langfristiges, nie vollständig erreichbares Ziel ist ein einziges, in sich konsistentes konzeptionelles Schema für die ganze Unternehmung.

Datenentwurf im Mittelpunkt

Der Datenentwurf gerät, nachdem er viele Jahre vernachlässigt worden ist, in den Mittelpunkt der Methodendiskussion. Dabei eröffnen sich allerdings neue Schwierigkeiten. Eine mittlere bis große Unternehmung unterscheidet heute in der maschinellen Verarbeitung zwischen 10000 und 30000 Datenelementen. Bereits ein mittleres Projekt kann mehrere hundert Datenelemente berühren. Bei diesen Größenordnungen gerät der Mensch rasch an die Grenze seiner Verarbeitungskapazität. Eine konsequente Strukturierung der Daten setzt maschinelle Hilfsmittel voraus.

Ein solches Instrument ist zunächst auf rein beschreibender Ebene das Data Dictionary. Darüber hinaus geht eine Datenbank-Entwurfshilfe wie beispielsweise der "Designmanager" [MSP, 3]. Er unterstützt den Datenbankentwurf im Sinne der Normalisierung nach Codd. Eine Entwurfshilfe für die Normalisierung muß sowohl das Top-down- als auch das Bottom-up-Vorgehen unterstützen.

Im Top-down-Vorgehen des Datenbankentwurfs werden aus dem Informationsbedarf, der aufgrund einer Erhebung erfaßt worden ist, zunächst die Entitätstypen (Sätze) abgeleitet. Dann werden die Beziehungen zwischen den Entitätstypen hergestellt und die Attribute (Felder) pro Entitätstyp ermittelt. Das Entwurfsinstrument unterstützt diesen Weg im wesentlichen durch die Möglichkeit, die Entwurfsergebnisse bei ihrer Entstehung zu erfassen und zu verwalten. Einfach erkennbare Mängel werden angemahnt.

Im Bottom-up-Verfahren des Datenentwurfs geht man von den verschiedenen Benutzersichten (Logical User Views) aus. Das ist die Sicht auf die Daten, die ein einzelnes Programm oder eine einzelne Abfrage besitzt. Das Programm "Provisionsermittlung" sieht beispielsweise jenen Teil der Verkaufsdaten, der für seinen Zweck notwendig ist. Es benötigt die Aufträge, die Kunden und die Vertreter zur Ermittlung der Provisionswerte und die Vertreter sowie die Personalstammsätze zur Speicherung der Provisionen.

Der Entwerfer beschreibt in diesem Vorgehen alle von ihm benötigten Attribute (Felder) und ihre gegenseitigen Abhängigkeiten. Er sagt beispielsweise, der Name des Vertreters sei voll funktional abhängig von der Personalnummer [s. dazu Codd, S. 381ff.]. Aus diesen Einzelangaben leitet nun das Entwurfswerkzeug die Entitätstypen (Sätze) und ihre Beziehungen ab. Etwaige Inkonsistenzen, die in den Angaben des Entwerfers enthalten sind, werden moniert.

Über das Top-down-Vorgehen wird gewöhnlich ein Rahmen für die weitere Entwicklung geschaffen. Werden im Projektablauf die Benutzersichten entwickelt, so ergeben sich laufend Änderungen am vorhandenen konzeptionellen Schema (Rahmen). Der Rechner übernimmt nun die Abstimmung der bottom-up entwickelten Benutzersichten mit dem top-down vorgegebenen Rahmen.

Generatoren bauen Sprachschwächen ab

Der Wert eines Datenbankentwurfs-Werkzeugs ist an kleinen Beispielen nicht ersichtlich. Der Mensch beherrscht diese auch ohne maschinelle Hilfe Die Situation ändert sich aber bei Aufgabenstellungen, wie sie in der Praxis den Normalfall darstellen

Ein weiteres Hilfsmittel zur effizienten SW-Entwicklung stellen die Code-Generatoren dar Das sind Werkzeuge, die aus wenigen Anweisungen in einer Generatorsprache (Makros) ein Mehrfaches an Anweisungen in einer Zielsprache (meist Cobol) erzeugen. Sie gestatten auch Anweisungen in der Zielsprache und Makros zu mischen, so daß einerseits die Vorteile aus der Mehrfachverwendung von Code in Form von Makros und andererseits die Möglichkeiten einer konventionellen Programmiersprache genutzt werden können.

Ein Generatorverbund wie etwa Delta (Sodecon AG) ist ein Zusammenschluß von Einzelgeneratoren so daß die Schnittstellen der Generatoren untereinander abgestimmt sind und die Verbindung maschinell geschieht. Delta realisiert das derzeit am weitesten ausgebaute Generatorkonzept.

Ein Generator ist ein Hilfsmittel, Schwächen der konventionellen Programmiersprache abzubauen. So bietet beispielsweise Delta die Möglichkeit,

- über den Strukturierten Programmgenerator die ungenügenden Kontrollkonstrukte (Steueranweisungen) von Cobol zu überwinden,

- über den Filegenerator Anweisungen, die in Cobol immer wieder neu geschrieben werden müßten, zu Makros zusammenzufassen und wie mächtigere Befehle zu verwenden, und

- über die generellen Fähigkeiten des Makrogenerators den bausteinartigen (modularen) Aufbau von Programmen zu unterstützen.

Der größte Nutzen von Programmgeneratoren liegt ihrer Mehrfachverwendung von Code, also im Vermeiden von redundanter Codier- und Testarbeit.

Die häufigste Form des Prototyping ist die Simulation des Dialoges. Der Benutzer erhält somit in der Entwurfsphase bereits die Möglichkeit, die Zweckmäßigkeit der vorgeschlagenen Lösung zu beurteilen. Aufgrund von statischen Beschreibungen des Dialoges allein ist es erfahrungsgemäß schwierig, sich den späteren Ablauf vorzustellen.

Vereinfachung als Zielvorgabe

Das Prinzip einer Prototypesprache ist, die Funktionsweise einer Anwendung mit wenigen Anweisungen zu beschreiben. Dies ist nur durch die Bildung sehr mächtiger Programmfunktionen möglich. Diese sind letztlich Zusammenfassungen von Programmcode, der in konventionellen Programmiersprachen immer wieder neu geschrieben wird, zu mehrfach verwendbaren Funktionen in Form von Anweisungen. Das wiederum ist der gleiche Weg, den auch die Entwickler einer VHLL beschreiten.

Der Unterschied zwischen Prototyping-Werkzeugen und VHLLs liegt in der Ausführungseffizienz. Prototyping-Werkzeuge werden ausschließlich unter dem Aspekt der Einfachheit und unter Vernachlässigung der Performance entwickelt; VHLLs haben von vornherein das Ziel, Produktionsversionen von Programmen zu liefern. In praxi gehen aber auch Prototypversionen häufig unverändert in den Routinebetrieb über, wenn über sie keine zu großen Transaktionsvolumina abzuwickeln sind.

Zu den VHLLs sind neben den Sprachen zur einfachen Entwicklung von Dialogen weiter folgende zu zählen:

- Abfragesprachen für Datenbanken mit den darin eingebauten Fähigkeiten zur Berichtsgenerierung (zum Beispiel SQL).

- Sprachen und interaktive Systeme zur Tabellenkalkulation (zum Beispiel Plancode und Multiplan).

Debugger sind wertvolle Testhilfen

Vergleicht man Prototyping-Sprachen und VHLLs mit Code-Generatoren, so stellt man auch hier große Übereinstimmungen fest. In beiden Fällen wird die Verbesserung über Funktionen erreicht, die mächtiger als die in konventionellen Sprachen sind. Vor allem die Einbettung in eine vorhandene Sprache beziehungsweise die Existenz einer abgeschlossenen eigenen Sprache unterscheidet die beiden Wege.

Testhilfen sind Werkzeuge zur Prüfung von Entwürfen und Programmen. Beim derzeitigen Stand der Technik heißt das fast ausschließlich Prüfung des tatsächlichen Verhaltens von Programmen auf Übereinstimmung mit dem beabsichtigten Verhalten.

Die wichtigsten Testhilfen sind:

- Debugger,

- Testfallgenerierung,

- Generierung der Testumgebung,

- Abdeckungsanalyse,

- Ergebnisvergleich,

- Testwiederholung.

Die Möglichkeiten eines Betriebssystems zusammen mit denen der Programmiersprachen beziehungsweise Übersetzer decken einen Teil des Bedarfs an Testhilfen ab.

Ein Hilfsmittel zur detaillierten Analyse des Ablaufes in einem Programm ist der Debugger. Er ist entweder Bestandteil des Compilers (Interpreters) wie zum Beispiel im PL/ 1-Check-out-Compiler oder ein getrenntes Programmsystem wie etwa der Debugger im Betriebssystem VMS von Digital Equipment Corp. Mit beiden Werkzeugen ist es möglich, zum Ausführungszeitpunkt die Veränderung von Variablenwerten zu beobachten, Werte von Variablen zu modifizieren, den Weg durch das Programm zu verfolgen und die Ausführung anzuhalten oder freizugeben. Debugger sind für den Programmierer eine wertvolle Testhilfe.

Testwiederholungen besonders wünschenswert

Der Compiler liefert auch die Abdeckungsanalyse. So haben der Cobol- sowie der PL/ l-Compiler beispielsweise eine Option zum Zählen der Durchlaufhäufigkeit von Code-Sequenzen. Eine weitere Hilfe für den Test, die vom Betriebssystem geliefert wird, ist der Dateikomparator. Er vergleicht zwei Dateien und listet die Unterschiede auf.

Schwieriger als die genannten Bereiche sind die Testfallgenerierung, die Bereitstellung einer Umgebung zum Test eines Moduls (Drivers und Stubs) und die Testwiederholung. Letztere ist vom Gesamtaufwand des Testens her gesehen besonders wünschenswert, das Programmodul nach jeder Veränderung, die er im Laufe seiner Existenz mitmacht, erneut getestet werden muß. Für diese Aufgaben liefern die Compiler wie die Betriebssysteme kaum Hilfen.

Ein umfassendes Werkzeug, das insbesondere den zuletzt genannten Aspekten großes Augenmerk schenkt, ist Softest (SES GmbH). Es deckt folgende Funktionen ab:

- Unterstützung der Definition von Testfällen und Testdaten,

- Aufbau der Testumgebung,

- Überwachung des Testablaufes (Testmonitoring),

- Testdokumentation zum Nachweis der Gründlichkeit des Tests,

- Testwiederholung.

Für das Projektmanagement sind Hilfen einerseits aus allgemeinen Projektplanungswerkzeugen, insbesondere auf der Basis von Netzplänen, und andererseits aus Entwicklungssystemen entstanden. Grundsätzlich sind Systeme vorzuziehen, die ihren Datenbedarf wenigstens teilweise aus der ohnehin vorhandenen Entwicklungsdatenbank oder Projektbibliothek ableiten. Ein Beispiel dafür ist Papics [Softlab, 2]. Es bietet zwei wesentliche Funktionen an:

- Zustandskontrolle

Die Entwicklung jedes Bausteines durchläuft mehrere Phasen, in denen der Baustein bestimmte Entwicklungszustände annimmt. Diese werden als Merkmale der Bausteine abgelegt und von Papics kontrolliert. Es wird nicht nur die Erreichung eines bestimmten Zustandes vor Freigabe eines Bausteins, sondern auch die Reihenfolge in der Erreichung der Zustände überprüft.

- Aufwands und Terminplanung

Pro Baustein werden der geplante und der bereits erbrachte Aufwand geführt. Über den Stand des Projektes informieren Management- Berichte.

In einer Idealvorstellung für einen Methoden- und Werkzeugverbund gibt es nur eine einzige Entwicklungsdatenbank, in der sämtliche Entwicklungsdaten vom Projektmanagement über die Spezifikation und die Programme bis hin zu den Testdaten enthalten sind. Daneben gibt es nur noch die Produktionsdaten und die Lademodulen.

Die empirischen Erhebungen, über die anfangs berichtet worden ist, zeigen eine geringe Verbreitung von Methoden und Werkzeugen. Dennoch gibt es eine größere Zahl von Hilfsmitteln, über deren Nutzen und Praktikabilität kaum Zweifel bestehen. Wenn hier dennoch ein relativ bescheidenes "Bündel geschnürt" wird, so geschieht dies in Anbetracht der Machbarkeit einer geschlossenen Einführung in einem Betrieb. Die Methodik soll folgende Bereiche abdecken:

- Elementare Beschreibungsmittel,

- Dokumentation,

- Erhebung,

- Entwurf,

- Implementierung,

- Qualitätssicherung,

- Projektmanagement.

Methodenwissen ersetzt starre Vorschriften

Die Methodenbereiche sollten folgende Bestandteile einschließen:

- Komponentenliste: Die Komponentenliste ist eine bloße Sammlung von Funktionen und Daten zu einem Anwendungssystem oder einem beliebigen Ausschnitt davon.

- Funktions- und Datenhierarchie: Die Funktionen und Daten, die in der Komponentenliste noch ungeordnet gesammelt sind, werden in einer Funktions- und einer Datenhierarchie geordnet.

- Entwurfssprache: Die Funktionshierarchie kann durch die Aufnahme von Kontrollkonstrukten zu einer Entwurfssprache erweitert werden. Analoges gilt für die Beschreibung der Datenstrukturen.

- Moduldefinition: Die Moduldefinition ist eine verbale Beschreibung der Funktion eines Moduls, ergänzt um eine Auflistung von Ein- und Ausgabedaten.

- Datenbankstrukturdiagramm: Das Datenbankstrukturdiagramm gibt einen Überblick über die in der Datenbank gehaltenen Entitätstypen und ihre Beziehungen. Die konkrete Form des Datenbankstrukturdiagrammes ist dabei von sekundärer Bedeutung.

- Datenflußplan: Irgendeine Form des Datenflußplanes (SADT (Softech), N2-Chart [Lano, S. 4ff.] oder ähnliches mehr) bringt die Verbindung von Daten und Funktionen und beleuchtet den Ablauf des betrieblichen lnformationssystems in einer auch für Mitarbeiter der Fachabteilung verständlichen Form. Der Datenflußplan verbindet die Funktionshierarchie beziehungsweise die Entwurfssprache mit dem Dantebankstrukturdiagramm.

Aus den Inhalten der Entwicklungsdatenbank werden anhand der elementaren Beschreibungshilfsmittel Dokumentationen für die Benutzer, das Management, die Entwickler, das Operating und die Wartung zusammengestellt. Dafür müssen die Dokumentationsrahmen definiert werden.

Für die Erhebung der Anforderungen stehen Befragungstechniken, Methoden der Kreativitätsförderung (zum Beispiel Morphologie) und allgemeine Modelle für betriebliche Anwendungsbereiche zur Verfügung. Eine Vorschrift im Projekthandbuch, welche Methode in welchem Fall anzuwenden ist, erscheint nicht sinnvoll, da die Zahl der Einflußfaktoren zu groß ist. Wichtig ist dagegen das Wissen der Entwickler über die methodischen Möglichkeiten.

Rahmenplanung umklammert das Projekt

Für den Entwurf sind drei Teilbereiche zu unterscheiden:

- BIS-Rahmenplan: Der Rahmenplan für das betriebliche Informationssystem (BIS) legt die langfristige Entwicklung der computerunterstützten Funktionen und der maschinell verwalteten Daten im Betrieb fest. Die Rahmenplanung ist der projektübergreifende Daten- und Funktionsentwurf. Dafür stehen Methoden wie etwa "Business Systems Planning" [IBM, 2] zur Verfügung.

- Datenentwurf: Zum Datenentwurf gehören die Definition der maschinell verarbeiteten Daten, die Beseitigung von Synonymen und Homonymen sowie die Festlegung der Datenbankstruktur beispielsweise auf dem Wege der Normalisierung.

- Funktionsentwurf: Für den Funktionsentwurf empfiehlt sich die Auswahl von Darstellungshilfsmitteln, wie sie oben beschrieben sind, und die Festlegung einiger grundsätzlicher Regeln wie etwa für die Modularisierung.

QS läuft Tool-Einsatz voran

In der Implementierung geht es primär um die Definition von Standards. An erster Stelle ist hier die Strukturierte Programmierung im Sinne der Beschränkung auf bestimmte Kontrollstrukturen (Steuerungskonstrukte) zu verstehen. Dazu zählt aber auch die Bestimmung des erlaubten Sprach-Subsets aus den eingesetzten Programmiersprachen.

Voraussetzung für die Einführung von Methoden und Werkzeugen ist eine Qualitätssicherung, die unter anderem die Einhaltung der Standards überprüft. Dazu zählen folgende Bestandteile:

- Review: Als Review bezeichnet man die Prüfung von Entwicklungsergebnissen durch den Menschen. Im Falle der Inspektion ist es ein Mitarbeiter der Qualitätssicherung, im Falle des Walk Through's (Yourdon) eine Gruppe von Mitarbeitern aus verschiedenen Gebieten. Reviews sind in allen Projektphasen einsetzbar, in denen der Rechner nicht zur Prüfung eingesetzt werden kann.

- Debugging: Debugging neu entwickelter oder geänderter Programmteile sollte minimale Testkriterien erfüllen. Dazu zählt etwa, daß jedes Statement wenigstens einmal durchlaufen werden muß.

- Frühzeitiger Testfallentwurf: Die Testfälle sind so früh wie möglich zu entwerfen. Das bedeutet beispielsweise, daß beim Entwurf einer Funktion auch die Fälle beschrieben werden, die diese Funktion verarbeiten können muß. Diese Testfälle werden äußere Testfälle genannt, da sie ohne Kenntnis der Interna der Funktion festgelegt werden. Daneben sind nach der Implementierung aus den Programmen die inneren Testfälle abzuleiten, die beispielsweise das Austesten von Extremwerten von Variablen sicherstellen.

- Testabdeckungsanalyse: Die Testabdeckungsanalyse ist eine Prüfung auf die Vollständigkeit der inneren Testfälle.

Für das Projektmanagement sind zu regeln:

- Projektantrag und -entscheidung,

- Phasenschema,

- Projektorganisation für das Entwicklungsteam und die begleitenden Gremien,

- Planung, insbesondere Zeitschätzverfahren,

- Steuerung, insbesondere Kontrollmechanismen.

Werkzeugverbund unterstützt Methoden

Der Werkzeugverbund muß die oben beschriebenen Methoden und die daraus resultierenden Beschreibungsformen unterstützen. Unter Berücksichtigung der heute verfügbaren Werkzeuge könnte er wie folgt aussehen:

Leistungsfähiger Editor

Der Editor wird für die Erfassung und Modifikation aller textlich dargestellten Teile benutzt. Es sind dies im Methodenvorschlag die Komponentenliste, die Funktions- und Datenhierarchie, die Entwurfssprache und die Moduldefinition. Der Editor sollte die Arbeit in diesen Beschreibungsformen unterstützen.

Projektbibliothek

Trotz der langfristig falschen Richtung, in die textbasierte Systeme führen, muß für mittelfristige Lösungen auf Textbibliotheken zurückgegriffen werden. Versionsführung und Zugriffsschutz sind wesentliche Funktionen derartiger Systeme.

Data Dictionary

Trotz der Übergangslösung "Projektbibliothek" ist zu versuchen möglichst viele Entwicklungsdaten in formatierter Form zu speichern. Das gilt beispielsweise für die Datenverwendung in Funktionen oder das Datenbankstrukturdiagramm.

Die Nachteile der Aufteilung in eine Texbibliothek und eine formatierte Entwicklungsdatenbank im Data Dictionary ist teilweise durch zu entwickelnde Schnittstellen zwischen diesen Komponenten zu beseitigen. Dies gilt sowohl für den laufenden gegenseitigen Update der beiden Datenbestände wie auch für den Durchgriff der Werkzeuge auf beide Datenarten.

Berichtsformatierer

Der Berichtsformatierer ist ein Werkzeug zur Erzeugung der Berichte aus der Projektbibliothek und dem Data Dictionary.

Nutzung von mächtigen Implementierungssprachen

Die Möglichkeiten von VHLLs der Code-Generatoren sind für die Beschleunigung in der Implementierung sowie für eine frühzeitige Vorführbarkeit von Dialogen im Sinne des Prototyping notwendige Bestandteile des Werkzeugverbundes.

Testhilfen

Minimale Forderung auf dem Gebiet der Testhilfen ist die Nutzung der Testhilfen aus dem Betriebssystem und aus den Programmiersprachen.

Projektmanagementunterstützung

Die wichtigste Unterstützung für das Projektmanagement ist die Auswertung des Status der Entwicklung aus der Projektbibliothek und dem Data Dictionary.

Aus einer Analyse der heute verfügbaren Methoden und Werkzeuge lassen sich allgemeine Hinweise für die Entwicklung einer Methoden und Werkzeugstrategie ableiten.

Eine Ideallösung für das Problem der Software-Entwicklungsumgebung ist nicht vorhanden und in den nächsten drei bis fünf Jahren auch nicht zu erwarten. Die Strategie kann damit nicht bis zum Zeitpunkt der Verfügbarkeit einer alle Wünsche abdeckenden Lösung verschoben werden.

Die Methodik ist die Basis für die Werkzeugstrategie. Die Anforderungen an die Entwicklungsdatenbank und die Werkzeuge müssen aus den Methoden der Informationsverarbeitung abgeleitet werden.

Die Entwicklungsdatenbank ist die Integrationsbasis für alle Methoden und Werkzeuge [vgl. Heuer, S. 5ff.]. Sie ist langfristig am Entity-Relationship-Ansatz, also an einer formatierten Datenverwaltung auszurichten. Als Übergangslösung ist eine Kombination aus formatierten und nicht-formatierten Daten mit den notwendigen Schnittstellenprogrammen anzustreben. Dabei ist vom Grundsatz der "Formatierung so weit wie möglich" auszugehen.

Für den Entwicklungsdatenbestand ist eine größtmögliche Redundanzfreiheit anzustreben. Damit reduziert man eines der Hauptprobleme der Systementwicklung, die doppelspurige Datenhaltung.

Die Zusammenfassung von immer wieder verwendeten Codesequenzen zu Makrobefehlen oder Befehlen einer VHLL ist die Basis für eine wesentliche Beschleunigung in der Implementierung. Wird ein derartiges Hilfsmittel eingesetzt, so benötigt man keine eigene Prototyping-Sprache mehr, da für diesen Zweck das auch in der Implementierung benutzte Werkzeug Verwendung findet.

Tool kann an der Schnittstelle scheitern

Mit der Auswahl eines Werkzeuges müssen dessen Schnittstellen zu den bestehenden und den geplanten Werkzeugen konzipiert werden. Ein isoliert nützliches Werkzeug kann an seiner Schnittstelle zur Umgebung scheitern.

Die Benutzeroberfläche der Werkzeuge gegenüber dem Systementwickler ist entscheidend für die Akzeptanz und die Effizienz im Routinebetrieb. Mehrfacheingaben der gleichen Informationen, fehleranfällige syntaktische Regeln und schlechte Korrekturmöglichkeiten sind nur einige Beispiele für die Probleme, die mit den derzeit verfügbaren Werkzeugen vielfach beklagt werden.

Ein großer Teil der dargestellten Methoden und Werkzeuge ist nur sinnvoll anwendbar, wenn diese gemeinsam eingeführt werden. Es ist daher anzustreben, mit einem Pilotprojekt beginnend, die Entwicklungsumgebung möglichst geschlossen projektweise einzuführen.

* Dr. Hubert Österle ist Professor für Informatik und EDV-Beauftragter der Hochschule St. Gallen (Schweiz). Der Beitrag wurde den Proceedings zur CW-CSE Fachtagung "Effizienzverbesserung in der Softwareentwicklung" vom November 1984 entnommen, die zum Preis von 110, - Mark erhältlich sind bei: CW-CSE, Kaiserstr. 35, 8000 München 40.