Verglichen mit den unrealistisch hohen Erwartungen der Anwender ist der praktische Nutzen des Software-Engineering relativ gering. Deshalb behaupten viele Programmierer, solche Methoden seien ungeeignet oder unpraktikabel, und suchen weiter nach einem anderen Allheilmittel. Zu diesem Denken gelangen nach Meinung von Harry Sneed* allerdings nur diejenigen, die das Verfahren nicht wirklich verstanden oder nie richtig angewandt haben.
Viele jener Anwender, die Software-Engineering so schnell abqualifiziert haben, um sich neuen, verheißungsvollen Ideen zu widmen, haben es entweder nicht wirklich verstanden oder nie richtig angewandt. In der Tat sind es nur wenige Anwenderbetriebe, die Software-Engineering praktisch einsetzen - dafür aber fast alle Hersteller und Software-Häuser.
Laienprogrammierer fangen mit Engineering nichts an
Dieser Zustand ist kennzeichnend. Denn "Software-Engineering" heißt professionelle Software-Entwicklung durch professionelle Software-Ingenieure, und gerade diese fehlen bei den meisten Anwenderbetrieben. Für die Laienprogrammierer, die den größten Teil der Anwendungs-Software entwickeln, ist und bleibt Software-Engineering ein Fremdwort, mit dem sie nicht allzu viel anfangen können. Wesentlich ist, daß sich der praktische Nutzen des Software-Engineering nur dann messen läßt, wenn diese Methode auch tatsächlich angewandt wird.
Jede Änderung, sei es eine neue Organisationsform oder eine neue Technologie, muß an ihren Zielen gemessen werden. Ziel des Softwareengineering ist es, die Produktivität und Qualität der Software-Entwicklung und -Wartung zu steigern. Aber hier fängt das Problem schon an, denn wenn weder Produktivität noch Qualität meßbar sind, läßt sich auch keine Steigerung nachweisen. Bei anderen Ingenieurdisziplinen kann leichter ermittelt werden, ob die Einführung neuer Techniken die Stückzahl und/oder die Produktqualität verbessert.
Nicht so beim Software-Engineering. Trotz zahlreicher Ansätze, die Software-Produktivität zu quantifizieren, zum Beispiel als
- Code-Zeilen,
- Anweisungen,
- Dokumentenseiten,
- Komponenten (Module, Datenkapseln),
- Funktion-Points (Ein-/Ausgabe-Schnittstellen),
- Datenflüsse,
- Ablaufzweige und
- Benutzerschnittstellen,
gibt es noch keine wissenschaftlich anerkannten Maßstäbe. Denn alle bisherigen Richtlinien haben sich als unzureichend erwiesen. Der Umfang der geistigen Substanz, die man "Software" nennt, läßt sich nicht messen, sie bleibt unfaßbar.
Noch schlimmer sieht es bei der Software-Qualität aus. Hier mangelt es auch nicht an Ansätzen, einzelne Qualitätsmerkmale zu definieren. Zu den allgemein bekannten zählen unter anderem die Benutzerfreundlichkeit, Zuverlässigkeit, Sicherheit, Effizienz, Wartbarkeit und Ausbaufähigkeit sowie die Übertragbarkeit.
Für jedes dieser Hauptmerkmale gibt es eine Reihe von Untermerkmalen, und für diese wiederum verschiedene Software-Metriken Einige davon wie die von McCabe Halstead, Chapin, Belady, Basili und Gilb, haben sich in der wissenschaftlichen Informatik etabliert. In einer Dissertation an der Technischen Universität Berlin faßte Dr. Horst Zuse 1985 sämtliche Metriken zusammen. Monika Schmitt von der GMD brachte ebenfalls eine Studie. In den Vereinigten Staaten hat sich das Software-Engineering-Labor von Professor Victor Basili ausschließlich diesem Thema gewidmet. Und schließlich verabschiedete die IEEE Computer Society (IEEE = International of Electrical and Electronic Engineers) eine Reihe von Normen. Dennoch sind diese Normen und Metriken in der Praxis kaum bekannt. Es herrscht nach wie vor völlige Verwirrung über die Qualität von Software. Wir sind noch weit davon entfernt, einheitliche Begriffe, geschweige denn einheitliche Maßstäbe für diesen Bereich zu verwenden. Infolgedessen bleibt die Beurteilung der Software-Qualität eine rein subjektive Angelegenheit.
Wenn also weder Produktivität noch Qualität meßbar sind, wie soll dann der praktische Nutzen von Software-Engineering wissenschaftlich nachgewiesen werden? Unwissenschaftliche und unqualifizierte Meinungen gibt es zur Genüge. Der eine behauptet, zum Beispiel, daß Software-Engineering ihm etwas gebracht hat, der andere das Gegenteil. Beide können recht haben.
Schon bei den Definitionen beginnt das Durcheinander
Abgesehen von den Schwierigkeiten, den Nutzen festzustellen, gibt es auch Probleme bei der Definition Viele Anwender meinen, wenn sie Struktogramme zeichnen oder einen Pseudo-Code erstellen, praktizieren sie schon Software-Engineering. Dieses Verfahren deckt jedoch alles ab angefangen von der Anforderungsanalyse bis hin zur Systemabnahme. Der Programmentwurf ist nur ein winziger Teil. Am besten ist es, sich bei der Definition an die IEEE-Normen zu halten. Danach gliedert sich die Disziplin in folgende Teilgebiete:
- Projektmanagement,
- Anforderungs-Spezifikation,
- System- und Programmentwurf,
- Programmierung,
- Unit-Test,
- Systemtest,
- Qualitätssicherung,
- Konfigurationsverwaltung und
- Systemwartung.
Jedes dieser Teilgebiete hat seine eigenen Methoden und Techniken beziehungsweise Sprachen. Für die Anforderungsspezifikation gibt es zum Beispiel die Structured-Analysis- und die Jackson-Systems-Design-Methode, das Warnier/Orr-Verfahren und das Entity/Relationship-Prinzip sowie die Spezifikationssprachen VDM, PSL, HOS und SETL - um nur einige von vielen zu nennen. Wesentlich ist, daß die Anwender überhaupt eine Spezifikationsmethode und -sprache anwenden, um ihre Fachkonzepte zu erstellen. Das gleiche gilt für den System- und Programmentwurf. Hier existieren wiederum zahlreiche Methoden wie die von Yourdon/Constantine, Jackson, Warnier Parnas und Nassi-Shneiderman. Hinzu kommen die vielen Entwurfstechniken wie PDL, Pseudo-Code, Struktogramme, Aktionsdiagramme und Warnier/Orr-Diagramme. Der Anwender muß auch hier eine Entwurfsmethode verfolgen und darf nicht einfach losprogrammieren.
Wenn man also Software-Engineering in seiner vollen Breite betrachtet, einschließlich der Methoden und Techniken des Testens, der Wartung und der Konfigurations-Verwaltung, dann ist festzustellen, daß kaum ein Anwender dieses Verfahren im weiteren Sinne einsetzt, sondern nur Bruchteile davon. Vom Nutzen insgesamt kann also nur begrenzt die Rede sein. Es wird allerdings, zum Beispiel von der IBM Federal Systems Division in den USA und der Bertelsmann Datenverarbeitung in der Bundesrepublik Deutschland, anhand von praktischen Beispielen behauptet, daß Software-Engineering in vollem Umfang die Kosten der Entwicklung senkt, Termine eingehalten werden und die Software-Qualität steigt. Ob dies auf Software-Engineering oder auf andere personelle und organisatorische Faktoren zurückzuführen ist, bleibt allerdings angesichts der vielen gegenseitigen Abhängigkeiten unklar.
Der Nutzen einzelner Methoden und Techniken läßt sich dagegen eher ermitteln. So wurde in vielen Fällen die Restfehlerrate durch systematische Tests mit Hilfe von maschinell gespeicherten Testfällen und im Hinblick auf wohldefinierte Deckungsgrade reduziert. Diese Erfahrung ist in mehreren Ländern dokumentiert worden. Daß aber der systematische Test zu höheren Kosten führt, bleibt ebenfalls unbestritten. Andererseits hat eine bestimmte Programm-Entwurfsmethode oft leichter test- und wartbare Programme hervorgebracht. Auch dies ist in der Fachliteratur vieler Länder bestätigt worden. Ob dadurch die Entwicklungskosten gestiegen sind, ist allerdings nicht immer erkennbar. Eines ist klar: Strukturierte, modulare und normierte Programme sind leichter zu testen, zu pflegen und zu transportieren. Darüber gibt es inzwischen keine Diskussionen mehr.
Die Frage, ob solche Programme wirklich leichter zu erstellen sind, ist jedoch noch nicht geklärt. Hier teilen sich die Meinungen. Es gibt eben Leute, die strukturiert denken, und andere, die es nicht können. Den erstgenannten fällt es leicht, in dieser Weise zu programmieren, den letzteren schwer. Werden diese gezwungen, strukturiert und modular zu programmieren, steigen die Kosten der Entwicklung, und das Ergebnis ihrer Arbeit wird nicht unbedingt besser. Es kann sogar schlechter werden. Dies untermauert eine weitere These: Software-Engineering kann kein Ersatz für unqualifiziertes Personal sein.
Der Nutzen ist nur schwer nachzuweisen
Je weiter man sich vom eigentlichen Programm entfernt, desto schwieriger wird es, den Nutzen nachzuweisen. So ist er bei einem formal spezifizierten, vollständigen und konsistenten Fachkonzept kaum zu quantifizieren. Möglicherweise reduzieren sich die Kosten der Systementwicklung und -wartung, und die Qualität des Endproduktes steigt. Die Verfechter formaler Methoden behaupten dies jedenfalls, die Gegner bestreiten es. Um also eine qualifizierte Aussage treffen zu können, muß mehr Erfahrung mit solchen formalen Spezifikationsmethoden gewonnen werden. Das gleiche trifft in noch stärkerem Maße auf die Anforderungsanalyse zu. Hier ist der Nutzen nur in Zusammenhang mit dem gesamten Vorgehensmodell zu ermitteln.
Aus den hervorgehenden Aussagen folgen zwei Modelle für die Nutzwertanalyse des Software-Engineering: ein Makro- und ein Mikro-Modell.
Das Mikro-Modell ist anzuwenden, um den Nutzen einzelner Methoden und Techniken zu erfassen. Um eine bestimmte Programmiertechnik zu beurteilen, kann der Test- und Pflegeaufwand vor und nach Anwendung der neuen Technik verglichen werden. Geht es um die Testtechnik, gilt Analoges für die Fehlerrate. Es wäre also im Prinzip relativ einfach, den Nutzen nachzuweisen, doch wird dieses Verfahren leider oft aus Rücksicht auf die beteiligten Mitarbeiter nicht angewandt.
Meßlatte für SW-Qualität muß normiert werden
Das Mikro-Modell dient dazu, den Nutzen eines gesamten Entwicklungsverfahrens zu erfassen. Hier sind die Kosten der Entwicklung und Wartung vor und nach Einsatz des neuen Verfahrens zu vergleichen. Es empfiehlt sich, in diesem Sinne auch weiterhin die Software-Qualität zu berücksichtigen. Voraussetzungen hierfür sind jedoch normierte Qualitätsmerkmale und Maßstäbe.
Einige Unternehmen wie die IBM Federal Systems Division, Hitachi Software Engineering und die Bertelsmann Datenverarbeitung haben diese Methode angewandt und die Ergebnisse verglichen. Insgesamt gibt es aber weltweit viel zuwenig Betriebe, die Software-Engineering in voller Breite einsetzen, um eine statische, relevante Aussage über den Gesamtnutzen treffen zu können.
Die Tatsache, daß die Anzahl immer noch so gering ist, ist weniger auf die Kritik am Software-Engineering, sondern auf die Unternehmen selbst zurückzuführen. Die DV-Führungsschicht steht nämlich der Einführung dieses Verfahrens eher skeptisch gegenüber. Viele Software-Manager wissen, daß das Personal den Herausforderungen nicht gewachsen ist, und sind nicht bereit, es umzuschulen. Andere hingegen sind selber keine Techniker und haben Angst vor technischen Erneuerungen. Die dritte Gruppe hat wiederum ihre Sporen als freischaffende Künstler in der Programmierung hinterlassen und zeigt wenig Verständnis für ein diszipliniertes ingenieurmäßiges Verfahren. Fest steht, daß allen die Kosten zu hoch, die Risiken zu groß sind und der Nutzen zweifelhaft erscheint. Sie würden lieber warten, bis er einwandfrei erwiesen ist. Daß dies noch sehr lange dauern kann, geht aus dem niedrigen Stand der Meßtechnik hervor.
Aus diesem Grund wird Softwareengineering hauptsächlich bei DV-Herstellern und Softwarehäusern angewandt. Sie verfügen über eine jüngere, technisch orientierte Führung und stehen unter mehr Leistungsdruck. Für die führenden professionellen Systemhersteller der Welt gibt es zum Software-Engineering keine Alternative. Sie zweifeln außerdem nicht am Nutzen, auch wenn er nicht statistisch nachweisbar ist. Wer in den Fachkreisen der internationalen Informatik behaupten würde, Software-Engineering sei unnütz, würde mit Sicherheit eine Welle allgemeiner Entrüstung auslösen. Auf einem Benutzertreffen deutscher Anwender-Unternehmen hätte diese These sicherlich viel Zustimmung erhalten. Dies zeigt, wie weit die Welten der professionellen Software-Entwickler und der Anwendungs-Amateure auseinanderliegen.
Die Frage nach dem Nutzen des Software-Engineering ist aus diesem Grund nicht ohne Qualifizierung beantwortbar. Für einen Anwenderbetrieb, bei dem es weder auf die Produktivität noch auf die Qualität der Software ankommt, ist der Nutzen zweifelhaft und sicherlich im Verhältnis zu den Kosten gering. Für ein professionelles Software-Unternehmen, dessen Existenz von der Produktivität und Qualität abhängt, ist der Nutzen unbestritten und rechtfertigt auch sämtliche Unkosten der Einführung.
Nicht jede Anwendung ingenieurmäßig entwickeln
Mit großer Wahrscheinlichkeit wird niemand in 20 Jahren einem Prozeßsteuerungs-, einem Flugsteuerungs- oder einem Platzbuchungssystem trauen, das nicht mit den Methoden und Techniken des Softwareengineering entwickelt und getestet wurde. Sehr wohl werden sich diese Unternehmen aber mit PC-Anwendungen, Berichtssystemen und Adhoc-Anwendungs-Programmen abfinden, deren Entwickler vom Software-Engineering keine Ahnung haben und nicht haben wollen. Software ist eben nicht gleich Software und nicht jede Anwendung muß ingenieurmäßig hergestellt werden.