La boîte à idées - Le blog de Jean Chambard

Une des questions clés de la préparation d’un projet est : « combien le projet va-t-il coûter ? ». Chaque responsable de projet se trouve donc confronté à l’élaboration du « fameux » budget du projet, c’est-à-dire imaginer et chiffrer à l’avance la totalité des dépenses qui seront générées par le projet sur son cycle de vie, ce qu'on appelle communément la charge globale d'un projet.

La charge globale d’un projet est la quantité de travail à fournir pour conduire le projet, indépendamment du nombre d’intervenants au sein de l’équipe. La charge s'exprime en Jours Homme, Mois Homme, ou Années Homme, selon la taille du projet. Elle permet  de calculer et d'obtenir un budget projet, et de définir la taille de l'équipe de réalisation. Notons que cette charge globale se répartira ensuite par lot (ce qui permet éventuellement de sous-traiter un lot), par phase (conception générale, détaillée, développement, intégration, recette), ce qui permet de planifier le projet, d'affecter les ressources puis de le piloter et par tâche, ce qui permet au chef de projet de piloter ses ressources.

Voici quelques méthodes simples pour calculer cette charge globale et donc les coûts et délais associés. Nous supposerons que vous avez déjà effectué votre analyse de risque et définit votre stratégie de développement en conséquence (Méthode agile, Cycle en V, etc.) Mais d'abord rappelons quelques lois régissant ces calculs.

La loi de Hofstadter

La loi de Hofstadter est une loi empirique (comme la loi de Moore) énoncée par l'universitaire américain Douglas Hofstadter dans son œuvre, Gödel, Escher, Bach : Les Brins d'une Guirlande Éternelle (Prix Pulitzer 1980) et qui s'applique généralement bien aux projets logiciels. Cette loi affirme :

Selon cette loi, il vous faudra, pour mener à bien votre projet, plus de temps que prévu. Mais selon cette même loi qui fait appelle à elle-même en boucle récursive, même en tenant compte de ce fait et de l'intégrer dans vos calculs, il vous faudra quand même plus de temps que prévu.

En clair, cela signifie qu'il est difficile d'estimer correctement la charge d'un projet mais que plus vous chercherez à affiner votre estimation, et plus votre estimation sera fausse. On peut d'ailleurs rapprocher cette loi de la loi de Parkinson.

La loi de Parkinson

La loi de Parkinson - à ne pas confondre avec la loi de futilité de Parkinson - a été énoncée en 1958 par le professeur C. Northcote Parkinson :

Selon cette loi très empirique, si vous donnez 15 jours à une personne pour réaliser un travail qui prend normalement 10 jours, il lui faudra effectivement ces 15 jours.

Si donc vous estimez la charge de votre projet à 200 jours*homme, et qu'à cela vous rajoutez une marge permettant de gérer les imprévus (car selon la loi de Hofstadter ci-dessus, il faut plus de temps que prévu), disons de 60 jours*homme, votre équipe projet consommera les 260 jours*homme pour réaliser le projet, mais il vous faudra probablement encore 80 jours pour traiter les imprévus, ce qui confirme ainsi la loi de Hofstadter.

Une fois ces lois maîtrisés, vous pouvez passer à l'estimation du projet à proprement parler.

L'estimation d'un projet

L’estimation d’un projet informatique comprend quatre étapes :

1. Estimer la taille du produit à développer. Celle-ci se mesure généralement en nombre d’instructions (lignes de code) ou en points de fonction, mais il existe d’autres unités de mesure possibles.

2. Estimer la charge en mois hommes ou en jours hommes, à partir de la taille du produit.

3. Construire le calendrier du planning.

4. Estimer le coût du projet en monnaie locale

La première étape consiste donc à estimer la taille du produit à développer. Il existe pour cela quatre grandes méthodes.

• La méthode COCOMO (acronyme de l'anglais COnstructive COst MOdel). Conçue en 1981 par Barry Boehm, COCOMO est une méthode basée sur les résultats de 63 projets de développements informatiques (allant de 2 000 à 100 000 lignes de code). Elle se base donc sur des statistiques. Aujourd'hui, il existe également un modèle COCOMO II, prenant en compte la ré-utilisation des composants. Cette méthode ne peut s'utiliser que quand la phase de conception est déjà bien avancée, car il est sinon difficile de calculer correctement le nombre de ligne de code qu'il va falloir créer, modifier ou réutiliser.

• Les points fonctions. Cette méthode a été mise au point par Alan Albrecht en 1979 et se base=ait à l'origine sur quatre entités (entrée, sortie, interrogation, fichiers). Depuis 1984, on utilise entrées, sorties, interrogations, les groupes de données externes et les groupes de données internes, avec pour chacune de ces 5 entités un niveau de complexité simple, moyen ou élevé. Cette méthode se limite aux aspects strictement fonctionnels et ne prend pas en compte la complexité de réalisation, pas plus que les moyens humains, matériels et technologiques. Les exigences non fonctionnelles ne sont pas prises en compte non plus.

• Delphi : C'est une méthode élaborée en 1948 par la Rand Corporation et basée sur le jugement d ’experts. Le principe est de rechercher des analogies avec des projets antérieurs, et d’affiner successivement les ratios énoncés par plusieurs experts jusqu’à obtention d’une convergence entre tous les experts. Chaque expert donne son estimation de la charge projet ; tous les points de vue sont ensuite publiés de manière anonyme, puis chaque expert corrige son estimation initiale qui publie une nouvelle estimation et justifie son jugement avant de faire sa proposition définitive.

• La répartition proportionnelle. Cette méthode peut être utilisée pour calculer les charges de chaque étape, ou pour calculer la charge globale du projet à partir d'une estimation de la charge de développement du projet. Cette dernière peut être obtenue par analogie avec des projets antérieurs, comme pour Delphi. Une fois la charge de réalisation connue, il suffit d'appliquer de simples ratios.

Ainsi, si vous estimez que la charge de développement d'un projet est de 1.000 JH, alors la charge de l'ensemble des phases sera de 1.000 / 0,47, soit 2.128 JH environ. A cela il faut rajouter les charges transverses au projet : pilotage, gestion des environnements, etc. Là encore, il existe des ratios qui s'appliqueront sur la charge totale calculée précédemment :

Ce qui vous donnera la charge globale du projet (hors marge de risque ; cf. infra).

La seconde étape consiste à  estimer, à partir de la taille du produit, la charge en mois hommes ou en jours hommes. Si vous êtes passé par la méthode Cocomo ou par les points fonction.

La troisième étape consiste à calculer le temps minimal et le temps optimal de réalisation du projet. on estime que le temps minimal pour réaliser le projet est fonction de la racine cubique de la charge :

Tmin (exprimés en mois) =  2,5 * (charge en mois homme)^1/3 (exposant 1/3 = racine cubique)

Selon la taille de votre organisation projet vous pouvez minorer ou majorer le coefficient multiplicateur en prenant comme valeur 2 ou 3 au lieu de 2,5. Le délai optimum correspond au meilleur compromis entre délais, coûts et prise de risques.

Topt (exprimés en mois homme) = 1,4 * Tmin

La quatrième et dernière étape consiste à estimer les ressources optimales nécessaires à la réalisation du projet. Le nombre de ressources est fonction de la racine carrée de la charge en mois homme.

Nombre de ressources = (charges en mois homme)^1/2

Ainsi, pour un projet estimé à 240 JH, soit 12 mois homme, il vous faudra 3,5 Equivalent Temps Plein.

La marge de risque

Sachez qu’en moyenne, 75% des projets informatique dépassent leur délais de 30% ! Une marge de 30 à 35% semble donc correcte, mais ce n’est pas aussi simple que ça. La loi de Parkinson dit “les programmes sont comme les gaz parfaits : Ils prennent toute la place qu’on leur donne “. En d’autres termes « le travail s’étale de façon à occuper le temps disponible pour son achèvement ». Il faut donc évaluer juste, san marge de rique, et garder la marge de manœuvre pour vous et votre budget.