Dans le premier post de cette série ‘Comment choisir un outil d’analyse de code ?’, nous avons cité 4 critères fréquemment mis en avant alors même que leur importance varie en fonction de ce que vous souhaitez faire.

Nombre de technologies analysées

Ne choisissez pas un outil uniquement parce qu’il sait aussi analyser du PL1 ou du Powerbuilder si ces technologies représentent moins de 10% de votre système d’information.

Vous ne développez pas de nouvelles applications avec ces langages, vous attendez que les applications existantes meurent ou soient migrées. Et vous le savez bien, l’investissement d’un éditeur logiciel sur une technologie est proportionnel aux ventes : un analyseur PL1 n’offrira jamais le même niveau de fonctionnalités qu’un analyseur J2EE. Ne les mettez pas sur le même plan.

Nombre de métriques

La plupart des cas d’utilisation d’un outil d’analyse de code – Continuous Integration / Improvement, Quality Gate, Gestion de l’outsourcing – s’appuient sur ensemble réduit de 10 á 20 métriques. Identifiez les métriques critiques pour les Use Cases que vous souhaitez implémenter. Identifiez ensuite les métriques qui vous paraissent intéressantes ou utiles. Le reste est du ‘nice to have’.

Possibilité de créer de nouvelles métriques

Pourquoi 90% des utilisateurs d’un outil d’analyse de code sont satisfaits des métriques fournies ? Parce qu’elles correspondent à des standards du marché. Evitez de jouer à l’apprenti sorcier en créant vos propres standards : cela vient avec un coût, de développement, de maintenance, d’implémentation et de support à chaque upgrade de l’outil.

Liens entre composants

Sur les 3 technologies le plus souvent rencontrées – J2EE, Cobol, SAP – seule la première est multi-tiers. Si vous utilisez des frameworks J2EE, des métriques basées sur les liens entre composants peuvent s’avérer utiles. Retenez néanmoins qu’elles représentent une faible proportion du total des règles, et que leur utilisation présente un coût, notamment dans la validation des false-positives.

Voyons maintenant 3 critères que j’estime réellement importants.

Modèles Qualité multiples

L’ensemble des métriques et leur organisation sur différents facteurs constituent votre modèle Qualité, la grille de mesures selon laquelle vous allez évaluez la qualité de vos applications. Plus vous disposez de souplesse dans la constitution de différents modèles, plus fine sera votre évaluation.

A partir de combien de lignes un programme Cobol est-il très volumineux ? A partir de combien points de complexité (CC) est-il très complexe ? Les programmes Batch sont plus lourds que les programmes TP (transactionnels) et il est souhaitable de pouvoir affecter des seuils différents sur ces métriques. Dans le cas contraire, une équipe de projet qui doit effectuer la maintenance d’une application Batch sera pénalisée par rapport à une équipe qui gère une application TP.

Autres exemples :

• Une base de données croît avec l’accumulation de ‘data’ et au fil du temps, certaines ‘bad practices’ de programmation SQL vont commencer à produire leurs effets, néfastes pour la performance des applications. N’attendez pas d’être dans le rouge avec les seuils par défaut : pouvoir hausser le niveau de criticité autorise une gestion pro-active des risques de non-performance.
• Vous savez combien coûte un projet d’upgrade de versions SAP ? Vous savez le nombre de jours nécessaires à identifier les composants qui cesseront de fonctionner parce qu’ils utilisent des syntaxes non supportées par la nouvelle version ou parce qu’ils accèdent au noyau SAP ? Ou bien vous avez une application C++ destinée à piloter des caisses enregistreuses de différentes marques avec des OS distincts. Dans de tels cas, la portabilité du code devient le facteur le plus critique de votre modèle Qualité.

Il n’existe pas de Quality Model unique : autant vouloir mesurer des pommes et des patates. Pouvoir définir et choisir un modèle qualité adapté à une application donnée est un critère plus important que ceux listés précédemment.

Personnalisation du tableau de bord

Les résultats des métriques calculées sur le code source de vos applications apparaît dans un ‘dashboard’ ou tableau de bord du pilotage de la Qualité. La capacité à personnaliser ce dashboard en fonction des use cases, des technologies ou même d’une simple application est un facteur de succès de votre projet Qualité.

Imaginons qu’on vous demande d’effectuer un audit d’une application critique et d’en présenter les résultats aux architectes et à l’équipe de projet. Au dernier moment, avant d’entrer dans la salle, on vous annonce que le directeur informatique sera présent. Celui-ci arrive pour se plonger immédiatement dans la lecture de ses mails sur son Blackberry. Que faites-vous pour l’intéresser à votre présentation ?

Simple. Montrez lui combien lui coûte cette application.

Un architecte Java ou un responsable Qualité sait ce qu’est la Complexité Cyclomatique ou une métrique telle que LCOM4. Je peux donc leur présenter un dashboard avec certaines métriques (LOC, CC, taux de commentaires ou de code dupliqué, …), passer á la liste des défauts les plus graves et conclure par un bilan qualitatif et quantitatif.

Pour un directeur informatique, un responsable Etudes ou un manager Outsourcing, je vais commencer par un bilan financier. Je veux pouvoir afficher la dette technique en haut de la première page du tableau de bord, descendre ensuite sur des axes fonctionnels tels que la maintenabilité ou la fiabilité de l’application, puis une liste d’indicateurs présents dans un SLA (Accord de niveau de service) et terminer par un plan d’action.

Imaginez que vous puissiez construire par drag and drop n’importe quel tableau de bord, avec un utilisateur á vos côtés en lui disant : ‘Tu veux çà ?’, ‘Ce diagramme là en premier ?’, ‘Quels indicateurs t’intéressent d’abord ?’.

Cà c’est un critère important.

Intégration avec d’autres outils

Vous le savez déjà, plus tôt un défaut est identifié, moins il est coûteux à résoudre. Et le plus tôt pour identifier un défaut, c’est quand le programmeur vient de l’écrire. Comme disait un responsable Etudes : « Si j’ai 30 développeurs sur une application, je ne vais pas attendre la fin de la semaine pour repérer leurs bugs ». A 5 jours par semaine et par programmeur, cela fait 150 jours de défauts qui s’accumulent.

Idéalement, vous souhaitez :

• Pouvoir gérer les composants d’une application au sein d’un référentiel de gestion de version ou de configuration.
• Pouvoir déclencher un build (nouvelle version) de l’application chaque fois qu’un développeur crée une nouvelle version d’un composant au sein du référentiel. De cette manière, vous pouvez vérifier que la version compile correctement et déclencher automatiquement une analyse du code source afin de repérer au plus tôt tout nouveau défaut.
• Disposer d’alertes automatiques sur la survenance de certains défauts ou d’un tableau de bord qui vous permette de réviser facilement l’apparition de nouveaux défauts et demander une correction.
• Mettre á jour automatiquement la liste des tâches de chaque développeur avec les corrections à effectuer.

Pour plus de détails, voir également ‘Amélioration continue de la qualité‘.

Coût

Evidemment, ce sera un critère déterminant de votre choix d’outils, et il faudrait un article entier afin d’en discuter. Je voudrais simplement noter l’apparition de nouveaux modèles de coût.

Tout le monde connaît le modèle traditionnel basé sur une licence par utilisateur qui se caractérise par un coût initial plus ou moins élevé – selon le nombre de licences, d’éventuels modules additionnels et d’autres facteurs tels que la fin de trimestre ou la fin d’année lorsqu’un éditeur logiciel s’avère plus facilement disposé á quelques concessions tarifaires.

Le monde Open Source a amené de nouvelles pratiques avec une licence par serveur d’analyse et non pas par utilisateur et un modèle économique axé sur le service : vous ne payez plus la maintenance mais un support de plus haut niveau. Quelle différence ? Vous pouvez cesser de payer sans perdre pour autant le bénéfice de nouvelles mises à jour ou le support de la communauté.
Enfin, on voit apparaître de plus en plus des solutions de type SaaS, avec un coût á l’utilisation ou sous forme d’abonnement.

Je me suis livré à quelques simulations et je vous encourage à faire de même. Quelques conclusions, trop rapides et qui nécessiteraient d’être affinées, mais :

• Le modèle ‘licence’ est plus coûteux que le modèle ‘souscription’ (Open Source / Saas) sur les premières années ; le modèle ‘souscription’ peut – éventuellement – devenir plus coûteux au bout d’une période assez longue (8 à 10 ans minimum).
• La réussite du modèle ‘souscription’ est fortement dépendante du taux de renouvellement.

Une différence de plus ou moins 5% dans le renouvellement des souscriptions impacte énormément la rentabilité et la valeur d’un éditeur type SaaS ou Open-Source. Vous comprenez pourquoi il a intérêt à vous soigner.

En conclusion, basez vos critères de choix sur une identification précise de vos besoins, centrée sur votre portfolio applicatif et les cas d’utilisation que vous souhaitez implémenter.

Je tenterai d’illustrer certains de ces cas dans le futur. Dans l’attente, n’hésitez pas à faire part de vos commentaires.

Ce article est également disponible en Leer este articulo en castellano et Read that post in english.