Ein Angebot von

„Software Engineering hat die Aufgabe, sich selbst abzuschaffen“

| Autor: Sebastian Gerstl

Prof. Dr. rer. nat. Jochen Ludewig: 
Der Experte für Software Engineering hat in den vergangenen 30 Jahren an Hochschulen der Schweiz und an der Universität Stuttgart Software Engineering in Forschung und Lehre vertreten. Sein besonderes Interesse gilt der Software-Qualität und dem Software-Projektmanagement. Mit dem Studiengang Softwaretechnik hat Ludewig in Stuttgart ein viel beachtetes Modell geschaffen.
Prof. Dr. rer. nat. Jochen Ludewig: 
Der Experte für Software Engineering hat in den vergangenen 30 Jahren an Hochschulen der Schweiz und an der Universität Stuttgart Software Engineering in Forschung und Lehre vertreten. Sein besonderes Interesse gilt der Software-Qualität und dem Software-Projektmanagement. Mit dem Studiengang Softwaretechnik hat Ludewig in Stuttgart ein viel beachtetes Modell geschaffen. (Bild: Elisabeth Wiesner)

Auch 50 Jahre nach der ersten Fachkonferenz zum Thema Software Engineering ist der Bereich der Softwareentwicklung weiter im Wandel. Im Interview spricht Professor Jochen Ludewig über die Herausforderungen des Gebiets – von den 1960er Jahren bis heute.

ELEKTRONIKPRAXIS: 1968 fand erstmals eine Fachkonferenz statt, die sich explizit mit dem Gedanken des Software Engineering beschäftigte. Softwareentwicklung an sich war ja damals nichts Neues. Aber was ist in dem Zusammenhang genau mit dem Bedarf nach Software Engineering gemeint?

Jochen Ludewig: Software Engineering definiert sich – anders als traditionelle Gebiete wie Physik oder Chemie – eigentlich durch ein Defizit. Was z.B. Physik ausmacht, darauf haben sich die Leute im Lauf der Jahrhunderte in etwa geeinigt. Wenn ich etwa Steine vom Schiefen Turm von Pisa fallen lasse und die Zeit messe, die sie brauchen, das ist Physik.

Den Begriff Software Engineering hat man dagegen geprägt, um etwas zu beschreiben, was nicht da ist. John Presper Eckert, Jr., der 1951 zusammen mit John William Mauchly die UNIVAC entwickelt hatte, sagte 1965 auf der Eastern Joint Computer Conference: „Computer programming would only be manageable when we could refer to it as ‚sofware engineering‘.“ Und ähnlich forderte es auch Professor Fritz Bauer 1968: „The whole trouble comes from the fact that there is so much tinkering with software. It is not made in a clean fabrication process, which it should be. What we need, is software engineering." Es war aber damals noch keineswegs klar, was unter Software Engineering zu verstehen ist.

Es gab immer – und zwar von 1968 bis heute – eigentlich zwei Fraktionen. Die eine Fraktion, die praktisch Software baut und sich bemüht, das Ganze in den Griff zu kriegen. Und die andere Fraktion, die mehr die theoretisch formale Seite repräsentiert und versucht, allgemeine Lösungen für die Probleme der Softwareentwicklung anzugeben, zu finden und zu verbreiten. Auch natürlich in der Lehre in den Hochschulen.

Also so wie Design Patterns, konkrete Entwicklungsmodelle, an die man sich hält?

Von Entwicklungsmodellen war damals noch nicht die Rede. Aber man kann es sehr schön an den Programmiersprachen sehen, die damals entstanden sind. Diese waren zunächst sehr pragmatisch, eben darauf zugeschnitten, dass man irgendwie Software machen kann. Vor 1968 waren da Sprachen wie Fortran, was für die Zeiten eine gewaltige Leistung war, oder Cobol. Dann kam eben die akademische Seite und hat gesagt: Das ist alles nicht strikt genug, das ist nicht mathematisch definiert und so fort. Da wurde, von Hochschulen getrieben, eine neue Sprache entwickelt: ALGOL 60 war in dem Sinne auch das Manifest einer bestimmten Herangehensweise.

Weg von einer Programmiersprache, die für spezielle Anforderungen entwickelt wurde, hin zu einer, die von Beginn an bestimmte Anforderungen erfüllt?

Und die vor allen Dingen akademischen Ansprüchen genügt.

Im Sinne der Lehrbarkeit?

Ja. Zum Beispiel war bei Algol 60 ein ganz wichtiges Ziel, dass man Algorithmen publizieren kann, und dass andere Leute in der Lage sind, diese Algorithmen zu lesen. Das wäre in Fortran natürlich auch irgendwie möglich gewesen, aber bei Weitem nicht so schön, muss man sagen.

Fortran war ja in erster Linie zur Berechnung mathematischer und physikalischer Formeln gedacht.

Ja, daher der Name: Formula translation – Fortran. Dinge wie beispielsweise Ein- und Ausgabe hat man in dieser Sprache ziemlich pragmatisch gelöscht. Und in Algol hat man das Thema der Ein- und Ausgabe letztendlich überhaupt nicht gelöst, weil man eigentlich keinen überzeugenden Ansatz hatte, um das formal ordentlich zu machen. Das ist auch einer der Gründe, warum Algol 60 zwar großen Einfluss auf die Entwicklung hatte, aber sich selbst nicht in großem Maßstab durchgesetzt hat.

War Algol 60 dann bereits ein Beispiel für strukturierte Programmierung?

Das hängt sehr davon ab, was man unter strukturierter Programmierung versteht. Die „Strukturierte Programmierung“ war auch ein Schlagwort der späten 60er. 1972 haben Ole-Johan Dahl, Edsger Dijkstra und C. A. R. Hoare zusammen das Buch „Structured Programming“ verfasst. Dieses Buch atmete bereits den Geist des Software Engineerings.

Dijkstra war ja auch auf der ersten Software Engineering Conference in Garmisch-Partenkirchen. Von ihm stammt der Ausspruch: „Als wir noch einfache Computer hatten, waren die Probleme noch einfach. Jetzt, wo wir mächtige Computer haben, haben wir mächtige Probleme.“

Es gab diese Unzufriedenheit, dass der Erfolg der Hardware von Software aufgefressen wird. Niklaus Wirth, Schöpfer der Programmiersprache Pascal, drückte es so aus: „Die Hardware wird immer schneller, die Software wird immer langsamer. Aber die Hardware wird nicht so schnell schneller, wie die Software langsamer wird.“

Speziell in den 60ern ließen der Aufwand für Software, und damit auch die Kosten, die unsachgemäße Entwicklung mit sich brachte, Projekte durchaus zum Scheitern bringen.

Ja, da sind große Projekte, vor allen Dingen amerikanische Rüstungsprojekte, einfach gescheitert. Ich habe das selbst bei einem Großprojekt in der Schweiz beobachtet: Da wurde ein elektronisches Vermittlungssystem gebaut. Das wurde noch in den 80er Jahren im Assembler implementiert. Dieses Projekt wurde eines Tages eingestellt, weil der Verantwortliche festgestellt hat, dass man mit jedem einzelnen Arbeitstag nicht weiter vorankam, sondern ein Stückchen weiter zurückfiel: Die Software veraltete schneller, als sie implementiert werden konnte. Das war also ganz charakteristisch für diese scheiternden Projekte durch mangelndes Software Engineering.

Um Probleme dieser Art zu adressieren, wurde ja die erste NATO Conference on Software Engineering 1968 ins Leben gerufen; auch, um ein strukturiertes oder geregeltes Software Engineering gewährleisten zu können, um Testbarkeit, Qualitätsmanagement und dergleichen gewährleisten zu können.

Das ist im Prinzip richtig. Dabei muss man sich klarmachen: Die dort Anwesenden stellten die Crème de la Crème des Gebiets dar. Aber es existierte keine übergeordnete Struktur. Jeder Experte hatte eine andere Vorstellung von Software Engineering – und nach der Konferenz sind alle nach Hause gefahren und haben nach ihren Vorstellungen weitergemacht. Es gab danach keine gemeinsame Anstrengung. Es gab schon diesen Impuls, dass man die Ideen dieser 68er Tagung weitertragen sollte. Deswegen hat man 1969 nochmal in Rom eine „Conference on Software Engineering“ abgehalten, die aber von den Teilnehmern als Flop beurteilt wurde. Das Wort Software Engineering war in der Folge durch diese Tagung in Rom verbrannt. Zwei, drei Jahre lang hat keiner mehr so richtig davon geredet. Man kann sagen, dass Software Engineering als Fachgebiet erst etwa ab 1973 wirklich entsteht.

Was war da der ausschlaggebende Faktor, der die Wende brachte?

Ich vermute, dass die Leute, die 1968 dabei waren, zwar verschiedene Sachen gemacht haben – aber doch das Bedürfnis hatten, darüber zu kommunizieren. Das heißt, es gab Fachzeitschriften. Es gab Konferenzen. Es gab irgendwann auch mal Lehrstühle. Sobald man solche Institutionen hat, wenn man Kommunikationsebenen hat – das bringt Leben in ein Gebiet.

Dennoch wurden mit dem Abschlussbericht der NATO-Conference gewisse Grundlagen geschaffen, auf denen man dann später Software Engineering betreiben konnte?

Ja, das kann man so sagen. Wie gesagt mit der Einschränkung, dass verschiedene Leute bis heute unter Software Engineering Unterschiedliches verstehen.

Und bis heute ist es ja doch durchaus so: Man hatte in den 60er Jahren angefangen, von der Softwarekrise eben aus den erwähnten Gründen zu sprechen.

Ja.

Und in den 80er Jahren – und auch heute noch – gibt es weiterhin große wie kleinere Projekte, die mit denselben Schwierigkeiten und Problemen konfrontiert wird, die zum Beispiel am unsachgemäßen Projektmanagement scheitern und enorme Kosten verursachen, ...

Ja, klar.

...oder am Ende ein Software-Produkt hervorbringen, das gravierende Sicherheitslücken im Quellcode enthält - ein Problem, das jetzt aktuell sehr kritisch ist.

Ja, vor 50 Jahren hat das noch keine Rolle gespielt.

Sind also die Probleme, die vor 50 Jahren zur ersten Software Engineering Conference geführt haben, überwunden? Oder wird es auch aufgrund der Hardware-Komplexität eher noch immer schlimmer?

Ich glaube, dass viele Probleme, die es 1968 gab und mit denen man damals zu kämpfen hatte, gelöst sind. Ein richtig großes Programm aus vielen hunderttausend Zeilen Code hätte man damals nicht machen können. Das kann man inzwischen. Die Probleme der Größe, die hat man mittlerweile ganz gut in den Griff gekriegt. Es sind aber viele neue Probleme dazugekommen. Wie Sie sagen: Sicherheit zum Beispiel. Dieses Problem wird uns in Zukunft noch viel Kopfzerbrechen machen. Und andere Probleme – Zuverlässigkeit beispielsweise. Man könnte jetzt durch die inzwischen vorhandenen Lehrbücher blättern und sagen: Da fehlt noch was, und da fehlt noch was und da fehlt noch was. Die Themen sind im Detail andere geworden. Aber es gibt immer noch reichlich zu tun.

Da Software Engineering, wie Sie schon sagten, keine Gesetzmäßigkeiten wie die Physik besitzt: Gibt es heute noch Meinungsunterschiede, wie wir mit den Problemen der Software-Bearbeitung umgehen sollten?

Ja, die gibt es natürlich noch. Aber wenn man von Moden und Hypes absieht, entwickelt sich doch ein Konsens darüber, was wichtig und richtig ist. Es wird etwa niemand darüber streiten, ob eine saubere Struktur der Software mit schmalen, wohldefinierten Schnittstellen sinnvoll ist.

Ich denke, dass Software Engineering in einem gewissen Sinne die Aufgabe hat, sich selbst abzuschaffen. Ich habe mal Elektrotechnik studiert. Und ich habe in meinem Elektrotechnikstudium nie eine Vorlesung über Elektrotechnik gehört. Die Elektrotechnik ist das Fachgebiet, der Studiengang. Und die Lehrveranstaltungen, die man besucht, sind alles irgendwelche Aspekte, Teilgebiete der Elektrotechnik. Genauso sehe ich das im Software Engineering auch. Wenn jemand Software Engineering studiert, lernt er viele Sachen, die insgesamt das Software Engineering ausmachen. Aber er wird keine Lehrveranstaltung Software Engineering haben.

Man kann sich fragen: Warum sind wir in der Softwaretechnik noch nicht, wo zum Beispiel die Elektrotechnik oder das Bauingenieurwesen sind? Da kann man sagen: Nun, die Kultur ist einfach noch nicht ausreichend weit entwickelt. Wenn Sie Elektrotechnik studieren, wird Ihnen vom ersten Tag an klar gemacht, dass Sie sich nach Normen zu richten haben, nach Darstellungskonventionen und so weiter. Das gilt für die Hochfrequenztechnik wie für die elektrischen Antriebe. Es gibt eine gewisse Disziplin, an die sich alle halten. Da sind wir im Software Engineering noch nicht.

Wenn jeder, der sich mit irgendeinem Teilgebiet beschäftigt – sei es mit Datenbanken, mit Programmiersprachen, mit KI oder dergleichen – sich als Software-Ingenieur versteht und verhält, dann hat sich das Software Engineering als separates Fach überflüssig gemacht. Das wäre eigentlich anzustreben. Was man dann wirklich speziell abhandeln muss ist die Infrastruktur des Fachgebiets. Das ist in der Elektrotechnik vor allem die Messtechnik. Wir brauchen im Software Engineering auch eine Messtechnik. Ebenso liegt die Lehre der Prozesse im Kern des Software Engineerings. Solche Themen gehören in die Grundausbildung aller künftigen Software-Ingenieurinnen und -Ingenieure.

Wie viele Jahre oder Jahrzehnte dürfte das noch dauern?

Ich fürchte, das werden noch drei, vier Dekaden sein Denn es geht um Änderungen in den Köpfen, um einen Kulturwandel. Und der braucht viel Zeit.

Kongresshinweis Professor Jochen Ludewig können Sie Anfang Dezember auf dem Embedded Software Engineering Kongress vom 3. bis 7. Dezember in Sindelfingen persönlich treffen. Auf dem ESE Kongress behandeln 100 Referenten an fünf Tagen alle Themen des modernen Embedded Software Engineering. Im letzten Jahr kamen über 1200 Teilnehmer nach Sindelfingen. Der Kongress wird von einer Fachausstellung mit über 50 renommierten Firmen begleitet. Programm und Information.

Raus aus der Software-Krise: 50 Jahre Software-Engineering

Raus aus der Software-Krise: 50 Jahre Software-Engineering

12.10.18 - In den 1960ern beginnen Computer, die Wirtschaft zu erobern. Doch die Softwareentwicklung steckt noch in den Kinderschuhen und verschlingt oft mehr Geld als die zugehörige Hardware. Eine NATO-Tagung in Garmisch-Partenkirchen sucht einen Ausweg: Die Computerlandschaft braucht Software-Engineering! lesen

Tech-Preview: Embedded Software Engineering Kongress 2018

Tech-Preview: Embedded Software Engineering Kongress 2018

23.10.18 - Die Keynotes zu KI, C++2020 und agilen Organisationsformen sind nur drei von vielen Highlights der Themenagenda des diesjährigen Leitkongresses der Embedded-Software Branche. Einige mehr lesen Sie hier. lesen

Im Zeichen der Disruption – Was Deutschlands Embedded-Software-Community jetzt tun muss

Im Zeichen der Disruption – Was Deutschlands Embedded-Software-Community jetzt tun muss

23.10.18 - Die Tech-Welt steht am Beginn eines neuen Zeitalters. Für die Softwareentwickler bedeutet dies nicht nur, das Wettrennen um neue Technologien aufzunehmen. Der gesamte digitale Umbruch im Job muss aktiv gestaltet werden. „Wir sind jetzt agil reicht nicht aus. Wie der Change wirklich klappen kann, erläutern Experten auf dem ESE Kongress. lesen

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45583565 / Software Engineering)