Moderne Produktionsumgebungen sind in der System-Entwicklung bald nicht mehr wegzudenken, aber:

Computergestütztes SW-Labor ist noch mit Mängel gepflastert

23.05.1986

Software-Produktionsumgebungen sind keine Spielzeuge für "verrückte Programmier-Fetischisten". Vielmehr werden sie heute bereits in den unterschiedlichsten Bereichen eingesetzt, um Entwicklung und Nutzung von Software rationell zu gestalten (Teil 2 und Schluß).

Der zur Zeit mächtigste Formalismus zur Definition paralleler Systeme, die allgemeine Netztheorie von C. A. Petri, hat bisher noch nicht zur Spezifikations-Sprache in Produktionsumgebungen geführt. Ein Ansatz zu einer neuen SPU sollte darauf aufbauen und eine Spezifikationssprache schaffen, mit der zeitunabhängig parallele Systeme (also concurrent systems) konzipiert werden können. Da die allgemeine Netztheorie eine Formulierung von Kommunikations- und Delegationsaufgaben gestattet, könnte sie auch die Entwicklung einer Sprache für die Anforderungsdefinition stimulieren.

Der System-Entwurf hat inzwischen eine Schlüsselstellung für die Software-Entwicklung gewonnen, er wird zur Zeit stark betont. Man ist sich heute einig, daß ein Software-System in Komponenten zerlegt werden muß, damit es beherrschbar ist. Man ist sich aber nicht einig, was eine Komponente sein soll.

Die meisten Produktionsumgebungen bieten Werkzeuge zur Unterstützung des Entwurfs: Manche unterstützen eine Programmiersprache, die entsprechende Beschreibungsmittel hat, andere enthalten spezielle Beschreibungsmittel für den Entwurf.

Da der Entwurf entscheidenden Einfluß auf die weiteren Entwicklungsstadien hat, muß eine SPU Mittel für diese Aufgabe enthalten.

Für die Implementierung gibt es die meisten und auch die am besten ausgearbeiteten Methoden und Werkzeuge. Sie wird in allen Produktionsumgebungen unterstützt, sei es durch die unterstützte Programmiersprache oder durch Hilfsmittel für Pseudocode.

Eine Methodik im Sinne einer Methodenwissenschaft gibt es bisher allerdings noch nicht. Man findet eine (Un-)Menge von Methoden. Aber es ist unklar, welchen Einfluß eine Methode auf das Produkt und auf seine Entwicklung hat. Der Einsatz einer bestimmten Methode führt zwar im allgemeinen zu besseren Ergebnissen; es ist aber offen, ob die Verbesserung gerade auf diese Methode zurückzuführen ist oder ob eine andere Methode nicht ein ähnliches Ergebnis bringen würde. Außerdem sind viele Methoden für einzelne Aufgaben oft nicht miteinander verträglich, so daß sie nicht kombiniert werden können.

Projekt-Management braucht viele Methoden und Tools

Entwicklungsprozeß und Managementprozeß sind parallele Prozesse. Der Entwicklungsprozeß wird vom Managementprozeß ausgelöst, gesteuert und schließlich beendet. Der Managementprozeß beginnt bereits vor dem Entwicklungsprozeß mit einer Definition des zu erstellenden Systems, Kosten- und Terminschätzungen sowie der Planung des Entwicklungsprozesses.

Es gibt eine Reihe von Methoden und Werkzeugen für die einzelnen Aufgaben des Projekt-Management: Für die Systemdefinition werden zum Beispiel Data-Dictionaries und Hilfsmittel für relationale Systembeschreibungen verwendet.

Kalkulationssysteme erlauben Schätzungen von Personalaufwand, Kosten und Terminen. Ein Beispiel für ein Kalkulationssystem ist Cocomo (Contructive Cost Model). Auf der Basis der Angaben der geschätzten Anzahl von Anweisungen pro Systemkomponente, verlangter Produktqualität und durchschnittlicher Produktivität der Entwicklungsorganisation werden anhand der Cocomo-Formel Entwicklungsaufwand, Entwicklungsdauer und Wartungsaufwand berechnet. Ein solches System ist ein erster Ansatz für das Problem der Kalkulation von Software-Projekten.

Planungssysteme unterstützen US-Air Force

Planungssysteme unterstützen die Erfassung und Manipulation von Balken- oder Netzplänen. Die meisten Systeme beruhen auf der bekannten Netzplantechnik. Ein Beispiel für ein Planungssystem ist "Parmis" (Planning and Resource Management Information System) der amerikanischen Luftwaffe.

Projektüberwachungssysteme bauen auf den Planungsinstrumenten auf. Ist-Termine, Ist-Kosten und Ist-Fortschritt werden erfaßt und mit den Soll-Angaben verglichen, entsprechende Projektfortschrittsberichte werden erstellt. Ein Beispiel für ein solches System ist "Vidoc" von IBM.

Es gibt heute noch keine Managementsysteme in den Produktionsumgebungen, die allen Anforderungen gerecht werden, es gibt aber Ansätze zu solchen Systemen. Beispiele sind die "Motor-Managementmaschine" (ADV/Orga), "Softman" in der SPU "Softorg" (SES) und "EPOS-P" in der SPU "EPOS" (Univ. Stuttgart).

SW-Management mangelt es an ausgereiften Methoden

Im Bereich Software-Management fehlen - mehr noch als in jedem anderen Bereich des Software Engineering - ausgereifte und problemgerechte Methoden. Deshalb sollte es auch nicht verwundern, daß die Management-Werkzeuge zur Zeit nur elementaren Management-Aufgaben gerecht werden. Es fehlen insbesondere zuverlässige Methoden und Werkzeuge für Planung. Kontrolle und Steuerung von Projektaufwand und Produktqualität.

Software ist nicht nur der lauffähige Objektcode eines Programm-Systems. Vielmehr gehören zur Software auch alle Dokumente von Anforderungsdefinitionen über Entwurfsbeschreibung bis zum Quelltext. Bei jedem Entwicklungsschritt entsteht eine Repräsentation des Systems, die selbst aus vielen Teilen besteht. Jedes dieser Teile kann in verschiedenen Versionen existieren.

Diese Vielzahl von Objekten kann leicht dazu führen, daß die Entwickler (oder das Wartungspersonal) im Laufe der Lebenszeit des Programm-Systems den Überblick verlieren. Es kann zum Beispiel schwierig sein, zu einem laufenden Programm den richtigen Quelltext aufzufinden.

Konfigurationssystem für eine SPU unverzichtbar

Produktverwaltungssysteme werden benötigt, die es erlauben,

- Die Unterschiede zwischen den Versionen eines Teils zu identifizieren. Solche Unterschiede können zum Beispiel Statusunterschiede sein (etwa entwickelt, getestet, freigegeben), sie können durch Änderungen im Text des Teils entstanden sein und sie können durch alternative Entwicklungen verursacht werden.

- Die Historie eines Objektes zu rekonstruieren.

- Eine Quelle zu einem laufenden Programm wiederzufinden. Dazu braucht man unter Umständen eine Beschreibung, wie das Programm entstanden ist.

- Ein System automatisch aus seinen Teilen zu generieren.

Da Produktionsumgebungen nur für die Entwicklung großer Software-Systeme verwendet werden, für die die Probleme von Versionen und Konfiguration relevant sind, gehört ein Konfigurationssystem zu den unverzichtbaren Bestandteilen einer SPU.

Ein weiterer wesentlicher Faktor für die Benutzbarkeit einer SPU ist die Dialogführung. Der Mensch wird aber dabei nicht ausreichend unterstützt. Systeme wie "Lisa", "Smalltalk" und "Sun"-Workstations zeigen neue Wege für den Mensch-Maschine-Dialog.

Geht man davon aus, daß mehr als 75 Prozent aller Arbeiten bei der interaktiven Software-Entwicklung Editierarbeiten sind, wird klar, daß der Komfort an dieser Stelle besonders wichtig ist, oder anders ausgedrückt, welche Bedeutung Editoren haben. Die Entwicklung von Editoren begann Mitte der 60er Jahre mit rein textorientierten Editoren, denen syntaxorientierte folgten. Syntaxorientierte Editoren werden in interaktiven Programmierumgebungen wie "Interlisp" angeboten. Es gibt sie für viele, meist neuere Sprachen wie Pascal, Modula und CDL2, bisher aber nicht für Cobol.

Die weitere Entwicklung führte zu sprachunabhängigen Editor-Generatoren, die man über eine Grammatik parametrisieren kann. Solche Editor-Generatoren findet man zum Beispiel in "Mentor" und im "Cornell Program Synthesizer".

Editor-Generatoren reduzieren den Aufwand für die Entwicklung von Editoren ganz erheblich. Dies ist besonders für eine SPU relevant, da in allen Phasen der Software-Entwicklung unterschiedlich strukturierte Dokumente bearbeitet werden müssen, was zu einer Vielzahl von Editoren in einer SPU führen kann.

Große Mengen von Informationen über das Produkt und über den Produktionsprozeß fallen während der gesamten Lebensdauer eines Programms an, müssen verarbeitet werden und verfügbar sein. Es ist nicht möglich, diese Informationsflut manuell zu bewältigen, jedenfalls nicht mit zuverlässigen Ergebnissen.

Entwickler und Manager ersticken in einer Unmenge von Dokumenten, die sie nicht mehr erfassen und verwalten können. Wichtige Unterlagen sind inkonsistent oder unauffindbar.... Die Wartung fertiggestellter Produkte ist mühsam und langwierig und nur mit hohem Zeitaufwand auf neue Bearbeiter übertragbar." Dieses Zitat stammt aus einer Schrift der Softlab GmbH.

Eine Datenbank und ein computergestütztes Informationssystem können helfen, diese Probleme zu bewältigen. Ein Computer ermöglicht nicht nur die automatische Analyse von Beschreibungen, sondern auch Interaktionen zwischen Mensch und Maschine in Form von Fragen und Antworten. Es ist dann auch möglich, korrekte Dokumentationen (zum Beispiel Benutzerhandbücher) halbautomatisch zu erstellen.

Informationssystem spielt Im Projekt tragende Rolle

Es gibt wohlbekannte Probleme, wenn man Programmtexte ändert, ohne gleichzeitig die entsprechenden Dokumente zu ändern. Bei großen Software-Systemen kann die Konsistenz zwischen Programmtexten und entsprechenden Unterlagen nur durch computergestützte Hilfsmittel garantiert werden.

So verwundert es nicht, daß Informationssysteme, von einfachen Datenbanksystemen mit elementaren Data-Dictionaries angefangen bis hin zu komplexen Auskunftssystemen (zum Beispiel Decision Support Systems) heute eine wichtige Rolle in Produktionsumgebungen spielen. Sie sind die zentrale Informationsquelle des Projektes, und technisch gesehen sind sie das Mittel zur Kommunikation zwischen den Werkzeugen einer SPU.