These: Das Dilema bei der Softwareentwicklung liegt in der klassischen Paretoregel begründet: Nach 80 % der Zeit ist nur 20 % der Software fertiggestellt.
Anders formuliert: Wenn der Abgabetermin da ist, sind nur 80 % der Software fertig, aber die letzten 20 % brauchen noch 80 % der Zeit. Rund 40 Prozent der Unternehmen setzen heute auf Software, die intern selbst entwickelt und auf die spezifischen Anforderungen abgestimmt wird. Zu diesem Ergebnis kam kürzlich eine vom Zentrum für Europäische Wirtschaftsforschung (ZEW, www.zew.de) präsentierte Umfrage. Demnach nutzen zwar rund zwei Drittel der Unternehmen aus dem IT- und Mediensektor, dem verarbeitenden Gewerbe und einigen IT-Anwendungsbranchen herkömmliche Softwarelösungen, die standardisiert am Markt angeboten werden. Trotzdem nehmen Eigeninitiativen zu, so die Wissenschaftler. „Einer der Hauptgründe für diese prozentuale Verteilungsverschiebung ist, dass die auf dem Markt befindlichen Standard-Softwarepakete die individuellen Anforderungen der Unternehmen häufig nicht mehr passgenau erfüllen”, erklärt Bettina Müller vom ZEW.
Die Zahlen belegen den Trend, dass mit zunehmender Unternehmensgröße der Anteil derer, die Software einsetzen, zunimmt. Schließlich steigt der Steuerungs- und damit verbundene Abstimmungsbedarf zwischen den einzelnen Unternehmensteilen mit der Größe massiv an. Vor allem Systeme zur Verwaltung von Kundendaten, sogenannte CRM-Applikationen, und des Mitteleinsatzes (ERP-Systeme) sowie unternehmensübergreifende Software wie SCM-Systeme, die den Datenaustausch zwischen allen an einer Wertschöpfungskette beteiligten Unternehmen koordinieren, lassen sich vielerorts wiederfinden.
Angesichts der branchenspezifischen Spezialisierungen der Unternehmen steigen somit auch die Anforderungen an die zu verwendende Software. Und spätestens an diesem Punkt kommt es zu einem Phänomen, das nun bereits beinahe ein halbes Jahrhundert erstaunlich „jung“ geblieben ist: zur „Softwarekrise“, einem Phänomen, das erstmals in den 1960er-Jahren aufgetreten ist, als die Kosten für die Software die Kosten für die Hardware überstiegen und es in der Folge zu den ersten großen gescheiterten Software-Projekten kam. Man erkannte, dass die bisher genutzten Techniken mit dem Umfang und der Komplexität von 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. (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: “[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.“
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 es in der Modernisierung und Strukturierung des Software-Entwicklungsprozesses große Fortschritte gab. Selbst einfache Programme mit einer Länge von unter 500 Programmcode-Zeilen können ja derart komplex aufgebaut sein, dass sie mathematisch sehr schwer beschreibbar und aufgrund der hohen Zahl von Permutationen (also der Vielzahl von Software-Zuständen) schwer testbar sind. 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 und schlechte Wartung durch Ressourcenknappheit und die Unmöglichkeit, Anforderungen einzuhalten können die Folgen sein.
Neben den prinzipiellen Ursachen der Softwarekrise, die eher zur Theoretischen Informatik zählen, tragen auch 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 kann wesentlich dazu beitragen.
Die Konzepte der objektorientierten und der 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. Eine nicht zu vernachlässigende Quelle von unzureichenden Ergebnissen ist mangelnde Kommunikation zwischen Programmierern und Nutzern. In diesem Zusammenhang habe ich zehn „Lieber-Regeln“ formuliert, die das Problem – zugegebenermaßen ein wenig polemisch – sprachlich eingrenzen.
Die zehn Lieber-Regeln
1) Wenn man in ein Software-Projekt spät zusätzliche Leute einbindet, wird es NOCH später fertig.
2) Mehr Geld motiviert zwar das liefernde Unternehmen durchzuhalten, aber nicht die Software-Entwickler.
3) Pönalen fördern nur die Angst und die Aufschläge, aber nicht den Projekterfolg.
4) Die Wahrscheinlichkeit in einem Softwareprojekt einen Prozess zu gewinnen oder zu verlieren ist geringer als ein Lotto-Sechser! In der Regel werden wegen fachlicher Inkompetenz der Gerichte so lange Sachverständige bestellt, bis die Prozesskosten den Streitwert bei weitem übersteigen und alle gerne einem Vergleich zustimmen. Zusätzlich wird dabei noch auf Zeit gespielt und Zeit = Geld.
5) Software spielt für viele Unternehmen eine existenzielle Rolle, wird aber nicht in dem Ausmaß wertgeschätzt, wie es die Software und deren Lieferant verdienen würde.
6) Fehler in der Softwareentwicklung (schlechte Dokumentation, schlechte Usability, schlechte Feasibility etc.) führen zu hohen Supportkosten und vielen Gewährleistungsfällen (die tw. keine sind, aber auch nicht gezahlt werden).
7) Die Aufwandschätzung für die Umsetzung eines Softwareteils hängt stärker vom Kunden ab als vom Entwickler – z. B. gilt bei kompetenten Großkunden (die selbst Softwareentwicklung betreiben oder eine IT-Abteilung haben), dass die Entwicklerschätzung (eines „Einzelkämpfers“) im Mittel mit dem Faktor 2,3 multipliziert werden muss, um den tatsächlichen Aufwand zu kennen. (Das hängt natürlich von vielen Faktoren ab, soll aber hier exemplarisch formuliert werden.)
8) Wenn ein Entwickler sagt, dass etwas fertig getestet ist, hat es der Entwickler getestet und nicht der Anwender, der es dann auch benutzen muss.
9) Wenn ein Entwickler einen Termin sagt, ist es jener Termin, von dem er glaubt, dass er fertig ist und nicht der Termin, an dem etwas fertig ist.
10) Wenn der Entwickler keinen Termin nennt, wird das Softwareprojekt nie fertig.
Geht man nun vom Spannungsfeld „Budget, Termin und Ressourcen“ aus, in dem sich das Software-Projekt bewegt. Hier lohnt sich ein Blick auf die tendenziell eher fallenden Preise für IT-Dienstleistungen. Manche Consulter formulieren griffig, dass diese Preise im Schnitt sogar um zwischen zehn und 30 Prozent jährlich „purzeln“. Die großen Betreiber rechnen hauptsächlich nach MIPS-Stunden ab. Unter MIPS versteht man die Stärke eines Prozessors, der x Millionen Instruktionen pro Sekunde schnell ist. Diese Kapazitätsangabe wird dann mit der genutzten Zeit hochgerechnet. Damit sich das System wirtschaftlich trägt, kommen zur reinen Computing Power natürlich noch andere Kostenfaktoren hinzu, für die man oft keine geeignete Berechnungsbasis hat – beispielsweise Kosten für Datenreorganisationen oder Operator-Stunden. Die Leistungseinheit MIPS-Zeit ist hier eine Schlüsselgröße, denn diese kann man messen und darauf weniger genau definierte Kostenfaktoren aufschlagen.
Bei Endkunden werden oft Pauschalpreise angegeben, z. B. für Datenbankabfragen. Damit kommt der Anbieter dem Kunden entgegen, indem er auf die für Laien unverständliche Berechnungsbasis verzichtet. Denn der Kunde hat meist keine Vorstellung, was er mit einer Suchanfrage auslöst. Einerseits ist es die Arbeit, die das System verrichtet, andererseits müssen die gewünschten Informationen auch verfügbar sein. Dazu braucht man Gebäude, Energie, Rechner, Plattenspeicher, Software und Menschen, die den Betrieb aufrecht erhalten.
Die Berechnung von IT-Dienstleistungen nach CPU-Minuten ist eine ungenaue Methode, da sie die tatsächliche Rechenleistung nicht berücksichtigt. Denn “CPU” (Central Processing Unit) ist kein fester Begriff. Es gibt schnelle und langsame, starke und schwache CPUs, vergleichbar mit den PS beim Automotor – während einer nur 50 PS an die Achse bringt, schafft der andere 100 PS. Daher muss eine Leistungskennzahl angewendet werden, die definiert, was ein Prozessor zu leisten vermag, wie viele Instruktionen er in einer Zeiteinheit abarbeiten kann. Das ist zum Beispiel der MIPS-Begriff, der sich für die zeitliche Abrechnung deutlich besser eignet. Rechnet man mit der unscharfen CPU-Minute, müsste man eigentlich für jeden Prozessor einen eigenen Preis angeben.
Der Lösungsansatz mit Zufriedenheitschancen
Am fairsten ist jedoch wohl die Abrechnung nach Projektaufwand. Der Kunde bekommt, was er wirklich will und kann die Ergebnisse, sooft es passt prüfen, weil er ja auch dafür die Zeit bezahlt. Das dafür am besten geeignete Vorgehensmodell sind iterative Methoden wie z. B. Agile Softwareentwicklung, RAD, FDD, Scrum etc. Hier geht es darum, den Softwareentwicklungsprozess flexibler und schlanker zu machen als das bei den „klassischen“ Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Die Agile Softwareentwicklung ist eine Gegenbewegung zu den schwergewichtigen und bürokratischen traditionellen Softwareentwicklungsprozessen wie Rational Unified Process oder dem V-Modell.
Agile Werte
Das „Agile Manifest“ aus dem Februar 2001 zeigt Wege aus der Softwarekrise:
1) Individuen und Interaktionen gelten mehr als Prozesse und Tools. Zwar sind wohldefinierte Entwicklungsprozesse und hochentwickelte Entwicklungswerkzeuge wichtig, wesentlich wichtiger ist jedoch die Qualifikation der Mitarbeitenden und eine effiziente Kommunikation zwischen ihnen.
2) Funktionierende Programme gelten mehr als ausführliche Dokumentation. Gut geschriebene Dokumentation kann zwar hilfreich sein, das eigentliche Ziel der Entwicklung ist jedoch die fertige Software.
3) Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen. Ein Vertrag ist normalerweise die Grundlage für die Zusammenarbeit.
4) Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans. Im Verlauf eines Entwicklungsprojektes ändern sich viele Anforderungen und Randbedingungen ebenso wie das Verständnis des Problemfeldes. Das Team muss darauf schnell reagieren können.
In diesem Sinne: Raus aus der Softwarekrise!
Recent Comments