CASE-Erfahrungen haben die"Hysterie" gebremst

26.07.1991

Die Einführung von CASE-Konzepten ist für die meisten Unternehmen nach wie vor mit einem Risiko verbunden. Fatalerweise starten Anwender immer wieder den Versuch, CASE-unterstützte Software-Entwicklung zu realisieren, ohne vorher Erfahrungen mit dem Software-Engineering selbst gesammelt zu haben. Weitere Gründe für das frühzeitige Scheitern von CASE-Projekten sind nach Einschätzung von Albert Karer* die fehlende Abstimmung des einzuführenden Werkzeugs auf die unternehmensspezifischen Bedürfnisse und der blinde Einkauf von Werkzeugen nach "herstellerpolitischen" Gesichtspunkten.

Welches Betriebssystem für CASE?

*AIbert Karer ist Beratungsleiter bei der Integrata AG in Wettingen/Schweiz.

Die McGraw-Hill-Tochtergesellschaft Datapro Information Services Group hat im März dieses Jahres 102 Anwender nach ihrer bevorzugten Betriebssystemumgebung für den Einsatz von CASE-Tools gefragt. Dabei waren Mehrfachnennungen erlaubt. Mehr als 60 Prozent der Anwender, so eines der Ergebnisse, setzen in diesem und auch im nächsten Jahr auf PC-DOS-Plattformen.

In den Jahren 1988 und 1989 fand in Europa zunehmend die neue Software-Entwicklungsphilosophie CASE Beachtung. Zahlreiche Produkthersteller verwendeten in der Folge das Computer Aided Software Engineering (CASE) als verkaufsfördernden Deckmantel für ihre Produkte. Eine Welle von Produktankündigungen, Fachvorträgen, Artikeln, Kongressen etc. folgten. So setzte eine regelrechte "CASE-Hysterie" ein, die manchem Produkthersteller und entsprechenden Satelliten beachtliche Umsätze bescherte.

Der Aufstieg von CASE zum Thema Nummer eins unter DV-Managern, Software-Entwicklern, Herstellern und Verkäufern hat verschiedene Gründe:

- Viele Unternehmen bewegen sich im Bereich der Software-Entwicklung an ihren Kapazitätsgrenzen. Von CASE versprechen sie sich eine höhere Produktivitätsrate, also eine Waffe gegen das "Application-Backlog"-Gespenst.

- Die Wartung von bestehenden Softwaresystemen, die oftmals zehn Jahre und älter sind, bindet immer mehr Ressourcen. Die Qualität der Software läßt stark zu wünschen übrig. Vielerorts ist die Gefahr erschreckend groß, daß wichtige Programme schwerwiegende und kostspielige Fehler beinhalten oder verursachen können. Von Software, die mit CASE entwickelt wurde wird bessere Qualität und damit mehr Sicherheit und eine einfachere Wartung erwartet.

- Die scheinbare Einfachheit der Bedienung (grafische Benutzeroberfläche der Front-end-Tools) läßt auf einen ebenso einfachen Einsatz dieser Werkzeuge schließen.

- Auch "modische" Aspekte spielen eine Rolle: Der Druck bei Verkäufern und Anwendern, über eine moderne Software-Entwicklungsumgebung zu verfügen, ist nicht zu unterschätzen .

Willkommener Nebeneffekt der CASE-Hysterie war und ist daß das Thema Software-Engineering und Methoden allgemein wieder in den Vordergrund rückte. Die Diskussion, wie zukünftig Software entwickelt werden soll, ist in vielen Firmen in vollem Gange und wird dort mit Sicherheit zu strukturellen Veränderungen führen.

Typisch ist allerdings, daß viele Unternehmen bei dieser Diskussion nur nach vorne blicken und ihre laufenden Anwendungen, von denen sie schließlich leben, vergessen. Dabei wird es in den 90er Jahren von strategischer Bedeutung sein, die altgedienten Softwaresysteme am Leben zu erhalten, sie an neue Anforderungen anzupassen oder durch neue Systeme zu ersetzen.

Das bisherige CASE-Mauerblümchen Re-Engineering wird für viele der Weg sein, mit ihren altgedienten Systemen weiterleben zu können. Auf diesem Gebiet, das heute nicht ausgereift ist, tut sich in Zukunft noch einiges. Mit dem Bachman-Tool wurde im Bereich des Re-Engineering von Datenbanken ein erster Schritt in die richtige Richtung getan.

Heute ist CASE in vielen Unternehmen bereits gescheitert. Die Gründe hierfür sind zahlreich, aber mit Sicherheit sind nicht die CASE-Philosophie an sich oder die (echten) CASE-Tools verantwortlich zu machen. Die folgende Auflistung enthält einige Punkte, die in unterschiedlicher Ausprägung und Kombination für gescheiterte CASE-Einführungen verantwortlich sein können.

1. Fehlende Basis: CASE heißt Computer-unterstütztes Software-Engineering. Das bedeutet aber, daß die Einführung voll CASE nur dann sinnvoll ist, wenn im Unternehmen bereits Software nach den Regeln des Software-Engineerings (SE) entwickelt wird. Der Versuch, SE via CASE einzuführen, ist vermutlich die teuerste und nicht unbedingt die sinnvollste Methode. Also: ohne SE kein CASE!

2. Fehlende Abstimmung auf eigene Bedürfnisse: In Unternehmen, in denen Software-Engineering bereits erfolgreich eingeführt ist, liegt oftmals das Problem in der fehlenden Abstimmung des einzuführenden CASE-Tools auf die firmenspezifischen Bedürfnisse. Ein Produkt, das andere als die bereits eingeführten Methoden und Techniken unterstützt, wird von den Mitarbeitern kaum akzeptiert.

Über den Softwarekauf entscheiden die Verantwortlichen leider vielerorts immer noch primär nach politischen (welche Farbe hat der Hersteller) als nach fachlichen Gesichtspunkten. Für CASE-Produkte gilt das gleiche wie andere Standardsoftware. Nur eine saubere Evaluation unter Berücksichtigung der eigenen Bedürfnisse kann zum gewünschten Ziel führen.

3. Technisch unausgereift: Wir stehen heute erst am Anfang von CASE. Es gibt noch kein Produkt beziehungsweise keine Produktpalette die eine über- alle Phasen durchgängige Software-Entwicklung ermöglicht - auch wenn Hersteller dies mit sogenannten "I-CASE"-Konzepten (Integrated CASE) weismachen, wollen.

Die heutigen Lösungen gleichen Inseln, die der Anwender mit eigenen Brücken untereinander beziehungsweise mit der bestehenden Entwicklungsumgebung verbinden muß. Gerade diese Brücken sind in der Realität nicht einfach zu realisieren und führen schnell zur Frustration der Software-Entwickler und zur Isolation des CASE-Tools.

Viele Werkzeuge sind auch heute noch auf Stand-alone-Arbeitsplätzen und lassen sich aus diesem Grunde oft nur eingeschränkt einsetzen. Der Einsatz von CASE ist noch zu stark von organisatorischen Lösungen abhängig, deren Qualität schließlich wieder Einfluß auf den Einsatz und die Akzeptanz des CASE-Tools nimmt.

4. Unterschätzter Investitionsbedarf: CASE ist teuer. Nicht nur die Tools, sondern die gesamten Folgekosten belasten schnell das meistens geringe Budget. Die Ausbildung beschränkt sich nicht nur auf die Bedienung des Werkzeugs, vielmehr müssen eine Reihe von Methoden geschult werden. Da man bekanntermaßen am besten durch Fehler lernt, sinkt zuerst einmal die Produktivitätsrate und die Qualität der Ergebnisse. Wer dies nicht einkalkuliert, dem fehlt nach dem Kauf des Tools oft das nötige Kleingeld, um die unvermeidbare Durststrecke zu überwinden.

5. Fehlende Einführungsstrategie: Eng hängt mit der Kosten- und Investitionsplanung auch die Einführungsstrategie zusammen. Oft genug reduziert sich diese auf ein Pilotprojekt. Wenn dessen Aufgabenstellung nicht sorgfältig ausgewählt wurde, kann das bereits das "Aus" für das gewählte Produkt bedeuten. Dies geschieht, obwohl das Projekt nur deshalb scheiterte, weil die Entwickler mit dem Tool nicht umgehen konnten - nicht weil es prinzipiell ungeeignet war.

Oft wird versucht, CASE in das bestehende firmenspezifische Vorgehensmodell (einschließlich Methoden) zu integrieren. Anpassung oder Änderung eines bestehenden Vorgehensmodells bedeutet in der Regel, an den Grundfesten der bestehenden Software-Entwicklung zu rütteln, und dies kann alle möglichen unangenehmen Folgen haben.

6. Fehlendes Methoden-Know-how: Beschäftigt man sich mit einem CASE-Tool, so stellt sich sehr schnell heraus, daß es zwar leicht zu bedienen, aber gar nicht so einfach richtig einzusetzen ist. Leider ersparen auch CASE-Tools nicht das Denken. Ganz im Gegenteil: Damit ein CASE-Tool überhaupt eingesetzt werden kann, müssen die unterstützten Methoden verwendet und beherrscht werden. Die heute bekannten Methoden sind zum Teil schon 20 und mehr Jahre alt. Da sie aber bisher technisch nicht unterstützt wurden, setzen sie sich nur langsam durch.

Da die meisten CASE-Tools ihren Ursprung in den USA haben, werden vor allem die dort gängigen Methoden und Techniken unterstützt. Dies führt dazu, daß Methoden, die vor wenigen Jahren in Europa nur einige Gurus kannten, bei uns nur langsam salonfähig werden. Der Umgang damit muß aber noch erlernt werden, praxisbezogene Erfahrungswerte (speziell für Großprojekte) sind kaum vorhanden.

Der Wechsel von Methoden führt zum Wechsel des Arbeitsverhaltens. Durch das fehlende Know-how wächst die Unsicherheit des Mitarbeiters, und die Arbeitsleistung sinkt. Diese Faktoren können bei den Beteiligten ein Abwehrverhalten erzeugen, das dazu führt, vorhandene Tools einfach nicht mehr einzusetzen. Die Mitarbeiter liefern in der Regel auch gleich den Beweis, indem sie zeigen, daß eine Aufgabe mit der alten Technik in einer Woche, mit der neuen in zwei Wochen gelöst wird.

7. Überforderung der Mitarbeiter: Modernes Software-Engineering basiert auf der frühzeitigen Modellierung des zu entwickelnden Systems. Diese Vorgehensweise bietet enorme Vorteile, denn Modelle lassen früh Schwachstellen erkennen und erlauben, mit geringen Kosten verschiedene Varianten durchzuspielen sowie frühzeitig Fehler zu erkennen und zu beseitigen.

Allerdings stellt die Modellierung von Software-Systemen große Anforderungen an die Entwickler: Die zu erstellenden Modelle sind abstrakt, und abstrakte Modelle sind wiederum typisch für den naturwissenschaftlichen Bereich. Die Regeln für die Modellierung basieren auf mathematischen Grundlagen. Viele Menschen tun sich mit diesem abstrakten mathematischen Denken schwer und sind oftmals einfach überfordert.

Auf die Überforderung reagieren Mitarbeiter - meist unbewußt - mit einer Abwehrhaltung, die als Vermeidung bezeichnet werden kann. Die Folge davon können endlose Diskussionen über Sinn und Zweck, über Vor- und Nachteile sein. Frustration, Demotivation und Ablehnung von Methoden a und CASE-Tools sind das Ergebnis. Zum Glück besteht eine der wichtigsten menschlichen Fähigkeiten darin, daß man die meisten Fehler nur einmal macht. Hoffen wir also, daß die meisten Fehler bald gemacht sind.

CASE ist durchaus wieder, beziehungsweise immer noch ein Thema, allerdings eines, mit dem heute allgemein vorsichtiger umgegangen wird. In den meisten Fällen wurde erkannt, daß die gemachten Fehler nicht auf die CASE-Werkzeuge, sondern auf den Menschen zurückzuführen sind.

Die Hysterie ist der Ruhe gewichen, und in vielen Unternehmen ist der Denkprozeß in vollem Gange. Diese Denkprozesse, in denen die Konzepte für eine neue Software-Entwicklung unter CASE entstehen, werden mittelfristig den Tools zum Durchbruch verhelfen. Sicherlich sind die hochgesteckten Ziele nicht morgen zu erreichen, aber eine solide Basis läßt sich relativ schnell aufbauen.

Diese Basis besteht vor allem aus der Einführung und Durchsetzung des Software-Engineering. Das Verständnis und die Akzeptanz von Methoden und Vorgehensweisen sind, wenn erst einmal vorhanden, relativ einfach auf die maschinellen

Werkzeuge zu übertragen. Die Weiterentwicklung der CASE-Tools wird viele der heute vorhandenen technischen Probleme lösen und damit das Arbeiten mit CASE vereinfachen. Parallel dazu dürfte sich auch das erforderliche Methoden-Know-how durchsetzen.