Eine Curriculardebatte

Lena Bonsiepen und Wolfgang Coy

(erschienen in: Informatik Spektrum 15(6) 1992)

Vor rund fünfzehn Jahren diskutierte die Association for Computing Machinery, wie sie ihr Akronym erhalten und dennoch den Fakt ausdrücken könne, daß die riesige Mehrzahl ihrer Mitglieder sich keineswegs als Vertreter einer Rechenmaschinenindustrie verstehen, sondern arbeitende Informatikerinnen und Informatiker sind. Die Diskussion verlief ergebnislos. Als ähnlich resistent scheinen sich die Begriffe »Computer Science« und »Computer Engineering« zu erweisen.

Dies ändert freilich nichts an der Tatsache, daß die inhaltlichen Bestimmungen dessen, was in der wissenschaftlichen Ausbildung der Informatik relevant und zukunftsträchtig ist, ständig überprüft werden müssen. Die typische Form einer solchen zwischen Lehrenden, Studierenden und den betroffenen Organisationen abzustimmenden Aufgabe ist der Ausschuß, eine Arbeitsgruppe, die auf Vorschlag einer Organisation, die sich für zuständig hält, gebildet wird. Die ACM übernahm diese Aufgabe, indem sie eine Task Force on the Core of the Science of Computing einrichtete. Ergebnis dieser Studie, die in Kurzfassung in den Communications of the ACM veröffentlicht wurde [6], ist die Aufforderung, statt von »Computer Science« oder »Computer Engineering« künftig von »Science of Computing« zu sprechen, und ein moderat modernisierter Curricularvorschlag, dessen radikalste Neuerung in der Anerkennung der Arbeit an grafisch gestalteten Bildschirmen liegt. Eine sanfte Reform wurde nahegelegt, wesentliche Themen, wie der Anteil der mathematischen Ausbildung oder die Verankerung in Naturwissenschaften oder Ingenieurfächern wurden ebenso wie die Aufnahme von Themen aus dem Bereich »Informatik und Gesellschaft« übergangen. Um den Gestaltungsaspekt und software-ergonomische Themen in die Lehre zu integrieren, empfiehlt der Ausschuß eine Öffnung der Informatik zur kognitiven Psychologie und Farbenlehre.

Die 1988 gemeinsam von ACM und IEEE Computer Society gebildete Joint Curriculum Task Force, die 1991 ihre Empfehlungen veröffentlichte [12], übernahm die Grundstruktur der currikularen Vorschläge der älteren Arbeitsgruppe, erweiterte aber deren Themenkatalog explizit um das Fach Sozialer und Professioneller Kontext, das ethische, soziale, juristische und kulturelle Aspekte der Informatik sowie ein Verständnis ihrer historischen Entwicklung umfassen soll.

Von diesen Empfehlungen ausgehend begann in den USA eine heftige Debatte, die inzwischen weit über die ursprünglichen Ziele einer Revision der Computer Science und Engineering Lehrpläne hinausgeht und in äußerst kontroverser Weise Grundfragen des Selbstverständnisses des Fachs Informatik aufwirft.

Im Dezember 89 veröffentlichte die Communications of the ACM den Beitrag »On the Cruelty of Really Teaching Computer Science« von E.W.Dijkstra, dem die Kommentare von sieben Kollegen gegenübergestellt werden [4].

Dijkstras Ausgangspunkt ist die These von der radikalen Neuheit des technischen Artefakts Computer, dessen Komplexität die aller bisherigen technischen Artefakte übertrifft. Programmierer finden sich in der Zwangslage, diese Komplexität mit »einer einzigen Technik«, eben dem Programmieren, beherrschen zu müssen. Zudem sind Computer die ersten digitalen Geräte in großem Maßstab. Der Zusammenhang von Ursachen und Wirkungen ist bei digitalen Maschinen nicht mehr kontinuierlich. Kleine Änderungen haben große Auswirkungen, ohne daß es ein sinnvolles Maß für deren Zusammenhang gibt.

Die Offensichtlichkeit radikaler Neuheiten wird nach Dijkstras Beobachtungen üblicherweise ignoriert; vorherrschende Strategie der Verleugnung ist es, das Neue mit bekannten Begriffen zu beschreiben. Im Umfeld des Computers entdeckt er vertraute, wenngleich inadäquate Termini für den Umgang mit der neuen Technik: Engineering, Maintenance, Tool, selbst Artificial Intelligence. Aus der Unangemessenheit dieser Begriffe und der damit verbundenen Methoden kann man - so Dijkstra - erkennen, daß Computer tatsächlich radikal neue Gebilde sind. Mit alten Termini ist die neue Qualität des Computers nicht zu erfassen; sie sollen nur den Eindruck erwecken, daß es sich um eine bekannte und beherrschbare Technik handele.

Die adäquate Methode des Umgangs mit der Komplexität und Diskretheit des Computers sieht Dijkstra in einer radikalen mathematisch-logischen Orientierung der Ausbildung und der Profession. Das einzige, was Computer wirklich können, ist die Manipulation von Symbolen. Sie tun dies mittels Programmen, abstrakte Symbol-Manipulatoren, die zu konkreten Manipulatoren werden, wenn sie auf einem Computer ablaufen. So betrachtet sind Programme maschinell ausführbare Formeln. Aufgabe der Programmierer bleibt, die Formeln durch die Manipulation von Symbolen herzuleiten. Informatik befaßt sich also mit dem Wechselverhältnis von maschineller und menschlicher Symbol-Manipulation. Computing Science ist am besten in der Welt formaler Mathematik und angewandter Logik anzusiedeln., mag diese jedoch letztlich hinter sich lassen, da die Informatik vor allem an der Effizienz interessiert ist und Größenordnungen modelliert, die weit über dem liegen, was Logik und Mathematik heute behandeln.

Als Konsequenz für ein Informatik-Curriculum wünscht Dijkstra eine stringent mathematisch-logische Ausbildung, beginnend mit einem Einführungskurs, in dem - ohne jedwede Verwendung von Computern - die formale Manipulation einer einfachen imperativen Programmiersprache gelehrt wird. Ziel dieser Grundausbildung ist die Fähigkeit, korrekte Programme zu schreiben, d. h. gegebene Spezifikationen in korrekter Weise in maschinell ausführbare Formaeln umzusetzen.

Alles, was nicht mit der Technik mathematisch-logischer Formalisierung und Umformung erreicht werden kann, die sogenannten frühen Phasen der Software-Entwicklung, alle Anwendungsfragen, alle Gestaltungsfragen bis hin zu den Fragen gesellschaftlicher Wechselwirkung und Folgen, gehört nicht in diese Informatikgrundausbildung. Es sind Aspekte eines »Pleasantness-Problems«, der Anpassung der programmierten Maschinen an ihr gesellschaftliches Umfeld und ihre Nutzung. Nach Dijkstra wird es von großem Nutzen sein, dieses »Pleasantness-Problem« von dem Korrektheitsproblem scharf zu trennen.

Dijkstras Aufsatz wird von eine illustren Reihe von Informatikwissenschaftlern kommentiert, unter ihnen der Komplexitätstheoretiker Richard M. Karp, David Parnas und Terry Winograd. Es gibt in unterschiedlichem Maße Zustimmungen zu Einzelaspekten des Papiers, wenngleich fast alle Kommentatoren vor der »radikalen Neuheit« von Dijkstras »Grausamkeit« zurückzuschrecken scheinen. Aber es gibt auch eine klare Front der Kritik, die im Kern zwei Argumentationssträngen folgt.

So faßt z. B. Winograd ein generelles Unbehagen zusammen, wenn er sagt, Dijkstras Kritik, wenngleich kohärent und interessant, beruhe auf falschen Prämissen: Dijkstra irrt bzgl. des Charakters von Computern und bzgl. der Tätigkeit von Programmierern wie Ingenieuren. Computer sind Geräte, die bestimmte Funktionen innerhalb menschlicher Tätigkeitsbereiche erfüllen. Im Kern mögen sie nichts anderes tun, als Symbole zu manipulieren, aber dies ist Mittel zum Zweck. Ziel der Ausbildung muß sein, künftige Computer-Fachleute zu befähigen, Geräte, Programme und Prozesse zu spezifizieren und zu entwerfen, die den gestellten Anforderungen genügen. Ingenieure suchen »hinreichend zuverlässige Konstrukte zu akzeptablen Kosten mit akzeptablem Aufwand.« Gesucht sind nicht die optimalen und perfekten Lösungen, sondern die akzeptablen.

Fast alle Kommentatoren weisen auf die reale Produktion großer Programmpakete hin. Die Schwierigkeiten scheinen dort weniger im formalen Umgang mit den bereits entstandenen Spezifikationen und Programmen zu liegen, sondern in den frühen Phasen: Wie kommt man zur Spezifikation?

Mit diesem Aufsatz ist der Grundlagenstreit der Informatik, die Frage nach der Bedeutung des Formalismus, erneut voll entbrannt - und dieses Mal heftiger als in den siebziger und achtziger Jahren, wo das Ende der Debatte durch Frederick Brooks Aufsatz »No Silver Bullet« [2] vorerst beendet schien. In Brooks Aufsatz ist die Position der »Intuitionisten« (wenn man diesen Ausdruck dem Grundlagenstreit der Logiker entlehnen will) oder vielleicht besser ausgedrückt, der »Realisten« präzise formuliert. Keine der bisher entwickelten formalen Methoden, von algebraischer Spezifikation über formale Verifikation bis zu KI-Methoden und der Geistbeschwörung mittels »automatischer Programmierung« hat zu einem bedeutenden qualitativen Sprung in der Software-Erstellung geführt oder wird zu einem solchen Sprung führen. Kontinuierliches Wachstum ist die einzige Hoffnung, die wir hegen können - silberne Kugeln, mit denen der Werwolf der Komplexität der Software-Produktion zu erlegen sei, wird es nicht geben.

1991 greift David Gries [10] Dijkstras Argumentationslinie erneut auf. Indem er eine mathematisch-logische Orientierung der Disziplin einfordert, konstatiert er in der Software-Produktion einen Mangel an Professionalität, der sich durch miserable Qualität von Software zeigt. Informatik als Disziplin verfolgt die Herausbildung von professionellen Standards wie sie in anderen Ingenieurdisziplinen selbstverständlich sind nicht mit dem nötigen Nachdruck. Gries hält eine mathematisch orientierte Informatikausbildung für geeignet, die Defizite der Disziplin zu überwinden - Hoffnungen, die er bereits in seinem Standardwerk »The Science of Computing« [9] vertreten hat. Auch in dieser Debatte ist der Formalismus vor allem durch die Hoffnung auf die Zukunft markiert, einer Hoffnung, die die Niederungen der Gegenwart nach Möglichkeit ignoriert.

Nicht formalistisch, aber keineswegs weniger radikal, hat David Parnas Anfang 1990 [15] in der Debatte eine dritte Grundsatzposition neben Dijkstra und Brooks aufgebaut. Parnas vergleicht wie Gries die Informatik mit Ingenieurwissenschaften, kommt aber bzgl. der Art der mathematischen Ausbildung zu einem ganz anderen Schluß. Informatiker arbeiten de facto wie Ingenieure, weil sie technische Artefakte herstellen, doch ihnen fehlt eine Ingenieurausbildung. Informatikern sind im Unterschied zu Ingenieuren fundamentale Methoden wie Zuverlässigkeitsanalysen komplexer Systeme weitgehend fremd. Die Ursache der defizitären Informatik-Ausbildung sieht Parnas in der mehr oder minder zufälligen Entstehung der Informatik-Curricula: In den 60er Jahren begeisterten sich multidisziplinäre Wissenschaftlergruppen für das neue Fach, das aus Mathematik, Ingenieurkursen und etwas Wissenschaft vom Computer (Computer Science) bestehen sollte. Vor allem war man neugierig auf das ãNeue". Mathematische Grundlagen und Ingenieurfächer wurden in wenigen Grundkursen zusammengepfercht; Gebiete, die damals aktuelle Forschungsinteressen widerspiegelten - wie Programmiersprachen und Compilerbau - bildeten vorrangige Bestandteile der Curricula des neuen Ausbildungsgangs. Das Ergebnis ist heute, so Parnas, daß Theoretiker der Informatik nicht viel von Mathematik verstehen und Praktiker nicht viel von Ingenieurwissenschaften. »As I look at CS departments around the world, I am apalled at what my younger colleagues - those with their education in computing science - don't know.«

Parnas' Vorschlag für ein Curriculum ist die Rückkehr zu einer klassischen Ingenieurausbildung, ein altmodischer aber dauerhafter Ansatz, bestens geeignet zur Vorbereitung für die Arbeit in einem so dynamischen Gebiet wie der Informatik. Die Grundausbildung soll im wesentlichen aus mathematischen und ingenieurwissenschaftlichen Kursen bestehen, nur weniges in spezifischen Informatikkursen scheint von so fundamentaler Bedeutung, daß es im Grundstudium gelehrt werden muß. Hier trifft er sich mit Dijkstras Forderung, die Programmierung realer Maschinen im Grundstudium weitgehend zu ignorieren.

Auch Peter Denning, der zuvor als Sprecher der ACM Task Force signierte, äußerte sich Anfang 91 unter dem Titel »Beyond Formalism« [5] erneut zur Curriculardebatte. Unter Bezugnahme auf die hier skizzierten Positionen seiner Kollegen stellt er eine Gemeinsamkeit sowohl der mathematischen wie der Ingenieurperspektive fest: Auch wenn sich die beiden Seiten resp. deren Vertreter über die Relevanz formaler Methoden der Software-Entwicklung streiten, sind sie sich doch einig in der Überzeugung, daß die Anforderungen an ein Software-System eindeutig formuliert werden können, daß die Übereinstimmung mit der Spezifikation ein geeignetes Kriterium für die Bewertung von Software ist, und daß wenig Interaktion zwischen Nutzern und Entwicklern von Software notwendig ist, nachdem man sich über die Spezifikation geeinigt hat.

Diese gemeinsame Überzeugung hält Denning für einen gemeinsamen Irrtum. Ihre Liebe zu eindeutigen Spezifikationen teilen die Software-Ingenieure mit Management-Theoretikern. Management ist im Kern eine »Disziplin der Kommunikation«, die aber insbesondere unter dem Einfluß der wissenschaftlichen Betriebsführung F. W. Taylors und seiner Adepten als System formalisierter Handlungsanweisungen, Anordnungen, Ablaufschemata und Aufgabenbeschreibungen interpretiert wird. Die Kommunikation ist in dieser Sicht eine einseitige: die Manager ordnen an, ihre Untergebenen führen aus. Die Grenzen formalisierten Managements liegen in seiner Unfähigkeit, auf ständig wechselnde Anforderungen und unerwartete Situationen zu reagieren.

Für die Entwicklung von Software-Systemen gelten dieselben Grenzen, solange man Software als Mittel betrachtet, welches Organisationen zur Erfüllung ihrer Aufgaben dient. Spezifikationen erfassen häufig genug veraltete Anforderungen und verhindern so die rasche und flexible Anpassung an die sich ständig ändernden organisatorischen Strukturen und Aufgaben.

Ein wichtiger neuer Ansatz der Software-Entwicklung ist in Skandinavien unter Bezeichnungen wie »user-centered design« bzw. partizipative Software-Entwicklung entstanden, der mittlerweile in Europa und auch in den USA Aufmerksamkeit erhält. Im Zentrum dieses Ansatzes stehen die alltäglichen Aufgaben von Menschen, die die Software nutzen werden. Software-Systeme sind Bestandteil einer funktionierenden Organisation, der Entwickler muß deshalb den sozialen Kontext des Arbeitsplatzes, die Aufgabenverteilung zwischen Mensch und Computer innerhalb des Arbeitsprozesses verstehen lernen. Denning hält den skandinavischen Ansatz für geeignet, Software-Systeme zu entwickeln, die einfach, benutzbar und arbeitsunterstützend sind. In dieser Hinsicht ist er der formalen Software-Entwicklung überlegen. Unbeantwortet muß freilich das Problem der von Brooks und anderen thematisierten inhärenten Komplexität von Software bleiben.

Die amerikanische Debatte holt so eine ältere skandinavische ein [1, 7, 8, 13, 14]. Eine ähnliche Entwicklung war schon bei der Aufnahme des 1986 erschienenen Buches »Understanding computers and cognition« von Winograd und Flores [16] zu sehen; auch hier sind viele skandinavische Diskussionen in die USA transportiert worden und haben dort durchaus eigenständige Formen und Wirkungen hervorgerufen.

In Deutschland ist diese Debatte bisher nur schemenhaft angekommen. Der Fakultätentag Informatik hat bei der Neugestaltung der Rahmenprüfungsordnung eine Diskussion des Fächerkatalogs letztlich vermieden. Dies ist umso beschämender, als die skandinavischen Kollegen uns wissenschaftskulturell um etliches näher liegen. Da sich die der Curriculardebatte zugrundeliegenden Probleme nicht dauerhaft verbergen lassen, ist ein innereuropäischer wie ein transatlantischer Diskussionsprozeß angesagt.

Literatur

1. Bjerknes, G., P. Ehn & M. Kyng: Computers and Democracy - A Scandinavian Challenge. Aldershot (England) et al.: Avebury 1987
2. Brooks, F.P.: No Silver Bullet - Essence and Accidents of Software Engineering. IEEE Computer April 1987, 10-19 (1987)
3. Cox, B.J.: There is a Silver Bullet. Byte Oktober 1990, 209-218 (1990)
4. Denning, P. J. (ed.): A Debate on Teaching Computer Science. Comm. of the acm 32(12), 1397-1414 (1989)
5. Denning, P. J.: Beyond Formalism. American Scientist 79(Jan.-Feb.), 8-10 (1991)
6. Denning, P. J., D.E. Comer, D. Gries, M.C. Mulder, A. Tucker, A.J. Turner & P.R. Young: Computing as a Discipline. Comm. of the acm 32(1), 9-23 (1989)
7. Ehn, P.: Work Oriented Design of Computer Artifacts. Stockholm: Almqvist&Wiksell 1988
8. Floyd, C., W.-M. Mehl, F.-M. Reisin, G. Schmidt & G. Wolf: SCANORAMA. Werkstattbericht Nr. 30. Ministerium für Arbeit, Gesundheit und Soziales des Landes Nordrhein Westfalen: Mensch und Technik - Sozialverträgliche Technikgestaltung 1987
9. Gries, D.: The Science of Programming. Berlin-Heidelberg-New York: Springer 1981
10. Gries, D.: Calculation and Discrimination: A more Effective Curriculum. Comm. of the acm 34(3), 45-55 (1991)
11. Harel, D.: Biting the Silver Bullet. IEEE Computer (Januar 1992), 8-20
12. Tucker, A.B. & B.H. Barnes: Flexible Design: A Summary of Computing Curricula 1991. IEEE Computer (November 1991), 56-66
13. Naur, P.: Programming as Theory Building. Microprocessing and Microprogramming 15, 253-261 (1985)
14. Nygaard, K.: Program Development as a Social Activity, in H. Kugler (Hrsg.): Information Processing 86 Amsterdam: Elsevier 1986
15. Parnas, D.L.: Education for Computer Professionals. IEEE Computer Jan. 1990, 17-22 (1990)
16. Winograd, T. & F. Flores: Understanding Computers and Cognition: A New Foundation for Design. Norwood, New Jersey: Ablex Publ. 1986, dt. Maschinen Erkennen Verstehen, Rotbuch, Berlin, 1989