Softwarekrise

Die Softwarekrise bezeichnet ein Mitte der 1960er-Jahre auftretendes Phänomen: Erstmalig überstiegen die Kosten für die Software die Kosten für die Hardware. In der Folge kam es zu den ersten großen gescheiterten Software-Projekten.

Inhaltsverzeichnis

1 Anfänge
2 Merkmale
3 Ursachen
4 Lösungsansätze
5 Siehe auch
6 Weblinks

Anfänge

Man erkannte, dass die bisher genutzten Techniken mit dem Umfang und der Komplexität der Software nicht Schritt gehalten hatten. Auf einer NATO-Tagung 1968 in Garmisch-Partenkirchen, Deutschland, wurde das Problem diskutiert und als Reaktion der Begriff des Software Engineering geprägt.

Eine der ersten gesicherten Erwähnungen der Softwarekrise findet sich in Edsger W. Dijkstras Dankesrede zum Turing-Preis "The Humble Programmer" (deutsch: „Der bescheidene Programmierer“, EWD340) die er 1972 hielt und die im "Communications of the ACM" Magazin veröffentlicht wurde.

Er beschreibt darin die Ursache der Softwarekrise recht treffend wie folgt: [The major cause of the software crisis is] that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.

Auf Deutsch: [Die Hauptursache für die Softwarekrise liegt darin begründet,] dass die Maschinen um einige Größenordnungen mächtiger geworden sind! Um es ziemlich einfach auszudrücken: Solange es keine Maschinen gab, stellte die Programmierung kein Problem dar; als wir ein paar schwache Computer hatten, wurde Programmierung zu einem kleineren Problem und nun da wir gigantische Computer haben, ist die Programmierung ein ebenso gigantisches Problem.

Edsger Dijkstra: The Humble Programmer (PDF, 473Kb)

Wie schon aus Dijkstras über 30 Jahre alten Ausführungen zu erkennen ist, kann die Softwarekrise auch heute nicht als beendet betrachtet werden: Die Komplexität der Software-Systeme steigt weiter und damit die Probleme, auch wenn die Modernisierung und Strukturierung des Software-Entwicklungsprozesses große Schritte unternommen hat.

Die Softwarekrise geht auf das Problem zurück, dass selbst einfache Programme mit einer Länge von unter 500 Programmcode-Zeilen derart komplex aufgebaut sein können, dass sie mathematisch sehr schwer beschreibbar und aufgrund der hohen Zahl von Permutationen (also Software-Zuständen) auch sehr schwer testbar sind.

Merkmale

Kostenexplosion bei der Entwicklung und dem Testen von Software
mangelnde Termineinhaltung bei der Softwareentwicklung
unzufriedene Anwender
schlechte Wartung der Software
Anforderungen nicht eingehalten
viele Programmfehler

Ursachen

Neben den prinzipiellen Ursachen der Softwarekrise, die eher zu der Theoretischen Informatik zählen, tragen auch viele Probleme der Qualitätssicherung zum Scheitern von Softwareprojekten bei:

Zeitdruck, da Termine oft von fachfremdem Personal vorgegeben werden
mangelnde Qualitätssicherung
schlechte oder übertriebene Projektorganisierung
mangelnde Einbeziehung des Anwenders / Kunden
mangelnde Standardisierung

Lösungsansätze

Die Konzepte der Objektorientierten Programmierung, Aspektorientierten Programmierung sowie verschiedene Entwicklungsprozesse sollen die Auswirkungen der gestiegenen Komplexität mildern.
Verstärkter Rückgriff erprobte Komponenten Softwarebibliotheken, Software ICs nutzt bereits geleistete Entwicklungsarbeit effizienter.
Einsatz von Code Generatoren und Modellgetriebene Softwareentwicklung ersetzt die Fehlerklasse der zufälligen Fehler durch leichter zu findende systematische Fehler.
Literate programming, entwickelt von Donald Knuth

Aus Anwendersicht kommen auch folgende Punkte in Betracht:

Stärkere Orientierung an offenen Standards. Dies ermöglicht einen leichteren Wechsel zwischen Anbietern und das kombinieren der jeweils besten Implementierungen zu einem gegebenen Problem.
Weniger neue nicht nötige Softwareversionen, die nur aus kommerziellen Gründen programmiert werden, dem Anwender aber kaum mehr Nutzen bringen. Dies betrifft vor allem Software „von der Stange“ wie Office Programme, deren Funktion erprobt ist und deren Anforderungen sich nicht mehr ändern.
Mehr Kommunikation zwischen Programmierern und Nutzern. Dies reduziert das Risiko von Fehlentwicklungen und minimiert die Auswirkungen von schlecht erfassten Anforderungen zu Projektbeginn.
Freie Software bzw. Open-Source-Software verfügt über den Vorteil einer Anpassbarkeit/Fehlerkorrektur durch den Nutzer und einen potentiell größeren Kreis der Entwickler, die Fehler finden und beheben können.