Dans le domaine industriel, les indicateurs de performance sont notamment construits à partir des dépenses (matériels, salaires, etc.) et des quantités produites.

Dans le monde du logiciel, les coûts de personnel sont les principales dépenses.  Mais le logiciel est plus intangible (au moins en apparence) que des produits tels que les voitures, les tables, les maisons ou les téléphones portables.

Mesurer la performance d’un département IT

Quand il s’agit de produire des indicateurs de performance, autres que purement financiers, la question à laquelle il faut répondre est : « Sommes-nous meilleurs que nos concurrents ? ».

Les indicateurs les plus classiques permettent de répondre aux questions suivantes :

• Quelle est notre productivité en matière de développement de logiciel ?
• Où se situe notre productivité par rapport au marché ?
• Notre productivité s’améliore-t-elle, ou au contraire, se dégrade-t-elle ?
• Quel est notre niveau de qualité ?
• Où se situe notre qualité par rapport au marché ?
• Comment la taille d’un projet ou d’un produit affecte-elle la productivité et la qualité ?
• Comment les développements multisites affectent-ils la qualité et la productivité ?
• Comment des initiatives CMMI, Lean, et Agile, ont-elles contribué à créer de meilleurs produits, et plus rapidement ?
• Quel a été le retour sur investissement de ces initiatives ?

Il est intéressant de noter que si nous pouvons répondre aux questions ci-dessus, alors nous sommes capables de fiabiliser les estimations de projets et donc les budgets.

Il faut également noter que la plupart des indicateurs ci-dessus nécessitent de mesurer la quantité de logiciel produite. C’est un élément central de la mesure de la performance d’un département IT. Il ne s’agit pas de mesurer le nombre d’heures, d’homme.jours ou les revenus. La quantité de logiciel c’est le volume de logiciel produit, ni plus ni moins.

Mesurer la performance des projets

Dans le domaine du projet logiciel, la mesure de la quantité de logiciel est utile pour produire les indicateurs suivants :

• Définir le périmètre du projet,
• Évaluer l’impact de la migration d’une application,
• Évaluer le coût de remplacement d’une application,
• Négocier le périmètre d’un projet,
• Évaluer les exigences,
• Estimer les ressources nécessaires au projet,
• Allouer les ressources de test,
• Évaluer les risques,
• Phaser le développement,
• Alerter quand la taille du logiciel augmente,
• Gérer le rework,
• Planifier les ressources de support,
• Benchmarker,
• Identifier les meilleures pratiques,
• Planifier les nouvelles releases,
• Évaluer le parc applicatif,
• Négocier les contrats d’outsourcing (développement, production et support),
• Etc.

Le défi : comment calculer simplement la taille logicielle ?

La mesure la plus connue et normalisée ISO, est la mesure en Points de Fonction IFPUG. Mais cette mesure est compliquée et nécessite de faire appel à un expert. Ceci explique que les Points de Fonction IFPUG soient largement promus par les cabinets de conseils.

Il existe cependant d’autres mesures de la quantité logicielle, qui sont normalisées, et bien plus faciles à mettre en œuvre (Simple Function Point, ou COSMIC Function Point, par exemple).

Conclusion

Ne pas mesurer la quantité de logiciel, et construire ses indicateurs de performance uniquement sur les heures ou le nombre de jours.hommes, c’est comme payer son plein d’essence en fonction du temps que met le pompiste à remplir le réservoir, plutôt qu’en fonction du volume d’essence livré.

La mesure de la quantité logicielle permet de passer d’une logique de jour hommes, à une logique de quantité produite, comme dans le monde industriel.