ACTUALITÉ SCIENTIFIQUE
ET INNOVATION DE L'ÉTS
Identifier les erreurs tôt dans le processus de développement de logiciels peut permettre de sauver beaucoup d’effort, d’argent et de temps – Vrai ou faux ? - Par : Claude Laporte,

Identifier les erreurs tôt dans le processus de développement de logiciels peut permettre de sauver beaucoup d’effort, d’argent et de temps – Vrai ou faux ?


Claude Laporte
Claude Y. Laporte était professeur de génie logiciel à l’ÉTS avant de prendre sa retraite. Il est l’éditeur du groupe de travail pour l’élaboration des normes ISO/IEC 29110 qui porte sur l’ingénierie de systèmes et l’ingénierie de logiciels.

L’image d’entête est de marsmet473a, licence CC, source.

Pouvez-vous répondre à ces 4 questions?

  • Savez-vous où vos défauts logiciels sont injectés et détectés pendant l’exécution de vos projets?
  • Connaissez-vous le nombre de défauts injectés et détectés dans chaque phase de vos projets?
  • Connaissez-vous le pourcentage de perte monétaire dans votre processus de développement logiciel (par exemple en pourcentage du budget total)?
  • Connaissez-vous la qualité de votre logiciel à chaque phase du cycle de développement (par exemple le nombre de défauts par page, par ligne de code)?

Si vous ne pouvez pas répondre à toutes ces questions, lisez la suite de ce blogue.

Pourquoi est-ce intéressant de corriger les défauts dans la même phase qu’ils ont été injectés? La figure 1 illustre un exemple de la croissance du coût d’une erreur non détectée dans la phase où elle a été produite. Par exemple, un défaut produit pendant la phase de conception et détecté pendant cette phase aurait un coût de correction de 1, un coût relatif de 175 si le défaut est corrigé pendant la phase des exigences, et un coût relatif de 572 s’il est corrigé pendant la phase de conception et ainsi de suite.

Figure 1. Coût de correction des défauts en dollars 2009 (traduit de [JON 00])

Figure 1. Coût de correction des défauts en dollars 2009 (traduit de [JON 00])

Qui n’a pas entendu parler de la fameuse phase de test pendant laquelle les développeurs doivent travailler, le soir ou la fin de semaine, de nombreuses heures supplémentaires, souvent non rémunérées, à corriger des dizaines de défauts et en découvrir d’autres au fur et à mesure que des défauts sont corrigés. Sans oublier que le budget du projet est fort possiblement tout dépensé et que le logiciel devait être livré au client hier ou même la semaine dernière !

prog

Si le logiciel doit être livré à une date prédéterminée, il est fort possible qu’un grand nombre de défauts ne soient pas corrigés pour respecter la date de livraison. Le client devra donc essayer d’utiliser un logiciel comportant un bon nombre de défaillances en attendant qu’une nouvelle version lui soit livrée.

L’origine des défauts du logiciel fait l’objet de plusieurs études. Une étude, réalisée par la société américaine Northrop Grumman, impliquant 14 systèmes où 3,418 défauts ont été détectés lors de 731 revues par les pairs, montre les phases où les défauts sont injectés et corrigés. Les systèmes développés par cet organisme comportaient de 25,000 à 500,000 lignes de code et les équipes étaient composées de 10 à 120 développeurs [SEL 07].

La figure 2 présente l’origine des défauts tout au long du cycle de vie du développement de logiciels. On constate qu’environ 50 % des défauts sont produits pendant la phase des exigences et qu’environ 20% sont injectés pendant les phases de conception. Autrement dit, plus de 70% des défauts sont produits avant même qu’une seule ligne de code ne soit écrite ! Que penser des nombreuses compagnies qui attendent la phase de test pour ‘découvrir’ les défauts alors qu’il aurait été possible de les détecter et de les corriger bien avant les tests et d’une façon moins couteuse.

Figure 2. Distribution des défauts injectés pendant le cycle de vie (traduit de [SEL 07])

Figure 2. Distribution des défauts injectés pendant le cycle de vie (traduit de [SEL 07])

La figure 3 montre qu’il est possible non seulement de détecter les erreurs, mais de les éliminer dans la phase même où ils ont été produits. Par exemple, dans la phase des exigences cette organisation a éliminé 96 % des défauts.

Figure 3. Pourcentage des défauts détectés à chaque phase du développement (traduit de [SEL 07])

Figure 3. Pourcentage des défauts détectés à chaque phase du développement (traduit de [SEL 07])

Ce que l’on peut aussi retenir au sujet de ces deux dernières figures, c’est qu’il est possible d’estimer le pourcentage de défauts qui seront injectés dans chaque phase du développement et le pourcentage de défauts qui ne se propageront pas dans les autres phases d’un projet. Muni de ces pourcentages, il sera donc possible de rédiger un plan qualité qui comportera des critères quantitatifs de qualité pour chacune des phases d’un projet.

On sait comment détecter des défauts dans le code, mais, comment fait-on pour détecter des défauts dans des documents comme le document des exigences ? La réponse a été donnée plus haut: les revues par les pairs.

peerreviewLa bonne nouvelle, c’est que les revues par les pairs sont des techniques faciles et rapides à apprendre. La mauvaise nouvelle, c’est qu’il faut de la rigueur et de la discipline pour détecter des erreurs. Si ces erreurs étaient si faciles à trouver, elles nous ‘sauteraient au visage’. Hélas, un grand nombre d’erreurs sont subtilement cachées dans le texte. Il faut donc prendre du temps pour les débusquer. Il faut se concentrer et étudier le document pour détecter les erreurs et les corriger correctement.

Vous avez maintenant quelques pistes qui pourraient vous permettre de répondre aux 4 questions ci-dessus.

Pour en savoir plus

Vous trouverez les descriptions des revues par les pairs dans nos ouvrages sur l’assurance qualité logicielle publiés chez Hermès-Lavoisier:

L’assurance qualité logicielle 1 : Concepts de base

L’assurance qualité logicielle 2 : Mise en oeuvre

Pour voir aussi le court vidéo sur l’assurance qualité logicielle, cliquez ici.

 

 

Claude Laporte

Profil de l'auteur(e)

Claude Y. Laporte était professeur de génie logiciel à l’ÉTS avant de prendre sa retraite. Il est l’éditeur du groupe de travail pour l’élaboration des normes ISO/IEC 29110 qui porte sur l’ingénierie de systèmes et l’ingénierie de logiciels.

Programme : Génie logiciel  Génie des technologies de l'information 

Profil de l'auteur(e)


commentaires

    Laisser un commentaire

    Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *