Estimation pilotée par les modèles

L'estimation du coût logiciel reste une question importante de gouvernance du SI, puisqu'il s'agit de calculer une charge prévisionnelle avec précision.

La vraie question de décision n'est pas cependant dans l'estimation brute d'un chantier monolithique, mais plutôt dans la capacité d'évaluer les variations de charge en fonction des options du projet. Dans une approche itérative, l'estimation d'une charge pour chaque version successive représente également un véritable élément de décision pour choisir le meilleur chemin d'avancement et mieux maîtriser les risques par les coûts.

En conséquence de quoi, la possibilité d'évaluer les impacts d'évolution ainsi que la traçabilité entre les choix d'un projet et ses charges pondérées représentent un prérequis au pilotage agile des évolutions de son SI.

Limites des approches actuelles

L'approche par points de fonction est l'approche dominante depuis près de 30 ans. Aujourd'hui, différents cabinets experts proposent des services d'estimation sur la base d'un cahier des charges et la décomposition en entrées et sorties de données élémentaires du projet considéré. Cette approche implique de "figer" le périmètre du cahier des charges, ainsi que de compter quelques jours de travail pour obtenir les chiffres demandés. Ils se conçoivent également dans le cadre de projets conséquents, ce qui exclut l'estimation des évolutions, comme particulièrement requis dans un cadre de contrat de maintenance. L'approche par les points de fonction, ne permet pas non plus de bien maîtriser l'impact d'un développement sur une architecture multi-couches, ni même de tracer les possibilités de réutilisation implicites avec les technologies orientées objet.

Des points de fonction pilotés par les modèles

L'introduction d'une approche orientée objet et des nouvelles architectures dans les points de fonction reste une solution pour mieux maîtriser les impacts et valoriser une approche itérative. Il faut cependant être capable de rapidement identifier les objets, les couches d'architecture et les interfaces embarqués dans chaque itération. Il faut également être capable de normaliser la charge afférente à chaque couche en fonction des nouvelles opportunités technologiques - une couche métier en JEE 6 est par exemple bien plus productive que dans les versions J2EE précédentes, sans parler des nouvelles opportunités MDA.

Le remplacement du cahier des charges par les cas d'utilisation est une vraie aubaine, car chaque cas d'utilisation trace les objets et les couches impliqués dans les itérations d'un projet. De plus, les points d'extension permettent de considérer avec une grande précision les changements liés à une évolution, même mineure.

Des cas d'utilisation aux modèles, il n'y a donc plus qu'un pas à franchir pour constituer un véritable référentiel d'estimation. Chaque classe et chaque interaction représentent en effet des entrées et sorties de données élémentaires qui permettent d'améliorer la technique reconnue des points de fonction, dans un système d'estimation globale.

A la différence que :

  • la réutilisation des mêmes objets par différents cas d'utilisation est prise en compte
  • la déclinaison d'un objet sur plusieurs couches d'architecture est tracée
  • les évolutions, les itérations et les options de développement sont plus facilement calculées.

Pour ajouter à l'ensemble, le couplage avec un atelier de cartographie applicative orientée modèles permet de calculer instantanément les estimations et d'évaluer très rapidement toutes les options possibles, en soutien d'un processus de décisions SI.

Pour l'avoir testé, un tel référentiel est très utile en pilotage de TMA.

Pour en savoir plus sur l'estimation du logiciel

2 commentaires

  1. L’introduction d’une approche orientée objet et des nouvelles architectures dans les points de fonction reste une solution pour mieux maîtriser les impacts et valoriser une approche itérative. Il faut cependant être capable de rapidement identifier les objets, les couches d’architecture et les interfaces embarqués dans chaque itération. Il faut également être capable de normaliser la charge afférente à chaque couche en fonction des nouvelles opportunités technologiques – une couche métier en JEE 6 est par exemple bien plus productive que dans les versions J2EE précédentes, sans parler des nouvelles opportunités MDA.

    Le remplacement du cahier des charges par les cas d’utilisation est une vraie aubaine, car chaque cas d’utilisation trace les objets et les couches impliqués dans les itérations d’un projet. De plus, les points d’extension permettent de considérer avec une grande précision les changements liés à une évolution, même mineure.

  2. Nous sommes d’accord que dans tous les cas, une « bonne » estimation requiert une connaissance fonctionnelle assez détaillée. L’approche par cas d’utilisation permet notamment de descendre plus rapidement dans la compréhension fonctionnelle et d’en mieux gérer les évolutions.
    Je reste par contre dubitatif concernant l’amélioration de productivité liée aux derniers frameworks d’architecture, voire du MDA… Mon expérience me montre que les environnements se sont compliqués et qu’ils en deviennent plus fragiles (moins résilients), mais cela ouvre un autre débat que celui de l’estimation.

Laisser un commentaire

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

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.