Software-Engineering (SE), der ingenieurmäßige Ansatz zu arbeitsteiliger, kontrollierter Software-Entwicklung, ist seit über 20 Jahren in der Diskussion. Die ersten Erfahrungen haben gezeigt, daß eine rein manuelle (nicht computerunterstützte) Anwendung der SE-Verfahren nicht praktikabel ist. Reinhold Thurner* untersucht, inwieweit man diese Verfahren mit Hilfe von CASE-Werkzeugen in die Praxis umsetzen kann.

Software als Produkt hat eine Geschichte, die kaum 40 Jahre zurückreicht. Trotzdem wurden in der kurzen Zeit gewaltige Softwaregebäude auf der Basis verschiedener Technologien erstellt. Da Software ein "unstetiges" Fehlerverhalten hat, müssen wir an sie deutlich höhere Anforderungen stellen als an viele andere technische Produkte. Das Vordringen von Software in sensitive Bereiche, die Abhängigkeit unserer Wirtschaft und Gesellschaft von Software sowie die nun auch für Software geltende Produkthaftung führen immer stärker zu der Forderung nach einer zuverlässigeren, sichereren Software-Entwicklung.

Das erste Schlagwort hieß "ingenieurmäßig"

Mit diesen Schwierigkeiten bei der Erstellung und Wartung von Software befaßte sich 1969 in Garmisch eine Konferenz über "Software-Engineering" . Die Antwort auf die anstehenden Probleme sollte die "ingenieurmäßige Herstellung" von Software sein.

Das Produkt mit seinen Qualitäts- und Funktionalitätseigenschaften bildet dabei den Ausgangspunkt: Es wird in abgegrenzte Baugruppen strukturiert, die einzeln wart- und austauschbar sind. Das Entwicklungs-Konzept (siehe Abbildung) unterscheidet zwischen:

- dem Entwicklungs-Prozeß, der in einzelne beherrschbare Arbeitsschritte zu unterteilen ist,

- den Zwischenergebnissen, die abgenommen, geprüft und dann als Grundlage weiterer Arbeitsschritte benutzt werden,

- den Methoden und Werkzeugen, die der Herstellung dienen und ursächlich miteinander verbunden sind, sowie

- den Entwicklern in ihren Rollen, da sich umfangreiche Systeme nur arbeitsteilig von einem Team entwickeln lassen.

Die 70er Jahre waren von der Diskussion um das Software-Engineering beherrscht. Die "strukturierten Methoden" und erste unterstützende Werkzeuge wurden bereitgestellt. Nach einer anfänglichen Euphorie für die neuen Methoden gab es die große Ernüchterung und eine boshafte Definition von Methoden machte die Runde: "Eine Methode ist, wenn man hinterher weiß, wie man es hätte machen sollten." Viele Entwickler erfuhren (und erfahren), daß die "eigene Methode" - wenn es darauf ankommt - schneller zum Ziel führt, als eine neue, die man erst lernen muß.

Oft war die Strukturierung des Entwicklungsprozesses unpräzise und unverbindlich, sobald es um die wirklich schwierigen Fragen ging. Außerdem konnten die Zwischenergebnisse nicht objektiv geprüft werden; eine Analyse war "fertig", wenn der Termin hinreichend überzogen war, weshalb das Problem dann in der Realisierung umso stärker zutage trat. Zudem deckten die Methoden und Werkzeuge nur isolierte Flecken der Landschaft ab und waren noch dazu mangelhaft integriert. Ein einheitliches Konzept fehlte, man erging sich in Diskussionen um die beste Methode.

Den größten Engpaß bildeten aber die Entwickler selbst. Ein ingenieurmäßiges Vorgehen ist ohne Ingenieure eben recht schwierig zu realisieren. Die Ausbildung war auch nicht darauf ausgerichtet, "Ingenieure" mit breiten Kenntnissen der Verfahrenstechnik und arbeitsteiligen Entwicklung heranzubilden. Man wollte den auf ein bestimmtes Hardware-Software-System getrimmten Spezialisten - und man bekam ihn auch. Die Beziehung zwischen Organisatoren, Analytikern, Programmierern und Systemgruppe war nicht gerade von gegenseitiger Anerkennung und Bereitschaft zur Zusammenarbeit geprägt.

Nur wenige schafften es, das Produktivitätsloch neuer Methoden zu überwinden, um dann Vorteile daraus zu ziehen. Die starke Dynamik in der Verfahrenstechnik, das Fehlen eines einheitlichen Methoden-Gebäudes und die offensichtliche Überlappung der Methoden veranlaßte die Entwickler zum Abwarten. Denn die Schuldigen für das Problem waren rasch gefunden - die Methoden.

Die frühen 80er Jahre brachten dann eine deutliche Abkehr vom Software-Engineering-Ansatz: "Methoden sind kompliziert und unnötig, mit geeigneten Werkzeugen geht das von selbst", hieß die Devise. An die Stelle des strukturierten (langen) Entwicklungsprozesses trat der Prototyping Ansatz, unterstützt durch Sprachen der vierten Generation. Die durchaus beeindruckenden Anfangserfolge wurde jedoch mit einem Wildwuchs an heterogenen Anwendungen erkauft - und mit { deutlichen Problemen, wenn die Anforderungen an die Software die Funktionalität der (einfacheren) Infrastruktur über stiegen. Die ursprünglich sogar als Werkzeug für den Endbenutzer apostrophierten 4GLs (James Martin: "Programming without Programmers"), wurden immer mehr als eigentliche "Programmiersprachen" erkannt. Die Notwendigkeit eines methodischen Vorgehens, insbesondere im Bereich des Datendesign, gewann zunehmend an Anerkennung.

Um heterogene Systeme zu einer Dienstleistungseinheit zu verbinden, entwickelten die Hersteller ihre Anwendungs-Architektur-Konzepte, die dann durch ein Gegenstück auf der Entwicklungsseite ergänzt wurden. Diese Architekturen werden vom Engineering-Gedanken getragen - die rationelle, zuverlässige Herstellung des Produktes mit den jeweils besten Verfahren steht dabei im Vordergrund. Es wird eine Verbindung hergestellt zwischen dem Vorgehensmodell, den Uper-CASE-Werkzeugen für die frühen Phasen, den Sprachen, den Anwendungs-Generatoren und dem Repository für die Speicherung der Entwicklungsdaten.

Über Anfangserfolge nicht hinausgekommen

Viele der Probleme, die SE im ersten Anlauf scheitern ließen, sind durch CASE nun behoben. Die neuen Benutzeroberflächen, die Workstation-Umgebungen und die weiter getriebene Integration der Werkzeuge erleichtern den Einstieg und die Nutzung der in den Werkzeugen verpackten Konzepte. Die Datenhaltung ist substantiell und erlaubt das Speichern von Informationen mit großem Detaillierungsgrad.

Trotz des raschen Einstiegs, der bunten Bilder und der schönen Grafik darf aber eines nicht übersehen werden: Wollen wir produktiv mit den Systemen arbeiten, so müssen wir die Methoden beherrschen. Manches CASE-Tool landet in der Ecke, weil man methodisch nicht über die Anfangserfolge der richtigen Benutzung der Maus hinausgekommen ist.

Rationalisierungseffekt nur bedingt zu erreichen

CASE bietet unbestritten die Chance, in der Softwaretechnologie ein großes Stück weiterzukommen. Die Chance sollte nicht vertan werden, indem der Fehler von früher wiederholt und nur das Werkzeug gesehen wird. Der CASE-Anwender ist deshalb gut beraten, wenn er zum Beispiel das Werkzeug in einem ersten Schritt "nur" für sorgfältiges Datendesign einsetzt, statt eine Gießkannen-Ausbildung und flache Nutzung ohne die entsprechenden Grundlagen zu forcieren.

Im Engineering-Bereich hat man diese Erfahrung vor Jahren schon gemacht: Mit Hilfe von CAD können deutlich schönere Zeichnungen erstellt werden - mit deutlich höheren Anforderungen an die Konstrukteure.

Ein echter Rationalisierungseffekt ist nur sehr bedingt zu erreichen. Wirkliche Produktivitätsvorteile verschafft jedoch die Integration von CAD und Produktion, also das ClM-Konzept.

Dokumentation veraltet während der Realisierung

Die Diskussion: CASE - ja oder nein? ist wohl ausgestanden. Sie hat sich heute deutlich auf die Frage verlagert, wie eine Integration der CASE-Werkzeuge mit der Realisierung zu erreichen ist. Es kann nicht sein, daß die Dokumentation der CASE Werkzeuge in dem Umfang veraltet, in dem die Realisierung fortschreitet.

An der Nahtstelle zwischen CASE und Realisierung knirscht es heute noch. Die Bemühungen, auf den gemeinsamen Fluchtpunkt hinzuarbeiten, sind unverkennbar. Die CASE Hersteller, die Hersteller von 4GLs und Datenbanken sowie die Hersteller von Anwendungsgeneratoren verfolgen heute eine Politik der vertikalen Integration - sei es durch Entwicklung eigener Werkzeuge (Oracle, SAG), durch Übernahmen (Sage/Excelerator oder IEW/Gamma, oder durch Zusammenarbeit Delta/Conceptor). Eine durchgängige Integration von CASE und Produktion steht ebenfalls auf dem Programm.

Keine ausreichende Basis für vertikale Integration

Die "klassischen" CASE-Tools heutigen Zuschnitts basieren weitgehend auf dem "strukturierten" Ansatz (DeMarco, Yourdon etc. ) Es wird heute aber immer mehr bezweifelt, daß dieser Ansatz eine ausreichende (methodische) Basis für eine voll ständige vertikale Integration sein kann. Wer versucht hat, eine vollständige Funktionsbeschreibung zu erstellen und von dieser auf die "Action-Diagramme" umzusteigen, kann ein Lied davon singen.

Eine Erweiterung in Richtung objektorientierter Entwicklung (nicht nur Programmierung) verspricht Abhilfe. Es scheint, daß die Weiterentwicklung des Datendesigns zum Objekt-Design sowie die Beschreibung des "Entity-Life-Cycle" (SSADM und Michael Jackson) die Lücke schließen könnten. Für den CASE-Anwender sind diese Überlegungen umso wichtiger, als er steuern kann, welchen Bereich er intensiv nutzen will (Daten-Design) und welcher Bereich doch eher fraglich ist.

Ein Schlüssel zur Integration liegt in der Datenhaltung. Die Datenhaltung der heute verfügbaren Systeme kann man nicht als offen bezeichnen. Eine Batch-Export-Schnittstelle, die mit enormen Zeitaufwand das sorgfältig abgekapselte Dictionary entleert, kann nicht die Lösung sein. Das Mainframe-Repository, auf das viele ihre Hoffnung richten, ist es wohl auch nicht. Ob die Anforderungen an eine Entwicklungs-Datenbank hinsichtlich Granularität Performance und Flexibilität von einem einzigen monolithischen Repository zu erfüllen sind, muß mindestens bezweifelt werden.

Eine Auslagerung von Entwicklungsdaten in ein Project-Repository mit späterer Re-Integration in das zentrale System scheint der bessere Weg zu sein Diese Systeme sind im Entstehen und das heißeste Diskussionsthema unter Insidern der Toolszene.

Software, haben wir festgestellt, lebt länger als die ihr zugrunde liegende Technologie. Sie wird auf der technologischen Stufe weiterentwickelt und gepflegt, auf der ihre Entwicklung stattgefunden hat. Dies bedeutet für neue Systeme und für die Einführung neuer Technologien ein schweres Handicap.

Noch mehr Schwierigkeiten birgt dies jedoch im Hinblick auf alte Systeme, die funktionell durchaus in Ordnung sind. Diese Systeme verursachen technische Schwierigkeiten, indem sie nicht auf neue Hardware portiert oder in neue Software-Umgebungen eingefügt werden können. Das notwendige technische Know-how für die Wartung ist überdies immer schwerer zu erhalten oder zu beschaffen.

Viele - besonders große - Anwender leiden unter einer technologischen Breite, die kaum mehr zu managen ist und erhebliche Ressourcen verschlingt. Zum Teil erschreckend sind die Bestände an Software in Assembler, RPG, exotischen 4GLs jeder Provenienz und alten Releases von Sprachen, die nicht mehr kompatibel sind.

Die Hoffnung, diese Systeme durch neue abläsen zu können, erweisen sich oft als trügerisch. Die vorhandenen Entwicklungskapazitäten werden für neue Systeme benötigt, nicht für die Weiterentwicklung von Systemen, mit denen der Anwender im Grund nicht unzufrieden ist - und ist er unzufrieden, so greift er allemal lieber zu einer Standardsoftware, von der er sich mehr Nutzen zu geringeren Kosten verspricht.

Ältere, aber funktionstüchtige Software auf einen neuen technologischen Stand anzuheben, ist das Thema des Re-Engineering. Ein wichtiger Püfstein für Entwicklungskonzepte und Entwicklungssysteme ist deren Fähigkeit, alte Systeme zu integrieren und auf den neuen Stand anzuheben.

Das letzte Wort in Sachen Software-Entwicklung ist noch nicht gesprochen, und es wird auch in einigen Jahren noch nicht gesprochen sein. Wir haben durchaus Fortschritte erzielt, und viele Anwender haben einen erheblichen Nachholbedarf von ihrem Stand auf den heute gesicherten State of the Art.

Die Entscheidung, angesichts der Unsicherheit abzuwarten, bis sich die Lage geklärt hat, ist durchaus zu verstehen; das Risiko, sich mit allzu langem Warten in eine Sackgasse zu manövrieren, darf aber auch nicht übersehen werden.

Eine sehr schmale Technologie-Abstützung besitzt unbestritten große Porduktivitätsvorteile, die sie jedoch mit einem Mangel an Flexibilität und Fähigkeit, neue Technologien zu absorbieren, bezahlt. Eine allzu breite Technologie-Abstützung birgt hingegen das Risiko, daß Technologie zum Selbstzweck wird und nie in die Produktivitätsphase gelangt.

In der Softwaretechnologie mit ihrer unvergleichbaren Dynamik ist die Beherrschung des technologischen Wandels schwierig, aber dennoch Voraussetzung, um langfristig erfolgreich zu sein.

*Dr. Reinhold Thurner ist Mitglied des Verwaltungsrates und Berater bei der Delta Software Technologie AG in Schwerzenback, Schweiz.