Von Fortran zu Software-Entwicklungsumgebungen#

Von

Gerhard Chroust (Johannes Kepler Universität Linz)

1. Mein Weg zur Informatik#

Ich begann 1959 mit dem Studium der Nachrichtentechnik an der Technischen Universität Wien (damals Technische Hochschule). Damals konnte man auch parallel einen 'Kurs für Moderne Rechentechnik' belegen, bei dem es um Computertechnik ging: den Begriff 'Informatik' gab es damals noch nicht!

v.l.n.r.: Rick Rabiser, Hanspeter Mössenböck, Heinz Zemanek und Gerhard Chroust

Der damalige Informatikrechner (die Universität hatte einen eigenen) war eine IBM 650 mit einem Magnettrommelspeicher. Die Vorträge im Kurs waren sehr interessant, das Thema faszinierend und neu, besonders ein juneer Univ.-Dozent Heinz Zemanek, bei dem ich alle angebotenen Lehrveranstaltungen belegte. Damals ging es um Grundbegriffe des Computers und relativ primitive Assemblersprachen. Meine Diplomarbeit (Chroust-64) war eigentlich auch ein Computer-Prgeramm: die Implementierung des Spieles TIC-TAC-TOE, aber den Automaten habe ich noch in konventioneller Schaltkreistechnik mit Transistoren implementiert. Nach Abschluss meines Studiums eine ich auf ein Jahr zu dem (damals sehr bekannten) Prof. Saul Gorn an der University of Pennsylvania in Philadelphia. USA. Mit Faszination lernte ich dort schon die nächste Computer-Generation kennen: die IBM 7090, die zweite Generation nach der IBM 650. Für mich war es eine Maschine mit unglaublicher Mächtigkeit. In Philadelohia lernte ich die wesentlichen Grundlagen der Informatik, die bis zu einem gewissen Grad noch heute meine Weltsicht prägen: Logik, höhere Programmiersprachen (FORTRAN, LISP, IPL-V etc.). Besonders IPL-V war (damals) ein Meilenstein, da ich mit Hilfe dieser Sprache ein Programm zum Finden und Beweisen von Sätzen der Aussagenlogik entwickelte (Chroust-65). Als komplettes Museumsstück konnte ich an dieser Universität - in einer Ecke, relativ unbeachtet und verstaubt - auch die ENI-AC bestaunen.

2. Fernziele der Informatik: Unabhängigkeit#

Der Computer wurde aus dem Wunsch nach Automation von Rechenvorgängen geboren, wobei die Automatentheorie und die Logik eine große Rolle spielte. Eines der bahnbrechenden, damals auch faszinierenden Konzept wurde von Saul Gorn Ende der 50-er Jahre formuliert. Es war die soeenannte 'unstratified control' (Gorn-61b): Man kann Computer-Instruktionen als Daten behandeln und bearbeiten, um sie dann als Instruktionen wieder in den Computer einzugeben. Dieses Konzept war bei der ENIAC noch nicht vorhanden. Erst dieses Konzept ermöglicht prmzipiell den Bau von Compilern und anderen Generatoren. Es war somit die Grundlage der Programmiersprachen.

Bei der Entwicklung von Software, kann man 4 Fernziele bezüglich Sprachunabhängiekeit der (Programmmier-)lösung identifizieren (Salomon-92):

• unabhängig von Hardware
• unabhängig vom Problemtypus
• unabhängig von menschlicher Variabilität
• unabhängig von zeitlicher Evolution (d.h. Weiterentwicklung und Wartung)

Die Entwicklung der Programmiersprachen in der damaligen Zeitepoche spiegelt diese Fernziele wider. Eines nach dem anderen wurde in Angriff genommen.

Ausdruckskraft: Als erstes musste die Ausdruckskraft der Programmiersprachen soweit erhöht werden, dass man - ohne Rücksicht auf die Hardware - das Problem genügend genau, problem-orientiert und nicht zu hardwarenahe ausdrücken konnte. Damit verbunden war die Frage der Übersetzbarkeit. Es begann eine phantastische Entwicklung der Programmiersprachen (ALGOL. ALGOL68. etc.) (Landin-66) (Nicholls-75) (Sammet-62).

Übersetzbarkeit: Die Theorie der Übersetzung (Compiler-Theorie) war und ist eines theoretisch am besten erforschte Gebiete der Informatik (Aho-72) (Gries-71) (Moessenboeck-001) (Rechen-berg-93). Auch meine eigene Dissertation beschäftigte sich mit einem Teilgebiet des Compilerbaus (Chroust-74c) (Chroust-03e). Diese Thema sollte mich später auch nicht loslassen: Bei der Entwicklung des PL/I-Compilers für die IBM 8100, ca. 1978, konnte ich viele dieser Erfahrungen einbringen.

Code-Effizienz: Besonders die Zeitabhängigkeit der Compiler von der Größe und Art des Ipout-Programms war eine Herausforderung. Dies wurde besonders deutlich, als IBM daran dachte, das Flaggschiff von IBM's Programmiersprachen (PL/I) auf die aufkommenden, deutlich weniger mächtigen Personal Computer zu migrieren - im Endeffekt mit wenig Erfolg.

Speichereffizienz: Der Mangel an schnellem Speichern war eines der großen Dilemmas der damaligen Zeit. Compiler mussten in viele Phasen zerlegt werden, die nacheinander eine Reihe von Transformations- und Bearbeitungsschritte des Originaltextes durchführen. Es gab bemerkenswerte Lösungsansätze. So erinnere ich mich noch (eher mit Schrecken) an die Overlay Feature von Fortran: eine im Programm nicht sauber festgelegte) Zahl von Speicherzellen auf Byte Basis) war allen laufenden Programmen und Unterprogrammen gemeinsam und konnte durch Darüberlegen von Variablen beliebig von den Programmen verwendet werden - ohne Rücksicht auf Wortgrenzen der Variablen - eine wahre Fundgrube für Programmierfehler. Ein Albtraum für Programmierer und ein Traum für jeden Malware-Hacker - aber die gab es ja damals mangels an Vernetzung noch nicht! Und der Datenaustausch zwischen Computern erfolgte vorzugsweise mit Lochkarten (!) als externer Speicher und zur Datenübermittlung.

3. Computer-Architekturen - IBM System /360#

• Die Gestaltung einer tragfähigen, zukunftsorientierten Computer-Architektur
• eine Technik die es 'relativ' einfach gestattete, verschiedene Computer-Architekturen auf einer gegebenen Hardware zu implementieren.

Für das zweite Problem bot sich die damals aufkommende Mikroprogrammiertechnik an. Unter Mikroprogramm versteht man eine programmierte Zwischenschicht zwischen der eigentlichen Hardware (Transistoren, Halbleiter etc.) und einer Schicht, die dem Benutzer als 'Schnittstelle zum Computer', eben als Computer-Architektur in Erscheinung tritt (Abb. I) Wieder zeigt sich in der Informatik eine Synergie zwischen verschiedenen Teildisziplinen: ohne das Konzept der Mikroprogrammierung wären verschiedene Computer-Architekturen nicht möglich gewesen. Glücklicherweise war die Hardware-Technologie inzwischen soweit fortgeschritten, dass der durch die eingeschobene Zwischenschicht hervorgerufene Performanceverlust problemlos ausgeglichen werden konnte. Als zweiter wesentlichen Faktor wirkte der ökonomische Druck nach zukunftsorientierter Architektur (ohne lästige Umprogrammierung) der die Investitionen in ein derartiges Konzept auch wirtschaftlich vertretbar machte: IBM kreierte das sogenannte System /360.

Abbildung l: Systemhierarchie

Auf der persönlichen Seite gab es auch noch eine Synergie. Die neue Technik der Mikroprogrammierung fand großes Interesse bei Prof. Arno Schulz, damals Professor für Software an der Kepler Universität. Es wurde ein aus der Benutzerebene mikroprogrammierbarer 'Informatikrechner' (H angeschafft, wo wir aus der höheren Prperammiersprache PL/I heraus Änderungen der Computer-Architektur vornahmen und theoretisch untersuchten. Die Institute von Prof. Arno Schulz und Prof. Jörg Mühlbacher waren damit zu meiner wissenschaftlichen Heimat geworden Und mit den theoretischen Fragen der Mikroprogrammierune habilitierte ich mich einige Jahre später (Chroust-79f).

Auch das Problem der Gestaltung der Computer-Architektur wurde von IBM bravourös gemeistert, dank eines Teams von drei hervorragenden Wissenschaftlern: Gene Amdahl, Gerrit Blaauw und Fred Brooks (Amdahl-64): Die damals konzipierte Computer-Architektur gilt - mit einigen Erweiterungen - nach heute als ein Ouasi-Standard.

In der Folge wurden auch mehrstufige hierarchische Schemata mit mehreren Ebenen von Mikroprogrammen entwickelt. Beim IBM System 32 - dem Vorläufer der sehr weit verbreiteten IBM AS 400 - wurden sie sogar praktisch eingesetzt.

4. Höhere Programmiersprachen#

Die ersten Programmiersprachen entstanden aus der Notwendigkeit, die Programmierung der Computer problemnäher und menschenfreundlicher zu gestatten, oft mit wenig theoretischer Überlegungen (die ja selbst erst erarbeitet werden mussten). Auch die Programmiersprache C ist ja nicht gerade ein theoretisch sauberes Produkt. Die Universitäten versäumten es damals, leider, stärkeren Einfluss auf die Praxis zu nehmen.

Später erreichte die Forschung über Programmiersprachen aber einen Höhepunkt, besonders in der Syntaxanalyse und im Parsing wurden wissenschaftliche Spitzenleistungen in der Theoretischen Informatik erbracht.

4.1 Gelöste Probleme - Compiler#

Beim Compilerbau traten eine Reihe von Problemen auf. die aber heutzutage gelöst sind.

Parser: Ein Parser (Von englisch parse. d.h. "zerlegen", bzw. von lateinisch pars. d.h. "Teil") ist ein Computerprogramm, das die Zerlegung eines Programms in seine Teile, die Identifizierung ihres Typs, die Analyse ihres logischen Zusammenhanges, und schließlich seine Umwandlung in ein für die Code-Generierung brauchbares, strukturiertes Format bewirkt. Häufig werden Parser eingesetzt, um im Anschluss an den Analysevorgang die Semantik der Eingabe zu erschließen und daraufhin Aktionen durchzuführen. Hier wurden hochinteressante theoretische und auch praktisch verwertbare Ergebnisse geliefert (Moessenboeck-00) (Moessenboeck-02) (Rechenberg-93).

Allgemeine Code-Effizienz: Die ursprüngliche Befürchtung, dass der computererzeugte Code schlechter als handcodierte sei. wurde schnell zerstreut, besonders durch die großen Fortschritte der Compilertechnologie.

Register-Zuordnung (allocation): Ein besonderes Problem stellte die temporäre Speicherung des Wertes von Variablen in den nur in geringer Zahl vorhandenen schnellen Registern dar: den

Wert welcher Variable soll man für welche Zeit in welchem Register halten? Register-Zuordnung war ein Schlüssel für eine zeiteffiziente Durchführung. Eine größere Zahl von Dissertanden schaffte es, genügend viele und gute Algorithmen dafür zu erfinden.

Verzweigungsvorhersage, Sprünge: Ein ähnliches Problem war die Berechnung von Sprungadressen, besonders von Vorwärtssprüngen. d.h. zu potentiellem Code, der noch nicht generiert war. Je nach 'Weite' des Sprunges hatte dies Auswirkungen auf die zu wählende Instruktion, damit auf die Codelänge und damit auf die Werte anderer Sprungadressen.

Unterprogramme / Parameterübergabe: Unterprogramme wurden schon sehr früh als Mittel zur Strukturierung und Wiederverwendung eingesetzt. Die Übergabe von Parametern (bv value, bv reference) war ein großer Diskussionspunkt und auch schwierig zu verstehen und damit auch schwierig zu lehren.

Blockkonzept / Gültigkeit von Variablennamen: ALGOL führte als Mittel zur Strukturierung von Programmen das sogenannte Block-Konzept ein, eine Abgrenzung eines Teilprogramms innerhalb des ganzen Programmes (z.B. durch 'begin' ... 'end'). Es war vorgesehen, dass Blöcke, ähnlich wie Unterprogramme, unabhängig von einander geschrieben werden können (und ohne Wissen über die Variablennamen). Damit entstand aber das Problem, wie man Variable mit gleichen Namen aber anderweitiger Verwendung derselben unterscheiden konnte. Zahlreiche technische Lösungen wurden dazu erfunden.

4.2 Teilweise gelöst: Code-Generierung#

Weniger erfolgreich, weil weniger Interesse hervorrufend, war die Theorie der eigentlichen Code-Generierung. Zu jedem durch den Parser identifizierten Teilstück eine Programm muss der Compiler entsprechenden Code erzeugen. Dazu besitzt der Compiler eine Reihe von Mustern (man spricht von 'Code-Skeletten'), nach denen der Code generiert wird (man würde heute 'pattern' sagen). Je mehr und je variiertere Code-Skelette ein Compiler besitzt, umso effizienter wird das Laufzeitverhalten des übersetzten Programms, aber auch umso aufwendiger ist die Compiler-Entwicklung und üblicherweise umso langsamer ist der Compiler. Da dieses Gebiet wissenschaftlich nicht attraktiv erschien wurde es etwas links liegengelassen. Doch hat sich das Problem von selbst weitgehend gelöst, da die Geschwindigkeit der heutigen Hardware extreme Verfeinerungen auf dem Gebiet der Code-Generierung nicht mehr so dringend benötigt. Geschwindigkeitserhöhungen können heute mit anderen Mitteln erreicht werden, durch die Hardware selbst, durch Parallelismus in der Hardware und durch Parallelismus in Programmen.

4.3 Bestehende Herausforderungen, Probleme, Theorie#

Als noch immer bestehende Herausforderungen kann man heute sehen:

Problemnähe der Programmiersprachen: Hier gibt es gewaltige Fortschritte, doch dazu werden die nachfolgenden Redner Stellung beziehen.

Höhe der Zwischensprache: Zwischen Programmiersprache und eigentlicher Hardware werden eine oder mehrere Zwischensprachen eingeschoben. Auch hier sind noch weitere Erkenntnisse zu erwarten.

Wiederverwendung: Dies ist eines der Schlüsselprobleme. Nur durch Wiederverwendung kann die heute notwendige Produktivität (und bis zu einem gewissen Maß auch die Qualität) erreicht werden. Frameworks, Obiekt-Orientierung und komponentenbasierte Entwicklung sind hier Meilensteine. Auch die Frage des Model Driven Develpment (d.h. der mehr oder minder automatischen Ableitung des lauffähigen Programms vom (formalisierten) Entwurf) wird noch viele Theoretiker und Praktiker beschäftigen.

Wartbarkeit: Das Jahr 2000 und die Euro-Umstellung haben auch den Nicht-Informatikern die Bedeutung, die Schwierigkeiten und die Notwendigkeiten von wartungsfreundlicher Software vor Augen geführt. Glücklicherweise bieten die unter Wiederverwendung angeführten Methoden und Konzepte auch dafür Lösungen.

Automatische Umsetzung eines Entwurf: Schon James Martin (Martin-81) (Martin-89a) hatte die Vision, dass man von einem Entwurf ohne menschliches Zutun den Code generieren müsste. Leider fehlen hier doch noch wesentliche Erkenntnisse bis dieses Konzept im großen Stil erfolgreich eingesetzt werden kann.

4.4 Spezialsprachen#

IPL-V: Diese Sprache wurde von Forschern auf dem Gebiet der Artificial Intelligence, von Herbert Simon und J.C. Shaw, zwischen 1950 und 1958 entwickelt, um Probleme des 'General Problem Solving' zu lösen. Diese Art der Programmierung war für mich vollkommen neu: Die Sprache besaß Listen, Assoziationen, Schemata ('frames') dynamische Zuordnung und Verwaltung von Speicherplätzen für Variable, Datentypen, Rekursion, assoziative Suche etc. Man konnte Funktionen als Parameter mitgeben und es gab kooperatives Multi-Tasking. Allan Newell agierte bei der Entwicklung als Sprachexperte und Anwendungsrprogrammierer. J.C. Shaw war der Systemrprogrammierer und H. Simon hatte die Rolle des Anwendungsrprogrammierers.

In IPL wurden mehrere Programme auf dem Gebiet der Artificial Intelligence programmiert, u.a. die Logic Theory Machine (1956), der General Problem Solver (1957) und das Schachspielprogramm NSS (1958). Ich programmierte in IPL-V den praktischen Teil meiner Dissertation (Chroust-65).

FORMAC: Ähnlich faszinierend war FORMAC, eine Formel-Manipulationsspracheauf der Basis von FORTRAN. Man konnte Formeln automatisch umformen, vereinfachen etc. und schlussendlich ausrechnen, ein sehr frühes MATHEMATICA.

APL: Ebenso faszinierend war APL, von Ken Iverson erfunden. Es war eine Sprache, die schon sehr früh komplexe Matrizenoperationen erlaubte. Dazu wurden neue Operatoren, wie z.B. inneres und äußeres Matrix-Produkt, eingeführt. Diese Operatoren wurden mit griechischen Buchstaben bezeichnet, mit dem Erfolg, dass man eine spezielle Tastatur mit diesen griechischen Buchstaben verwenden musste. Dafür erlaubte APL eine äußerst kompakte Darstellung von Funktionen, es gab sogar Wettbewerbe, wer die mächtigste Funktion als Einzeiler schreiben konnte. Sicher eine Herausforderung für manchen Programmierer, aber im Sinne von Software-Engineering ein Irrweg - Verständlichkeit und Wartbarkeit waren gleich null.

Ich gehörte u.a. auch zu den erfolgreichen Anwendern, da im Rahmen einer Taskforce die IBM ermitteln wollte, wo ein einziges zentrales Rechenlabor in Europa zu platzieren sei. Da alle Datenverarbeitung aller europäischen Labors in diesem einen Zentrum erfolgen sollte, waren natürlich Netzwerk-Kosten ein wesentlicher Faktor: ein ideales Anwendungsgebiet für eine Matrix-Bearbeitungssprache.

Proliferation der Programmiersprachen: Die Erfolge der frühen Hochsprachen, aber auch Unzufriedenheit mit der Ausdruckskraft und/oder Problemnähe (oder was Informatiker dafür hielten) ließ unter dem Motto 'Jedem Informatiker seine eigene Sprache' eine Unzahl von Hochsprachen aus dem 'Boden wachsen', was von [Landin-66] in seinem Artikel 'The next 700 Programming laneuaees' angeprangert wurde.

PL/I - der Dinosaurier: Gleichzeitig trat auf dem kommerziellen Sektor der Wunsch nach Vereinheitlichung stärker hervor. IBM beschloss (als Parallele und Ergänzung zur einheitlichen Computerfamilie System /360) eine einheitliche Programmiersprache für alle Anwendungen zu entwickeln. Bis dato war FORTRAN für numerisch/technische Anwendungen, COBOL für kommerzielle Anwendungen, und ALGOL für wissenschaftliche Anwendungen ausersehen.

Die neue Sprache sollte auf FORTRAN aufsetzen und die Vorteile aller drei Vorgänger umfassen: FORTRAN, COBOL und ALGOL. Es war das spätere PL/I, aber das ist ein eigenes Kapitel.

Nach anfänglichen größeren Erfolgen zeigten sich einige Nachteile von PL/I die schließlich die Sprache wieder aus dem Markt drängten. Die Show-Stopper waren: die Größe der Sprache benötigte mächtige Computer (und leistungsfähige Maschinen). Eine Subset-Bildung (z.B. für die damals bereits aufkommenden PCs) war nicht ohne weiteres möglich. Im Eifer, alles bisher Dagewesene zu überdecken hatte PL/I zahlreiche redundante und überlappende Konzerne. Auch war die uneingeschränkte (automatische) Konversion zwischen Datentyoen eher ein Anlass für unbemerkte Fehler und weniger eine Annehmlichkeit für die Programmierer.

Auch an PL/I bewahrheitete sich ein alter Spruch: "Eine Summe von kleinen Annehmlichkeiten kann eine große Unannehmlichkeit werden".

5. Beschreibung der Semantik von Programmiersprachen - Vienna Definition Language#

Für das IBM Labor hatte aber PL/I noch eine andere Bedeutung, die bereits von Prof. Zemanek angesprochen wurde: ein Proiekt, die Semantik (d.h. die Bedeutung in all ihren Facetten) einer großen, kommerziellen Programmiersprache (nämlich PL/I) mathematisch zu erfassen. Zu Beginn des Projektes lag die Spezifikation von PL/I nur als natürlichsprachiger Text vor. ein typisches Programmiersprachenhandbuch, aber noch nicht endgültig festgeschrieben. Das ganze IBM Labor arbeitete an dieser Aufgabe. Die Resultate waren:

• Eine gründlichere Analyse der verschiedenen Konstrukte von PL/I, besonders deren Zusammensüiel. Dies Arbeit musste mit der sogenannten 'Laneuaee Definition Grouo' in Hurslev. England, abgestimmt werden und brachte auch einige logische Verbesserungen der Sprache.

• Eine Methode, wie man die Semantik einer Programmiersprache beschreiben konnte [Lucas-69] [Wegner-72]
• Ein umfangreiches Dokument (mehrere 100 Seiten!) [PLI-66] [PLI-69], das die Bedeutung von PL/I in mathematischer Notation beschrieb.

Mir fiel dabei die Aufgabe zu, die Auswertung arithmetischer und logischer Ausdrücke zu bearbeiten. Es war aufregend, in der Literatur die verschiedenen möglichen Auswerte-Reihenfolgen für arithmetisch/logische Ausdrücke zusammenzustellen und ihre verschiedenen Eigenschaften zu untersuchen (Zeitverhalten, Speicherverhalten etc.), wobei die ersten Überlegungen über diese Reihenfolgen sich ebenfalls schon bei Saul Gorn finden (Gorn-61). Diese Überlegungen führten dann nach einigen Jahren zu meiner Dissertation (Chroust-74c) (Chroust-03e). Ich identifizierte 14 verschiedene Auswerte-Strateeien für arithmetische Ausdrücke, theoretisch recht interessant. Ich zeigte, dass man die Verknüpfung der verschiedenen Auswertestrategien (es sind Halbordnungen!) als eine Halbgruppe darstellen konnte. Praktisch war die Arbeit aus zwei Gründen weitgehend irrelevant: Zum ersten brauchte ich einen Ausdruck mit mindestens 10(!) Variablen, dass alle 14 Varianten verschiedene Reihenfolgen zeigten. Aber das größere Problem war, dass kaum ein Programmierer so große Ausdrücke schreibt. Die Lehre daraus: akademisch interessant muss nicht wirtschaftlich interessant sein.

6. Weiterentwicklung, Verschiebung der Fragestellung#

Stand am Anfang der Software-Entwicklung die Faszination und Herausforderung, (für damalige Begriffe) große Probleme zu programmieren und zum Laufen(!) zu bringen, traten allmählich Fragen der Produktivität und Qualität in den Vordergrund. Daraus entstanden zwei Strömungen, die die Software-Entwicklung über Jahre nachhaltig praktisch und theoretisch beschäftigten.

6.1 Software-Entwicklungsumgebungen#

Man schenkte dem Umfeld der Programmierung immer mehr Aufmerksamkeit, es entstanden sogenannte 'Software-Entwicklungsumgebungen' (englisch: Software engineering environments} in den vielfältigsten Formen. Eine derartige Umgebung stellte dem Software-Ingenieur die notwendigen Werkzeuge (Compiler. Editoren. Tester etc.) zur Verfügung. In vielfältigen Ausformungen und mit verschiedenen Unterstützungen wurde experimentiert [Huenke-80].

Schrittweise wurden neben den eher 'generellen' Programmierwerkzeugen, auch spezielle Entwurfswerkzeuge angeboten, angeregt durch das Konzept des 'Information Engineering' [Martin-89a]. Im Anfang waren es Diagramm-Editoren für Entity-Relationship-Modelle und Datenflussgraphen. Zahlreiche andere Werkzeuge kamen allmählich auf Grund der Konzepte des Information Engineering hinzu. IEF und IEW waren zwei verbreitete Entwicklungsumgebungen. Damit erhielten auch graohische Darstellungen immer mehr Bedeutung, auch wieder in Svnereie mit der Hardware-Entwicklung, die schnellere Prozessoren und bessere Bildschirme zur Verfügung stellte.

6.2 Vorgehensmodelle#

Die möglichst nahtlose Unterstützung der Software-Entwicklung war ein schwieriges Ziel. Sehr bald setzte sich aber auch die Ansicht durch, dass der Entwicklungsprozess selbst ebenfalls festgelegt und durch Programme unterstützt werden sollte [Humphrey-89]. Es entstanden Vorgehensmodelle von verschiedener Tiefe und Detaillierung [Chroust-92a]. Daraus entwickelte sich ein starker Fokus auf die Prozesse des Software Engineering. Ein Vorgehensmodell beschreibt die auszuführenden Aktivitäten, deren Reihenfolge sowie die Zwischen- und Endprodukte, die zwischen den Aktivitäten weitergegeben und bearbeitet werden. Oft enthält es auch weitere relevante Festlegungen für den Software-Entwicklungsprozess. Dieser Trend setzte sich nach einer frühen Konzeption des ersten Wasserfall-Modells von W. Rovce [Rovce-70], über auf dem Panier festgelegten Vorgehensmodellen [Boehm-84] [IBM-85] bis zu computerinterpretierbaren Modellen fort, wie z.B. ADPS [Chroust-89d] [Bandat-90]. SE/E/TEC [Softlab-82a], MAESTRO [Merbeth-8] [Merbeth-92] usw. Die Werkzeuge wurden an die im Vorgehensmodell festgelegten Aktivitäten als 'Standardwerkzeuge' angebunden. Der Programmierer konnte dann die im Vorgehensmodell vorgesehen Zwischen- und Endprodukte erzeugen. Die Steuerfunktion einer derartigen Entwicklungsumgebung ruft zum Teil automatisch die notwendigen Werkzeuge auf. Sobald Vorgehensmodelle entwickelt wurden, modellierte man sehr bald nicht nur den eigentlichen Entwicklungsprozess sondern auch die Teilprozesse der Dokumentation, der Qualitätssicherung und des Proiektmanagement, später auch die des Konfigurationsmanagement [Broehl-93] [KBst-06].

7. Rückblick#

Blickt man auf die Gesamtentwicklung zurück so kann man verschiedene zeitlich versetzte Strömungen erkennen (Abb. 2)

1. Am Anfang der Entwicklung stand der Wunsch nach automatischer Generierung, mit der damit zusammenhängenden Unabhängigkeit von Hardware. Fortschritte in der Programmiertechnik und dem Computerbau lösten die Probleme.
2. Programmieren allein greift bei komplexeren Aufgaben nicht weit genug - Man betonte die Notwendigkeit, vor der eigentlichen Programmierung. Anforderungen, und Entwurf festzulegen - Information Engineering ist eine der wesentlichen Beiträge zu dieser phasenteiligen Entwicklungsform [Martin-89a].
3. Neben den vorgelagerten Phasen erkannte man auch, dass begleitende Prozesse (Dokumentation. Qualitätssicherung. Projektmanagement, Konfigurationsmanagement) nicht nur notwendig sind, sondern auch mit dem eigentlichen Entwicklungsprozess verflochten werden müssen [Bandat-901 [Chroust-89d] [Corzilius-92].
4. Eine weitere Erkenntnis war. dass man den Entwicklunesorozess abstrahieren muss. um ihn dann zu analysieren. Danach kann man ein Assessment und Verbesserungen ansetzen FSoire-981. Der Schritt zum Prozess-Assessment fISO 9000. ISO/IEC 15504) war gemacht [ISO 15504-1-04].
5. Die Probleme mit entwickelter Software brachten dann eine Fokussierung auf Wartung und damit eng verwandt der Wiederverwendung. Angefangen vom mehrfachen Aufruf von Unterprogrammen, über unabhängig verwendbare, fertigprogrammierte Module (COTS) und Software-Komponenten [Cheesman-01] und schließlich zu Produktlinien [Hover-07].

Abbildung 2: Zeitliche Abfolge der Schwerpunkte des Software Engineerings

8. Neue Herausforderungen#

Mit den oben beschriebenen Errungenschaften ist die Software-Entwicklung noch lange nicht abgeschlossen. Es stehen bereits neue Herausforderungen an, die aber wieder, wie in der Vergangenheit, eine Änderung der Blickrichtung erfordern. Die folgenden Trends zeichnen sich ab:

Steigerung der Komplexität: Durch die beachtlichen Fortschritte der Software-Engineerings versuchen wir immer schwierigere, komplexere, vernetztere Probleme softwaremäßig zu lösen [Lehman-SOb].

Beschleunigung aller geschäftlichen und informationsverarbeitenden Prozesse: Menschen fühlen sich überrollt, gleichzeitig fehlt die menschliche Kontrolle bei Ausufern von Prozessen. Es besteht die Gefahr von überraschend auftauchenden nicht kontrollierbaren Zyklen und Oszillationen (Emergenz).

Weitere Benutzerschichten: Immer mehr Menschen werden mit computerisierten Schnittstellen und Geräten in Kontakt gebracht (e-Government, automatische Warenbestellungen...). Gleichzeitig besteht die Gefahr, dass die Undurchschaubarkeit der Systeme wächst [Weizenbaum-83]. Es wächst aber auch der Glaube an die Unfehlbarkeit des Computers und die unüberlegte Akzeptanz der vom Computer gelieferten Resultate.

Demokratisierung der Computer-Programmierung: Immer mehr Menschen, oft ohne es zu Wissen, 'programmieren' einen Computer (z.B. Verwendung von EXCEL). Das bringt den Vorteil der Anpassung an die eigenen Wünsche, aber auch die Gefahr fehlender Professionalität und dadurch auch Anfälligkeit gegen unbeabsichtigte (Bedienungsfehler) und bösartige (Virus und Spam) Einwirkungen. Hier ist die Software-Entwicklung noch sehr gefordert, menschenfreundliche und verständliche Schnittstellen zu entwerfen.

Globalisierung der Märkte: Die Kunden haben die Möglichkeit gewünschte Produkte und Services global einzukaufen, was für lokale Händler oft eine große Schwierigkeit darstellt. Neue Methoden des Vertriebs werden notwendig, besonders die Benützung von Internet.

Kulturelle Probleme der Globalisierung: Computer führen heute immer komplexere Aufgaben in Zusammenarbeit mit Menschen durch [Bourges-Waldegg-98]. Bei der Kommunikation zwischen zwei Menschen erwarten beide Partner einen Kodex von Verhalten und Weltsicht. Zu beachten ist aber, dass diese Regeln kulturell/ethnisch und damit auch geographisch verschieden sein können. Mit steigender Realitätsnähe der Schnittstellen mit dem (nicht unmittelbar sichtbaren Computern erwarten die meisten Benutzer von Computerschnittstellen ebenfalls 'gutes' Benehmen, das heißt kulturell kompatibles Verhalten [Pavr-04] [Chroust-OVd] oder wie [Miller-04] sagt: "mit dem Einfühlungsvermögen eines intuitiven, höflichen Butlers", wobei natürlich diese Erwartungshaltung je nach Kultur verschieden ist [Hofstede-05]. Adäquate Anpassung ('Lokalisierung') wird eines der nächsten großen Probleme international verwendbarer Software sein [Boes-06] [Esselink-00].

9. Schlussbemerkung#

Keine andere Technologie hat in derart kurzer Zeit (knapp 60 Jahre) sich nicht nur mit immenser Geschwindigkeit verbreitet, dabei Gesellschaft und Wirtschaft komplett verändert, sondern auch noch ihr eigenes Gesicht gewandelt: von einer engen hightech Programmiertechnologie zu einer alle Disziplinen umfassenden Basistechnologie. Ich bin überzeugt, dass wir noch lange nicht am Ende dieser Entwicklung stehen - es werden noch weitere Veränderungen kommen, die wir uns noch gar nicht vorstellen können, die weitere Umwälzungen in der Wirtschaft (e-business, Globalisierung), in der Gesellschaft ('Informationsgesellschaft', Web 2.0). und im Leben des Einzelnen (always online) bringen werden. Ich bin glücklich und stolz, dass ich diese dramatische Entwicklung fast vom Anfang an miterleben und auch etwas mitgestalten konnte, und wünsche der nächsten Generation weiterhin soviel Erfolg im allgemeinen, aber im Besonderen in der Reduzierung der Schattenseiten unserer heutigen Welt.

• https://austria-forum.org/af/Wissenssammlungen/Essays/Technik/Chroust%2C_Gerhard
• https://austria-forum.org/af/Wissenssammlungen/Essays/Kulturwandel_durch_Technik/zemanek