Softwarekrise
Softwarekrise bezeichnet das erstmals Mitte der 1960er-Jahre aufgetretene Phänomen, dass die Leistungsfähigkeit der Software derjenigen der Hardware hinterher hinkte. In der Folge kam es zu gescheiterten Software-Projekten.
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 wurde das Problem diskutiert und als Reaktion der Begriff des Software Engineering geprägt.[1]
Eine der ersten gesicherten Erwähnungen der Softwarekrise findet sich in Edsger W. Dijkstras Dankesrede zum Turing Award The Humble Programmer (deutsch: „Der bescheidene Programmierer“, EWD340), die er 1972 hielt und die im Communications of the ACM Magazin veröffentlicht wurde.[2]
Er beschreibt darin die Ursache der Softwarekrise 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 leistungsfähiger geworden sind! Um es ganz deutlich zu sagen: 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.“
Wie schon aus Dijkstras Ausführungen von 1972 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 es in der Modernisierung und Strukturierung des Software-Entwicklungsprozesses große Fortschritte gab.
Die Softwarekrise geht auf das Problem zurück, dass selbst einfache Programme 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.
Merkmale
Die Kosten bei der Entwicklung und dem Testen von Software können mit der Entwicklungszeit exponentiell steigen. Dadurch wird es schwierig, Termine bei der Softwareentwicklung einzuhalten; der Zeitdruck erhöht sich, Programmfehler treten häufiger auf. Unzufriedene Anwender, schlechte Wartung durch Ressourcenknappheit und die Unmöglichkeit, Anforderungen einzuhalten, können die Folgen sein.
Ursachen
Neben den prinzipiellen Ursachen der Softwarekrise tragen auch Probleme der Qualitätssicherung zum Scheitern von Softwareprojekten bei. Insbesondere die unterschiedlichen Erfahrungshorizonte und Sichtweisen von Management und Entwicklern führen oftmals zu Problemen im Projektmanagement. 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 kann wesentlich dazu beitragen.
Lösungsansätze
Verschiedene Konzepte und Paradigmen aus der Softwareentwicklungstheorie sowie verschiedene Entwicklungsprozesse versprechen die Auswirkungen der weiter steigenden Komplexität zu 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 für Anwender gibt es 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 mangelnde 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.
Jedoch, trotz verschiedenster Ansätze, gilt die Softwarekrise weiterhin im Allgemeinen als ungelöstes Problem der Informationstechnik.
Weblinks
- Edsger Dijkstra: The Humble Programmer (PDF; 473 kB)
- B. Randell – The NATO Software Engineering Conferences (englisch)
- Markus Bautsch: Cycles of Software Crises in: ENISA Quarterly on Secure Software (englisch; PDF; 2 MB)
Einzelnachweise
- Peter Naur & Brian Randell (Hrsg.): Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968. NATO Scientific Affairs Division, Brüssel 1969 (PDF; 2,3 MB)
- Edsger W. Dijkstra: The humble programmer. In: Communications of the ACM. Band 15, Nr. 10, 1972, S. 859–866, doi:10.1145/355604.361591.
- Edsger Dijkstra: The Humble Programmer (PDF; 473 kB)