Günther Lattwein Geschäftsführer der Renker Daten KG

Der Instruktor schwärmte: "Mit dieser Programmiersprache kann der Sachbearbeiter in der Fachabteilung sein Problem ohne Spezialwissen selbst formulieren, denn er schreibt Klartext, zum Beispiel: "IF AMOUNT IS GREATER THAN l000, THEN ..."

Das war zu Beginn der 60er Jahre, und der Instruktor sprach über Cobol. Er nannte Cobol eine höhere Programmiersprache, weil sie rein problemorientiert war, das heißt unabhängig von der verwendeten Hardware.

Common Business Oriented Language war eine Sprache, die die niederen maschinenorientierten Assemblersprachen ablösen und den Programmierer in die Lage versetzen sollte, ohne Kenntnisse der maschineninternen Vorgänge seine, Programme zu schreiben. Cobol war damit herstellerunabhängig.

Vergleichen wir die Hardware-Ausrüstung unserer Rechenzentren der frühen 60er Jahre mit unserer heutigen Ausrüstung, so müssen wir anerkennend feststellen, daß die Hersteller Großes geleistet haben.

Doch was ist mit der Software? Die Statistiken sind alarmierend. Auf bis zu 90 Prozent der gesamten EDV-Kosten schätzt man den Anteil der Software-Kosten in der Mitte der 80er Jahre. Mehr als 80 Prozent davon entfallen auf die Wartung bestehender Programme. Vor 20 Jahren war das Verhältnis genau umgekehrt. Alle Welt spricht erneut von einer Software-Krise, und die COMPUTERWOCHE stellte erst im August auf ihrer Titelseite fest, daß es für diese Krise kein Patentrezept gibt. Wenn schon kein Patentrezept, dann sollten wir wenigstens die Ursachen untersuchen.

Die offensichtliche Ursache dieser Krise ist, daß die Software-Entwicklung mit der Hardware-Entwicklung nicht Schritt gehalten hat. Dies kann daran liegen, daß unsere Anforderungen zu hoch sind, oder daß zu wenig in die Software-Entwicklung investiert wird. Setzen wir die Anforderungen als gegeben voraus, so müssen wir mehr in die Entwicklung investieren.

Software wird von Fachkräften entwickelt. Wir brauchen also mehr oder bessere Fachkräfte. Wenn wir bei der Qualifikation von Fachkräften eine Gaußsche Normalverteilung voraussetzen, so wird die Zahl der verfügbaren Kräfte umso kleiner, je höher wir das Qualifikationsniveau ansetzen. Durch intensive Schulung kann hier eine begrenzte Verbesserung erzielt werden, jedoch würde ein Teil der Verbesserung durch den Zeitaufwand für die Schulung wieder kompensiert werden.

Wir können also praktisch das Fachkräfte-Potential als gegeben voraussetzen; das heißt andererseits, daß uns nur die Möglichkeit bleibt, das Qualifikationsniveau durch die Auswahl geeigneter Werkzeuge und Verfahren soweit abzusenken, bis wir die erforderliche Anzahl von Fachkräften verfügbar haben.

Die Entwicklung solcher Werkzeuge, Cobol wäre ein Beispiel, war bisher größtenteils eine Domäne der Hersteller von Computer-Hardware. Ist also dort bisher zu wenig in die Entwicklung von Software investiert worden? Ein Blick in die Entwicklungszentren verneint diese Frage sofort angesichts der Heerscharen von Fachkräften, die dort Software produzieren. Sind diese Fachkräfte unqualifiziert oder falsch geführt? Jeder der einmal Einblick in eine solche Produktionsstätte genommen hat, wird auch diese Frage sofort verneinen.

Fragen wir einmal einen Anwender, was er von der idealen höheren Programmiersprache erwartet. Er wird sagen: "Die Programmiersprache muß kurzfristige Ergebnisse mit optimalen Lauf- und Wartungseigenschaften bringen." Kurzfristige Ergebnisse, das heißt: leicht erlernbar, unabhängig von Hardware und anderen Software-Komponenten, geringe Anforderung an die Qualifikation des Programmierers, wenig Codier- und Testaufwand. Gute Laufeigenschaften, das heißt schnelle Laufzeiten und kurze Antwortzeiten bei geringstmöglichem Hardware-Einsatz. Gute Wartungseigenschaften, das heißt möglichst detailliert strukturierte Anwendungen. Durchführung von organisatorischen Änderungen ohne Mehrfachkompilierung ist dann Cobol noch eine höhere Programmiersprache?

Würde ich von einem Hersteller den Auftrag erhalten, eine Programmiersprache zu entwickeln, die seine Interessen in den Vordergrund stellt, so würde ich das Ziel etwa so formulieren: "Die Programmiersprache muß den Anwender an die Hardware binden, den Preisverfall kompensieren und neue Märkte schaffen."

Das heißt: möglichst nicht ohne herstellerinterne Schulung erlernbar, möglichst fest verbunden mit der Hardware oder anderen Komponenten der herstellereigenen Software. So hohe Anforderung an die Qualifikation des Programmierers, daß die besten Kräfte des Anwenders durch die Entwicklung vordringlicher Anwendungen gebunden werden und dadurch keine Zeit finden, durch entsprechende Maßnahmen die Strategie des Herstellers zu durchkreuzen. Hoher Codieraufwand ist nicht unbedingt von Nachteil, weil durch die Erhöhung der Fehlerwahrscheinlichkeit häufigere Testlaufe erforderlich werden, die eine bessere Systemauslastung zur Folge haben. Steuerung der Laufeigenschaften des Programms durch die Basissoftware, um eventuelle spätere Leistungssteigerungen des Systems noch korrigieren zu können.

Lange Laufzeiten oder Antwortzeiten, um zu gegebenem Zeitpunkt Argumente für eine Hardware-Aufstockung bereit zu haben.

Durch die Wartung von Insellösungen, und jedes mit heutigen Mitteln geschriebene Programm ist eine solche, muß die Auslastung der Systeme noch auf Jahre hinaus gesichert werden, und sei es nur für den Eigenbedarf der EDV-Abteilung. Da all dies auf Cobol zutrifft, ist Cobol aus der Sicht des Herstellers eine höhere Programmiersprache.

Gute Hardware-Umsätze wären folglich ohne die Entwicklung von Compilern sehr viel schlechter zu realisieren. Schwierig wird das ganze nur, wenn irgendwann der Punkt erreicht wird, an dem die Fachabteilungen ihre Arbeiten wieder manuell verrichten, weil der Computer mit sich selbst beschäftigt ist, das er für betriebswirtschaftliche Anwendungen keine Zeit mehr hat. Falls die Hersteller für diesen Fall noch keine Lösung im Schließfach haben sollten wir überlegen, was dann zu tun ist.

Zunächst einmal sollte die Entwicklung von Software-Tools nicht ein Monopol der Hardware-Hersteller sein. Diese Werkzeuge können ebensogut von Anwendern entwickelt werden, die meist der Praxis etwas näher stehen, als der Informatiker im Labor ohne Felderfahrung. Die Programmiersprachen müssen einfach, wirtschaftlich und hardwareunabhängig sein.

Die Sprachen müssen nach zehn Jahren endlich der Dialogverarbeitung angepaßt werden. Sie müssen die Möglichkeit bieten, Anwendungen (nicht Programme!) zu strukturieren, das heißt, die Strukturierung muß zur Ausführungszeit erfolgen. Es genügt nicht, die Daten zu strukturieren. Ein Programm besteht aus Daten und Instruktionen, das bedeutet die Verknüpfungsmethode muß Bestandteil der Struktur sein.

Von alledem scheinen die heutigen Programmiersprachen noch weit entfernt zu sein.

Aber auch der Anwender muß endlich erkennen, wo die Ursache der Krise liegt, und daß er sehr viel zu ihrer Lösung beitragen kann, wenn er nicht kritiklos das hinnimmt, was ihm als besonderer Service verkauft oder gar geschenkt wird.

Der Schritt zu dieser Erkenntnis ist schwierig, weil die Orientierung fehlt. Wer will schon den mündigen Anwender? Der Anwender wird geködert mit umfangreichen Software-Paketen die eine Menge Serviceleistungen beinhalten - manchmal etwas mehr, als eigentlich gebraucht werden - und sehr preiswert sind. Manchmal sogar kostenlos.

Wie sagte Laokoon? "Ich fürchte die Danaer, besonders wenn sie Geschenke bringen." Seine Landsleute waren anderer Meinung ... und gingen unter.