La méthodologie de test logiciel repose-t-elle sur des données erronées?


45

C'est un fait bien connu en génie logiciel que le coût de la correction d'un bogue augmente de façon exponentielle à la découverte ultérieure du bogue. Ceci est corroboré par les données publiées dans Code Complete et adaptées dans de nombreuses autres publications.

Cependant, il s'avère que ces données n'ont jamais existé . Les données citées par Code Complete ne montrent apparemment pas une telle corrélation coût / temps de développement, et des tableaux publiés similaires ne montraient que la corrélation dans certains cas particuliers et une courbe plate dans d’autres (c’est-à-dire aucune augmentation de coût).

Existe-t-il des données indépendantes pour corroborer ou réfuter cela?

Et s’il est vrai (c’est-à-dire s’il n’existe tout simplement pas de données permettant de prendre en charge ce coût exponentiellement plus élevé pour les bogues récemment découverts), quel en est l’impact sur la méthodologie de développement logiciel?


Cela semble logique, car la découverte d’un bogue plus tard implique dans la plupart des cas une corruption des données. De plus, avoir des données corrompues coûte beaucoup aux entreprises si cela est découvert plus tard au cours du processus de correction du bogue.
EL Yusubov

8
@ ElYusubov C'est le cas. Mais le bon sens peut être très trompeur. La logique apparente peut facilement tromper notre esprit, alors que c'est en fait l'inverse. C'est pourquoi le génie logiciel fondé sur des preuves est si important.
Konrad Rudolph


2
Pour mémoire (et mentionné dans ma réponse), la première mention que j’ai pu trouver est bien antérieure à Code Complete. Les travaux de Fagan et Stephenson (indépendamment) en 1976 sont la première référence à ce sujet que je puisse trouver. La première édition de Code Complete n'a été publiée qu'en 1993, presque 20 ans plus tard. Je m'attendrais à ce que les travaux de Barry Boehm dans les années 1980 aient conduit à une popularité croissante de cette idée - le travail de Boehm a été très influent sur le processus de génie logiciel dans les années 1980 et même à la fin des années 2000.
Thomas Owens

1
Il est évident que toute déclaration concernant les statistiques du génie logiciel est fausse, y compris celle-ci. (Les bogues que vous rencontrerez plus tard sont généralement les bogues les plus complexes. Et leur correction est compliquée davantage par les "contrôles" mis en place concernant les correctifs de dernière minute.)
Daniel R Hicks

Réponses:


25

La méthodologie de test logiciel repose-t-elle sur des données erronées?

Oui, manifestement. L'examen de la courbe du coût de changement agile montre qu'une partie du travail de Kent Beck sur XP (je ne sais pas si cela faisait partie de sa motivation ou de sa justification) consistait à "aplanir la courbe" des coûts des défauts, sur la base de la connaissance du " exponentielle "qui se trouve derrière la table Code Complete. Alors oui, travailler sur au moins une méthodologie - celle qui a le plus contribué à vulgariser le développement test-first - repose au moins en partie sur des données erronées.

Existe-t-il des données indépendantes pour corroborer ou réfuter cela?

Oui, vous pouvez certainement consulter d'autres données. La plus grande étude que je connaisse est l'analyse des défauts effectuée par Hughes Aircraft dans le cadre de son programme d'évaluation CMM . Le rapport de là montre comment les coûts de défaut dépendu avec la phase pour eux : si les données contenues dans ce rapport ne comprennent pas les écarts afin que vous devez se méfier de tirer trop de « cette chose coûte plus de cette chose » conclusions. Vous devriez également noter que, indépendamment de la méthodologie, il y a eu des changements dans les outils et les techniques entre les années 1980 et aujourd'hui qui remettent en question la pertinence de ces données.

Donc, en supposant que nous ayons toujours un problème pour justifier ces chiffres:

Quel impact cela at-il sur la méthodologie de développement logiciel?

Le fait que nous nous appuyions sur des chiffres non vérifiables n'a pas empêché les gens de progresser sur la base d'anecdotes et d'expérience: de la même manière que de nombreux métiers de maître-apprenti sont appris. Je ne pense pas qu'il y avait un Journal of Evidence-Based Maonry au Moyen Âge, mais tout un tas d'immeubles de grande taille, impressionnants et durables ont néanmoins été construits avec un certain succès. Cela signifie que nous basons principalement notre pratique sur "ce qui a fonctionné pour moi ou pour les personnes que j'ai rencontrées"; Ce n'est pas une mauvaise chose, mais ce n'est peut-être pas le moyen le plus efficace d'améliorer un groupe de millions de personnes qui constituent la pierre angulaire de l'ère technologique actuelle.

Je trouve décevant que, dans une prétendue discipline d'ingénierie, l'empirisme ne soit pas mieux fondé, et je soupçonne (bien que cela ne puisse clairement pas prouver) que nous serions en mesure de progresser plus clairement et plus clairement dans l'amélioration de nos techniques et méthodologies. cette fondation en place - tout comme la médecine clinique semble avoir été transformée par la pratique fondée sur des preuves. Ceci est basé sur quelques grandes hypothèses cependant:

  • que le caractère exclusif de la plupart des pratiques de génie logiciel n'empêche pas la collecte de suffisamment de données utiles et pertinentes;
  • que les conclusions tirées de ces données sont généralement applicables (du fait que le génie logiciel est une profession qualifiée, des différences personnelles d'expérience, de capacité et de goût pourraient affecter cette applicabilité);
  • que les ingénieurs en logiciel "sur le terrain" soient capables et motivés pour utiliser les résultats ainsi obtenus; et
  • que nous savons réellement quelles questions nous sommes censés poser en premier lieu. C’est évidemment le point le plus important: lorsque nous parlons d’ amélioration du génie logiciel, que voulons-nous améliorer? Quelle est la mesure? Améliorer cette mesure améliore-t-il réellement le résultat ou joue-t-il au système? A titre d'exemple, supposons que la direction de ma société ait décidé que nous allions réduire le rapport entre le coût réel du projet et le coût prévu du projet. Je pourrais simplement commencer à multiplier toutes mes estimations de coûts par un facteur de fudge et je réaliserais cet "objectif". Devrait-il alors devenir une pratique courante de l’industrie de falsifier toutes les estimations?

Méta-réponse géniale sur l'ingénierie fondée sur des preuves. Merci.
Konrad Rudolph

4
Bon sang, je viens de me rendre compte que cela vient tout droit de la bouche du cheval. Héhé. Impressionnant.
Konrad Rudolph

1
J'ai l'impression que tout le monde interprète l'utilisation de "données erronées" comme "complètement fausse, le contraire est vrai", mais j'ai l'impression que votre position est simplement de souligner qu'elle peut être fausse. Est-ce correct?
Daniel B

3
@DanielB Correct. Montrez-moi la preuve que c'est vraiment faux et que je pourrais changer d'idée. jusque-là, je sais seulement que ce n'est pas manifestement correct.

1
@ GrahamLee, je vois ce que vous dites (pensez simplement que le phrasé a peut-être été un peu trop agressif). Par curiosité, j’ai trouvé le papier Fagan ici , où il est écrit "... permet de retravailler ... près de leur origine ... 10 à 100 fois moins cher que si cela était fait dans la dernière moitié du processus". Je ne vois cependant aucune citation près de ce texte.
Daniel B

8

Pour ma part, la réponse à "comment cela affecte-t-il la méthodologie de développement logiciel" est "pas grand chose".

Qu'il soit capturé par le développeur ou par l'utilisateur final, que cela prenne plus d'argent après avoir été capturé par l'utilisateur ou non, le fait demeure qu'un bogue a été trouvé dans le système. Si attrapé par le développeur, espérons que c'est une solution rapide. Le même espoir est valable pour les bugs détectés par l'utilisateur.

Indépendamment du coût réel en heures-développeur pour la résolution d'un bogue détecté par un utilisateur final, il existe un coût intangible lié au maintien du stéréotype que les codeurs craignent pour ce qu'ils font. Lorsqu'un utilisateur trouve un bogue, c'est la faute du développeur. Par conséquent, chaque bogue détecté par l'utilisateur final réduit sa confiance dans le système. C'est comme visiter une maison que vous voulez acheter et voir une tache d'eau apparaître à travers le plafond dans un coin de la maison. Cela, en soi, est une solution facile, mais vous vous demandez quelle en est la cause et quelles autres conséquences cette cause fondamentale peut avoir affectée. Que vaut votre tranquillité d'esprit? Vous devrez peut-être abattre les murs et recouvrir les murs et tout inspecter pour vous assurer que la tache provient d'un incident isolé qui a été corrigé. Savoir que cela pourrait être une possibilité ne vous rend pas très confiant à la maison. De même,

Ces coûts intangibles sont évités plus vite que le bogue est détecté, ce qui est l'objectif déclaré des méthodologies de type TDD. Un bogue détecté lors de la frappe par le développeur ou le partenaire d’une paire, un détecté au moment de la compilation ou un test détecté par unité / intégration (couche ajoutée par TDD), est un bogue que l’utilisateur ne doit jamais connaître, que votre Le chef de projet n'a jamais à s'excuser et à ce que vous n'ayez pas à vous soucier de ce que vous faites maintenant pour passer à la vitesse supérieure en mode de réparation des défauts sur une partie du système que vous pensiez avoir laissée derrière vous depuis.


3
Réponse intéressante. J'essaie de faire comprendre à mes utilisateurs que le développement est un processus itératif ou à la fois le raffinage et l'amélioration. Je peux leur donner quelque chose très rapidement, et s’ils rencontrent des problèmes ou souhaitent des améliorations, je peux également inverser ces changements très rapidement (minutes ou heures, pas jours ou semaines). Le système devient de plus en plus stable avec le temps, mais ils ont confiance dans le processus de développement et le résultat final, plutôt que dans le processus de spécification et de construction initiale. (Bien sûr, cela dépend de l'environnement dans lequel vous travaillez. J'écris en ligne pour les applications métier, si elles se cassent, elles seront réparées).
Kirk Broadhurst

Malheureusement, la preuve initiale - selon laquelle les erreurs liées aux exigences détectées lors de la mise en service du produit sont plus coûteuses que les erreurs de mise en œuvre constatées lors de la mise en service du produit - implique la nécessité d'une meilleure validation, et non d'une meilleure vérification. TDD - utiliser des tests pour vérifier le produit par rapport aux exigences - n’est tout simplement pas pertinent pour la recherche de ces bogues.
Pete Kirkham

6

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.


@AndresF. L’un des problèmes que j’ai trouvé dans la recherche de ces citations est ce que Bossavit a décrit comme le problème de «l’aiguille dans une botte de foin» dans le livre auquel vous avez fait référence. Citer un livre est très obscur - même s'il est toujours imprimé lorsque vous allez lire la citation, vous avez quelques centaines de pages à lire à la recherche de la petite pépite qui soutient la prétention de l'auteur citant.

3

C'est juste une simple logique.

Erreur détectée dans la spéc.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

Comme vous pouvez le voir, plus l'erreur est détectée tardivement, plus le nombre de personnes impliquées est important, plus le travail doit être refait. Dans n'importe quel environnement "normal", la paperasserie et la bureaucratie augmentent de manière exponentielle une fois que vous avez touché UAT.

Tout cela sans inclure les coûts qu'une entreprise pourrait encourir en raison d'une erreur dans un logiciel de production (pertes de ventes, dépassement des commandes, piratage de clients, etc.).

Je ne pense pas que quiconque ait jamais réussi à écrire un système non trivial qui n'ait jamais eu de bugs en production, mais tout ce que vous pouvez faire pour attraper les bugs tôt vous fera économiser du temps et des efforts à long terme. Les revues de spécifications, les revues de code, les tests unitaires approfondis, l'utilisation de différents codeurs pour écrire les tests, etc. sont toutes des méthodes éprouvées pour détecter les bogues tôt.


2
Cela ne concerne qu'un cas: une erreur détectée dans la spécification, c'est-à-dire une erreur introduite au tout début. Toutefois, des erreurs peuvent être introduites à toutes les étapes du développement (y compris la résolution des bogues après le déploiement) et leur résolution en sera considérablement facilitée car elles auront probablement une influence sur une plus petite partie du système.
Konrad Rudolph

2
Mais le problème est que les corrections de bugs peuvent avoir des effets secondaires inattendus. Par conséquent, à moins que vous ne puissiez absolument garantir que le correctif n’affectera qu’un sous-ensemble particulier de composants pour lesquels vous êtes obligé de refaire SIT UAT, etc. changement.
James Anderson

2
Je ne suis toujours pas convaincu que cela montre que les bugs seront toujours plus coûteux à corriger lorsqu'ils seront découverts tardivement. Je prétends qu'un bug devient plus coûteux à corriger avec le temps qui s'écoule après son introduction . C'est-à-dire qu'un bogue introduit tardivement, découvert peu après et corrigé est moins cher qu'un bogue introduit très tôt et découvert tôt (mais avec un délai plus long que dans le premier cas). Au moins, je peux imaginer que c'est comme ça que ça marche.
Konrad Rudolph

@ KonradRudolph Pourriez-vous élaborer? C’est ce que je comprends aussi, et je ne vois pas pourquoi le temps importait, mais pas la phase. Pour moi, la mesure du temps dans un projet est votre phase actuelle (et parfois votre itération dans le temps imparti pour passer par toutes les phases). Je ne vois pas la différence entre le travail effectué au jour 3 de la conception détaillée et le jour 300 - le produit de travail de conception détaillée n'a pas été utilisé pour fabriquer d'autres produits de travail. Un défaut injecté dans la conception détaillée n'existe donc qu'à un seul endroit et uniquement. nécessite un changement là-bas. Je ne vois pas en quoi le passage des jours est important.
Thomas Owens

3
@Thomas je ne fais que supposer. Mais le temps compte, car la plupart des éléments de code ou de caractéristiques introduits influenceront le nombre de composants, à moins qu'ils ne soient hautement spécialisés et qu'aucun autre ne dépende d'eux, directement ou indirectement. Ainsi, un bogue qui dure depuis longtemps, quelle que soit la phase dans laquelle il a été introduit, influencera potentiellement de nombreuses parties du système et sa suppression nécessite de s’assurer qu’aucun autre composant n’est endommagé par ce processus.
Konrad Rudolph

2

Je pense que cela concerne, et a toujours été, la gestion des risques et l’économie. Quel est le coût de la réduction du nombre de défauts par rapport à la valeur actuelle de l’impact des défauts futurs? La trajectoire de l’oiseau jaune légèrement en retrait dans Angry Birds n’équivaut pas à celle d’un missile de croisière Tomahawk. Les développeurs de logiciels dans les deux projets ne peuvent pas prendre de décisions en fonction de cette table. À cet égard, rien ne change.

À mon avis, cela a tendance à se faire par le biais du retour d’information. En raison des bogues coûteuses sur le terrain, les entreprises resserrent leurs processus qualité alors qu’aucune plainte de la part du secteur ne l’assouplit. Ainsi, avec le temps, les sociétés de développement de logiciels auront tendance à converger ou à osciller autour de quelque chose qui leur convient (+/-). Code Complete peut influer sur certaines valeurs initiales ou peut entraîner les entreprises légèrement d'une manière ou d'une autre. Une entreprise qui consacre trop d’efforts à éliminer les défauts que personne ne remarquerait risque probablement de perdre des clients au profit d’un concurrent doté d’une approche plus optimisée. D'autre part, une entreprise qui commercialise des produits buggy va également fermer ses portes.

Quelques articles pertinents à partir d'une recherche rapide (lisez les articles complets, faites plus de recherches et formez votre propre opinion):

Analyse systématique de la littérature sur la recherche en coût de la qualité des logiciels (2011)

"Alors que la communauté a ainsi développé une solide compréhension de la structure du domaine de recherche, la validation empirique fait souvent défaut. Seul environ un tiers des articles analysés présente une étude de cas ou des résultats empiriques plus détaillés. Cela semble insuffisant pour la recherche du coût de la qualité logicielle. , qui repose fortement sur des données quantitatives pour générer de nouvelles découvertes. Il est donc nécessaire d’adopter de nouvelles approches pour collecter des données sur les coûts de qualité, ainsi que de renforcer la coopération entre l’industrie et la recherche afin de rendre ces données disponibles. "

Évaluation du coût de la qualité du logiciel (1998)

"Enfin, nous avons constaté qu'il était important de surveiller les coûts de conformité et de non-conformité des logiciels afin que les stratégies de conformité puissent être ajustées afin de réduire les coûts totaux de la qualité des logiciels."

Le comportement des coûts des défauts logiciels (2004)

Résumé ... "Les recherches en cours tentent de mettre à jour nos connaissances sur la manière dont les défauts et leur coût de correction (ou de les laisser non corrigés) influence le coût final du logiciel" ... "les défauts non corrigés deviennent exponentiellement plus coûteux à chaque phase dans laquelle ils ne sont pas résolus "

Couverture des tests et défauts après vérification: une étude de cas multiple (2009)

"Nous constatons également que l'effort de test augmente de manière exponentielle avec la couverture de test, mais que la réduction des problèmes sur le terrain augmente de manière linéaire avec la couverture de test. Cela suggère que pour la plupart des projets, les niveaux de couverture optimaux seront probablement bien inférieurs à 100%".

Combler le fossé entre le processus de test du logiciel et la valeur commerciale: étude de cas (2009)


0

Je ne peux pas répondre à votre première partie de la question, car je n’ai tout simplement pas vérifié. Mais je peux formuler une réponse à votre deuxième question et peut-être une allusion à une réponse possible à la première.

Il va sans dire que certains des facteurs les plus importants dans le coût de la correction d'un bogue, à l'exception des outils de développement intrinsèquement difficiles à utiliser, sont la complexité intrinsèque du produit et la capacité de l'utilisateur à comprendre ce produit.

En me concentrant un instant sur le code, en partant du principe que le code est généralement écrit et géré par des développeurs capables de gérer les complexités intrinsèques de leur code (ce qui peut ne pas être tout à fait vrai et mériter son propre débat), j'oserais suggérer que L’importance cruciale dans la maintenance, et donc dans la correction des bugs, est la capacité des mainteneurs à comprendre ledit code.

La capacité à comprendre le code est grandement améliorée par l’utilisation d’outils d’ingénierie logicielle éprouvés qui, malheureusement, sont pour la plupart sous-utilisés ou mal utilisés. Utiliser le bon niveau d'abstraction, la modularité, l'amélioration de la cohésion des modules et la réduction du couplage des modules sont des outils essentiels pour faire face à la complexité et nécessitant une utilisation appropriée. Le codage aux interfaces ou, dans la programmation orientée objet, en évitant l'utilisation excessive de l'héritage par rapport à la composition, emballage par fonctionnalité, sont certaines des techniques qui font souvent l'objet d'une attention insuffisante dans le codage.

Je pense que les réalités de la concurrence dans le secteur exercent une influence négative sur l’utilisation de méthodes d’amélioration de la qualité pour le développement de logiciels, tout en limitant la qualité intrinsèque des logiciels en tant que mesure du succès actuel.

Par conséquent, je pense que, dans l’industrie, les logiciels ont tendance à souffrir davantage des coûts de correction des bogues à mesure qu’ils grandissent. Avec de tels produits, les bugs deviennent de plus en plus difficiles à résoudre, car le système devient plus difficile à comprendre au fur et à mesure de sa croissance. Les préoccupations introduites par chaque fonctionnalité sont trop associées à d'autres préoccupations, ce qui complique la compréhension. Ou bien, le bon niveau d'abstraction n'a pas été utilisé, ce qui a empêché le responsable de la maintenance de formuler un modèle correct du système et de raisonner à son sujet. Le manque de documentation n'aide certainement pas.

Il y a des exceptions. Je suis sûr que Google ne fonctionne pas à son rythme sans de solides pratiques soutenues par des développeurs stellaires. Et d'autres sont probablement dans la même situation. Mais pour la majorité du logiciel, je ne serais pas surpris si les données ne confirment en effet la demande en code complet .


Je maintiens ma réponse même avec la note négative. J'ai récemment interviewé un candidat qui gère l'outil de banque en ligne de l'une des plus grandes banques. Lors d’une discussion informelle, il a suggéré de ne pas l’utiliser, en raison de la lourde réutilisation du copier-coller et de la mauvaise structure de cette dernière. Auparavant, j'étais développeur dans une entreprise qui rédigeait des outils d'analyse pour des banques telles que Lehman, MS, UBS et nous devions agir en tant qu'experts du domaine. Même si en désaccord avec les pratiques spécifiques, le message général concernant l'industrie est vrai.
Mihai Danila

-1

Une autre réponse! Cette fois, pour répondre à la question du titre "Le logiciel morhtodoligy repose-t-il sur des données erronées".

La vraie réponse est "il n'y a pas de données". Comme il n’existe pas de masse de données fiable sur les projets logiciels, il présente des défauts, des succès de mise sur le marché, etc.

Toutes les tentatives de collecte de ces données ont été sous-financées, statistiquement imparfaites ou si spécifiques à un projet particulier qu'il est impossible d'en tirer des conclusions générales.

De plus, je ne pense pas qu'il y en aura jamais, le processus de développement logiciel est trop subjectif et glissant pour une mesure stricte. Les organisations les mieux placées pour collecter ce type de données (les grands éditeurs de logiciels et les intégrateurs de systèmes) savent pertinemment que toute donnée recueillie à partir de leurs performances serait profondément embarrassante.

Les seuls organismes qui publient des chiffres sur le coût et le succès des projets de logiciels
sont les ministères, et alors seulement parce qu'ils doivent le faire, et oui, ces chiffres sont profondément embarrassants, quel que soit le résultat.

En conclusion, toutes les études de logiciels sont donc nécessairement purement subjectives, car il n’existe aucune donnée réelle sur laquelle fonder une conclusion objective.


1
Non, je n'achète pas ça. Tout d’abord, il existe des données, bien que vous ayez peut-être raison de dire qu’elles sont défectueuses. Mais cela nécessite une critique individuelle de chaque ensemble de données, pas un rejet général. Et je me méfie profondément de l'affirmation selon laquelle il n'y aura jamais de données et de raisons telles que «c'est trop subjectif». C'est essentiellement un argument de manque d'imagination . Je ne prétends pas qu'il est facile de recueillir des statistiques fiables ici, mais je soutiens que c'est tout à fait réalisable. Dans d'autres domaines, des systèmes beaucoup plus compliqués sont analysés avec succès.
Konrad Rudolph

@ Konrad - prenez quelque chose de basique et simple comme "nombre de défauts", certains magasins comptent les échecs de tests unitaires, certains magasins ne commencent pas à dépister les défauts jusqu'à UAT, certains magasins ne font que suivre les défauts dans le code, certains magasins incluent la documentation, la configuration et scripts de déploiement dans leur processus de suivi des défauts. Avoir la mauvaise couleur de fond compte-t-il comme un défaut? Certains projets le suivront comme un défaut, d’autres l’ignoreront.
James Anderson

Ce sont tous des problèmes particuliers, c'est-à-dire solubles. Ils ne posent pas de contraintes fondamentales sur ce qui est possible, ils ajoutent simplement des difficultés qui nécessitent une résolution.
Konrad Rudolph
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.