La performance en développement logiciel, une question de métriques

Voir la version AMP

L’évaluation de la performance d’une équipe de développement logiciel dans le cadre d’un projet de développement logiciel peut varier grandement selon le type de métriques utilisées aux fins de l’évaluation.

Cette requête de mesure de la performance au niveau des projets de développement revient constamment et constitue une source de préoccupation majeure chez les Gestionnaires; ce qui est tout à fait normal considérant le faible ratio de projets livrés dans les temps et les coûts.

La question demeure : comment se fait-il que mon contracteur immobilier soit en mesure de me certifier que ma maison possédant les caractéristiques ABC sera livré pour le 30 juin mais que mon directeur TI non seulement ne réussit-il pas à me livrer mon projet TI (les fonctionnalités escomptés) dans les délais prévus mais il ne peut pas plus me dire quand, au final, mon projet sera terminé ?

Dans nos billets précédents, nous avons parlé de type de gestion, de processus et d’innovation.  Dans ce billet-ci, nous voulons analyser et démystifier la notion de métrique car c’est elle qui sera en mesure de nous donner les indicateurs de performance nous permettant de nous évaluer et de nous comparer…

Le fait est qu’il y a plusieurs approches possibles et, en ce sens, l’évaluation de la performance est aussi beaucoup une question de méthode.

On pourrait, par exemple, mettre l’emphase sur la quantité de codes ou de fonctionnalités livrées; d’autres voudront plutôt mesurer la qualité du code ou des fonctionnalités livrées. Et d’autres encore prendront en compte l’exécution finale en regard des objectifs visés par le projet, des coûts du projet, du temps de livraison du projet ou encore des bénéfices du projet pour l’entreprise ou les départements concernés.

La grande question est comment évaluer la performance de l’équipe de développement dans le cadre d’un projet TI d’une manière constante; peu importe le pays, la technologie, le type de gestionou le secteur d’activités.

Bref, existe-t-il une mesure universelle de la performance en développement logiciel ?

 

Métriques de la Performance en Développement logiciel

La réponse est « oui »; les FFP, Full Functional Point du modèle CMMI, Capability Maturity Model Integration.

CMMI a été créé à l’origine par le département de la défense US (DoD) pour assurer le suivi des développements et des budgets sous l’appellation CMM. Par la suite, en absorbant d’autres spécifications relatives, le référentiel s’est adjoint la lettre I pour Intégration. CMMI a pour finalité essentielle de mesurer la capacité des projets à s’achever correctement en termes de délais, de fonctionnalités et de budget. (source : piloter.org)

Bien que nous ne nous considérions pas chez Analystik comme des « gourous CMMI », nous en appliquons plusieurs principes de base dont l’évaluation de nos projets de développement via la métrique FFP, le « Full Functional Point ».

Un point fonctionnel est une activité de base en développement logiciel telle la lecture, l’écriture, l’entrée et la sortie d’une donnée. Cette notion est liée à la notion de « processus fonctionnel » qui, lui, traduit le concept de « traitement des données » et comptera plusieurs points fonctionnels tel qu’illustré dans les trois schémas ci-dessous.

Functional ProcessFFP
Source : COSMIC
Source : Software Engineering by K.K. Agarwal & Yogesh Singh (2007)

Ainsi, combien d’heures devrons-nous consacrer par point de fonction (FFP) pour nos différents projets logiciels ?  Cette métrique nous permettra non seulement de nous comparer à notre industrie tout en tenant compte de nos spécificités, mais aussi de mieux planifier nos futurs projets de développement logiciel.

Le nombre points de fonctions, normalement, pour un même projet sera le même, peu importe la technologie ou l’endroit dans le monde ; ce qui varie d’une équipe de développement à l’autre est le ratio Nombre d’heures / FFP que l’on nomme la vélocité.  Pour le directeur TI, LA métrique qui l’intéressera sera la vélocité de ses équipes de développement, toujours en tenant compte des contraintes propres à chaque secteur d’activités.

Par exemple, est-ce que la documentation technique dans notre industrie entraîne un surplus de travail ?

Autre exemple, un projet bancaire qui impose des normes de sécurité et de confidentialité très sévères ajoutera nécessairement une charge de travail plus lourde sur le traitement, le transfert, la lecture, l’écriture et l’archivage des données que le développement d’un logiciel d’automatisation d’une chaîne de production.

Le projet bancaire donnera peut-être une vélocité de 30 hres / FFP alors que le projet industriel de chaîne de production donnera une vélocité de 15 hres / FFP; qui sait ?

Conclusion

Finalement à partir du moment que tous nos projets de développement logiciel sont évalués d’une manière standard, reproductible et comparable; au fil des projets, il nous sera possible d’évaluer la performance de notre équipe de développement logiciel et d’établir des barèmes de développement selon la nature des projets.

La notion de performance sera toujours relative à notre secteur d’activités… et notre niveau de maturité !

La performance tout comme l’univers est une question de relativité; encore faut-il être en mesure de la quantifier !

 

Denis Paul & Michel

 

 

Laisser un commentaire

Votre adresse de courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *