Par Michael Muller (Metrixware) : Le défi de la qualité des composants logiciels Remettre le développeur au centre du processus qualité
Le caractère a posteriori des contrôles montre ses limites
Conscients de ces enjeux, les responsables informatiques se sont depuis longtemps engagés dans une véritable démarche qualité. Mais dans le temps, le caractère a posteriori des contrôles "classiques" sur des applications en maintenance montre ses limites. Intervenant en aval des développements, ces analyses, contrôles et mesures remplissent correctement leur rôle informatif, en permettant aux responsables de l'entreprise de connaître l'état exact de leur parc applicatif à un instant T. Paradoxalement, leur rôle correctif est plus difficile à mettre en œuvre en raison de la multiplicité des points à améliorer et de leur difficile arbitrage.
Une mission d'autant plus délicate qu'elle repose entièrement sur la compréhension entre opérationnels et managers, et la formalisation d'objectifs concrets : quels composants retoucher ? Sur quels aspects de la qualité est-il urgent d'agir ? Dans tous les cas, le manager n'a pas d'autres choix que de faire confiance à la bonne volonté des développeurs, en attendant la prochaine analyse, souvent très éloignée dans le temps en raison de la masse de corrections à effectuer. Une "démarche aveugle" qui, au-delà du caractère aléatoire des actions d'amélioration à moyen terme, empêche le management de se projeter sereinement à long terme, sans aucune certitude de résultats tangibles sur la qualité de la prochaine livraison. Un ROI des efforts plus long à atteindre, qui rend alors peu aisé la justification financière d'une démarche qualité.
Fournir des outils de contrôle aux développeurs
Donner aux développeurs la possibilité d'analyser par eux-mêmes leur code et de le corriger, sans attendre l'analyse 'officielle'
Pour Jean-Louis Letouzey, consultant chez DNV IT Global Services, expert CMMI et qualimétrie : "Le succès de la mise en place d'une plate-forme automatique d'analyse de code dépend de beaucoup d'aspects tels que la définition de scénarios d'utilisation précis et la précision détaillée du modèle qualité pris en référence. On est aidé dans ce sens par les bonnes pratiques du CMMi et de la norme ISO 15939. Ces contrôles automatisés du code livré apportent des bénéfices bien connus et liés entre-autres à ce qu'on nomme l'effet radar. Ils sont très profitables pour l'organisation, mais souvent mal acceptés individuellement par ceux dont on vérifie le travail.".
Il ajoute ": "pour obtenir l'adhésion nécessaire, il faut impérativement soigner deux points décisifs lors de leur mise en place : d'une part, soigner la communication auprès des personnes concernées, d'autre part, donner aux développeurs la possibilité d'analyser par eux-mêmes leur code et de le corriger sans attendre l'analyse 'officielle' de la livraison. Qui accepterait que l'on mette en place des radars sur les autoroutes s'il n'y avait pas de compteur de vitesse dans les voitures pour permettre aux conducteurs un auto-contrôle de leur vitesse ?"
De leur côté, les développeurs, outre la désagréable sensation d'observation (voire de "flicage"), manquent d'autonomie et sont même parfois totalement écartés du processus qualité, alors même qu'ils sont au coeur du développement. Or, la réussite de toute démarche qualité passe souvent et essentiellement par l'adoption du contrôle par les opérationnels. Les sensibiliser et leur fournir des outils de contrôle directement embarqués sur leurs postes - dont ils ont la maîtrise - permet d'obtenir une appropriation forte de la démarche et des résultats immédiats, dans une posture proactive d'amélioration de la qualité de leurs projets.