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

Anbieter zum Thema

DR. JOHANNES HEIDENHAIN GmbH

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

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!

Als Computer in den 50er Jahren noch ausschließlich dem Militär und einigen wenigen Forschungseinrichtungen vorbehalten waren, spielte das Thema Softwareentwicklung noch eine eher untergeordnete Rolle. In dieser Zeit interagierten Programmierer nicht einmal direkt mit Computergeräten. Sie lieferten ihre Programme von Hand an Techniker aus, die sich um die Eingabe kümmerten; was bezeichnenderweise zu Beginn zu einem Großteil Frauen waren, da diese Aufgabe eher als lästige Tipparbeit aufgefasst wurde. Stunden später holten sie die Ergebnisse wieder ab, nachdem die Programme mit vielen anderen im Stapelbetrieb verarbeitet wurden.

Softwareentwicklung in der Frühzeit: Von Struktur keine Spur

In diesen Frühzeiten des Computings waren Aufgaben typischerweise auf mathematische Berechnungen ausgerichtet. Software musste hierfür nicht sonderlich komplex sein, meist war nur eine sehr begrenzte Rückkopplungsschleife erforderlich. Die erste Programmiersprache, die zum Erleichtern von Aufgaben diente – das 1957 entwickelte FORTRAN – diente damals wie heute explizit zum Berechnen mathematischer und wissenschaftlicher Formeln. Computer dienten zur schnelleren Abarbeitung von Berechnungsaufgaben – damit war ihre Aufgabe auch meist bereits erfüllt.

Bildergalerie

Bildergalerie mit 5 Bildern

Mit dem Aufkommen von Transistoren und integrierten Schaltkreisen werden allerdings kleinere, schnellere Computeranlagen möglich, die Computer auch für den kommerziellen Markt interessant machen. So genannte „Minicomputer“, die ab 1963 auf den Markt kommen, sind zwar immer noch so groß wie ein Kühlschrank. Terminal- und Time-Sharing-Systeme machen die Anschaffung von solchen Rechnern aber nun beispielsweise auch fürs Bankwesen interessant. Auch eingebettete „Embedded Systeme“ sind dank der neuen ICs möglich, was vor allem auch die NASA für sein Satellitenprogramm eifrig nutzt.

Mächtige Rechner, mächtige Probleme

Doch mit dem Aufkommen immer mächtigerer Rechner, die von immer mehr Personen genutzt werden konnten, wurde das Thema Programmierung und Bedienung plötzlich zu einem völlig neuem Problem. Als es nur wenige Anwender gegeben hatte und Software nicht komplex sein musste, hatte es ausgereicht, wenige Programmierer zu haben, die auch nur wenige Zeilen Code zu schreiben brauchten – die Menge potentieller Fehler war überschaubar, Programmcode wurde nach Bedarf geschrieben, eine gesonderte Sicherung der Softwarequalität war nicht notwendig.

Doch mit den mächtigeren Systemen stellte sich heraus, dass mangelhafte Softwarequalität oft horrende Kosten verursachen konnte. 1962 verlor die NASA kurz nach dem Start den Kontakt zu seiner Venussonde Mariner-1; ein falsch gesetzter Bindestrich im Programmcode hatte dafür gesorgt, dass die Trägerrakete falsch auf die Befehle des Leitsystems reagierte. Der Softwarefehler kostete der NASA mehr als 18 Millionen US-$. Computerhersteller IBM versenkte zwischen 1961 und 1964 sogar knapp eine halbe Milliarde US-$ (das wären heute etwa 4 Milliarden US-$) in die Entwicklung seines Mainframe-Betriebssystems OS/360.

Die Ursachen lagen unter anderem im unzureichenden Projektmanagement – unterschiedliche Programmierer arbeiteten an unterschiedlichen Bestandteilen der Software, ohne genau zu wissen, was die jeweiligen Kollegen eigentlich machten. Methoden für ausführliche Fehlersuche und Softwaretests existierten in dem Projekt nicht; erst nach Start des Projekts begann IBM, einen Basic Programming Support (BPS) zu entwickeln, um OS/360 überhaupt auf realer Hardware testen zu können. Die Folge: Nach mehreren verfehlten Deadlines und zahlreichen kostspieligen Verzögerungen wird OS/360 fallengelassen. Um weitere Verzögerungen zu vermeiden musste IBM die Rechner der System/360-Familie mit einem von vier „Zwischenlösungs“-Betriebssystemen ausliefern, die alle nur zum Teil umsetzen konnten, was OS/360 hätte leisten sollen.

In der Softwareentwicklung prägte sich für diese Umstände schnell ein Begriff: Die „Software-Krise“ beschreibt eine Ära, in der mangelndes Sachverständnis und unstrukturierte Programmierarbeit wieder und wieder zu kostspieligen Systemausfällen mit stellenweise katastrophalen, fatalen Konsequenzen führt. 1972 beschrieb der Niederländer Edsger Dijkstra, einer der führenden Computerwissenschaftler der Ära, die Ursachen für diese Krise vereinfacht wie folgt: „Solange es keine Maschinen gab, war Programmierung kein existierendes Problem; als wir ein paar schwache Computer hatten, wurde Programmierung zu einem geringen Problem, und nun, da wir gigantische Computer haben, ist die Programmierung ein ebenso gigantisches Problem.“

Aufgrund dieser immer mächtiger werdenden Rechenleistungen sahen sich Akademiker, Entwickler und Unternehmer mit bislang unbekannten Schwierigkeiten im Umgang mit Computern – und vor allem in der Herangehensweise an die Software – konfrontiert.

• Was ist dann ein guter Prozess für den Aufbau einer Lösung zu einem Problem, das bis dahin noch keine bekannte Lösung besessen hat?

• Wenn Software so viele verschiedene Dinge auf einmal erledigen kann, wie kann man dann wissen, dass Software auch „funktioniert“?

• Wie kann man Fortschritte machen, wenn niemand im Team jeden Teil des Programms versteht?

• Wenn Menschen ein Projekt verlassen, wie stellen Sie sicher, dass ihr Ersatz über das gesamte Wissen verfügt, das sie hatten?

• Wenn niemand jeden Teil des Programms versteht, wie diagnostiziert man dann Fehler?

• Wenn Menschen parallel arbeiten, wie verhindern Sie, dass sie sich gegenseitig die Arbeit stören?

• Wenn es bei der Softwareentwicklung um mehr als nur um Programmierung geht, welche Fähigkeiten muss ein guter Programmierer haben?

• Welche Arten von Tools und Sprachen können die Arbeit eines Programmierers beschleunigen und ihm helfen, Fehler zu vermeiden?

Eine Ingenieursstruktur muss her

Um diese Software-Krise zu adressieren und eine Antwort auf all diese Fragen zu finden, sponserte das NATO Science Committee (SCOM) vom 7. bis 11. Oktober 1968 eine Konferenz in Garmisch-Partenkirchen, die einen Weg aus diesem Dilemma heraus finden soll: Die erste NATO Software Engineering Conference. Der Begriff Software Engineering war an sich nichts Neues, wurde aber bewusst provokativ gewählt. Erstmals tauschten sich internationale Experten auf dem Gebiet der Softwareentwicklung aus, um strukturierte Entwicklungsmethoden, Designtechniken, Softwaretests und -wartung oder Projektmanagement zu diskutieren – aber auch Aspekte wie Platz und Stellenwert von Software in einer modernen Gesellschaft.

Über 50 renommierte Teilnehmer (zu denen auch der zuvor erwähnte Dijkstra zählte) aus 11 Ländern fanden sich vier Tage in Garmisch-Partenkirchen zusammen, um Grundlagen für ordentliche, strukturierte und auf Fehler untersuchbare Software zu finden. Wie es im Abschlussbericht der Konferenz heißt, befasste sich die Konferenz „mit allen Aspekten von Software, einschließlich dem Verhältnis von Software zur Hardware eines Computers, dem Design von Software, der Produktion oder Implementierung von Software, dem Vertrieb von Software und dem Service an Software." Darüber hinaus sollten Antworten gefunden werden auf Themen wie, [Zitat]

• „Die Problematik, eine hinreichende Zuverlässigkeit in Datensystemen zu erreichen, die in zunehmendem Maße in zentrale Aktivitäten der modernen Gesellschaft integriert werden,

• Die Schwierigkeiten bei der Einhaltung und Spezifizierung großer Softwareprojekte,

• Die Ausbildung von Software- (oder Datensystem-)Entwicklern, und

• die überaus umstrittene Frage, ob Software unabhängig von der Hardware bepreist werden sollte.“

Mindestens drei dieser Punkte werden auch auf modernen Software Engineering Konferenzen weiterhin und regelmäßig eifrig diskutiert. In einer Folgekonferenz im Rom im darauffolgenden Jahr wurden noch weitere Richtlinien für Software-Engineering-Techniken debattiert und festgelegt.

Von Grundlagen zu Entwicklungen des Software-Engineering

Die folgenden Jahrzehnte brachten zahlreiche Umwälzungen und Veränderungen mit sich, die durch den Grundgedanken des „Software Engineering“ geprägt wurden. Programmiersprachen wie C kamen auf, mit denen mehr Wert auf strukturierte Programmierung gelegt wurde. Anfang der 70er Jahre entstanden Schlüsselideen im Systemdenken, die es den Ingenieuren ermöglichten, diese riesigen Projekte in modulare (und viel überschaubare) Teile zu zerlegen, die über Schnittstellen kommunizierten. Mit den 80ern erhielt auch Strukturiertes Design und Pattern-basierte Designmethoden Einzug in die Softwareentwicklung. Es wurden Entwicklungsumgebungen geschaffen, die es erleichterten, Code auch auf Fehler und Schwächen zu analysieren.

In den späten 80er setzen sich überwiegend objektorientierte Programmiersprachen wie C++ durch und bringen neue Methodiken für die Softwareentwicklung mit sich. Hatten Programmierer zuvor Daten nur als einen sich beständig ändernden Strom begriffen, setzte sich nun ein Verständnis durch, auf beständige diskrete Objekte in einem Softwarecode zu setzen, mit denen interagiert werden kann und die einen unabhängigen Zustand halten können. Dies erlaubte Softwareentwicklern beispielsweise, Objekte der grafischen Benutzeroberfläche (GUI) wie Menüs, Symbole und Fenster zu erstellen und mit ihnen zu interagieren.

In der jüngeren Vergangenheit setzen sich Agile Entwicklungsmethoden oder Entwicklungsmodelle wie Extreme Programming durch, die dazu dienen, Softwarequalität zu verbessern, eine bessere Wartung des Codes zu gewährleisten und eine schnellere Reaktion auf sich ständig verändernde Kundenanforderungen zu ermöglichen.

Wo liegt das Ende der Software-Krise?

50 Jahre ist es her, dass sich Experten erstmals versammelten, um einen Weg aus der Software-Krise zu finden. Vor 50 Jahren wurde erstmals eine Art Regelwerk verfasst, dass Softwareentwicklung und größere Softwareprojekte in geregelte Bahnen lenken sollte, um mehr Struktur, bessere Softwarequalität und eine allgemeine Verbreitung des Wissens über die Programmierung zu schaffen.

Ist die Software-Krise damit überwunden? Oberflächlich betrachtet könnte dieser Eindruck entstehen. Softwareentwicklung hat sich zunehmend professionalisiert, Strukturen, Muster und Methoden wurden gefunden und werden auf breiter Ebene gelehrt. Über einen allgemeinen Mangel an geschulten Software-Entwicklern könnte man sich nicht beklagen – und gleichzeitig sind Softwareentwickler, und gerade Software Engineers, gefragter denn je.

Aber viele der Probleme, die als ursächlich für die Software-Krise der 60er Jahre identifiziert wurden, sind auch heute noch nicht überwunden. Die Feststellung, dass Software in zunehmendem Maße unseren Alltag durchdringt, gilt heute noch viel mehr als noch vor 50 Jahren. Und dasselbe trifft auch auf die Grundaussage von Softwarepionier Dijkstra zu: Die Computerleistung wird weiterhin immer mächtiger; und je komplexer die Rechner und Prozessoren werden, um so komplexer und schwieriger werden sie auch in der Programmierung. Ein ernsthaftes Problem der modernen Zeit ist beispielsweise ineffizienter Code. Die Verfügbarkeit von leistungsstarken Mikrocontrollern und großzügigem Speicher verleitet zum Abfassen von aufgeblähtem und unübersichtlichem Quellcode, ohne dass dieser die vorhandenen Hardware-Ressourcen effektiv nutzt.

Auch Projektmanagement ist immer noch ein essentielles Thema, das auch etablierte Software-Konzerne immer wieder trifft. Die Entwicklung von Microsofts Betriebssystem Windows Vista war beispielsweise verbunden mit zahlreichen Projektschwierigkeiten, einem hohen personellem Aufwand und von verschiedenen Programmierern unabhängig voneinander entwickelten Softwaremodulen, die im fertigen System nicht richtig zusammenarbeiteten. Eine erste, 2001 begonnene Version musste 2004 eingestampft und wieder neu begonnen werden; die geplante allgemeine Verfügbarkeit verschob sich von 2003 letztlich auf Anfang 2007.

Nach offiziellen Angaben verschlang die Entwicklung von Vista 6 Milliarden US-$ und benötigte 2000 Programmierer; das Resultat war ein bei Release unter Stabilitäts- und Performanceproblemen leidendes OS, dass Kunden und PC-Hersteller als Enttäuschung aufnahmen. (Microsoft änderte daraufhin im Übrigen die Herangehensweise an Entwicklungsprojekte; mit Erfolg: Der Nachfolger Windows 7 ist binnen 2,5 Jahre fertiggestellt. Und auch wenn keine offiziellen Zahlen existieren, werden die Entwicklungskosten zu dessen Nachfolger Windows 8 auf 1,5-1,8 Milliarden US-$ geschätzt - weniger als ein Drittel dessen, was der „Großvater“ gekostet hatte.)

Das Feld der Qualitätssicherung ist sogar noch um weitere Komponenten gewachsen, die 1968 kaum jemand auf dem Schirm hatte. Hacking und Security hatten vor 50 Jahren noch wenig Bedeutung, als es nur wenige Personen gab, die sich überhaupt mit Computerbedienung auskannten, geschweige denn der Programmierung von Software. Doch im Zeitalter der vernetzten Geräte, der leichten Zugänglichkeit von Designtools und einer großen Verbreitung an praktischem Entwicklerwissen sing Sicherheitslücken zu einem Problem geworden, dass in zunehmendem Maße kritische Infrastrukturen bedroht – und auch Menschenleben.

Der oft erwähnte Jeep-Hack aus dem Jahr 2015 ist da nur das bekannteste Beispiel. Kostspielige und potentiell lebensbedrohliche Softwarerisiken bestehen weiterhin – Computerwissenschaftler Peter G. Neumann führt etwa eine umfangreiche, bis ins Jahr 1985 zurückreichende Liste an Beispielen, die nur die bekanntesten durch Software entstandenen Risiken der jüngeren Vergangenheit aufzeigt.

Die Zukunft des Software Engineering

Es gibt es auch andere, neuere Fragen, die im Software Engineering gerade erst begonnen wird zu adressieren. Wenn heute jeder Teil der Gesellschaft mit Code arbeitet, welche Verantwortung haben Softwareentwickler, um sicherzustellen, dass Code richtig ist? Wenn KI geschult wird und uns Arbeit erleichtern soll – welche Verantwortung haben dann deren Programmierer, um algorithmische Verzerrungen zu vermeiden? Wenn Autos in Massen autonom herumfahren sollen, wer ist dann verantwortlich, wenn es zu einem tödlichen Unfall kommt: das Auto, der Fahrer oder die Softwareentwickler, die es gebaut haben, oder die Firma, die es verkauft hat?

Diese ethischen Fragen sind in gewisser Weise die Zukunft des Software-Engineerings und werden regulatorischen Kontext, Prozesse und Verantwortlichkeiten dieses Feldes signifikant prägen. Und gleichzeitig sind die Wahrung von Softwarequalität, das Gewährleisten von Testbarkeit und effektives Projektmanagement heute noch ebenso brennende Themen, wie sie es noch vor 50 Jahren waren.

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

Tech-Preview: Embedded Software Engineering Kongress 2018

Nida-Rümelin über künstliche Intelligenz und Ethik

(ID:45539624)