Module 303

Gestion de Projets

Estimation des charges

Bibliographie

Grard-Michel Cochard
cochard@u-picardie.fr

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

Organic

2.4 1.05

Semi-detached 3.0 1.12

Embedded

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

Rating
Low

Very
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.65

TIME

Execution time constraint

1.00

1.11

1.30

1.66

STOR

Main storage constraint

1.00

1.06

1.21

1.56

VIRT

Virtual machine volatility

0.87

1.00

1.15

1.30

TURN

Computer turnaround time

0.87

1.00

1.07

1.15

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

Computer

Personnel

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
Organic

3.2 1.05

Semi-detached 3.0 1.12

Embedded

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

Very Low 1.80 1.35 1.35 1.50

Low
ACAP

0.85 0.85 0.85 1.20

Nominal 1.00 1.00 1.00 1.00

High

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 tables de donnes sources

nombre de
vues

<4

<8

>=8

nombre de
sections

<4

<8

>=8

<3

simple

simple

moyen

01

simple

simple

moyen

37

simple

moyen

complexe

23

simple

moyen

complexe

8 et +

moyen

complexe

complexe

4 et +

moyen

complexe

complexe

crans

rapports

Aprs avoir dnombr les objets par type et complexit, un facteur (poids de complexit) est affect chaque objet :
type/
complexit

simple

moyen

complexe

cran

rapport

composant
3GL

10

De plus, le fait de rutiliser des composants dj existants est pris en considration avec un coefficient donn par
un pourcentage : R (pourcentage d'objets rutiliss). Par ailleurs, la productivit est galement prise en compte
selon le tableau suivant.
exprience de
dveloppement

trs
basse

basse

moyenne

forte

trs
forte

performance
du produit

trs
basse

basse

moyenne

forte

trs
forte

push

13

25

50

La formule magique donnant la charge est alors la suivante :

charge (en moisxhommes) = (nombre de points objet).(100-R)/(100.push)

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

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
Counterpart
Combined
Cost
Description
PostDriver
Architecture
Cost Driver

Product

Product
reliability
RCPX
and
complexity

Description

Rating
Very Low

Low

Nominal

High

Very High Extra

High

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.66

RELY,
DATA,
CPLX,
DOCU

RUSE

Required reusability

0.91

1.00

1.14

1.29

1.49

DOCU

Documentation

0.95

1.00

1.06

1.13

Platform

Required
reuse

TIME

Execution time constraint

1.00

1.11

1.31

1.67

RUSE

RUSE

STOR

Main storage constraint

1.00

1.06

1.21

1.57

Platform volatility

0.87

1.00

1.15

1.30

PDIF

TIME,
STOR,
PVOL

PVOL

Platform
difficulty

PERS

Personnel
capability

ACAP,
PCAP,
PCON

PREX

Personnel
AEXP,
experience PEXP, LTEX

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

Language and tool experience

1.22

1.10

1.00

0.91

0.84

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.78

SCED

Development Schedule

1.29

1.10

1.00

1.00

1.00

FCIL

Facilities

TOOL, SITE

LTEX

SCED

Schedule

SCED

Project

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 High

Precedentedness

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.00

Architecture/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.00

Process 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

complexit des GDE

1 19 DE

20 50 DE

51 DE ou plus

1 SLD

faible

faible

moyenne

2 5 SLD

faible

moyenne

6 SLD ou plus

moyenne

leve

1 19 DE

20 50 DE

51 DE ou plus

1 SLD

faible

faible

moyenne

leve

2 5 SLD

faible

moyenne

leve

leve

6 SLD ou plus

moyenne

leve

leve

complexit des ENT

complexit des SOR

1 4 DE

5 15 DE

16 DE ou plus

1 5 DE

6 19 DE

20 DE ou plus

0 ou 1 GDR

faible

faible

moyenne

0 ou 1 GDR

faible

faible

moyenne

2 GDR

faible

moyenne

leve

2 3 GDR

faible

moyenne

leve

3 GDR ou plus

moyenne

leve

leve

4 GDR ou plus

moyenne

leve

leve

complexit des INT

1 5 DE

6 19 DE

20 DE ou plus

0 ou 1 GDR

faible

faible

moyenne

2 3 GDR

faible

moyenne

leve

4 GDR ou plus

moyenne

leve

leve

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

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

complexit

faible

moyenne

leve

points de fonction des GDI

10

15

points de fonction des GDE

10

points de fonction des ENT

points de fonction des SOR

points de fonction des INT

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 :