Je vais commencer par dire que la plupart de ce que je trouve provient des années 70 et du début des années 80. Pendant ce temps, les modèles de processus séquentiels étaient beaucoup plus courants que les approches itératives et / ou incrémentales (le modèle Spiral ou les méthodes agiles). Une grande partie de ce travail est construit sur ces modèles séquentiels. Cependant, je ne pense pas que cela détruise la relation, mais l'un des avantages des approches itératives / incrémentielles est de libérer rapidement les fonctionnalités (toute une tranche verticale d'une application) et de corriger les problèmes avant que les dépendances ne soient injectées et la complexité de chaque phase. est haut.
Je viens tout juste de sortir mon exemplaire de Software Engineering Economics et de trouver une référence aux données sous-jacentes à ce graphique au chapitre 4. Il cite "Contrôles de conception et de code pour réduire les erreurs de développement de programmes" par ME Fagan ( IEEE , PDF de UMD ), EB "Management of Software Engineering" de Daly, "Une analyse des ressources utilisées dans le développement de logiciels système de sauvegarde" ( ACM ) de WE Stephenson et "Plusieurs projets TRW".
... le coût relatif de la correction des erreurs de logiciel (ou de toute autre modification de logiciel) en fonction de la phase de correction ou de modification. Si une erreur d'exigences logicielles est détectée et corrigée pendant la phase de planification et d'exigences, sa correction est une opération relativement simple de mise à jour de la spécification des exigences. Si la même erreur n'est pas corrigée avant la phase de maintenance, la correction implique un inventaire beaucoup plus important de spécifications, de codes, de manuels d'utilisation et de maintenance, ainsi que de matériel de formation.
En outre, les corrections tardives impliquent un processus d'approbation et de contrôle des modifications beaucoup plus formel, ainsi qu'une activité beaucoup plus étendue pour revalider la correction. Ces facteurs se combinent pour rendre l'erreur 100 fois plus coûteuse à corriger lors de la phase de maintenance sur les grands projets que lors de la phase des exigences.
Bohem a également examiné deux projets plus petits et moins formels et a constaté une augmentation des coûts, mais beaucoup moins significative que les 100 fois identifiées dans les projets plus importants. Compte tenu de la carte, les différences semblent être 4 fois plus importantes pour corriger un défaut d’exigences une fois le système opérationnel que lors de la phase d’exigences. Il a attribué cela à la réduction du nombre d'articles composant le projet et à la réduction des formalités, ce qui a permis de mettre en œuvre plus rapidement les solutions simplifiées.
Basé sur Boehm dans Software Engineering Economics, le tableau dans Code Complete est plutôt bouffi (le bas des fourchettes est souvent trop élevé). Le coût de toute modification au sein de la phase est en effet 1. Extrapolant à partir de la figure 4-2 de la rubrique Ingénierie du logiciel, un changement des exigences doit être de 1,5 à 2,5 fois dans l’architecture, de 2,5 à 10 pour le codage, de 4 à 20 pour les tests et de 4 à 4. 100 en maintenance. Le montant dépend de la taille et de la complexité du projet ainsi que de la formalité du processus utilisé.
Dans l'annexe E de Barry Boehm et Richard Turner, Équilibrage de l'agilité et de la discipline, contient une petite section sur les conclusions empiriques concernant le coût du changement.
Les premiers paragraphes citent Extreme Programming Explained de Kent Beck, citant Beck. Il dit que si le coût des changements augmentait lentement avec le temps, les décisions seraient prises le plus tard possible et seul le nécessaire serait mis en œuvre. C'est ce qu'on appelle la "courbe plate" et c'est ce qui motive la programmation extrême. Cependant, ce que la littérature précédente avait découvert était la "courbe raide", avec de petits systèmes (<5 KSLOC) présentant un changement de 5: 1 et des grands systèmes ayant un changement de 100: 1.
La section cite le Centre d'ingénierie logicielle empirique de l'Université du Maryland (parrainé par la National Science Foundation). Ils ont effectué une recherche dans la littérature disponible et ont constaté que les résultats avaient tendance à confirmer un rapport de 100: 1, certains résultats indiquant une plage allant de 70: 1 à 125: 1. Malheureusement, il s’agissait généralement de projets de «grande conception initiale» gérés de manière séquentielle.
Il existe des exemples de "petits projets Java commerciaux" exécutés à l'aide de la programmation extrême. Pour chaque histoire, les efforts consacrés à la correction des erreurs, à la nouvelle conception et à la refactorisation ont été suivis. Les données montrent que, à mesure que le système se développe (plus de user stories sont implémentées), l'effort moyen tend à augmenter de manière non triviale. Les efforts de refactorisation augmentent d’environ 5% et les efforts de correction d’efforts d’environ 4%.
Ce que j'apprends, c'est que la complexité du système joue un rôle important dans la quantité d'effort nécessaire. En créant des coupes verticales dans le système, vous ralentissez le rythme de la courbe en ajoutant lentement de la complexité au lieu de l’ajouter en piles. Plutôt que de traiter de la complexité des exigences suivie d'une architecture extrêmement complexe, suivie d'une implémentation extrêmement complexe, etc., vous commencez très simplement et vous ajoutez des éléments.
Quel impact cela at-il sur le coût à réparer? En fin de compte, peut-être pas beaucoup. Cependant, il présente l'avantage de permettre un contrôle accru de la complexité (grâce à la gestion de la dette technique). En outre, les livrables fréquents souvent associés à l'agilité signifient que le projet peut s'achever plus tôt. Au lieu de livrer "le système", les éléments sont livrés jusqu'à ce que les besoins de l'entreprise soient satisfaits ou aient radicalement changé: un nouveau système (et donc un nouveau projet). est nécessaire.
Métriques et modèles en ingénierie de la qualité logicielle de Stephen Kan comprend une section au chapitre 6 sur le rapport coût-efficacité de la suppression des défauts de phase.
Il commence par citer l'article de Fagan de 1976 (également cité dans la publication Software Engineering Economics) selon lequel les retouches effectuées dans une conception de haut niveau (architecture système), une conception de bas niveau (conception détaillée) et une implémentation peuvent être entre 10 et 100 fois moins chères. que le travail effectué pendant les tests au niveau des composants et du système.
Il cite également deux publications de Freedman et Weinberg (1982 et 1984) qui traitent des grands systèmes. Le premier est "Manuel des procédures pas à pas, inspections et examens techniques" et le second est "Avis, procédures pas à pas et inspections". L'application des examens au début du cycle de développement peut réduire le nombre d'erreurs atteignant les phases de test d'un facteur 10. Cette réduction du nombre de défauts entraîne une réduction des coûts de test de 50% à 80%. Je devrais lire les études plus en détail, mais il apparaît que le coût comprend également la recherche et la correction des défauts.
Une étude réalisée en 1983 par Remus, intitulée "Validation logicielle intégrée dans la perspective des inspections / examens", a étudié le coût de la suppression des défauts dans différentes phases, en particulier les inspections de conception / code, les tests et la maintenance, à l'aide de données provenant du laboratoire IBM Santa Teresa en Californie. Les résultats cités indiquent un ratio de coûts de 1:20:82. C'est-à-dire qu'un défaut constaté lors des inspections de conception ou de code a un coût de changement de 1. Si le même défaut s'échappe lors des tests, il coûtera 20 fois plus cher. S'il parvient à échapper à un utilisateur, il corrigera jusqu'à 82 fois le coût pour corriger. Kan, utilisant des exemples de données provenant de l'installation d'IBM à Rochester, Minnessota, a constaté que le coût de suppression des défauts pour le projet AS / 400 était similaire. à 1:13:92. Cependant, il souligne que l'augmentation des coûts pourrait être due à la difficulté accrue de trouver un défaut.
Les publications de Gilb en 1993 ( "Inspection de logiciel" ) et 1999 ("Optimisation des processus de contrôle technique et de contrôle de la qualité d'ingénierie logicielle") sont citées pour corroborer les autres études.
Des informations supplémentaires peuvent être trouvées dans la page de Construx sur Augmentation du coût des défauts , qui fournit un certain nombre de références sur l'augmentation du coût de réparation des défauts. Il convient de noter que Steve McConnell, auteur de Code Complete, a fondé et travaille pour Construx.
J'ai récemment écouté une conférence intitulée Real Software Engineering donnée par Glenn Vanderburg à la conférence Lone Star Ruby en 2010. Il a donné la même conférence à la conférence Scottish Ruby et à Erubycon en 2011, à la conférence QCon San Francisco en 2012 et à la conférence sur l'architecture O'Reilly Software. en 2015 . Je n'ai écouté que la conférence Lone Star Ruby, mais le discours a évolué au fil du temps, à mesure que ses idées se précisaient.
Venderburg suggère que l'ensemble de ces données historiques indique en réalité le coût de la réparation des défauts au fil du temps, pas nécessairement à mesure du déroulement du projet. Un grand nombre des projets examinés dans les documents et ouvrages susmentionnés étaient des projets séquentiels de "cascade", où la phase et le temps allaient de pair. Cependant, un schéma similaire se dégagerait dans les projets itératifs et incrémentaux: si un défaut était injecté en une itération, il serait relativement peu coûteux de réparer cette itération. Cependant, au fur et à mesure que les itérations progressent, il se passe beaucoup de choses: le logiciel devient de plus en plus complexe, les utilisateurs oublient certains détails mineurs relatifs au travail dans des modules particuliers ou des parties du code, les exigences changent. Tout cela augmentera le coût de la réparation du défaut.
Je pense que cela est probablement plus proche de la réalité. Dans un projet en cascade, le coût augmente en raison de la quantité d'artefacts à corriger en raison d'un problème en amont. Dans les projets itératifs et incrémentaux, le coût augmente en raison de la complexité accrue du logiciel.