Das Kostenverhältnis HardwareSoftware entwickelt sich zuungunsten der Software:

Schluß machen mit den Scheinargumenten

23.09.1977

Für eine gegebene Problemlösung in der EDV-Anwendung entwickelt sich das Kostenverhältnis Hardware/Software immer mehr zu Ungunsten der Software. Diese Aussage ist ebenso wahr wie trivial. Wie rapide sich dieses Verhältnis ändert, ist nur wenigen Anwendern bewußt, da sieh das Mietvolumen bei der Hardware im Regelfall durch umfangreiche Erweiterungen konstant hält und somit die erhebliche Preisreduzierung der Hardware nicht unmittelbar sichtbar wird. Ermessen kann man es am besten an den Kaufpreisen der Minicomputer, wo Systeme von einem Leistungsvermögen, das vor einigen Jahren noch ein Mietvolumen in der Größenordnung von monatlich 100 000 Mark ausmachte, heute schon für weniger als eine halbe Million zu kaufen sind.

Dagegen stehen bei der Softwareentwicklung

- kontinuierlich steigende Personalkosten

- abnehmende relative Produktivität (je Mann/Tag)

- abnehmende Produktivkapazität (durch Steigerung von Wartung und Verwaltung).

Stellt man die Trends einander gegenüber, so erkennt man auf der einen Seite eine rasante technologische Entwicklung, die sich alle Möglichkeiten der ingenieurmäßigen und nahezu vollautomatischen Produktion zu eigen macht, auf der anderen Seite keineswegs ingenieurmäßige, ja nicht einmal handwerklich zu nennende (denn selbst der rückständigste Handwerker hat eh Arsenal von Hilfsmitteln und Werkzeugen) Anstrengungen, deren Qualität in einem anderen Felde als der Datenverarbeitung selbst von Hobbybastlern als amateurhaft eingestuft würden.

Neidvoll schaut man den Hardware-Ingenieuren über die Schulter und beklagt das in manchen Situationen gänzliche Fehlen an historisch gewachsenen, wissenschaftlich fundierten Formalismen und Vorgehensweisen, an denen man sich orientieren und gleichzeitig sicher sein kann, keine elementaren Fehler begangen zu haben.

Dabei ist die Lösung bekannt und unumstritten. Sie liegt in dem Medium, dem alle EDV-Leute ihren Beruf verdanken und das sie anderen täglich zur Lösung derer Probleme anbieten: dem Computer. Sie lautet: Erhöhung der Produktivität durch Automation und Wiederverwendung durch Verbesserung der Kommunikation und Transparenz der Systeme, durch vollständige Dokumentation, Personenunabhängigkeit und höhere Sicherheit. Kurzum: Einsatz von Werkzeugen - auch Tools genannt - eine Vorgehensweise, die sich pauschal unter dem Begriff "System-Engineering" zusammenfassen läßt.

Woran liegt es nun, daß diese allgemein bekannten Möglichkeiten nicht wahrgenommen werden? Ist es der Perfektionismus der EDV-Leute, die sagen, solange nicht alles automatisiert werden kann, lassen wir es lieber (eine Pervertierung des "Alles-oder-Nichts-Gesetzes")? Oder das Realitätsbewußtsein, das IBM mit "Immer Besser Manuell" übersetzt und die Probleme der Computernutzung dem Anwender, dem Laien überläßt? Ist es vielleicht der Altruismus, nachdem der Schneider bekanntlich die schlechtesten Hosen besitzt, weil er vor lauter Aufopferung für andere nicht an sich denkt? Ist es das Laisser-faire oder die Bürokratenhaltung: "Das haben wir schon immer so gemacht"? Oder letztlich und endlich ein Machtdenken ß la Parkinson, nach dem mit dem zwangsläufigen Anwachsen des Programmierstabes auch ein ebenso zwangsläufiges Aufrücken (vielleicht in den Vorstand und damit "weg von den Bits") verbunden ist?

Mit Unterstellungen all dieser Art tut man dem geplagten EDV-Chef sicherlich unrecht. Zweifellos ist dieser überfordert, wenn er sich auch noch um die Erstellung von Software-Werkzeugen kümmern soll, und das mit einer Mannschaft, die zumindest für so komplexe Aufgaben überfordert ist. Und der Ruf nach dem Hersteller oder den Universitäten, sich dieser Probleme anzunehmen (wie zuletzt auf dem Hamburger Anwendergespräch: "Computergestützte Methoden zur Entwicklung kommerzieller Programmsysteme" vielstimmig artikuliert), ist zumindest subjektiv ehrlich und verständlich.

Im Teufelskreis der Alltagsprobleme

Andererseits muß festgestellt werden, daß vielerorts diese Probleme sträflich vernachlässigt oder zumindest stiefmütterlich behandelt worden sind. Während man zum einen gern mit Hardware-Statistiken glänzt und Auslastungskoeffizienten im Knopfloch vor sich her trägt, zieht man zum anderen beim Thema Produktivität der Systementwicklung oder Einhaltung von Projektterminen den Kopf ein. Hier dient als Alibi das Methodenhandbuch, von dem es genügt, daß es irgendwo im Regal steht. Darin kann (wer will, der kann!) man dann schwarz auf weiß nachlesen, wie etwas gemacht werden soll. Erfahrungsgemäß sind diese Elaborate meist älteren Datums (sie regeln dann, daß im Assembler Stern-Adressierung und Befehlsmodifikation verboten sind), sie setzen tief auf (man spricht von Programmen, das versteht jeder, die Systemtheorie ist "außen vor"), sie sind entweder sehr allgemein gehalten ("unter Umständen", "sollte", "gegebenenfalls") oder so restriktiv, daß jeder Anfangsprogrammierer schnell nachweisen kann, daß solche Regelung für seine Situation nicht anwendbar ist. Worauf nach dem "Alles-oder-Nichts"-Gesetz... (siehe oben).

Soviel zu den Scheinargumenten. Es gibt sicherlich auch objektive Gründe, die einem Einsatz von Hilfsmitteln im Wege stehen; das sind die Arbeitsbelastung, die unproduktive Phasen, wie eine Einführung von neuen Methoden, Verfahren, Techniken es nun einmal sind, nicht erlauben; das ist die Individualität von Programmierern, die sich ungern an Standards gewöhnen; es sind schließlich schlechte Erfahrungen mit früheren Software-Tools, die günstigenfalls Ernüchterung erzeugten, aber wenig Software.

All diese Aspekte sind aber nur auf der ersten Blick schlüssig; aus dem Teufelskreis "zuviel Arbeit - keine Zeit für Innovationen" kann man nur mit Gewalt ausbrechen; auch der verschrobenste Programmierer wird einmal begreifen müssen, daß ein Verharren auf antiquierten Ansichten auch seinen Weg in die Zukunft verstellt; und schlechte Erfahrungen der Vergangenheit sollten kein Anlaß sein, nicht neue Ansätze zu suchen und zu überprüfen.

Scheinargument des "Rien-ne-va-Plus"

Denn wer die Entwicklung der letzten Jahre verfolgt hat, wird festgestellt haben, daß man durchaus nennenswerte Fortschritte gemacht hat in der Entwicklung von Tools:

- Eine neue Technologie, die den Assembler bei der Realisierung von Werkzeugen ablöste und eine erhebliche Verbesserung in Portabilität, Anpassung und Weiterentwicklungspotential erbringt

- Grundlegende methodische Ansätze, die den Anforderungen komplexer Strukturen, Online-Programmierung und Unterstützung von allen Zugriffsformen durchaus gerecht werden

- Bessere Berücksichtigung der Situation des Anwenders (bestehende Standards und Normen können übernommen werden, kein "Nimm-mich-so-wie-ich-bin")

- Unterstützung einer situationsangepaßten Einführung des Systems (Einführungsstrategien, die bei den schwächsten Punkten oder den dringlichsten Problemen ansetzen und eine schrittweise Einführung der Werkzeuge ermöglichen)

- Abstellung der benutzten Techniken auf moderne Ansätze der Software-Technologie (Top-down-Approach, CPO-Organisation).

Berücksichtigt man alle diese Punkte, so ist es schwer zu begreifen warum die Einführung bereits bewährter Werkzeuge mit dieser Ausstattung so geringe Resonanz findet. Letztlich ist es doch wieder der Anwender, der initiativ werden und sieh von seinen Alltagsproblemen lösen muß, um den erwünschten Fortschritt zu bewirken. Denn die Befreiung aus dem Teufelskreis der Alltagsprobleme wird nicht dadurch erfolgen, daß man eines Tages unversehens im Paradies des allumfassenden Super-Tools aufwacht. Vielmehr kann eine realistische und praktikable Fortentwicklung nur so aussehen, daß man schrittweise die verfügbaren Lösungen nachvollzieht.

Ein Weg, der sicherlich mehr Hinwendung, Konzentration und Anstrengungen erfordert, der aber die Gewißheit birgt, nicht eines Tages von einer wachsenden Bugwelle der Wartung erschlagen zu werden.

Zusammenfassend kann man dem Anwender nur raten, nicht auf das wundersame Totalsystem bis zum St. Nimmerleinstag zu warten, sondern aus diesem Teufelskreis auszubrechen und sich der verfügbaren Tools zu bedienen, um nicht übermorgen Programme warten zu müssen, die mit der Methodik von vorgestern erstellt wurden. Auf eines sollte er jedoch achten: Das Hilfsmittel sollte auch nicht von gestern sein, sondern auf einer softwaretechnologischen Konzeption aufbauen, die deutlich in die Zukunft gerichtet ist.

* Die Autoren sind Mitarbeiter der GMO-Gesellschaft für Moderne Organisationsverfahren mbH &r Co. KG, Hamburg