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.

27.02.1981

Linientaxi statt Omnibus und Individualverkehrsmittel

27.02.1981

Johann F. Jauk, Österreichische, Unilever und TU Wien

In der COMPUTERWOCHE Nr. 44/80 vom 31. Oktober 1980 stellt Harry M. Sneed unter dem Titel "Ein Volk von Programmierern" als Reaktion auf die große Nachfrage an Programmierern in Europa und den USA die These auf, daß eine weitere Ausbildung zu Programmierern nicht zielführend sei, da, egal wie viele Programmierer auch ausgebildet wurden, niemals so viele vorhanden sein könnten, wie es Aufgaben zu programmieren gäbe. Vielmehr gehe es in Zukunft darum, die Programmentwicklung an den Endbenutzer zu delegieren.

Fast keine geistigen Anforderungen

So provokant diese Behauptung auf den ersten Blick erscheinen mag, bei näherer Betrachtung gewinnt sie an Bedeutung. Beobachtet man im Zeitraum 1970 bis 1980 die Zahlen der im EDV-Bereich eines Unternehmens und insbesondere in der Softwareentwicklung beschäftigten Personen, so läßt sich ein enormes exponentielles Anwachsen diese Werte erkennen. Extrapoliert man diesen Trend auf die nächsten zwanzig Jahre, so wird man feststellen, daß innerhalb dieser Zeit mehr als die Hälfte der Beschäftigten eines Unternehmens Softwareentwickler, also "Programmierer" sein werden. Zwar wird es nie Millionen Programmierer im heutigen Sinne geben, aber für jeden installierten Computer und für jedes installierte Terminal wird es eine Reihe von Beschäftigten geben, die sie bedienen und programmieren können. Dies ist jedoch nur dann möglich, wenn die Softwareentwicklung so einfach geworden ist, daß sie (fast) keine geistigen Anforderungen an die "Softwarehersteller" stellt. Ein Vergleich mit einer gänzlich anders gelagerten Entwicklung soll diese Aussagen noch bekräftigen, Nachdem das Telephon erfunden wurde, hat im Jahre 1910 die Bell Telephon-Gesellschaft in den USA ähnliche Überlegungen angestellt. Eine damals durchgeführte Hochrechnung ließ erwarten, daß nach Aufbau des Telephonnetzes bald mehr als die Hälfte der Bevölkerung der USA den Beruf eines Telephonvermittlers ausüben werde.

Diese damals sehr angezweifelte Voraussage ist auch eingetreten, nur daß jeder Fernsprechteilnehmer durch die technische Vereinfachung bei der "Vermittlung" (= Wählen) ausschließlich seine eigenen Gespräche vermittelt.

Somit stimme ich mit Harry M. Sneed überein. Unsere Auffassungen trennen sich jedoch dort, wo es um die Realisierung der Vereinfachung in der Softwareentwicklung geht. Sieht Sneed die Lösung des Problems ausschließlich in der "Entzauberung" der individuellen Programmierung, so halte ich es für wesentlich zielführender, eine "Standardisierung im Kleinen" anzustreben.

Dabei möchte ich auf das Beispiel von Omnibus und Individualverkehrsmittel aus dem Artikel von Sneed zurückgreifen und auf eine dritte Möglichkeit aufmerksam machen. Das Fahren mit dem Omnibus läßt sich gut mit dem Einsatz von Standardprogrammen vergleichen und hat dieselben Vor- und Nachteile. Der Bus ist zwar ein relativ sicheres Massenverkehrsmittel (getestetes Standardprogramm für mehrere Benutzer), jedoch hat er eine fixe Streckenführung und wird nur in den seltensten Fällen genau dort halten, wo das Ziel des Benützers liegt, das heißt, das Programm wird fast nie in allen Punkten den Benutzeranforderungen entsprechen.

Das Fahren mit dem Privatauto ist zwar risikoreicher und wird auch immer teurer (steigende Benzinkosten beziehungsweise Programmierergehälter), jedoch kommt man in der Regel viel näher an sein eigentliches Ziel (Programm entspricht eher den Benutzeranforderungen), obwohl durch Parkplatzmangel ( Kommunikationsprobleme zwischen Benutzer und Programmierer) oder Parkverbote (technische Mängel in den Programmiersprachen) auch dieses oft nicht ganz erreicht wird. Außerdem ist das Autofahren selbst mit einem (manchmal anstrengenden) Arbeitsvorgang verbunden.

Als dritte Möglichkeit möchte ich ein Verkehrsmittel (Softwareentwicklungsmedium) vorstellen, welches die Vorteile des Omnibusses (Standardprogramm) und die des Individualverkehrsmittels (eigene Programmierung) kombiniert, ohne jedoch auch all deren Nachteile in Kauf nehmen zu müssen - nämlich das Linientaxi, welches an beliebigen Stellen seiner Route angehalten werden kann. Dieses ist zwar ebenfalls streckenweise von mehreren Personen benutzbar, wird wegen seiner fixen Linienführung den Benützer in der Regel auch kaum ganz genau an sein Ziel bringen, jedoch durch seine jederzeitige Anhaltemöglichkeit wesentlich näher als ein Omnibus. Es ist jedoch risikoärmer und auf lange Sicht gesehen billiger und weniger anstrengend als das Fahren mit dem Privatkraftfahrzeug. Lediglich die Auswahl und Angabe der Aussteigstelle ist dem Fahrgast überlassen.

Übertragen auf die Softwareentwicklung bedeutet dies: Der Benutzer hat die Möglichkeit, aus einer für bestimmte Sachgebiete existierenden Menge von getesteten Standardprogrammteilen (Modulen), diejenigen auszuwählen und nach gewissen Regeln zu kombinieren, die ein Programm zusammensetzen, welches seinen persönlichen Anforderungen möglichst nahekommt. Die Menge derartiger Standardprogrammteile bezeichne ich als "Modulsystem" . Unter einem kommerziellen Modulsystem ist ein für einen Teilbereich eines Unternehmens (Rechnungswesen, Beschaffung und Lagerhaltung, Personalwesen, Fertigung, Vertrieb,... ) geschaffenes Bausteinsystem zu verstehen, welches, nach gewissen Regeln konstruiert, es jedem Benutzer ermöglichen soll, mit geringem Aufwand ein seinen Wünschen nahekommendes, möglichst individuelles Softwarepaket zu erzeugen.

In einer wissenschaftlichen Arbeit am Institut für angewandte Informatik der Technischen Universität Wien ist man derzeit damit beschäftigt, die theoretischen und praktischen Voraussetzungen zu erarbeiten, welche den Einsatz von Modulsystemen ermöglichen. Dazu ist es notwendig, neben der Schaffung eines Modulbausatzes Regeln anzugeben, welche die Auswahl, Kombinierbarkeit, Schnittstellen der Modulen, Beziehungen und funktionale Abhängigkeit zwischen den Modulen, sowie den maximale/minimale Umfang des Systems steuern. Die Entwicklung eines algorithmischen Fragensystems ermöglicht es dem Benutzer durch interaktive Beantwortung von Fragen das für ihn passende Softwaresystem auszuwählen. Dabei wird durch jede Benutzerantwort das Modulsystem auf ein anderes den Benutzerwünsches näherkommendes Modulsystem eingeengt.

Via Fragenkatalog programmieren

Nach Durchlaufen des ganzen Fragenkataloges ergibt sich ein ausführbares Programm, welches den Wünschen des Benutzers weitestgehend entspricht. Auf diese Weise kann jeder Angestellte eines Unternehmens auf einfache Weise sein eigenes Programm "programmieren", womit sich die zu Beginn des Artikels aufgestellten Behauptungen bewahrheitet hätten.

Die Beschäftigung mit Modulsystemen, gepaart mit der in letzter Zeit vermehrten Entwicklung gut anwendbarer Programmierwerkzeuge lassen mich optimistisch in die Zukunft der Softwareentwicklung blicken.

Informationen: Johann F. Jauk, Kampstraße 6/1 1/ 1/2, A-1200 Wien.