Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

06.12.1991 - 

Der Einsatz einzelner Tools ist wenig lukrativ

Integriertes CASE ist nicht in jedem Fall ein Marketing-Bluff

Verschiedene Hersteller von Software-Entwicklungswerkzeugen rühmen sich, integrierte CASE-Umgebungen anzubieten - ein Anspruch, der von Fachkreisen angezweifelt wird. Dirk Berensmann* beschreibt, welche Anforderungen erfüllt sein müssen, damit eine CASE-Umgebung wirklich als integriert bezeichnet werden kann. Dabei spielen Durchgängigkeit und vertikale Integration eine entscheidende Rolle.

Entgegen den wohlklingenden Versprechungen, mit denen Anbieter für neue CASE-Technologien werben, verhalten sich DV-Manager eher skeptisch und abwartend. Diese Zurückhaltung allein mit negativen Erfahrungen aus der Vergangenheit zu begründen, wäre nur zum Teil richtig. Tatsächlich blieben die wirklichen Fähigkeiten der angebotenen Programme oft weit hinter den Werbeversprechen der Software-Industrie zurück. Welche Gründe lassen sich für die Zurückhaltung anführen, mit der CASE in der deutschen Wirtschaft aufgenommen wird?

Alte Programme neu vermerktet

Genauere Untersuchungen des Angebots zeigen, daß eine konkrete Begriffsbestimmung des Computer Aided Software Engineering bis heute nicht besteht. Viele Programme, die zum Teil bereits seit Jahrzehnten im Bereich Software-Entwicklung existieren, werden heute unter dem Oberbegriff CASE neu vermerktet, ohne daß sich deren Fähigkeiten merklich geändert haben.

Auf der anderen Seite gibt es eine Flut neuer Anbieter, die in den zukunftsträchtigen CASE-Markt einsteigen wollen, ohne eigentlich zu wissen, welche Ziele der CASE-Ansatz verfolgt. Nur so läßt sich erklären, daß selbst einfache Grafikprogramme unter der Produktbezeichnung CASE anzufinden sind.

Doch wer will den Marketing-Strategen verübeln, daß sie unter der Flagge eines neuen Trends segeln, vor allem, wenn dieser so verschwommen definiert wird, wie dies im Fall des Computer Aided Software Engineering geschieht? Bevor also Argumente gesammelt werden können, muß dieser Begriff erst einmal genau definiert werden.

Der Begriff Engineering läßt sich nur schwer kurz und prägnant ins Deutsche übersetzen. Gemeint ist das ingenieurmäßige Vorgehen bei der Lösung von Problemen, wobei auf der Basis fest definierter Methoden und Regeln gearbeitet wird. In diesem Sinne läßt sich Software Engineering als Programmentwicklung nach einem klar umrissenen methodischen Vorgehen verstehen. Oft wird ein sogenanntes offenes CASE-Tool als Werkzeug verstanden, das dem Anwender die Möglichkeit gibt, seine Methode selbst zu definieren. Dahinter steckt aber wohl eher ein Marketing-Gag als eine tatsächliche Eigenschaft des jeweiligen Programms, denn wie läßt sich eine Methode unterstützen, die eigentlich niemand kennt?

Genauere Untersuchungen zeigen, daß derartige CASE-Tools lediglich die Auswahl aus einer Reihe vordefinierter Techniken bieten, wobei deren Summe letztendlich auch nichts anderes ergibt als die "geschlossene" Methodik des jeweiligen Tools.

Auch muß in diesem Zusammenhang zwischen tatsächlich unterschiedlichen Techniken und der lediglich wahlweisen Ergebnisdarstellung ein und derselben Technik differenziert werden.

Der Begriff CASE impliziert auch, daß diese ingenieurmäßige Software-Entwicklung computergestützt (Computer Aided) durchgeführt wird. Die Methodik ist also in Programmen implementiert, die die einzelnen Techniken der Methode unterstützen. Auf dieser Basis könnte man vielleicht folgende Definition erstellen: CASE ist die Kombination von Methoden beziehungsweise Techniken der Software-Entwicklung mit leistungsfähigen Computerprogrammen, welche diese Methoden oder Techniken implementieren und weitgehend automatisieren.

Diese Definition zeigt, daß CASE durchaus nicht so aufregend neu ist, wie dies die Softwarebranche glauben machen will. Sowohl Software-Entwicklungsmethoden als auch Computerprogramme, die auf deren Basis erstellt wurden, gibt es seit langem. Erinnert sei an die Vielzahl von Data Dictionaries und Diagrammwerkzeugen, Bildschirm-Designern oder Code-Generatoren, die schon seit Jahren am Markt sind.

CASE - ein neues Modewort für alte Techniken? In der Tat ist das Thema im Rahmen der genannten Definition nicht neu. Es wird schwerfallen, ein namhaftes Unternehmen zu finden, in dem nicht mindestens ein derartiges Tool bereits vorhanden ist. Ich spreche in diesem Zusammenhang bewußt von "Vorhandensein", denn oftmals werden diese - nennen wir sie" traditionellen - CASE-Tools kaum produktiv in der Software-Entwicklung eingesetzt.

Die Ablehnung hat einen Grund: Traditionelle Werkzeuge adressieren lediglich einen kleinen Ausschnitt aus dem gesamten Lebenszyklus der Software-Entwicklung und lösen so nur einen geringen Teil der Probleme, mit denen ein Anwendungsentwickler im Laufe seiner Arbeit konfrontiert wird. Daraus aber ergibt sich oft ein - aus Sicht des jeweiligen Entwicklers - denkbar schlechtes Aufwand-Nutzen-Verhältnis, denn dem hohen Lern- und Einarbeitungsaufwand steht meist nur ein relativ bescheidener Nutzen (in Form von besserer Qualität oder Zeitersparnis) gegenüber.

Dies führt dazu, daß die oft mit hohem Aufwand in ein Unternehmen eingeführten traditionellen Tools gegenwärtig zumeist kaum benutzt werden und im DV-Management eher Alpträume als Euphorie auslösen. Hinzu kommt, daß alle Versuche, durch die Kombination mehrerer Tools eine möglichst weitgehende Abdeckung des gesamten Lebenszyklus zu erreichen, gescheitert sind. Methoden und Programme erwiesen sich als inkompatibel, die Einarbeitung in die verschiedenen Produkte erforderte einen Lernaufwand, der nicht mehr zu rechtfertigen war.

Vor diesem Hintergrund erscheint logisch, daß ein erfolgversprechender CASE-Ansatz ganzheitlich erfolgen muß. Sowohl die Methodik als auch das darauf basierende Werkzeug müssen den gesamten Lebenszyklus der Software-Entwicklung abdecken. Dieser Ansatz, in der Fachliteratur auch als I-CASE (Integrated Computer Aided Software Engineering) bezeichnet, ist heute nur in sehr wenigen CASE-Tools implementiert.

In eigenen Projekten konnte ich mich davon überzeugen, daß Produktivitätssteigerungen von mehr als 50 Prozent durch den Einsatz vollständig integrierter CASE-Tools erreicht werden können und so zu einer Akzeptanz führen, die den hohen Aufwand ihrer Einführung rechtfertigt. Im Gegensatz zu den traditionellen CASE-Produkten, die lediglich die Symptome einzelner Probleme lindern, hat sich der I-CASE-Ansatz einer radikalen Umgestaltung der Software-Entwicklung verschrieben, mit dem Ziel, die "Automatisierung der Automation" einzuführen.

Welche Merkmale und Eigenschaften unterscheiden den integrierten CASE-Ansatz vom traditionellen? Wie wirken sich diese Merkmale auf die Anwendungsentwicklung aus? Da CASE entsprechend der obigen Definition stets in einer Kombination von Methode und Tool zu sehen ist, sollen hier zunächst einige der wichtigsten Merkmale von I-CASE-Methoden dargestellt werden.

Typisch für eine I-CASE-Methode ist deren Vollständigkeit, ihre Gültigkeit für den gesamten Lebenszyklus der Softwareentwicklung. Die Methode muß Techniken zur strategischen Planung von Informationssystemen, zur Grob- und Feinanalyse von Geschäftsgebieten, zum fachlichen und technischen Systementwurf, zu Implementierung und Test von Anwendungssystemen, zur Ablösung von Altsystemen und zur Programmpflege unter den Bedingungen des produktiven Einsatzes enthalten.

Darüber hinaus sollten Fragen des Projektmanagements und der Einführungsstrategie der Methodik selbst beantwortet werden. Ein weiteres wichtiges Merkmal ist die Kompatibilität der einzelnen in der Methodik enthaltenen Techniken. Das heißt, die Methode darf nicht als wahllos zusammengestellte "Kochbuchsammlung" agieren; vielmehr müssen die einzelnen Techniken aufeinander aufbauen und sich im Sinne einer fortschreitenden Detaillierung konsistent ergänzen. Die Methode sollte unabhängig von den jeweiligen Organisationen, Projekten und Zielsystemen einsetzbar sein. Entsprechend den Rahmenbedingungen eines Projektes müssen alternative Vorgehensweisen innerhalb der Methode definiert werden können, damit sich sowohl strategische als auch kurzfristige Projekte durchfuhren lassen. Dies bedeutet auch eine klare Unterscheidung zwischen obligatorischen und optionalen Techniken oder Ergebnissen und die Möglichkeit zur fortlaufenden Einbindung neuer Technologien.

Letzteres wird vor allem dadurch erreicht, daß eine ständige Weiterentwicklung der Methode auf der Basis wirtschaftlicher Interessen gewährleistet ist. Die Auswahl der Techniken und Vorgehensweisen der Methode sollten eine größtmögliche Automatisierbarkeit gewährleisten; die manuellen Arbeitsschritte innerhalb der Methode sind auf ein notwendiges Mindestmaß zu beschränken. Dies wiederum setzt voraus, daß die entsprechende Methode nicht ausschließlich von Theoretikern entwickelt wird, sondern auch praktische Aspekte berücksichtigt werden.

Analog dazu ergeben sich für Werkzeuge, die solche Methoden unterstützen, einige konkrete Merkmale, die deren Effizienz in der Praxis wesentlich bestimmen. Eines dieser Merkmale ist die Durchgängigkeit: Das I-CASE-Tool hat zumindest die obligatorischen Techniken aus allen Methodenphasen zu unterstützen. Dazu gehören folgende Mindestanforderungen:

- Matrixprozessor für die strategische Planung: Innerhalb dieses Matrixprozessors sollten die grundlegenden Matrizen für eine strategische Planung (wie zum Beispiel Informationsbedürfnisse versus Organisationseinheit) bereits vordefiniert sein. Gleichzeitig muß es möglich sein, eigene Zuordnungen entsprechend den jeweiligen geschäftlichen Anforderungen zu erstellen.

- Diagrammwerkzeuge der Daten- und Funktionsmodellierung auf verschiedenen logischen Ebenen: Hier ist besonders wichtig, daß genau zwischen der Ebene einer abstrakten Definition der Geschäftslogik und deren technischer Realisierung unterschieden wird. Eine Denormalisierung sollte niemals auf der abstrakten Ebene definiert werden müssen, da dies einerseits zu einer Verfälschung der Analyseergebnisse führt und weil andererseits Aspekte der späteren Zielsysteme (Performance) bereits zu einem Zeitpunkt definiert werden müssen, zu dem diese Aspekte oft noch nicht bekannt sind und allenfalls vermutet werden können.

Zu bedenken ist, daß sich die Zielsysteme ebenfalls ständig weiterentwickeln. Folglich sind am Ende eines Projekts viele Performance-Nachteile, die zu Beginn aufgrund älterer Erfahrungen noch als kritisch eingeschätzt worden waren, gar nicht mehr vorhanden. Als Beispiel sei hier die rasante Entwicklung der relationalen Datenbank-Managementsysteme in den letzten Jahren aufgeführt.

- Diagrammwerkzeuge für die Definition der Systemstruktur und der Anwendungsoberflächen: Die Darstellung der Systemstruktur (beispielsweise der Online-Dialogabläufe) in diagrammatischer Form erleichtert die Kommunikation zwischen dem Entwickler und den späteren Anwendern. Somit werden von Anfang an Design-Fehler vermieden, die im nachhinein nur mit großem Aufwand korrigiert werden können.

Aus dieser Diagrammform sollte das jeweilige Tool direkt alle für die Kommunikation zwischen den Programmen notwendigen Codestrukturen erzeugen können. Auf die Bedeutung von intelligenten Oberflächen-Designern für eine effiziente Software-Entwicklung muß an dieser Stelle sicher nicht gesondert hingewiesen werden.

Als sehr nützlich in der praktischen Arbeit hat sich ebenfalls ein Prototyping-Tool auf der Basis der Systemstruktur und der Anwendungsoberflächen erwiesen, mit dessen Hilfe zum Beispiel die Online-Dialoge mit den Anwendern abgestimmt werden können, ohne daß bereits eine Codierung erfolgt sein muß.

- Leistungsfähige Programmiersprache der vierten Generation. Ohne den alten Streit über das Für und Wider von Programmiersprachen an dieser Stelle erneut anzufachen: Nach meiner Meinung ist es nach wie vor unerläßlich, die Algorithmen, Formeln etc. des jeweiligen Geschäftes in einer eindeutigen und genau definierten Form (Syntax) ablegen zu können.

Anforderungen an eine Programmiersprache

Solange nicht eine einheitliche und allumfassende Diagrammdarstellung derartiger Logiken verfügbar ist, hat sich das Konzept der Programmiersprache im praktischen Einsatz als das universellste erwiesen. Allerdings sollte eine Programmiersprache in der heutigen Zeit einigen grundlegenden Anforderungen genügen. Dazu gehören:

1. die Orientierung an der natürlichen Sprache ohne Verzicht auf Eindeutigkeit,

2. die Beschränkung auf die logische (abstrakte) Ebene mit möglichst wenig Syntaxelementen,

3. die Möglichkeit zur Einbindung traditionell erstellter Programme für performance-kritische Anwendungen und zur Nutzung existierenden Codes,

4. grafische Strukturierungshilfen,

5. Referenzierung bereits in Diagrammform definierter Eigenschaften statt Neudefinition aller Codebestandteile wie beispielsweise der Variablendeklarationen,

6. interaktive Unterstützung des Entwicklers durch das kontextsensitive Aufblenden der an der jeweiligen Position gültigen Syntaxelemente und durch den ständigen Abgleich mit bereits definierten Ergebnissen in anderen Tool-Komponenten.

- Schneller und fehlerfreier Code- und Datenbankgenerator: Dies ist ein ganz entscheidender Punkt für die Akzeptanz eines CASE-Tools. Nichts ist frustrierender für einen Anwendungsentwickler, als wenn er nach der Definition des Systems in Diagrammstellungen und einer höheren Programmiersprache letztendlich doch in altbekannter Weise die Programme in Cobol oder einer ähnlichen Sprache selbst implementieren und damit quasi alle Ergebnisse neu erfassen muß. Andererseits ist zu beobachten, daß die Motivation der Entwickler um so stärker steigt, je schneller und zuverlässiger aus den (in ersten CASE-Projekten aufgrund des Hohen Lern- und Einarbeitungsaufwandes) oft mühsam erstellten Diagrammen lauffähige und fehlerfreie Programme generiert werden.

- Test-Tool auf der Ebene der logischen Spezifikation: Für die Akzeptanz und Effizienz eines CASE-Tools ist von entscheidender Bedeutung, mit welchem Aufwand die für die meisten Entwickler leidige Testphase von Anwendungssystemen durchzuführen ist. Muß für das Auffinden von Fehlern die logische Ebene verlassen werden, so ist der Entwickler nicht nur genötigt, sich in die technischen Details seines Programmes einzuarbeiten; vielmehr muß er auch noch die interne Logik des jeweiligen Codegenerators kennen, uni die automatisch generierten Codebestandteile von der eigentlichen Geschäftslogik, unterscheiden zu können.

- Werkzeuge zum Projekt- und Versionsmanagement: in bezug auf die Einbindung von Projektmanagement-Werkzeugen gibt es zwei grundlegende Alternativen

Entweder bietet das CASE-Tool integriert eigene Werkzeuge an oder eine Schnittstelle zu den mittlerweile am Markt reichlich vorhandenen Tools. Da es sich bei dieser Schnittstelle gewissermaßen um eine "Einbahnstraße" handelt, entstehen auch bei dem letzteren Ansatz keine nennenswerten Nachteile und die freigewordenen Entwicklungskapazitäten kommen anderen Bereichen des CASE-Tools zugute.

Ein solcher Bereich könnte zum Beispiel das Versionsmanagement sein, das vor allem bei der Produktionseinführung Lind späteren Pflege der Systeme eine wichtige Rolle spielt. durch die Möglichkeit, gleichzeitig mehrere Versionen eines Systems verwalten zu können, ist nicht nur die Revisionsfähigkeit der Programme gewährleistet - jede Übernahme aus der Test- in die Produktionsversion wird protokolliert -, sondern auch die Rückwärtskompatibilität der einzelnen Versionen.

Die vielgeschmähten, aber leider nie ganz vermeidbaren "Production Fixes" können durch derartige Werkzeuge automatisch in die aktuellen Test- oder Entwicklungsversionen übernommen werden, wobei das CASE-Tool selbständig die Konsistenz der einzelnen Versionen sicherstellen sollte.

- Werkzeuge der Entwicklungskoordination: Hierbei handelt es sich um Tools, die unter anderem

1. das Zusammenfügen oder Aufteilen von Modellen entsprechend den definierten Projekten ermöglichen,

2. die Zugriffsberechtigungen auf die verschiedenen Entwicklungsobjekte verwalten und gewährleisten, daß keine konkurrierenden Änderungen auftreten, die zu Inkonsistenzen führen,

3. die Verwaltungsaufgaben durch vordefinierte Berichte und Auswertungen unterstützen,

4. eine zentrale Datensicherung ermöglichen.

Neben der Durchgängigkeit der I-CASE-Umgebung ist die Integration von zentraler Bedeutung. Eine horizontale Integration, die Sicherstellung der Integrität zwischen den unterschiedlichen Diagrammen beziehungsweise Techniken innerhalb einer Tool-Komponente, ist heute in den meisten Werkzeugen mehr oder weniger gut verwirklicht.

Unterschiede zwischen CASE- und I-CASE-Tools

Der wichtigste Unterschied zwischen den traditionellen CASE-Tools und einem I-CASE-Werkzeug besteht darin, daß die einzelnen Komponenten hier auch vertikal integriert sind. Dies bedeutet, daß alle Ergebnisse von einer Komponente in die nächste direkt übernommen werden können, zum Beispiel von der strategischen Planung in die Detailanalyse. Die einzelnen Tool-Komponenten stellen somit eine unterschiedliche Sicht auf die Entwicklungsobjekte dar (abstrakte Sicht, technische Sicht). Die Objekte selbst aber werden nicht mehrfach definiert, sondern nur um bestimmte Eigenschaften ergänzt (Vorwärtsintegration).

Ebenso wichtig ist, daß im Laufe der Entwicklung nicht die bereits früher definierten Eigenschaften verändert werden können (Rückwärtsintegration). Nur so läßt sich erreichen, daß die letztendlich erstellten Systeme tatsächlich den in der Planungs- und Analysephase definierten Anforderungen entsprechen. So sollte es nicht möglich sein, während des technischen Systementwurfs andere Feldtypen definieren zu können als sie im abstrakten Datenmodell angegeben wurden.

Die Entwicklungsobjekte sind im zentralen Repository des CASE-Tools redundanzfrei abzulegen. So ist gewährleistet, daß jedem Entwickler stets die aktuellsten Informationen zugänglich sind. Eine Namensänderung zum Beispiel sollte sofort in allen Komponenten (Diagrammen, Programmen) wirksam werden, egal an welcher Stelle diese vorgenommen wurde.

Pragmatismus ist eine weitere wichtige Eigenschaft des CASE-Tools: Das Werkzeug sollte keine Angaben vom Entwickler erzwingen, die für das Generieren von Systemen nicht unbedingt notwendig sind. Damit wird die Möglichkeit gegeben, schnell dringend benötigte Systeme erstellen zu können, auch wenn diese nicht bis in letzter Konsequenz "perfekt" sind. So sollte das Werkzeug von sich aus Standardvorgaben für Parameter verwenden, wo immer dies möglich ist (zum Beispiel während der Definition physischer Datenbestände), sobald der Entwickler keine diesbezüglichen Werte angibt.

Die Automation des I-CASE-Tools sollte sich nicht nur auf den Einsatz von Codegeneratoren beschränken, sondern während aller Phasen die Möglichkeit zum Erzeugen vordefinierter Strukturen nutzen. So ist es möglich, aufgrund der definierten abstrakten Datenstruktur bereits die funktionale Logik für die Pflege dieser Daten zu erzeugen (natürlich im Format des I-CASE-Tools).

Auf der Basis der definierten funktionalen Logiken können Vorschläge für eine Systemstruktur und die Anwendungsoberflächen erstellt werden, die dann lediglich noch entsprechend den jeweiligen Anforderungen "nacheditiert" werden müssen. Standardfunktionen wie kontextsensitives Help oder Abend-Handling können vordefiniert angeboten werden, wobei sich diese Aufzählung noch beliebig fortsetzen ließe.

Während Durchgängigkeit, Integrität, Redundanzfreiheit, Pragmatismus und Automation wichtige Eigenschaften sind, erweisen sich andere Merkmale, die von Vertriebsbeauftragten gern euphorisch angepriesen werden, in der praktischen Arbeit oft als nutzlos und teilweise sogar hinderlich. An dieser Stelle seien nur zwei Beispiele angeführt: Manche CASE-Tools bieten die Möglichkeit, daß sich der Entwickler die Diagrammsymbole selbst definieren kann.

Diese auf den ersten Blick vielleicht sinnvolle Eigenschaft erweist sich spätestens dann als Nachteil, wenn in einem Projekt mehrere Entwickler ihre Ergebnisse untereinander koordinieren oder mit späteren Anwendern abstimmen müssen. Die Zeit, die vergeht, weil sich die Beteiligten gegenseitig die jeweiligen Symbole erklären, kann in einem Projekt sicher produktiver genutzt werden.

Der Einsatz dieser Tools erfordert die Definition von Standards, Schulung und Überwachung - ein Aufwand, der einfach dadurch vermieden werden kann, daß das CASE-Tool von sich aus diese Standards vorgibt. Wenn diese Standards einigermaßen sinnvoll und akzeptabel sind, können alle Beteiligten damit leben, schließlich geht es in einem CASE-Projekt nicht darum, wer die schönsten Diagramme malt!

Andere Anbieter wiederum scheinen nach der Methode zu verfahren: "Viel hilft viel." Sie übersehen dabei, daß gerade in der Software-Entwicklung das berühmte Chinesenprinzip nicht anwendbar ist. Was soll also die Flut von Diagrammen und Listen, die manche CASE-Tools anbieten, wenn sich die gleichen Ergebnisse auch in einer einzigen Darstellung übersichtlich und kompakt anordnen lassen?

Jedes zusätzliche Diagramm bedeutet nicht nur einen erhöhten Lern- und Einarbeitungsaufwand, es erschwert auch die Suche nach einer konkreten Information sowie die Abstimmung von Ergebnissen. So haben sich zum Beispiel auf dem Gebiet der Datenmodellierung zwei verschiedene Diagramme zur Darstellung von abstrakter Struktur und technischer Realisierung als völlig ausreichend erwiesen.

Nicht allein die Verfügbarkeit entscheidet

Ob und wann ein Unternehmen über die Einführung von CASE nachdenkt, entscheidet nicht allein die Verfügbarkeit entsprechender Produkte am Markt. Sicher ist, daß die SW-Entwicklung eine immer strategischere Bedeutung für den Gesamterfolg des Unternehmens erlangt. In einigen Branchen entscheidet sie schon heute über die Wettbewerbsfähigkeit und auch die traditionellen Industrien werden von dieser Entwicklung auf längere Zeit gesehen nicht verschont bleiben (man denke nur an die Logistik der Just-in-time-Produktion). In diesem Sinne sollten sich nicht nur die DV-Manager Gedanken über CASE machen.