La complexité de l’ingénierie logicielle a nécessité des travaux importants pour identifier les bonnes pratiques de développement et éviter les échecs des projets. Cela a donné naissance à des modèles de maturité comme le CMMI (Capability Maturity Model Integration) qui, selon les activités mises en œuvre dans les projets et les organisations, détermine un niveau de maturité de l’estimation, autrement dit, la capacité à « industrialiser » les activités de développement de logiciel dans le cadre d’une démarche d’amélioration continue.

Nous proposons dans cet article un modèle de maturité qui s’inspire du modèle CMMI, mais qui n’est pas le CMMI.

Estimation de projet logiciel : les bas niveaux de maturité de l’estimation

C’est typiquement le cas des organisations qui n’ont pas ou très peu défini leur processus d’estimation. À la question « comment estimez-vous vos projets ? », la réponse est généralement « nous nous appuyons sur l’expérience des chefs de projet ».

Cette expérience ne s’appuie généralement pas sur des données historiques organisées. Ce n’est donc qu’un « avis » subjectif pouvant être facilement remis en cause par le management. Sans données objectives, c’est souvent l’avis du plus « gradé » qui prévaut.

Or, une méthode d’estimation immature va conduire à une estimation basse (optimiste). Et une estimation optimiste conduit généralement à l’échec du projet.

Les conséquences sont des dépassements de budgets et de délais, une mauvaise image auprès des clients / utilisateurs, des surcoûts de gestion de projet, et du stress inutile.

Une organisation de bas niveau de maturité évalue un nombre de jours homme, sans prendre en considération la quantité de logiciel à développer. C’est comme si vous achetiez votre plein d’essence en fonction du temps que met le pompiste à remplir votre réservoir, plutôt qu’au volume d’essence livré.

Dans une relation de sous-traitance, un processus d’estimation immature va conduire généralement à choisir le moins disant.

Pour bien comprendre, cette notion de maturité de l’estimation, on peut proposer une image de chacun de ces niveaux :

 

Au niveau 1 :

L’effort global est estimé, au doigt mouillé, de manière informelle, sans ou avec peu de contradicteurs. Aucun ou peu de détails ne sont fournis dans ce que comprend l’estimation. Aucun retour d’expérience n’est effectué.

 

Au niveau 2 :

Les efforts des principales activités sont estimés à dire d’expert, avec des contradicteurs, et ils alimentent une feuille de calcul. L’effort du projet est la somme des efforts. Généralement l’effort de développement et tests unitaires sert de base au calcul des autres activités qui sont calculées par ratios.

Au niveau 3 :

L’organisation a adopté une mesure formelle de la taille du logiciel, comme les Point de Fonction.

Quelques mesures de bilans de projet ont permis de confronter la taille du logiciel développé avec l’effort dépensé. De ces mesures de bilans sont déduites la productivité moyenne ainsi que la ventilation des efforts dans les activités du projet. Le modèle d’estimation ne comprend généralement qu’un paramètre : la taille. L’effort se calcule comme suit :

Effort = Taille x Productivité

 

Au niveau 4 :

L’organisation a défini plusieurs processus d’estimation selon la phase du cycle de vie du projet où l’estimation est demandée (macro-chiffrages, spécification générales, spécifications détaillées, etc.). Ces différents processus d’estimation mettent en œuvre différentes techniques d’estimation, et différentes méthodes de mesures du logiciel (mesures approchées, mesures formelles). Différentes productivités sont identifiées selon les technologies, la localisation, etc. Les modèles d’estimation paramétrés comprennent généralement moins de 10 paramètres.

L’organisation s’efforce de comparer le prévu avec le réel pour enrichir sa base d’historique de projet.

 

Au niveau 5 :

L’organisation exploite son historique de projets pour mener des analyses avancées et enrichir ses modèles d’estimation. Les modèles paramétrés peuvent comprendre un grand nombre de paramètres (parfois plusieurs dizaines). Le passage du niveau 4 au niveau 5 nécessite beaucoup de données, et, par conséquent, beaucoup de bilans de projets. Il est difficile pour une entreprise d’atteindre le niveau 5, car plus la variété de projets est importante, plus il y aura besoin de bilans de projets, et plus le coût de l’amélioration sera élevé.

Le niveau 5 ne se justifie pas toujours, tout dépend des enjeux économiques.

 

Conclusion

Le niveau de maturité du processus d’estimation va avoir des conséquences directes sur la vie des projets.

Si le processus d’estimation a un niveau de maturité bas (1 ou 2), nous sommes en générale face à des sous-estimations, entrainant des erreurs de planning, l’allocation de ressources supplémentaires au projet générant des surcoûts importants, une surveillance accrue du management générant du stress et des pertes de temps, et plus de défauts sur le projet.

D’une manière générale les estimations à dire d’expert sont en moyenne 30 % en sous-estimation.

L’effort pour passer du niveau 2 au niveau 3 n’est pas très important selon la méthode de mesure logicielle choisie (Cf article : « Quelle mesure logicielle choisir ? »). Certaines méthodes sont très simples et peuvent s’avérer très efficaces.

L’atteinte du niveau 5 ne se justifie pas toujours, car il ne pourra être atteint que si l’ensemble des processus de développements de logiciels – au sens CMMI – auront acquis un haut niveau de maturité.