Der Begriff "Software Engineering" wurde vor über 20 Jahren geprägt. Trotz einer Reihe von Fortschritten sind die Forderungen der Industrie nach einer ingenieurmäßigen Planung bei der Software-Entwicklung nur zu einem geringen Teil erfüllt. Der Beitrag von Johann Wagner* beschrieb im ersten Teil die Schwierigkeiten der Einführun von Computer Aided Software Engineering (CASE), im zweiten Teil widmet er sich den Perspektiven, die sich daraus für die Zukunft ergeben.
CASE ist auch ein Mittel der Arbeitsteilung. Jedes Projekt, an dem mehr als eine Person beteiligt ist, steht unter dem zur Arbeitsteilung. Größer, Projekte sind ohne Strukturierung der zu erbringenden Leistungen, sprich: der zu schreibenden Teilsysteme und Programme, nicht durchführbar.
Sachzwänge bei der Softwareproduktion
Bei allen Großprojekten im mechanischen und elektrotechnischen Bereich sind Entwürfe ein selbstverständlicher Bestandteil des Vertrages. Bei Software-Aufträgen waren es bisher die Leistungsbeschreibung und bestenfalls ein Projektstrukturplan.
Vor der Realisierung war der Aufbau und die Vollständigkeit einer Softwarelösung nicht überprüfbar. Die Lieferung bestand daher in den meisten Fällen aus einem ersten Wurf und vielen, vielen Nachbesserungen. Speziell bei öffentlichen Ausschreibungen werden deshalb neuerdings CASE-Pläne als Bestandteil des Angebots gefordert. Das geht soweit, da CASE-Entwürfe nur von Personen mit erfolgreichem Abschluß einer CASE-Schulung akzeptiert werden.
Die Softwareproduktion ist heute durch mehrere Sachzwänge gekennzeichnet. An erster Stelle steht der Mangel an EDV-Personal, an zweiter der ungeheure Druck zur schnellen Verfügbarkeit einer Lösung ("Alles, was länger braucht als sechs Monate, ist bereits veraltet, wenn es am Markt erscheint.") und außerdem der ungeheure Aufwand, der zur Instandhaltung und Anpassung bestehender Lösungen getrieben werden muß. Letzterer wird von der IBM bereits mit über 90 Prozent des DV-Etats angesetzt.
Die Aufgabe ist damit klar. Für die lange stiefmütterlich behandelte Wartung der Systeme muß mehr getan werden. Wenn diese Systeme CASE-fähig gemacht wären, würde es auch mit CASE vorangehen. Unter Mitarbeit von Siemens entstand inzwischen ein vollautomatisches Verfahren zur Restrukturierung alter Cobol-Programme und ein komfortables Browser-Interface für ein Repository-orientiertes Re-Engineering. Doch damit ist es nicht getan.Computer Aided Reverse Engineering (CARE):
Auf diesem Gebiet sind noch enorme Entwicklungsmöglichkeiten vorhanden. Die Metriken von heute sind als Qualitätsmaß bei weitem nicht ausreichend. Sie dienen bestenfalls als Maße für die Komplexität eines Programms, sprich: einer Anwendung, nicht aber für die Programmverständlichkeit.
Eine Theorie der Verständlichkeit fehlt. Sie zu haben wäre nicht nur nützlich für die Inspektion eines zu sanierenden Softwarepaketes oder zur laufenden Überprüfung der Wartungsqualität (Source-Ergonomiefaktor), sondern auch für die Entwicklung einer künftigen CASE-Sprache, in Verbindung mit einem ebenso noch unbekannten CASE-Language-Interface zum Benutzer.
Die Weiterentwicklung der Restrukturierungstechnik würde im Endeffekt nicht nur innerhalb eines Sprachparadigmas erfolgen, sondern auch den Wechsel des Paradigmas erlauben. Bei unseren Restrukturierungsarbeiten haben wir alte Cobol-Programme aus den 60er Jahren gefunden, die man heute ohne Zweifel mit der Technik der Entscheidungstabellen programmieren würde. Transformationen für diesen Fall gibt es bisher nicht.
Ein nicht völlig brachliegendes Feld ist das Controlling der Programmterminologie und der systemweiten Updates von Programmnamen. Namen sind der Schlüssel zum Verständnis der Funktionalität eines Programms.
Wie wir aus unserer großen Cobol-Sammlung aus ganz Europa wissen, wird in diesem Bereich am meisten gesündigt. Gute Namen zu finden ist zwar nicht leicht, aber in einem Programm mit einer größeren Lebenserwartung unverzichtbar. Heute stehen mächtige Parsergeneratoren zur Programmanalyse zur Verfügung.
Verbunden mit Dialogprogrammen wie Browsern können diese helfen, ganze Systeme redaktionell zu überarbeiten. Damit sind außerdem die riesigen Papierstapel, die in der Vergangenheit bei einer Programmanalyse produziert wurden, nicht mehr nötig.
CASE-Repository:
Inzwischen erreichen sogar Anwenderprogrammsysteme eine Größenordnung, bei der schon die Spezifikationen nicht mehr überschaubar sind. Viele Vorgaben werden an vielen Stellen mehrfach beschrieben, meist noch von verschiedenen Autoren, dies führt in vielen Fällen zu redundantem Code.
Natürlich ist das Problem nicht damit erledigt, die Spezifikationen, wie sie heute vorliegen, einfach in einer zentralen Registratur, dem Repository, zu hinterlegen. Das künftige Repository, auf das die CASE-Entwircklung heute setzt, sollte nicht als "Müllkippe" mißbraucht werden.
Die sinnvolle Verwendung eines Repositories hängt weitgehend davon ab, wie gut die Stücklistenstruktur der Entwicklungselemente ist. Hier können wegen der zu erwartenden Performanzprobleme noch keine klaren Aussagen über eine sinnvolle und wirtschaftliche Tiefe der strukturellen Auflösung der Entwicklungsdokumente gemacht werden.
Semantische Probleme machen mehr zu schaffen
Das Repository zur Plattform einer Tool-Integration zu machen ist technisch gesehen ein brauchbarer Vorschlag. Die Performanz und Kommunikation bereiten zwar Probleme, die sich aber grundsätzlich lösen lassen. Viel höher einzuordnen sind semantische Probleme. So erscheint der Versuch, Tools mit unterschiedlicher Semantik und von verschiedenen Herstellern zu integrieren, wie die Kunst einen guten Cocktail zu mischen. Ohne eine Abstimmung der von den Tools repräsentierten Methoden entsteht hier kein ausreichender Kundennutzen.
Nicht unterschätzt werden darf der Einfluß eines Repositories auf die Organisation eines Unternehmens. Die Einführungsstrategie ist dabei von entscheidender Bedeutung. Sie beginnt schon mit der Auswahl des Repositories selbst. Niemand sollte in den Glauben verfallen, daß ein vollständig integriertes Repository möglich oder auch nur wünschenswert wäre. Keinesfalls darf das Warten auf das Repository (das "endgültige Unternehmensmodell") die gesamte Entwicklung lahmlegen.
Entscheidend für die sinnvolle Nutzung eines Repositories erscheint uns die Weiterentwicklung der Display-Technik für große Datenmengen. Diese Arbeiten erweitern die Möglichkeiten der Orientierung des Betrachters durch die Projektion der Informationen in den dreidimensionalen Raum und zeigen sogar die Rotation von Informationsgegenständen als Mittel des Zugriffs.
Daß unser Denken den uns umgebenden Raum einbezieht, ja durch ihn beflügelt oder ein geschnürt wurde, weiß jeder, dem auf dem Nachhauseweg plötzlich klar wurde, woran es lag, warum ein Programm nicht funktioniert hat. Umgekehrt sollten wir diese Ortsbindung des Wissens bei der Gestaltung grafischer Oberflächen besser nützen.
Neben der Darstellungsform wird die Möglichkeit der Abstraktion, das heißt der Ableitung grober aus feinstrukturierter Information, ein Versinken des Anwenders in der Flut der Information vermeiden, die auf ihn einströmt. Hierzu zählen Techniken des Knowledge Engineering in Kombination mit Hypertextfunktionen. Sie bereiten den Weg für eine neue Generation von Datenbanken, den Intelligent Databases.
Informationsmodelle:
CASE ist derzeit wie schon erwähnt zu abstrakt. Die Entwicklung von Business-Modellen und Business-Regeln, die vermutlich wieder einmal vom Sauerteig der künstlichen Intelligenz getrieben wird, dürften die notwendige, anwendungstypische Spezialisierung der CASE-Methoden bringen.
Heute sind bereits 50 Prozent der in den USA eingesetzten Programmsysteme Standardlösungen. Dieser Trend könnte sich auch auf die Eigenentwicklung ausdehnen. Eine Uniformität der Wirtschaft ist kaum zu befürchten, dagegen jedoch ein noch reibungsärmerer Handel.
Bei der Software-Entwicklung wird diese Standardisierung zu einer deutlichen Reduktion der Programmvorgaben führen. Heute muß dem Programmierer vom Organisator das Umfeld, für welches eine Funktion zu schreiben ist, in weitschweifiger Form geschildert werden. Dies führt insgesamt zu riesigen Bergen von Papier, die niemand mehr überblickt. Der künftige Programmierer kann mit Hilfe der Unternehmensmodelle viel schneller begreifen, was von ihm verlangt wird.
Objektorientierter Entwurf:
Noch in den Kinderschuhen werden objektorientierte Techniken bereits als die Lösung betrachtet. Die ersten Erfahrungen mit dem Paradigma der objektorientierten, besser: simulationsfreundlichen, Programmierung geben Anlaß zur Aufmerksamkeit.
Hierbei handelt es sich um Designmethoden, welche auf den ersten Blick verständlicher erscheinen als vieles zuvor. Erlauben sie doch, aus der Sicht der Daten (Objekte und Funktionen) Systeme als Ganzes zu betrachten.
Die Produktivität beim Einsatz dieser Programmierordnung entspringt aus der Wiederverwendung von sogenannten Klassenbibliotheken. Diese erlauben die schnelle Anpassung eines bestimmten Programmtyps an die momentanen Bedürfnisse. Der Vorteil der Ordnung der Funktionen (Methoden) nach dem Schema der Daten führt zu deutlichen Codeeinsparungen. Die strikte Klassenordnung verengt aber gleichzeitig den Blickwinkel auf die Daten selbst. Daß objektorientierte Programmiermittel im CASE- oder CAD-Bereich zur Entwicklung der Werkzeuge nützlich sein können, wird kaum mehr bestritten. Sie kommen zum Einsatz, wenn die entsprechenden Datenhaltungen verfügbar sind. Die Verwendbarkeit im Bereich kommerzieller Anwendungen wird derzeit über Pilotprojekte untersucht. Auf Erfahrungen beim Einsatz der Technik im Rahmen großer Projekten läßt sich bisher noch nicht zurückgreifen.
Vielsprachigkeit:
Das Bild vom Babylonischen Turm, mit dem die nicht mehr zu übersehende Zahl der Programmiersprachen verglichen wird, trifft den Sachverhalt nur zum Teil. Es stimmt jedoch, daß es selbst bei den gebräuchlichsten Sprachen immer wieder große Schwierigkeiten bereitet, diese in einer Anwendung gleichzeitig zu verwenden.
Hier liegt ein großer Nachholbedarf für die Standardisierung der Kommunikationsmodelle auch zwischen unterschiedlichen Programmierparadigmen.
Eine derartige Anstrengung hätte zweifellos Rückwirkungen auf die Entwicklung einer künftigen CASE-Sprache, welche derartige Kommunikationsprinzipien berücksichtigen und die schrittweise Spezialisierung in Richtung dieser Paradigmen vorsehen mußte. Prozeßstruktur:
Die Erkenntnis, daß immer weniger Neuentwicklung nötig sein wird, sondern vielmehr die Anpassung des Vorhandenen durch Wiederverwendung von Teilen oder durch Generierung, muß auch zur Überarbeitung der Prozeßstruktur der Software-Entwicklung führen. Vermutlich sind künftig auch die geringsten Änderungen von einem technischen Direktor zu genehmigen, welcher sich natürlich eines Stabes erfahrener Mitarbeiter bedient. Es wird eigene Abteilung geben, die sich ausschließlich mit der Instandhaltung der Komponenten und nicht nur mit der funktionellen Systemerweiterung befassen.
Prozeß-Management:
Die Forderung der Marketiers nach kürzeren Produktionszeiten für Software hat auch etwas Gutes für die Entwicklung. Ihre Erfüllung führt dazu, daß bald jeder intelligente DV-Laie sich sein eigenes Benutzer-Interface selbst gestalten kann. Mehr Kenntnisse als bei der verbreiteten Spreadsheet Technik sind dafür nicht erforderlich. Das Prototyping kann teilweise zum künftigen Benutzer verlagert werden. Ein wesentlicher Teil des Pflichtenheftes wird der Prototyp des Kunden sein.
Der Prozeß der Software-Entwicklung wird am Ende nicht nur zu einem neuen Produkt führen, sondern auch zur Erfassung und Begutachtung neuer, wiederverwendbarer Softwarekomponenten.
CASE-Ausbildung:
Entscheidend für den Erfolg von CASE ist die Ausbildung der Entwickler. Der ersten Lektüre eines CASE-Handbuchs folgt nicht notwendig die große Erleuchtung. Wissen bildet sich erst durch Praxis. Leider kostet jede Ausbildung Zeit und Geld. Für das Erkennen eines guten Software-Entwurfs ist unser Auge nicht trainiert, weshalb manche Manager den für sie undurchsichtigen CASE-Methoden eher mit Argwohn begegnen. Sie können deswegen nur über Pilotprojekte eingeführt werden.
CASE-Kultur:
Die Verfahren des Computer Aided Software Engineering sind eine Forderung der Industrie und eine Herausforderung für die Informatik. Viele Fachleute haben bedauert, daß die Informatik in der Nähe der Mathematik angesiedelt wurde und für die Umsetzung der Erkenntnisse viel zu wenig getan hat. Am häufigsten hört man diese Einschätzung von Mathematikern, die in der Industrie arbeiten.
Eine Aufteilung der Informatik in Computerwissenschaften und Softwaretechnik ist längst überfällig. Am Scheideweg steht CASE.
*Johann Wagner arbeitet als Entwicklungsleiter Computer Aided Re-Engineering (CARE) im Bereich Anwendersoftware bei der Siemens-Nixdorf Informationssysteme AG, München.