La détection d’erreurs en génie logiciel

En mars 2015, Claude Y. Laporte, professeur agrégé de génie logiciel à l’École de technologie supérieure (ÉTS) de Montréal, était l’invité d’une émission scientifique dans laquelle il a expliqué les concepts généraux de cette nouvelle discipline d’ingénierie.

____________________________________

Diffusée chaque dimanche de 12 h 10 à 14 h, l’émission radiophonique Les années lumière (ICI Radio-Canada) se penche sur la science et les nombreux sujets qui gravitent autour tels que la santé, l’environnement, la recherche fondamentale, la démographie, l’urbanisme… M. Claude Y. Laporte, professeur agrégé de génie logiciel à l’ÉTS, a récemment participé à « La règle de 3 », segment de l’émission au cours duquel un chercheur est invité sur trois semaines à présenter une science déclinée en trois enjeux majeurs, soit un enjeu par semaine.

Après une première partie consacrée à la définition du génie logiciel et une deuxième sur la qualité des logiciels, M. Laporte aborde cette semaine l’injection et la détection d’erreurs dans la fabrication et production des logiciels.

Le bogue, cet incontournable

Attribué à l’origine à la détection d’un insecte (bug en anglais, bogue au Québec) dans un ordinateur électromécanique, le mot bogue fait malheureusement partie intégrante de l’environnement du génie logiciel. Nous ne trouvons plus d’insectes dans nos machines désormais, mais ce sont bel et bien les humains qui « injectent » involontairement des erreurs dans le processus intellectuel consistant à traduire les besoins du client en spécification, en architecture, en code, en test et en documentation.

La complexité des logiciels, la raison de la présence d’erreurs

Si les logiciels étaient linéaires, la tâche serait bien plus aisée. Or chaque logiciel est constitué de points de décision (un questionnement vrai/faux, une donnée est-elle inférieure ou supérieure à 10, etc.).  Chacun de ces points de décision représente alors pour le logiciel une branche différente qu’il faudra coder et ensuite tester. Il faut savoir que dans un logiciel, il y a environ un branchement par 10 lignes de codes. Si nous prenons l’exemple d’un très petit logiciel critique [1] composé de 100 branchements (soit 1 000 lignes de codes), tester chacun de ces branchements pourrait nécessiter plusieurs milliers de tests. Nous pouvons facilement imaginer la complexité et la possibilité d’erreurs pour les logiciels présents dans nos voitures, avions, cellulaires, systèmes médicaux et systèmes de métro qui sont eux constitués de millions de lignes de codes!

L’importance de mettre en place des pratiques logicielles

Watts Humphrey, un des pères du génie logiciel, a fait une étude avec environ 800 développeurs expérimentés pour mesurer le processus de développement logiciel. Il a ainsi découvert qu’un défaut était injecté dans un logiciel toutes les 10 lignes de code. Ce qui exige de mettre en place des pratiques logicielles pour détecter et corriger ces erreurs et réduire le nombre de défauts injectés dans un nouveau projet. Inventé par un ancien responsable du développement produit chez IBM, Michael Fagan, le processus d’inspection Fagan est une des pratiques qui est décrite dans des normes de génie logiciel qui consiste à effectuer des revues par les pairs et à étudier rigoureusement entre autres, les spécifications, l’architecture, les tests et le code. À titre d’exemple, une grande entreprise américaine a publié ses données : elle a constaté que 50 % des erreurs étaient introduites involontairement dans la phase de spécifications et un autre 20 % dans la phase d’architecture, soit 70 % d’erreurs injectées avant même l’écriture d’une seule ligne de codes! Cette entreprise a donc mis en place des pratiques d’ingénierie logicielle rigoureuses qui lui permettent maintenant de détecter plus de 90 % des erreurs injectées à chaque étape du développement réduisant ainsi considérablement ses coûts des reprises.

Les erreurs ne sont donc pas le fait des seuls ingénieurs logiciels, mais aussi des développeurs, des spécialistes en architecture, des spécialistes en ingénierie des exigences qui interviennent en amont. Il est donc indispensable de créer des logiciels de diagnostic et de détection d’erreurs – qui ne sont pas à l’abri de contenir eux-mêmes des erreurs! – pour révéler les défaillances de sous-systèmes. Dans le secteur automobile, environ le tiers des millions de lignes de code sont des logiciels de diagnostic : ils permettront  par exemple d’informer l’opérateur qu’un sous-système de freinage est potentiellement déficient et nécessite une mise à jour.

Voici la cabine de pilotage de l’Airbus A-380 : beaucoup de systèmes logiciels et des millions de lignes de code!

Des logiciels « zéro défaut »?

Capers Jones a mesuré qu’aux États-Unis, le taux moyen d’élimination des défauts chez les manufacturiers est de 85 %, ce qui laisse donc un 15 % de défauts en moyenne. Ce chiffre baisse à près de 5 % chez les organisations qui ont mis en œuvre des processus logiciels rigoureux comportant plusieurs activités de prévention et de détection comme les revues par les pairs. Chiffre certes faible, mais quand nous le rapportons à un système comportant 20 millions de lignes de codes comme dans les automobiles de moyenne gamme, cela laisse malheureusement un grand nombre de défauts résiduels!

Est-ce que l’atteinte d’un niveau d’élimination des défauts d’au moins 95 % pour ceux qui créent ou entretiennent des logiciels critiques ne devrait pas être une exigence professionnelle minimale?

Le génie logiciel a de l’avenir

Au vu des nombreuses implications et applications du génie logiciel dans l’industrie aujourd’hui, le génie logiciel est indéniablement une discipline en voie d’expansion. On constate d’ailleurs à l’ÉTS chaque année une recrudescence en ce qui concerne les inscriptions. Le métier d’ingénieur est lui-même appelé à évoluer de plus en plus : le développeur de logiciel doit désormais apprendre, en plus du logiciel en tant que tel, à s’adapter aux nombreux domaines d’application du logiciel (médical, pharmaceutique, transport, communications, etc.).

Pour entendre cette entrevue radiophonique, cliquez ici.