CASE-Anwender werden ist nicht schwer

Ein schlechtes Design wird durch ein Tool nicht besser

01.05.1992

Alle reden über CASE-Tools, aber keiner nutzt sie. Vielleicht liegt das an den übertriebenen Erwartungen, die durch die Versprechungen der Anbieter geweckt, aber oft nicht erfüllt werden. Manfred Weidl* plädiert für eine realistische Einschätzung und rät den Anwendern, sich genau zu überlegen, welches Tool sie mit welcher Absicht erwerben wollen.

CASE bedeutet die Automatisierung des Software-Entwicklungszyklus. Will man also mit CASE-Tools arbeiten, so müssen die Phasen dieses Zyklus mit ihren jeweiligen Methoden und Ergebnissen bekannt sein. CASE-Tools verbinden diese einzelnen Entwicklungsphasen miteinander. Die Ergebnisse der einzelnen Phasen lassen sich bei den meisten CASE-Tools der leichteren Verständlichkeit halber grafisch aufbereiten.

Freilich muß die Durchgängigkeit der Informationen durch einen erhöhten Aufwand für die Erfassung in frühen Phasen der Software-Entwicklung erkauft werden. Auch das beste CASE-Tool kann keine Informationen in der Benutzerdokumentation wiedergeben, die vorher nicht erfaßt wurden. Anwender müssen auch bereit sein, diesen Mehraufwand in die Projekte mit aufzunehmen, um letztlich von der Vielzahl der erfaßten Daten zu profitieren. Häufig wird der enorme Aufwand für die Schulung bei der Einführung solcher Entwicklungswerkzeuge unterschätzt oder ganz vergessen.

Nicht an Hardware oder Ausbildung sparen

Viele Firmen arbeiten heute nur mit unzureichend automatisierten Methoden der Software-Entwicklung. Wird ein CASE-Tool eingeführt, müssen dann alle Software-Entwickler die komplette Methodik der Software-Entwicklung beherrschen und darin geschult werden. Das hat allerdings den angenehmen Nebeneffekt, daß sich gleichzeitig mit der Implementierung eines CASE-Tools eine allgemeine automatisierte Software-Entwicklungsmethodik durchsetzen läßt.

Ein CASE-Tool stellt enorme Anforderungen an die Hardware. Haupt- und Festplattenspeicher sollten reichlich Kapazität haben, damit die großen Datenmengen komplexer Softwareprojekte verwalten werden können. Empfehlenswert ist dabei ein großer Bildschirm, da sonst der Überblick verlorengeht. Spart man an der Hardware oder an der Ausbildung der Mitarbeiter, so nimmt man zumindest längere Projektlaufzeiten in Kauf; schlimmstenfalls scheitert das Projekt.

Die Entwicklung verzögert sich konkret durch längere Generierungszeiten und durch zu kleine Hauptspeicher beziehungsweise durch die Anlernphase. In der Folge erhöhen sich die Gehaltskosten für die Software-Entwickler, und das ganze Projekt ist nicht mehr rentabel. Leider wird dies nur allzu häufig vergessen, weshalb so manches Unternehmen draufzahlt, statt Geld und Zeit einzusparen.

Wenn die grundlegenden Voraussetzungen für das Arbeiten mit CASE gegeben sind, sollte man sich über die Anforderungen, die man an das Tool stellt, klar werden. Denn kaum ein Unternehmen kann es sich leisten, bisherige DV-technische Investitionen durch Einführung solcher Werkzeuge zu verlieren. Dies bezieht sich sowohl auf die installierte Hardware als auch auf die eingesetzte Software-Entwicklungsmethodik. So müssen ein unternehmensweites Datenmodell (Data-Dictionary) und bestehende Schnittstellen zu anderen Anwendungen in ein CASE-Tool integrierbar sein. Hier sollte sich das mitgelieferte Data-Dictionary vollständig durch das bereits vorhandene austauschen lassen.

Es gibt wohl in jedem Unternehmen eine eigene akzeptierte und erfolgreiche Methode, mit der Software entwickelt wird. Deshalb paßt ein CASE-Tool von der Stange nicht in jedes Unternehmen. Warum aber unterscheiden sich die Methoden so stark? Die Methodik des Unternehmens ist über Jahre hinweg gewachsen und muß auch die sogenannten Altlasten einbeziehen. Die CASE-Tool-Anbieter hingegen machen sich die Lehrbücher der Universitätsprofessoren zunutze, die mit der Realität nur sehr wenig zu tun haben.

Hier wäre es sinnvoll, wenn die Anbieter selbst das täten, was sie propagieren: nämlich eine Entwicklung mit System. Hierzu gehört nun einmal auch, daß Endanwender, in diesem Fall die Software-Entwickler selbst, in den Entwicklungsprozeß eingefunden werden. Es muß vor allem darauf geachtet werden, daß der Einsatz von CASE-Tools von den Software-Entwicklern akzeptiert wird. Denn erworbene, aber nicht eingesetzte Software, ist nur ein unnötiger Kostenfaktor.

Eine wichtige Rolle für die Akzeptanz bei den Software-Entwicklern spielt die Reduzierung von unangenehmen Arbeiten auf ein Minimum. Wenn die Dokumentation der Anwendung größtenteils automatisch erstellt wird, stößt der Einsatz von CASE-Tools sicherlich nicht auf Ablehnung. Vor allem die ungeliebte Wartung muß automatisiert werden. Das dient sowohl dem Unternehmen wie auch dem Software-Entwickler, der eine neue Aufgabe sicher der Wartung einer 20 Jahre alten Software vorzieht. Gleichzeitig spart das Unternehmen "Manpower" und damit finanzielle Mittel.

Leider sind CASE-Tool-Anbieter von ihren Produkten so überzeugt, daß sie nur vorgefertigte Werkzeuge auf den Markt bringen, die sich nicht an firmeneigene Software-Entwicklungsmethoden anpassen lassen. Daher können CASE-Tools von Unternehmen heute noch nicht bedingungslos eingesetzt werden.

Leider nur eine Wunschvorstellung

Während sich nun einige Häuser dem immer größer werdenden Markt der CASE-Tools ganz verschließen, öffnen sich ihm andere zu schnell. Der gesunde Mittelweg ist hier sicherlich die Lösung. Wie aber findet man ihn?

Denkbar einfach: Wenn es die eierlegende Wollmilchsau, also ein auf die Bedürfnisse des Unternehmens exakt zugeschnittenes CASE-Tool nicht gibt, benutzt man einfach Werkzeuge, die Teilbereiche der CASE-Kette abdecken. Man denke hierbei nur an den Einsatz von Prototyping-Tools oder von Codegeneratoren.

Wenn die einzelen Anbieter hier die Schnittstellen offenlegen würden, könnte man sich wie in einem großen Baukasten die einzelnen Steine zusammensuchen und sich ein eigenes Unternehmens-CASE-System zusammenstellen. Damit würde dann auch eine Entwicklungsmethodik unterstützt, die sich im Laufe der Jahre in dem Unternehmen gebildet hat und von den Mitarbeitern bereits akzeptiert worden ist.

Der Programmieraufwand für die Verbindung der einzelnen Phasen und Module dürfte im Vergleich zum Erfolg gering sein.

Leider ist das eine Wunschvorstellung, die sich wegen der Unternehmenspolitik der Anbieter wohl kaum einstellen wird. Wer läßt sich schon von der Konkurrenz in die Karten schauen und Teile des Marktsegmentes streitig machen?

Manchmal kann der Anwender allerdings Listings oder Reports von einem CASE-Tool als Schnittstellen zu anderen verwenden - insbesondere dann, wenn die Daten von einem Schnittstellen-Programm so aufbereitet werden, daß sie durch die Simulation der Tastatureingabe übernommen werden können. Mit diesen Möglichkeiten lassen sich die Entwicklungszeiten und gleichzeitig die Qualität erhöhen. Verwendet man solche Tools zur Unterstützung und nicht als Ersatz der bestehenden Entwicklungsschritte, so kann der Erfolg schon fast als gesichert angesehen werden.

Der Prototyp ersetzt nicht das Pflichtenheft

Kann der Endanwender mit Hilfe des Prototyping die fachlichen Erfordernisse des künftigen Anwendungssystems überprüfen, so lassen sich Fehler im Design wesentlich früher entdecken und die Folgekosten niedrig halten. Der Prototyp ersetzt allerdings nicht die schriftliche Fixierung der Anforderungen; vielmehr kann er in der Fachkonzeption nur unterstützend wirken.

Genauso wenig können Codegeneratoren eine endgültige Anwendung erzeugen. Mit solchen Werkzeugen läßt sich sehr schnell das Grundgerüst eines Anwendungssystems generieren. Für die Erstellung eines vollständigen Anwendungssystems sind sie jedoch nicht geeignet. Aber allein die Erstellung des Grundgerüstes kann bei einem mehrere Mannjahre umfassenden Anwendungssystem etliche Mannmonate an Entwicklungszeit kosten.

Produktivität wird nicht ad hoc gesteigert

Erfahrungen im Umgang mit CASE-Tools sammelt der Anwender am besten in Pilotprojekten. Dabei sollte er jedoch bereits sein, diesen Projekten genügend Zeit einzuräumen, damit sich die Mitarbeiter ausgiebig mit der Materie auseinandersetzen können. CASE-Tools steigern die Produktivität nämlich nicht sofort. Vielmehr setzt zu Beginn der Projekte im allgemeinen erst einmal ein Lernprozeß ein, der die Kosten und die Laufzeit um ein Vielfaches erhöhen kann.

Aus diesen Erfahrungen lassen sich Rückschlüsse über die Grenzen und Möglichkeiten des CASE-Einsatzes ziehen. Bei aller Euphorie sollte man nie vergessen, daß ein Unternehmen auch mit CASE nicht in der Lage sein wird, Softwaresysteme ohne Zeit, Geld und geballte Ingenieurleistung zu erstellen.

Ein Anwendungssystem, dessen Entwurf bereits schlecht ist, wird auch durch CASE-Tool-Unterstützung nicht besser werden. Man kann lediglich hoffen, daß durch den aufgezwungenen Formalismus die fachlichen Fehler früher erkannt werden. Fazit: Es ist zwar einfach, ein CASE-Tool zu kaufen, aber schwierig, mit ihm Software zu entwickeln. Wie heißt doch die Binsenweisheit? Wer ohne CASE keine Software entwickeln kann, kann es auch mit CASE nicht.