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.

05.04.1991 - 

Theoretisch erworbene Urteile müssen oft revidiert werden

Erst in der Praxis offenbaren die CASE-Werkzeuge ihre Schwächen

Anhand von Produktbeschreibungen läßt sich ein Softwaresystem kaum beurteilen; auch Präsentationen des Herstellers legen die Schwachstellen eines Produktes selten offen. Insbesondere eine so folgenschwere Entscheidung wie die Auswahl eines CASE-Werkzeugs sollte nicht getroffen werden, ohne das betreffende System im praktischen Einsatz zu testen.

CASE-Tools sind zur Zeit der Renner auf dem Softwaremarkt. Nach einer Schätzung des CASE-Experten Ed Yourdon arbeiten zwar derzeit erst fünf bis acht Prozent der Analytiker mit solchen Werkzeugen; doch sei zu erwarten, daß bis 1995 etwa jeder zweite von ihnen seine Arbeit mit Computerunterstützung durchführen werde. Dementsprechend eilig haben es die Unternehmen, CASE-Werkzeuge anzuschaffen.

Wer ein solches Tool einführt, erwartet meist Kosten in 8 Höhe von 30000 bis 40000 Mark pro Entwickler. Die Preise für die Softwarelizenz und für einen leistungsfähigen Arbeitsplatzrechner machen jedoch nur einen Teil der Gesamtkosten aus. Weniger evident, dafür aber höher sind die Kosten für die Ausbildung in der zugrundeliegenden Methodik und in der Handhabung der Tools so wie nicht zuletzt für den Aufbau der organisatorischen Infrastruktur. Auch die ersten Pilotprojekte, die möglicherweise in den Sand gesetzt werden, sollten einkalkuliert werden. Somit erreichen diese Investitionen schnell Millionenhöhe.

Diese Kosten müssen sich erst einmal amortisieren! Neben der Hoffnung auf qualitativ bessere DV-Lösungen existiert vielfach der Wunsch, daß die Produktivität der Anwendungsentwickler gesteigert werde. Hier gibt es mehrere Einflußfaktoren:

Zum einen soll die Arbeitsgeschwindigkeit bei der Erstellung von Diagrammen und Beschreibungen erhöht werden. Diese wird im wesentlichen durch die Benutzeroberfläche der Tools beeinflußt.

Zum anderen soll das Tool die Korrektheit und Vollständigkeit der Eingaben sicherstellen, um die Revisionsarbeit zu verringern. Weiterhin wird erwartet, daß ein CASE-Tool eine komplette Dokumentation erstellt und viele für die Programmierung notwendige Komponenten wie Bildschirm-Masken, Rahmenprogramme sowie Datenbank-Definitionen automatisch generiert.

Die Frage ist jedoch, ob diese Erwartungen hinsichtlich einer Produktivitätssteigerung wirklich erfüllt werden. Um die Leistungsfähigkeit eines CASE-Tools zuverlässig zu ermitteln, reicht eine Analyse anhand der Produktbeschreibung sicherlich nicht aus. Auf dem Papier sind alle Tools Spitze. Auch eine Vorführung durch einen routinierten Fachmann des Herstellers läßt das Produkt meist wirkungsvoll und problemlos erscheinen. Es ist ja schließlich nicht Aufgabe des Herstellers, die Schwachstellen seines Systems aufzuzeigen. Erst wenn man selbst ein Tool erprobt merkt man, wo die Probleme versteckt sind.

Erst dann fällt zum Beispiel auf, daß bei IEW die synchrone Änderung einer Grafik mit allen Konsequenzen auf abhängige Grafiken, Beschreibungen und Eintragungen in der Enzyklopädie auch Nachteile mit sich bringt: Wird ein Objekt aus Versehen gelöscht, so gibt es zwar noch einen Hinweis bezüglich der Auswirkungen auf andere Grafiken - nicht aber bezüglich der Verwendung dieses Objektes in einer Funktionsbeschreibung.

Auf dem Papier sind alle Tools Spitze

Leider ist es nicht möglich, einen versehentlich gegebenen Löschbefehl zurückzusetzen (UNDO); damit entfällt auch die Möglichkeit eines probeweisen Änderns. Im Gegensatz dazu lassen andere CASE-Tools die Änderungen erst durch ein SAVE-Kommando wirksam werden, was ein Experimentieren in der Grafik erlaubt.

Noch gravierender sind Iu-Konsistenzen, die zum Beispiel bei Excelerator oder Foundation erzeugt werden können. Zeichnet man in einem Entity-Relationship-Diagramm eine Verbindung zwischen den Objekten "Kunde" und "Auftrag", gibt aber bei der erforderlichen Eintragung für das Data-Dictionary als Objektnamen "Lieferant" und "Artikel" an, so fällt dies auch bei dem Analyselauf nicht auf - falls "Lieferant" und "Artikel" definierte Objekte im Data-Dictionary sind. Eine solche Inkonsistenz zwischen grafischer Darstellung und gespeicherter Beschreibung erhöht aber die Fehleranfälligkeit und den Prüfaufwand.

Oder ein Beispiel zum Thema doppelte Arbeit: Bei Excelerator gibt es keine Verbindung zwischen einem Prozeß im Datenfluß-Diagramm und dem gleichen Prozeß in der Funktionsstruktur (Strurcture Chart). Deshalb ist die Prozeßbeschreibung zweimal einzugeben. Umgekehrt müssen beide Beschreibungen separat gelöscht werden.

Auch funktionale Mängel schaffen Probleme. So ist zum Beispiel bei Foundation nur eine Referenzierung pro Objekt erlaubt. Deswegen ist es nicht möglich, einer Funktion im Datenfluß-Diagramm sowohl eine Funktions-beschreibung als auch ein darunterliegendes Diagramm anzuhängen. Das läßt sich zwar umgehen; allerdings wird die Sicherstellung der Korrektheit so auf den Menschen verlagert.

Jedes Tool besitzt andere Vor- und Nachteile

Andere Auswirkungen auf die Produktivität ergeben sich, wenn mehrere Analytiker arbeitsteilig am gleichen Projekt arbeiten. Zwar ist jeder mit der Verfeinerung eines anderen Datenfluß-Diagrammes beschäftigt, doch verwenden alle die gleichen Objekte aus dem Entity-Relationship-Diagramm.

Setzen die Entwickler zum Beispiel IEW ein, wo die Enzyklopädie (das Data-Dictionary) nicht gemeinsam genutzt beziehungsweise ein Teil davon nicht gesperrt werden kann, so sind einige Klimmzüge notwendig, um die Wissensbasis sinnvoll aufzuteilen und die auseinanderlaufenden Definitionen wieder zusammenzuführen.

Die Liste von unerwarteten Problemen, die sich auf die Produktivität eines CASE-Tools auswirken, läßt sich beliebig verlängern. Jedes Tool besitzt andere Vor- und Nachteile. Deshalb sollte sich das Anwenderunternehmen vor einer so großen Investition, wie sie die Einführung von CASE darstellt, ein realistisches Bild von den Stärken und Schwächen der relevanten Produkte machen, und dazu müssen die Werkzeuge systematisch getestet werden.

Realistisches Bild von den Stärken und Schwächen

Um bei einer solchen Erprobung alle Aspekte zu berücksichtigen, kann sich der Anwender an der Schichtenarchitektur der CASE-Tools orientieren (siehe Abbildung).

- Die Präsentationsschicht oder Benutzeroberfläche entscheidet durch ihr Führungsangebot, ihre Konsistenz der Handhabung, ihre Anleitungs und Hilfefunktionen sowie die Anzahl paralleler Fenster im wesentlichen über die Eingewöhnungs- und Arbeitsgeschwindigkeit der Benutzer.

- Die User-Interface-Schicht bildet die konsistente innere Schnittstelle zwischen dem Benutzer und den verschiedenen Tools. Ist sie nicht oder nur teil- weise vorhanden, so zerfällt das Produkt in isolierte Komponenten, die einzeln aktiviert werden müssen und zwischen denen der Benutzer selbst hin- und herzuwechseln hat.

- Bei der Tool Schicht handelt es sich um die funktionalen Komponenten eines CASE-Tools. Man findet zwei Arten von Tools, die vertikalen und die horizontalen. Die vertikalen Tools übernehmen eine Aufgabe innerhalb einer bestimmten Entwicklungsphase (zum Beispiel Datenfluß-Diagramm-Editor, Entity-Relationship-Editor); die horizontalen Tools können während des gesamten Software-Lebenszyklus genutzt werden (zum Beispiel Dokumentation sowie Projekt- und Konfigurations-Management).

- Die Objekt-Management-Schicht übernimmt die Kommunikation der einzelnen Tools mit dem zentralen Repository und sorgt dafür, daß jedes Objekt von jedem Tool, das hierüber Informationen braucht, bearbeitet werden kann. Wenn die Beziehungen der Objekte untereinander - beispielsweise Grafik und Beschreibungen - korrespondierend verwaltet werden, können Änderungen oder Löschungen automatisch an allen betreffenden Stellen durchgeführt werden. Ansonsten fällt diese Verwaltungsarbeit auf den Benutzer zurück.

- Die Repository-Schicht stellt eine Ablage der Grafik und der Beschreibung aller Design-Objekte in konsistenter Form dar. Wichtige Funktionalitäten dieser Schicht sind ein Abgleichsmechanismus, eine Versionsführung und eine dedizierbare Zugriffsberechtigung. Sind diese Leistungen nicht oder nur unvollständig realisiert, so bedeutet dies für die Benutzer erhöhten Verwaltungsaufwand und mehr Fehlerquellen.

Um ein CASE-Tool vollständig abklopfen zu können, haben wir für unser CASE-Testzentrum einen 16seitigen Kriterienkatalog geschaffen, der alle Beurteilungsaspekte enthält. Doch das allein reicht nicht. Der Anwender sollte die einzelnen Funktionen selbst erproben können. Zu diesem Zweck ist eine Aufgabenstellung notwendig.

Ad-hoc-Aufgaben und Pilotprojekte sind für eine Tool-Erprobung wenig geeignet. Ad-hoc-Aufgaben sind zu wenig durchdacht und sicherlich nicht über alle Analyseobjekte hin konsistent; Pilotprojekte sind zu umfangreich.

Meist wird viel zuviel Zeit und Arbeit in ein CASE-Tool investiert, bis sich herausstellt, daß es unbrauchbar ist. Bei einem großen Chemie-Unternehmen zum Beispiel wurde ein theoretisch ausgewähltes CASE-Werkzeug mit einem Aufwand von sechs Mannmonaten in einem Pilotprojekt erprobt. Erst dann stellte das Unternehmen fest, daß sich das Tool für diesen praktischen Einsatz doch nicht eignete.

Aus diesem Grund ist für die Erprobung ein im Umfang passendes und abgesichertes Fallbeispiel notwendig. Abgesichert heißt, daß die Aufgabenstellung inhaltlich durchdacht ist und eine methodisch korrekte Lösung vorliegt. Andernfalls findet man nämlich nicht die methodischen Schwachstellen der CASE-Tools wie mangelhafte Unterstützung von Sub-Entitäten oder Mangel an exklusiven Beziehung zwischen Entitäten.

Darüber hinaus müssen Testaufgaben formuliert sein, anhand derer die Stärken und Schwächen der Tools erkannt werden können. Einen Ausschnitt aus der an unserem Testzentrum entwickelten Aufgabenliste zeigt der nebenstehende Kasten. Gemäß unseren Erfahrungen kann ein CASE-Tool - unter Anleitung eines erfahrenen Fachmannes - innerhalb von zwei bis drei Tagen systematisch und vollständig erprobt werden. Dabei geht so manches theoretisch erworbene Meinungsbild zu Bruch.

Informationen:Michael Bauer ist Geschäftsführer der Informatik Training GmbH, Radolfzell. Thomas Zeier ist Projektleiter des CASE-Testzentrums.