Lorsqu’on débute des nouveaux développements sur une application existante, on a souvent pour objectif une stratégie d’amélioration de la qualité par rapport à ce qui a été fait au préalable.
Pour cela on souhaite :
- Effectuer des actions correctrices ciblées sur le code existant : celles dont la mise en oeuvre est rapide, dont les bénéfices sont concrets et qui ne vont pas augmenter les tests de non-régression.
- Partir sur des objectifs de qualité plus ambitieux pour le nouveau code afin de ne pas reproduire les problèmes existants et de faire bien mieux dès le départ pour éviter les problèmes plutôt que les corriger.
Il est cependant difficile de concilier ces 2 approches car les outils traditionnels de qualité du code analysent l’ensemble du projet sans distinguer le code existant et le nouveau code. Ainsi lorsqu’on applique les règles souhaitées, les outils génèrent un volume important d’alertes liées au code existant. Elles noient l’équipe sous l’information, la rendant difficilement exploitable En conséquence, l’objectif de qualité perd son ambition et se limite finalement à quelques règles à appliquer sur les nouveaux et les anciens développements.
Le Cockpit permet une approche différente, en ne gardant dans son « radar » que les problèmes existants que l’on souhaite corriger pour s’assurer que l’on progresse sur ce point, tout en s’assurant que les nouveaux développements suivent des exigences plus importantes.
La mise en œuvre de cette approche est simple, rapide et s’effectue en 4 étapes:
- Effectuer un diagnostic qualité sur l’application. Ce diagnostic apporte une vision précise de la situation en s’appuyant sur une analyse automatique du code et restitue des informations qualitatives et quantitatives sur les problèmes détectés.
- Cibler les améliorations à apporter. Sur la base du diagnostic, il s’agit de choisir les problèmes à régler et de les prioriser pour adhérer aux contraintes du projet. Les résultats des analyses réalisés sur le Cockpit montrent que ce sont principalement les problèmes critiques correspondants à des « bugs » qui sont corrigés (problèmes d’accès concurrents, instructions erronées, etc.) D’autres problèmes comme par exemple les problèmes structurels (code non maintenable), ou les copier-coller excessifs sont laissés de coté car trop long à corriger ou avec un risque de régression trop important.
- Eliminer du « radar » qualité les problèmes qui ne seront pas corrigés pour le moment. Avec le Cockpit, les règles qualité peuvent-être désactivées uniquement sur des portions de code particulières (méthode(s), classe(s), module(s)), pour éviter le code existant. Le mode RAZ (remise à zéro) permet aussi de faire disparaître les problèmes détectés dans une version donnée tout en prenant en compte toute nouvelle détection. Par exemple, on ne détecte plus les méthodes existantes dont la complexité est trop importante et que l’on ne changera pas, mais on détectera toutes les nouvelles méthodes trop complexes.
- Partager cette vision avec l’ensemble de l’équipe projet et suivre la mise en oeuvre du processus. On rentre là dans l’utilisation standard du Cockpit et de ses tableaux de bords pour piloter la qualité tout au long du projet.
Lors d’une itération suivante, on paramètre le Cockpit pour inclure d’autres actions d’améliorations si nécessaire.
On a conçu cette approche pour répondre aux besoins de nos clients qui ont besoin de piloter la qualité globale du projet en distinguant les nouveaux développements et les actions d’améliorations sur l’existant. Ils l’utilisent par exemple sur les projets en maintenance que cela soit en interne ou en TMA.
