Existe-t-il des preuves suggérant que le temps consacré à la rédaction ou à la réflexion sur les exigences aura un effet sur le temps de développement? Une étude réalisée par Standish (1995) suggère que des besoins incomplets (13,1%) ont partiellement contribué à l'échec des projets. Existe-t-il des études qui montrent que le temps consacré à l'analyse des besoins aura un effet sur le temps de développement d'un projet ou sur la réussite du projet.
software-engineering
Ken Li
la source
la source
Réponses:
Voir Code Complete, par Steve McConnell, tableau 3-1. Il compare le coût moyen de réparation des défauts en fonction du moment où ils sont introduits et détectés. La détection au moment de la construction coûte 5 à 10 fois plus que la détection au moment des besoins et 10 à 100 fois plus après la publication.
Le tableau est basé sur les sources suivantes:
"Conception et inspections de code pour réduire les erreurs de développement de programme" (Fagan 1976)
Suppression des défauts logiciels (Dunn 1984)
"Amélioration des processus logiciels chez Hughes Aircraft" (Humphrey, Snyder et WIllis 1991)
et plusieurs autres
la source
Oui, il existe de nombreuses études sur ce sujet. Bien sûr, la question est trop générale pour répondre à toutes sortes de projets de développement de logiciels, mais il existe des preuves provenant de plusieurs contextes qui soutiennent l'idée qu'une analyse correcte des exigences aura un impact positif sur la phase de mise en œuvre. Ces preuves ont été partiellement rassemblées dans des "lois", et voici trois exemples:
Loi sur le verre: les lacunes dans les exigences sont la principale source d'échecs du projet.
Cette loi est étayée par des preuves d'études de cas provenant de grands projets de développement de logiciels. Glass a constaté que dans les cas ratés, les exigences étaient bien trop nombreuses, instables en raison de modifications tardives, ambiguës et incomplètes.
Cela suggère qu'il existe une relation entre la qualité des exigences et les résultats du projet.
Première loi de Boehm: les erreurs sont plus fréquentes lors des exigences et des activités de conception et sont d'autant plus coûteuses qu'elles sont supprimées ultérieurement.
Ceci est également étayé par des preuves issues d'études de cas et contribue à répondre à la question de la manière suivante: le respect correct des exigences réduira le nombre d'erreurs dans le système, et la correction des erreurs avant de commencer la mise en œuvre sera moins coûteuse que leur recherche. arrêt lorsque l'implémentation a déjà commencé (ou pire, lorsque le système a déjà été livré).
Deuxième loi de Boehm: le prototypage réduit (considérablement) les exigences et les erreurs de conception, en particulier pour les interfaces utilisateur.
Ceci est soutenu par des expériences contrôlées dans un contexte étudiant. Une interprétation possible est que les exigences et les phases de conception n'ont pas besoin d'être entièrement axées sur la documentation et théoriques. Au lieu de cela, effectuer le prototypage dans le cadre des phases d'exigence et de conception - ce qui revient à consacrer du temps et à réfléchir aux exigences - va affecter le succès du projet et le temps de mise en œuvre.
Il existe également de nombreuses autres preuves qui vont dans le même sens: passer du temps à préparer la mise en œuvre est rentable sous la forme de moins de risques et de chances de dépassement de calendrier en raison de surprises. Bien que la question ne porte pas sur les tests, une préparation appropriée affecte également les tests.
Les références de ces lois sont:
Loi sur le verre: Glass, RL: Software Runaways. Leçons tirées des échecs massifs de projets logiciels. Upper Saddle River, NJ: Prentice Hall 1998
Première loi de Boehm: Boehm, BW, McClean, RK, Urfrig, DB: une certaine expérience des aides automatisées à la conception de logiciels fiables à grande échelle. IEEE Trans on Software Engineering 1, 1 (1975), 125–133
Deuxième loi de Boehm: Boehm, BW, Gray, TE, Seewaldt, T .: Prototyping Versus Specifying: A Multiproject Experiment. IEEE Trans on Software Engineering 10, 3 (1984), 290–302
En outre, la référence suivante peut être intéressante: Endres, A. et Rombach, D. A Handbook of Software and Systems Engineering. Observations empiriques, lois et théories. La série Fraunhofer IESE sur le génie logiciel. Addison Wesley, 2003.
la source