Die anfängliche CASE-Euphorie ist der Ernüchterung gewichen. Tom deMarco, Begründer der als "Structured Analysis" bekannten Software-Entwurfsmethode, führt die grassierende Enttäuschung der CASE-Gemeinde vor allem auf falsche Erwartungen zurück. Mit dem Software-Theoretiker sprach unser freier Mitarbeiter Horst-Joachim Hoffmann.
CW: Untersuchungen über den Einsatz von CASE-Tools haben ergeben, daß nur ein Drittel der Werkzeuge im beabsichtigten Leistungsumfang genutzt werden. Wie bewerten Sie diese Zahlen?
Tom deMarco: Es stimmt tatsächlich, daß CASE als Thema für Konferenzen, Fachartikel oder Seminare sehr viel mehr Reiz ausübt als im tatsächlichen Einsatz. Das ist an sich schon enttäuschend. Ich glaube, daß das CASE-immanente Versprechen nicht vollständig wahrgenommen wurde. Aber noch entmutigender ist, daß viele Unternehmen, die oft mehrere Hundert Softwarespezialisten beschäftigen, nur ein einziges System gekauft, ausprobiert und - wenn überhaupt - mit einer Schwarzweiß-Sicht adaptiert haben.
CW: Wie kommt das?
Tom deMarco: Dafür gibt es verschiedene Begründungen; sie betreffen nicht so sehr den Weg, wie CASE implementiert wurde, sondern die Art, wie ein solches System tatsächlich genutzt und eingebunden wird: Tools für das Computer-aided Software-Engineering werden vielfach zu Dokumentationswerkzeugen degradiert. Und solange CASE in dieser Rolle eingesetzt wird, kann es sein Versprechen nicht einlösen. Um eine Umgebung für computerunterstütztes Software-Engineering bereitzustellen, ist es wichtig, daß CASE ein integraler Bestandteil des Denkens wird.
CW: Können Sie diesen Gedanken näher erläutern?
Tom deMarco: Der Denkprozeß für die wichtigen Softwareprojekte findet sehr oft nicht dort statt, wo das CASE-System installiert ist. Meist sitzt jemand isoliert vor dem System und arbeitet damit. Fast alle wichtigen Aktionen in der ersten Hälfte eines Software-Lebenszyklus aber finden in sehr viel größeren Gruppen statt, mit drei oder vier Mitgliedern, die die typischen Teilnehmergruppen - Anwender und Systemspezialisten - repräsentieren. Normalerweise wird das CASE-System dazu beiseite gelegt und die Interaktion über Sprache, Notizen und Bilder vorgenommen. Später erst wird versucht, diese Ergebnisse auf CASE zu reduzieren. So wird das CASE-System zu einem Dokumentationsunterstützungspaket. Und das ist absolut unerheblich.
CW: Auf welcher Basis ist es denn möglich, die ja doch wohl vorhandenen guten Seiten einer DV-unterstützten Entwicklungsumgebung herauszuarbeiten?
Tom deMarco: Der Schlüssel dazu, CASE wirklich sinnvoll zu machen, ist, ihm eine Rolle als organischer Part des Denkprozesses einzuräumen, so wie es beispielsweise in der Automobilindustrie bei CAD der Fall ist. CASE muß eine sinnvolle Aufgabe genau dort bekommen, wo kleine Gruppen zusammenarbeiten. Die Vorstellung einer CASE-Station, an der eine einzelne Person arbeitet, geht am Thema vorbei.
CW: Wie läßt sich CASE praktisch in einen Projektablauf einbinden?
Tom deMarco: Wir beobachten zur Zeit einige Versuchssysteme in amerikanischen Unternehmen, wo CASE in Gruppen angewendet wird - auf einem Großbildschirm, mit drei oder vier Arbeitsplätzen, wo die Leute umherlaufen und miteinander reden.
Da gibt es schöne Lösungen: eine Kombination von CASE mit der Technik des "Blitzing" oder anderen methodischen Hilfen zum Beispiel. Aber man kann CASE auch als Unterstützung im Hintergrund einsetzen, wo durch einen Unbeteiligten Dinge visualisiert werden, die gerade besprochen werden. Das alles sind Ansätze, CASE zu einem organischen Teil des Denkens zu machen. Nochmal: CASE ist keine Dokumentationsbeigabe.
CW: Warum ist die Annäherung an CASE mit so vielen Problemen behaftet?
Tom deMarco: Ein ausgereiftes CASE-System kann sehr leicht in dem Sinne eingesetzt werden, den ich gerade skizziert habe. Irgendwie aber sind wir daran gescheitert,
den Leuten verständlich zu machen, daß ein solches System als Teil des Denkprozesses betrachtet werden sollte.
CW: Handelt es sich wirklich nur um Verständnisprobleme?
Tom deMarco: Nein. Wir haben zusätzliche Probleme in diesem Bereich; eines davon ist, daß die Leute geradezu süchtig nach Dokumenten sind. Dieses Überbewerten von Dokumenten resultiert meiner Meinung nach aus einer Führungsunsicherheit. Wir generieren Türme von Dokumenten; dieser Aspekt muß speziell im Bereich der Führungsebene überdacht werden. Zudem hat die Dokumentengläubigkeit einen fast inflationären Einfluß auf die Erwartungen der Anwender in die CASE-Systeme gehabt.
CW: Welcher Art sind diese Erwartungen?
Tom deMarco: Nehmen wir einen typischen Entwickler, der behauptet, er könne beispielsweise eine multidimensionale Bildanalyse nicht durchführen, weil er kein CASE-Tool besitze. Aber auch wenn er das CASE-Tool dann hat, kommt er nicht weiter, weil er nicht entsprechend denkt. Er wird nie ein guter Architekt sein, wenn ihm die bildliche Vorstellung fehlt. Aber er wird überall erzählen, er könne deshalb kein guter Architekt sein, weil ihm das CASE-Tool fehle. Wenn ihm nun ein solches Werkzeug gegeben wird, dann ist seine Enttäuschung riesengroß; denn er kann das Tool nicht nutzen. Der Entwickler mag auf anderen Gebieten Stärken haben, aber er wird trotzdem kein guter Systemanalytiker sein, da er nicht multidimensional denken kann. Die traurige Sache bei den CASE-Tools ist, daß die einzigen Entwickler, die gut damit arbeiten, diejenigen sind, die auch ohne sie gut gearbeitet haben.
CW: Welche CASE-Probleme gilt es vorrangig zu lösen?
Tom deMarco: Ich glaube, wir müssen die Aufmerksamkeit mehr auf den Sinn und Nutzen von CASE-Tools in Teams und auf deren Nutzen im Prozeß lenken. Und ganz speziell müssen wir die offensichtlichen mechanischen Probleme lösen. Die frühe Interaktion, die auf Grund der Anwendervorgaben stattfindet, erfordert eine physische Umgruppierung. Wir gehen immer noch davon ans, daß CASE etwas für den Programmierschreibtisch ist, aber dort gehört es - wie gesagt - überhaupt nicht hin.
CW: Wie lassen sich die Erwartungen, die lange Zeit in CASE gesetzt wurden, in eine andere Richtung lenken?
Tom deMarco: Lassen sie mich die Erwartungen zunächst reduzieren! Es ist beileibe nicht so, daß Leute, die mit einer bestimmten Methode nicht klarkommen, diese Methode mit Hilfe eines Tools beherrschen könnten - obwohl einige das behaupten. Die Enttäuschungen bei der CASE-Einführung beruhen zum Teil darauf, daß die Auswirkungen zum Beispiel auf der Dokumentationsseite falsch eingeschätzt werden. Die Anwenderunternehmen realisieren vielfach nicht, daß sie durch die Einführung von Bildern eine Chance haben, ernsthaft ihre Dokumentenflut einzudämmen. Ein Bild ist schnell erstellt; 1000 Worte haben erst formuliert und gedruckt zu werden - das scheint niemand zu sehen.
CW: Dokumentation an sich galt bislang als erstrebenswert. Was stört Sie daran?
Tom deMarco: Die Summe der Dokumentationen wächst zusehends. Es wurde bereits ermittelt, daß Unternehmen mit kommerzieller DV zwischen 22 und 66 Seiten Text je 1000 Codezeilen benötigen. Diese Zahl ist absurd. Natürlich kann CASE uns helfen, diese Dokumentation effektiver zu machen, aber das macht wenig Sinn. Wir haben diese Dokumentationslast zu verringern. Text ist - unglücklicherweise - selten up to date, so daß hier eine trügerische Sicherheit entsteht: Das Produkt ist dokumentiert, aber auf dem Stand des vergangenen Jahres.
CW: Sehen Sie einen Ausweg aus diesem Dilemma?
Tom deMarco: Wir sollten jedenfalls nicht den Fehler machen, dokumentierende Werkzeuge zu stark an CASE-Tools anzubinden. Der Entwickler zeichnet ein Bild, und das Tool beschreibt es mit vielen Worten - beeindruckend, aber was soll das? Früher hatte man wenigstens die Gewißheit, daß der, der die Dokumentation schrieb, sie las. Jetzt aber haben wir eine Situation, wo weder der Verfasser noch der Adressat die Dokumente lesen.
CW: Wo aber schlummern denn die positiven Eigenschaften von CASE?
Tom deMarco: Eine faszinierende Eigenschaft von CASE ist die Möglichkeit, etwas zu entwickeln, das ich "nahtlosen Lebenszyklus" (Seamless Lifecycle) nennen möchte. Nahtlos nenne ich einen Lebenszyklus, in dem es einen kontinuierlich steigenden Grad der Funktionalität eines Systems gibt. Heute haben wir, an der Zeitachse gemessen, einen Spezifikationsprozeß, der zunächst auf 0 Prozent steht und nach gewisser Zeit zu 100 Prozent fertiggestellt ist; das Design folgt demselben Schema. Beide Abläufe kommen vorher nicht oder nur schwer zusammen. Schließlich folgt die Codierung - nach dem nämlichen Muster. Die Alternative ist: Die Spezifikation wächst, und parallel wird zu einem bestimmten Zeitpunkt ein Animationsprozeß - CASE-unterstützt - gestartet, der dem Prototyping ähnelt; dann kommt die tatsächliche Implementierung dazu. Bei diesem Vorgehen kann in jedem Moment festgestellt werden, wieviel Prozent der Spezifikationen erledigt, wieviel als Modell dargestellt und zur Vorlage beim Anwender bereit und wieviel davon schon codiert sind. Das bringt eine wachsende funktionale Kontinuität. Mit CASE kann das erreicht werden. Damit kommen Realität und Modell besser zusammen.
CW: Erfordert dies einen grundsätzlichen Umdenkprozeß bei Erstellern und Anwendern?
Tom deMarco: Hier bin ich positiv überrascht: Die Modelliermethoden, mit denen ich gearbeitet habe, und von denen ich angenommen habe, daß sie nur für einen Bruchteil der Menschen anwendbar sind, sind viel weiter verbreitet als gedacht. Diese Methoden und Strukturen werden fast intuitiv angewendet und nicht formal ausgeprägt dargestellt. Es gibt einen starken Trend hin zu Bildern. Die Anwendergemeinde hat sich zudem drastisch in ihrem Kenntnisstand verändert. Der Entwicklungsprozeß ist Anwendern nicht so fremd wie früher, und der Entwickler selbst ist in die Anwenderwelt hineingewachsen.
CW: Wieso haben wir dann noch nicht Abschied von der oft zitierten Software-Krise genommen?
Tom deMarco: Die Investition, die in ein CASE-Tool gesteckt wird, auch unter Berücksichtigung der indirekten Kosten an Zeit und Geld, ist verhältnismäßig klein im Vergleich zu der, die in die menschliche Arbeitskraft gesteckt wird. Ich bin immer wieder erstaunt, daß Leute es wagen, diese triviale Geldsumme nicht zu investieren. Vielleicht kostet ein Tool ein Zehntel eines Jahresgehaltes. Wenn aber auch nur die geringste Chance besteht, die Produktivität zu erhöhen, finde ich ist es unverständlich, nicht zu investieren.
CW: Wie erklären Sie sich diese Ihrer Ansicht nach unbekümmerte Haltung?
Tom deMarco: Der Grund für diese Haltung - speziell in den USA - ist eine zu starke Ausrichtung auf kurze Zeiträume, auf ein Quartal oder auf ein Jahr. Wir berücksichtigen lange Zeiträume nicht genug - dafür gibt es sicherlich viele Gründe. Einer davon ist der konsequente Druck, immer noch positivere Berichtszahlen und bessere Prozente "nach oben" melden zu müssen. In den USA verweilen die Manager normalerweise auch nicht lange genug in einem Unternehmen.
CW: Welche Probleme schafft die durch CASE verursachte Veränderung gewachsener Arbeitsinhalte?
Tom deMarco: Wovor viele Entwickler sich fürchten, ist die Abschaffung des Programmierers durch ein automatisiertes System. CASE ist jedoch nicht einmal zur Hälfte dafür geeignet, und deshalb wird das auch nicht passieren: Systementwickler sind "Systemausbrüter"; sie lassen sich nicht ersetzen - genausowenig wie Architekten ersetzt werden können. Die konzeptionelle Entwicklung von Systemen ist das Brot der Entwickler, der Rest ist Mechanik: CASE unterstützt den mechanischen Part, es wird nie den menschlichen Teil übernehmen.
Die Rolle des Deus ex Machina bleibt unbesetzt
Unbestätigten Gerüchten zufolge vergleichen die meisten Software-Entwickler die Nützlichkeit sogenannter CASE-Tool mit der eines Kropfes. Hersteller und CASE-Gurus hingegen betonen ohne Unterlaß, wie notwendig automatisierte und exakt dokumentierte Entwurfsverfahren für die Entwicklung bedarfskonformer und pflegeleichter Anwendungen seien. So wenig die Argumente der Anbieter von der Hand zu weisen sind, so wenig kann aber ein Werkzeug für das computerunterstützte Software-Engineering der ihm aufgezwungenen Rolle als Deus ex Machina gerecht werden. Tom deMarco, Vater der "Structured Analysis", bringt es auf den Punkt: Die einzigen Entwickler, die gut mit CASE-Tools arbeiten, sind diejenigen, die auch ohne sie gut gearbeitet haben. Enttäuschen dürfte das nur diejenigen, die vergessen haben, daß das "A" in "CASE" schlicht für "aided" steht. qua