Aussagen aus Analysen zur Qualität der Softwareentwicklung

Studie des U.S. Government Accounting Office (85):

kam zum Ergebnis, daß die untersuchten Softwareprojekte zu ca.

47% unbrauchbare Resultate lieferten

29% keine Resultate lieferten

19% abgebrochen wurden oder Resultate lieferten, die weiter bearbeitet werden mußten

3% Resultate lieferten, die nach Überarbeitung benutzt werden konnten

und nur zu ca.

2% Resultate lieferten, die ohne Veränderung direkt verwendet werden konnten.

Tom de Marcos Analyse von 500 Software-Projekten (1991):

- Jedes sechste DV-Projekt wurde ohne jegliches Ergebnis abgebrochen,

- alle Projekte überzogen den Zeit- und Kostenrahmen um 100 bis 200 Prozent,

- auf hundert ausgelieferte Programmzeilen kommen im Durchschnitt drei Fehler

Studie der Standish Group (95)

(Befragung von 365 IT-Verantwortlichen):

- 31,l Prozent aller Projekte werden vor ihrer Fertigstellung abgebrochen

- über die Hälfte überschreiten die veranschlagten Entwicklungskosten um durchschnittlich 189 Prozent.

- Nur 9 Prozent der Soft ware wird zeitlich und finanziell plan mäßig fertig.

Kommunikationsprobleme

Viele Software-Projekte werden durch falsche Annahmen von vornherein gefährdet. So ist es meistens falsch, anzunehmen, daß

-	der Anwender bei Projektbeginn genau weiß, was er will,
-	der Anwender das, wovon er weiß, daß er es will, vollständig mitteilen kann,
-	der Entwickler ausreichend verstanden hat, was der Anwender mitteilen konnte,
-	das kommunizierte Wissen ausreicht, um die vom Anwender gewollten Funktionen produzieren zu können,
-	der Entwickler eine wissenschaftlich begründete Methode besitzt, um das verstandene in Software zu übertragen,
-	der Anwender versteht, was der Entwickler außer den vorgelegten Beispielen noch leisten könnte,
-	der Anwender also wüßte, welche Software möglich wäre, wenn der Entwickler besser über seine Bedürfnisse unterrichtet wäre.

Eine recht naive und gefährliche Annahme versteckt sich außerdem in der Zuversicht, daß Entwickler und Anwender es schon rechtzeitig merken werden, wenn Mißverständnisse auftreten, und diese durch Nachfragen leicht beseitigen können. Vielmehr ist es die Regel, daß Verständnislücken auf beiden Seiten viel zu spät und manchmal gar nicht aufgeklärt werden, so daß für den Anwender Unnützes mit viel Mühe implementiert wird, und zugleich zentrale, aber bislang implizit gebliebene Anforderungen gerade noch nicht erfüllt sind.

Methodenproblem

Das Risiko der Software-Entwicklung, eingeschlossen deren Management, erwächst nicht allein aus den Tücken der Kommunikation, sondern auch aus Mängeln der bislang vorhandenen Methodik. Verfahren zur Softwarespezifikation weisen oft eine reichlich große Beliebigkeit auf und sind selten ausreichend methodisch kontrolliert. Was zum Beispiel heißt "abstrahieren"?

aus "Ein tätigkeitstheoretischer Ansatz zur Entwicklung von brauchbarer Software"