Vous êtes sur la page 1sur 78

Mastre Spcialis HEC Mines de Paris

Management des Systmes dInformation et des Technologies

Thse Professionnelle

Mthodes dEstimation
de Charges
dans le cadre dun projet xNet

Georges Zadrozynski
Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

Cette thse professionnelle a t ralise la Direction des Systmes


dInformation de la Caisse des Dpts et Consignations (Etablissement
Public), dans le cadre de la formation du Mastre Spcialis Management
des Systmes dInformation et des Technologies, conduite conjointement
par lEcole des Hautes Etudes Commerciales (HEC) et lEcole Nationale
Suprieure des Mines de Paris (ENSMP).

Responsable Acadmique : Alain Berdugo


(Professeur HEC, Directeur du Mastre MSIT)

Responsable Entreprise : Andr Probst


(Responsable Mthodes de la DSI CDC - Etablissement Public)

Copyright 2002 Georges Zadrozynski


Tous droits rservs
http://www.gezzed.net
gz@msit.org

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

Mthodes dEstimation de Charges


dans le cadre dun projet xNet

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

Table des Matires


TABLE DES MATIERES ..................................................................................................................................................................5
REMERCIEMENTS ...........................................................................................................................................................................6
INTRODUCTION................................................................................................................................................................................7
I. L'EVALUATION DE CHARGES DUN PROJET INFORMATIQUE...........................................................................8
I.1. POURQUOI EVALUER LES CHARGES ? .......................................................................................................................................8
I.2. LE CONCEPT DE "JOUR*HOMME" .............................................................................................................................................8
I.3. LES PIEGES DE LEVALUATION THEORIQUE ...........................................................................................................................10
II. LE PROJET XNET ..................................................................................................................................................................... 12
II.1. LE XNET....................................................................................................................................................................................12
II.2. CARACTERISTIQUES INTRINSEQUES DUN XNET.................................................................................................................16
III. ETAT DE LART DES METHODES DEVALUATIONS............................................................................................ 20
III.1. M ETHODE DES POINTS DE FONCTIONS................................................................................................................................20
III.2. M ETHODE COCOMO...........................................................................................................................................................26
III.3. EVALUATEUR-RAD (J-P.VIKOFF).......................................................................................................................................36
III.4. M ETHODE INTERNE CDC (A.PROBST ) ...............................................................................................................................42
III.5. M ETHODE INTERNE ICDC (ESTIMAT) .............................................................................................................................51
IV. EVALUATION DUN XNET ................................................................................................................................................. 56
IV.1. INTRODUCTION.......................................................................................................................................................................56
IV.2. CREATION DUN X NET & AJOUT DE MODULES..................................................................................................................57
IV.3. A LORS COMMENT EVALUER LE XNET ?..............................................................................................................................58
V. UN EXEMPLE CONCRET : RPI........................................................................................................................................... 59
V.1. PRESENTATION ........................................................................................................................................................................59
V.2. ESTIMATIONS THEORIQUES DE LA CHARGE DE RPI............................................................................................................65
V.3. DEROULEMENT CONCRET ......................................................................................................................................................71
V.4. CONCLUSION............................................................................................................................................................................72
CONCLUSION .................................................................................................................................................................................. 74
LA BONNE METHODE ?....................................................................................................................................................................74
QUELQUES BONNES PRATIQUES.....................................................................................................................................................74
ANNEXES ........................................................................................................................................................................................... 76
BIBLIOGRAPHIE................................................................................................................................................................................76

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

Remerciements
Je tiens remercier particulirement :

Alain Berdugo
Robert Mahl
tout d'abord pour leur prcieux soutien, constant, et cordial tout au long de l'anne, mais
aussi, pour avoir eu un jour, l'extraordinaire ide de crer le Mastre MSIT.

Andr Probst
de m'avoir confi un sujet aussi passionnant, et d'tre tout moment disponible.

Catherine Ritz
Guy Audoli
d'tre toujours de bonne humeur, et d'excellents managers, tout simplement.

Josselin Requillard
Catherine Yvonnou
Mounir Khaldi
pour leur soutien, leur chaleureuse prsence au quotidien, et leur inpuisable potentiel de
sympathie.

Franois Malliaros
Arnaud Ventre
Anne Rias
Franois-Xavier Bouquet
pour leur bonne volont et leur indispensable collaboration plus qu'encourageante cette
thse.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

Introduction
Lorsque l'on parle d'"Estimation des charges" de projets informatiques une Matrise d'uvre
ou une Matrise d'ouvrage, chacun dj plus ou moins une ide sur la question une
mthode lui qu'il utilise, ou une vieille formule gribouille sur une feuille (dont, d'ailleurs,
on ne sait plus trs bien d'o elle vient), mais qui a fait ses preuves, et que l'on continue
utiliser ou alors, la bonne vieille mthode du "nez" du chef de projet, que l'on retrouve tout
aussi frquemment lors de l'estimation de charges de certains projets.
Evidemment, une entreprise qui a dj fait un certain nombre de projets informatiques,
connat plus ou moins les charges et les dlais dont elle aura besoin pour faire un projet, dont
la plateforme technique et les rgles fonctionnelles lui sont familires. Ces "mthodes", d'une
efficacit relative, n'en restent pas moins intuitives, et par l, perdent une certaine crdibilit
lors d'une justification officielle de l'estimation.
Il existe pourtant des mthodes reconnues et efficientes d'estimation de charges de projet
informatiques. Ces mthodes ont eu le temps de faire leur preuve dans divers domaines. La
plupart d'entre elles se basent sur l'exprience d'un certain nombre de projets-types analyss.
Jusqu' prsent, ces mthodes taient relativement fiables, vis--vis des projets informatiques
"classiques",qui pouvaient se faire jusqu'au milieu des annes 1990 en l'occurrence, les
applications monopostes, ou en client-serveur.
Mais depuis moins d'une dizaine d'annes, et avec l'volution exponentielle des techno logies
et l'apparition des xNet, les rgles du jeu ont chang, une fois encore. Toutes les entreprises
ont aujourd'hui leur internet, tous les grands comptes leur intranet, et la majorit de
commerces leur extranet.
La mesure des cha rges de ces xNet est une "science" bien trop rcente pour pouvoir en parler
avec certitude, et sans risquer de se tromper. Mais cette mesure devient aujourd'hui plus
qu'indispensable, et l'utilisation d'une mthode sre, et reconnue dans le cadre des xNet,
pourrait aider poser des bases concrtes de comparaison, pour les MOE, les MOA, et,
pourquoi pas, les SSII.
Nous allons donc nous plonger dans l'univers des xNet, tout d'abord, puis dans celui de
l'valuation des charges, ensuite. Et grce un exemple concret, nous verrons s'il est possible
de les faire cohabiter, et avec quelle fiabilit.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

I. L'Evaluation de Charges dun projet Informatique


I.1. Pourquoi valuer les charges ?
Dans le cadre des projets de la nouvelle conomie, le concept de lxNet est devenu quasiincontournable : toutes les grandes entreprises possdent aujourdhui un intranet, et la
conception (et le dveloppement) de modules sy greffant est le lot quotidien des responsables
informatiques de ces entreprises.
Une fois le "projet" dfini par les responsables du mtier, ces modules devront tre raliss
(en passant par des tapes successives, telles que les spcifications fonctionnelles globales, les
spcifications fonctionnelles dtailles, le cahier des charges, la conception de la base de
donnes, la ralisation, la recette, etc.).
Il est bien entendu que ces tapes prennent du temps, aussi bien du ct de la MOE que celui
de la MOA, et mme de lexploitation et parfois beaucoup plus (ou beaucoup moins) que
les mtiers et la matrise douvrage ne pourraient lestimer.
Pour pourvoir accorder un budget, il est ncessaire davoir une vision, mme globale, des
diffrents cots engendrs, et du temps ncessaire la ralisation.
Ainsi, ces mthodes dvaluation des charges aident les responsables mtiers apprcier non
seulement la charge, mais aussi la quantit de temps ncessaire la ralisation, la taille de
lquipe, etc.
I.2. Le concept de "Jour*Homme"
Le "Jour*Homme 1 " est lunit de mesure de la charge de travail dans le contexte dun projet 2 .
Concrtement, si un projet est estim "cent jours pour une personne plein temps" pour
arriver son terme, on pourra considrer quil sagit dun projet estim "100 jours
hommes" comme lindique lintitul du rsultat de lvaluation, si lon confie la ralisation
de ce projet un unique homme, ce dernier devrait sauf erreur destimation, et sauf
vnements extrieurs perturbant la ralisation du projet passer exactement cent jours le
raliser.
Cependant, nous pouvons nous permettre de supposer que tout projet, un certain niveau, est
"scindable" : cest--dire que lon va pouvoir le dcomposer (dans la mesure o ce projet est

La syntaxe Jour/Homme est admise, mais errone sur la forme: Il ne sagit pas, comme pourrait le laisser
penser cette criture, dun nombre dhomme par jour. La syntaxe Jour*Homme est beaucoup plus prs de la
ralit, puisquen effet, le nombre obtenu rsulte bien thoriquement- de la multiplication dun nombre de jours
par un nombre dhomme. Jour/Homme, Jour*Homme, et Jour-Homme, sont la plupart du temps utiliss
indiffremment en Entreprise et dans de nombreux ouvrages. Pour rester cohrents, nous utiliserons la syntaxe
qui semble la plus adapte, donc "Jour*Homme".
2

Il est galement possible dutiliser des concepts alternatifs de mesure, tel que le "Mois -Homme" (appel
galement l "Homme-Mois"), que lon pourra considrer quivalent, de faon linaire, 21 Jours*Homme.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

de taille intuitivement suffisamment leve) en un ensemble de tches. Et ceci est aussi vrai
dans les projets informatiques "classiques", que dans les projets de la nouvelle conomie.
Si ce projet est partitionnable (et ce sera quasiment toujours le cas), il est raisonnablement
possible deffectuer plusieurs de ces tches en parallle donc de les faire effectuer par
plusieurs hommes simultanment.
Partant de ce postulat, et dans un cadre idal (figure I.2.1), on peut donc considrer quun
projet de 36 J*H (planifi pour 12 hommes sur 3 jours) pourra tre effectu en 9 jours par 4
hommes.

Jours

Jours

Cette rpartition idale suit une parabole. Nous verrons cependant un peu plus tard que cette
thorie est loin dtre exacte dans le domaine qui nous intresse, cest dire celui des projets
informatiques de la nouvelle conomie.

36
36
Hommes

Hommes
36 JH = 4H * 9J

Jours

Jours

36 JH = 12H * 3J

Hommes
Courbe de 10 JH

Hommes
Cas gnral idal

figure I.2.1 Le principe du "Jour*Homme"

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

I.3. Les piges de lvaluation thorique


I.3.1. La loi de Parkinson sur le temps de travail
Une des lois de C.N.Parkinson3 stipule que "les programmes sont comme les gaz parfaits : Ils
prennent toute la place quon leur donne ". Linterprtation de ce postulat est extrmement
simple : Si lon donne une quipe un projet de 50 Jours*Homme (valeur "relle") faire sur
100 Jours*Homme, le projet sera fait en 100 Jours*Homme, et pas un de moins. (Et donc,
vous limaginez, factur 100 Jours*Homme, bien entendu.)
Cela fonctionne galement dans lautre sens : il est possible de rduire sensiblement la dure
thorique dun projet, et obtenir un rsultat dans le dlai escompt. Ce nest cependant pas
une mthode recommande par la plupart des manuels de gestion de projet, et par les MOE
eux- mmes.
Si lon part de ce principe danalogie avec les gaz parfait, on peut supposer qu peu prs
toutes les estimations de charge possibles (dans la mesure de lintuitivement raisonnable) sont
correctes.
Il sagit cependant bel et bien dun pige dans lequel il est ncessaire dviter de tomber, en
effectuant les estimations de faon, ce que la charge supporte une "pression" raisonnable et
suffisamment confortable pour la matrise duvre et la matrise douvrage.
De plus, la plupart des responsables MOE (tant tout fait conscients de cette loi, et en tenant
compte quotidiennement), avancent largument suivant : il est beaucoup plus indiqu de
laisser un peu plus de temps la MOE quon ne pourrait le juger ncessaire suite une
estimation.
En effet, la plupart des informaticiens (qui, donc, ont tendance effectuer le travail dans le
temps imparti) consacrent le temps supplmentaire accord llaboration dune ergonomie
beaucoup plus pousse, et qui de fait- satisfera davantage lutilisateur final, ou bien dans la
construction dun code plus facilement maintenable, etc.
I.3.2. Le mythe du partage des "Jours*Hommes"
Si nous reprenons lexemple du paragraphe sur le concept de Jours*Hommes, (le projet de
100 J*H), et que nous nous basons sur ses conclusions, nous pourrions effectuer le postulat
que ce projet de 100 J*H pourrait tre effectuer par 200 Hommes en une demi-journe. Bien
que ce soit mathmatiquement exact, cest une aberration vidente : Les projets de
linformatique, en gnral, ne peuvent pas tres scinds de cette manire.
Ce type de raisonnement sapplique par contre, parfaitement, des "projets" trs spcifiques,
comme la peinture en btiment, la rcolte agricole, etc.
A lextrme oppos, il existe galement des projets que ne sont pas partitionnables.

Dans louvrage Parkinson's Law (C.N. Parkinson), Penguin Books. ISBN : 0141186852

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

10

Lexemple revenant le plus souvent est celui il est vrai, assez simpliste, mais trs illustratifde la femme enceinte, qui va mettre neuf mois mettre au monde un enfant Il est, de faon
vidente impossible de partitionner, en plus dune tche. Mme trois femmes dotes de la
meilleure volont du monde ne pourront faire un enfant en trois mois.
Nous nous devons alors de faire des distinctions en plusieurs types de projets (figure I.2.2),
dont lattribution des ressources devra diffrer de faon significative (et ce, en fonction du
nombre de personnes supposes travailler sur ce projet.)

Jours

Jours

Aprs avoir abord les extrmes (figure I.2.2.A : Projet totalement partitionnable, et figure
I.2.2.B : Projet non partitionnable), nous pouvons nous attacher analyser une modlisation
plus raliste. (figures I.2.2.C & D)

Hommes

B) Tche non partitionnable

Jours

Jours

A) Tche partitionnable

Hommes

Hommes
C) Tche partitionnable
ncessitant communication

Hommes
D) Tche avec des
inter-relations complexes

figure I.2.2 Affectation des charges aux tches

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

11

II. Le projet xNet


II.1. Le xNet
II.1.1. La philosophie xNet
Le "xNet" (ou *Net 4 ) est une appellation gnrique du Systme d'Information de front-office
de lentreprise. Il peut dsigner un Internet, un Extranet, ou encore un Intranet, voire une
combinaison de ces modles de rseaux.
La diffrence fondamentale entre ces Interne t, Extranet, et Intranet, est principalement lie
au public (aux "visiteurs") vis par ces rseaux, et par voie de consquence au type daccs de
ces utilisateurs ce que nous appellerons le "moteur de distribution de contenu5 .
La plupart du temps, la technologie utilise dans les xNet est la suivante :
Un serveur HTTP 6 fournissant du contenu HTML, indiffremment statique ou dynamique, et
interactif. A cela s'ajoutent divers services 7 tournant derrire les serveurs HTTP, tels que des
serveurs de donnes, ou de fichiers, et plus gnralement quasiment n'importe quelle
application pouvant potentiellement tre assure en back-office par le systme d'information.
La frontire entre les trois concepts d'Intranet, d'Internet et d'Extranet s'avrant parfois
extrmement tnue, certains professionnels prfrent utiliser le terme d'"Application xNet"
pour dsigner un systme de "site" interactif mlant indiffremment un ou plusieurs des trois
concepts.
On peut, par extension de cette philosophie, considrer le xNet comme une application
rpartie dont le fonctionnement pourrait tre modlis comme suit :
Dun ct, un ou plusieurs "clients lgers" (navigateurs ddis, tels que Microsoft Internet
Explorer, Mozilla, Netscape, Lynx, Opera) sur lesquels saffichent une interface utilisateur,
trs proche du principe des interfaces standard (Windows ou MacOS), et dans lesquels le

*, par analogie avec lastrisque des informaticiens dsignant tout. xNet, ou *Net signifie donc "Tout ce qui
se termine par Net" (Attention : Certaines appellations sont de faon vidente non comprises dans cette
dfinition. I.e.: Ethernet)
5

Ensemble arbitraire des technologies permettant lidentification dun utilisateur, et la navigation et les droits
daccs aux divers documents en fonction de cette identification. (Il dcoule du module didentification et est
intimement li au module de navigation)
6

HyperText Transfer Protocol : Protocole permettant, principalement, de dlivrer des fichiers plus ou moins
standardiss (statiques ou dynamique) sous forme de flux, interprtable par des clients ddis.
7

Ces services peuvent tre trs diversifis : interprteurs ASP ou PHP, liaisons avec diverses bases de donnes,
serveurs dapplications, etc.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

12

client verra safficher des objets graphiques lui permettant deffectuer des oprations. Le
rsultat des oprations effectues saffichera de mme dans cette fentre de "client lger"
De lautre ct, un ou plusieurs "serveurs", qui auront pour tche de rcuprer les ordres
envoys par le client, de les traiter8 (sans restriction de champ daction), et de renvoyer au
"client lger" le rsultat des oprations.

Client

Transport

Client xNet
(Client lger)
gnrique
( Internet Explorer,
Netscape, Mozilla,
Opera, Konqueror )

HTML
HTTP
TCP/IP
WAN
MAN
LAN

Serveur
Serveur xNet
(Apache, IIS
Weblogic,
Websphere)

BDD
(Oracle, MySQL ,
SQLServer)

figure II.1.1 Modle simplifi d'architecture des xNet

II.1.2. Internet
Typiquement, un site dit "Internet" aura pour vocation de toucher toutes les personnes
capables de s'y connecter physiquement (via le rseau du mme nom.)
Il ny a, priori, aucun processus didentification des visiteurs du site, lexception prs
(ventuelle mais rarissime) dun mot de passe gnrique permettant - de faon binaire - un
accs total, ou bien, aucun accs, un site. (ou un rpertoire de ce site)
Ce type de site peut dlivrer de faon indiffrente des pages statiques ou dynamiques.
Il est important de noter que les visiteurs de ce site sont priori inconnus : ce sont des clients
potentiels, ou bien encore des clients actuels, voulant cons ulter un support technique (dans le
cas dune entreprise.) Il peut galement sagir de particuliers consultant des informations,

Notons que certains ordres ne sont pas envoys sur le serveur, mais sont, la plupart du temps, quand la logique
le permet, traits sur le client (cas des scripts de type JavaScript, ou VBScript), pour des raisons de gain de temps
daccs au serveur. Ces programmes sont implments directement lintrieur du code de linterface destin au
client lger.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

13

telles que les informations, la mto, ou bien tout simplement le contenu de pages construites
par des particuliers.
En bref, il sagit bel et bien de lInternet tel quil est dfini de nos jours par le grand public et
les mdia : Linformation en libre accs monsieur tout- le-monde.
Quelques exemples :
http://www.meteo.fr (Site dinformation de Mto France)
http://www.google.fr (Moteur de recherche)
II.1.3. Intranet
Un site "Intranet" est li un accs extrmement restreint : le nombre de visiteurs potentiels
est parfaitement connu, ainsi que l'identit de ces derniers. Ce type de site requiert en gnral
des technologies dynamiques, et apporte des services consquents ses visiteurs, dans le
cadre, par exemple, d'une organisation.
Il nest accessible qu partir dun rseau local (rel ou virtuel9 ), et donc dun nombre de
machines connu, chacune dentre elles tant identifie par son adresse MAC 10 . La plupart du
temps, cet intranet est li un module didentification, permettant aux utilisateurs de se faire
reconnatre par le serveur de faon unique. A cette identification sont trs souvent lis les
profils et les droits de consultation des documents distribus sur cet Intranet.
Il est noter que ce type de site n'est pas, priori, accessible de l'extrieur de lorganisation.
Exemple :
http://intradfepriv-p.dfci.cdc.fr (Intranet de la Caisse des Dpts et Consignations nest
accessible qu partir de lun des postes de travail lintrieur de la CDC)
II.1.4. Extranet
Un site "Extranet", plus restreint quun site Internet, sera destin un public possdant un mot
de passe, ou une clef permettant de consulter ses donnes. Le plus souvent, ce type de site est
dynamique, et les visiteurs sont priori connus, ou, en tout cas, rpertoris.
On peut sans arrires penses simplement considrer lExtranet comme un Intranet "ouvert".
Exemples :
http://www.amazon.com (Vente en ligne de produits culturels),
http://www.theplasticsexchange.com (Place de march B2B pour les matires plastiques)
9

Soit en LAN, ou en VLAN. Cest pratiquement toujours le cas.

10

Adresse MAC, ou adresse Ethernet : Il sagit dune adresse physique attribue par le constructeur la carte
rseau dun ordinateur. A priori, on peut considrer que chacune de ces adresses est unique.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

14

II.1.5. Conclusion sur les xNet


Par extension, certains voient lInternet et lIntranet comme tant des cas particuliers de
lExtranet :
- LIntranet serait un Extranet consultable exclusivement dans le cadre dun rseau ferm.
- LInternet serait un Extranet dont on aurait supprim les contraintes didentifications
appliques au moteur de distribution de contenu.

La figure II.5.1 illustre de faon simple les diffrences entre les trois types xNet existants.

Module
dIdentification

Type dAccs
en Rseau

Internet

NON

Ouvert

Intranet

OUI

Ferm

Extranet

OUI

Ouvert

figure II.5.1 Les diffrents types de xNet

Lanalyse de cette figure peut ventuellement amener la question suivante : existe-t-il un cas
de figure ou lon na pas de module didentification, mais que lon a un accs restreint ?
Cette configuration existe, en effet. Il sagit galement dun Intranet (puisque tant en rseau
ferm), o lon pourra considrer quun seul type dutilisateur (un seul profil) existe : celui
dun visiteur lambda, ayant accs toutes les informations de ce xNet.
La distinction qui est faite ici est purement thorique : il est parfaitement possible davoir un
serveur capable dassumer les trois fonctions de xNet sans quil y ait rellement de frontire.
Le cas dAmazon est dailleurs assez illustratif de ce principe : la limite entre linternet et
lextranet dAmazon est imperceptible.
En effet, sur le site internet dAmazon, il est possible, pour un visiteur, de naviguer et de
remplir un panier virtuel sans quil doive sidentifier. Cependant, une couche supplmentaire
didentification est disponible, permettant au visiteur du site de bnficier de services
supplmentaires (conseil dachat, etc.), et daccs son "compte", offrant un rcapitulatif des
objets achets, etc.
Il sagit l typiquement dun cas o la frontire est concrtement imperceptible.
On peut imaginer de mme un site Internet qui offre en plus des informations disponibles
tous les visiteurs, des services distance pour ses clients (Extranet) aprs identification, ou
encore aux diffrents collaborateurs de lentreprise

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

15

II.2. Caractristiques intrinsques dun xNet


II.2.1. Module de Navigation
Grce au modle HTML et aux liens hypertextes (invents par Thodore Nelson en 1965), on
peut de faon extrmement simple modliser nimporte quel xNet sous forme dun ensemble
de "pages" lies entre elles par ces liens.
Trois modles globaux (et totalement arbitraires) dagencement de "pages" coexistent dans le
monde des xNet.

Modle Linaire

Modle en Arbre

Modle Alternatif

figure II.2.1 Exemples d'architecture de xNet

Le module de navigation (intimement li au module didentification) permet au xNaute 11 de


naviguer lintrieur.
Ce module de navigation peut tre situ nimporte o sur la page, se rpte le plus souvent sur
toutes les pages, et peut dfinir un ou plusieurs niveaux de larborescence. (si lon est dans le
cas dun site en arbre, ce qui est le cas la plupart du temps)

figure II.2.2 Le module de Navigation d'Amazon

La figure II.2.2 montre le module de navigation du site Amazon.com. Il s'agit ici d'un site de
type "Internet" : Il n'y a pas de droits et de restrictions particulires en fonction du profil. On
peut cependant le considrer galement comme un Extranet, puisque les informations et le
contenu de la page changent sensiblement en fonction de l'utilisateur.
11

Nologisme dsignant un intranaute, un internaute, ou un extranaute. (Plus concrtement, utilisateur dun


xNet)

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

16

II.2.2. Module dIdentification


Suivant le type de xNet visit, et suivant le contexte dans lequel on se place, tous les
utilisateurs nauront pas accs de la mme faon au site (ces "droits daccs" ayant une
rpercussion directe sur le module de navigation)
Pour simplifier : certaines pages pourront tre visibles par certaines personnes, tandis que
dautres ne pourront pas y accder.
Ceci tant parfaitement comprhensible si lon considre que derrire chaque page visite, il y
a une information (pouvant tre caractre priv), ou un traitement (pouvant tre caractre
sensible) qui peut tre uniquement ddi un groupe dutilisateurs, voire un seul utilisateur.
Un exemple trs parlant pour le cas dune authentification12 au niveau de lutilisateur est celui
du site Web dune banque (donc, dun Extranet) o chaque client accs ses comptes et
peut y effectuer des oprations. Il est bien entendu - totalement impensable quune personne
ait accs tous les comptes, ou aux comptes dautrui ; do la ncessite du module
didentification au moment de laccs aux pages "sensibles".
Un autre exemple, cette fois-ci en Intranet, de lutilit didentification dun groupe de
personnes. Dans le cadre de lapplication RPI de la Caisse des Dpts et Consignations (que
nous verrons dtaille plus loin), plusieurs groupes dutilisateurs ont accs aux diffrentes
pages du site.
En loccurrence, lapplication RPI permet deffectuer un reporting des projets informatiques
au sein de la DSI de la CDC. Cette application est disponible sur lintranet de la CDC et
accessible la fois la DSI, mais galement aux MOE, au MOA, et la production. Ces trois
derniers groupes peuvent remplir les informations relatives leurs rles respectifs, et toutes
ces donnes peuvent tre consultes et modifies par la DSI exclusivement.
Dans le cas gnral, une fois les spcifications fonctionnelles gnrales acheves, on dfinit
les divers groupes dutilisateurs, et on leur assigne ou non le droit daccder aux
fonctionnalits de lIntranet.
Ceci passe par deux tapes :
Premire tape (figure II.2.3), on liste toutes les pages qui requirent une potentielle
identification. En fonction de ces pages, on cre une matrice qui liste autant de profils que
ncessaire, auxquels on aura associ ou non un droit daccs chacune des pages.
La figure II.2.4 illustre une matrice dauthentification pour un site dune arborescence trois
niveaux. On applique cette arborescence un ensemble daffectation de droits, (en fonction
du cahier des charges fonctionnel) do dcoule une liste de huit profils.

12

Driv du mot anglais signifiant "identification". Les deux mots peuvent tre utiliss indiffremment.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

17

Profil 1
Profil 2
Profil 3
Profil 4
Profil 5
Profil 6
Profil 7
Profil 8
figure II.2.3 Droits des profils sur les pages

La seconde tape consiste affecter les profils ainsi dfinis chacun des utilisateurs
potentiels de lintranet. Cette affectation passe galement par une matrice (figure II.2.4).

Profil 8

Profil 7

Profil 6

Profil 5

Profil 4

Profil 3

Profil 2

Profil 1
Utilisateur 1
Utilisateur 2
Utilisateur 3
Utilisateur 4
Utilisateur 5

figure II.2.4 Affectation de profils aux utilisateurs

Par la suite, lorsqu'un utilisateur viendra s'identifier sur le site, son "profil utilisateur" sera
dduit, et le menu de navigation propre son profil sera ainsi calcul, puis affich l'cran,
pour lui permettre de naviguer sur le site. A priori, aucune autre page que celles qui lui sont
propose ne sera disponible, puisqu'elles auront t protges en prvention de ce cas.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

18

La figure II.2.5 montre la premire page du site "The Plastics Exchange" (Place de March
B2B d'change de matires plastiques, rserve aux professionnels, sur le web.)
Il s'agit ici typiquement d'un extranet : La premire page est une page de prsentation de
l'entreprise, destine au grand public, ou aux clients potentiels. On y trouve une zone
d'identification, qui va permettre au visiteur de s'identifier vis--vis du site.
Une fois cette identification faite, le systme connaissant l'utilisateur et son profil, il va
pouvoir lui proposer l'accs un ensemble de pages auxquelles il a un droit d'accs.

Zone didentification
john
********

Welcome John !

Le module de navigation
nest plus le mme aprs
lidentification.

figure II.2.5 Identification et navigation sur un Extranet

II.2.3. Contenu dun xNet : Interface, Donnes, et les Traitements


Il faut garder en tte qu'un xNet n'est pas un simple "site web". Un xNet est une application
part entire : en plus de l'interface utilisateur, chaque xNet possde son traitement et ses
donnes.
La partie "visible" du xNet, l'interface, est en fait un contenu dynamique affich sur un
client ce contenu est le rsultat d'une suite d'oprations effectus sur un ou plusieurs
serveurs distant, grce des donnes situes elles aussi, sur un ou plusieurs serveurs distants.
La seule diffrence significative par rapport au Client-Serveur, est que l'interface client est
normalise, et que les transactions liant l'interface aux traitements le sont aussi.
Il est donc tout fait lgitime, dans une certaine mesure, de considrer le xNet comme une
application Client-Serveur, et en terme de charges- de l'valuer de faon similaire.
Les diffrentes mthodes que nous allons analyser ne prendront pas en compte le contenu
textuel statique du site, qui devra faire l'objet d'une spcificatio n part, du ct de
l'utilisateur.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

19

III. Etat de lart des mthodes dvaluations


III.1. Mthode des points de Fonctions
III.1.1. Philosophie des Points de Fonction
La mthode des Points de Fonctions est une mthode destine valuer la taille dun projet, et
ce, indpendamment de la technologie utilise pour le raliser.
Son avantage rside principalement dans le fait quil est possible deffectuer une valuation
grce cette mthode trs en amont dans le projet en mme temps que les spcifications
fonctionnelles.
On s'affranchit, de plus, du comptage de lignes de code comme pour la mthode COCOMO,
qui devient d'une fiabilit tout fait relative en fonction du langage utilis Ceci tant
d'autant plus vrai dans le domaine des xNet ou une grosse partie des lignes de "code" dfinit
l'interface.
III.1.2. Paramtres de Points de Fonction
Les points de fonctions reposaient, lorigine, sur un calcul bas sur quatre entits (entre,
sortie, interrogation, fichiers), et ce, sans catgorisation de complexit. (Albrecht, 1979)
Depuis le milieu des annes 80, avec l'IFPUG13 , et la normalisation AFNOR, le comptage des
points de fonctions se fait partir des entits suivantes :

Donnes internes (GDI)


Relatif l'aspect statique du Systme d'Information.
Groupe de donnes logiquement lies, ou de groupe de paramtres de contrle, et
identifiables par l'utilisateur. Ces donnes sont mises jour et utiliss l'intrieur de
la frontire de l'application.
Notons que certaines entits relies par une cardinalit (1,1) sont susceptibles de
former un seul et mme GDI.

Donnes externes (GDE)


Relatif l'aspect statique du Systme d'Information.
Groupe de donnes logiquement lies, ou groupe de paramtre de contrle, et
identifiables par l'utilisateur. Ces donnes sont utiliss par l'application, mais mises
jour par une autre application. Le GDE est un GDI dans un autre domaine.

13

IFPUG: International Function Points User Group, association fdrant plusieurs grandes entreprises, ayant
pour but d'actualiser le guide de comptage par les points de fonctions.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

20

Entres (ENT)
Relatif l'aspect dynamique du Systme d'Information.
Ce sont les donnes, ou les paramtres de contrle, qui entrent dans l'application
considre. Ces entres maintiennent un ou plusieurs GDI, initialisent ou contrlent
un traitement, et font l'objet d'un traitement unique. Une Entre correspond donc un
cran de saisie, ou une rception de donnes. Il est noter qu' chaque GDI doit
correspondre au moins une entre, permettant sa mise jour.

Sorties (SOR)
Relatif l'aspect dynamique du Systme d'Information.
Ce sont les donnes, ou les paramtres de contrle qui sortent de l'application. Ces
sorties sont le rsultat d'un traitement unique. (Ce traitement unique doit tre
diffrent d'une simple extraction de donnes). Ce peut tre un cran de visualisation,
ou un message vers une autre application.

Interrogations (INT)
Relatif l'aspect dynamique du Systme d'Information.
Ce sont des donnes lmentaires qui correspondent une extraction de donnes.
L'INT ne met jour aucun GDI.

Ces entits peuvent tre dfinis sur trois acteurs (figure III.1.1) :
L'application
L'utilisateur
Les autres Applications

Interrogations

Sorties

Entres

Utilisateurs

GDI

Interrogations

Sorties

Entres

Application

Autres application

GDE

figure III.1.1 Principe des Points de Fonctions

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

21

On associe ces cinq entits deux paramtres supplmentaires, qui vont permettre de
dterminer par la suite le niveau de complexit de chaque lment.
Ces paramtres sont les suivants :

Donnes Elmentaires (DE)


Chaque GDI ou GDE est compos de donnes lmentaires. Une DE quivaut un
champ de donnes. On compte un seul DE par champ rptitif dans les entres, les
sorties, et les interrogations.

Sous-ensemble logique de donnes (SLD)


Relatif aux GDE et aux GDI.
D'un point de vue fonctionnel, ce sont les groupements logiques de GDI ou de GDE
qui sont traites simultanment dans l'application.

Groupe de donnes rfrences (GDR)


Relatif aux ENT, SOR ou INT.
D'un point de vue fonctionnel, ce sont les groupements logiques de GDI ou de GDE
qui sont mis jour, ou consults simultanment par les diffrentes ENT, SOR ou
INT.

III.1.3. Calcul des Points de Fonction Bruts


Une fois toutes les entits isols (ENT, SOR, INT, GDI, GDE) et leurs paramtres respectifs
calculs (DE, SLD ou GDR), on pourra donc, pour chacun des composants, dterminer son
niveau de complexit (figure III.1.2).
Points de Fonctions
Complexit des Composants
GDI
GDE

ENT

SOR
INT

1 SLD
2 5 SLD
= 6 SLD
0 ou 1 GDR
2 GDR
= 3 GDR
0 ou 1 GDR
2 3 GDR
= 4 GDR

1 19 DE 20 50 DE
Faible
Faible
Faible
Moyen
Moyen
lev
1 4 DE 5 15 DE
Faible
Faible
Faible
Moyen
Moyen
lev
1 5 DE 6 19 DE
Faible
Faible
Faible
Moyen
Moyen
lev

= 51 DE
Moyen
lev
lev
= 16 DE
Moyen
lev
lev
= 20 DE
Moyen
lev
lev

figure III.1.2 Complexit des Composants

Une fois le niveau de complexit de chaque composant dterminer, il suffit de sommer le


nombre de chacun des composant, pondr par une valeur dtermine en fonction de sa
complexit.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

22

Points de Fonctions
Grille de Complexit
k (i,j) Faible
GDI
GDE
ENT
SOR
INT

7
5
3
4
3

Moyen
10
7
4
5
4

lev
15
10
6
7
6

figure III.1.3 Affectation de PdF aux complexits

" PFB = S (Ci,j * ki,j) "14

- Ci,j correspond au nombre de composants calculs.


- ki,j correspond au coefficient attribuer chacun des composants suivant son type et sa
complexit. (figure III.1.3)
- PFB correspond au nombre de Points de Fonctions bruts calculs pour l'application.
On peut, pour le calcul, utiliser galement le directement le tableau de la figure III.1.4.
Points de Fonctions
Valeur des Composants
GDI

1 SLD
2 5 SLD
= 6 SLD

GDE

1 SLD
2 5 SLD
= 6 SLD

ENT

0 ou 1 GDR
2 GDR
= 3 GDR

SOR

INT

0 ou 1 GDR
2 3 GDR
= 4 GDR
0 ou 1 GDR
2 3 GDR
= 4 GDR

1 19 DE
7 PdF
7 PdF
10 PdF
1 19 DE
5 PdF
5 PdF
7 PdF
1 4 DE
3 PdF
3 PdF
4 PdF
1 5 DE
4 PdF
4 PdF
5 PdF
1 5 DE
3 PdF
3 PdF
4 PdF

20 50 DE
7 PdF
10 PdF
15 PdF
20 50 DE
5 PdF
7 PdF
10 PdF
5 15 DE
3 PdF
4 PdF
6 PdF
6 19 DE
4 PdF
5 PdF
7 PdF
6 19 DE
3 PdF
4 PdF
6 PdF

= 51 DE
10 PdF
15 PdF
15 PdF
= 51 DE
7 PdF
10 PdF
10 PdF
= 16 DE
4 PdF
6 PdF
6 PdF
= 20 DE
5 PdF
7 PdF
7 PdF
= 20 DE
4 PdF
6 PdF
6 PdF

figure III.1.4 Affectation de PdF aux composants

14

i dcrit l'ensemble {GDI, GDE, ENT, SOR, INT}, j dcrit l'ensemble {Faible, Moyen, Elev}

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

23

III.1.4. Calcul des Points de Fonction Ajusts


L'tape suivante (facultative) consiste ajuster ces points de fonctions. Le principe est le
suivant : on corrige le PDF grce un ensemble de 14 DI (degrs d'influence).
Chaque DI aura une valeur entre 0 et 5 en fonction de l'importance du degr d'influence sur
l'application.
Les degrs d'influence sont les suivants :
Degr d'influence de la communication des donnes
Degr d'influence de la distribution des donnes ou des traitements
Degr d'influence de la performance
Degr d'influence de l'intensit d'utilisation de la configuration matrielle
Degr d'influence du taux de transition
Degr d'influence du taux de transaction
Degr d'influence de la saisie interactive
Degr d'influence de la convivialit
Degr d'influence de la mise jour en temps rel des GDI
Degr d'influence de la complexit des traitements
Degr d'influence de la rutilisation
Degr d'influence de la facilit d'installation
Degr d'influence de la facilit d'exploitation
Degr d'influence de la portabilit
Degr d'influence de la facilit d'adaptation
On calcule ainsi le facteur d'ajustement, en fonction des degrs influence :

" FA = 0.65 + SDIi / 100 "


Puis on en dduit le nombre ajust de points de fonctions :

" PFA = PFB * FA "


On en dduit que le Facteur d'Ajustement va nous permettre de corriger le nombre de points
de fonctions bruts avec un taux allant de 65% 135% (allant donc du simple au double.)

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

24

III.1.5. Calcul de la Charge avec les Points de Fonction


Le calcul de la charge (le point qui nous intresse en particulier) est une fonction linaire de
PFB. (ou de PFA si on l'a calcul)
Cette valuation se fait grce un facteur multiplicatif.
Ce facteur multiplicatif est d'environ 3 Jours*Homme par Point de Fonction en moyenne (2
J*H si le projet est petit, 4 s'il s'agit d'un grand projet)
A la fin de l'tude dtaille, ce facteur peut varier de 0,1 (pour les projets en L4G, dans le
meilleur des cas) jusqu' 2 pour les projets plus complexes, en passant par un facteur 0,5 pour
les projets de type RAD, o la productivit est plus leve.
III.1.6. Conclusion sur les Points de Fonction
Projet, Spcifications

Ecrans

Points de Fonctions

Lignes de Code
Tables/Donnes

Pondration

Traitements
Fonctions
Complexit
Archit./Matriel
Equipes
Mthodes Trans.

Charge
MOE

Charge
MOA

Dlai

Taille de
lquipe
Rsultats

figure III.1.5 Vue d'ensemble de la mthode

Inconvnients :
Le comptage est assez subjectif.
Le comptage est trs difficile automatiser.
Mme si l'estimation de l'effort est juste, l'estimation de la charge (tant sujette une
multiplication par une valeur subjective) est d'une exactitude toute relative.
Avantages :
L'estimation est disponible assez tt dans le projet. (Seules des spcifications dtailles
sont ncessaires)
L'estimation est indpendante du langage, de la plateforme, et des diverses technologies
utilises.
On peut, avec l' exprience et les statistiques, adapter facilement le modle l'estimation
des xNet.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

25

III.2. Mthode COCOMO


III.2.1. Philosophie de COCOMO
"Pour estimer la charge dun projet, il faut en estimer la taille"
Ainsi pourrait tre rsume la philosophie de la mthode COCOMO15 .
En effet, la principale hypothse de cette mthode est quun informaticien saura mieux
valuer la "taille" dun projet informatique que l'"effort" fournir pour le dvelopper.
COCOMO a t dfini par B.W.Boehm16 sous la forme d'quations simples, admettant quatre
paramtres.
Ces divers paramtres (qui sont, en fait, des coefficients) ont t trouvs de faon
exprimentale, Boehm se basant sur lestimation et la ralisation de plus dune soixantaine de
projets divers dinformatique classique. (chaque projet ayant une taille situe entre 2000 et
100.000 lignes de code)
La probabilit dobtenir un rsultat proche de la ralit grce COCOMO dpend du fait que
le projet que lon analyse soit proche ou non du panel de projets analyss par Boehm.
III.2.2. La "Ligne de Code"
Le premier et le plus important de ces quatre paramtres est la "ligne de code". Le nombre
de milliers de ligne de code reprsente la "taille" du projet. Cest principalement en fonction
de cette "taille" que lon estimera le temps ncessaire la ralisation du projet.
On considre la dfinition de la ligne de code donne par N.E.Fenton (Software Metrics: A
Rigorous and Practical Data, 1998) :
"Une ligne de code est toute ligne du texte dun programme qui nest pas une ligne de
commentaire, ou une ligne blanche, sans considration du nombre dinstructions ou de
fragments dinstructions dans la ligne. Sont incluses toutes les lignes contenant des en-ttes
de programmes, des dclarations, et des instructions excutables et non excutables."
Cependant, dans le contexte des xNet, contrairement aux langages modernes, orients GUI 17 ,
on est en droit de se demander si le concept de "nombre de lignes de code" reste fiable, en
raison de la ncessit d'utilisation d'un grand nombre d'entre elles pour dfinir uniquement
l'interface de l'application xNet. (C'est typiquement le cas du HTML).

15

COCOMO : Constructive Cost Model (Modle Constructif De Cot)

16

Dans louvrage Software Engineering Economics (Barry W. Boehm, 1981). ISBN : 0138221227

17

GUI : Graphical User Interface. Il d'agit l de langages de type "Visual", o les lignes de code ne servent pas,
ou peu la dfinition de l'interface.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

26

La taille d'un projet est estime en milliers de lignes de code. On parle gnralement de KDSI
(Kilo Delivered Source Instruction), ou de KLOC. (Kilo Lines Of Code)
Il est possible, thoriquement, d'valuer la taille (le nombre de KDSI) en fonction du nombre
de points de fonctions du projet, grce la formule suivante :

" T = 0.1187 * PFA 6.49 "


Une autre mthode 18 d'estimation de T peut tre dtermine grce aux facteurs suivants, en
fonction du langage utilis :

Assembleur
C
COBOL
Pascal
Prolog
Basic
SQL
Smalltalk

: 0,32 KDSI par Point de Fonction


: 0,15 KDSI par Point de Fonction
: 0,106 KDSI par Point de Fonction
: 0,091 KDSI par Point de Fonction
: 0,064 KDSI par Point de Fonction
: 0,064 KDSI par Point de Fonction
: 0,040 KDSI par Point de Fonction
: 0,021 KDSI par Point de Fonction

III.2.3. Equations COCOMO destimation dEffort


Equation pour les projets "simples" : (Projets ncessitant une quipe de trois personnes, ou
moins)

" E = 21 * A * T + B "
Equation pour les projets "complexes" : (Projets ncessitant une quipe de plus de trois
personnes)

" E = 21 * A * TB * M "19
Le modle COCOMO admet les paramtres suivants :
- E : effort. (mesur en Jours*Hommes) Il sagit du rsultat de lquation

18

Dans louvrage Function Point Analysis (B.J. Dreger, 1989). ISBN : 0133323218

19

Le facteur 21 du dbut de lquation est d au fait que lquation de Boehm est, lorigine, destine valuer
le projet en Mois*Homme.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

27

- A, B : Coefficients de "Type de logiciel".


- T : Taille, exprime en KDSI (Kilo Delivered Source Instruction, Nombre de milliers de
lignes de code source du projet)
- M : Facteur dajustement de leffort
III.2.4. Equation COCOMO destimation de Dure
Il est possible destimer la dure dun projet en fonction de leffort fournir.

" DUREE = 21 * C * (E/21)D "20


Les paramtres sont les suivants :
- E : effort. (mesur en Jours*Hommes)
- C, D : Coefficients de "Type de logiciel"
- DUREE : Dure prvue du projet. Il sagit du rsultat de lquation
On peut, par la suite, calculer le nombre de personnes ncessaires la ralisation de ce projet :

" S = E / DUREE "


Le paramtre est les suivant :
- S: Staffing. (Effectifs) Il sagit du rsultat de lquation

NB : Les coefficients A, B, C et D diffrent, non seulement, selon le type de projet, mais


galement selon le type destimation utilis.
Il existe trois types destimation :
COCOMO Basique
COCOMO Intermdiaire
COCOMO Dtaill
Une fois le type de projet dcel, il suffira dapplique les prcdentes quations. Nous verrons
en dtails tous les paramtres pour les deux premiers types destimation.

20

Il est ncessaire dans cette quation de diviser l'Effort par 21, puisque l'unit d'origine de E dans le modle
COCOMO est le Mois*Homme.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

28

III.2.5. Types de projets


La premire chose faire lorsque lon dcide dutiliser COCOMO pour valuer le projet, est
donc de dterminer quel "type" de projet lon a affaire.
Boehm propose trois types de projet:
Projet Organique : Projet simple, ou de routine, effectu par une quipe ayant dj travaill
ensemble, dans lequel il y a peu de "surprises" et o une bonne anticipation est possible.
Projet Semi-Dtach : Entre organique et imbriqu. Le Projet nest ni trop simple, ni trop
complexe, lquipe de dveloppement se connat un peu, et les technologies peuvent tre mal
connues, mais pas dune grande difficult dapprhension.
Projet Imbriqu : Techniques innovante, organisation complexe, beaucoup d'interactions.
Projet difficile, ou dans un domaine inconnu par lentreprise, quipe de dveloppement
nayant pas encore travaill ensemble, ou projet impliquant des technologies encore peu
connues des dveloppeurs.

III.2.6. COCOMO Basique


Le modle de base de COCOMO est relativement simple. Il permet d'estimer non seulement
l'effort (le nombre de Jours*Homme ncessaires la ralisation d'un projet) en fonction de la
Taille (nombre de lignes de code), mais aussi la dure ncessaire, par consquent le nombre
de personnes ncessaires sa ralisation.

Organique
Semi-Dtach

2.4

1.05

2.5

0.38

3.0

1.12

2.5

0.35

Imbriqu

3.6

1.20

2.5

0.32

COCOMO Basique

figure III.2.1 Coefficients COCOMO Basique

Les coefficients du COCOMO Basique (figure III.2.1) suffisent pour avoir une estimation
rapide des projets Simples (figure III.2.2) et des projets complexes (figure III.2.3).
NB : Notons que pour le modle COCOMO Basique, le facteur dajustement M = 1.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

29

COCOMO Basique

Projet Organique

Projets Simples

Projet Semi-Dtach

Projet Imbriqu

figure III.2.2 COCOMO Basique, Projets Simples


COCOMO Basique

Projet Organique

Projets Complexes

Projet Semi-Dtach

Projet Imbriqu

figure III.2.3 COCOMO Basique, Projets Complexes

Il est mme possible de comparer l'estimation pour ces deux types de projet (figure III.2.4).
On constate cependant une rapide divergence pour les projets qui ne sont pas de type
"organique". Il n'est donc pas recommand d'utiliser l'quation "projets simples" du modle
Basique.
COCOMO Basique

Comparaison Simple & Complexe

Simple
Complexe

Projet Organique

Projet Semi-Dtach

Projet Imbriqu

figure III.2.4 Divergence des Projets Simples et Complexes

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

30

III.2.7. COCOMO Intermdiaire


Le Modle Intermdiaire de COCOMO est relativement similaire au modle Basique, la
diffrence prs d'un changement des coefficients a et b (figure III.2.5), et de la prsence d'un
"Facteur d'Ajustement" appel M, dpendant d'une quinzaine de diffrents paramtres.
La figure III.2.6 reprsente les courbes de COCOMO intermdiaire avec un facteur
d'ajustement gal 1.

Organique

3.2

1.05

2.5

0.38

Semi-Dtach
Imbriqu

3.0

1.12

2.5

0.35

2.8

1.20

2.5

0.32

COCOMO Intermdiaire

figure III.2.5 Coefficients COCOMO Intermdiaire

Le facteur dajustement M est gal au produit des 15 facteurs consigns dans le tableau de la
figure III.2.7.
COCOMO Interm .

Projet Organique

EFFORTS - Projets Complexes (avec M = 1)

Projet Semi-Dtach

Projet Imbriqu

figure III.2.6 COCOMO Intermdiaire, projets complexes

Les quinze facteurs doivent tre classs suivant une chelle six degrs, allant de "Trs Bas"
"Extrmement haut"

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

31

COCOMO Intermdiaire
Facteurs d'Ajustement

Trs
Bas

Bas

Normal

Haut

Trs
Haut

Extr.
Haut

0,88
0,94
0,85

1,00
1,00
1,00

1,15
1,08
1,15

1,40
1,16
1,30

1,65

0,87
0,87

1,00
1,00
1,00
1,00

1,11
1,06
1,15
1,07

1,30
1,21
1,30
1,15

1,19
1,13
1,17
1,10
1,07

1,00
1,00
1,00
1,00
1,00

0,86
0,91
0,86
0,90
0,95

0,71
0,82
0,70

VEXP
LEXP

1,46
1,29
1,42
1,21
1,14

MODP
TOOL
SCED

1,24
1,24
1,23

1,10
1,10
1,08

1,00
1,00
1,00

0,91
0,91
1,04

0,82
0,83
1,10

Attributs du produit
Fiabilit Requise
Taille de la Base de Donnes
Complexit du produit
Attributs du Matriel
Contraintes de temps d'excution
Contraintes de taille mmoire principale
Instabilit de la Machine Virtuelle
Temps de Retournement
Attributs de l'quipe
Comptence des Analystes
Exprience du domaine d'application
Comptence des Programmeurs
Exprience de la Machine Virtuelle
Exprience du langage
Mthodes et Outils
Pratique des Mthodes Modernes
Utilisation d'outils logiciels
Contraintes de planning

RELY
DATA
CPLX

0,75
0,70

TIME
STOR
VIRT
TURN
ACAP
AEXP
PCAP

1,66
1,56

figure III.2.7 Facteurs d'ajustement COCOMO

Notons que le facteur d'ajustement peut varier de 0.09 72.38 (un rapport de plus de 800 !!!),
sa valeur tant gale 1 pour un projet normal.
Les quinze composants du facteur d'ajustement M sont spars en quatre catgories :
Attributs du produit
Fiabilit Requise (RELY)
Quelles sont les consquences de la dfaillance du logiciel ?
De "trs basse" (Pas de consquences), "trs haute" (Pertes de vies humaines).
Le "Normale" quivaut des pertes rcuprables.

Taille de la Base de Donnes (DATA)


Ratio entre la taille de la base de donnes et la taille du programme (en octets sur
nombre d'instructions). Le "Normale" quivaut un ratio compris entre 10 et 100.

Complexit du produit (CPLX)


En terme de structure de contrle, oprations et calculs, oprations dpendant
d'entres/sorties sur priphriques, gestion de donnes.

Attributs du Matriel
Contraintes de temps d'excution (TIME)
En terme de temps d'excution machine. (en % en fonction du temps disponible)

Contraintes de taille mmoire principale (STOR)

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

32

En terme de temps de taux d'utilisation de la place. (en % en fonction de la place


disponible)

Instabilit de la Machine Virtuelle (VIRT)


(NB: Machine virtuelle, dans l'appellation de Boehm, correspond l'environnement de
programmation.)

Temps de Retour nement (TURN)


Temps qui s'coule entre la soumission d'une donne au systme, et la rcupration du
rsultat. Typiquement dans les xNet, ce temps varie de Bas Normal.

Attributs de l'quipe
Comptence des Analystes (ACAP)

Exprience du domaine d'application (AEXP)


Exprience pouvant varier de "Trs Bas" (moins de 4 mois) "Haut" (Plus de six ans)

Comptence des Programmeurs (PCAP)

Exprience de la Machine Virtuelle (VEXP)


Exprience pouvant varier de "Trs Bas" (moins d'1 mois) "Haut" (Plus de trois ans)

Exprience du langage (LEXP)


Exprience pouvant varier de "Trs Bas" (moins d'1 mois) "Haut" (Plus de trois ans)

Mthodes et Outils
Pratique des Mthodes Modernes (MODP)
Dpend de la mthode utilise, du degr d'utilisation, et de la connaissance et de
l'exprience dans ces mthodes.

Utilisation d'outils logiciels (TOOL)


Dans l'environnement de programmation, utilisation d'outils aidant au
dveloppement/dboguage du logiciel, et contribuant la communication entre les
membres de l'quipe

Contraintes de planning (SCED)


Adquation entre le temps estim par l'quipe de ralisation et le temps estim par
COCOMO. "Trs Bas" correspond 75% du temps, "Trs Haut" 160%.

Il est galement possible grce COCOMO Intermdiaire, de calculer la Dure du projet


(figure III.2.8), et les Effectifs ncessaires sa ralisation (figure III.2.9).

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

33

COCOMO Interm .

Projet Organique

DUREE - Projets Complexes (avec M = 1)

Projet Semi-Dtach

Projet Imbriqu

figure III.2.8 Dure, en fonction de l'effort


COCOMO Interm .

Projet Organique

EFFECTIFS - Projets Complexes (avec M = 1)

Projet Semi-Dtach

Projet Imbriqu

figure III.2.9 Effectifs, en fonction de l'effort

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

34

III.2.8. COCOMO Dtaill


Le dernier niveau de COCOMO (COCOMO Dtaill), fonctionne de la faon suivante : le
projet doit tre dcoup en "phases" distinctes. Chacune des phases doit tre value avec
COCOMO Intermdiaire (Le facteur d'ajustement M est donc diffrent pour chaque phase),
puis les rsultats doivent tre somms la fin.
III.2.9. Conclusions sur COCOMO
Projet, Spcifications

Ecrans

COCOMO

Lignes de Code
Tables/Donnes

Pondration

Traitements
Fonctions
Complexit
Archit./ Matriel
Equipes
Mthodes Trans.

Charge
MOE

Charge
MOA

Dlai

Taille de
lquipe
Rsultats

figure III.2.10 Vue d'ensemble de la mthode

Inconvnients :
"Pour savoir combien de temps il va falloir pour construire ta maison, compte le nombre
de briques dont tu as besoin !"
Il est assez ardu de calculer de faon fiable la "taille" du projet (en KDSI) lorsque lon est
peu avanc dans le projet. Cette difficult saccrot dautant plus avec lEffort quil
conviendrait de fournir.
Il est peu ais de choisir de faon correcte le "Type de projet".
La fiabilit du rsultat obtenu dpend normment du fait que le projet raliser se
rapproche fortement de ceux qui ont servi crer le modle.
Le fait d'utiliser la "ligne de code" en tant qu'unit de calcul amne quelques failles dans le
systme : on ne tient pas compte, par exemple, des commentaires dans le code (Qui, pour
la maintenance ou le dboguage s'avrent primordiaux).
Avantages :
COCOMO est transparent, il est facile dajuster ses paramtres (dautant quil y en a peu
ce qui peut tre aussi bien un avantage, que la mise en valeur dun manque ) et de
recrer son propre modle.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

35

III.3. Evaluateur-RAD (J-P.Vikoff)


III.3.1. Philosophie dEvaluateur-RAD
Evaluateur-RAD est un logiciel de Jean-Pierre Vikoff 21 qui se base, selon l'auteur, sur une
volution des travaux de Albrecht, Ashby, Boehm, Clark, Egyed, Gacek, Hoh, Lehman,
Martin, Maxwell, Pareto, Parkinson, Rayleigh et Shannon autant dire un mlange de al
plupart des mthodes d'valuation et de statistiques du domaines.
Evaluateur-RAD n'est donc pas, proprement parler, une mthode. Cependant, ce logiciel
reste nanmoins trs intressant dans le contexte de cette thse, pour les raisons suivantes :
-

Evaluateur-RAD prend en compte plusieurs paramtres, dont la nature a totalement t


occulte dans les autres mthodes analyses ici.
Il s'agit bel et bien du produit la plus "adapt" aux xNet, les autres mthodes rpondant
aux demandes d'valuation, pour la plupart, du client-serveur, ou bien de l'informatique
classique.

III.3.2. Paramtres
En guise de prsentation, nous allons passer en revue les 12 crans d'Evaluateur-RAD, et
passer en revue les paramtres intervenant dans le calcul de la charge finale.
La mtrique Gnrale
Le premier tableau est le plus significatif : il va servir mesurer d'entre le "contenu" de
l'application, et son "niveau de complexit". Tout comme la mthode des Points de Fonctions,
le rsultat obtenu en fin d'valuation de "contenu" sera altr par des paramtres
d'environnement.

figure III.3.1 Mtrique Gnrale

21

Fourni dans l'ouvrage "Piloter les projets informatiques de la nouvelle conomie (J-P.Vickoff, Editions
d'Organisation), ISBN : 2708124870, mais galement disponible sur http://mapage.noos.fr/rad/eval2000.htm

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

36

figure III.3.2 Application, Organisation

figure III.3.3 AGL Conception

figure III.3.4 Mthode, Qualit, Focus

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

37

figure III.3.5 - Industrialisation

figure III.3.6 Communication, Workflow, BPR

figure III.3.7 Equipe et Support

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

38

figure III.3.8 Ralisation et Outils

figure III.3.9 - Finalisation

figure III.3.10 Elments techniques

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

39

figure III.3.11 Utilisateurs, Matrise d'Ouvrage

figure III.3.12 - Ressources

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

40

III.3.3. Conclusion sur Evaluateur-RAD


Projet, Spcifications

Ecrans

Evaluateur-RAD

Lignes de Code
Tables/Donnes

Pondration

Traitements
Fonctions
Complexit
Archit./Matriel
Equipes
Mthodes Trans.

Charge
MOE

Charge
MOA

Dlai

Taille de
lquipe
Rsultats

figure III.3.13 Vue d'ensemble de la mthode

Pour un projet nominal de 100 Jours*Homme, les paramtres d'environnement peuvent varier
de 8% plus de 35000% de la taille prvue. (O , d'ailleurs, le programme dclare un
dpassement de capacit.)
Plusieurs personnes ayant utilis Evaluateur-RAD estiment que la charge jauge en fin de
remplissage des crans tait lgrement suprieure la ralisation relle.
Nous verrons par la suite si pour l'estimation du projet test (RPI), la valeur finale tait ou non
comparable la ralit.
Avantages :
Un logiciel complet est fourni pour mettre en application la mthode. Son utilisation est
intuitive, et on obtient un rsultat rapidement.
Inconvnients :
La mthode Evaluateur-RAD semble donner des chiffres beaucoup trop levs pour des
petits projets.
Certains coefficients de pondration sont difficilement explicables ou justifiables (ex: taille
de l'cran de l'application, etc...)
La mthode est opaque, et on ne peut pas "rgler" les paramtres et coefficients.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

41

III.4. Mthode Interne CDC (A.Probst)


III.4.1. Philosophie de la mthode Interne CDC
Cette mthode a t mise au point par Andr Probst, Responsable Mthodes de la Direction
des Systmes d'Information de la CDC. La mthode correspond, l'origine, l'valuation de
projets de type Client-Serveur.
Les coefficients de cette mthode sont obtenus grce l'exprience, sur des essais fait sur plus
d'une dizaines de gros projets de la Caisse des Dpts et Consignations. (Il est d'ailleurs
possible, de ce fait, que l'estimation soit mal adapte certains projets de trop petite taille.)
Cette mthode est la mthode la plus complte tudie dans ce document : elle l'avantage
d'valuer la fois, la charge ncessaire en terme de MOE et de MOA, en rentrant dans tous
les dtails de la construction de l'application.
III.4.2. Etape 1 : Dcomposition fonctionnelle
La premire tape consiste dcomposer le projet en macro- fonctions. Chacune de ces
macro- fonctions correspond une fonctionnalit globale de lapplication. Par la suite, il
sagira de dcomposer chaque macro-fonction en un ensemble de micro-fonctions. (dont le
nombre peut tre trs variable suivant les cas)
Nom du Projet
Fonctions recenses en tude pralable

Estimation nbre de fonctions lmentaires


simple

standard complexe

Total

Libell de la premire Fonction


Libell de la deuxime Fonction
Libell de la troisime Fonction
Libell de la quatrime Fonction
Libell de la cinquime Fonction
etc.

5
10
20
16
2

3
28
30
30
4

2
11
10
20
5

10
49
60
66
11

TOTAL

Nbre Fonctions

53

95

48

196

MCD

Nbre d'Objets/Relations

58 Nombre
d'objets/relations
saisir

Effort Brut
Effort Corrig

390
600
figure III.4.1 Dcomposition Fonctionnelle

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

42

Ces micro- fonctions seront pondres par leur niveau de complexit que leur attribue le chef
de projet grce sa propre exprience.
Il faut, par la suite, renseigner "Nombre d'Objets/Relations". Sa valeur correspond, dans le
MCD, la somme du nombre de tables "significatives" du modle de donnes, et du nombre
de relations les liant.
Soient les variables suivantes :
Fsimples : Nombre de fonctions Simples
Fstandard : Nombre de fonctions Standard
Fcomplexes : Nombre de fonctions Complexes
NOR : Nombre dObjets/Relations
EB : Effort Brut
EC : Effort Corrig
On obtient par le calcul les rsultats suivants :

" EB = Fsimples * 3/5 + Fstandard * 3/2 + Fcomplexes * 4 + NOR * 2/5 "


" EC = EB / 0.65 "
L'Effort Brut (EB) correspond une mtrique : il s'agit de l'effort fournir dans le cadre de la
ralisation d'un projet, partir d'une tape avance dans le temps, correspondant
approximativement au milieu de l'tude pralable. (La mthode d'origine permettant de
calculer les charges en fonction de ces informations tait base sur une dure de projet
value partir de cette priode).
L'Effort Corrig est obtenu par la division de l'Effort Brut par 0.65 (la multiplication par 1.54)
pour obtenir l'effort total fournit sur le projet. Cet effort sera ensuite multipli par un
ensemble de coefficients, afin d'obtenir la charge.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

43

III.4.3. Etape 2 : Rpartition des Charges

Nom du Projet
Ne rien saisir sur cette feuille

Maitrise d'uvre
Etapes:
Coeff

Suivi de Projet
Encadrement Projet

0,23

Initialisation
Cadrage
Protocole de Projet
Comit de Pilotage
Runion d'initialisation

Etude Pralable
Analyse et Modlisation
Etude de l'existant
Prise en cpte des contraintes
Etude de Faisabilit
Estimation des charges
Revue Qualit
Comit de Pilotage
*Etude de l' Option Progiciel
*Comit de Pilotage

Construction

138

0,1

1%

0%

2
1
3
2

0,005

8%

60
60
6
60
24
30
6
60
0

90
12
30
48
6

7
0
0

24
204
54
48
36
1

44
0,01
0,02
0,04

4%

3%

1000 100% 62%

29

2%

323

20%

138
30
48
84
12
1
10
0
0

542

33%

120
120
30
78
24
48
9
72
0
24
6
1
10

1%

24

98
0,03
0,1
0,03

12%

8
7
9
5

60
60
24
18
0
18
3
12
0
24
3
0
7

24
0,04

6
12
24
2

1%

229 14%

0,02
0
0,04
0,005

198
198

193 12%

0,03

MOE + MOA
Charge %MOE+MOA
J/H
/tot

6
6
6
3

0,15
0,02
0,05
0,08
0,01

0,1
0,1
0,04
0,03

3
1
3

4%

60

21
0,01
0,01

48
18
18
36
6
1
3
0
0

Charge %MOA
J/H
/tot.

60

367 37% 23%


0,04
0,34
0,09
0,08
0,06

Recette

Charge Totale Projet

8%

Coeff

313 31% 19%

Analyse des Flux


0,1
Analyse des Donnes
0,1
Impacts Organisationnels
0,01
Maquettage
0,1
Architecture Applicative/Technique
0,04
Spcifications Fonctionnelles Dtailles 0,05
Retours revue d'ergonomie
Spcifications Techniques
0,1
* Reprise d'antriorit
0
Organisation pour l'implantation
Estimation des Charges
0,005
Revue Qualit
Comit de Pilotage

Prparation logistique
Tests de Recette
Prparation de l'exploitation
Revue Qualit/ Comit de Pilotage

138 14%

130 13%
0,08
0,03
0,03
0,06
0,01

Conception Dtaille

Prparation des Tests (jeux d'essais)


Codage des composants
Tests unitaires
Tests fonctionnels
Qualification/Intgration.
Revue Qualit

/tot

8
0,004
0,002
0,005
0,003

Maitrise d'Ouvrage

Charge % MOE
J/H
/MOE

391

24%

48
204
54
48
36
1

6%

18
60
18
2

142

9%

24
72
42
4

625 38% 1625

100%

% de chacun
MOE

MOA

70%

30%

70%

30%

28%

72%

25%
14%
33%
40%

75%
86%
67%
60%

40%

60%

35%
60%
38%
43%
50%
100%
30%

65%
40%
63%
57%
50%
0%
70%

58%

42%

50%
50%
20%
77%
100%
63%
67%
83%

50%
50%
80%
23%
0%
38%
33%
17%

0%
50%
100%
30%

100%
50%
0%
70%

94%

6%

50%
100%
100%
100%
100%
100%

50%
0%
0%
0%
0%
0%

31%

69%

25%
17%
57%
50%

75%
83%
43%
50%

62%

38%

figure III.4.2 Rpartition des Charges

Nous aurons par la suite besoin d'une variable de ce tableau :


- SUIVI : % de Charge de MOE assign au "Suivi de projet". (ici: 14%)

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

44

Recette
Construction
Conception Dtaille
MOE
MOA

Etude Pralable
Initialisation
Suivi de Projet
0%

10%

20%

30%

40%

50%

60%

70%

80%

90% 100%

figure III.4.3 Rpartition des charges, EC < 100 JH

Recette
Construction
Conception Dtaille
MOE
MOA

Etude Pralable
Initialisation
Suivi de Projet
0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

figure III.4.4 Rpartition des charges, EC > 100 JH

La rpartition des charges du projet se fait pour la MOE et la MOA en fonction de diverses
pondrations de la charge corrige, suivant des coefficients affects certaines tches du
projet.
Il est important de noter quune barrire de Charge Corrige de 100 jours a t fixe : dans le
cas o cette valeur serait dpasse, les rsultats escompts diffrent.
Les diffrents coefficients sont rsums dans les deux tableaux suivants.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

45

Etape

Coefficient MOE Coefficient MOA

Suivi de Projet
Encadrement Projet
Initialisation

0,23

0,1

Cadrage
Protocole de Projet
Comit de Pilotage
Runion d'initialisation
Etude Pralable

0,004
0,002
0,005
0,003

0,01
0,01
0,005

Analyse et Modlisation
Etude de l'existant
Prise en cpte des contraintes
Etude de Faisabilit
Estimation des charges
Conception Dtaille

0,08
0,03
0,03
0,06
0,01

0,15
0,02
0,05
0,08
0,01

Analyse des Flux


Analyse des Donnes
Impacts Organisationnels
Maquettage
Architecture Applicative/Technique
Spcifications Fonctionnelles Dtailles
Spcifications Techniques
* Reprise d'antriorit
Organisation pour l'implantation
Estimation des Charges
Construction

0,1
0,1
0,01
0,1
0,04
0,05
0,1
0

0,1
0,1
0,04
0,03

Prparation des Tests (jeux d'essais)


Codage des composants
Tests unitaires
Tests fonctionnels
Qualification/Intgration.
Recette
Prparation logistique
Tests de Recette
Prparation de l'exploitation

0,03
0,02
0
0,04
0,005

0,005
0,04
0,34
0,09
0,08
0,06

0,04

0,01
0,02
0,04

0,03
0,1
0,03

figure III.4.5 Coefficients de Rpartition

Charge Corrige < 100 Charge Corrige >= 100


Etape

Charge MOE Charge MOA Charge MOE Charge MOA

Suivi de Projet
Encadrement Projet

EC * 0,115

EC * 0,05

EC * 0,23

EC * 0,1

0
0

0
0

EC * 0,005
EC * 0,003

6
EC * 0,005

0
0
0

EC * 0,01
1
3

EC * 0,01

EC * 0,005
3

EC * 0,005
7

Initialisation
Comit de Pilotage
Runion d'initialisation
Etude Pralable
Estimation des charges
Revue Qualit
Comit de Pilotage

Conception Dtaille
Estimation des Charges
Comit de Pilotage

0
0

Construction
Qualification/Intgration.

EC * 0,03

EC * 0,06

Recette
Revue Qualit/ Comit de Pilotage

figure III.4.6 Coefficients en fonction de l'Effort Corrig

Il faut garder en tte que les tapes et les coefficients calculs ici sont adapts au ClientServeur.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

46

Pour pouvoir tre en adquation avec les xNet, A.Probst propose d'ventuellement diminuer la
charge du projet de 20% par rapport sa valeur d'origine (pour avoir un rsultat rapide), ou
mieux, ajouter des tapes, et modifier les diffrents coefficients des deux figures prcdentes.
Nous verrons par la suite quel type d'tapes nous pourrons modifier pour arriver un rsultat
proche de celui escompt.
III.4.4. Etape 3 : Pondrations des charges
Parmi toutes les charges calcules prcdemment, celles de certaines tches sont directement
lies au niveau dexpertise de lquipe de dveloppement.
1 Pondration du niveau d'expertise de l'quipe de dveloppement
Seules les 3 cellules bleues sont renseigner

(le total % doit faire 100)


Senior (coeff.0,6)

Exemple: Pour 1 expert, 5 bons et 4 novices,


entrez : (senior=10,moyen=50,novice=40)

Tches rvises

10

Charges initiales

Maquettage

60
24
60
204
54

Architecture Applicative/Technique
Spcifications Techniques
Codage des composants
Tests unitaires

Total en jours

Moyen (coeff.1)

Senior

Novice (coeff.1,4)

50

Moyen

3,6
1,44
3,6
12,24
3,24

402
24
figure III.4.7 Pondration des Charges

40

Novice

Total %

100
Pondres

30
12
30
102
27

33,6
13,44
33,6
114,24
30,24

67
27
67
228
60

201

225

450

On compte parmi ces tche le Maquettage, lArchitecture Applicative, les Spcifications


Techniques, le Codage des Composants, et les test.
On applique chacune de ces charges un coefficient de pondration en fonction du niveau
d'expertise du dveloppeur.
Ces coefficients sont respectivement de 60%, 100% et 140% du temps nominal pour des
programmeurs experts, moyens, et dbutants.
Les applications du monde du Client-Serveur peuvent, par ailleurs, ncessiter une intgration
plus ou moins complexe.
En fonction de la complexit de cette intgration, on va affecter au chiffre donn dans la
figure III.4.2 de Qua lification/Intgration, un facteur de 1, 1.5 ou 2.5 suivant que cette
intgration est d'une difficult normale, complexe, ou trs complexe.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

47

2 Pondration selon la complexit intgrer le Produit


(architecture technique et logicielle complexe, forte intgration avec d'autres applications)

Normal
Complexe
Trs complexe

Normal

Slectionnez le niveau de difficult de l'intgration du produit :

coefficient

0
Tche rvise
Qualification/Intgration

Charges initiales

Pondres

36
36
figure III.4.8 Pondration due la complexit d'intgration

Par la suite, on va estimer un besoin "transverse". Ce surcot est donc li des structures
transverses, s'impliquant principalement dans le projet lors de runions, pour des besoins de
suivi de projet en terme d'architecture, de qualit, et de scurit.
Ces charges se calculent par tranche de 100 jours, en fonction des coefficients suivants :
3 Estimation de la charge Architecture/Qualit en J/H (calcul automatique)
Nature

Barme J/H

1048

100 premiers
jours

Par tranche de 100


j supplm.

Fixe si > 100 jours

Charges
calcules

Administration
administration fonctions
administration donnes

0,5
0,5

0,25
0,5

2,75
5,00

PVCS
validation archivage

0,5

0,50

Revues Qualit
code NCL
code C
ergonomique
procdures stockes
architecture
performances
fin d'tape

0,5
0,5
0,5
0,5
2
3
3

0,5
0,5
0,5
0,5
0,5
0,5
7,5

5,00
5,00
5,00
5,00
6,50
7,50
7,50

49,75

TOTAL Charges

figure III.4.9 Charge Architecture/Qualit

Notons qu'en xNet, ce besoin est beaucoup moins important qu'en Client-Serveur.
III.4.5. Etape 4 : Total aprs Pondrations
Il suffit par la suite de remplacer les valeurs trouves grce aux pondrations dans le tableau
de rpartition des charges.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

48

Nom du Projet
Ne rien saisir sur cette feuille

Matrise d'Oeuvre (MOE)


Charge

Etapes:

J/H

Suivi de Projet
Encadrement Projet

* Etude de l' Option Progiciel


* Comit de Pilotage

Conception Dtaille
Analyse des Flux
Analyse des Donnes
Impacts Organisationnels
Maquettage
Architecture Applicative/Technique
Spcifications Fonctionnelles Dtailles
Retour revue d'ergonomie
Spcifications Techniques
* Reprise d'antriorit
Organisation pour l'implantation
Estimation des Charges
Revue Qualit
Comit de Pilotage

Construction
Prparation des Tests (jeux d'essais)
Codage des composants
Tests unitaires
Tests fonctionnels
Qualification/Intgration
Revue Qualit

J/H

%MOE+MOA
/tot

% de chacun
MOE

MOA

60
60

3%

198

11%

70% 30%

8
2
1
3
2

1%

0%

21
6
6
6
3

1%

29

2%

28% 72%

130
48
18
18
36
6
1
3
0
0

12%

8%

193
90
12
30
48
6
0
7
0
0

11%

323

19%

40% 60%

330
60
60
6
67
27
30
6
67
0
0
3
1
3

30% 19%

229
60
60
24
18
0
18
3
12
0
24
3
0
7

13%

559

32%

59% 41%

398
24
228
60
48
36
1

36% 23%

24
24
0
0
0
0
0

1%

422

24%

94%

98
18
60
18
2

6%

142

8%

50

3%

36% 1723

100%

Recette
Prparation logistique
Tests de Recette
Prparation de l'exploitation
Revue Qualit/ Comit de Pilotage

Charges Architecture

TOTAL PROJET

J/H

MOE + MOA
Charge

8%

Protocole de Projet
Comit de Pilotage
Runion d'initialisation

Prise en cpte des contraintes


Etude de Faisabilit
Estimation des charges
Revue Qualit
Comit de Pilotage

%MOA
/tot.

13%

Cadrage

Analyse et Modlisation
Etude de l'existant

Matrise d'Ouvrage (MOA)


Charge

/tot

138
138

Initialisation

Etude Pralable

% MOE
/MOE

44
6
12
24
2

4%

3%

50

5%

3%

1098 100% 64%

625

6%

31% 69%

100%
64% 36%

figure III.4.10 Total aprs pondrations

III.4.6. Etape 5 : Reste Faire


Le "Reste Faire" calcul en fin de mthode est calcul ainsi :
Le suivi de projet MOE sera gal la somme des charges MOE de conception, de
cnostruction, et de recette, pondres par la variable SUIVI (cf plus haut).

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

49

Le suivi de projet MOA sera gal la somme des charges MOA de conception, de
construction, de recette, et de suivi de projet MOE, le tout pondr par la variable SUIVI.

Nom du Projet
Ne rien saisir sur cette feuille

Reste Faire
Etapes

J/H MOE *

J/H MOA *

Conception Dtaille

330

229

Construction

398

24

Recette

44

98

Charges Architecture

50

Suivi de Projet

107

47

TOTAL PROJET

929

398

TOTAL PROJET (MOE+MOA)

1327

figure III.4.11 Reste faire

Le "Total Projet MOE" revient une estimation MOE en terme de charge de projet (ce qui
nous intresse ici).
III.4.7. Conclusions
Cette mthode, mme si rserve au dpart au Client-Serveur exclusivement, possde
l'avantage d'tre d'une transparence ingale. La plupart des paramtres correspondants
rellement au Client-Serveur peuvent tre modifis, voire compltement adapts. Nous
verrons par la suite s'il est possible d'ajouter et d'enlever plusieurs paramtres dans la mthode
afin de coller au maximum l'valuation des xNet.

Projet, Spcifications

Ecrans

Mthode Probst

Lignes de Code
Tables/Donnes

Pondration

Traitements
Fonctions
Complexit
Matriel
Equipes
Mthodes

Charge
MOE

Charge
MOA

Dlai

Taille de
lquipe
Rsultats

figure III.4.12 Vue d'ensemble de la mthode

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

50

III.5. Mthode interne ICDC (ESTIMAT)


III.5.1. Philosophie dESTIMAT
ESTIMAT est un outil mis au point au dbut des annes 1990 par la cellule MIP (Mthode
Ingnierie Progiciels, laquelle appartenait galement A.Probst) d'Informatique CDC.
Cette mthode se base principalement sur la mthode Algorithmique : le principe consiste
utiliser des formules mathmatiques pour exprimer l'effort en fonction d'lments mesurs, ou
estims.
Par la suite, on leur applique un coefficient d'ajustement se basant sur l'environnement. (Le
principe de ces coefficients est relativement similaire au modle COCOMO).
Ce sont des donnes issues de l'exprience qui vont servir dterminer ces coefficients.
III.5.2. Estimation de l'Effort Brut de Ralisation
L'effort est la mesure de la charge humaine ncessaire l'tude et la ralisation du projet.
Cet "effort" va permettre d'estimer la charge et le dlai.
L'Effort Brut de Ralisation est un effort calcul partir d'lments dnombrs ou estims, et
de donnes statistiques.
Le but de l'opration va tre d'obtenir une Estimation Thorique la suite d'une tude
pralable. Le chiffre obtenu aura une valeur et une prcision toute relative, mais aidera dj
avoir un aperu de la situation.
Il faudra, bien entendu, par la suite, aprs l'tude dtaille, faire un chiffrage plus prcis et
justifi du projet.

La premire tape consiste donc faire une estimation en fin d'tude pralable :

ESTIMAT - Effort de Phase


Valeur (JH)

Facile
20

Moyen
40

Difficile
60

figure III.5.1 Effort de Phase

On commence par calculer le nombre de phase l'intrieur du projet, et on en estime l'effort


en fonction du niveau de difficult et du tableau des efforts ncessaires chacune des phases
(figure III.5.1).
L'Effort Brut de Ralisation sera donc de :

" EBR = nfacile * 20 + nmoyen * 40 + ndifficile * 60 "

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

51

nfacile est ne nombre de phases dites "faciles".


nmoyen est ne nombre de phases dites "moyennes".
ndifficile est ne nombre de phases dites "difficiles".

A cet EBR, il est ncessaire d'ajouter 14% d'"Effort d'Encadrement".

" Effort Thorique = EBR * 1.14 "

III.5.2. Estimation de l'Effort de Ralisation et Rpartition


Une fois la phase d'tude dtaille amorce et bien avance, il sera possible d'effectuer un
chiffrage plus pertinent.
Pour cela, on va calculer un effort tenant compte, la fois de la complexit des rgles de
gestion et des rgles de mise jour de la base, mais aussi du volume des travaux effectuer.
On distingue ainsi deux types de traitements :
- Le traitement Conversationnel : (ou Transactionnel) - Nombre d'crans ddis
l'utilisateur
- Le traitement par lots : Nombres d'Etats Traitement automatis
A l'intrieur de ces traitements, on va distinguer deux parties :
- Partie Variable : Ecrans, ou traitement.
- Partie Fixe : Traitement de la partie variable, Processus. (Cot de la squence entre les
parties variables)22

ESTIMAT
Estimation Dtaille
(JH)
Simple Moyen Difficile
Traitements
Conversationnels
Traitements
par lots

Fixe
Variable
Fixe
Variable

5
3
4
4

10
4
8
6

15
5
12
8

figure III.5.2 Charges par type de traitement

On peut donc calculer l'effort de ralisation grce la figure III.5.2.

22

Les appellations "Variable" et "Fixe" sont trompeuses. On pourrait les remplacer pour plus de comp rhension
par "Etape" et "Enchanement d'tapes".

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

52

" E = Efixe + nsimple * Esimple+ nmoyen * Emoyen+ ncomplexe * Edifficile "


Efixe : Effort fixe, en fonction de la difficult de la phase (Partie fixe)
nsimple : Nombre d'crans "simples"
Esimple : Effort pour un cran simple (Partie Variable)
nmoyen : Nombre d'crans "moyens"
Emoyen : Effort pour un cran moyen (Partie Variable)
ncomplexe : Nombre d'crans "difficiles"
Edifficile : Effort pour un cran complexe (Partie Variable)
III.5.3. Rpartition en Charges (Mthode ESTIMAT)
Une fois l'Effort de ralisation obtenu, on va pouvoir assigner une charge chacune des
phases. Soit un effort nominal E, il faudra affecter comme suit les charges :
Etude Pralable: 10% * E
Etude Dtaille : 60% * E
Etude Technique : 20% * E
Production du Logiciel : K * E
Mise en uvre : 40% *E
Soit un total de (1.3 + K) * E d'Effort Total.

" ETOTAL = (1.3+K) * E "


Le coefficient de pondration K sera calcul grce 12 facteurs (figure III.5.3).
ESTIMAT
Facteurs d'Ajustement
Attributs du produit
Contraintes de Scurit et de Qualit
Taille de l'Application
Complexit des Spcifications
Attributs de l'Ordinateur
Contraintes d'implantation/d'excution
Instabilit du support Mtriel/Logiciel
Attributs de l'quipe
Comptence de l'quipe
Exprience du domaine
Exprience du support Mtriel/Logiciel
Matrise du langage de Programmation
Attributs du Projet
Utilisation de Mthodes & Outils
Niveau de Langage utilis
Contraintes de dlai de Livraison

Bas

Moyen

Elev

Trs
Elev

Similarit
COCOMO

0,85
0,95
0,85

1,00
1,00
1,00

1,15
1,10
1,15

1,40
1,20
1,30

RELY

0,95
0,85

1,00
1,00

1,10
1,15

1,25
1,30

TIME
VIRT

1,20
1,15
1,10
1,05

1,00
1,00
1,00
1,00

0,85
0,90
0,90
0,85

0,70
0,80
0,90
0,85

A(P)CAP
AEXP
VEXP

1,10
1,10
0,80

1,00
1,00
1,00

0,90
0,90
1,05

0,80
0,80
1,10

MODP
N/A
SCED

DATA
CPLX

LEXP

figure III.5.3 Facteurs d'ajustement

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

53

Ces douze facteurs doivent tre classs suivant une chelle six degrs, allant de "Bas"
"Trs Elev"
Le coefficient de pondration est le produit des 12 facteurs calculs partir de la figure
III.5.3.
Notons que ce coefficient peut varier de 0.12 7.5 (un rapport de plus de 60 ce qui reste
trs raisonnable par rapport COCOMO, mais reste extrmement lev dans l'absolu), sa
valeur tant gale 1 pour un projet normal.

III.5.4. Rpartition en Charges (Mthode alternative)


Au-del du modle ESTIMAT, ICDC utilise un autre type de modle pour le calcul de la
charge et des dlais, en fonction de l'effort.
Soit E, l'effort fournir en terme de ralisation et de tests unitaires.
ICDC a dtermin les coefficients suivants :
Spcifications Fonctionnelles Globales (SFG) : 20% * E
Spcifications Fonctionnelles Dtailles (SFD) : 40% * E
Etude Technique : 20% * E
Ralisation : 100% * E
Tests Unitaires : 25% *E
Mise en uvre : 25% * E
Total : 230% * E
Il convient donc d'appliquer un coefficient de C = 2.3 E pour avoir le temps total ncessaire
la ralisation de l'application.
On admet que ce coefficient soit rduit C = 2.1 si E < 80.
Soit :

" Charge TOTALE = C * E"


Le Dlai sera gal la racine de la Charge Totale (En Mois*Homme), laquelle on aura
enlev les SFG et les SFD :
Soit :

" Dlai = 21 *

( ((C-0.6) * E) / 21) "

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

54

III.5.5 Conclusions
La mthode ESTIMAT, visiblement inspire d'une mtrique de type "Points de Fonction"
pour l'estimation nominale de la charge, et de COCOMO pour la pondration, a l'avantage
indniable d'affecter la charge nominale des coefficients permettant d'estimer la charge
totale, des spcification la mise en production.
La mthode est, priori, bien adapte tous les projets en gnral, puisque ne dispose pas de
paramtres spcifiques au type d'application dvelopp. Il est donc ais, une fois de plus,
d'adapter les coefficients de la mthode pour obtenir une estimation propre aux xNet.

Projet, Spcifications

Ecrans

ESTIMAT

Lignes de Code
Tables/Donnes

Pondration

Traitements
Fonctions
Complexit
Matriel
Equipes
Mthodes

Charge
MOE

Charge
MOA

Dlai

Taille de
lquipe
Rsultats

figure III.5.4 Vue d'ensemble de la mthode

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

55

IV. Evaluation dun xNet


IV.1. Introduction
Les mthodes que nous avons analyses jusqu' prsent (hormis celle de J-P.Vikoff) ne sont
pas, proprement parler, ddies l'valuation des xNet.
C'est d'autant plus cohrent, que ces mthodes qui nous sont arrives, et par consquent ont
eu le temps de faire leurs preuves datent d'avant le milieu des annes 1990 23 .
Il est relativement lgitime de considrer le dveloppement d'un xNet comme celui d'une
application en client-serveur (et ce, pour des raisons techniques). Cependant, on notera tout de
mme quelques diffrences flagrantes entre ces deux mondes, qui ne sont pas sans avoir un
impact important sur un paramtre de dveloppement qui nous intresse particulirement ici,
savoir la charge ncessaire au dveloppement.
Tout d'abord, il faut savoir que le client sur le xNet est universel (c'est le navigateur). Le code
de l'application "client" s'en trouve de fait considrablement simplifi : grce un "mtalangage" (comprenez : le HTML, bien videmment) la fois simple, et ayant un formidable
potentiel en terme d'interface, il n'est plus ncessaire d'avoir un code lourd du ct client
sans compter que la simplicit du HTML permet une capacit de modification du code client
sans comparaison.
De mme, grce la standardisation du CGI 24 et du HTTP 25 , on s'affranchit des protocoles
complexes de communication (Sockets, RMI, RPC, CORBA, SOAP, COM, etc.) inhrents au
client-serveur ce qui est un avantage indniable.
Ensuite, nous avons pu voir dans certains mthodes que les applications de type "RAD"
pouvaient tre dveloppes beaucoup plus rapidement pour dire la mme chose d'une autre
faon, si l'utilisateur peut donner le plus souvent possible un retour sur l'application en cours
de dveloppement, les chances de voir le projet dvier seront amoindries (dans une certaine
mesure, bien entendu), et le dveloppement devrait en tre d'autant plus rapide
Dans la ralit, ce genre de fonctionnement n'est pas forcment du got de la matrise
d'uvre en effet, si ce levier est mal utilis par la matrise d'ouvrage, la pression subie par
les dveloppeurs, et les changements d'opinions (invitables) de la part des MOA pourrait
galement faire perdre du temps de dveloppement.

23

C'est en effet au milieu des annes 1990 que l'Internet a rellement commenc se dmocratiser, (il n'tait
auparavant destin qu'aux instituts de recherche et aux universits) et toucher de plus en plus les entreprises et
le grand public, et ce, jusqu' son paroxysme en 2000, o l'intrt conomique pour les nouvelles technologies a
commenc dcrotre.
24

CGI: Common Gateway Interface. Il s'agit d'un protocole de "client-serveur" normalis, utilis entre une page
HTML et un processus de l'application se situant sur le serveur.
25

HTTP: HyperText Transfer Protocol. C'est le protocole sur lequel se base le CGI pour fonctionner. Il sert de
support de communication entre un client xNet et un serveur xNet.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

56

Il faut aussi bien voir que si une partie de la charge de la MOE est rduite, du fait d'une
vrification assez assidue de la MOA, ce gain de charge est contrebalanc de l'autre ct par
une trop grande implication et une perte de temps pour la MOA ce qui est galement
coteux.
Enfin, il existe divers problmes de "scurit" dus au fait que le client soit standardis ceci
pouvant ncessiter une charge supplmentaire, assigne au contrle du droulement correct du
processus, aux vrifications des authentifications, au comblement des trous de scurit, etc.
En bref, le type d'application xNet peut aussi bien se trouver tre largement plus simplifie en
terme de dveloppement que le client-serveur, ou bien ncessiter peu prs la mme charge,
voire compltement dpasser les dlais prvus, et ce, en fonction principalement, de la
complexit de l'application et des contraintes annexes.
IV.2. Cration dun xNet & ajout de modules
Il faut savoir, par la suite, que le dveloppement d'un xNet connat plusieurs tapes
potentielles. La premire, est proprement parler, celle de la "cration", et la seconde, celle de
l'"ajout de modules".
IV.2.1. Cration d'un xNet
La cration d'un xNet est l'tape qui a lieu avant toutes les autres. (les autres tant des "ajouts
de modules", si le cas se prsente)
Il s'agit en fait, de la toute premire ralisation, de la "cration" proprement parler. Lors de
cette tape, sont tablies toutes les bases de l'application : framework applicatif, module
d'authentification, module de navigation, charte graphique, etc. et, bien videmment, les
modules mtiers, pour lesquels le xNet a t mis en place.
IV.2.2. Ajout de modules
La seconde tape pourrait tre compare une simple "maintenance volutive" : il suffit de
greffer l'existant une application possdant ses propres rgles fonctionnelles. Le terme
"greffer" est tout fait adapt : il s'agit en effet de se baser sur les modules d'identification et
de navigation existants (et au besoin, les modifier) pour ajouter une application l'existant.
Ce type de "projet" est beaucoup moins spcifique que lors d'une cration, et s'apparente, dans
ce cas, plus de l'informatique classique.
IV.2.3 Importance de l'environnement technologique
Il faut savoir que les solutions techniques de crations de xNet sont multiples. Celles-ci
peuvent aller de la simple page en HTML sans base de donnes, des technologies objets
mtiers (Beans, EJB, Java), des procdures stoques en base (PL/SQL), en passant par

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

57

des langages pr-compils (CGI en gnral), ou interprts ct serveur (Perl, ASP,


PHP).
Bref, la MOE dispose d'un panel de choix technologique on ne peut plus important. Le choix
en est d'autant plus difficile qu'un mme rsultat peut tre obtenu en utilisant des technologies
tout fait diffrentes, parfois de la plus simple la plus complexe.
Par exemple : une application affichent le calendrier du mois d'Octobre 2002 en HTML peut
tre dvelopp en 5 minutes pour les technologies les plus simples, ou en journe avec les
langages les plus complexes
En fait, tout dpend :
du niveau de rutilisabilit de l'application,
du besoin en maintenance,
de la performance dsire.
Il va falloir, quel que soit les dlais imposs, trouver le meilleur compromis entre le temps de
dveloppement, les contraintes de plateforme technologique, le besoin en rutilisabilit et en
maintenance, etc.
D'autant qu'il est de plus en plus ncessaire de revenir par la suite sur les applications, pour
des besoins en terme d'ergonomie, ou d'volutivit du produit.
Le temps pass en dveloppement doit tre considr comme un "investissement" sur les
maintenances venir. (Comme dans tous les projets informatiques, d'ailleurs)
IV.3. Alors comment valuer le xNet ?
La mthode idale pour valuer un xNet serait, de faon intuitive, d'adapter un modle
existant (La mthode Probst, par exemple, tant la plus transparente, est trs adapte) en
modifiant les coefficients attribus.
Les coefficients suivants :
- Maquettage
- Ergonomie
doivent faire l'objet d'une rvision indniable, puisque l'ergonomie en gnral est devenu un
point-clef de ce type d'application.
Il est galement indispensable de faire apparatre les coefficients suivants :
- Module d'Identification
- Module de Navigation
- Production de "contenu"
- Complexit de la plateforme
En revanche, certains coefficients (les transverses, par exemple), seront beaucoup moins
importants.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

58

V. Un exemple concret : RPI


V.1. Prsentation
V.1.1. Contexte de RPI
La mission dextension du projet RPI lintranet de la Caisse des Dpts et Consignations a
t initialise dans le cadre du partenariat entre le Mastre Spcialis HEC/ENSMP MSIT
(Management des Systmes dInformations et des Technologies) et de la CDC.
La mission est sponsorise par Monsieur Viteau (Direction de la coordination de la stratgie
informatique du groupe CDC), demande par Monsieur Guy Audoli (Directeur du SI de la
Caisse des Dpts), et supervise par Monsieur Andr Probst.
La mission consiste tendre lintranet de la CDC le projet RPI.
Lapplication RPI met en place des tableaux de bord des projets informatiques de la Caisse
des Dpts. Ces tableaux font apparatre aux dcideurs des informations pertinentes sur les
projets informatiques qui porteront sur les cots, les dlais et les risques.
Lapplication RPI est actuellement constitue dune base de donnes Access mono-utilisateur,
et dune application dveloppe sous Visual Basic permettant son interrogation, et la cration
des tableaux de bord.
Lobjectif cible consiste dfinir et mettre en place un ensemble de modules se greffant sur
lintranet de la Caisse des Dpts. Ces modules constitueront des interfaces dalimentation et
de consultation de la base de donnes de lapplication RPI.
Il s'agira d'une chane de reporting permettant la MOE, la MOA, et la Production de faire
part la DSI de leurs budgets et de leurs consommations, en introduisant leurs donnes
respectives dans RPI.
La cration des modules suivants est envisage :
Lot 1.1 :
- Module de saisie dinformations de budgets via des formulaires HTML, par lintranet. Ce
module est destin remplacer terme lalimentation actuelle de la base de donnes de
RPI par la MOA, qui seffectue lheure actuelle par lintermdiaire de fichiers Excel
envoys sous Outlook.
- Module de mise disposition dinformations budgtaires contenues dans la base RPI,
suivant un modle de tableau de bord dfini par la DSI.
Lot 1.2 :
- Module de saisie dinformations de suivi mensuel de consommations, via des formulaires
HTML, par lintranet.
- Module de publication des tableaux prdfinis, similaire lapplication existante.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

59

Lot 2 :
- Module de publication des tableaux alternatifs, (par cration de nouveaux tableaux),
(ventuellement sous BO).
Processus transversal :
- Gestion du changement, fond sur le nouveau processus de reporting et de tableaux de
bord SI.
NB: Seul le lot 1.1 ayant t ralis et finalis la date de rdaction de cette thse,
l'valuation de RPI grce aux mthodes proposes portera uniquement sur le lot 1.1 .
V.1.2. Vue d'ensemble du Lot 1.1
Voici un ensemble de captures d'crans de l'application RPI, donnant un aperu assez global
du contenu de l'application.

figure V.1.1 : cran RPI [A]

Le premier cran [A] est un cran d'identification standard. Cet cran pass, l'utilisateur arrive
sur la liste des projets [B] qu'il va pouvoir consulter/modifier. Il va pouvoir galement ajouter
des projets, et obtenir des tableaux de bord.

figure V.1.2 : cran RPI [B]

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

60

figure V.1.3 : cran RPI [C]

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

61

L'cran [C] reprsente un cran de cration ou de modification de projet. (ou en tout cas la
premire partie de la cration/modification, la seconde tant dans un second cran, appel
[D]) On peut considrer l'cran [C] comme complexe, puisqu'il permet de modifier nombre
important de donnes, et qu'il contient des vrifications d'erreurs de saisies relativement
pointues, la fois du ct client et du ct serveur.

figure V.1.4 : cran RPI [D]

La suite de l'cran [C], l'cran [D], est lui relativement moins complexe que l'cran prcdent,
mais possde lui aussi des vrifications d'erreurs de saisie.

RPI Enchanement des Ecrans

figure V.1.5 : Enchanement des crans RPI

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

62

figure V.1.6 : cran RPI [E]

figure V.1.7 : cran RPI [F]

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

63

Les crans [E] et [F] sont les pendants des crans [C] et [D], mais en consultation seulement.
Du fait qu'il ne s'agit l que de la restitution d'information, la difficult de ces deux crans
peut tre considr comme d'un niveau moindre.
On pourra galement demander une restitution des informations de RPI contenues en base.
L'cran [G] permet de choisir la sous-direction pour laquelle on veut obtenir la restitution.

figure V.1.8 : cran RPI [G]

Cette restitution (Ecran [H]), sera considre comme complexe, du fait d'un contenu rsultant
de calculs ardus, la fois en fonction du profil de l'utilisateur et de la sous-direction pour
laquelle il voudra obtenir sa restitution.

figure V.1.9 : cran RPI [H]

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

64

V.2. Estimations thoriques de la charge de RPI


V.2.1. Avec les points de Fonctions
L'analyse des Spcifications Fonctionnelles Dtailles et de la Base de Donnes de
l'application RPI donne les rsultats suivants en terme d'estimation de GDI,GDE,ENT,SOR et
INT :
RPI - Points de Fonctions
Grille de Complexit
Nombre Faible
Moyen
lev
GDI
5
2
0
GDE
0
0
0
ENT
0
0
2
SOR
0
0
0
INT
0
0
1
figure V.2.1 : Grille de complexit de RPI

Soient :

PFB = 5 * 7 + 2 * 10 + 2 * 6 + 1 * 6 = 73 PdF
Si l'on considre les ajustements suivants :
RPI - Pts de Fonctions, Pondration
Degr d'influence :
/5
Communication des donnes
1
Distribution des donnes ou des traitements
3
Performance
3
Intensit d'utilisation de la configuration matrielle
1
Taux de transition
2
Taux de transaction
2
Saisie interactive
5
Convivialit
4
Mise jour en temps rel des GDI
3
Complexit des traitements
2
Rutilisation
3
Facilit d'installation
1
Facilit d'exploitation
4
Portabilit
1
Facilit d'adaptation
3
Total : 38
figure V.2.2 : Grille de Pondration pour RPI

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

65

On obtient :

FA = 0.65 + 38 / 100 = 1.03


Soit :

PFA = 73 * 1.03 = 75
Dans le cas d'un projet "simple", la mthode conseille d'utiliser une estimation 2
Jours*Homme par Points de fonctions.
On obtient donc le rsultat suivant :

Charge = 2 * 75 = 150 J*H

V.2.2. Avec COCOMO


La taille de l'application RPI (Taille effective, donne par la MOE aprs la ralisation) est de
3.798 KDSI26 . (Notons que lestimation du nombre de ligne de code ne comprend que la
partie dveloppe du ct serveur, en JAVA, contenant quelques requtes SQL.)
Soit en appliquant les quations :

T = 0.1187 * 75 - 6.49 = 2.412


On se rapproche de faon tonnante des 2.500 KDSI
Le langage considr est le Java (qui n'tait pas mentionn dans la mthode de Dreger, de
1989).
Si l'on considre les 3.798 KLOC, on obtient 0.050 PdF par KLOC.
Si l'on considre les 2.500 KDSI, on obtient 0.033 PdF par KDSI.
Le code contenant la fois du SQL et un L3G, le chiffre 0.050 se trouve tre tout fait
acceptable.
COCOMO basique, semi-dtach : a=3.0 , b=1.12 :

E = 21 * 3.0 * 3.7981.12 = 281 J*H


COCOMO basique, semi-dtach : a=3.0 , b=1.12, c=2.5, d=0.35 :

26

Le nombre donn correspond au nombre effectif de lignes du programme. Si on compte le nombre de ";"
(points-virgules), on obtient environ 2.5 KDSI, ce qui correspond un effort nominal de 176 Jours*Homme. En
ralit, il serait plus judicieux de parler dun projet de 2.5 KDSI sur 3.798 KLOC.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

66

Projet RPI - COCOMO


Facteurs d'Ajustement

Trs
Bas

Bas

Normal

Haut

Trs
Haut

0,88
0,94
0,85

1,00
1,00
1,00

1,15
1,08
1,15

1,40
1,16
1,30

0,87
0,87

1,00
1,00
1,00
1,00

1,11
1,06
1,15
1,07

1,30
1,21
1,30
1,15

Extr.
Haut

1,65

Attributs du produit
Fiabilit Requise
Taille de la Base de Donnes
Complexit du produit
Attributs du Matriel
Contraintes de temps d'excution
Contraintes de taille mmoire principale
Instabilit de la Machine Virtuelle
Temps de Retournement
Attributs de l'quipe
Comptence des Analystes
Exprience du domaine d'application
Comptence des Programmeurs
Exprience de la Machine Virtuelle
Exprience du langage
Mthodes et Outils
Pratique des Mthodes Modernes
Utilisation d'outils logiciels
Contraintes de planning

RELY
DATA
CPLX

0,75
0,70

TIME
STOR
VIRT
TURN
ACAP
AEXP
PCAP
VEXP
LEXP

1,46
1,29
1,42
1,21
1,14

1,19
1,13
1,17
1,10
1,07

1,00
1,00
1,00
1,00
1,00

0,86
0,91
0,86
0,90
0,95

0,71
0,82
0,70

MODP
TOOL
SCED

1,24
1,24
1,23

1,10
1,10
1,08

1,00
1,00
1,00

0,91
0,91
1,04

0,82
0,83
1,10

1,66
1,56

figure V.2.3 Facteur d'ajustement pour RPI

M = 1.18 - La valeur de M a t calcule grce au tableau des facteurs d'ajustement


COCOMO (figure V.2.3).

E = 21 * 3.0 * 3.7981.12 * 1.18 = 331.5 J*H


DUREE = 21 * 2.5 * (331.5/21)0.35 = 138 J
S = 331 / 138 = 2.4 => 3 personnes
On obtient ainsi le rsultat :

Charge = 21 * 3.0 * 3.7981.12 * 1.18 = 331.5 J*H

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

67

V.2.3. Avec Evaluateur-RAD

figure V.2.4 Estimation grce Evaluateur-RAD

La valeur nominale du projet est de 66 Jour*Homme. Les diffrents facteurs annexes


intervenant amne une charge de 96 J*H. (145% de la taille nominale)

Charge = 96 J*H

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

68

V.2.4. Avec Mthode Interne CDC (A.Probst)


RPI - Lot 1.1
Fonctions recenses en tude pralable

Estimation nbre de fonctions lmentaires


simple

standard complexe

Total

Identification de l'Utilisateur
Affichage des Projets
Nouveau Projet
Consulter le Projet
Modifier le Projet
Imprimer Dtails Projet
Restitution Budgtaire

0
0
0
1
1
1
0

1
1
1
1
1
0
1

0
0
1
0
0
0
1

1
1
2
2
2
1
2

TOTAL

Nbre Fonctions

11

MCD

Nbre d'Objets/Relations

12 Nombre
d'objets/relations
saisir

Effort Brut

24

Effort Corrig

37

Reste Faire
Etapes

J/H MOE *

J/H MOA *

Conception Dtaille

20

13

Construction

22

Recette

Charges Architecture

12

Suivi de Projet

TOTAL PROJET
TOTAL PROJET (MOE+MOA)

60

23
82

figure V.2.5 Application de la mthode Probst l'valuation de RPI

Soit la charge de ralisation MOE :

Charge = 60 J*H

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

69

V.2.3. Avec ICDC-ESTIMAT


ESTIMAT
Estimation Dtaille de RPI
Traitements
Conversationnels
Traitements
par lots

Fixe
Variable
Fixe
Variable

RPI
Complexit
Ecran

Simple Moyen Difficile


0
1
0
3
3
2
0
0
0
0
0
0

A
B
C
D
E
F
G
H

Complexit
Simple
Moyen
Difficile
Moyen
Moyen
Simple
Simple
Difficile

figure V.2.6 Complexit de RPI

RPI - ESTIMAT
Facteurs d'Ajustement
Attributs du produit
Contraintes de Scurit et de Qualit
Taille de l'Application
Complexit des Spcifications
Attributs de l'Ordinateur
Contraintes d'implantation/d'excution
Instabilit du support Mtriel/Logiciel
Attributs de l'quipe
Comptence de l'quipe
Exprience du domaine
Exprience du support Mtriel/Logiciel
Matrise du langage de Programmation
Attributs du Projet
Utilisation de Mthodes & Outils
Niveau de Langage utilis
Contraintes de dlai de Livraison

Bas

Moyen

Elev

Trs
Elev

Similarit
COCOMO

0,85
0,95
0,85

1,00
1,00
1,00

1,15
1,10
1,15

1,40
1,20
1,30

RELY

0,95
0,85

1,00
1,00

1,10
1,15

1,25
1,30

TIME
VIRT

1,20
1,15
1,10
1,05

1,00
1,00
1,00
1,00

0,85
0,90
0,90
0,85

0,70
0,80
0,90
0,85

A(P)CAP
AEXP
VEXP

1,10
1,10
0,80

1,00
1,00
1,00

0,90
0,90
1,05

0,80
0,80
1,10

MODP
N/A
SCED

DATA
CPLX

LEXP

figure V.2.7 Facteur d'ajustement pour RPI

K = 1.03 - La valeur de K a t calcule grce au tableau des facteurs d'ajustement


ESTIMAT. (figure V.2.3)

E = 10 + 3 * 3+ 3 * 4+ 2 * 5 = 41 J*H
ETOTAL = (1.3+ 1.03) * 41 = 95.5 J*H
Charge TOTALE = 2.1 * 41 = 86.1 J*H
Dlai = 21 *

( ((2.1-0.6) * 41) / 21) = 36 J

Soit la charge de ralisation (Uniquement pour la ralisation) :

Charge = 1.7 * 41 * 1.03 = 72 J*H


Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

70

V.3. Droulement Concret


V.3.1. Estimation de la MOE
Le lot 1.1 de l'application RPI a t estime 48 Jours*Homme.
Il faut garder en tte, lorsque l'on donne ce chiffre, que la premire partie du projet (en
l'occurrence, le lot 1.1) devait absolument tre livr pour dbut septembre 2002, en vue de son
utilisation par la DSI pour la procdure budgtaire 2003.
Notons que cette estimation couvre uniquement le dveloppement, les tests, et la recette.
V.3.2. Charge Relle
Le projet devait donc tre oprationnel trs vite Si l'on considre les valuations faites
travers les diffrentes mthodes proposes, on se rend compte que toutes les valuations (sans
exceptions) annoncent, sans ambigut, un chiffrage plus important.
Ce projet a pris trs peu de retard Pourtant, un certain nombre de fonctionnalits non
prvues l'origine ont d tre rajoutes par la suite dans ce lot, sans compter la modlisation
de la base, qui a pris un certain temps se stabiliser. (ce qui n'est pas anormal, dans un
contexte de ce type) On pourra considrer que mme si 48 jours ont t prvus, environ 55
ont t utiliss pour la ralisation.
On peut donc aisment conclure que la thorie de Parkinson sur les gaz parfaits s'est sans nul
doute applique ici.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

71

V.4. Conclusion
Aprs l'valuation du projet RPI avec les cinq mthodes proposes, on obtient les valeurs
suivantes :
Mthode

Valeur Nominale Valeur Pondre


Rel
48
55
Probst
60
60
ESTIMAT
70
72
RAD-Evaluateur
66
96
PDF
146
150
COCOMO
281
331,5
figure V.4.1 Facteur d'ajustement pour RPI

Charges RPI

Comparaison des Mthodes

350
300
250
200
150
100
50
0
Rel

Probst

ESTIMAT

Value Nominale

RADEvaluateur

Points de
Fonction

COCOMO

Pondration

figure V.4.2 Facteur d'ajustement pour RPI

On peut tirer de ces rsultats les conclusions suivantes :

La mthode COCOMO ne semble pas tre adapte : si l'on considre rellement les
KDSI ou les KLOC, en fonction du langage utilis, pour la mme application, on
obtiendra des rsultats rellement disproportionns. D'autant que la mthode
COCOMO ne tient pas du tout compte de l'application du ct client et de la
complexit de l'ergonomie.

La mthode des points de fonction semble tre excellente pour mesurer la "taille"
d'une application, en terme de KDSI ou KLOC, mais le facteur de 2 JH par Point de
Fonction est beaucoup trop lev. Il aurait fallu, pour avoir un rsultat exact, faire le
calcul avec 0.75 JH par Point de Fonction.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

72

La mthode RAD- Evaluateur donne un rsultat nominal (mtrique d'origine) trs


acceptable, mais les pondrations opaques faites par le logiciel font perdre de la
crdibilit la mthode, ce qui est d'autant plus dommage que le logiciel a t
dvelopp spcifiquement pour estimer la charge des xNet.

La mthode ESTIMAT est proche du rsultat final. Il faudrait probablement pour tre
proche de la ralit, y ajouter certaines donnes relatives aux modules d'identification
et de navigation, et modifier les coefficients de complexit des composants.

C'est la mthode Probst qui se rapproche le plus de la ralit (moins de 10% d'erreur
sur ce projet). Comme suggr lors de l'analyse pralable, il faudrait l aussi, ajouter
des donnes relatives aux modules d'identification et de navigation, et les charges
d'oprations transverses, pour obtenir un rsultat rellement fiable.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

73

Conclusion
La bonne mthode ?
En rsum, si l'on voulait construire une mthode idale d'valuation des charges de projets
xNet, on devrait effectuer les tapes suivantes :
1) Calcul de la mtrique du projet, en terme d'crans (ESTIMAT, RAD-Evaluateur), ou de
Fonctions (Probst, Points de Fonctions).
2) Pondration en fonction de paramtres internes (COCOMO, Probst)
3) Pondration en fonction de paramtres externe (Toutes les Mthodes)
4) Ajout de contraintes transverses (Probst)
5) Calcul de charges restant effectuer en fonction d'un coefficient correspondant l'tat
actuel du projet (Probst)
Quelques bonnes pratiques
Au bilan, cinq mthodes plus ou moins diffrentes les unes des autres. Chacune a ses propres
paramtres, chacune donne ses propres rsultats.
Et la fourchette des paramtres entrs tant rellement large, on ne peut pas rellement faire
ressortir les paramtres de mtriques principaux. De plus, les variables de sortie tant elles
mmes peu cloisonnes, on ne sait jamais exactement ce que l'on est en train d'estimer (les
tests unitaires et la recette sont- ils compris dans les charges de la ralisation, etc.)
En bref, vouloir faire ressortir un rsultat prcis et bien dlimit, partir d'une science non
exacte prenant en compte toute sorte de paramtres, dont certains sont plus ou moins farfelus,
se rvle tre, au final plus un exercice de style, qu'une mthode fiable : on jongle avec
beaucoup de chose, et il est on ne peut plus ais de faire rendre la mthode les chiffres que
l'on veut.
Cependant tout n'est pas perdu : le fait de croiser toutes ces mthodes peut permettre de
donner une estimation plus ou moins raliste ( un facteur prs, puisque toutes les valuations
se rvlent tre trop leves.)
Ainsi, une bonne solution pourrait tre, si l'on dsire effectuer rapidement une valuation d'un
projet xNet, de crer une sorte de "Tableau de Bord", destin la MOA, qui serait galement
fourni la MOE, et contenant un ensemble de points sur lesquels ils pourraient se mettre
d'accord, en l'occurrence sur les paramtres d'entre... ceci ncessitant une demi-journe, tout
au plus.
La MOA pourrait rapidement avoir un aperu global des estimations ainsi faites.
Ce tableau de bord pourrait contenir les informations suivantes ::

Estimation de la MOE.
Mtriques des cinq mthodes (Nombre et complexit d'crans, de tables, de fonctions,
etc.)
Estimations faites avec les Points de Fonctions, COCOMO, RAD- Evaluateur, Probst,
et ESTIMAT (tableaux similaires aux figures V.4.1 et V.4.2)

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

74

Comparaison des Mthodes


120
100

73%

80 65%
60
40

12%
9%

20
0
8000

Points de
Fonction

COCOMO

ESTIMAT

Probst

7238%

7000
6000
5000
4000
3000
2000

753%

135%

1000

114%

0
Points de
Fonction

Plus Bas

COCOMO

ESTIMAT

Nominal

Probst

Plus Haut

figure VI.1.1 Extrmes des pondrations

Prsentation des marges d'inexactitude des pondrations en fonction des mthodes


(figure VI.1.1). En effet, ces pondrations font varier la taille nominale du projet de
faon inquitante. La MOA, en voyant ces chiffres, aura probablement le rflexe
d'utiliser la mthode o l'erreur due la pondration est la plus faible.
Moyenne des estimations de 1/6 * ( Charge la plus optimiste + Charge la moins
Optimiste + 4 * Charge la plus probable).

... cette solution amnerait la MOA juger elle- mme du chiffre d'estimation des charges
qu'elle peut obtenir, tout en lui mettant en avant qu'il est vident que le rsultat obtenu sera
d'une fiabilit relative, en raison des marges d'erreurs, et de la difficult comparer ces
mthodes htroclites... Le plus important de ce tableau de bord tant probablement
d'apporter des arguments ncessaires une discussion saine et constructive, en matire
d'laboration de planning, entre la MOE et la MOA.

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

75

Annexes
Bibliographie
Ouvrages

La mesure du logiciel (Henri Habrias)


2me dition revue, corrige et augmente
Teknea (ISBN : 2877170454)

Piloter les projets informatiques de la nouvelle conomie (Jean-Pierre Vickoff)


Editions d'Organisation (ISBN : 2708124870)

Project Management: a Managerial Approach


(Jack R. Meredith, Samuel J. Mantel Jr.)
John Wiley and Sons (ISBN: 0471434620)

Web Site Project Management (Ashley Friedlein)


Morgan Kaufmann (ISBN: 1558606785)

Gestion dun projet systme dinformation - Principes, techniques et mise en uvre


(Chantal Morley)
Dunod (ISBN: 2100059734)

Prcis de Conduite de Projet Informatique (Cyrille Chartier-Kastler)


Editions d'Organisation (ISBN : 2708118145)

Conduite de projets informatiques : principes et techniques


(Jos Morjon, Jean-Ren James)
Interditions (ISBN : 272960457X)

Le management d'un projet (H.-P. Maders)


Editions d'Organisation (ISBN : 2708117947)

Que Sais-je : Le management de projet (Olivier Badot, Jean-Marie Hazebroucq)


Presses Universitaires de France (ISBN : 2130474179)

Le matre d'ouvrage du systme d'information (Alain Berdugo)


Herms Sciences (ISBN : 2866016211)

Guide du Management des Systmes d'Informations - Thmes & Termes Essentiels


(Alain Berdugo, Robert Mahl, Grard Jean, HEC/ENSMP MSIT 2002)
Herms Sciences Publications (ISBN : 2746205246)

De la Stratgie aux Systmes d'Information (ALTIME)


Formation ALTIME/HEC/ENSMP, fvrier 2002

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

76

Documentations Electroniques
ADELI (d'Association pour le Dveloppement de la Logique Informatique)
http://www.adeli.com/
- Estimations des charges dun projet Informatique (Alain Coulon)
http://www.adeli.com/actcomest.htm

- Estimations de charges - Les orientations de la commission (Alain Coulon)


Lettre ADELI n39 - Square des Utilisateurs - avril 2000
http://www.adeli.com/doc/l39p8.pdf

- Estimation de projets informatiques (Kathleen Peters, traduit par Alain Coulon)


Lettre ADELI n41 - Square des Utilisateurs - octobre 2000
http://www.adeli.com/doc/l41p23.pdf

- Calibrage et talonnage (Jean Joskowicz)


Lettre ADELI n42 - Square des Utilisateurs - janvier 2001
http://www.adeli.com/doc/l42p20.pdf

- Science ou magie ? - Le point sur les estimations des projets logiciels


(Nicolas Trves et Alain Coulon)
Lettre ADELI n45 - Square des Utilisateurs - octobre 2001
http://www.adeli.com/doc/l45p19.pdf

La mthode des Points de Fonction (Olivier Denel)


Thse MSIT (HEC/ENSMP) - http://www.denel.com/pdf/index.html

Rapport CIGREF : Rseaux Internet/Intranet


Rapport CIGREF, septembre 1997

COCOMO: Resource Estimation


(David Stotts, Associate Professor, Dept. of Computer Science)
University of North Carolina - http://www.cs.unc.edu/~stotts/COMP145/cocomo.html

IFT3902 : Dveloppement, maintenance de logiciels


(Universit de Montral : Facult des Arts et des Sciences)
Informatique et recherche oprationnelle
http://www.iro.umontreal.ca/~pift3902/Cours2001/Planification.pdf

Estimation des cots et dlais par la mthode COCOMO


(Tina Wilhelm, velyne Parthenay, Hugues Am)
Ecole Suprieure en Sciences Informatiques
http://www.essi.fr/~hugues/GL/COCOMO/cocomo.html

Algorithmics Costs Model (Dan Snell)


Bournemouth University - http://www.ecfc.u-net.com/cost/models.htm

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

77

Conduite de projets informatiques - Principes Gnraux et Techniques


(Violaine Prince)
Laboratoire d'Informatique, de Robotique et de Microlectronique de Montpellier
http://www.lirmm.fr/~joab/tni/cp2.pdf

Evaluation, la thorie (Jean-Pierre Vickoff)


http://mapage.noos.fr/rad/boudeval.htm

Principes dEvaluation (Jean-Pierre Vickoff)


http://mapage.noos.fr/rad/evalint.htm

Autres documents & Mthodes

Mthode Interne CDC Feuille de Calcul dEstimation de Projets


(Andr Probst)

Mthode ESTIMAT
Informatique CDC, Mthodes Ingnierie Progiciels

Version 103.463( 3703), 29/09/2002 (17:07)


Imprim le 15/11/2002 ( 18:26)

Georges Zadrozynski MSIT 2002 - Mthodes dEstimation de Charges dans le cadre dun projet xNet

78