Jeder spricht von CASE, aber nur wenige wissen, was darunter zu verstehen ist - so etwa läßt sich die seit Jahren anhaltende Diskussion um dieses Thema beschreiben. Das Markforschungs- und Beratungsunternehmen IDC hat die CASE-Szene unter die Lupe genommen. Die Ergebnisse stehen in der Studie " CASE - Status, Produkte und Trends" zur Verfügung.

Daniela Maag ist Projektleiterin bei der IDC Deutschland GmbH

"Softwareentwicklung ist in erster Linie Intuition" - diesem oder ähnlichen Grundsätzen scheint die herkömmliche Softwareproduktion nach wie vor zu frönen. Der Entwickler wird in diesem Zusammenhang als Künstler gesehen, dessen Techniken bestenfalls für Eingeweihte nachvollziehbar sind. Ursprüngliches Ziel dieser Art von Softwareentwicklung war die Bereitstellung von Lösungen, die aufgrund teurer und "langsamer" Hardware einen möglichst kompakten Code bereitstellen sollte, der zudem noch möglichst sparsam mit Hardware-Ressourcen umgeht. Weiterhin sollten die Programme noch ein Optimum an Geschwindigkeit aus der "langsamen" Hardware herauskitzeln.

Da es der so entstandenen Software zumeist an Struktur und somit an Übersichtlichkeit mangelte, ließ man bei notwendigen Verbesserungen oder Erweiterungen den ursprünglichen Code meist unangetastet und fügte stattdessen wie bei einem Flickenteppich die neuen Teile an passender Stelle hinzu. Durch diese Vorgehensweise entstanden dann immer unübersichtlichere, wartungsunfreundlichere und langsamere Software-Gebilde, deren Geschwindigkeitsmanko nur durch die immer schneller werdende Hardware ausgeglichen werden konnte.

Und noch ein weiterer Punkt führte direkt hinein in die Softwarekrise. Untersuchungen zeigen nämlich, daß der größte Teil der Entwickler oder Entwicklungsunternehmen, selbst nach jahrelanger Erfahrung, dazu neigen, den Aufwand für ein Projekt zu unterschätzen. Auf der anderen Seite stehen die Auftraggeber, die aus ihrer Interessenslage heraus die Tendenz haben, den oft etwas zu vollmundigen Versprechen der Entwickler Glauben zu schenken. Eine lauffähige Software soll her - möglichst schnell und möglichst günstig. Vor diesem Hintergrund erscheinen Untersuchungen verständlich, die belegen, daß nur rund ein Zehntel aller Softwareentwicklungsprojekte am Ende auch einsatzfähig sind. Aus dem Verteidigungsministerium der Vereinigten Staaten von Amerika wird berichtet, daß nur ein Prozent der in Auftrag gegebenen Software nach Lieferung unverändert benutzt werden konnte, hingegen 47 Prozent bezahlt, aber nicht geliefert wurden.

Doch auch die einsatzfähige Software verursachte Probleme, die man nicht oder nur ungenügend bedacht hatte. Was zum Beispiel sollte geschehen, wenn ein Entwickler ausfiel oder das Unternehmen verließ. Aufgrund schlecht oder gar nicht strukturierter Programme, war es nur unter enormem Zeitaufwand - wenn Oberhaupt möglich, Korrekturen oder Verbesserungen in das Programm einzubinden.

Wartbarkeit der Software war aufgrund des oft ungenügenden Weitblicks immer ein Stiefkind der Softwareentwicklung.

Die Diskussionen über die Ursachen der Softwarekrise wurden auf breiter Ebene geführt. Involviert waren das Softwareentwicklungspersonal, das Management der betroffenen Unternehmen, die Endanwender der Produkte und die Hersteller von Software. Trotz der Vielzahl präsentierter Ergebnisse konnte der Prozentsatz an einsatzfähiger Software aber nicht erhöht werden.

Vielversprechende Ansätze zur Lösung der Krise gingen von Methodenspezialisten wie Yourdan, Tom DeMarco, Michael Jackson u.a. aus. Sie entwickelten Konzepte zur systematischen Analyse der Softwareentwicklung. In deren Mittelpunkt stand die Intention, mit Hilfe eines strukturierten Konzepts die Systementwicklung Übersichtlicher zu gestalten, nach Möglichkeit so zu programmieren, daß Teile des Programms (Module) auch anderweitig verwertbar sind und die Wartung der Programme erleichtert wird.

Die Konzepte sollten den Entwickler dazu zwingen, Fehler möglichst frühzeitig zu erkennen, denn die Mehrzahl der Fehler entsteht bereits im Planungsstadium und nicht erst während der folgenden Produktentwicklungsphasen. Von dort aus werden sie dann oft bis zur Installation verschleppt, ehe sie erkannt und korrigiert werden.

Die Korrektur von Fehlern wird aber mit zunehmendem Projektfortschritt immer schwieriger und kostspieliger. In diesem Zusammenhang machen die berühmten Bell Labs folgende Rechnung auf. Die Korrektur eines Fehlers in der Planungsphase verursacht praktisch keine Kosten. Die Bereinigung des Fehlers nach der Kodierung ist mit rund 100 Dollar anzusetzen. Zur Korrektur eines Fehlers nach der Freigabe des fertigen Produktes müssen etwa 10 000 Dollar aufgewendet werden.

SW-Entwicklung hat eine subjektive Komponente

Die Methoden wurden denn auch von einigen Softwareentwicklern eingesetzt. Doch allein dadurch waren die Probleme noch nicht gelöst. Die Entwickler mußten sich die Frage stellen, welche Methode denn die für sie richtige sei. Doch die Beantwortung dieser Frage gestaltete sich schwierig.

Denn in diesem Zusammenhang zeigt sich, daß Softwareentwicklung auch eine philosophische und damit subjektive Komponente hat. Der Softwareentwicklungsprozeß ist eine Bestimmung und Übertragung von Ausschnitten und Prozessen aus unserer Welt in die der EDV. Je besser eine Software ist, um so genauer und zweckmäßiger bildet sie diese Ausschnitte ab. Für die Methodenpäpste galt es also, Verfahren zu finden, die es erlaubten, diese Weltausschnitte optimal zu bestimmen und sie dann auch noch optimal in die EDV zu transferieren. Die Entwickler wiederum mußten aus den gefundenen Methoden die für sie geeignete auswählen.

Da die Methoden letztlich auch vom Weltverständnis ihres Entwicklers abhängen, gab es folglich nicht nur eine Methode, sondern viele. Und die Väter der jeweiligen Methode verteidigten natürlich immer nur die ihrige, gingen sogar soweit, sie in den Rang der Unfehlbarkeit zu erheben. Hinzu kommt, daß diese Methoden von Theoretikern entwickelt wurden und vom Praktiker nur bedingt oder in individuell veränderter Form nutzbar waren.

Diese Methodenvielfalt und die dadurch bedingte fehlende Standardisierung bewirkten wenn Oberhaupt - einen Auswahlprozeß von Seiten des Entwicklers, der durch seinen Ausbildungsstand, seine Denkweisen und Vorlieben geprägt war. Die Unübersichtlichkeit von Programmen wurde dadurch nur geringfügig eingegrenzt. Programmen, die gänzlich auf der Sicht der Dinge eines oder mehrerer Entwickler beruhten, standen nun Programme gegenüber, die auf unterschiedlichen und dazu oft individuell abgewandelten Methoden beruhten. Zweifellos zeigte sich hier eine bessere Strukturierung und Nachvollziehbarkeit, aber nur, wenn man mit den angewandten und individuell abgewandelten Methoden vertraut war. Eine Lösung der Softwarekrise war damit also noch nicht erreicht. Das Dilemma war lediglich auf eine andere Ebene verlagert worden.

"Computer Aided Software Everything"

Das Zauberwort, das heutzutage den Weg aus der Krise weisen soll, heißt CASE - "Computer Aided Software Engineering", von Zynikern auch oft als "Computer Aided Software Everything" bezeichnet.

Eine der Aufgaben von CASE ist die Überwachung der Einhaltung der oben angesprochenen Methoden und Regeln. Mit der Überwachung von Regeln ist aber der Methodenstreit noch nicht aus der Welt geschafft, geschweige denn ein einheitlicher Standard geschaffen. Und auch wenn die Umsatzzahlen von CASE-Produkten eindeutig belegen, daß immer mehr Anwender auf das Pferd namens CASE setzen, so läßt sich damit höchstens sagen, daß mit CASE der Weg zum Stein der Weisen beschritten wurde, das Ziel aber noch lange nicht erreicht ist.

IDC schätzt den Markt für CASE-Tools in der Bundesrepublik Deutschland auf ein Volumen von rund 35 Mio DM, was im Vergleich zum gesamten Markt für Software und Services mit einem Volumen von 14 780 Mio. Mark doch noch einen recht geringen Marktanteil darstellt. International konnten jedoch starke Wachstumstendenzen ausgemacht werden. So tummeln sich mehr als 70 US-Hersteller im weltweiten CASE-Markt. Diese können auf ca. 21 610 Installationen weltweit verweisen, was ein Wachstum von 82 Prozent bedeutet.

CASE-Nachfrage noch relativ gering

Mit rund 30 Mio. Mark ebensogroß wie der CASE-Markt in Deutschland, ist der bundesdeutsche Markt für die Beratung und Schulung von CASE-Tools. Dies hängt sicherlich mit der Komplexität von CASE-Tools zusammen, die ohne Kenntnis der zugrundeliegenden Methoden praktisch nutzlos sind. Wie wichtig die Beratung und Schulung im Falle CASE von den Herstellern genommen wird, zeigt sich auch daran, daß einige CASE-Hersteller ihre Produkte -dem Anwender nur zur Verfügung stellen, wenn dieser einen Vertrag unterschreibt, der umfangreiche Beratungs- und Schulungsaktivitäten beinhaltet.

Beim Kauf von CASE-Tools müssen Anwender deshalb den doppelten Kaufpreis ansetzen, da die Hälfte der Gesamtkosten für Beratung und Schulung angesetzt werden muß.

Mehr Produktivität nicht von heute auf morgen

Auf keinen Fall sollten Anwender davon ausgehen, daß CASE-Tools einen kurzfristigen Nutzen bringen. Eine effektivere Produktivität in der Softwareentwicklung ist mit den heutigen CASE-Produkten nur auf langfristiger Basis zu erwarten und nicht von heute auf morgen.

Eine Befragung von IDC zeigte, daß sich bereits viele Entscheidungsträger mit dem Gedanken der Einsparung von Softwareentwicklungskosten durch den Einsatz von CASE-Tools befassen. Ohne Spezialisten mit profunden Softwareentwicklungskenntnissen ist zumindest der Einsatz heutiger CASE-Produkte nicht möglich.

Abschließend läßt sich festhalten, daß der Einsatz von CASE-Tools eine Leistungssteigerung bei der Softwareentwicklung mit sich bringt. Zahlreiche Gespräche, die IDC mit heutigen CASE-Anwendern führte, machten deutlich, daß sich insbesondere im Bereich der Dokumentation der erstellten Software hervorragende Ergebnisse ausmachen ließen. Das führt zu einer besseren Wartbarkeit der Software. Auch Zeitersparnisse bei der Softwareentwicklung konnten festgestellt werden. Und letztlich lagen die Ergebnisse deutlich näher an den ursprünglich formulierten Softwareanforderungen als bei der herkömmlichen Softwareentwicklung.

Nicht vorhandener Standard wird beklagt

Dem stehen aber heute noch zahlreiche Nachteile gegenüber. Viele Tools sind nicht miteinander kompatibel und können somit nicht verknüpft, sondern nur getrennt voneinander eingesetzt werden. Diese Inkompatibilität läßt sich bedauerlicherweise sogar auch zum Teil bei Produkten von ein und demselben Hersteller finden. Der Einsatz auf unterschiedlichsten Hardwareplattformen ist erst zum Teil verwirklicht. Viele Anwender beklagen auch den nicht vorhandenen Standard bei den Software Engineering-Methoden, so daß die Entscheidung für ein Produkt oft aus einer Abwägung zwischen der Leistungsqualität des Tools und der dafür verwendeten Software Engineering-Methode gefällt werden muß.

Es bleibt festzuhalten, daß CASE noch viel zu oft als reiner Marketingbegriff verstanden wird. Der Reifegrad der angebotenen Produkte ist nach wie vor

gering.

Tools realisieren CASE-Ideen

Zur Zeit läßt sich eher festhalten, daß der Anwender nach wie vor verwirrt darüber ist, was CASE eigentlich darstellt bzw. welchen Nutzen er daraus ziehen kann. Eine der Ursachen dafür ist die magische Wirkung, die im Moment noch von diesem Wort ausgeht, und für die insbesondere die Marketing-Strategen zahlreicher Soft- und Hardware-Hersteller, aber auch anerkannter Beratungsunternehmen, sehr anfällig sind. So gibt es denn viele Produkte, die ursprünglich unter einer ganz anderen Softwaregruppierung liefen, die heute - marketingmäßig neu verpackt - unter dem Schlagwort CASE angeboten werden, um aus dem aktuell bestehenden Marktinteresse Kapital zu schlagen.

Gefördert wird der Begriffswirrwarr durch Wortschöpfungen wie Front-End-, Back-End-, Upper- und Lower-CASE-Tools, IPSEs, usw. Festzuhalten bleibt, daß im Prinzip jedes Softwarepaket als CASE-Tool bezeichnet werden darf, das in irgendeiner Form die Programmierung erleichtert. Dadurch ergibt sich das gleiche Dilemma, wie auch schon bei der , CIM-Diskussion: nämlich, daß der Begriff CASE immer schwammiger wird.

IDC verwendet folgende Definition: CASE ist ein umfassender Begriff - richtigerweise eine Idee -, die für eine Software-Unterstützung im Rahmen der Entwicklung von Anwendungsprogrammen steht.

Angestrebt wird, daß jeder Abschnitt der Anwendungsentwicklung unterstützt werden soll, also die Phasen der Planung, der Definition, des Entwurfs, der Codierung, der Implementation, des Tests und der Einführung, der Dokumentation und der Wartung.

Ein CASE-Tool ist nun die Verwirklichung der Idee CASE, wobei alle obengenannten Phasen durch diese Tools abgedeckt werden sollen. Vor allem soll ein CASE-Tool die Funktionen Entwurfsunterstützung, Dokumentationsverwaltung, Projektplanung, Software-Generierung und Test beinhalten. Damit wird deutlich, daß ein CASE-Tool eine Datenbankkomponente enthalten muß, die heute als ein Repository bezeichnet wird, in früheren Jahren jedoch auch Entwicklungsdatenbank oder Data Dictionary hieß. Die zuvor erwähnten Begriffe Front-End-, Back-End-, Upper- und Lower-CASE-Tools, IPSEs, usw., decken nur einen Teil der Phasen der Softwareentwicklung ab.

Subjektive Komponente

"Die Beantwortung der Frage, welche Methode denn die Richtige ist, gestaltet sich schwierig. Denn Software-Entwicklung hat auch eine Philosophische und damit subjektive Komponente."