Usages

Pilotage par les points de fonction

Publié le : Auteur: Anteo Consulting Laisser un commentaire
usages

Avec une récente spécification sur les points de fonction – Automated Function Point (http://www.omg.org/spec/AFP), l’OMG ravive l’intérêt d’une technique d’estimation formelle.

Les méthodes d’estimation par les points de fonction prennent leur origine dans les travaux de Allan Albretcht il y a plus de 30 ans. On peut donc facilement arguer qu’il n’y a rien de nouveau concernant une approche qui n’a pas eu l’occasion d’emporter l’adhésion de l’industrie du logiciel depuis sa création. Doit-on pour autant en rester à ce niveau de rejet basique ?

La technique d’estimation par les points de fonction est très séduisante dans la mesure où elle permet de rationaliser une discipline du logiciel, totalement artisanale autrement. Par ailleurs les approches d’estimation couramment employées introduisent un biais organisationnel qui ne permettent pas d’envisager une approche de supervision, d’analyse et d’optimisation comme on peut le voir actuellement pour beaucoup d’autres processus de la DSI.

Sur la base d’une estimation confiée au chef de projet, les organisations se privent en effet de la capacité d’évaluer objectivement la valeur d’une proposition de développement. Dans le cadre d’appels d’offre, la méthode d’écart-type entre les différentes propositions permet de réduire le biais, mais elle n’offre aucune possibilité de se référer à un étalon. On ne peut donc pas évaluer clairement la part de risque prise dans une réponse forfaitaire et cela constitue de facto un paramètre important qui va conditionner le déroulement d’un projet.

L’IPFUG (International Function Point User Group www.ifpug.org) définit un cadre méthodologique qui tend à normaliser la mesure du poids fonctionnel d’un développement logiciel. En adoptant cette approche, l’OMG lui apporte une certaine légitimité. Pour autant, on peut également citer la méthode COSMIC (http://www.cosmicon.com) qui fournit une approche plus adaptée aux méthodes de spécification système et qui peut donc s’appliquer sur une gamme plus étendue de cas logiciel, notamment pour l’estimation de services SOA.

Dans tous les cas, ces méthodes d’estimation passent par la mesure intermédiaire d’un poids fonctionnel qui constitue un premier paramètre d’évaluation significatif dans un cadre de gouvernance informatique. Le poids fonctionnel représente en effet le degré de complexité d’un logiciel et sa comparaison à la valeur-ajoutée métier est un facteur déterminant de la qualité de conception d’une solution informatique. En phase d’avant-projet, le calcul en points de fonction d’une solution peut être simplement outillé. Il permet de répondre aux questions suivantes :

  • quel est le poids obtenu et comment le réduire en révisant la spécification de la solution logiciel tout en conservant le même niveau de service métier ?
  • sur quels services métier se situent les plus gros poids fonctionnel de la solution, pourquoi, sont-ils indispensables, comment les optimiser ?
  • quel est le poids fonctionnel d’un progiciel en regard de son TCO ?

La difficulté et la critique de cette approche, réside dans l’espoir a priori vain de pouvoir introduire une technique formelle dans un cadre qui n’a rien de très formel en soi. En effet, les méthodes d’estimation consistent à comptabiliser le nombre de flux d’échange simples, moyens et complexes d’un système logiciel. Or même si un cadre normatif tente d’apporter une définition précise à ces comptages, la méthode se heurte à des disparités importantes du fait que :

  • les spécifications logiciel peuvent prendre des formes très diverses à des degrés de détail également très disparates
  • l’estimateur dispose lui aussi d’une marge d’appréciation introduisant également des biais difficilement maîtrisables
  • le passage du poids fonctionnel à la charge effective constitue encore une autre difficulté du fait de la variété de facteurs exogènes qui viennent encore pondérer l’estimation (la technologie utilisée, le processus organisationnel, le niveau de qualité exigé, la dépendance vis-à-vis de fournitures externes, etc.).

On sait par expérience que ces méthodes d’estimation ne sont au final pas transférables d’une organisation à l’autre et qu’il est effectivement illusoire de croire qu’il est possible aujourd’hui de disposer d’étalons de référence pour l’industrie du logiciel. Dans le cadre contrôlé d’une même entreprise, il y a cependant intérêt à déployer une approche d’estimation par les points de fonction, sans pour autant renoncer aux autres techniques d’estimation. Une approche par points de fonction au sein d’une gouvernance offre en effet les avantages suivants :

  • elle ne représente qu’un coût très faible de mise en œuvre : la formation de quelques personnes, et la mise au point d’un outillage assez simple, généralement à base de feuilles Excel
  • l’estimation elle-même est assez rapide. Elle représente de 0.5 à 3 jours d’effort pour les plus gros cas logiciel
  • elle est l’occasion de relire une spécification et d’en vérifier formellement la qualité. En effet l’estimateur va mécaniquement identifier les zones de flou et les manques éventuels
  • elle alimente une base de connaissance, à laquelle il sera ensuite facile de se référer, après avoir capitalisé une petite dizaine d’estimations au préalable et ‘avoir pu y associer les coûts réels projet
  • elle fournit rapidement un indicateur précieux d’estimation de risque projet (plus un projet est gros, plus il est risqué) qui aide à la décision de lancement
  • elle permet de jauger la complexité d’un projet et d’identifier les zones de solution à potentiellement optimiser, et ce dès la spécification
  • elle produit un indicateur qui permet de vérifier, voire challenger, l’estimation généralement fournie par la maîtrise d’œuvre
  • elle permet de ce fait d’évaluer le niveau de risque pris par le maître d’œuvre.

La question de fond n’est donc pas l’estimation à proprement parler, mais plutôt le degré de maturité des organisations à concevoir ou à acquérir des solutions logiciel. Même si les techniques d’estimation formelle ne produisent pas des résultats absolument fiables, leur mise en œuvre contribuent grandement à mûrir un processus critique de la DSI. C’est par ailleurs en capitalisant formellement, que les organisations sont en mesure d’alimenter leur connaissance d’elles-mêmes et de trouver des filières d’optimisation.