Zeitaufwand für die Anforderung und seine Auswirkung auf den Projekterfolg und die Entwicklungszeit

Gibt es Hinweise darauf, dass sich Zeit, die für das Schreiben oder das Nachdenken über die Anforderungen aufgewendet wurde, auf die Entwicklungszeit auswirkt? Eine von Standish (1995) durchgeführte Studie legt nahe, dass teilweise unvollständige Anforderungen (13,1%) zum Scheitern der Projekte beigetragen haben. Gibt es Studien, die belegen, dass sich die für die Anforderungsanalyse aufgewendete Zeit auf die Entwicklungszeit eines Projekts auswirkt oder auf den Erfolg des Projekts.

Siehe Code Complete, Von Steve McConnell, Tabelle 3-1. Er vergleicht die durchschnittlichen Kosten für die Behebung von Fehlern anhand des Zeitpunkts ihrer Einführung und Entdeckung. Die Erkennung zur Bauzeit kostet das 5- bis 10-fache der Erkennung zur Anforderungszeit und das 10 bis 100-fache der Nachveröffentlichung.

Die Tabelle basiert auf den folgenden Quellen:

1. "Design- und Code-Inspektionen zur Reduzierung von Fehlern in der Programmentwicklung" (Fagan 1976)

2. Software-Fehlerbehebung (Dunn 1984)

3. "Software Process Improvement bei Hughes Aircraft" (Humphrey, Snyder und WIllis 1991)

und einige mehr

Ja, es gibt viele Studien zu diesem Thema. Natürlich ist die Frage zu allgemein, um für alle Arten von Softwareentwicklungsprojekten beantwortet zu werden, aber es gibt Belege aus verschiedenen Zusammenhängen, die die Annahme stützen, dass sich eine ordnungsgemäße Durchführung der Anforderungsanalyse positiv auf die Implementierungsphase auswirkt. Diese Beweise wurden teilweise in "Gesetzen" gesammelt, und hier sind drei Beispiele:

Glasgesetz: Anforderungsmängel sind die Hauptursache für Projektfehler.

Dieses Gesetz wird durch Fallstudien aus großen Softwareentwicklungsprojekten gestützt. Glass stellte fest, dass in den fehlgeschlagenen Fällen viel zu viele Anforderungen vorlagen, dass sie aufgrund späterer Änderungen instabil und mehrdeutig und unvollständig waren.

Dies deutet darauf hin, dass ein Zusammenhang zwischen der Qualität der Anforderungen und dem Projektergebnis besteht.

Böhms erstes Gesetz: Fehler treten am häufigsten bei den Anforderungen und Entwurfsaktivitäten auf und sind umso teurer, je später sie beseitigt werden.

Dies wird auch durch Fallstudien belegt und trägt zur Beantwortung der Frage auf folgende Weise bei: Wenn die Anforderungen ordnungsgemäß erfüllt werden, wird die Anzahl der Fehler im System verringert, und die Korrektur der Fehler vor Beginn der Implementierung ist kostengünstiger als die Suche nach ihnen nach unten, wenn die Implementierung bereits gestartet wurde (oder noch schlimmer, wenn das System bereits ausgeliefert wurde).

Böhms zweiter Hauptsatz: Prototyping reduziert (deutlich) Anforderungs- und Designfehler, insbesondere bei Benutzeroberflächen.

Dies wird durch kontrollierte Experimente im studentischen Kontext untermauert. Eine mögliche Interpretation ist, dass Anforderungen und Entwurfsphasen nicht vollständig dokumentationsgetrieben und theoretisch sein müssen. Das Durchführen von Prototypen als Teil der Anforderungs- und Entwurfsphasen - was bedeutet, Zeit zu investieren und über die Anforderungen nachzudenken - wirkt sich stattdessen auf den Projekterfolg und die Implementierungszeit aus.

Es gibt auch viele andere Hinweise, die in die gleiche Richtung weisen: Die Vorbereitung der Implementierung zahlt sich in Form eines geringeren Risikos und einer geringeren Wahrscheinlichkeit einer Terminüberschreitung aufgrund von Überraschungen aus. Obwohl es nicht um das Testen ging, wirkt sich die richtige Vorbereitung auch positiv auf das Testen aus.

Die Referenzen für diese Gesetze sind:

Glasgesetz: Glas, RL: Software Runaways. Lehren aus massiven Softwareprojektfehlern. Upper Saddle River, New Jersey: Prentice Hall 1998

Böhms erstes Gesetz: Böhm, BW, McClean, RK, Urfrig, DB: Einige Erfahrungen mit automatisierten Hilfsmitteln für die Entwicklung von zuverlässiger Software in großem Maßstab. IEEE Trans on Software Engineering 1, 1 (1975), 125–133

Böhms zweites Gesetz: Böhm, BW, Gray, TE, Seewaldt, T .: Prototyping versus Specifying: Ein Multiprojekt-Experiment. IEEE Trans on Software Engineering 10, 3 (1984), 290–302

Die folgende Literaturstelle kann auch von Interesse sein: Endres, A. und Rombach, D. Ein Handbuch für Software- und Systemtechnik. Empirische Beobachtungen, Gesetze und Theorien. Die Fraunhofer IESE-Reihe zum Thema Software Engineering. Addison Wesley, 2003.