Bien estimer son projet logiciel pour améliorer sa valeur business ?

Bien estimer son projet logiciel pour améliorer sa valeur business ?

L’ingénierie de l’estimation : une nouvelle discipline plus que nécessaire

Bien estimer un projet logiciel reste un défi pour les managers comme l’atteste les nombreux projets terminant hors budget ou délais. Malgré les nombreuses méthodes d’estimations existantes, les estimations sont souvent trop approximatives et peu fiables. Dans cet article, nous passons en revue les raisons de ces difficultés, donnons un aperçu des principales méthodes avant de détailler une méthode basée sur la taille fonctionnelle, applicable dès le stade d’élaboration du cahier des charges. Pour terminer, nous donnons quelques recommandations pour réussir son estimation.

Date: 27 avril 2016

Expertises:

Co-création pour le numérique 

L’estimation des projets de développement de logiciels, un défi pour les managers ! 60% à 80% des projets informatiques (1) se terminent en dépassement de budget et/ou de délais. Des dépassements, en moyenne, de 30 à 40% et parfois beaucoup plus. Et beaucoup des projets qui se terminent dans le temps et délai sacrifient la qualité. Les facteurs d’échec des projets sont nombreux, mais les deux causes principales sont les changements dans les spécifications (scope creep) et les mauvaises estimations (51% sous-estimé pour cause d’optimisme non objectif). L’impact de l’utilisation de méthodologies de gestion de projet sur la limitation des changements dans les spécifications est démontré. L’ingénierie de l’estimation des projets logiciels est une discipline assez récente, et date de seulement quelques décennies, apportent des réponses aux mauvaises estimations. Les études montrent qu’une bonne estimation permet de diminuer considérablement les risques sur un projet de développement logiciel et d’augmenter sa valeur business. Elle permet de définir des critères objectifs et de prendre des décisions bien réfléchies.

Pourquoi estime-t-on mal ?

L’estimation est une opération délicate qui doit être réalisée dans le respect de bonnes pratiques et de façon méthodologique pour être efficace et fiable. Elle est loin d’être une démarche intuitive.
Une erreur fondamentale des estimateurs est de croire qu’il peuvent rapidement calculer ou même deviner « un nombre unique » en se basant sur des outils « black-box » ou en se basant sur un manuel de recettes. Dans son keynote (2) Alain Abran compare ces pratiques au « Dark Age » lorsque les seigneurs attendaient de leurs « alchimistes » des formules magiques qui transforment l’argile en or.

Il est important de se rendre compte que l’objectif de l’estimation n’est pas de donner une valeur unique sur le projet. Chaque projet est différent, et chaque estimation doit être décrite dans le contexte du projet. L’estimateur donne une fourchette de valeurs et c’est au manager d’évaluer les risques sur le projet et de réduire la marge et de décider d’une valeur approximative finale.

Flyebjerg (2,3) a identifié trois raisons majeures pour de mauvaises estimations :

  1. Techniques : données et modèles inadéquats ;
  2. Psychologiques : L’Optimisme est le facteur qui biaise le plus les estimations. Lovallo et Kahneman (4) montrent, dans leur article « Delusions of Success : How Optimism Undermines Excecutives’ Decisions », comment les managers basent leur décisions sur un optimisme exagéré plutôt que sur des critères objectifs en terme de gain, perte et probabilités. Ils surestiment les bénéfices et sous-estiment les coûts. Comportement bien expliqué par la recherche sur les aspects cognitifs de l’être humain.
  3. Politiques/économiques : En réalisant des prévisions sur les résultats des projets, les managers ont tendance à délibérément et stratégiquement à surestimer les bénéfices du projet et à sous-estimer les coûts dans le but d’augmenter l’acceptation et le financement de leur projet

L’optimisme est nécessaire dans un projet pour motiver l’équipe et les acteurs du projet. Néanmoins, il faut le balancer par le réalisme et le baser sur des critères objectifs.

Les méthodes d’estimation

Très souvent, les chefs de projets se basent sur leur expérience personnelle pour estimer leur projet. Parfois, des techniques un peu plus structurées et basées sur le jugement d’experts (appelées aussi les non-méthodes).

Les méthodes et modèles d’estimation sont nombreux et sont répartis dans deux groupes, les méthodes non- algorithmiques et les algorithmiques (6).

Les méthodes non-algorithmiques

Les non-algorithmiques se basent sur des comparaisons analytiques et des inférences sur les projets passés. La plus simple est l’estimation par analogie et qui se base sur de comparaisons structurés avec des projets passés similaires.
La classe la plus importante de ces méthodes est celle des « Machine learning models ». Leur principe est l’apprentissage des règles d’estimation et la répétition du cycle d’exécution. On distingue deux groupes, celles utilisant réseaux neuronaux et celles basées sur les méthodes fuzzy (simulation des comportements et du raisonnement humain). Le principe d’apprentissage des règles augmente la précision des résultats de l’estimation. Néanmoins, leur utilisation reste assez limitée car difficile à utiliser.

Les méthodes algorithmiques

Les méthodes algorithmiques nécessitent des données en entrées. L’effort est calculé comme le résultat d’une fonction mathématique appliquée à un ensemble de facteurs qui impactent le coût (des cost drivers)

Effort=f(x1, x2, …,xn)

Les facteurs peuvent appartenir à différentes catégories :

  • Produit : complexité, réutilisabilité, facteurs liés à la plateforme de développement (Temps d’exécution, contrainte de mémoire…)
  • Facteurs personnels : capacité d’analyse, expérience sur le type d’application, sur le langage de développement, sur les outils de développement
  • Projet (projet multi-sites, le planning exigé...).

Ces méthodes se différencient entre elles par le type de fonction à appliquer et par les facteurs à prendre en compte dans les calculs. SLC (Source lines of code) ou COCOMO II, Modèle SEER sont des exemples de méthodes algorithmiques.
Compter le nombre de lignes de code pour estimer l’effort de développement est assez simple ce qui explique son utilisation assez répandue. Un des inconvénients est que c’est dépendant du langage de développement utilisé. Par ailleurs, on mesure le produit, or l’objet d’une estimation est souvent d’évaluer l’effort de développement le plus tôt possible. Le mieux est d’avoir une première estimation dès que les exigences les plus importantes ont été identifiées.

C’est ce que proposent les méthodes de mesure de la taille fonctionnelle (les FSM - Functional Size Measurement) et aussi ce qui expliquent le succès qu’elles rencontrent depuis quelques décennies. De nombreuses études montrent qu’elles sont plus efficaces et dès lors s’imposent comme la réponse la plus adéquate aux exigences modernes en terme d’estimation des projets de logiciels. Les études en ingénierie d’estimation de projets logiciels s’accordent sur le fait que la taille fonctionnelle est le facteur le plus influent dans l’estimation de l’effort de développement. Un bon processus d’estimation doit se baser sur cette taille fonctionnelle, d’où l’intérêt croissant pour les FSM. 

La première méthode de type FSM a été mie au point en 1983 par Albrecht (chez IBM) combler le manque de méthodologie. La méthode se basait sur les concepts de inputs/outputs, fichiers logiques, interrogations et interfaces. Depuis, cette première approche a largement évoluée et donner naissances à plusieurs méthodes comme l’illustre le graphique suivant.

Historique des méthode de points de fonction

COSMIC (anciennement COSMIC FFP) est la dernière bifurcation de ces méthodes et représente la deuxième génération. La méthode a profité des erreurs et limitations des premières méthodes pour développer une nouvelle approche adaptée aux nouvelles méthodologies de développement de logiciels et aux nouveaux types de projets. En particulier, elle a apporté une réponse aux mesures de projets de développement de logiciels embarqués et en temps réel.

COSMIC - Mesure de la taille fonctionnelle

COSMIC (Common Software Measurement International Consortium) a été acceptée comme standard international, ISO/IEC 1976 :2011, en 2002. La méthode a évoluée afin de s’adapter à l’évolution des logiciels et les méthodologies : technologies mobiles, SOA, Cloud, Agile etc. La version actuelle est la 4.1 (publiée en 2014).

COSMIC se base sur un ensemble de règles, principes, modèles et processus pour mesurer les exigences fonctionnelles de l’utilisateur (Functional User Requirements – FUR) d’un logiciel ou partie de logiciel.
La force de la méthode est qu’elle peut s’appliquer à n’importe quel moment du cycle de vie de logiciel. Elle peut s’appliquer assez tôt dès l’élicitation des premières exigences comme à la fin du cycle lorsque le logiciel est produit. Le choix du moment de l’estimation dépend de la raison de l’estimation. Parmi les raisons les plus souvent avancées :

  • Estimer la taille du logiciel à développer
  • Estimer les phases d’un projet et le planifier le projet
  • Estimer l’effort de développement
  • Établir des critères pour sélectionner un fournisseur/soumissionnaire. Cette démarche est de plus en plus répandue car elle offre la possibilité de réaliser des comparaisons objectives. C’est le cas de l’UE qui de plus en plus rend l’estimation avec COSMIC obligatoire.
  • Estimer des parties du logiciel séparément
  • Mesurer la performance des développeurs ou de l’équipe.

La méthode se base sur l’identification des processus fonctionnels et des mouvements de données (ENTREE, SORTIE, INPUT, OUTPUT) entre le logiciel et ses utilisateurs fonctionnels (humain ou hardware) comme illustré par les deux graphes suivants. Le premier illustre la frontière établie entre le logiciel à développer et entre ses utilisateurs.

Principe de la méthode COSMIC

Le second graphe montre comment les processus fonctionnels sont liés aux événements qui les déclenchent.

Lien des processus fonctionnels avec les événements

En plus de donner des estimations fiables, l’approche COSMIC pousse indirectement à structurer les exigences fonctionnelles et de se fait à utiliser des démarches et méthodes standardisées d’identification des exigences. Par conséquence, le premier bénéfice indirect est la diminution des changements des exigences. Rappelons que c’est le second facteur d’échec des projets après les mauvaises estimations. De manière générale, l’utilisation de COSMIC force à implémenter des bonnes pratiques d’estimation et ainsi influence directement sur la réussite du projet de développement.

Recommandations pour une bonne estimation

Une bonne estimation permet de diminuer considérablement les risques sur un projet de développement logiciel et d’augmenter sa valeur business. Elle permet de définir des critères objectifs et de prendre des décisions bien réfléchies.
Avant de commencer une estimation il est important de définir le pourquoi de l’estimation : estimer pour un appel d’offre ne demande pas le même niveau de détail que pour planifier le projet par exemple.

Quelques recommandations pour réussir son estimation :

  • Définir le contexte du projet et faire une analyse des risques appropriée
  • Le rôle de l’estimateur est de fournir l’information technique la plus pertinente et la plus complète possible, avec son contexte pour aider à la prise de décision (allocation de budget par exemple).
  • Éviter de calculer un nombre unique mais plutôt fournir un intervalle allant du cas le plus pessimiste au plus optimiste, sur base de l’analyse de risque du projet.
  • Collecter, analyser et développer son propre modèle d’estimation est un facteur clé de réussite des estimations pour l’entreprise. C’est également un avantage compétitive et de crédibilité pour l’entreprise.

Réussir son processus d’estimation des projets de développement nécessite de mettre en place une démarche stratégique adaptée aux besoins de l’entreprise. Comme dans d’autres démarches d’amélioration continue de la qualité (au niveau processus, pratiques de développement ou gestion de projets), ceci nécessite un budget et du temps pour l’implémenter correctement. La qualité coûte chère ? Mais dans un marché complexe, hyper changeant, et où les clients sont de plus en plus exigeants, peut-on encore prendre le risque de négliger la qualité ? Peut-on continuer à sous-estimer les projets, à sacrifier la qualité au risque d’accroître la non satisfaction des clients et de les perdre ? Mettre en place des modèles d’estimations adéquats est un investissement dont l’impact est direct sur la valeur business de l’entreprise.

Pour plus d’information sur l’apprentissage et la mise en oeuvre de COSMIC et plus généralement de méthodes d’estimation d’effort, n’hésitez-pas à nous contacter

Bibliographie

(1) Kjetil Molokken, Magne Jorgensen – A review of Surveys on Software Effort Estimation.
(2) Alain Abran – Software Estimation : Transforming Dust into Pots of Gold ? – Keynote in MENSURA conference 2014
(3) Bent Flyvbjerg, Massimo Garbuio, Dan Lovallo – Delusion and Deception in Large Infrastructure projects : Two Models for Explaining and Preventing Executive Disaster- California Management Review, vol. 51, no. 2, Winter 2009, pp. 170-193.
(4) Bent Flyvbjerg – From Nobel Prize to Project Management : Getting Risks Right. - Project Management Journal, vol. 37, no. 3, August 2006, pp. 5-15.
(5) Dan Lavallo, Daniel Kahneman – Delusions of success : How Optimism Undermines Executives’ Decisions – Harvard Business Review, July 2003.
(6) Vahid Khatibi, Dayang N. A. Jawawi – Software cost estimation methods : A review. Journal of Emerging Trend in Computing and Information Sciences - Vol 2, No 1, 2011.