Square des Utilisateurs

Estimation de projets informatiques

Traduction dune vision canadienne

Nous vous proposons la traduction franaise dun article de Kathleen PETERS, (kpeters@telus.net) paru dans le supplment FORUM LOGICIEL.net de lt 2000. Cette revue est dite par M@rtinig & Associs site web : www.martinig.ch. Rsum rdig par Franco MARTINIG Lestimation des cots et des charges ncessaires aux projets est une tche courante de notre profession. Cest pourtant dans ce domaine quune rputation plutt ngative plane sur linformatique en soulignant les diffrences entre les estimations et les ralisations. Dans cet article, Kathleen PETERS rappelle les principes de base de lestimation, de projets informatiques en abordant les diffrents lments qui influencent les rsultats. Une partie du texte est consacre aux critres de choix dun outil destimation . Lestimation des projets informatiques est lune des plus importantes activits du dveloppement de logiciels. La planification rigoureuse et le pilotage du projet ne sont pas envisageables en absence dune estimation srieuse et fiable. En rgle gnrale, notre industrie du logiciel ne sait pas estimer correctement les projets et nutilise pas convenablement les estimations. Nous souffrons de ces consquences et nous devons focaliser nos efforts sur lamlioration de la situation. La sous-estimation dun projet entrane : un sous-effectif, provoquant la surchauffe de lquipe ; une sous-apprciation de la charge dassurance qualit, avec le risque de livrables de mdiocre qualit ; ltablissement dun planning trop serr, qui dgradera votre crdibilit, lorsque ces dlais prsomptueux sont largement dpasss. Pour ceux qui pensent viter cette situation en gonflant lestimation, la surestimation dun projet peut savrer aussi nfaste pour lOrganisme ! Si vous accordez un projet plus de ressources que ncessaires sans contrler lutilisation de ces ressources, le projet : cotera beaucoup plus cher (en grevant le bilan du projet) ; durera plus longtemps que ncessaire (en manquant les opportunits cibles) ; diffrera la disponibilit de vos ressources pour le prochain projet.

Estimation de charges de projets informatiques

Lestimation dun projet informatique comprend quatre tapes : 1) Estimer la taille du produit dvelopper. Celle-ci se mesure gnralement en nombre dinstructions (lignes de code) ou en points de fonction, mais il existe dautres units de mesure possibles. Une comparaison des avantages et des inconvnients de chacune de ces mesures est aborde dans les rfrences bibliographiques donnes en fin de larticle. 2) Estimer la charge en mois hommes ou en jours hommes. 3) Construire le calendrier du planning. 4) Estimer le cot du projet en monnaie locale.

La Lettre d'ADELI n41 Octobre 2000

23

Estimation de la taille
Le premier stade dune opration destimation consiste estimer, le plus prcisment possible, la taille du logiciel dvelopper. Les sources dinformation, relatives au primtre du projet, naissent avec une description formelle des besoins1 (spcification des besoins des clients, appel doffres, spcification du systme, spcification des exigences du logiciel). Lors de la restimation du projet dans les phases ultrieures du cycle de vie, les documents de conception vous fourniront des dtails additionnels. Ne prtextez pas du manque de description formelle pour vous abstenir de faire une premire estimation du projet. Une description verbale, une prsentation succincte au tableau noir sont quelquefois les seules donnes concrtes pour dmarrer. Dans tous les cas, vous devez informer toutes les parties concernes du niveau de risque et dincertitude de lestimation. De plus, vous devrez restimer le projet ds que les limites du primtre se prciseront. Les deux principaux moyens destimation de la taille de louvrage sont : 1) lanalogie. Si vous avez dj fait un projet similaire dont vous connaissez la taille, vous estimerez chaque partie principale du nouveau projet comme un pourcentage de la taille de la partie similaire du prcdent projet. Vous estimerez la taille totale dun nouveau projet en cumulant les estimations des tailles de toutes les parties. Un estimateur chevronn peut produire des estimations convenables, par analogie, sil connat les valeurs prcises des tailles des parties dun projet prcdent et si le nouveau projet est suffisamment voisin de ce prcdent. 2) La comptabilisation des caractristiques quantitatives de louvrage. On peut utiliser une approche algorithmique telle que celle des points de fonction pour convertir le total en une mesure de la taille. Les caractristiques globales incluent le nombre de sous-systmes, de classes/modules, de mthodes/fonctions. Des caractristiques plus dtailles incluent le nombre dcrans, de dialogues, de fichiers, de tables, de rapports dits, de messages etc.

Estimation de la charge
Aprs avoir estim la taille de louvrage produire, vous pouvez en dduire lestimation de la charge. Cette conversion de la taille du logiciel en charge totale du projet ne peut senvisager quaprs dfinition dun cycle de vie de dveloppement du logiciel et dfinition dun processus de dveloppement de la solution pour spcifier, concevoir, raliser et tester le logiciel. La ralisation dun projet de dveloppement de logiciel implique plus quun simple codage du logiciel ; car le codage ne reprsente souvent quune faible partie de la charge. crire et peaufiner la documentation, raliser des prototypes, concevoir les livrables, revoir et tester le code, reprsentent la part prpondrante de la charge totale du projet. Lestimation de la charge du projet exige didentifier, dvaluer, et dadditionner les travaux que vous devez accomplir pour construire un ouvrage de la taille estime. Il existe deux manires de dduire la charge partir de la taille : 1) La meilleure faon est dutiliser lhistorique de votre Organisme pour recenser les charges relles consommes par les prcdents projets pour raliser les ouvrages. Ceci suppose videmment : a) que votre Organisme ait document les rsultats rels des prcdents projets ; b) que vous ayez ralis, au moins, un projet de taille quivalente - disposer de plusieurs projets de taille quivalente, renforce la conviction quil existe une relation stable entre la taille dun ouvrage et la charge ncessaire sa ralisation ; c) que vous suivez un cycle de vie de dveloppement similaire en utilisant la mme mthodologie et les mmes outils, grce une quipe qui possde les mmes comptences et les mmes expriences.

1Nous traduirons le terme requirements , selon le cas, par besoins ou exigences . Dautre part, nous traduirons le

terme effort par charge .

24

La Lettre d'ADELI n41 Octobre 2000

2) Il se peut que vous ne disposiez pas dun historique utilisable, parce que votre Organisme na pas encore commenc le constituer ou parce que ce nouveau projet est nettement diffrent des prcdents sur un ou plusieurs aspects fondamentaux. Vous pouvez appliquer une approche algorithmique reconnue telle que le modle COCOMO de Barry BOEHM ou la mthodologie de PUTNAM pour convertir une estimation de taille en estimation de charge. Ces modles ont t labors en tudiant un nombre significatif de projets termins par divers Organismes, pour en extraire la relation entre les tailles et les charges. Ces modles, issus des donnes de lindustrie du logiciel, peuvent ne pas tre aussi prcis que ceux de votre historique, mais ils vous donneront, toutefois, une premire approche des estimations de charges.

Estimation des dlais

La troisime tape de lestimation consiste dterminer les dlais partir de la charge estime. Ce qui implique gnralement destimer les ressources affectes au projet (la Structure de Contribution) ce quelles devront faire (le WBS Work Breakdown Structure Organigramme des Tches) quand elles commenceront travailler au projet et quand elles le termineront. Lorsque vous aurez ces informations, vous devez planifier les tches. nouveau, les historiques des projets passs, raliss par votre Organisme ou, dfaut, des modles classiques, peuvent tre utiliss pour dterminer le nombre de personnes dont vous aurez besoin pour un projet dune taille donne et pour ordonnancer ces travaux. Si vous navez rien dautre, la formule empirique suivante [MCCONNELL 1996] vous donnera une ide du temps total requis. Dlai en mois = 3,0 * (charge en mois) 1/3 Des opinions diverses proposent au lieu de 3,0 des coefficients variant de 2,0 4,0. Ce nest quen procdant des essais que vous trouverez le bon coefficient applicable vos propres travaux.

Estimation du cot
Il faut prendre en compte de nombreux facteurs pour estimer le cot total dun projet. Ces facteurs incluent les charges des travaux, les acquisitions ou les locations de matriels et de logiciels, les frais de dplacements (runions et essais) les tlcommunications (appels longue distance, vidoconfrences, lignes ddies aux tests, etc.) les formations, les frais de locaux etc. Lestimation exacte du cot total du projet dpend de la faon dont votre Organisme affecte les cots. Au lieu dtre affects aux projets, certains cots peuvent tre pris en compte en les intgrant dans les taux horaires (en euros par heure). Souvent, un Directeur de projet estimera seulement le cot du travail et nidentifiera que les cots additionnels qui ne sont pas considrs, par lOrganisme, comme des frais gnraux. Le cot du travail peut tre obtenu en multipliant, simplement, lestimation de charge en heures par un taux en euros par heure). Un calcul plus prcis de cot de la charge rsulte de lutilisation dun taux pour chaque catgorie de personnel (technicien, qualiticien, encadrement, documentation, support, etc.). Vous devrez dterminer quel pourcentage de la charge totale du projet doit tre affect chaque profil. nouveau, les donnes historiques ou des modles classiques peuvent apporter une aide.

La Lettre d'ADELI n41 Octobre 2000

25

Recueillir les besoins initiaux Estimer la taille de louvrage Estimer la charge

Restimer si ncessaire

Historique des projets Ressources disponibles

Calculer les dlais

Estimer le cot

Ratio de cot

Approuver les estimations Raliser louvrage

Estimations approuves Taille relle, Charges, etc. Analyser le processus destimation

Figure 1 - Le processus destimation dun projet.

Estimer partir des dlais imposs

Souvent, la date de livraison de louvrage nest pas ngociable La nouvelle version doit tourner dans 6 mois . Le nouveau service tlphonique pour les clients dmarre dans 12 mois et votre logiciel devra tre prt . Si vous connaissez dj votre date de mise en uvre, la seule chose que vous pouvez ngocier est le champ des fonctionnalits mettre en uvre dans le temps imparti. Lorsque le temps imparti ne permet pas de tout faire, les fonctionnalits doivent tre classes par priorit dcroissante et regroupes en ensembles homognes qui peuvent tre dvelopps en temps voulu. Lestimation partir des dlais impartis nentrane pas labandon des tapes du processus destimation indiqu ci-avant. Vous devrez toujours dfinir la taille de louvrage, vous devrez lclater en diverses parties que vous pourrez soit slectionner, soit soustraire de la livraison ; vous devrez toujours estimer les charges les dlais, et les cots. Cest l que les outils peuvent tre rellement utiles. Essayer de raliser un ensemble de fonctionnalits dans un temps limit exige de drouler de nombreuses simulations. Des simulations manuelles prendraient trop de temps et consommeraient trop de charges ; des outils appropris permettent de drouler ces simulations facilement et rapidement.

Exactitude et prcision dune estimation

On aimerait connatre lapproximation dune estimation prvisionnelle. Certes, vous ne connatrez cet cart la ralit qu la fin du projet et vous devrez vivre avec cette incertitude. Naturellement, vous voulez que chaque estimation soit aussi exacte que possible en fonction des donnes dont vous disposez alors. Et, naturellement, vous ne voulez pas prsenter une estimation dune faon trop rigide qui inspirerait une fausse sensation de trop grande crdibilit de ces valeurs. Quappelons-nous une estimation exacte ? Lexactitude caractrise lapproche de la ralit, alors que la prcision caractrise la finesse avec laquelle une grandeur est mesure. Par exemple, une estimation de taille de 70 ou 80 kilo-instructions peut tre la fois la plus exacte et la plus prcise que vous puissiez faire la fin de la phase de spcifications des besoins dun projet. Si vous simplifiez votre estimation en annonant 75 000 instructions, celle-ci semble plus prcise mais en ralit elle est moins exacte. Vous pouvez annoncer 75 281 avec une prcision d1 instruction, mais on ne pourra mesurer cette taille qu la fin de la phase de codage du projet, aprs dcompte des instructions.

26

La Lettre d'ADELI n41 Octobre 2000

Si vous donnez lestimation de la taille sous forme dune plage (intervalle entre une valeur minimale et une valeur maximale) plutt quavec une simple valeur, toutes les valeurs ultrieurement calcules (charges, dlais, cots) seront galement reprsentes par des plages. Si, lors du droulement du projet, vous faites plusieurs estimations au fur et mesure que les spcifications de louvrage deviennent plus dtailles, lintervalle peut se resserrer et votre estimation se rapprochera du cot rel de louvrage que vous dveloppez (figure 2).

Plage dincertitude des estimations 4,0

Limite s
1,0 Valeur relle

uprie ure

nfr Limite i

ieure

0,25 Besoins Spcifications

Avancement du projet Codage Tests

Figure 2 Graphe de convergence des estimations Dveloppement rapide (MCCONNELL 1996) adapt de Modles de cots pour le cycle de vie (BOEHM 1995). Bien sr, vous devez aussi garder lesprit dautres facteurs importants qui affectent lexactitude de vos estimations : lexactitude de toutes vos donnes dentres des estimations (le vieil adage flou en entre, flou en sortie reste vrai) ; lexactitude de tous les calculs (par exemple, la conversion des points de fonction ou des nombres dinstructions en charges, conserve une certaine marge derreur) ; la faon dont vos donnes historiques ou les donnes classiques utilises pour calibrer le modle sappliquent au projet en cours destimation ; le respect du processus de dveloppement prconis par votre Organisme ; les conditions de management du futur projet : rigueur de la planification, conduite et contrle ; labsence dincident majeur dclenchant des retards intempestifs.

Comprendre les arbitrages

Lorsque vous avez labor une estimation du projet, le travail rel commence. Il faut trouver un compromis de fonctionnalits, de dlais, de cots et deffectifs, qui puisse tre accept la fois par le management et par les clients ! Cest alors quune bonne comprhension des relations entre ces diffrentes variables savre particulirement importante, et o la disponibilit des rsultats des diffrents arbitrages rendus sur des projets prcdents vous est trs utile pour tablir vos propres limites.

La Lettre d'ADELI n41 Octobre 2000

27

Voici quelques vidences rappeler pendant les phases darbitrages des estimations. Si vous allongez les dlais, vous pouvez gnralement rduire le cot global en utilisant moins de personnes. Quelquefois, il suffit daugmenter le dlai de quelques semaines pour obtenir un bnfice. En rgle gnrale, le management et les clients souhaitent un dlai court, ce qui ne les empche pas dtudier attentivement les consquences dun allongement si ces consquences sont acceptables pour eux. En effet, de nombreuses personnes nenvisageront une hypothse de planification qui augmente le dlai, que si elles sont fortement motives par une rduction concomitante du cot du projet et de la taille de lquipe. Il ny a que trois dcisions possibles pour rduire le dlai : ! diminuer les fonctionnalits (rduire la charge pour en faire moins) ; ! augmenter les effectifs, lorsquil existe des tches que lon peut parallliser ; ! faire travailler leffectif constant en dpassement dhoraires.

Cot

Dlai minimal Dlai nominal

Dure

Figure 3 - Relation entre cot et planning sur un projet logiciel Source Dveloppement rapide (MCCONNELL 1996). Le cot de ralisation selon un planning normal est trs infrieur au cot de ralisation la plus rapide possible. Si vous ne pouvez rduire les fonctionnalits de louvrage, choisir lune des autres possibilits peut savrer extrmement coteux. Il pourra vous en coter beaucoup plus que votre budget prvisionnel selon la faon dont vous voulez rduire le dlai (figure 3). Et de plus, vous augmentez vos risques dchec du projet ! Rappelez-vous la rgle incontournable Augmenter leffectif dun projet en retard, ne peut quaggraver le retard . Ce mme principe sapplique aux projets informatiques ; vous pouvez ajouter plus de ressources, mais la quantit de travail augmentera, car vous devrez grer des communications supplmentaires et renforcer lencadrement. Si vous escomptez une rduction du dlai par le recours aux heures supplmentaires, vous devez vous souvenir que la productivit pourra, certes, augmenter court terme mais elle risque de dcrotre long terme, car les dveloppeurs se fatigueront et commettront plus derreurs. Pour tout projet, il existe un dlai minimal possible, que vous devez connatre. Vous pouvez seulement approcher ce dlai pour des fonctionnalits bien dfinies, ralises selon un processus minimal de dveloppement et de test afin dobtenir le niveau minimal de qualit souhait. Nesprez pas franchir cette barrire !

28

La Lettre d'ADELI n41 Octobre 2000

Vous ntes pas toujours en mesure datteindre ce dlai minimal. Pour tenir le dlai minimal, votre quipe de projet doit tre particulirement comptente et exprimente, votre processus de dveloppement doit tre bien dfini et stable et le projet doit se drouler parfaitement. Il y a peu dOrganismes qui puissent esprer tenir le dlai minimal et il est plus sage de ne pas le viser. Vous devez dterminer votre plus court dlai possible (ce que lon appelle le dlai nominal). Les donnes historiques de vos projets passs demeurent votre meilleure source dinformation. Gardez toujours lesprit lexactitude de lestimation que vous essayez dajuster. Si votre dlai estim est de 5 7 mois, alors un petit dcalage de 2 semaines napparatra pas. Vous pouvez seulement ajuster le dlai en ajouts significatifs par rapport lexactitude de lestimation.

Il est intressant dobserver les ractions de ceux qui apprennent estimer des projets quand on leur demande de faire plusieurs estimations diffrentes en utilisant des options varies. Quand ils analysent les rsultats, ils sont troubls par les consquences des diffrentes options. Par exemple, le tableau suivant (figure 4) compare 3 estimations pour un projet de 75 kilo-instructions.

Plan nominal Charge (mois hommes) Dure en mois Cot (15 k par mois) Effectif maximal Effectif moyen 40 12,4 600 k3 4,8 3,2

Plan dlai minimal 97 102 1 460 k 14,6 9,8

Plan cot minimal 14 16,2 210 k 1,3 0,9

Figure 4 - Les diffrentes estimations pour un projet de 75 000 instructions. La diffrence entre le dlai du plan nominal et celui du plan minimal est de lordre de deux mois mais pour viser le dlai minimal, leffectif maximal monte plus de 10 personnes et le cot augmente de 860 k (1 460 600). Ces rsultats amnent sinterroger si une diminution de 2 mois du dlai vaut une telle augmentation de cot et si dix personnes supplmentaires peuvent tre mobilises en temps voulu pour accomplir le projet. Pour quelques rares projets, une rduction du dlai peut tre exige, cote que cote, pour les autres, ce jeu nen vaut pas la chandelle ! Tous les projets ne prsentent pas de telles diffrences entre les options, mais la relation entre taille, charge, dlai, effectif, cot, suit quelques rgles simples que vous ne pouvez transgresser. Disposer de plusieurs options, lorsque vous discutez lestimation dun projet, donne chaque responsable, une vision des consquences de ces rgles simples et lui permet de prendre ses dcisions en toute connaissance de cause.

Les difficults des estimations

Lestimation des charges des projets informatiques est absolument ncessaire ; mais cest aussi lune des activits les plus difficiles du dveloppement de logiciels. Pourquoi est-ce si ardu ? La liste suivante indique quelques-unes de ces difficults que nous devons surmonter. Lestimation de la taille est, intellectuellement, ltape la plus difficile (mais non impossible) ; elle est souvent esquive en passant directement lestimation des dlais. Cependant, si vous ne vous interrogez pas sur lobjectif que lon vous demande datteindre, vous naurez aucune base suffisante pour prvoir un dlai ou valuer les consquences dun changement de primtre.
2 Lapplication de la formule du dlai minimal, applique la charge nominale de 40 mois hommes (3*401/3 ) donne ce dlai

de 10 mois.
3 Le document original exprime les montants en $ sans prciser si ce sont des $ canadiens ou des US $. Pour trancher nous

avons mis des (kilo-euros) sans recalculer les montants avec des taux de change, volatils.
La Lettre d'ADELI n41 Octobre 2000

29

Souvent, les clients et les techniciens de logiciels, ne comprennent pas que le dveloppement de logiciels est un processus de raffinement progressif et que les estimations faites en amont du projet sont floues. Les bonnes estimations, elles-mmes, ne sont que des paris, avec des hypothses sur les risques inhrents ; cependant, on a quelquefois tendance les considrer comme graves dans le marbre ! Il est pertinent de prsenter les estimations comme une plage de valeurs possibles, en exprimant, par exemple, que le projet prendra de 5 7 mois, au lieu daffirmer quil sera achev le 15 juin. Mfiez-vous dune plage trop troite qui reviendrait donner une date prcise ! Vous pouvez inclure lincertitude sous forme dune probabilit en disant, par exemple, quil est probable, 80 %, que le projet soit achev avant le 15 juin. Souvent, lOrganisme ne recueille ni nanalyse les mesures des performances des projets termins. Lutilisation de donnes historiques est cependant la meilleure manire pour laborer des estimations dun nouveau travail. Il est trs important dtablir une liste de caractristiques fondamentales que vous mesurerez dans chaque projet. Il est souvent difficile dobtenir un planning raliste accept par lencadrement et les clients. Chacun prfre que les rsultats soient disponibles au plus tt, mais pour chaque projet, il y a un dlai minimal qui vous permet dintgrer toutes les fonctionnalits avec la qualit requise. Vous devez dfinir ce que vous pouvez faire dans un dlai donn et expliquer toutes les parties concernes ce qui est possible et ce qui ne lest pas. Oui, il arrive, de temps en temps, que limpossible se ralise mais cest trs rare et trs coteux. Esprer limpossible relve dune tmraire imprudence !

Projets de maintenance et dvolution, compars au nouveau dveloppement

Lindustrie du logiciel procde plus souvent des travaux de maintenance et dvolution sur des produits existants qu des dveloppements compltement nouveaux. De nombreux projets de maintenance sont des combinaisons de nouveaux dveloppements et dadaptations de logiciels existants. Bien que toutes les tapes du processus destimation nonc ci-dessus, sappliquent aux projets de maintenance et dvolution, il faut prendre en compte quelques aspects particuliers. Lorsque vous dfinissez la taille dun nouveau dveloppement intgr un projet de maintenance, vous devez tre conscient quinsrer cette nouvelle fonctionnalit ne sera faisable que si larchitecture existante du produit peut lintgrer. Si elle ne le peut pas, la charge de maintenance doit tre augmente pour remodeler cette architecture. Il est vain dessayer de calculer la charge de maintenance volutive comme celle dun nouveau travail. : en dfinissant la taille du travail dadaptation en nombre dinstructions ou en points de fonction et en la convertissant en charge (bien que cette approche ait t discute [PUTMAN 1992]). Il vaut mieux procder une estimation de la charge de maintenance par analogie avec les charges dautres oprations similaires. Les modles destimation, calibrs pour des estimations de charge et de dlais de projets de nouveaux dveloppements, supposent que chaque partie de louvrage soit cre de toutes pices. Ce nest pas le cas pour les projets de maintenance dans lesquels vous modifiez une certaine partie de la documentation existante, le code, les cas de tests. Utiliser ces modles peut entraner une survaluation des projets de maintenance. Souvent, le travail de maintenance est soumis des dlais fixes (par exemple, une version maintenue tous les 6 mois ou une fois par an) ou est ralis par un effectif fixe (par exemple, une quipe de maintenance). Dans ce cas, les estimations doivent jouer avec un dlai impos et un effectif constant. Quelques modles destimation prtendent sadresser aux aspects de la maintenance. Mais actuellement, il y a beaucoup plus de support, de conseil, et de discussion, disponibles pour de nouveaux dveloppements que pour les projets de maintenance et dvolution. Heureusement, il y aura une volution, car il existe une forte demande daides dans le domaine de la maintenance.

Estimation des petits projets

De nombreux dveloppeurs travaillent sur des petits projets, gnralement raliss par une ou deux personnes en moins de 6 mois. Les modles destimation diffuss (qui ne sont pas calibrs pour des petits projets) ne sont pas dune grande utilit sauf lorsquils peuvent tre ajusts par les donnes historiques de petits projets dj raliss par lOrganisme.

30

La Lettre d'ADELI n41 Octobre 2000

Les estimations des petits projets sont largement dpendantes des performances des individualits impliques et ainsi les meilleures estimations sont faites par ces futurs ralisateurs. Une approche telle que celle du PSP (Personal Software Processus - Processus personnel pour le logiciel) de Watts HUMPHREY [HUMPHREY 1995] est beaucoup plus raliste pour les petits projets.

Estimation des projets dans de nouveaux domaines

Comment estimez-vous les charges dun projet, dans un nouveau domaine applicatif, dans lequel aucun membre de votre Organisme na dexprience ? Pour un projet novateur trs pointu, personne (y compris en dehors de votre Organisme) ne saurait avoir dexprience. La premire fois que vous accomplissez un nouveau travail, vous affrontez de nombreuses incertitudes et il ny a aucune solution autre que de conduire le projet avec prcaution et de grer le projet prudemment. Ces projets, haut risque, sont gnralement sous-estims par les processus utiliss pour les estimations [VIGDER 1994]. Connaissant ces deux aspects, vous devez : associer lencadrement et les clients la matrise des risques ; viter les engagements majeurs sur les dlais ; restimer lorsque vous serez plus familier du domaine et ds que vous aurez spcifi le produit dune faon plus dtaille. Choisir un cycle de vie de projet pour mieux matriser les incertitudes des projets novateurs est souvent une tape cl manquante dans le processus de dveloppement. Des cycles de vie, itratifs : modle incrmental de rvision (IRM Incremental Release Model) - livraison par parties ; modle en Spirale (Boehm) rvision des estimations et valuation de risques avant de procder chaque nouvelle tape ; sont souvent de meilleures approches que le modle traditionnel en Cascade.

Quelques recettes
Donnez-vous le temps suffisant pour faire une bonne estimation de votre projet. Les estimations bcles sont imprcises et prilleuses ! Pour des projets de grands dveloppements, ltape destimation doit tre considre comme un vritable mini-projet. Si possible, utilisez des donnes enregistres de votre propre Organisme sur des projets similaires. Il en dcoulera une estimation plus prcise. Si votre Organisme na pas encore constitu cet historique, il est grand temps de commencer recueillir les donnes. Utilisez des estimations fondes sur les expriences des dveloppeurs. Les estimations, prpares par des personnes diffrentes de celles qui feront le travail, sont moins prcises. Utilisez au moins un outil destimation du logiciel. Les outils daide lestimation mettent en uvre des modles complexes qui demanderaient trop de temps dapprentissage significatif pour les appliquer manuellement. Ces outils vous assurent que vous noublierez rien et vous permettent dajuster une estimation rapidement et facilement. Utilisez plusieurs estimateurs et utilisez plusieurs techniques diffrentes (utiliser un outil peut tre considr comme lune de ces techniques) et comparer les rsultats. Observez la convergence ou la dispersion des estimations. La convergence confirme que vous avez vraisemblablement fait une bonne estimation. La dispersion signifie quil y a probablement des aspects qui ont t ngligs pour certaines estimations ; vous devez approfondir ces aspects. Lapproche de DELPHES (DELPHI en anglais) ou DELPHES tendu [BOEHM 1981] peut tre utilise pour recueillir ou discuter les estimations en mobilisant un groupe de personnes ; lobjectif tant de produire une estimation prcise et objective. Restimer le projet, plusieurs fois, au cours de son cycle de vie. Au fur et mesure que vous spcifiez les dtails du produit, vos estimations se rapprocheront des consommations relles ncessaires pour achever le projet. Crez une procdure standardise destimation que toute personne implique adoptera. On pourra discuter les entres de cette dmarche mais pas remettre en cause les sorties. Votre effort se rpartira dune faon progressive, tout en dcouvrant le primtre et les facteurs de cot du projet.

La Lettre d'ADELI n41 Octobre 2000

31

Centrez vos efforts sur lamlioration de votre processus destimation des projets informatiques de votre Organisme. Comparez les charges consommes de chaque projet termin aux charges prvisionnelles Comment aviez-vous prvu les charges et les dlais ? Quaviez-vous oubli ? Quauriez-vous pu amliorer ?

Les outils daide lestimation des projets informatiques

Les outils destimation peuvent tre des produits indpendants ou tre intgrs des fonctionnalits de produit daide la gestion de grands projets. Ces outils peuvent simplement aider au processus destimation de la taille ou se contenter de la conversion de la taille en charge, dlais et cots ou les deux la fois. Les outils qui aident au calcul de la taille incluent la dtermination du nombre dinstructions, lanalyse des points de fonction et, parfois, la saisie des exigences et la connaissance des applications de gestion. Le prsent chapitre concerne les outils destimations qui sont des produits indpendants et aident la conversion de la taille de louvrage en charges de ralisation. Aucun outil destimation nest une baguette magique pour rsoudre vos problmes destimation. Ce sont des aides prcieuses de votre panoplie destimation et vous devez srieusement en utiliser un ou plusieurs outils, mais noubliez pas que la qualit des sorties dpend de la qualit de vos donnes dentre et que vous devez dfinir un processus de dveloppement et destimation. Attention, mfiezvous de ces fournisseurs qui prtendent que leur outil est capable dlaborer des estimations dune excellente approximation, sauf sils indiquent toutes les actions prparatoires et toutes les actions accomplir pendant le projet, pour vous assurer en permanence de lexactitude de lestimation. Il existe un large ventail doutils disponibles. Chercher un outil destimation sur la Toile (web) nest pas aussi immdiat que lon pourrait lesprer. Il faut utiliser des combinaisons de mots-cls avec un moteur de recherche pour dcouvrir 80 % des outils et des sites qui contiennent la liste des autres. Les informations recueillies sur la Toile sur les aptitudes et les prix des outils sont trs variables et parfois superficielles, aussi quelques adresses lectroniques et quelques numros de tlphone doivent tre utiliss pour approfondir les premires moissons dinformation. Les paragraphes suivants rsument les caractristiques importantes et les critres que vous devez respecter quand vous valuez un outil daide lestimation de projets informatiques. La figure 3 fournit un contexte pour la discussion.

Donnes importes

Exigences

Estimation de la taille (outil)

Charges Estimation du projet (outil) Dlais Cots

Autres lments de cots Contraintes et priorits

ditions

Figure 3 Le contexte des outils destimation

32

La Lettre d'ADELI n41 Octobre 2000

Prix
Les outils destimation se classent selon leur mode de rmunration : en location contre une redevance annuelle ; lachat un seul paiement : on distingue trois tranches de prix : ! bon march (moins de 1 000 ) ! prix moyen (entre 1 000 et 5 000 ) ! cher (de 5 000 20 000 , voire plus) Seuls, les grands Organismes et les grands projets envisageront les produits de prix lev. Les outils moins de 1 000 mettent en uvre des modles communs publis par dautres (par exemple COCOMO) et certaines fonctionnalits risquent de faire dfaut comme le support tendu des options perfectionnes, mais ces outils peuvent cependant produire plus que les seules estimations.

Plates-formes et performances
Loutil tourne-t-il sur votre plate-forme (matriels et logiciels) ? Tourne-t-il sur dautres platesformes ? Quelles sont les capacits de mmoire (vive et espace disques) exiges ? Sa base de donnes intgrera-t-elle la quantit de donnes historiques prsentes et venir et grera-t-elle le nombre de projets que vous voulez estimer ?

Facilit dutilisation et documentation

Pouvez-vous facilement laborer la premire estimation dun projet, lors de la prise en main de loutil ou devez-vous tudier le modle sous-jacent en dtail pendant plusieurs jours, dchiffrer les abrviations et assimiler les dfinitions des attributs ? Pouvez-vous esquisser votre estimation facilement ? Le mode demploi et les messages daide en ligne vous permettent-ils de comprendre comment utiliser loutil pour laborer des estimations de projets au-del dune liste des fonctionnalits offertes par loutil ? Existe-t-il un exemple type ?

Aptitude travailler en rseau

Existe-t-il une base de donnes commune partageable laquelle plusieurs utilisateurs peuvent accder et peuvent-ils enrichir lhistorique partir de leurs propres donnes, visualiser et mettre jour les estimations (en supposant que cette aptitude soit importante pour vous) ?

volutions
Le modle ne doit pas tre fig. Au fur et mesure que de nouveaux langages de programmation et de nouveaux paradigmes de dveloppement apparaissent, que la gamme des projets de dveloppement stend, il faut envisager la mise jour du modle interne de loutil. Le fournisseur vous donne-t-il accs au modle ? Le fournisseur sengage-t-il faire des amliorations progressives qui vous offriront de nouvelles fonctionnalits oprationnelles sur de nouvelles plates-formes ? Combien cote cette mise jour ?

Assistance
Il faut bien comprendre quen dpit des progrs des outils destimation (plus accessibles, plus ergonomiques) les modles sous-jacents sont trs complexes et vous pouvez tre amen poser quelques questions ou quelquefois avoir besoin dun conseil. Le fournisseur propose-t-il un support technique et des moyens pour rpondre aux questions comment faire ? Le fournisseur offre-t-il des cours destimation, au-del du simple mode demploi de loutil ou recommande-t-il des cours de soutien et de perfectionnement ? Le fournisseur vous offre-t-il des manuels dauto formation ?

Spcification du primtre et de la taille

La flexibilit est un facteur-cl de loutil. Vous pouvez commencer, dune certaine faon, lestimation de la taille dun projet, puis au fur et mesure que vous dcouvrirez les spcifications de votre ouvrage particulier ou lorsque vous deviendrez plus comptent en estimation, vous souhaiterez vous brancher sur dautres techniques et vous voudrez que loutil supporte ces nouveaux besoins.
La Lettre d'ADELI n41 Octobre 2000

33

Quelles options loutil vous propose-t-il pour spcifier nouveau une estimation ? Pouvez-vous entrer soit des nombres dinstructions, soit des points de fonction ? Pouvez-vous spcifier des composants GUI, des nombres de classes ou de mthodes ou des modules et des fonctions ? Est-ce que la taille sintroduit comme une seule valeur (par exemple, 55 000 instructions, 345 points de fonction,) une plage de nombres (minimum 45 000 probable 55 000 maximal 65 000) ? La taille peut-elle tre estime en la divisant en modules ou en lots de travaux dont vous estimerez chaque composant particulier de faon convenable ?

Modle(s) destimation
Quelques outils utilisent un ou plusieurs modles propritaires pour lesquels une information succincte est diffuse. Dautres utilisent des modles non-propritaires pour lesquels vous pouvez acheter un livre ou tlcharger une information dtaille partir de la Toile mondiale pour en savoir plus. Llaboration dun modle perfectionn de dveloppement de logiciel consomme beaucoup de ressources ; il nest donc pas surprenant quil ny ait quune poigne de modles. En tudiant les algorithmes internes de loutil, vous devez vrifier que les estimations gnres par loutil sont utiles en regard des types de projets dvelopps par votre Organisme. Les modles paramtriques reposent sur des spcificits, qui ont tendance biaiser les rsultats ; par exemple, quelques-uns suivent un processus de dveloppement dapplications militaires alors que dautres suivent un processus de dveloppement dapplications commerciales. La seule faon de savoir rapidement si un outil peut vous apporter des rsultats valables est dobtenir une version dvaluation ou de dmonstration et de procder lestimation de projets termins pour lesquels vous connaissez les consommations relles. Il convient de comparer les estimations fournies par loutil avec les donnes des projets termins et danalyser lamplitude des carts. Vous devez vrifier si loutil vous permet de saisir les donnes historiques des projets termins et vous devez contrler lergonomie de la saisie. Quelques outils ne pourront tre calibrs pour vos projets quen modifiant le modle sous-jacent (cest--dire que vous devez calculer les valeurs) dautres vous permettent dintroduire simplement les mtriques du projet comme la taille relle, la charge, le dlai, et alors loutil gnre les changements du modle. Loutil supporte-t-il lestimation de projets de maintenance et dvolution ? Loutil supporte-t-il lorient objet, la rutilisation du logiciel ou dautres particularits importantes pour votre projet ?

Autres facteurs de cots

Gnralement, les modles vous permettent dvaluer certains cots et certains facteurs de productivit (ce sont les aptitudes et lexprience de lquipe, les exigences du cycle de vie, lutilisation doutils) de faon adapter lestimation la situation particulire de votre projet, dans votre Organisme. Quels facteurs de cot sont-ils disponibles et les valeurs correspondantes sont-elles utiles dans votre contexte ?

Contraintes et priorits
Loutil vous permet-il de spcifier les contraintes (par exemple, un dlai maximal de 12 mois avec une quipe maximale de 10 personnes) pour calculer votre estimation ? Loutil vous permet-il de spcifier les priorits (par exemple, si le dlai minimal prsente la plus grande priorit ou si, au contraire, le plus faible effectif a la plus grande priorit) dans le calcul des estimations ?

Gnration de sorties
Il faut rechercher un outil dont les fonctions offrent des options, des probabilits et des plages. Les outils utilisant la simulation de Monte-Carlo pour produire des estimations, avec des probabilits diffrentes, fournissent dintressantes perspectives, lies aux inconstances des processus de dveloppement. Les tats restitus peuvent vous aider prsenter clairement les estimations et les discuter avec les clients et lencadrement. Quelles sortes dtats sont labores ? Vous sont-ils utiles ? Pouvez-vous obtenir des copies lectroniques des tats afin de les complter et de les insrer facilement dans les autres documents du projet ?

34

La Lettre d'ADELI n41 Octobre 2000

Aptitude dimportation/exportation
Les importations possibles comprennent des lments tels questimation des tailles, module par module, des donnes historiques sur les projets, et des mises jour du modle. Les exportations possibles comprennent le planning, le WBS (Work Breakdown Structure = Organigramme des Tches), et des informations pour les outils de gestion de projet tels que MS-Project ou des feuilles Excel.

Conclusion
Il nexiste pas de recette rapide pour faire de nous, immdiatement, de meilleurs estimateurs et utilisateurs destimation. Des estimations efficaces dcoulent de la dfinition et de lamlioration du processus, de lducation, de la formation, du bon management de projet, de lutilisation de techniques et doutils appropris, de mesures, de lemploi de ressources suffisantes, et dun travail rigoureux. Selon votre situation de dpart et la dure des projets dans votre Organisme, plusieurs annes pourront se passer avant dtablir ( partir des projets termins) les bases sur lesquelles vos estimations soient solidement bties. Essayer de construire quelque chose en une semaine revient essayer de faire Rome en un jour ! Mais, ne vous dcouragez pas ! Vous pouvez agir, avec pertinence, pour amliorer votre projet actuel et prendre dautres mesures pour amliorer votre prochain projet. En supposant que vous ayez pass ltape de planification de votre projet actuel et que vous ne disposiez que de peu de temps, vous pouvez prendre quelques initiatives sur ce projet pour engager lamlioration de votre processus destimation. Restimer le projet au franchissement de plusieurs jalons essentiels ( la fin de la spcification des exigences, la fin de la conception de larchitecture, la fin de la conception dtaille). la fin du projet, enregistrer les valeurs relles (ou des valeurs aussi proches de la ralit que vous le pourrez) de la taille, de la charge, du cot, des effectifs. Commencer votre base de donnes historique. la fin du projet, rvisez votre rapport estimations prvisionnelles/consommations relles et analyser ce que vous avez bien fait et comment vous pourriez faire mieux dans le futur. Vous utiliserez ce que vous venez dapprendre, loccasion de la prochaine estimation. Voici quelques mesures prendre pour votre prochain projet. Rvisez ltat de votre processus de dveloppement de logiciel. Est-il alatoire ou est-il ordonn et structur ? Le suivez-vous gnralement ? Sil est chaotique au commencement ou si votre processus se dgrade sous les pressions externes et si vous subissez les vnements qui impactent le projet, alors vous devrez en tenir compte dans vos estimations. Mais vous feriez mieux dessayer de rduire le dsordre. tablir un processus de dveloppement mthodique ne se fera pas en une nuit, mais chaque petit travail effectu aidera mieux estimer votre projet et mieux le diriger. Crez un premier brouillon dun document de procdure destimation et suivez cette procdure lors de lestimation. Voyez ce qui fonctionne et ce qui ne fonctionne pas, et ajustez si ncessaire. Notez quil y a des formulaires pour crer un tel document pour vous viter de tout rinventer. Donnez-vous le temps de faire de bonnes estimations de projet. Prvoyez quand vous pourrez restimer le projet et jalonner les tches pour les restimations dans le plan du projet. Commencez la formation de votre management et des clients sur la prcision des estimations. Prsentez les estimations sous forme de plages et expliquez les incertitudes et les risques associs. Suivez le plus grand nombre possible de recettes donnes plus haut dans cet article. Prenez du temps pour : travailler la dfinition, la documentation, lamlioration de votre processus de dveloppement de logiciel. Un processus clairement dfini est requis pour fonder vos estimations de projet sur une base solide. Il existe des formulaires et des guides de dfinition de procdures ; des consultants et des formations pourront pour vous y aider ; tudier les outils destimation de projets et en utiliser un (ou plusieurs).
La Lettre d'ADELI n41 Octobre 2000

35

Des tapes de lgres amliorations, prises avec soin et attention, vous conduiront sur la route de meilleures estimations et planification de projets. En effet, procder par petits pas, est souvent la seule faon dassurer un changement permanent.

Au sujet de lauteur
Kathleen PETERS est une consultante indpendante en gnie logiciel avec une matrise de sciences en informatique. Elle possde plus de 15 ans dexprience dans lindustrie du dveloppement de logiciel et en management de projets. Elle travaille simultanment avec le SPC - Software Productivity Center - (centre de productivit de logiciel) Vancouver (Colombie britannique) au Canada. Elle enseigne galement le gnie logiciel lUniversit Simon Fraser. Ses adresses lectroniques : kpeters@spc.ca, petersk@istar.ca, kpeters@telus.net.

Traduit et adapt avec laimable autorisation de Kathleen PETERS par Alain COULON - Secrtaire dADELI

Rfrences
Gnralits (estimations et planification de projet)
DE MARCO Tom, Controlling Software Projects, Prentice-Hall 1982 GOETHER Wolfhart B., BAILEY Elizabeth K., BUSBY Mary B., Software Effort and Schedule Measurment,: A framework for counting Staff-hours and reporting Schedule Information, CMU/SEI-92-TR-021, 1992, http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.021.html HUMPHREY Watts, A Discipline for Software Engineering, Addison-Wesley, 1995 MCCONNELL Steve, Rapid Development - Taming Wild Software Schedules, Microsoft Press, 1996 MCCONNELL Steve, Software Project Survival Guide, Microsoft Press, 1998 VIGDER, M.R. & KARK A.W., Software Cost Estimation and Control, 1994

Dtermination du nombre dinstructions

R. PARK, Software Size Measurement: A framework for counying source statements, CMU/SEI-92-TR-020, 1992, http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.020.html

Points de fonction
DREGER, Brian, Function Point Analysis, Prentice-Hall, 1989 GARMUS, David & David HERRON, Measuring the Software Process, Yourdon Press, 1996 CAPERS Jones, Applied Software Measurment, Assuring Productivity and Quality, McGrawHill, 1991 CAPERS Jones, Site Web - Software Productivity Research http://www.spr.com SYMONS Charles, Software Sizing and Estimating: Mark II Function Point Analysis, John Wiley, 1991 International Function Point Users Group (IFPUG) site web : http://www.ifpug.org A function point FAQ : http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm

36

La Lettre d'ADELI n41 Octobre 2000

Modles destimations
BOEHM Barry, Software Engineering Economics, Prentice-Hall, 1981 (COCOMO natif) PUTNAM Lawrence & WARE Myers, Measures for Excellence: Reliable Software on Time, Within Budget, Yourdon Press, 1992 PUTNAM Lawrence & WARE Myers, Industrial Strength Software: Effective Management using Measurement, IEEE Computer Society, 1997 COCOMOII web site Center for Software Engineering : http://sunset.usc.edu/COCOMOII/cocomo.html

Panoramas dautres outils destimation

DOUGLIS Charles, Cost Benefit Discussion for Knowledger-Bases Estimation Tools, 1998 http://www.spr.com/html/cost_benefit.htm GILES, Alan E & Dennis BARNEY, Metrics Tools : Software Cost Estimation, 1995http://www.stsc.hill.af.mil/CrossTalk/1995/jun/Metrics.html Software Cost Estimation Web Site (SCEW) http://www.ecfc-u-net.com/cost/index.htm Parametric Cost Estimating Reference Manual, http://www.jsc.nasa.gov/bu2/resources.html DoD Data &Analysis Center for Software, http://www.dacs.dtic.mil

La Lettre d'ADELI n41 Octobre 2000

37