Softwarekrise
aus Wikipedia, der freien Enzyklopädie
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 |
[Bearbeiten] 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.”
„[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 35 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 der Vielzahl von Software-Zuständen) schwer testbar sind.
[Bearbeiten] Merkmale
Die Kosten bei der Entwicklung und dem Testen von Software steigen exponentiell. Dadurch wird es schwierig Termine bei der Softwareentwicklung einzuhalten; der Zeitdruck erhöht sich, Programmfehler treten häufiger auf. Unzufriedene Anwender und schlechte Wartung durch Ressourcenknappheit und die Unmöglichkeit Anforderungen einzuhalten sind Folgen dessen.
[Bearbeiten] 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. So entsteht Zeitdruck, wenn von fachfremdem Personal Termine vorgegeben werden. Mangelnde Qualitätssicherung, schlechte oder übertriebene Projektorganisation sind genau so verantwortlich für das Missraten von Projekten wie die ungenügende Einbeziehung des Anwenders oder Kunden. Auch die unzureichende oder überdimensionierte Standardisierung können wesentlich dazu beitragen.
[Bearbeiten] Lösungsansätze
Die Konzepte der objektorientierten Programmierung, aspektorientierten Programmierung sowie verschiedene Entwicklungsprozesse sollen die Auswirkungen der gestiegenen Komplexität mildern. Ein verstärkter Rückgriff auf erprobte Komponenten und Softwarebibliotheken nutzt bereits geleistete Entwicklungsarbeit effizienter. Der Einsatz von Code-Generatoren und modellgetriebener Softwareentwicklung (ersetzen die Fehlerklasse der zufälligen Fehler durch leichter zu findende systematische Fehler) sowie das von Donald Knuth vorgeschlagene Literate programming sind weitere Möglichkeiten.
Auch als Anwender gibt es diverse Ansätze, die Qualität der eingesetzten Software zu erhöhen. Stärkere Orientierung an offenen Standards beispielsweise ermöglicht einen leichteren Wechsel zwischen Anbietern und das Kombinieren der jeweils besten Implementierungen zu einem gegebenen Problem. Zudem sollte vor jedem Wechsel auf eine neue Softwareversion geprüft werden, was genau der dadurch gewonnene Nutzen ist. Oftmals enthalten neue Versionen Fehler, die noch nicht bekannt sind und die sich durch einfaches Abwarten umgehen lassen. Dies betrifft unter anderem Standardsoftware wie Office-Anwendungen, deren Funktion erprobt ist und deren Anforderungen sich nicht mehr ändern.
Des Weiteren ist die Kommunikation zwischen Programmierern und Nutzern eine nicht zu vernachlässigende Quelle von unzureichenden Produkten. Gute Kommunikation kann das Risiko von Fehlentwicklungen reduzieren und minimiert die Auswirkungen von schlecht erfassten Anforderungen zu Projektbeginn. Freie bzw. Open-Source-Software verfügt, entsprechendes Wissen vorausgesetzt, über den Vorteil der Anpassbarkeit/Fehlerkorrektur durch den Nutzer und hat damit einen potentiell größeren Kreis von Entwicklern, die Fehler finden und beheben können.
