3.

GESTION DE PROJET
3.1.
ESTIMATION DES COUTS ET DUREE......................................................1
3.2.
ESTIMATION DE LA TAILLE VIA LES POINTS DE FONCTION
(ALBRECHT 79) ............................................................................................................1
3.3.
ESTIMATIONS DES COUTS: MODELE COCOMO CONSTRUCTIVE
COST MODEL (BOEHM, 81).......................................................................................2
3.3.1. Le Modle de base............................................................................... 2
3.3.2. Hypothses........................................................................................... 3
3.3.3. Distribution par phases ........................................................................ 3
3.3.4. Limitations du modle de base ............................................................ 5
3.3.5. Le modle intermdiaire...................................................................... 5
3.4.
LEMENTS DE PLANIFICATION ..............................................................6
3.4.1. Dcomposition structure des activits, (WBS) .................................. 6
3.4.2. Ordonnancement et dpendances: Graphe PERT................................ 8
3.4.3. Rpartition des activits: diagramme de Gantt.................................... 8
3.5.
PLAN PROJET.................................................................................................9
3.5.1. Contenu du plan projet ...................................................................... 10
3.5.2. Modle de plan projet IEEE (1987)................................................... 10
3.5.3. Planification pour le paradigme orient objets.................................. 10
3.6.
SUIVI DE PROJET ........................................................................................11
3.6.1
Rapports d'activits............................................................................ 11
3.6.2. Diagrammes 45 ............................................................................. 11
3.7.
ORGANISATION DU TRAVAIL.................................................................12
3.7.1. lments de rflexion pour le partage du travail............................... 12
3.7.2. Les acteurs principaux d'un projet..................................................... 13
3.7.3. Profil des membres d'une quipe ....................................................... 13
3.7.4. Ncessit de la structuration.............................................................. 14
3.7.5. Les types d'organisation .................................................................... 14
3.7.6. La taille des quipes .......................................................................... 16
3.7.7. Facteurs humains ............................................................................... 16
3.8.
ORGANISATION DE LA DOCUMENTATION........................................16
3.8.1. Documents de rfrence .................................................................... 16
3.8.2. Forme des documents ........................................................................ 17
3.8.3. Documentation utilisateurs ................................................................ 17
3.8.4. Documentation interne ...................................................................... 18
3.9.
CONCLUSION ...............................................................................................18

3. GESTION DE PROJET
Il n'est pas rare pour un projet logiciel de dpasser le dlai estim de 25 100%, c'est mme partir de ces
constatations que la crise du logiciel est apparue Aujourd'hui si quelques projets ont encore des drapages
parfois catastrophiques, certains ne dpassent les prvisions que de 5 10% seulement, le prsent chapitre
donne quelques indications pour parvenir ce type de rsultat..
Il est indispensable pour le client comme pour le fournisseur (chef de projet et management) d'estimer
l'avance la dure (calendrier) et le cot (effort) d'un projet logiciel. Il convient galement d'en mesurer les
risques en recensant les dpendances extrieures qui influeront sur les cots et dlais. Une remarque pralable
s'impose quant au processus d'estimation : beaucoup trop souvent, le management et les clients ont de la peine
comprendre que l'estimation est une activit comportant des difficults intrinsques et la rendent encore plus
difficile par ce manque de comprhension. Le processus requiert des raffinements successifs, il est impossible
de fournir une estimation correcte jusqu' ce que le logiciel soit apprhend dans son intgralit.
L'estimation des cots et dure se fait en trois tapes :
lors d'une rponse un appel d'offres o il s'agit de fournir au plus vite une rponse adapte au march,
lors de la planification du projet o il s'agit d'tablir le plan projet et le plan qualit qui serviront de cadre
contractuel au projet,
lors du droulement du projet afin d'affiner les prvisions et de les mettre jour.

3.1.

PROCESSUS D'ESTIMATION

La meilleure faon d'valuer le montant proposer dans un devis est sans doute de connatre le budget que le
client est prt lui consacrerIl est toutefois peu probable que le client ait la navet de faire part de ses
prvisions de dpenses.
L'estimation du cot total d'un projet logiciel comprend le cot de dveloppement du logiciel et du matriel,
le cot de la formation, le cot des outils Nous nous limitons ici au cot de dveloppement du logiciel qui
sera calcul en fonction du temps pass dvelopper celui-ci par les ingnieurs dont on connat le tarif horaire
et le taux d'implication dans le projet en terme de pourcentage de leur temps. Les cots du dveloppement
logiciel sont donc troitement lis la notion de productivit des ingnieurs logiciels, c'est dire le nombre de
lignes de code (valides) produites par unit de temps. A noter qu' ces cots salariaux chargs, il ne faudra pas
oublier de rajouter les cots fixes selon un mode de calcul propre chaque entreprise. Dans la suite lorsque nous
parlerons de cots, nous entendrons donc effort en terme d'hommes/mois.
Une mthode raisonnable pour tablir une rponse un appel d'offres, est de faire appel des experts qui
vont procder par analogie avec des projets dj achevs. On value chaque lment important du nouveau
systme en terme de pourcentage de cot d'un lment comparable dans le systme achev. L'estimation du cot
total du nouveau projet est obtenue par sommation des estimations lmentaires. L'estimation est un exercice
difficile, impossible en thorie et faisant donc appel des heuristiques. Dans de trop nombreux cas, l'estimation
pralable est faite la hte dans le but de remporter un march, la planification qui s'ensuit est souvent pnalise
par une sous-estimation initiale des cots et dlais globaux.
Nous suggrons, en accord avec B.Boehm d'viter de donner une estimation qui s'appuie sur un chiffre
unique mais recommandons plutt d'encadrer les prdictions par une fourchette optimiste/pessimiste. Le tableau
ci dessous (Adapt de "Cost Models for Future Software Life Cycle Processes: COCOMO 2.0" , Bohem et al.
1995) donne une base d'estimation pour passer d'un chiffre unique une fourchette grce des coefficients
multiplicateurs.
Taille et effort
Optimiste
Pessimiste
Analyse initiale des besoins
0.25
4.0
Dfinition approuve des besoins
0.5
2.0
Spcification des besoins
0.67
1.5
Conception Globale
0.80
1.25
Conception dtaille
0.90
1.10
Tableau 3. 1 : Coefficients multiplicateurs pour chaque phase du projet
Phase

dure
Optimiste
Pessimiste
0.60
1.60
0.80
1.25
0.85
1.15
0.90
1.10
0.95
1.05

Pour utiliser les facteurs multiplicatifs du tableau, il suffit de multiplier le point d'estimation unique par les
coefficients appropris de manire obtenir une fourchette d'estimation dont on peut remarquer qu'elle se

Gestion de projet

Anne-Marie Hugues 15/02/01

3-1

resserre au fur et mesure que l'on avance dans les phases (0.90 1.10 en conception dtaille contre 0.25 4
en analyse initiale des besoins, donc au moment de la rponse l'appel d'offres!)
Plutt que d'estimer la dure du projet dans son ensemble on peut le dcompose et estimer chacun de ses
composants. Nous verrons que cette technique s'applique trs bien l'approche objets du fait de l'indpendance
des diffrents objets entre eux.

Quelques rgles d'or pour l'estimation

Eviter de deviner : prendre le temps de rflchir , ne jamais rpondre sans avoir

tudier la situation calmement
Prvoir du temps pour l'estimation et la planifier
Utiliser des donnes de projets prcdents
Prendre l'avis des dveloppeurs qui vont effectivement effectuer le travail
Estimer par consensus : consulter les diffrentes quipes , converger sur des dates
au plus tt et au plus tard
Estimer par difficults (facile, moyen, difficile)
Ne pas oublier les tches rcurrentes : documentation, prparation des
dmonstrations utilisateurs, formation utilisateurs et dveloppeurs, intgration
l'existant, rcupration des donnes, revues, runions, maintenance de l'existant
pendant le dveloppement du nouveau produit, gestion qualit, absentisme
(congs, maladie, RTT)
Utiliser plusieurs techniques d'estimation
Changer de mthodes d'estimation au fil de l'avancement du projet
Prendre en compte les risques de gestion dans l'estimation

De manire gnrale, le processus d'estimation passe par 3 tapes

1. Estimer la taille du produit (nombre de lignes de code ou points de fonctions)
2. Estimer l'effort (en homme mois)
3. Estimer la dure (en mois ou semaines calendaires)

3.2.

ESTIMATION DE LA TAILLE VIA LES POINTS DE FONCTION (ALBRECHT 79)

L'estimation des cots passe comme nous l'avons vu en dbut de chapitre par l'estimation de la taille et de la
productivit. Dans un premier temps nous avons dfini la productivit en terme de nombre de lignes de code
source produites par unit de temps, cette mtrique simple prsente cependant certains inconvnients:
- l'criture de lignes de code reprsente une toute petite partie du dveloppement
- pour des langages diffrents un mme logiciel se code avec un nombre de lignes diffrent
- comment compter le nombre de lignes (commentaires)?
- on crit souvent du code non livr (outils de dveloppement)
- le nombre de lignes ne peut tre compt qu'a posteriori
Un autre moyen de mesurer la productivit consiste valuer le nombre de fonctionnalits intressantes
produites par units de temps. La mthode des points de fonction, dfinie chez IBM par Albrecht en 1979, puis
rafine en 83 propose ainsi d'estimer la taille d'un logiciel partir de valeurs connues tt dans le cycle de vie et
qui sont indpendantes du langage choisi pour l'implmentation. La mthode est aujourd'hui dfendue et mise
jour par l'IFPUG (the International Function Point User Group ) qui publie the Function Point Counting
Practices Manual dont la version courante est le IFPUG Manual 4.1.
Le nombre de points de fonctions d'un programme est bas sur le nombre et la complexit de cinq
paramtres.:

Les donnes
Entres externes (External Inputs EI) - Ces donnes peuvent venir d'un cran ou d'une autre application,
elles peuvent tre utilises pour mettre jour un ou plusieurs fichiers internes, il peut s'agir d'informations ou de
donnes de contrle. Les crans, boites de dialogue, messages travers lesquels un utilisateur entre une donne
font partie des entres externes.
Sorties externes. (External outputs EO) - Ce sont les sorties d'un programme, elles peuvent prendre la
forme de fichiers de sortie envoys d'autres application, d'crans, de rapports de graphes destins l'utilisateur
final ; ils sont crs partir de fichiers logiques internes.

3-2

Anne-Marie Hugues 12/02/01

Gestion de projet

Modle
Modle des
des points
points de
de fonction
fonction

Fonctionnalits
Fonctionnalits
de
de
ll application
application

Utilisateurs externes

Autres
Autres applications
applications
EQ
EQ

Application
Application

EIF
EIF

ILF
ILF

Points
de
fonction

ILF
ILF
EO
EO
ILF
ILF

EI
EI

taille

Autres
Autres applications
applications

Figure 1 : Modle des points de fonction

Les transactions
Requtes externes (External Inquiry EQ) - Un procd lmentaire mettant en jeu des entres et des
sorties qui rsulte en la production de donnes provenant de plus d'un fichier logique interne. Le processus ne
met pas jour de fichier interne, combinaison d'entres /sorties o le rsultat apparat sous forme simple et
immdiate, gnralement en utilisant une seule cl d'accs. La frontire entre requte externe et donne externe
est assez floue. Nous dirons que les requtes concernent exclusivement les accs une base de donnes alors
que les donnes externes combinent ces accs avec des calculs et traitements plus ou moins complexes.
Fichiers logiques internes (Internal Logical Files ILFs) - Un groupe de donnes corrles entirement
rsidant dans les limites de l'application, mis jour par les donnes externes, entirement contrl par le
programme. Par exemple un fichier, une table dans une base de donnes
Fichier interfaces externes (External Interface Files EIFs) - Un groupe de donnes corrles utilises
pour des rfrences seulement. Les donnes rsident entirement hors de l'application et sont mises jour par
une autre application (c'est donc un ILF pour une autre application)
Aprs que les composants du projet aient t ainsi classifis, chaque paramtre est affect d'un score : faible,
moyen, lev. Pour les transactions (EIs, EOs, EQs) le score est calcul sur le nombre de fichiers mis jour
ou rfrencs (FTRs) et le nombre de types de donnes impliques (DETs).
FTR's
0-1
2
>2

Donnes
1-4
faible
faible
moyen

5-15
faible
moyen
haut

>15
moyen
haut
haut

Tableau 3.2: Table EI:

Une requte est note (faible, moyenne ou haute ) comme une sortie externe (EO) mais on lui attribue une
valeur plutt comme une entre externe. La notation est base sur le nombre total des lments de donnes et
des types de fichiers rfrencs (combinaison "ddoublonne" des entres et sorties). Si un fichier ou un type est
utilis plusieurs fois il est rpertori une seule fois.

Gestion de projet

Anne-Marie Hugues 15/02/01

3-3

FTR's
0-1
2-3
>3

lments de Donnes
1-5
6-19
faible
faible
faible
moyen
moyen
haut

>19
moyen
haut
haut

Tableau 3.3 : Table EO et EQ:

Pour les fichiers externes et internes (ILFs and EIFs ) le score (haut, moyen , lev) est bas sur le type des
lments d' enregistrements (Record Element Types) et le nombre de types des donnes (Data Element Types).
Un type d'lment d'enregistrement est un sous groupe reconnaissable de donnes dans un ILF ou EIF. Un type
de donne est un champ unique non rcursif.
RET's
1
2-5
>5

Data Elements
1-19
faible
faible
moyen

20-50
faible
moyen
haut

>50
moyen
haut
haut

Tableau 3. 4Table ILF and EIF:

On rcapitule ensuite dans un tableau les scores de chacun des paramtres et on obtient le nombre de points
de fonction bruts (UFP)
Points de fonction
Caractristiques
du
Faible
Complexit
programme
Haute complexit
Total
complexit moyenne
Nombre d'entres externes
__*3=
__*4=
__*6=
__
Nombre de sorties externes
__*4=
__*5=
__*7=
+__
Nombre de requtes
__*3=
__*4=
__*6=
+__
Nombre de fichiers logiques
__*7=
__*10=
__*15=
+__
internes
Nombre de fichiers interfaces
__*5=
__*7=
__*10=
+__
externes
Nombre total de
points de fonctions
__
bruts (UFP)
Multipli par le
facteur d'ajustement*
__
TCF
Total de points de
fonction ajusts
__
AFP
Tableau 3.5 Multiplicateurs de points de fonction.
source: adapt de "Applied Software Measurement" (Jones 1991)

3-4

Anne-Marie Hugues 12/02/01

Gestion de projet

On calcule ensuite le facteur d'ajustement partir de 14 caractristiques gnrales du systme. Pour chaque
caractristique on value le degr d'influence DI de 0 (aucune influence) 5 (trs grande influence). La table
ci-dessous donne un aperu des caractristiques gnrales du systme pour les auteurs du manuel utilisateurs de
l'IFPUG.
Caractristiques
Description
gnrales du systme
Communication
de
Combien de facilits de communication pour aider au transfert ou l'change
donnes
d'information avec l'application ou le systme?
Distribution
du
Comment les donnes et les traitements distribus sont ils grs
traitement et des donnes
Critres
de
L'utilisateur a t il des exigences en matire de temps de rponse?
performance
Configuration
Quel est l'tat de charge actuel de la plate-forme matrielle sur laquelle le
matrielle trs charge
systme sera mis en exploitation?
Frquence
des
Quelle est la frquence d'excution des transactions (quotidien, hebdomadaire,
transactions
mensuel)
Donnes saisies en
Quel est le pourcentage de donnes saisies en temps rel?
temps rel
Efficacit
interfaces utilisateur

des

Mise jour en temps

rel des fichiers internes
logiques
Calculs complexes
Rutilisabilit
Facilit d'installation
Facilit oprationnelle
Portabilit
Evolutivit

Les interfaces ont elles t dessines pour atteindre l'efficacit maximale de

l'utilisateur
Combien de fichiers logiques internes sont ils mis jour en temps rel?
L'application fait elle appel des traitements logiques ou mathmatiques
complexes?
L'application est elle dveloppe pour satisfaire un ou plusieurs besoins clients?
Quelle est la difficult de conversion et d'installation?
Quelle est l'efficacit et /ou l'automatisation des procdures de dmarrage,
backup, et rcupration en cas de panne ?
L'application est elle spcifiquement conue, dveloppe maintenue pour tre
installe sur de multiples sites pour de multiples organisations?
L'application est elle spcifiquement conue, dveloppe maintenue pour
faciliter le changement?

Tableau 3.6 : Caractristiques gnrales du systme

Une fois que les caractristiques gnrales du systme ont t values avec leur degr d'influence respectif,
on peut calculer le degr d'influence DI. (0<DI<70) qui est la somme des degrs d'influence de chaque
caractristique.
Le facteur d'ajustement ou facteur technique de complexit se calcule par :
TCF = 0.65 + DI/100 , on a (0.65<TCF<1.35)
Et enfin on calcule le nombre de points de fonctions ajusts:
FP = TCF * UFC
On peut maintenant calculer les cots, l'effort et le calendrier partir d'expriences prcdentes, ou bien
utiliser une mthode rapide de calcul du planning (voir ci dessous).
De nombreuses expriences ont montr la supriorit de l'valuation par les points de fonction (Jones
constate une marge d'erreur de 200% avec les points de fonction alors qu'elle est de 800% avec le nombre de
lignes de code source!!.)
La mthode des points de fonction ne repose sur aucune technologie, il y a videmment une relation entre le
nombre de lignes de codes et le nombre de points de fonction que l'on peut trouver dans les archives de sa
propre entreprise ou bien en utilisant les tables de conversion nombre de points de fonction / nombre de lignes
de code que l'on peut trouver sur le site de l'IFPUG ( table de correspondance rpertoriant plus de 500
langages). Cette table permet de prdire le nombre de lignes assez tt. Elle permet aussi d'tudier les
productivits compares lors de programmation dans diffrents langages et de convertir la taille d'une
application dans n'importe quel langage.
Comme on peut le voir sur les caractristique gnrales retenues pour un systme, la mthode des points de
fonctions a t dfinie pour des projets essentiellement orients gestion. En 1986 la mthode dite des Features
Gestion de projet

Anne-Marie Hugues 15/02/01

3-5

points propose des extensions pour pouvoir tre applique en contexte industriel (logiciels embarqus, tlcoms,
systmes d'exploitation), elle prend en compte un nouveau paramtre, le nombre d'algorithmes. Sur les projets
"systmes d'information les deux mthodes convergent mais sur un petit systme temps rel on a pu constater
des divergences pouvant aller jusqu' 45 points de fonction contre 70 features points.

3.3. ESTIMATIONS DE L'EFFORT: MODELE COCOMO (BOEHM, 1981, 1998)

L'estimation de l'effort (en homme mois) fait suite l'estimation de la taille (en lignes de code source) et
permettra de dfinir un calendrier pour le projet.
La mthode COCOMO fournit un algorithme permettant de driver une valuation, de l'effort et du planning
partir de l'estimation de la taille du logiciel. Nous donnons en rfrence la mthode de (Putman and Myers
1992) qui conduit galement une valuation de l'effort

3.3.1 Description de la mthode

La mthode COCOMO, pour COnstructive COst Model a t dvelopp par Dr. Barry Boehm pour estimer
l'effort et le temps de dveloppement d'un produit logiciel. A l'origine elle a t construite partir d'une analyse
des donnes par rgression pratique sur 63 projets logiciels (gestion et informatique industrielle) comprenant
de 2000 100.000 lignes de code dans l'entreprise TRW (USA). COCOMO l'avantage d'tre un modle
ouvert. Les donnes de calibrage, les formules et tous les dtails des dfinitions sont disponibles. La
participation son dveloppement est encourage.
Aujourd'hui, COCOMO II est un nouveau produit beaucoup plus adapt l'aspect rutilisation des
composants (modules existants). La version 1998 a t calibre sur 161 points de donnes, en utilisant
l'approche statistique Bayesienne pour combiner les donnes empiriques avec les avis d'experts. De plus elle
peut tre re-calibre sur les donnes de l'entreprise. Un nouveau modle appel COCOTS, est en cours de
dveloppement par l'quipe de COCOMO. Ce modle permet d'estimer les cots et planifier des projets logiciels
utilisant des composants existants. C'est encore un projet de recherche.
Pour les projets bass sur une technologie traditionnelle, le modle original de 1981 est encore valable,
d'autant plus qu'il est maintenant rod et bien document.

3.3.2 COCOMO 81
Le modle COCOMO 81 s'appuie sur une estimation de l'effort en homme*mois (HM) calcule par la
formule
Effort = C*M*taille**s
C facteur de complexit
M facteur multiplicateur
Taille en milliers de lignes de code source livres (KDSI)
s proche de 1
Hypothses :
KDSI livr :
- Exclut en gnral les environnements de tests, les supports de dveloppement
- Exclut les commentaires
- Inclut le shell
HOMMES MOIS (HM)
- MM = 152 Heures (Normes amricaines), tient compte des vacances, arrts maladie...
Le modle COCOMO 81 est en fait constitu de trois modles :
- le modle de base
- le modle intermdiaire
- le modle dtaill ou expert
Le modle de base
Le modle de base estime l'effort (le nombre de homme mois) en fonction du nombre de milliers
d'instructions source livres(KDSI), de la productivit (le nombre de lignes de code par personne par mois) et
d'un facteur d'chelle qui dpend du type de projet.
Les 3 types de projet identifis sont :
organique
:
Il est dfini par une innovation minimale, une organisation simple en petites quipes
exprimentes. (ex: petite gestion, systme de notes dans une cole , petits systmes
d'exploitation, traducteurs)

3-6

Anne-Marie Hugues 12/02/01

Gestion de projet

mdian (semi-detached) :
Il est dfini par un degr d'innovation raisonnable, (exemples: Compilateurs, Contrle de
processus simple, systme bancaire interactif)
imbriqu
Dans ces projets le niveau d'innovation est important , l'organisation complexe, couplage fort
avec beaucoup d'interactions, (exemples: Gros systme d'exploitation, Systmes
transactionnels complexes, systme de contrle arospatial..)

TYPE DE PROJET
ORGANIQUE
MEDIAN
IMBRIQUE

effort en homme mois (HM)

2.4(KDSI)1.05
3.0(KDSI)1.12
3.6(KDSI)1.20

Temps de dveloppement
2.5(HM)0.38
2.5(HM)0.35
2.5(HM)0.32

Tableau 3. 7 formules d'estimation COCOMO pour le modle de base

EXEMPLES
Effort (HM)
Organique
Mdian
Imbriqu

2KDSI
5
6,5
8,3

8KDSI
21,3
31
44

32KDSI
91
146
230

128 KDSI
392
687
1216

512 KDSI
3250
6420

Tableau 3. 8 : Effort en HOMMES MOIS (HM) en fonction de la taille et du type de projet

TDEV( mois)

2KDSI

8KDSI

32KDSI

128 KDSI

512 KDSI

Organique

4.6

14

24

Mdian

4.8

8,3

14

24

42

Imbriqu

4.9

8,4

14

24

41

Tableau 3.9 : Temps de dveloppement (en mois) en fonction de la taille et du type de projet
Le temps de dveloppement commence aprs les spcifications fonctionnelles et s'arrte aprs l'intgration
De ces chiffres on peut dduire la productivit (KDSI/HM) et le nombre moyen de personnes sur le projet
(FSP=HM/TDEV).
On peut ensuite calculer la distribution de l'effort par phases (en %)
- RPD (Requirements and Preliminary Design): Conception globale et Plan d'intgration
- DD (Detail Design) : Conception dtaille
- CUT (Code and Unit Test) : Programmation et Tests unitaires
- IT (Integration and Test) : Intgration
PROJET ORGANIQUE
RPD
DD
CUT
IT
PROJET MEDIAN
RPD
DD
CUT
IT
PROJET IMBRIQUE
RPD
DD
CUT
IT

Gestion de projet

2 KDSI
16
26
42
16

8 KDSI
16
25
40
19

32 KDSI
16
24
38
22

128 KDI
16
23
36
25

512 KDSI

17
27
37
19

17
26
35
22

17
25
33
25

17
24
31
28

17
23
29
31

18
28
32
22

18
27
30
25

18
26
28
28

18
25
26
31

18
24
24
34

Anne-Marie Hugues 15/02/01

3-7

Tableau 3. 10 : distribution de l'effort par phases en pourcentatge

ORGANIQUE
RPD
DD et CUT
IT

2 KDSI
19
63
18

8 KDSI
19
59
22

32 KDSI
19
55
26

128 KDI
19
51
30

512 KDSI

MEDIAN
RPD
DD et CUT
IT

24
56
20

25
52
23

26
48
26

27
44
29

28
40
32

IMBRIQUE
RPD
30
32
34
DD et CUT
48
44
40
IT
22
24
26
Tableau 3.11 distribution du temps de dveloppement par phases en pourcentage

36
36
28

38
32
30

EXEMPLE :

Soit un projet estim 32 KDSI en mode organique,

HM
= 2.4 * (32)1.05 = 91 HM
TDEV
= 2.5 * (91)0.38 = 14 Mois
PRODUCTIVITE
= 32000 DSI/91 HM
= 352 DSI/HM
FSP
= 91 HM / 14 MOIS
= 6.5 FSP
Conformment au tableau 3.10, on a
PHASE DE CONCEPTION :
0.16 * 91 = 14.5 HM
PHASE DE CODAGE :
0.62 * 91 = 56.5 HM
PHASE D'INTGRATION :
0.22 * 91 = 20 HM
Conformment au tableau 3.11, on a :
PHASE DE CONCEPTION :
0.19 * 14 = 2.6 Mois
PHASE DE CODAGE
:
0.55 * 14 = 7.7 Mois
PHASE D'INTGRATION :
0.26 * 14 = 3.7 Mois
En divisant on obtient le nombre de personnes ncessaires pour chaque phase.

Le modle intermdiaire
Le modle de base ne prend en compte que le nombre de lignes source et induit des discontinuits un peu
brutales au niveau du personnel entre chaque phase du cycle de vie ; ce qui peut perturber l'organisation du
projet
Le modle intermdiaire introduit 15 facteurs de productivit (appels 'cost drivers'), reprsentants un avis
subjectif du produit, du matriel, du personnel, et des attributs du projet. Chaque facteur prend une valeur
nominative de 1, et peut varier selon son importance dans le projet. Ces facteurs sont rapprocher des
caractristiques gnrales du produit vus plus haut dans le paragraphe sur les points de fonction. Les 15 facteurs
sont multiplis entre eux pour donner un facteur d'ajustement qui vient modifier l'estimation donne par la
formule de base.
Facteurs de productivit
- Logiciel
- RELY: Fiabilit requise
- DATA: Volume des donnes manipules
- CPLX: Complexit du produit
- Matriel
- TIME: Contraintes de temps d'excution
- STOR: Contraintes de taille mmoire
-VIRT: Instabilit de la mmoire
- Personnel
- ECAP: Aptitude de l'quipe
- AEXP: Exprience du domaine
- VEXP: Exprience de la machine virtuelle
- LEXP: Matrise du langage
- Projet

3-8

Anne-Marie Hugues 12/02/01

Gestion de projet

- MODP: Pratique de dveloppement volues

- TOOL: Utilisation d'outils logiciels
- SCED: Contraintes de dlais

Multiplicateurs
RELY
DATA
CPLX

Trs bas
0,75

Bas
0,88
0,94
0,85

Nominal
1
1
1

Elev
1,15
1,08
1,15

0,87

1
1
1

1,11
1,06
1,15

1,3
1,21
1,3

1,18
1,13
1,1
1,07

1
1
1
1

0,86
0,91
0,9
0,95

0,7
0,82

MODP
1,24
1,1
1
0,91
TOOL
1,24
1,1
1
0,91
SCED
1,23
1,08
1
1,04
Tableau 3.12 Coefficients multiplicateurs pour chacun des facteurs de productivit

0,82
0,83
1,1

0,7

TIME
STOR
VIRT
ECAP
AEXP
VEXP
LEXP

1,44
1,29
1,21
1,14

TYPE DE PROJET
ORGANIQUE
MEDIAN
IMBRIQUE

effort en homme mois (HM)

3.2(KDSI)1.05
3.0(KDSI)1.12
2.8(KDSI)1.20

Trs lev Extrmement lev

1,4
1,16
1,3
1,65
1,66
1,56

Temps de dveloppement
2.5(HM)0.38
2.5(HM)0.35
2.5(HM)0.32

Tableau 3. 13 : coefficients pour le calcul d'effort et de temps dans le modle intermdiaire

Calcul de l'effort (HM) dans le modle intermdiaire
Identifier le mode de dveloppement - organique, mdian, imbriqu) . Ceci donne 4 coefficients au modle :
p (productivit nominative), e (chelle applique la taille du logiciel), c (constante du modle) et d (chelle
applique au temps de dveloppement) conformment au tableau 3.13.
Estimer le nombre de lignes du code source ( en KDSI), puis calculer le nombre d'homme*mois par la
formule approprie du tableau 3.13. On obtient HM base
Estimer les 15 facteurs de productivit et calculer le facteur d'ajustement (a) en multipliant les facteurs
ensemble conformment au tableau 3.12
Multiplier
l'effort
'nominal'
par
le
facteur
d'ajustement
:
HM = HM base * a
Calculer
le
temps
de
dveloppement
en
utilisant
le
tableau
3.13:
TDEV = c(HH)^d (on notera que les coefficients restent inchangs par rapport au modle de base)
Dans le modle intermdiaire, les coefficients multiplicateurs s'appliquent uniformment sur l'ensemble des
phases.
Modle expert
Le modle expert inclut toutes les caractristiques du modle intermdiaire avec une estimation de l'impact
de la conduite des cots sur chaque tape du cycle de dveloppement : dfinition initiale du produit, dfinition
dtaille, codage, intgration . De plus, le projet est analys en terme d'une hirarchie : module, sous systme et
systme. Il permet une vritable gestion de projet, utile pour de grands projets. Le modle expert n'est pas dcrit
ici.

Gestion de projet

Anne-Marie Hugues 15/02/01

3-9

3.3.2 COCOMO II
A la lecture du paragraphe prcdent sur COCOMO 81, plusieurs questions viennent l'esprit:
- une seule entreprise est-elle reprsentative comme base de dveloppement de COCOMO?
- COCOMO reste trs li au nombre de lignes de code, surtout le modle de base, mais plus les
programmeurs sont experts (et leur salaire lev), moins ils crivent de lignes de code pour un mme
projet!
- Comment prendre en compte le rutilisation?
Afin de prendre en compte ces critiques, COCOMO II (Boehm 98)est apparue.
COCOMO II peut tre calibr pour mieux correspondre aux projets de l'entreprise. COCOMO II tient
compte de la rutilisation
COCOMO II est constitu de trois modles :
Modle de composition d'application :
Ce modle est utilis pour les projets fabriqus l'aide des toolkits d'outils graphiques. Il est bas sur les
nouveaux 'Object Points'.
Modle avant projet :
Modle utilis pour obtenir une estimation approximative avant de connatre l'architecture dfinitive. Il
utilise un sous ensemble de facteurs de productivit (cost drivers). Il est bas sur le nombre de lignes de code ou
les points de fonction non ajusts.
Modle post-architecture :
Il s'agit du modle le plus dtaill de COCOMO II. A utiliser aprs le dveloppement de l'architecture
gnrale du projet. Il utilise des facteurs de productivit (cost drivers) et des formules.
Les facteurs utiliss sont classs en : Facteurs d'chelle, Urgence, Flexibilit de dveloppement, rsolution
d'architecture/Risque, Cohsion d'quipe et Maturit de Processus.

3.3.3 Conclusion
COCOMO reste le plus connu des modles d'estimation de cot de projet logiciel. Mais le modle d' origine
n'adresse pas les projets utilisant les composants logiciel existants. COCOMO II rpond ce problme, mais est
encore jeune, Le projet de recherche appel COCOTS est suivre pour les personnes dsirant estimer un projet
logiciel moderne.
COCOMO reste la rfrence en matire d'estimation dtaille des cots et surtout de la ventilation de ces
cots suivant les phases des projets. Les estimations de COCOMO sont d'autant plus fiables, que les paramtres
du projet sont bien connus, c'est--dire qu'on a profit des projets prcdents pour talonner ces paramtres.
La principale faiblesse rside dans la ncessit d'avoir une estimation du nombre de lignes du logiciel.
Cette taille du logiciel n'est connue qu' la fin de la ralisation et le problme de son estimation reste entier
mme si l'approche par les points de fonction peut fournir une aide. Ainsi, le management devra valuer la
justesse des prvisions tout au long de la dure de vie du projet.
Les rsultats montrent que les valeurs relles sont gales 20% prs aux valeurs estimes par COCOMO
dans 68 % des cas .

3-10

Anne-Marie Hugues 12/02/01

Gestion de projet

3.4. AUTRES METHODES D'ESTIMATION

3.4.1 Estimation rapide du calendrier (Jone's First-Order Estimation Practice)
Une mthode d'estimation rapide du temps de dveloppement consiste le calculer partir de l'effort en
utilisant la formule:
Temps de dveloppement en mois = 3.0 * HM^(1/3) ( ou : TDEV=3.0*effort(1/3))
Jones dfinit 3 types de projets
- logiciels systmes: systmes d'exploitation, pilotes, compilateurs, bibliothques de code
- logiciel de gestion: systmes d'information utiliss par une seule entreprise.
Business Software:in-house systems that are used by a single organization. They run on a
limited set of hardware, perhaps only a single computer.Payroll systems, accounting systems,
inventory control system, as well as (there) IS,IT and MIS software are in that category.
Shrink-wrap Software:software that is packaged and sold commercially.(word
processors,spreadsheet, but also financial analysis software, screenplay-writing and legal case
management programs)
Systems software does not include Embedded software,firmware,real-time sytems,scientific sofware and the
like. Productivity for this kinds of systems would be much lower. For you particular project, you can mix the
models , for example 40% Business, 60% shrink-wrap, and recompute the schedule and effort obtained with the
following
tables
with
these
proportions.
Le tableau 3.14 emprunt Jones donne une estimation de la dure partir du nombre de points de fonction.
Type de logiciel
Systmes
Gestion
Petits projets

Meilleur de la classe
0.43
0.41
0.39

Moyen
0.45
0.43
0.42

Pire de la classe
0.48
0.46
0.45

Tableau 3.14 Exposants pour le calcul de la dure partir des points de fonction: source: adapt de "Determining Software
Schedules" (Jones 1995c). Ces exposants ont t calculs partir de l'analyse de milliers de projets.
Exemple : pour un petit projet ayant 350 points de fonction confi une quipe moyenne on trouve 3500.42
soit environ 12 mois calendaires.
Cette pratique ne remplace pas des mthodes plus prcises mais donne une approximation rapide qui vaut
mieux que la simple devinette.
On notera que l'on retrouve la mme forme de mtrique que dans COCOMO 81 de base et des chiffres
sensiblement quivalents .
Estimation Ballpark Schedule:
Before using these tables, you may want to reduce the schedule, here is how to recompute effort
(possible
if
you
use
nominal
project
table..):

Schedule Compression factor= desired schedule/initial schedule

compressed schedule effort = initial effort/Schedule Compression factor

If you have an initial schedule of 12 months and an initial effort of 78 man months, and you want a 10
months schedule: that yield a compressed schedule effort of 94 man months which means that the 17
percent reduction in the schedule requires a 21 percent increase in effort
Most researchers have concluded that it isn't possible to achieve a schedule compression factor
lower than about 0.75-0.80 (Boehm 1981; Putnam and Myers 1992, Jones 1994).

Gestion de projet

Anne-Marie Hugues 15/02/01

3-11

Shortest
possible
Schedule:it
is
more
a
theorical
limit
you
can't
reach
source: derived from data in "Software Engineering Economics"(Boehm 1981),"An Empirical
Validation of Software Cost Estimation Models"(Kemerer 1987),"Applied software
Measurement"(Jones 1991),"Measures for Excellence"(Putman and Myers 1992),and "Assessment and
Control of Software risks"(Jones 1994).
Systems Products
Business Products
Shrink-Wrap products
Effort
Schedule
Effort
Schedule
Effort
System Size
Schedule
(man(calendar
(man(calendar
(man(lines of code)
(calendar
months)
months)
months)
months)
months)
months)
10,000
6
25
3.5
5
4.2
8
15,000
7
40
4.1
8
4.9
13
20,000
8
57
4.6
11
5.6
19
25,000
9
74
5.1
15
6
24
30,000
9
110
5.5
22
7
37
35,000
10
130
5.8
26
7
44
40,000
11
170
6
34
7
57
45,000
11
195
6
39
8
66
50,000
11
230
7
46
8
79
60,000
12
285
7
57
9
98
70,000
13
350
8
71
9
120
80,000
14
410
8
83
10
140
90,000
14
480
9
96
10
170
100,000
15
540
9
110
11
190
120,000
16
680
10
140
11
240
140,000
17
820
10
160
12
280
160,000
18
960
10
190
13
335
180,000
19
1,100
11
220
13
390
200,000
20
1,250
11
250
14
440
250,000
22
1,650
13
330
15
580
300,000
24
2,100
14
420
16
725
400,000
27
2,900
15
590
19
1,000
500,000
30
3,900
17
780
20
1,400
Efficient Schedule:the one you could reach with a good team , and very good management
source: derived from data in "Software Engineering Economics"(Boehm 1981),"An Empirical
Validation of Software Cost Estimation Models"(Kemerer 1987),"Applied software
Measurement"(Jones 1991),"Measures for Excellence"(Putman and Myers 1992),and "Assessment and
Control of Software risks"(Jones 1994).
Systems Products
Business Products
Shrink-Wrap products
Effort
Schedule
Effort
Schedule
Effort
System Size
Schedule
(man(calendar
(man(calendar
(man(lines of code)
(calendar
months)
months)
months)
months)
months)
months)
10,000
8
24
4.9
5
5.9
8
15,000
10
38
5.8
8
7
12
20,000
11
54
7
11
8
18
25,000
12
70
7
14
9
23
30,000
13
97
8
20
9
32
35,000
14
120
8
24
10
39
40,000
15
140
9
30
10
49
45,000
16
170
9
34
11
57
50,000
16
190
10
40
11
67
60,000
18
240
10
49
12
83
70,000
19
290
11
61
13
100
80,000
20
345
12
71
14
120
90,000
21
400
12
82
15
140
100,000
22
450
13
93
15
160
120,000
23
560
14
115
16
195
140,000
25
670
15
140
17
235
160,000
26
709
15
160
18
280
180,000
28
910
16
190
19
320

3-12

Anne-Marie Hugues 12/02/01

Gestion de projet

200,000
250,000
300,000
400,000
500,000

29
32
34
38
42

1,300
1,300
1,650
2,350
3,100

17
19
20
22
25

210
280
345
490
640

20
22
24
27
29

360
470
590
830
1,100

Nominal Schedule:Average team, average project, a normal project!

source: derived from data in "Software Engineering Economics"(Boehm 1981),"An Empirical
Validation of Software Cost Estimation Models"(Kemerer 1987),"Applied software
Measurement"(Jones 1991),"Measures for Excellence"(Putman and Myers 1992),and "Assessment and
Control of Software risks"(Jones 1994).
Systems Products
Business Products
Shrink-Wrap products
Effort
Schedule
Effort
Schedule
Effort
System Size
Schedule
(man(calendar
(man(calendar
(man(lines of code)
(calendar
months)
months)
months)
months)
months)
months)
10,000
10
48
6
9
7
15
15,000
12
76
7
15
8
24
20,000
14
110
8
21
9
34
25,000
15
140
9
27
10
44
30,000
16
185
9
37
11
59
35,000
17
220
10
44
12
71
40,000
18
270
10
54
13
88
45,000
19
310
11
61
13
100
50,000
20
360
11
71
14
115
60,000
21
440
12
88
15
145
70,000
23
540
13
105
16
175
80,000
24
630
14
125
17
210
90,000
25
730
15
140
17
240
100,000
26
820
15
160
18
270
120,000
28
1,000
16
200
20
335
140,000
30
1,200
17
240
21
400
160,000
32
1,400
18
280
22
470
180,000
34
1,600
19
330
23
240
200,000
35
1,900
20
370
24
610
250,000
38
2,400
22
480
26
800
300,000
41
3,000
24
600
29
1,000
400,000
47
4,200
27
840
32
1,400
500,000
51
5,500
29
1,100
35
1,800

3.5 LEMENTS DE PLANIFICATION

On cherche :
- Dfinir les activits constituant le projet
- Organiser les activits dans le temps.
valuer les dpendances entre activits.
valuer l'effort ncessaire pour chaque activit (dure maximum et minimum).
- Affecter les personnes aux activits.

3.4.1.

Dcomposition structure des activits, (WBS)

La planification commence par un recensement des tches raliser. La dcomposition structure des
activits (WBS Work Breakdown Structure) permet de recenser l'ensemble des activits d'un projet et de les
dcomposer. La dcomposition apparat sous forme arborescente
Il s'agit d'une dcomposition purement statique :elle ne tient pas compte du temps, et par consquent ne
s'attache pas l'ordonnancement des activits. Elle permet une prsentation analytique: on doit dcomposer

Gestion de projet

Anne-Marie Hugues 15/02/01

3-13

jusqu' obtenir des activits qui soient bien dfinies et facile grer c'est dire dont les entres et rsultats sont
parfaitement identifis et dont la responsabilit est confie une ou des personnes prcise(s).
Elle permet au chef de projet de planifier son projet en tablissant le graphe PERT 1 de celui ci Elle permet
le suivi budgtaire du projet en liaison avec les activits lmentaires identifies lors de la construction du
PERT
La WBS doit tre complte car elle conditionne l'laboration du PERT et donc du budget. Elle doit tre non
ambigu dans la dfinition des activits Elle doit dfinir des activits dont le rsultat est mesurable, ces activits
feront l'objet d'affectation de ressources. Il est noter que certaines activits existent dans tout projet:
- laboration des diffrents documents du cycle de vie
- Inspections, - Revues
- Construction d'outils
- Apprentissage
Exemples de schmas de WBS, arborescences

NOUVEAUX
PRODUITS
OU EXTENSIONS
0000

Activite de
GESTION
1000

1dcrit

3-14

Activites de
DEVELOPPEMENT
2000

Activites de
MAINTENANCE
3000

Activites de
QUALIFICATION
4000

plus loin
Anne-Marie Hugues 12/02/01

Gestion de projet

Activites de
dveloppement
2000

Dfinition des
besoins
dfinition du
produit

Prparation
annonce
2400

2200

-Dfinition des besoins

. cahier des charges
-Dfinition du produit
. spcifications
fonctionnelles
plan projet
Dfinition

- documentation client
Dveloppement
2300

des

objectifs

2100

-tude de faisabilit
-tude d'opportunit
-spcifications d'objectifs
-plan de la phase 1

3.4.2.

Ordonnancement et dpendances: Graphe PERT

On utilise un graphe de dpendances: (PERT: Project valuation and Review Technique). Pour chaque
tche, on indique une date de dbut et de fin au plus tt et au plus tard.
Le diagramme permet de dterminer le chemin critique qui conditionne la dure minimale du projet. Ces
techniques ne sont en aucun cas propres au gnie logiciel; elles sont par exemple trs fortement appliques dans
le BTP.
Exemple:

Gestion de projet

Anne-Marie Hugues 15/02/01

3-15

(0,3)
A1

(3,7)

(7,9)

A3

A8

(0,3)

(3,7)

(0,0)
(3,5)

Dbut

(0,0)

(0,2)
A2
2
(3,5)

2
(13,15)

(15,1

(7,11)

A4

A6

(9,11)

Fin

(15,1

(7,11)

(2,8)
A5
6
(5,11)

(11,15)
A7
4
(11,15)

Les

dures apparaissent dans les cercles,

les couples au dessus sont les dates de dbut et de fin au plus tt,
les couples au dessous sont les dates de dbut et de fin au plus tard.
A ce niveau les activits sont les plus lmentaires possibles
Si le projet ncessite plusieurs quipes, on a des PERT plusieurs niveaux

3.4.3.

Rpartition des activits: diagramme de Gantt

Ce diagramme permet de faire apparatre la rpartition des activits dans le temps et l'affectation des
individus. Il est indispensable pour dfinir le plan projet. Il fournit une description dtaille des cots (en
homme x mois) et des dates pour chaque tche et pour chaque phase du projet .
A chaque tache/sous tache on associe un objectif qui permet de reprer la terminaison de l'activit. On
dfinit des points cls (milestones) qui servent de borne intermdiaire (exemple: ralisation d'un prototype)
On dfinit les revues qui sont aussi des milestones, on n'oubliera pas la tche de prparation de la revue.

3-16

Anne-Marie Hugues 12/02/01

Gestion de projet

activit

A,B

10

Cumul act.

3
A,B

2.1
A,C

A,C
4

2.2
B

B,D

B,D

2.3

5
A,C

2.4
C,D

2.5

2
C,D

D
3

Tot.mens 1

Cumul

12

16

17

19

21

22

Attention aux pics brutaux, le passage du mois 6 au mois 7 n'est pas judicieux, on passe de 4 1; il est
souvent ncessaire de procder un lissage.

3.5. PLAN PROJET

C'est l'un des lments cls du cycle de vie. C'est aussi un lment de base de la planification du
dveloppement
Le responsable du plan projet est le chef de projet du dveloppement
L'laboration du plan projet se fait ds la phase de planification. On procde ensuite par actualisations
successives et raffinements.

Gestion de projet

Anne-Marie Hugues 15/02/01

3-17

3.5.1.

Contenu du plan projet

Le plan projet contient les lments qui permettent de dfinir le projet

- Domaine d'application
- Objectifs
- Principales fonctionnalits
- Autres caractristiques
- Les limites
- Les performances
- Scnario de dveloppement
- Classification des priorits et des contraintes
- Brve description de chaque composant
- Ressources
- Humaines
- Matrielles
- Logicielles
- Cot
- Calendrier
Ce document n'est pas forcment trs long. C'est avant tout un instrument de travail pour le chef de projet et
son management. C'est une garantie de qualit pour le client.

3.5.2.

Modle de plan projet IEEE (1987)

Introduction
rsum du projet
fournitures (avec les dates, documents, codes, jeux de tests)
procdures pour faire voluer le plan projet
rfrences des documents cits dans le plan projet
dfinitions et acronymes
Organisation du projet
modle de processus (organisation, bornes intermdiaires, revues avec participants but matriel dates..)
organisation structurelle (voir plus loin organisation des quipes)
limites et interfaces (description des interactions avec autres projets...)
rles et responsabilits
Management
Objectifs et priorits
Hypothses dpendances contraintes
Gestion du risque
moyens de contrle (rapport d'activits...)
ressources humaines (quipes affectes au projet)
Techniques
mthodes outils techniques employs (ex: OMT, OMTools, C++...)
documentation (dates de remise de la doc..)
fonctions support (gestion de configuration, tests, assurance qualit..)
Calendrier, budget, lots
lots (avec le dtail des activits et tches constituant chaque lot)
dpendances (matrielles et logicielles pour le projet mais aussi pour tests, simulation...)
ressources (autres qu'humaines, Identification des fournisseurs, sous-contractants, )
budget et allocation de ressource
calendrier dtaill (Gantt, comprenant les dates de revues)
Risques Problmes Proccupations
Il s'agit de lister ici les problmes potentiels que l'on pressent. En particulier
Hypothses sur les effectifs.
Difficults techniques (nouvelle technologie, )
Conflits sur le calendrier

3.5.3.

Planification pour le paradigme orient objets

Les mthodes d'valuation vues plus haut s'appliquent assez bien dans le cas de projet raliss en suivant le
paradigme objet. La forte modularit induit une valuation plus facile de chaque lment. Il faut bien
videmment tenir compte lors de l'valuation de l'ensemble des interactions existant entre chaque composant qui
gnrent un overhead qu'il ne faut pas ngliger.
3-18

Anne-Marie Hugues 12/02/01

Gestion de projet

La mthode COCOMO peut tre applique pratiquement telle quelle (si ce n'est quelques changements
mineurs dans certains coefficients) pourvu qu'il n'y ait pas trop de rutilisation. Si la rutilisation intervient
pendant le dveloppement, clairement les cots et dures devraient tre rduits. Il n'existe aujourd'hui aucun
outil d'valuation fiable prenant en compte la rutilisation.
Par contre si le dveloppement se fait en vue de la rutilisation il faudra prvoir une augmentation des
estimations. Des publications rcentes ont montr que le dveloppement de composant rutilisable peut prendre
jusqu' 3 fois plus de temps que pour un composant similaire non rutilisable.
On peut supposer qu'a long terme les conomies faites grce la rutilisation surpasseront le surcot
occasionn ( rapprocher de l'amortissement d'un investissement)

3.6. SUIVI DE PROJET

Une fois le planning dfini il importe de le respecter. Au niveau d'quipes de 4 10 personnes, le
responsable de projet utilise des fiches de suivi (ou rapports d'activits) qui permettent d'identifier les drives et
d'assurer le contrle budgtaire. Il en dduit :
- L'actualisation du graphe PERT
- Le diagramme de GANTT actualis
- Des diagrammes 45 qui donnent une perception visuelle de la drive par rapport aux objectifs.

3.6.1

Rapports d'activits

Chaque membre de l'quipe fournit un rapport d 'activit hebdomadaire succinct qui dcrit
- l'objectif atteindre pour la semaine
- le temps pass sur les diffrentes tches
- si les objectifs ont t atteints et si ce n'est pas le cas pour quelle raison.
A partir des rapports individuels, le chef de projet peut tablir un rapport d'activit de l'quipe.

3.6.2.

Diagrammes 45

Ils permettent de mesurer l'ange de drive des objectifs. En ordonne on reprsente les points cl (exemple
revue de fin de phase, obtention du prototype) tels qu'ils sont planifis T0. On utilise la mme chelle en
abscisse et en ordonne, d'o l'appellation 45 On suppose que les abscisses reprsentent des mois. Sur la figure
suivante, la revue P1 est prvue T0+3 (=P1)

P3
P2

P1

T0

T1

T2

A l'instant T0+1 la revue est toujours prvue T=T0+3

A l'instant T0+2, la revue est repousse d'un mois (P2)
A l'instant T0+3 (T1) la revue est encore repousse d'un mois (P3)
A l'instant T1+1, la revue est maintenue P3
A l'instant T2=P3, la revue a effectivement lieu.
On mesure l'angle form par la droite passant par les points de premire et dernire estimation horizontale,
si a =0 alors l'objectif initial a t atteint.
On tablit des seuils acceptables,
1. 20
bon niveau

Gestion de projet

Anne-Marie Hugues 15/02/01

3-19

2. < < 30
> 30

niveau moyen
niveau mdiocre, drive importante

3.7.

ORGANISATION DU TRAVAIL

3.7.1.

lments de rflexion pour le partage du travail

La rpartition du travail entre les membres d'une quipe ne peut pas toujours se faire. Cela dpend de la
nature de la tche effectuer; Les diagrammes ci-dessous donnent une ide de la dure du projet en fonction du
nombre de personnes affectes dans 3 cas diffrents.

DUREE DU

PROJET

PERSONNEL
TACHE PARFAITEMENT PARTITIONNEE

Exemple: codage et tests unitaires

DUREE DU

PROJET

TACHE NON PARTITIONNABLE

PERSONNEL

Exemple analyse et conception globale

DUREE DU
PROJET

PERSONNEL
TACHE NECESSITANT UNE COMMUNICATION COMPLEXE

Exemple dveloppement d'un systme d'exploitation embarqu avec fortes contraintes espace-temps

3-20

Anne-Marie Hugues 12/02/01

Gestion de projet

3.7.2.

Les acteurs principaux d'un projet

Le chef de projet
Il est responsable de l'ensemble du projet, la fois au niveau des cots et des dlais. Il est responsable de la
rdaction et du suivi du plan projet.
Le responsable qualit
Il est responsable de la mise en oeuvre du manuel qualit sur un projet donn. Il rdige et fait appliquer le
plan qualit du projet.
Le responsable des ressources matrielles
Il assure la disponibilit du matriel conformment la planification.
Le responsable de l'intgration
Il est responsable de la mise en oeuvre du plan d'intgration
Le responsable de la qualification
Il est responsable de la mise en oeuvre du plan de qualification
Le responsable des performances
Il est responsable des tests de performances conformment au cahier des charges et au plan qualit. Il prend
les mesures ncessaires pour atteindre les objectifs de performance dfinis dans le cahier des charges
(simulation, prototypes)
Le responsable de la maintenance
C'est le responsable de l'quipe qui prendra en charge la maintenance du produit (en gnral diffrente de
l'quipe de dveloppement).
Le responsable de la documentation
Il est responsable de la documentation du projet. Ceci ne veut pas dire qu'il rdige toute la documentation
associe au projet, mais plutt qu'il s'assure de sa rdaction. Il dfinit les normes de prsentation des documents
en accord avec le manuel qualit de l'entreprise. Il s'assure de la mise jour de la documentation.
REMARQUE:
Sur les gros projets, le chef de projet pourra nommer des responsables pour les phases amont du cycle de vie
(analyse des besoins, spcifications, conception, codage).

3.7.3.

Profil des membres d'une quipe

Ces profils doivent tre choisis en fonction de l'intervention dans les diffrentes phases du cycle de vie. Nous
rpertorions les qualits requises suivant les phases.
Dfinition et analyse des besoins
Savoir anticiper
Savoir analyser les stratgies
Spcifications fonctionnelles
Clart, prcision, cohrence, rigueur
L'idal serait un ingnieur ayant la double comptence: utilisateur et concepteur
Conception
Cette phase demande des communications intenses.
Capacits formaliser et abstraire
Programmation et tests unitaires
Discipline de programmation (style), rigueur, communication, sens du groupe
Intgration
C'est une phase o la comptence requise est bien souvent celle d'un ingnieur systme.

Gestion de projet

Anne-Marie Hugues 15/02/01

3-21

Qualification
Ici il s'agit plutt de la comptence d'un ingnieur d'application, c'est dire trs proche du
domaine du produit qualifier
Maintenance
La maintenance requiert des qualits de rigueur, analyse et expertise

3.7.4.

Ncessit de la structuration

Dans un groupe non structur de N personnes il y a N * (N -1) / 2 interactions "I"

Exemple
N = 3 --> I = 3
N = 11 --> I = 55
Il faut donc structurer les quipes pour diminuer le temps pass la communication.
Calcul du temps en heures/jour pour des groupes non structurs
N = 4 -->
T=2
N = 8 -->
T=4
N = 16 -->
T=6
N = 24 -->
T = 7.5 !!
Cependant la communication
- Amliore la comprhension du projet.
- Permet une plus grande mobilit dans le projet.
Mais aussi
- Fait perdre du temps.
- Peut nuire a la documentation
(dont on peut croire qu'elle devient moins ncessaire!).

3.7.5.

Les types d'organisation

Les extrmes:
PETIT GROUPE DE TRAVAIL SANS AUTORITE DEFINIE : EGOLESS PROGRAMMING
Le travail s'effectue par consensus; le travail de chacun devient le travail de tous. L'quipe s'enrichit par le
travail quotidien en commun, les revues et inspections de code. On limine l'attachement son programme, ses
ides.

Cette notion apparat pour la premire fois dans [Hein 71]. Elle est reprise dans les techniques de revues et
d'inspection de code dveloppes au chapitre validation/vrification.

3-22

Anne-Marie Hugues 12/02/01

Gestion de projet

L'ORGANISATION "CHIEF PROGRAMMER TEAM"

Il s'agit d'une structuration de l'egoless programming, faisant suite un projet russi publi par IBM en 1970.
Un ingnieur en chef ou chef de projet ou senior programmeur dirige l'quipe compose de 2 5 personnes.
Il coordonne, planifie et vrifie le travail effectu. L'adjoint seconde l'ingnieur en chef et peut tout instant le
remplacer.
L'quipe peut s'adjoindre les services d'un ou plusieurs experts (tlcoms, bases de donnes...).
Le bibliothcaire est une ressource partage par divers projets. Son importance ne peut tre nglige. Il
maintient et contrle les lments de la bibliothque de programmes, vrifie l'intgrit des configurations
(sources, donnes, bandes, documentation...) Il collecte les donnes qui permettront d'valuer la productivit.
L'amlioration de la qualit passe par cette activit d'archivage et de contrle.
Chacun a accs au travail de tous, l'ingnieur en chef a le leadership technique.

Ingnieur en chef
Adjoint
Bibliothcaire

Ingnieurs de
ralisation

Les structures intermdiaires:

CHEF DE PROJET POUR PLUSIEURS EQUIPES

Gestion de projet

Anne-Marie Hugues 15/02/01

3-23

COMIT DE DIRECTION ET PLUSIEURS QUIPES:

3.7.6.

La taille des quipes

Structuration en groupes de 2 10 personnes

Nombre magique:
=72

3.7.7.

Facteurs humains

Outre l'organisation du travail d'quipe il faut veiller

- Aux motivations individuelles et la motivation collective de l'quipe.
- Aux relations entre les membres et avec l'extrieur.
- A la dynamique du chef de projet.
- Aux cueils viter :
Sur-spcialisation
Trop de niveaux
Pas assez de niveaux
Dresponsabilisation
- A la formation et en particulier au temps d'apprentissage du domaine.
Mais il faut savoir que de grandes variations sont lies aux facteurs humains
- Temps de codage
1 A 25
- Temps de mise au point
1 A 26
- Temps CPU utilis
1 A 11
- Temps d'excution
1 A 13
- Lignes crites
1A5
- Nombres d'erreurs
1 A 10
Ces variations peuvent tre rduites par
- Mthodologies de dveloppement.
- Standards, normes,
- "Confort" : matriel, logiciel
en aucun cas elles ne peuvent tre annules

3.8. ORGANISATION DE LA DOCUMENTATION

La documentation associe un projet doit tre le reflet de la vie de ce projet. Elle est labore et mise jour
tout au long du projet. Elle est constitue par un ensemble de documents dont certains sont associs aux phases
"verticales " du cycle de vie et d'autres sont plus transversaux.
Elle est ralise par des spcialistes partir de documents fournis par l'quipe de dveloppement

3.8.1.

Documents de rfrence

Il s'agit des diverses documentations associes au projet, on distingue les lments destins aux utilisateurs
de eux destins aux dveloppeurs pendant le dveloppement et aux mainteneurs en phase de maintenance.

3-24

Anne-Marie Hugues 12/02/01

Gestion de projet

Documents lis une phase du cycle de vie (essentiellement destin aux dveloppeurs et mainteneurs)
- cahier des charges
- document de spcifications fonctionnelles
- plan d'intgration
- manuel de conception globale et dtaille
- procdures de validation
tests unitaires, d'intgration, de validation, de non rgression
- code
Documents transversaux la vie du projet
- Le glossaire, la liste des abrviations.
- Le plan projet
- Le plan qualit
Documents remis au client
- Le manuel utilisateur
- Le manuel d'installation
- Le manuel de maintenance

3.8.2.

Forme des documents

La documentation adopte une forme spcifie par le plan qualit. Elle est conforme aux normes et
conventions dictes par le manuel qualit de l'entreprise. Elle doit de toute faon comporter les notions de
numrotation, chapitre, statut, date, classification , mots cls. Tout comme le reste du produit, la documentation
doit tre maintenue pour rester en phases avec les volutions du produit.
NUMROTATION: Elle peut tre unique ou par classe ou par tche
STATUT :
Le statut peut prendre 4 valeurs
D dfinitif et approuv
P
partiel, sujet modification et /ou ajouts
R rvis (actualis)
I
incomplet (et dans ce cas la date laquelle le chapitre doit tre complet)
Exemples
rvision
(165 rvision 3)
question
(165 question 2)
commentaire
(165 commentaire 5)
CLASSIFICATION
document de travail
spcification
conception
code
test
administration
compte rendu de runion
MOTS CLS : Ils permettent des recherches automatiques
CONTENU : Le contenu sera prcis dans les chapitres associs aux diffrentes phases du cycle de vie.
RGLES DE STYLE
Utiliser des formes actives
Faire des phrases courtes, une seule ide par phrase
Faire des paragraphes courts (7 phrases au plus)
Prfrer les listes aux phrases
Ne pas hsiter rpter si ncessaire
Pas de verbiage
viter les rfrences du style 1.2.3.4.5 pour parler d'un objet, plutt nommer l'objet
tre prcis, dfinir les termes (glossaire)
Attention la grammaire et l'orthographe

3.8.3.

Documentation utilisateurs

Manuel utilisateur

Gestion de projet

Anne-Marie Hugues 15/02/01

3-25

Il doit donner une impression initiale correcte:

Ce n'est pas une plaquette publicitaire
Il doit tre possible de lire sans aller dans tous les niveaux de dtail
Structure possible:
- Description fonctionnelle simple l'aide d'exemples de ce que le systme peut faire
- Document d'installation: dcrit la procdure d'installation, souvent assorti d'un fichier A LIRE
(READ ME)
- Manuel d'Introduction (utilisation "normale", exemple simples), class par rubriques de
difficults croissantes
- Manuel de Rfrence: contient toutes les rfrences aux possibilits du systme classes par
ordre alphabtique.
Autres documents destins aux utilisateurs
Plaquette publicitaire
Carte de Rfrence
Aide en ligne (man)

3.8.4.

Documentation interne

Nous verrons la description prcise de ces documents dans les chapitres concerns. Nous insistons tout
particulirement sur la ncessit de maintenir la cohrence de tous les documents .
Pour cela il est souhaitable de grer TOUS les documents avec un gestionnaire de versions, par exemple
SSCS, RCS, MAKE...
L'utilisation d'un dictionnaire des donnes permettra d'avoir des dtails
- sur toutes les entits manipules
- avec des rfrences croises

3.9. CONCLUSION
La gestion de projet est une des meilleures garanties de l'assurance qualit, elle permet la matrise du
processus de dveloppement. Il existe un certain nombre d'outils pour aider le chef de projet dans sa tche.
Les outils manipulant des graphes PERT et des diagrammes Gantt: Mac Project, Method1, Teamwork
Access.
Les mthodes COCOMO et Function points peuvent tre programmes trs simplement sur des tableurs.
Enfin pour la documentation technique des outils comme Interleaf ou Framemaker seront prfrs Word
pour leur facilit d'interfaage avec les outils d'analyse et conception qui seront vus au chapitre suivant.

3.10 REFERENCES
de "Cost Models for Future Software Life Cycle Processes: COCOMO 2.0" , Bohem et al. 1995)
http://www.ifpug.org/
McConnell, Steve, Rapid Development,Microsoft Press,1996 Presents all the factor to achieve rapid
development, from risk evaluation, good practices, classical mistake, etc ... to team psychology or negociating.
Really great.
Boehm, Barry W., Software Engineering Economics,Englewood Cliffs N.J.: Prentice Hall 1981 COCOMO
cost-estimation model, by its creator.
DeMarco, Tom, Controlling Software Projects, New York: Yourdon Press,1982. Describes several
estimation models.
Putnam,Lawrence H., and Ware Myers. Measures of Excellence: Reliable Software on Time, Within Budget.
Englewood Cliffs N.J.:Yourdon Press,1992. Presents a full-fleged software-project estimation.Explains how to
calibrate a simple cost-estimation model to your organisation and how to use it to estimate medium to large
projects.
Jones,Capers. Assessment and Control of Software Risks. Englewood Cliffs N.J.:Yourdon Press,1994.
Estimation,Project management.

3-26

Anne-Marie Hugues 12/02/01

Gestion de projet

Gilb,Tom. Principles of Software Engineering Management. Workingham,Englang: Addison Wesley,1988.

Practical advices for estimating software schedule.Focus on the importance of controlling the project to achieve
your objectives rather than passive prediction about it.
Dreger,Brian. Function Point Analysis,Englewood Cliffs N.J.: Prentice Hall 1989
Function Point Analysis. Jones,Capers. Applied Software Measurement:Assuring Productivity and Quality,
New York:McGraw-Hill,1991. Function Point Analysis.
Boehm, Barry W., Software Engineering Economics, (1981) Cocomo dans toute sa profondeur, par l'auteur
de Cocomo lui mme.
Boehm, Barry W., Software engineering economics, IEEE Trans. on Software Engineering.,(1984) Dtails
pour assigner les valeurs aux 15 facteurs de productivit.
Shepperd, Martin, Fundation of Software Measurement, (1994) Le pourquoi et comment des diffrentes
mthodes de mesure de logiciels.
Katwijk, J. van, Inleiding software engineering, (1994)
Pressman, Roger S., (adapted by Darrel Ince) Software engineering "A practitioner's approach", (1994)

Universite de Californie du Sud, Centre de dveloppement de logiciel

C'est l'endroit ou COCOMO a t dvelopp et continu de l'tre. L'tat du dveloppement de
COCOMO II. Les sponsors du programme de recherche Tlcharger des logiciels et de la
documentation COCOTS Projet de recherche pour estimer les cots, les efforts et planifier des projets
logiciels utilisant des composants existants.
COQUALMO Un modle d'estimation logiciel pour quilibrer cot, planning et qualit.
CORADMO Le modle COCOMO RAD est une extension de COCOMOII centre sur les cots de
dveloppement logiciel utilisant les techniques du 'Rapid Application Development'.
Un projet estim avec COCOMO 2.0
Bibliographie Quelques estimateurs en ligne Expert COCOMO II par USC avec estimation de
risque Par Dr. Ray Madachy (Implementation trs innovante donnant galement une valuation des
risques. Interface graphique conviviale.)
COCOMO II par USC ( Interface lente et moins conviviale.)
Predicate logic software systems Estimation en ligne du modle intermdiaire de COCOMO 81.
COCOMO Intermdiaire Interactive Dvelopp par 2 tudiants de l'Universit de Caroline du Nord.
Interface graphique trs sympathique. Manuel d'utilisation et Information sur le calculation
(COCOMO 81).
La NASA Estimateur COCOMO : modle de Base (COCOMO 81). COCOMO II COSTAR
Entreprise commercialisant COCOMO II.
Critique de COCOMO Par des consultants spcialiss de la gestion du risque, par l'utilisation des
rseaux Bayesian (COCOMO II tant bas sur l'approche Bayesian). Modles d'valuation de projet
logiciel
Les modles orients activits Par M. JM Jaeger EN FRANCAIS!!
Universit du Texas : Projet COCOMO Prsentation de l'histoire de COCOMO. (Manuel
utilisateur et Estimateur en ligne (COCOMO 81)
Les buts de COCOMO Explications d'un professeur de l'Universit Britannique.
Estimation des cots logiciels Universit de Calgary. Bon rsum de la problematique mme si il
ne parle pas directement de COCOMO.
Methodes d'estimation des cots logiciels Prsentation rapide des diffrentes mthodes
d'estimation, suivie par une prsentation assez dtaille des 3 modles de COCOMO 81. Formules
COCOMO Prsentation intressante en diagrammes comments.(COCOMO 81) COCOMO :
quation de base (COCOMO 81), Universit Thalandaise
. Bibliographie d'Estimations de Logiciel Compil par l'Universit de Bournemouth, UK

Gestion de projet

Anne-Marie Hugues 15/02/01

3-27