Die derzeit verfügbaren Werkzeuge für das Computer-unterstützte Software-Engineering (CASE) mögen nichts weniger als perfekt sein. Trotzdem sollten sie eingesetzt werden - und zwar bald; denn wer den CASE-Einsatz hinauszögert, läuft Gefahr, den Anschluß zu verpassen.
Ein Durchschnittsprogrammierer in Nordamerika oder Westeuropa kann pro Tag nicht mehr als zehn bis fünfzehn fehlerfreie Programmzeilen erzeugen; die jährliche Steigerungsrate seiner Produktivität beträgt lediglich fünf bis sechs Prozent.
In den USA wird jedes vierte große Systementwicklungsprojekt niemals zu Ende geführt. Diese Projekte hinken nicht etwa nur hinter ihrem Zeitplan her, vielmehr werden sie vollkommen gestrichen. Das typische Softwareprojekt wird mit einem Jahr Verspätung fertig und kostet doppelt soviel wie veranschlagt.
Außerdem haben wir ernsthafte Probleme mit der Softwarequalität: Zwar reserviert der Projektzeitplan normalerweise die Hälfte der Gesamtzeit für Tests und Fehlerbeseitigung, doch sind die Ergebnisse meist alles andere als zufriedenstellend. Typischerweise enthält ein Softwaresystem, wenn es an den Kunden ausgeliefert wird also nach den Tests, immer noch drei bis fünf Fehler je 100 Programmzeilen.
Die Chancen der Software-Ingenieure, einen Fehler zu eruieren, haben sich als ziemlich schlecht herausgestellt. Beim ersten Versuch beträgt die Trefferquote kaum 50 Prozent, und wenn grundlegende Veränderungen am Programm vorgenommen werden müssen, sinkt sie auf etwa 20 Prozent.
Die Produktivität der Software-Entwicklung variiert von Programmierer zu Programmierer um den Faktor 25. Das heißt, einige Entwickler sind 25mal produktiver als andere. Und es gibt keine Korrelation zwischen der Produktivität und den Berufsjahren oder den bei Eignungstests erzielten Punkten.
Wie können wir also eine höhere Softwarequalität und -produktivität erreichen? Die wichtigste Lösung für dieses Problem heißt CASE, wobei dieser Begriff ein ganzes Konglomerat verschiedener Techniken umfaßt.
Die niederen und die höheren Weihen
Die automatisierten Werkzeuge für die Unterstützung von Codierung, Tests und Fehlerbeseitigung zähle ich zu den niederen CASE-Tools. Sie sind seit den 60er Jahren verfügbar, werden allerdings erst seit kurzem CASE-Tools genannt.
Daß die Tests, die bis zu 50 Prozent der Projekt-Ressourcen in Anspruch nehmen, soviel Zeit verschlingen, liegt daran, daß wir schlechte Arbeit bei der Systemanalyse und beim Design leisten. Wir können natürlich die automatisierten Werkzeuge für das Testen verbessern, aber eine einfachere Lösung wäre es, zunächst die Analyse und das Design in Angriff zu nehmen.
Und hier kommen wir zu den höheren CASE-Tools: Das sind automatisierte Werkzeuge, die Unterstützung bei der System-Analyse und beim System-Design gewähren. Auch unter der Bezeichnung Frontend-Tools bekannt, werden diese Werkzeuge in den ersten Phasen eines Projekts eingesetzt.
Solche Tools sind ausgesprochen wichtig; denn mit unzureichenden, zweideutigen oder verworrenen Benutzeranforderungen werden auch die besten Codier- und Test-Techniken wahrscheinlich niemals zu einem qualitativ hochwertigen System führen (vielmehr werden sie Ihnen höchstens dabei helfen, schneller als zuvor in die Katastrophe zu schlittern).
In der Tat haben wir innerhalb der vergangenen 20 Jahre feststellen können, daß etwa die Hälfte der Fehler, die in einem System stecken, und 80 Prozent der Kosten, die deren Beseitigung verschlingen, auf Mißverständnisse oder Irrtümer zwischen Anwender oder Kunde einerseits und Systemanalytiker andererseits zurückzuführen sind. Diese Mißverständnisse und Irrtümer entstehen bereits in der Phase der Anforderungsdefinition. Demnach ist es also genau dieser Bereich, den wir uns vornehmen müssen.
Die CASE-Industrie ist noch ziemlich jung; die meisten ihrer Produkte sind allenfalls drei Jahre alt.
Nur ein ganz kleiner Prozentsatz der System-Analytiker und -Designer in Europa und Nordamerika setzen derzeit CASE-Tools ein, schätzungsweise fünf bis zehn Prozent. Aber jetzt schon wollen die Software-lngenieure mehr Funktionalität, als sie augenblicklich bekommen können.
Mangelhafte CASE-Tools sind besser als keine
Doch auch wenn die heute verfügbaren CASE-Produkte keineswegs perfekt sind und oft an Funktionalität zu wünschen übrig lassen, so sind sie doch brauchbar. Das heißt, sie sind wesentlich besser als gar nichts.
Wenn Ihnen also Ihre technischen Mitarbeiter erzählen wollen, die heutigen CASE-Produkte seien noch nicht gut genug, sollten Sie ihnen erwidern, daß sie auf jeden Fall besser sind als gar keine Unterstützung.
Die meisten CASE-Produkte, die heute auf dem Markt sind, kosten zwischen 1000 und 10 000 US-Dollar pro Anwender. In den kommenden zwei oder drei Jahren wird dieser
Preis dramatisch sinken, nämlich auf etwa 200 Dollar.
Es ist gerade ein halbes Jahr her, daß in den USA das erste "Shareware"-CASE-Produkt auftauchte. Dabei handelt es sich um ein CASE-Werkzeug, das von einem Electronic-Bulletin-Board-Systemen auf den PC heruntergeladen werden kann - für ganze 85 Dollar. Dies ist möglicherweise nicht das perfekteste CASE-Produkt, aber es ist unbestritten das wirtschaftlichste.
Die Zukunft gehört den netztauglichen Werkzeugen
Daneben wird es ebenso dramatische Verbesserungen im Netzbereich geben. Die CASE-Werkzeuge mögen ganz nützlich für kleine individuelle Projekte sein, aber sie sind vor allem in großen Projekten notwendig, wo Hunderte von Software-Ingenieuren zusammenarbeiten.
Wir brauchen LANs, WANs und Data-Dictionaries auf der Projektebene, kurz: eine ganze Palette von Techniken zur Unterstützung großer Mitarbeitergruppen, die gemeinsam an einem umfangreichen Softwaresystem arbeiten. Langsam, aber sicher erscheinen solche Features auf der Bildfläche.
Darüber hinaus gibt es einen Bedarf für Projekt-Management-Unterstützung. Der Projekt-Manager braucht eigene CASE-Tools und eine eigene Workstation; mit deren Hilfe kann er Kosten- und Zeitpläne aktualisieren und abschätzen, wann die Software-Entwickler ihre individuellen Produkte beendet haben werden.
Wahrscheinlich die bedeutendste Eigenschaft, die die nächste Generation von CASE-Produkten aufweisen wird, ist die Annäherung an eine offene Architektur. Wenn Ihre technischen Mitarbeiter ein CASE-Produkt anschaffen, dann wollen sie mit einfachen Mitteln die Verbindung zu anderen Produktivitätswerkzeugen herstellen: zu Code-Generatoren, Projekt-Management-Werkzeugen, Software-Metrik-Paketen und vielleicht auch zu den CASE-Produkten, die Sie im vergangenen Jahr angeschafft haben.
Amerikaner und Europäer oder Japaner nähern sich dem CASE-Bereich auf unterschiedliche Art und Weise. Die meisten US-Unternehmen suchen eine sogenannte Bottom-up-Integration von verschiedenen Stand-alone-Werkzeugen, die zum Teil bereits entwickelt sind.
Außerdem tendieren die Amerikaner dazu, ihre CASE-Tools am unteren Ende ihrer Organisationsstruktur einzuführen - also nicht unbedingt mit Unterstützung des Top-Managements. Diese Vorgehensweise ermöglicht viel Kreativität, birgt aber die Gefahr der Anarchie.
Andere Anbieter, vor allem in Europa und Japan, verfolgen hingegen einen Top-down-orientierten Ansatz für das Design einer komplett integrierten CASE-Umgebung. Diese Methode dauert länger, verspricht aber längerfristig mehr Erfolg.
Das Schlüsselproblem, das gelöst werden muß, ist das des Technologie-Transfers. Schon immer gehörte es zu den schwierigsten Dingen überhaupt, neue Techniken, neue Ideen und neue Konzepte in eine bestehende Organisation einzuführen. Doch wird dieser Technologie Transfer von einigen bedeutenden Forschern in den USA und in Europa auch als Chance betrachtet, Wettbewerbsvorteile gegenüber anderen Ländern wie Japan zu erlangen.
CASE zielt auf möglichst lange SW-Lebenszyklen
Ich möchte Ihnen also dringend empfehlen, mit der Implementierung von CASE-Techniken sofort zu beginnen; denn Sie werden drei bis fünf Jahre brauchen, bis Ihr Unternehmen in der Lage ist, die nächste Produktgeneration einzusetzen, die sich bereits ankündigt. Sie stehen am Anfang eines langen und schwierigen Prozesses, der Sie dahin bringen wird, wo Sie - auf Dauer gesehen - hinkommen sollten, nämlich dahin, Software zu bauen, die mindestens ein Jahrhundert lang Bestand hat.