Temps consacré aux exigences et son effet sur la réussite du projet et le temps de développement


15

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.


3
Comment les modèles agiles s'inscrivent-ils ici? On peut affirmer qu'ils passent du temps aux exigences (on et off) mais il n'y a pas de "phase" d'exigences en tant que telle.
Raphael

1
D'accord avec @Raphael. Allons-nous répondre à des questions sur le génie logiciel? Ou la politique officielle du site est-elle qu'il ne vaut pas la peine de faire la distinction entre «informatique» et «génie logiciel» à l'heure actuelle?
Patrick87

1
@ Patrick87 Passons à la méta .
Raphael

Il me semble que cette question serait mieux adaptée aux sites existants de génie logiciel et de gestion de projet .
Adam Lear

Réponses:


10

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:

  1. "Conception et inspections de code pour réduire les erreurs de développement de programme" (Fagan 1976)

  2. Suppression des défauts logiciels (Dunn 1984)

  3. "Amélioration des processus logiciels chez Hughes Aircraft" (Humphrey, Snyder et WIllis 1991)

et plusieurs autres


Cela seul ne suffit pas. Les erreurs coûteuses doivent se produire assez souvent et doivent être rattrapées assez souvent en proposant des exigences appropriées. Sinon, le coût supplémentaire lié à la définition des exigences pourrait encore l'emporter sur les coûts d'erreur.
Raphael

C'est vrai. Nous devons supposer que jusqu'à un certain point, ne pas se précipiter sur les exigences signifie qu'il y a moins d'erreurs dans les exigences, mais cela ne semble pas exagéré.
Joe

10

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.