La Gestion des Anomalies pour les DSI
L’implémentation de processus de gestion des anomalies n’est pas un élément sur lequel les DSI perdent trop de sommeil. Peut-être à tort. Cet article définira cinq aspects clé qui devraient être suivis par les DSI et responsables de développements logiciels, qu’ils externalisent ou non les développements et les tests.
Pourquoi une Gestion d’Anomalies ?
Bien entendu pour gérer, mais pas uniquement. Une anomalie est souvent le reflet d’une défaillance dans les processus de conception. Les mêmes causes ayant les mêmes effets, tant que cette défaillance n’est pas corrigée, des anomalies similaires apparaitront. La correction d’anomalies impacte les délais – et les coûts – des livraisons de logiciels aux utilisateurs et clients. DSI ou Responsables de Développements doivent limiter ces impacts, et optimiser les processus, en mesurer l’efficacité et en améliorer la rentabilité. Une gestion d’anomalie est donc une source d’économies potentielles.
1. Mesurer et Informer Une gestion d’anomalies complète doit :
– identifier les processus les plus coûteux (ceux qui génèrent le plus d’anomalies),
– mesurer l’efficacité des processus de détection (revues ou tests), et
– permettre d’anticiper les livraisons.
Parmi les informations à fournir par la gestion d’anomalies, nous avons :
– Le nombre de défauts trouvés, corrigés, et à corriger (voir Figure 1)
– Les composants ou fonctionnalités avec le plus de défauts (voir Figure 2)
– Les durées moyennes de correction des défauts (voir Figure 3)
– Le coût des anomalies et les économies potentielles
– Les causes d’anomalies, et les processus défaillants (voir Figure 4).
Pour prendre des décisions en temps utile, vous devez mesurer périodiquement l’écart par rapport à des objectifs initiaux. Ceci implique des données correctement introduites et un reporting identifiant les tendances.
2. Tirer des Leçons des Anomalies
Une anomalie – corrigée ou non – a un coût, et indique un dysfonctionnement dans les processus de conception. Tant que ces processus ne sont pas corrigés, des anomalies de même type se reproduiront. Une analyse des causes racines des anomalies est connu, souvent coûteuse et non généralisable pour chaque anomalie. D’autres techniques existent et ont fait leurs preuves. Elles nécessitent souvent une expertise spécifique pour être mise en place efficacement, sans cela les bénéfices seront absents, et les livraisons en retard.
3. Ne pas travailler en silos
Souvent les équipes de conception, de réalisation et de support utilisent des outils de gestion de défauts différents et ne communiquent pas entre eux. Chaque équipe a ses propres outils – ou n’en a pas – et n’échange pas automatiquement avec les autres équipes. Les exigences font l’objet de revues, mais les anomalies identifiées en revues ne sont pas introduites dans le même outil de gestion d’anomalies. Donc on n’identifiera pas les documents de mauvaise qualité, ni le besoin d’amélioration d’exigences.
Les anomalies identifiées par les développeurs (lors des tests unitaires) sont-elles enregistrées dans l’outil de gestion des anomalies ? Souvent, elles sont corrigées sans être remontées. Les causes racines de ces anomalies ne seront ni identifiées ni corrigées. Si les équipes de test et de développement ne partagent pas le même outil, des informations se perdront, et donc de la valeur (et des possibilités d’améliorations).
Nous pouvons réfléchir aux équipes de support client, sollicitées pour les défauts trouvés en production. Les informer des défauts non corrigés réduira la durée des appels clients (un gain de temps mesurable). Obtenir, de la part des équipes de support client, les anomalies trouvées en production, identifiera des domaines omis par les testeurs. Remonter aux analystes métier les demandes des clients à l’équipe support, identifiera de futurs axes de développements.
Il est important de ne pas travailler en silos séparés, et l’outil de gestion d’anomalies permet de partager des informations utiles aux divers acteurs, pour autant que les données brutes soient introduites par les divers acteurs.
4. Adapter l’outil aux besoins
Il existe de nombreux outils de gestion d’anomalies, gratuits ou payants, en shareware, en Open Source ou commerciaux. Leur installation initiale est souvent simple, cependant les éléments de reporting fournis en standard sont limités. Beaucoup des données de classification, nécessaires à l’élaboration des rapports mentionnés dans cet article, sont absentes. Pour obtenir la pleine rentabilité de votre outil de gestion d’anomalies, vous devrez (selon la méthode GQM) : définir vos objectifs de gestion, identifier les questions à poser et déterminer les métriques à mesurer.
Pour mesurer le nombre de défauts trouvés, corrigés, et à corriger, puis le remonter de façon cohérente (cf. Figure 1), vous devrez concevoir un graphique comprenant 5 axes, qui n’est généralement pas fourni en standard dans les outils de gestion d’anomalies. Il faudra passer par des échanges de données et des graphiques générés par des tableurs.
Pour identifier la durée moyenne de correction des défauts (cf. Figure 3), vous aurez besoin de données de dates dont la fourniture peut être automatisée, mais non standard. Ainsi vos équipes devront adapter l’outil, rajouter des champs et veiller à ce qu’ils soient remplis.
En fusionnant les informations d’anomalies provenant des divers sources identifiées plus haut (cf. §3) et les coûts (de développement, de test, de correction, et de support), vous saurez déterminer le taux d’efficacité de vos activités de développement et de recette, et les améliorer. Ces informations sont essentielles pour les DSI et Responsables de Développement.
5. S’améliorer continuellement
Pour les causes d’anomalies, et les processus qui les génèrent (cf. Figure 4), seuls huit champs sont nécessaires (activité, impact, déclencheur, composant cible, type d’erreur, type de correction, source et âge). Ces champs doivent être introduits par les testeurs, et par les développeurs. Ces champs ne sont pas présents par défaut dans les outils de gestion d’anomalies.
L’analyse des informations liées à ces données, (p.ex. via des rapports tel celui Figure 4) associe les processus de conception et le nombre d’anomalies qu’ils génèrent. Responsable de Développement, ou au DSI, identifieront les processus de conception à améliorer, et optimiseront les développement futurs.
6. Synthèse
Au vu de l’impact des défauts (à la fois en termes de délais et de coûts), il est impératif d’améliorer la rentabilité et l’efficacité des processus de conception et de test. Une gestion d’anomalies optimisée est nécessaire. Des techniques simples comme GQM (GQM : Goal Question Metric, Méthode proposée par Victor Basili, hors du scope de cet article) et ODC (ODC : Orthogonal Defect Classificatoin, méthode proposée par IBM dans les années 1980) peuvent limiter le nombre et l’impact des anomalies (p.ex. retards des livraisons). Cela nécessite :
– d’adapter les outils disponibles, – de définir des exports de données,
– d’obtenir les graphes et rapports adaptés à vos besoins.
Ceci n’est pas trivial et dépasse le cadre simpliste de suivi d’anomalies proposé en standard. DSI et responsables de développements doivent définir leurs besoins et ne pas ignorer cette source d’informations souvent méprisée.
B. Homès
Bernard Homès
Président TESSCO sas
Fondateur et ex-président du Comité Français des Tests Logiciels
( bhomes@tesscogroup.com )
Bernard Homès (55 ans) bénéficie d’une expérience de plus de 33 ans dans le domaine de la Qualité et des Tests de logiciels. Il a occupé différents postes clefs à dimension internationale, en Amérique du Nord et en Asie. Depuis 2000, il exerce en qualité de Consultant Senior pour le compte d’entreprises renommées dans l’aéronautique, le spatial et les télécommunications. Bernard possède plusieurs certifications en test (CMAP, ISTQB CTFL, CTAL-TM, CTAL-TA, CTAL-TTA) et en gestion des exigences (IREB et REQB), et se focalise sur le transfert de connaissances, la formation et l’amélioration de la rentabilité des projets de test.
Bernard est également intervenu en dernière année du Mastère au sein de l’École des Mines de Paris et de HEC, dispense de nombreuses conférences chaque année et s’implique au sein de nombreuses organisations professionnelles (jury de l’Académie d’experts de France Télécom R&D, groupe de travail et auteur du Syllabus Avancé de l’ITQSB, bureau exécutif de l’IEEE France, membre fondateur de l’Association for Software Testing aux USA, du GASQ et du CFTL.
[…] […]
[…] […]