Je repensais au post précédent sur la mesure de l’effort de projet – estimer les charges de développement et de QA avant le début du projet quand on dispose de peu d’éléments de chiffrage – lorsque je suis tombé sur une annonce dans un forum sur la mesure de la Qualité logicielle, pour une conférence sur ce même sujet.

Vous savez, un de ces évènements dans lequel différents orateurs effectuent un exposé sur des thèmes comme ‘quelles métriques pour évaluer les projets’ ou des tables rondes pour discuter de ‘méthodes d’estimation des coûts de développement et de maintenance’.

L’auteur de cette annonce a demandé aux membres du forum quels thèmes de réflexion et sujets d’actualité ils souhaiteraient voir aborder lors de cette conférence, ce qui a déclenché toute une série de réponses et de réactions assez insolites, mais que je vous résume brièvement :

• Halte, stop, assez, fini, arrêtez les présentations et les ‘papers’ sur ‘Comment mesurer la productivité en matière de maintenance logicielle ?’, ‘Mesures effectives du risque’ ou ‘Utilisation des Points de Fonction dans l’industrie aéronautique’.
• Cela fait maintenant plus de 35 ans que nous disposons de métriques et pourtant les directions IT continuent d’ignorer les mesures de qualité logicielle et le nombre de projets en échec ou en retard est toujours plus important.

Et quelqu’un de commenter que « l’industrie de la mesure logicielle est dans un triste état » et que « nous pourrions en apprendre de la communauté Agile qui a intégré ces mesures dans leurs pratiques ».

Je suis complètement d’accord avec cette constatation, et cela m’a rappelé une présentation réalisée par Olivier Gaudin, co-fondateur et CEO de Sonarsource, que vous trouverez ici : Webinar: Take Continuous Inspection to Your Enterprise with Sonar 3.0.

J’ai extrait de cette présentation le slide qui me paraît le plus important quant à la vision de notre marché de la mesure logicielle, et qui va complètement dans le sens des remarques précédentes :

Remarque : la colonne de gauche indique ce qu’est aujourd’hui ce marché et la colonne de droite ce qu’il devrait être.

Analyse de code, analyse de la qualité des applications, mesure de la qualité logicielle, mesure de la qualité du code, … Il y a pratiquement autant d’appellations différentes que d’outils, merci à l’inventivité des départements marketing. Et même si ces-derniers s’en défendent, tous ces outils exécutent les mêmes fonctions, analyser le code pour identifier les violations aux bonnes pratiques de programmation et assembler différentes métriques pour les présenter à travers un tableau de bord.

Il y a 5 ans, il existait beaucoup moins d’outils sur le marché, ils étaient chers, généralement limités à l’analyse de deux ou trois technologies, difficiles à mettre en œuvre et leur utilisation réservée à des équipes Qualité transverses. Celles-ci tentaient de mettre en œuvre des processus d’audit d’applications, mais ces initiatives restaient souvent vaines en l’absence de volonté marquée du management pour généraliser ces processus sur les projets, mais également, il faut bien le dire, de la méfiance des développeurs à se voir contrôler.

Aujourd’hui, il m’arrive régulièrement de rencontrer des responsables Qualité, dont certains que j’ai connu comme anciens clients, et de les voir me confier, avec un air très embêté, que l’outil d’analyse de code qu’ils ont acheté à prix fort n’est pas utilisé, mais que les équipes de projet ont mis en œuvre elles-mêmes un processus d’Intégration Continue basé sur des outils Open Source comme Sonar et Jenkins.

Première leçon importante : la qualité des applications provient des développeurs. Vouloir contrôler les développeurs et mesurer la qualité de leur production n’a que peu de chances de réussir si ceux-ci ne sont pas complètement persuadés de l’intérêt de cette démarche et associés à celle-ci. Il est évidemment plus facile de contrôler le code fourni par une société de services, mais cela ne donnera de résultats que si ce provider met lui-même en place un processus d’Intégration Continue au sein de ses propres équipes de projet. Ou sinon, il vous faudra vous préparer à changer de provider, ce qui n’est pas si facile lorsque celui-ci est le seul à posséder la connaissance de votre code, connaissance que vous avez perdu lorsque vous avez décidé d’outsourcer vos applications.

Donc première conclusion : les développeurs sont les premiers utilisateurs d’un outil d’analyse de code et celui-ci doit s’intégrer dans une chaîne logicielle, depuis l’outil de développement jusqu’à un référentiel de gestion de configuration. Tant que les consultants Qualité voudront rester seuls aux commandes d’un outil d’analyse de code pour contrôler les développeurs, leurs efforts seront vains et ils resteront isolés. Leur rôle doit être de pousser les outils et processus Qualité au sein des équipes.

Cela nous amène à la seconde question importante : pourquoi le travail des équipes et cellules Qualité est-il ignoré par les directions TI ? Parce que les consultants Qualité, dans leur grande majorité, ne savent pas vendre la valeur des informations et du support qu’ils peuvent apporter aux directions TI et aux utilisateurs.

Les consultants Qualité s’intéressent plus souvent à la métrique elle-même qu’à son utilisation. J’en fais l’expérience constamment, chaque fois que je parle de LOC – la métrique Lines Of Code – sur un forum : immédiatement, nombre d’experts me rétorquent que l’usage de cette métrique est une ‘malpractice’ et que seuls les Points de Fonction permettent de mesurer la taille d’une application. Et je dois alors déployer des trésors de diplomatie et de longues explications pour justifier mon utilisation de cette métrique : non pas pour mesurer la taille fonctionnelle de l’application, simplement pour mesurer le nombre de lignes de code.

Lorsque vous rencontrez une personne pour la première fois, quelle est la première chose que vous remarquez ? Sa taille. Est-elle petite, moyenne ou grande ? Il en va de même avec une application, je commence par regarder sa taille. Ensuite, je peux utiliser des mesures de poids fonctionnel afin de vérifier si cette personne, pardon cette application, est ou non en surpoids.

Mais les consultants Qualité préfèrent souvent se perdre dans des querelles d’experts sur l’utilité ou non de telle ou telle métrique que de réfléchir à l’utilisation qu’il peut en être faite, et à sa valeur pour les équipes de projet, les stakeholders ou les managers informatiques. Combien de ‘papers’ pour expliquer les variantes complexes du calcul de Points de Fonction sur telle application ou sur tels types de programme ? Combien de directeurs informatiques sont capables de comprendre de tels calculs et quelle utilité pour eux ?

Je connais des directeurs de production qui ont en permanence devant eux un écran avec le tableau des alertes sur toutes les applications présentes dans l’infrastructure dont ils ont la responsabilité. Si une application critique – par exemples, de paiements bancaires – rencontre un problème – par exemple, sur les fichiers avec les données de paiement – celle-ci apparaîtra alors en rouge sur son écran, ce qui lui permettra de réagir immédiatement, avant même que les utilisateurs n’aient connaissance du problème.
Combien de directeurs informatiques, combien de responsable Etudes, combien de managers responsables d’un portefeuille d’applications possèdent-ils un tel tableau de bord sur leur écran ?

Je n’en connais aucun. Pourquoi ? Parce que la plupart des outils sont compliqués à utiliser, avec des métriques complexes à comprendre, et surtout ne permettent pas de personnaliser le tableau de bord en fonction des souhaits de l’utilisateur (à l’exception de Sonar). Donc il faut un consultant Qualité pour interpréter ces métriques afin de délivrer une information de valeur aux managers.

On trouve aujourd’hui plus d’outils que par le passé, mais je n’en vois que très peu qui :

1. S’intègrent efficacement à la chaîne de production logicielle, depuis le poste de travail du développeur.
2. Permettent d’améliorer l’efficacité des développeurs pour la production d’un code de qualité, sans surcoût/surcharge de travail.
3. Présentent une interface suffisamment conviviale et customisable, qui permette à différents types d’utilisateurs de disposer de son propre tableau de bord et des indicateurs qu’il jugera utiles à sa fonction.

Au contraire, je continue à voir des éditeurs logiciels expliquer les techniques complexes mises en œuvre par leurs outils pour détecter encore plus de défauts et dérouler la liste des métriques que seuls leurs outils savent produire, mais qui ne seront utiles que pour un architecte J2EE ou un consultant Qualité. Tant qu’il en sera ainsi, le marché pour ces outils restera, comme le fait remarquer Olivier Gaudin, un marché de niche avec des logiciels chers.

Et les consultants Qualité continueront à se demander pourquoi on ne fait pas appel à eux alors que tant de projets sont en échec ou en retard.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.