Akelaï

La maîtrise des projets de développement IT

Projets IT


Visitez notre site Web dédié à l'ingéniérie logicielle et aux projets IT : software.akelai.fr

logo Akelaï Visitez notre site WEB : www.akelai.fr

La cause d'un bug logiciel

Faut-il pendre les développeurs ?

Amélioration Continue

Les normes qualité préconisent une démarche d'amélioration continue.
Une des premières sources d'amélioration est l'identification des défauts, la recherche de leur cause, puis l'élimination de ces causes.
L'ISO 9001 nomme cette démarche « action corrective » -- à ne pas confondre avec le simple traitement du défaut (élimination, dérogation, rebut ou autre).
L'action corrective -- dans la terminologie ISO qui est parfois mal comprise -- est un complément au traitement du défaut ; elle a pour but d'éviter de reproduire ce défaut. Il s'agit donc bien pour l'entreprise d'une démarche d'amélioration.
Le texte de la norme (ISO 9001 v2008):

8.5.2 Action corrective
L'organisme doit mener des actions pour éliminer les causes de non-conformités afin d'éviter qu'elles ne se reproduisent. Les actions correctives doivent être adaptées aux effets des non-conformités rencontrées.
Une procédure documentée doit être établie afin de définir les exigences pour :

  1. procéder à la revue des non-conformités (y compris les réclamations du client);
  2. déterminer les causes de non-conformités;
  3. évaluer le besoin d'entreprendre des actions pour que les non-conformités ne se reproduisent pas;
  4. déterminer et mettre en oeuvre les actions nécessaires;
  5. enregistrer les résultats des actions mises en oeuvre (voir 4.2.4);
  6. evaluer l'efficacité des actions correctives mises en oeuvre.

Le CMMI introduit le « process area » CAR : Causal Analysis and Resolution, dont les deux objectifs sont -- sans surprise -- de déterminer et de traiter la cause des défauts.

Si l'on cherche à remonter à l'origine de ces pratiques, on trouve les cercles de qualité et le « Total Quality Management » japonais. Le processus d'amélioration continue par élimination des causes de défauts est un des piliers du TQM. Il y est précisément défini et formalisé. La littérature est abondante. On peut citer [4] à titre d'exemple -- parmi beaucoup d'autres.

Le terme « analyse causale » désigne cette démarche. Il est peut-être moins ambigü que « action corrective » pour non-initié de la qualité.

Développement Logiciel et Erreur Humaine

En logiciel, remonter du défaut (le bug) à sa cause renvoie bien souvent à une erreur humaine, erreur de conception, de codage, de compréhension, etc.

Les « 5 M » mentionne la Main d'oeuvre comme contributeur des processus, et de leur variabilité :

diagramme 5M

Les « 5 M » ont été introduits en production de biens comme moyen de rechercher systématiquement les causes de défauts (AMDEC, Diagramme d'Ishikawa). En production, les « Moyens » représentent les machines, facteurs significatifs de variabilité et de défaut dans le processus. La main doeuvre sera plus souvent identifiée comme cause de défaut par manque de formation ou par non-respect d'un standard de fabrication.

En développement logiciel, la Main d'oeuvre devient le contributeur majeur parmi les 5M. On pourra parfois incriminer le milieu (ambiance sonore ou perturbée) ou les moyens (manque d'outils tel que gestion de configuration, gestion documentaire), mais cela reste marginal tant il est facile d'y pallier compte tenu de l'enjeu. Les Méthodes font l'objet d'intenses réflexions : le « génie logiciel » est jeune encore. Pour une réflexion sur les méthodes et leurs lacunes inhérentes au logiciel, voir l'article de F. Brooks « No Silver Bullet » [1] qui reste toujours d'actualité.

Le tableau ci-dessous (© CNAM/CMSL) fournit une typologie d'erreurs « courantes » en développement logiciel.

Erreurs courantes png

Dans certains cas, on peut agir sur la cause :

Le plus souvent, on se rend compte à la lecture du tableau qu'il ne s'agit que d'une étape dans le cheminement vers la cause du défaut. Il faudrait aller plus loin et réïtérer le « pourquoi » :

Vaste programme. On peut quand même se reporter aux études de A. Cockburn, dont [2] "Characterizing People as Non-Linear, First-Order Components in Software Development". Cette étude pointe sur 4 caractéristiques humaines principales dans le développement logiciel :

  1. People are communicating beings, doing best face-to-face, in person, with real-time question and answer.
  2. People have trouble acting consistently over time.
  3. People are highly variable, varying from day to day and place to place.
  4. People generally want to be good citizens, are good at looking around, taking initiative, and doing "whatever is needed" to get the project to work.

La caractéristique 2 fait clairement obstacle à la maîtrise du processus logiciel, c'est à dire à la maîtrise de sa variabilité, son caractère prédictible et répétable.
La caractéristique 4 est précisément celle qui permet de « s'en sortir », dans un processus logiciel que l'on ne peut décidément par confier à des machines, tant il nécessite d'invention et d'initiative.

Pour l'anecdote, on commence à trouver dans la littérature des essais sur l'application de la Maîtrise Statistique des Processus au processus logiciel [3]. Toutefois la MSP indique clairement que la première étape est d'avoir un processus « sous contrôle », ce qui est encore loin d'être le cas en logiciel.

Analyse causale

Dans le cas du développement logiciel, du fait de l'importance écrasante du facteur humain, on pourrait donc se poser la question de l'intérêt de l'analyse causale:

  1. la correction du bug n'a-t-elle pas, sauf exception, traité définitivement le problème ? -- rechercher la cause est donc « inutile »
  2. traiter la cause du bug renvoie à l'humain et est une tâche autrement ardue, même si elle aurait eu l'avantage de traiter plus généralement des « types » de bugs.

On peut quand même appliquer l'analyse causale sous une forme « faible », en considérant non la problématique du bug, mais celui de sa (non) détection.

Cette adaptation accepte le développeur « imparfait » comme il est. Elle reconnaît qu'il peut faire, et fera encore, des erreurs. Par contre elle le responsabilise sur la qualité de sa production livrée, dont la garantie est fournie par les tests unitaires. Ce sont les tests unitaires qui font la qualité de sa livraison. On n'interroge pas le pourquoi du bug, mais pourquoi il a pu passer la phase de tests unitaires sans être détecté. La cause sera l'insuffisante couverture des tests unitaires -- sur laquelle on peut agir -- plutôt que l'imperfection des hommes.

Ce point est essentiel. L'engagement de l'équipe de développement (codage et test unitaire) n'est pas de fournir du code qui devra ensuite, en phase de test, être « déverminé ». Son engagement est de fournir un code correct, qui seul a de la valeur. Mieux, son engagement doit être de fournir un code correct et dans lequel on a confiance. Ce dernier point justifie une forte attention aux tests effectués.

Le livrable en sorti de production est un « code testé ». En terme de processus de développement, l'anomalie n'est pas que le code comporte un bug : le code est un artefact interne à la phase de production. L'anomalie est que le comporte toujours un bug après la phase de test.

Ainsi la découverte d'un bug doit entraîner une double action :

  1. correction du bug
  2. analyse causale: analyse de la couverture des tests unitaires.

L'analyse causale doit permettre d'identifier les lacunes des tests unitaires : quels tests manquent-il pour assurer que l'équipe ne puisse plus livrer cette fonction avec des bugs ? Cette analyse causale sera suivie bien évidemment par la mise à jour (couverture plus complète) des tests unitaires.

Pour trouver sa pleine efficacité, une telle approche doit être appliquée conjointement avec l'utilisation de tests automatiques. L'analyse causale examinera, et conduira à compléter, le jeu de tests automatiques.

Références

[1] Fred P. Brooks, No silver Bullet, Computer Magazine; April 1987.
http://www.apl.jhu.edu/Classes/635431/felikson/Publications/No_Silver_Bullet_Brooks.html

[2] A. Cockburn, "Characterizing People as Non-Linear, First-Order Components in Software Development", presented at the 4th International Multi-Conference on Systems, Cybernetics, and Informatics, Orlando, FL, June 2000.
http://alistair.cockburn.us/crystal/articles/cpanfocisd/characterizingpeopleasnonlinear.html

[3] Anita Carleton, Statistical Process Control for Software, SEI 2001.
http://www.sei.cmu.edu/str/descriptions/spc_body.html

[4] Shiba, Graham, Walden, TQM: 4 révolutions du management, Dunod.


© Akelaï Conseil 2006-2018. Akelaï Conseil encourage l'usage de navigateurs internet respectueux des normes : Google Chrome, Firefox, Opera, Safari.

Valid CSS Valid XHTML 1.0