Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

21.11.1980

Ein Volk von Ignoranten

21.11.1980

Dipl.-Phys. Wolfgang Zinke, Insotec Beratungsgesellschaft für Software-Technologie m.b.H" München

Nach der Lektüre des Sneedschen Gastkommentars "Ein Volk von Programmierern (CW 44 vom 31. Oktober 1980) drückt es mich, etwas zum Thema "Software-Engineering" zu sagen. Meiner Meinung nach gehen nämlich die Schlußfolgerungen Harry M. Snees ein gutes Stück an der Wahrheit vorbei.

Natürlich gibt es zuwenig Programmierer. Aber wenn man diesen Mangel einfach dadurch kurieren will, daß man mehr Programmierer ausbildet, ist das etwa genauso, wie wenn konstatiert wird, wir haben zuwenig Erdöl und jemand verkündet daraufhin die Lösung, auf die bisher alle ratlos gewartet haben: Wir müssen mehr Erdöl fördern.

So geht es natürlich nicht. Es wurde auch genügend darüber nachgedacht, warum wir zuwenig Programmierer haben. Schließlich ist das nur ein Aspekt der vielbesprochenen Softwarekrise.

Bevor wir große Summen ausgeben, um das vermeintlich unausweichliche Schicksal, ein ganzes Volk zu Programmierern auszubilden, auf uns nehmen, sollten wir einen Moment nachdenken und fragen: Warum besteht denn dieser Mangel? Und siehe da, die Antwort stellt sich ganz von selbst ein: Wir brauchen so viele Programmierer, weil wir eine so schlechte Software haben! Die Tatsache, daß heutige Datenverarbeitungssysteme oft unbefriedigend aus vielerlei Sicht sind, wurde in den letzten Jahren in zahlreichen Kongressen, Tagungen und Seminaren beklagt und in der Literatur umfassend abgehandelt. Als Hauptgründe für die Unzufriedenheit stellen sich dar:

- Die Programme funktionieren nicht so, wie erwartet; oft liefern sie Ergebnisse, mit denen der Benutzer nach den ihm vorliegenden Beschreibungen überhaupt nicht rechnen kann.

- Der Aufwand für die Entwicklung und die Wartung von Datenverarbeitungssystemen liegt weit höher als erahnt.

So viele Programmierer werden vor allem wegen des hohen Wartungsaufwandes gebraucht. In vielen Fällen schreibt man Programme lieber neu, wenn etwa wegen veränderten Voraussetzungen Änderungen vorzunehmen sind, als bestehende zu modifizieren. Warum ist das so? Programme sind oft so unverständlich, daß nach einiger Zeit sich nicht mal der Autor mehr darin zurechtfindet. Die Kosten für die Wartung von Software können über 50mal höher als die für ihre Entwicklung liegen, wie Boehm in seinem Beitrag "The High Cost of Software" feststellte (Proc. of a Symposion, NTIS, Monterey 1973).

Heutiges Programmieren ist zu vergleichen mit der Methode, mit der im Altertum gebaut wurde: Weitgehend ohne Planung und durch Ausprobieren von Lösungen ging man vor. Damals wurde hingenommen, daß ein Bauwerk in einem langwierigen, evolutionären Prozeß entstand.

Daß Verbesserungen nötig sind, bestreitet allgemein niemand. Jedoch setzt Sneed an der falschen Ecke an, wenn er sagt, wir brauchen nur ein paar schöne Werkzeuge, dann gehe alles von selbst.

Uns fehlen in erster Linie Methoden im Software-Entwurf, ein fest umrissenes Vorgehen in der Planung und Dokumentation von Datenverarbeitungssystemen wie in anderen Ingenieurdisziplinen auch. Diese Einsicht hat sich noch nicht recht durchgesetzt. Dabei gibt es einige wissenschaftlich gesicherte Verfahren, die ein ingenieurmäßiges Planen durchaus unterstützen:

- die strukturierte Programmierung für die Planung von Abläufen;

- das lineare Datenbankmodell zur Darstellung von Daten;

- die Jackson-Methode für die Verknüpfung von Abläufen mit Daten;

- die Petri-Netz-Methode zur Darstellung von Wechselwirkungen zwischen Abläufen.

Hier ist eine Unterstützung durch Werkzeuge zu begrüßen. Man denke nur an den Erstellungs- und Änderungsaufwand von Nassi-Shneiderman-Struktogrammen. Ein Struktogrammgenerator leistet wertvolle Dienste.

Dagegen sind Werkzeuge von der Art, die nur das Spektrum der Programmiermöglichkeiten einschränken - etwa Prograrmmgeneratoren - kaum hilfreich. Sie haben oft den Nebeneffekt, nur bei Einhaltung vielfältiger Konventionen einsetzbar zu sein. Die Effizienz des Computers schränken sie ein.

Sneeds Vergleich des Programmierers mit dem Autofahren geht meiner Meinung nach völlig daneben. Ein Programm ist ein Produkt. Die Erstellung eines Programmsystems ist eine Ingenieurleistung wie die Konstruktion eines Autos. Sie hat mit Autofahren nichts zu tun. Mit dem Autofahrer kann höchstens der Operator verglichen werden.

Ein Software-Ingenieur braucht einen hohen Grad an Abstraktionsvermögen, damit er ein DV-Modell als Abbild der zu programmierenden Arbeitsgänge entwerfen kann. Es reicht nicht aus, Leute in der Handhabung einer Programmiersprache recht und schlecht auszubilden und ihnen ein paar Tools aufs Auge zu drücken. Man kann Programmieren nicht vereinfachen, weil die zu programmierenden Probleme nicht einfach sind! Ein paar Beispiele aus heutiger Praxis:

- Online-Systeme mit konkurrierendem Zugriff auf Daten;

- Organisation einer Datennbank über ein Rechnernetz;

- Fehlertoleranz in Anwendungssystemen durch programmierte Error recovery.

Ein Computer ist ein Wirt schaftsgut, kein Spielzeug, auch wenn er Kinder zu faszinieren vermag. Hoffentlich bleibt uns er spart, daß wir als ein Volk von Programmierern unsere Kräfte da mit vergeuden, immer und immer wieder die gleichen Aufgaben in Form von Computerprogrammen zu lösen - nur weil der eine nicht versteht, was der andere gemach hat.

Hoffentlich geht aber auch der Kelch an uns vorbei, daß ein Voll von Ignoranten immer wieder von den wahren Problemen ablenke und irgendwo ein Stück vom Paradies verheißt, wenn man nur ihre Produkte kauft.