Vom isolierten Tooleinsatz zur integrierten Methoden- und Werkzeugstrategie (Teil 1):

Ideale Produktionsumgebung nicht in Sicht

23.11.1984

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.

Da Entscheidungen in diesem Bereich derart lange wirken und die erwähnten Teilbereiche stark miteinander verflochten sind, müssen sie auch entsprechend langfristig geplant werden. Das bedeutet, daß die Informatik in einer Unternehmung neben einer langfristigen Strategie im Bereich "Hardware und Systemsoftware" auch eine langfristige Planung für den Sektor "Methodik und Werkzeuge" benötigt. Tatsächlich trifft man in vielen Betrieben auf derartige Vorhaben, selten aber auf ausgereifte Konzepte.

Die Ausgangslage für eine Methoden- und Werkzeugstrategie sei an folgendem Fall aus der Praxis charakterisiert:

- Die Unternehmung hat eine in zwanzig Jahren gewachsene EDV.

- Das vorhandene Betriebssystem genügt den heutigen Anforderungen und vor allem zukünftigen Aufgaben nicht mehr. Eine Umstellung auf ein anderes Betriebssystem ist in den nächsten drei Jahren jedoch nicht möglich.

- Ein großer Teil der Anwendungen läuft noch als Batchverarbeitung und kann erst im Laufe der nächsten acht Jahre vollständig auf Dialog umgestellt werden. Die heute laufenden Dialogprogramme müssen demnächst auf ein neues Konzept der dezentralen Verarbeitung mit einem neuen Netzwerk übertragen werden.

- Etwa ein Drittel der Programme ist zugekaufte Standardsoftware, für die wenig Know-how im eigenen Hause besteht.

- Es ist kein Datenbankverwaltungssystem im Einsatz. Viele Dateien sind ausschließlich sequentiell verarbeitbar.

- Erste Versuche, die Datendefinitionen in einem Data Dictionary abzulegen, laufen seit einem Jahr.

- Zur Programmerstellung wird der Texteditor des Betriebssystems benutzt.

- Zur Projektsteuerung existiert ein Phasenschema, das lediglich als Leitlinie benutzt wird.

Zu dieser Situation in den Bereichen Betriebssystem, Datenmanagement, Methoden und Werkzeuge kommen nun noch folgende Erschwernisse hinzu:

- Das hausinterne Know-how auf dem Gebiet der Methoden und Werkzeuge ist gering.

- Der Anwendungsstau beträgt etwa drei Jahre. Alle neben der Wartung verfügbaren personellen Hilfsmittel werden in die anstehenden Anwendungsprojekte gesteckt.

- Durch den unstrukturierten Einsatz von Mikros und Endbenutzerwerkzeugen in den Fachabteilungen entsteht ein zusätzlicher Zugzwang für die DV-Abteilung.

- Die Dezentralisierung der Entwicklung auf Teilbetriebe behindert die Durchsetzung einheitlicher Konzepte.

- Darüber hinaus bietet der Markt eine verwirrende Vielfalt an Methoden und Werkzeugen (insbesondere der Begriffe). Ein Mißerfolg mit der Einführung einer Methode ist den Mitarbeitern noch in frischer Erinnerung. Das macht deutlich, vor welchem Hintergrund die Strategie für den Methoden- und Werkzeugeinsatz entwickelt werden muß. Daß dieser Fall - zumindest unter dem Gesichtspunkt der Methoden- und Werkzeugsituation - nicht zu negativ gewählt ist, belegen die Bilder 1 und 2 [Österle, 1]. Sie zeigen den Einsatz von Methoden und Werkzeugen in der Schweiz, wobei von den befragten 336 Betrieben 90 geantwortet haben.

Daß eine entsprechende Strategie notwendig ist, sei an folgenden Problemstellungen im oben dargestellten Fall erläutert: Die Benutzer sollen Zugriff auf die maschinell gespeicherten Daten bekommen, um mit Hilfe von Endbenutzer-Werkzeugen Führungsinformationen ableiten zu können. Dies setzt eine Datenplanung und -beschreibung voraus.

Modulbibliotheken erhöhen Effizienz

Auftragsabwicklung und Fertigungsplanung sowie -steuerung sollen besser integriert werden. Dabei stellt sich heraus, daß das Wissen über die derzeit laufenden isolierten Systeme nicht mehr vollständig vorhanden und die Dokumentation entweder fehlt oder veraltet ist.

Änderung an vorhandenen Systemen sind äußerst zeitaufwendig, da die Zusammenhänge der existierenden Programme und Daten schwierig zu analysieren sind. Daraus resultieren langwierige Tests und viele Fehler bei der Einführung neuer Versionen.

Bei Neuentwicklungen könnte eine höhere Effizienz erreicht werden, wenn durch Modulbibliotheken Programmteile mehrfach verwendet beziehungsweise sogenannte Very High Level Languages (VHLL) weniger codiert werden müßten.

Während nur ein Argument aus den aufgeführten Beispielen auf die Geschwindigkeit in der Erstellung neuer Programme zielt, richten die anderen sich auf die Beherrschbarkeit der gesamten maschinellen Informationsverarbeitung in Form von Programmen und Daten. Die Bedeutung einer Methoden- und Werkzeugstrategie liegt keineswegs in einer möglichst hohen Zahl von Lines of Code pro Mannstunde in der Entwicklung neuer Programme, sondern in der Strukturierung der alten und neuen Anwendungssysteme.

Die textliche Darstellung ist beim heutigen Stand von Theorie und Praxis das am stärksten eingesetzte Medium der Softwareentwicklung. Als Texte werden Programme, verbale Beschreibungen sowie Tabellen und Formulare behandelt.

Es ist daher nicht verwunderlich, daß Texteditoren die am weitesten verbreiteten Werkzeuge sind (vgl. Abb. 2). Daß an dieser Stelle darauf überhaupt noch eingegangen wird, liegt am unterschiedlichen Leistungsumfang und -komfort gängiger Editoren. Editoren für die Softwareentwicklung haben spezielle Fähigkeiten, die sie von allgemein einsetzbaren Textsystemen unterscheiden. Beispiele dafür sind:

- Mehrere Dateien (Textmembers) können gleichzeitig offengehalten werden. Sie sind entweder in verschiedenen Fenstern auf dem Bildschirm sichtbar oder man kann zwischen den offenen Dateien über Knopfdruck wechseln, ohne den Stand in der Datei zu verändern.

- Im Editor können Kommandos an das Betriebssystem gegeben werden. - Im Editor kann ein eigenes Fenster für die Betriebssystemumgebung geöffnet werden. Dadurch wird es möglich, ein gerade editiertes Programm zu compilieren, die Fehlermeldungen in einem Fenster anzuschauen und in einem anderen Fenster die Fehler im Quellcode zu beseitigen.

- Der Editor besitzt eine Prozedursprache (zum Beispiel Tastenmakros), die etwa die Formatierung von Programmen erleichtert.

Vielfach benutzt die Softwareentwicklung zur Ablage sämtlicher Texte die häufig primitiven Bibliotheksverwaltungshilfen, die in den meisten Betriebssystemen angeboten werden. Darüber hinaus gibt es aber spezielle Erweiterungen, die bei der Strukturierung der Entwicklungsdokumentation behilflich sind. Beispiele dafür sind entsprechende Möglichkeiten in Opus (IBM, 1), IS/WB (Interactive Systems Workbench, Danet) oder in PET/Maestro mit der Erweiterung Plus, Project Library User Services [Softlab, 1].

Derartige Bibliotheksverwaltungssysteme bieten die Möglichkeit, Projektstände einzufrieren und alle Änderungen ab diesem Zeitpunkt zu protokollieren. Vielfach unterstützen sie auch die Zusammenstellung von Dokumentationen wie etwa des Benutzerhandbuches aus den Spezifikationen und den Dialogbeschreibungen. (wird fortgesetzt)

* 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 der Softwareentwicklung" vom November 1984 entnommen, die zum Preis von 110, - Mark erhältlich sind bei: CW-CSE, Kaiserstr. 35, 8000 München 40.