B303_Ch3

Module 303

Gestion de Projets

Estimation des charges

Bibliographie

Grard-Michel Cochard

[email protected]

Estimation des charges Combien pse un projet

Mthode Delphi Mthode de la rpartition proportionnelle

Mthode d'valuation analytique Mthodes Cocomo

Mthode des points fonctionnels

Tests

Combien pse un projet ?

La charge ou effort est la quantit de travail ncessaire mesure en moisxhommes (ou joursxhommes ou annesxhommes). Dans de telles units, il faut prendre en compte le fait qu'un mois correspond 20 jours si les week-ends ne sont pas des priodes de travail.

Connaissant la charge et le cot unitaire du moisxhomme, on peut avoir une estimation du cot en ressources humaines d'un projet. En se limitant aux projets de type informatique, o le cot d'un programmeur est estim environ 400 HT par jour , on peut dresser le tableau suivant :

La dure se calcule partir de la charge lorsque l'on sait combien de personnes sont affectes au projet. Une charge de 6 moisxhommes peut correspondre une dure de 6 mois si on ne dispose que d'une seule personne ou de 1 mois si on dispose de 6 personnes. Toutefois ce mode de calcul est relativement thorique car toutes les personnes ne sont pas quivalentes (et n'ont pas la mme spcialit) et les tches sont en gnral interdpendantes.

Il existe un certain nombre de mthodes pour calculer la charge d'un projet. Il existe aussi des "trucs" (malheureusement plus courants qu'on ne le croit) qui sont des agissements ni scientifiques, ni honntes : la "mthode" de la dilatation consiste ajuster le temps de dveloppement d'un projet au temps disponible ("le travail se dilate jusqu' remplir le temps disponible") ; la "mthode" du march consiste ajuster la charge au

prix propos (dans un appel d'offres par exemple).

Plus srieusement, les mthodes employes sont :

la mthode Delphi la mthode de la rpartition proportionnelle la mthode d'valuation analytique les mthodes Cocomo/Diebold la mthode des points fonctionnels

Passons en revue ces diffrentes mthodes (qui peuvent, d'ailleurs, tre utilises simultanment ou en combinaison).

Mthode Delphi

Son nom vient de Delphes o la Pythie rendait ses oracles. Elle consiste faire appel des experts qui, selon leur propre exprience, proposent confidentiellement une charge indicative. On procde alors en deux tapes :

1) Une runion des experts permet de faire la liste des propositions (sans mentionner les noms des experts).

2) Un temps de rflexion est donn aux experts qui peuvent rviser leur jugement. Une seconde runion dresse une nouvelle liste des propositions. La moyenne de celles-ci, par exemple, donne une ide de la charge globale du projet.

Mthode de rpartition proportionnelle Elle est adapte aux projets dcoups en tapes, phases et tches classiques : les tapes sont l'tude pralable, l'tude dtaille, l'tude technique, la ralisation, la mise en oeuvre. Seule l'tude pralable fait l'objet d'une quantification analytique claire : elle est divise en 3 phases : observation, conception, apprciation. Il existe aussi des charges complmentaires annexes correspondant aux tches suivantes : encadrement du projet, recette, documentation utilisateur. Les tableaux ci-dessous indiquent des ratios ( ajuster selon l'expertise du chef de projet) :

Mthode d'valuation analytique

Cette mthode est adapte particulirement aux dveloppements informatiques couramment appels "programmes". Ceux-ci sont rpartis en programmes transactionnels (menu, consultation, mise jour, dition temps rel) et en programmes batch (extraction de donnes, mise jour, dition temps diffr). Suivant le type de programme et la difficult du projet, des "poids" sont appliqus comme indiqus (en joursxhommes) dans le tableau ci-dessous (correspondant une pratique d'une SSII particulire) :

Attention, ceci ne concerne que la charge de ralisation (programmation, jeux d'essais, mise au point). Il est convenu de rajouter aux charges ci-dessus des charges complmentaires :

tests d'enchanement : 10% de la charge de ralisation encadrement : 20% de la charge de ralisation.

Mthodes Cocomo

Cocomo signifie COnstructive COst MOdel. Cette mthode, qui ne s'applique qu' l'tape de ralisation, suppose l'existence d'une corrlation entre la taille (en instructions source) d'un programme et la charge consomme. Le rsultat s'exprime par la formule suivante dans le modle de base Cocomo81 :

charge (en moisxhommes) = a{KLOC}b

o a, b, sont des coefficients donns ci-dessous et KLOC reprsente le nombre, en milliers, de lignes de code (LOC = Lines Of Code) ; en fait il s'agit du nombre d'instructions source.

Mode a bOrganic 2.4 1.05

Semi-detached 3.0 1.12Embedded 3.6 1.20

organic : projets simples mens avec de petites quipes

semi-detached : projets intermdiaires mens avec des quipes mixtes

embedded : projets complexes devant obir des ensembles de contraintes

Un projet est considr comme moyen si le nombre d'instructions source est compris entre 50 000 et 300 000.

Le modle intermdiaire Cocomo81 est plus labor et prend en compte des facteurs d'ajustement intgrant les conditions de dveloppement. L'quation donnant la charge est alors :

charge (en moisxhommes) = a(EAF)(KLOC)b

o EAF (Effort Adjustment Factor), qui vaut 1 dans le modle de base, est calcul partir de 15 critres regroups en 4 catgories : produit, ordinateur, personnel et projet. Le tableau ci-dessous donne les valeurs affectes chaque paramtre suivant son importance. EAF est le produit de toutes ces valeurs.

Cost Driver Description RatingVery Low

Low Nominal High Very High

Extra High

Product RELY Required software reliability 0.75 0.88 1.00 1.15 1.40 -DATA Database size - 0.94 1.00 1.08 1.16 -CPLX Product complexity 0.70 0.85 1.00 1.15 1.30 1.65Computer TIME Execution time constraint - - 1.00 1.11 1.30 1.66STOR Main storage constraint - - 1.00 1.06 1.21 1.56VIRT Virtual machine volatility - 0.87 1.00 1.15 1.30 -TURN Computer turnaround time - 0.87 1.00 1.07 1.15 -Personnel ACAP Analyst capability 1.46 1.19 1.00 0.86 0.71 -AEXP Applications experience 1.29 1.13 1.00 0.91 0.82 -PCAP Programmer capability 1.42 1.17 1.00 0.86 0.70 -VEXP Virtual machine experience 1.21 1.10 1.00 0.90 - -LEXP Language experience 1.14 1.07 1.00 0.95 - -

Project MODP Modern programming practices 1.24 1.10 1.00 0.91 0.82 -TOOL Software Tools 1.24 1.10 1.00 0.91 0.83 -SCED Development Schedule 1.23 1.08 1.00 1.04 1.10 -

Par ailleurs, les valeurs de a et b sont donnes par le tableau ci-dessous :

Mode a bOrganic 3.2 1.05

Semi-detached 3.0 1.12Embedded 2.8 1.20

Le modle Cocomo81 avanc prend en compte, comme prcdemment, la taille du programme, mais aussi des facteurs de pondration qui diffrent suivant la phase de dveloppement. 4 phases de dveloppement sont proposes : tude globale (RPD : requirements planning and product design), tude dtaille (DD : detailed design), programmation (CUT : code and unit test), integration (IT : integration and test). La charge se calcule donc phase par phase partir de la formule du Cococmo81 intermdiaire avec la pondration ci-dessous de chaque phase :

Cost Driver Rating RPD DD CUT IT

ACAP

Very Low 1.80 1.35 1.35 1.50Low 0.85 0.85 0.85 1.20

Nominal 1.00 1.00 1.00 1.00High 0.75 0.90 0.90 0.85

Very High 0.55 0.75 0.75 0.70

A partir de la fin des annes 90, un modle nouveau Cocomo a fait son apparition : CocomoII. Il prend en compte l'volution des technologies de dveloppement (programmation oriente objet, rutilisation, cycle en spirale et production de plusieurs prototypes, ....). CococmoII se dcline en 3 modles que nous dcrivons ci-dessous.

Le modle Application Composition de CocomoII est utilis dans le prototypage. Au lieu de qualifier la taille du logiciel en SLOC (lignes de code source), on utilise ici les "points objets". Les objets considrs sont les crans, les rapports et les programmes en langage de 3me gnration. Chaque objet est caractris comme simple, moyen , complexe. Les programmes en langage de troisime gnration sont caractriss comme complexes. Pour les crans et les rapports, la complexit dpend du nombre de tables de donnes source et du nombre de vues :

nombre de tables de donnes sources

nombre de vues

Dans le modle Early Design CocomoII, la taille est value suivant la technique des points de fonction (voir plus loin). Pour faciliter la transition entre Cocomo81 et CocomoII, une table de conversion entre les points de fonction et le nombre de SLOC est fournie suivant le langage utilis :

langage niveau min moyen max

langage machine 0,10 - 640 -

langage d'assemblage 1,00 237 320 416

C 2,50 60 128 170

RPGII 5,50 40 58 85

C++ 6,00 40 55 140

Visual C++ 9,50 - 34 -

Powerbuilder 20,00 - 16 -

Excel 57,00 - 5,5 -

La taille peut aussi tre exprime directement en lignes source :

charge (en moisxhommes) = a.EAF.(KLOC)b

a = 2,94 et b varie de 1,01 1,26 en fonction de plusieurs facteurs que nous ne dtaillerons pas ici.

o Le facteur EAF est calcul partir des deux tableaux suivants : le premier donne les facteurs influents en fonction de facteurs plus prcis. Ces dernier sont donns dans le second tableau.

Cost Driver Description

Counterpart Combined

Post-Architecture Cost Driver

RCPX

Product reliability

and complexity

RELY, DATA, CPLX, DOCU

RUSE Required reuse RUSE

PDIF Platform difficulty

TIME, STOR, PVOL

PERS Personnel capability

ACAP, PCAP, PCON

PREX Personnel experienceAEXP,

PEXP, LTEXFCIL Facilities TOOL, SITESCED Schedule SCED

Cost Driver

Description RatingVery Low Low Nominal High Very High Extra

HighProduct RELY Required software reliability 0.75 0.88 1.00 1.15 1.39 -DATA Database size - 0.93 1.00 1.09 1.19 -CPLX Product complexity 0.70 0.88 1.00 1.15 1.30 1.66RUSE Required reusability 0.91 1.00 1.14 1.29 1.49DOCU Documentation 0.95 1.00 1.06 1.13 Platform TIME Execution time constraint - - 1.00 1.11 1.31 1.67STOR Main storage constraint - - 1.00 1.06 1.21 1.57PVOL Platform volatility - 0.87 1.00 1.15 1.30 -Personnel ACAP Analyst capability 1.50 1.22 1.00 0.83 0.67 -PCAP Programmer capability 1.37 1.16 1.00 0.87 0.74 -PCON Personnel continuity 1.24 1.10 1.00 0.92 0.84 -AEXP Applications experience 1.22 1.10 1.00 0.89 0.81 -PEXP Platform experience 1.25 1.12 1.00 0.88 0.81 -LTEX Language and tool experience 1.22 1.10 1.00 0.91 0.84 Project TOOL Software Tools 1.24 1.12 1.00 0.86 0.72 -SITE Multisite development 1.25 1.10 1.00 0.92 0.84 0.78SCED Development Schedule 1.29 1.10 1.00 1.00 1.00 -

Enfin, dernier modle propos par les concepteurs de Cocomo, le modle Post Architecture CocomoII est bas sur l'quation suivante :

charge (en moisxhommes) = a.EAF.(KLOC)b

a, EAF (calcul avec les facteurs du tableau ci-dessus droite), KLOC ont les dfinitions donnes ci-dessus. Quant l'exposant b, il est dfinit lui-mme par :

b = 1,01 + 0,01.(Wi)

La somme des coefficients Wi prend en compte divers facteurs d'environnement de dveloppement :

W(i) Very Low Low Nominal High Very High Extra HighPrecedentedness 4.05 3.24 2.42 1.62 0.81 0.00

Development/Flexibility 6.07 4.86 3.64 2.43 1.21 0.00Architecture/Risk Resolution 4.22 3.38 2.53 1.69 0.84 0.00

Team Cohesion 4.94 3.95 2.97 1.98 0.99 0.00Process Maturity 4.54 3.64 2.73 1.82 0.91 0.00

Mthode des points fonctionnels

Cette mthode s'appuie sur une description fonctionnelle du systme dvelopper. en terme d'units d'oeuvre, mais aussi en terme de complexit. A chaque couple (unit, complexit) on affecte un poids appel point de fonction, d'o le nom de la mthode. Les units d'oeuvre sont relatives aux donnes (GDI, GDE) et aux traitements (ENT, SOR, INT). Dveloppe initialement par Alan Albrecht en 1979, la mthode a volu et en 1986 s'est cr l'IFPUG (International Function Points User Group) pour sa promotion. En France, la FFUP (french Function point User's Group) s'acquitte de la mme tche. Signalons que le point de fonction est aussi normalis par l'AFNOR (XP Z 67-160).

GDI : groupe logique de donnes internes (mises jour par le systme) que l'on peut considrer comme un "enregistrement" rassemblant des donnes lmentaires (DE). On pourra utiliser avec profit un MCD de type entit-association : les GDI sont des entits ou des associations n-aires. Un GDI peut tre constitu de sous-ensembles logiques de donnes (ayant un sens propre) appels SLD eux-mmes composs de donnes lmentaires DE.

GDE : groupe logique de donnes externes (consultables, mais non mises jour par le systme). Un GDE, comme un GDI, se dcompose en SLD (sous-ensembles logiques de donnes) composs de donnes lmentaires DE.

ENT caractrise les donnes ou paramtres qui entrent dans l'application ; les informations saisies se rfrent des GDI ou des GDR, appels ici GDR (groupe de donnes rfrencs)L Les GDR sont videmment composes de DE.

SOR caractrise les donnes ou paramtres qui sortent de l'application ou sont le rsultat d'un traitement.

Comme prcdemment, les informations de sortie se rfrent des GDR, composs de DE.

INT caractrise une interrogation , c'est dire une combinaison entre/sortie qui ne fait pas de mise jour de GDI et qui met en oeuvre un processus d'extraction de donnes brutes. Il utilise GDR, donc des DE.

La complexit (faible, moyenne, leve) est dtermine par les tableaux suivants :

complexit des GDI

1 19 DE 20 50 DE 51 DE ou plus

1 SLD faible faible moyenne

2 5 SLD faible moyenne leve

6 SLD ou plus moyenne leve leve

complexit des GDE


1 SLD faible faible moyenne

2 5 SLD faible moyenne leve

6 SLD ou plus moyenne leve leve

complexit des ENT


0 ou 1 GDR faible faible moyenne

2 GDR faible moyenne leve

3 GDR ou plus moyenne leve leve

complexit des SOR



2 3 GDR faible moyenne leve


complexit des INT



2 3 GDR faible moyenne leve


On affecte ensuite des points de fonction chaque unit d'oeuvre suivant sa complexit :

complexit faible moyenne leve

points de fonction des GDI 7 10 15

points de fonction des GDE 5 7 10

points de fonction des ENT 3 4 6

points de fonction des SOR 4 5 7

points de fonction des INT 3 4 6

Connaissant le nombre d'units de chaque type et leur complexit, on obtient le nombre de points pour chacune d'elles . On en fait ensuite la somme pour obtenir le nombre brut de points de fonction NBPF. On ajuste ensuite NBPF par une opration de correction base sur des degrs d'influence DI compris entre 0 et 5 (O : pas d'influence, 5 : influence maximum) pour obtenir le nombre net de points de fonctions NNPF suivant la formule :

NNPF = (0,65 + somme des DI/100)*NBPF

degr d'influence

communication de donnes systme distribu

performance intensit d'utilisation de la configuration matrielle

taux de transaction saisie interactive

convivialit mise jour en temps rel des GDI

complexit des traitements rutilisation du code de l'application

facilit d'installation facilit d'exploitation

portabilit de l'application facilit d'adaptation

Pour terminer, il faut passer du NNPF la charge en multipliant le premier par un coefficient multiplicateur. La mthode ne fournit pas ce coefficient (laiss la charge des SSII). Toutefois le tableau ci-dessous donne un ordre de grandeur du coefficient de transformation :

D'autres tudes proposent 0,1 0,5 jourxhomme par point de fonction.

Tests

Exercice 1

L'tape "tude pralable" d'un projet est estime 10 jours. En utilisant la mthode de la rpartition proportionnelle, estimer les charges des diffrentes tapes du projet.

Exercice 2

Un projet de logiciel est estim 60 000 instructions source. En utilisant les mthodes Cocomo, puis la mthode de rpartition proportionnelle, dterminer la charges des diffrentes tapes du projet.

Solution de l'exercice 1

L'tape "tude pralable" d'un projet est estime 10 jours. En utilisant la mthode de la rpartition proportionnelle, estimer les charges des diffrentes tapes du projet.

On se fixe les ratios suivants :

tape ratio

tude pralable 10% du projet

tude dtaille 23% du projet

tude technique 10% de la charge de ralisation

ralisation 2 fois la charge de l'tude dtaille

mise en oeuvre 35% de la charge de ralisation

Il faudra y rajouter les charges complmentaires :

encadrement du projet : 20% de la charge de ralisation (tape de ralisation) ; 10% de la charge (autres tapes) recette : 20% de la charge de ralisation documentation utilisateur : 5% de la charge de ralisation

A partir de la charge de l'tude pralable, on dtermine la charge du projet : 100 jours approximativement (sans les charges complmentaires). Les autres charges peuvent tre dduites de ces rsultats (on arrondit les calculs puisque nous faisons une approximation). :

Solution de l'exercice 2

Cocomo :

Charge = 3*601,12 = 295 mh = 5900 jh

Avec les ratios de l'exercice 1, on obtient :

Disque localEstimation des charges

Documents

B303_Ch3