PRATIQUE DE L ’ESTIMATION DES COUTS DE PROJETS DE SI

C E N T R E D E 

MAITRISE DES 

SYSTEMES ET 

DU LOGICIEL 

PRATIQUE DE L ’ESTIMATION 

DES COUTS DE PROJETS DE 

SI 

CMSL/B.Mesdon - Mars 2004 

Estimation des projets SI 

Page 1

PLAN 

• Pratique de l ’estimation 

– Introduction 

– Typologie des projets 

– Cas des projets « agiles » 

– Démarche générale 

– Ratios de productivité 

– Charges additionnelles 

– Estimation et suivi des délais de 

développement 

– Problématique du coût total de 

possession 

• Etudes de cas 

– Typologie à travers 3 cas 

– Récapitulatif des charges et 

délais 

– STARTALERT : Projet moyen de 

gestion 

– GESTMAT : Grand projet de 

gestion 

– GROUPWORK : Très grand 

projet d ’intégration 



Page 2

PRATIQUE DE L ’ESTIMATION 



Page 3

Introduction 

• Les méthodes d ’estimation COCOMO et Points de fonction ont 

été proposées en 1970-1980 pour les applications centralisées 

de l ’époque. Dans la pratique courante d ’aujourd’hui, la 

typologie des projets a beaucoup évolué. Néanmoins, 

moyennant quelques adaptations, ces méthodes sont encore 

globalement valables dans les environnements actuels. 

• De toutes façons, l ’étalonnage à partir des cas connus et 

mesurés (en terme de typologie, taille, complexité, 

environnement, etc.) reste fondamental, quand à la fiabilité des 

résultats. 

⇒ L ’utilisation des méthodes d ’estimation font partie des 

« bonnes pratiques » de l ’AQL (Assurance Qualité Logiciel). 



Page 4

Typologie des projets (1/4) 

• La typologie proposée comprend les trois classes 

suivantes : 

– Développement d ’applications de gestion 

– Développement d ’infrastructures logicielles et applications 

techniques 

– Intégration de systèmes 

• Nota1 : Dans COCOMO-2, B.Boehm introduit une classe spécifique 

pour « End-User Programming ». Mais, les « end-user » n ’utilisant pas 

habituellement de méthodes d ’estimation, on négligera cette catégorie. 

• Nota2 : Les « embedded systems » sont devenus une catégorie 

importante. Leur estimation peut s ’approcher par des méthodes 

dérivées des points de fonction (Full Fonction Points) 



Page 5


• Applications de gestion 

– Ce sont les applications de gestion traditionnelle développées en 

méthodologie MERISE ou objet. 

– Profil type : 

» Développement sous AGL orienté Gestion 

• Delphi, PowerBuilder, Uniface 

• AGL HTML, XML, JAVA, etc. 

» BD relationnelles 

» IHM graphiques et/ou « navigateur » 

» Mises à jour des BD en mode transactionnel 

» Environnements d ’exécution maîtrisés 

• Centralisé (classique, client léger) 

• Client /Serveur (2-tier, n-tier, web, ..) 

⇒ Méthode d ’estimation : Points de fonction (IFPUG, MKII) 



Page 6


• Projets d ’infrastructures logicielles et applications techniques 

– Ce sont sont les développements chez les constructeurs (OS) et 

chez les éditeurs (middleware). On y rattache les applications 

techniques (CAO, DAO, etc.), ainsi que les logiciels embarqués. 


» Développement sous AGL orienté système 

• historiquement, développement en assembleur, puis C. 

• évolution vers C++, JAVA 

» Prise en compte de contraintes de productisation : portabilité, 

interopérabilité, évolutivité, maintenabilité, etc. 

» Environnement d ’exécution pouvant dépendre d ’aspects 

combinatoires, événementiels, sécuritaires, etc. 

⇒ Méthode d ’estimation : COCOMO (ou FFP ?) 



Page 7


• Intégration de systèmes 

– Ce sont les « grands projets complexes » des domaines 

Défense, Avionique, Télécommunications, Energie, etc. 


» Ces projets cumulent la contrainte d ’adéquation à des besoins 

spécifiques « métier » propres aux applications de gestion, 

avec la complexité d ’architecture des infrastructures logicielles. 

» L ’ensemble implique une étude d ’architecture complexe, et 

une intégration d ’éléments hétérogènes (COTS, spécifiques, 

réutilisés). 

» Méthodologies de gestion de projet « lourdes » avec 

contraintes rigoureuses de gestion de configuration. 

⇒ Méthode d ’estimation bien adaptée : COCOMO + Points 

de fonction 



Page 8

• Cycle classique 

Cas des projets « agiles » 

– Les méthodes d ’estimation ont été proposées pour estimer 

des projets à spécification fonctionnelle pré-définie et 

développés suivant un cycle plutôt séquentiel. 

• Méthodes agiles 

– Les méthodes de développement dites « agiles » veulent 

supporter une spécification évolutive. L ’estimation à partir de 

la spécification est donc impossible dans ces 

conditions.Concrètement, l ’agilité implique souvent de 

considérer le budget de développement et le calendrier comme 

des données de départ. 

» Tout chef de projet confirmé sait de toutes façon que, même en 

méthode traditionnelle, les budgets et calendriers sont contraints. 

– En fait, ces méthodes sont plutôt réservées aux projets 

exploratoires, et de toutes façon limités en taille. 



Page 9

Démarche générale (1/3) 

• Généralités 

– La démarche d ’estimation des charges et coûts par le Chef 

de Projet correspond à une phase de responsabilisation. 

– L ’état de l ’art en méthodes d ’estimation est loin d ’être 

parfait. Une marge d ’erreur de + -20% est acceptable. 

– A 99,999%, l ’écart est dans le sens de l ’augmentation 

» Syndrome de dérive des coûts/délai, avec pour cause 

fondamentale, la non stabilité de {F,Q} 

⇒ La démarche d ’estimation est un bon préambule à 

l ’analyse des risques projet, et à l ’analyse de la valeur. 



Page 10

• Les 9 étapes de l ’estimation 


– 1 Cadrage général et identification de la classe de projet 

– 2 Modélisation fonctionnelle (découpage en fonctions) 

– 3 Estimation des charges de développement de chaque fonction 

et/ou module 

– 4 Estimation de certaines charges additionnelles, si elles sont omises 

dans la modélisation fonctionnelle. 

– 5 Cumul des charges pour obtenir la charge projet brute 

– 6 Application de facteurs correcteurs pour obtenir la charge projet nette 

– 7 Détermination des délais et calendriers de développement 

– 8 Analyse des risques projet Recommandé 

– 9 Analyse de la valeur (nécessite l’estimation des charges et coûts 

additionnels au développement proprement dit : infrastructure, 

déploiement, exploitation, formation, support, ..). Optionnel 



Page 11


• Remarques 

– Les étapes 1 à 7 constituent l ’estimation des charges et 

délais de développement (les tâches MOE, de la conception 

à l ’intégration) 

– L ’étape 8 est le plus souvent sous responsabilité conjointe 

MOA/MOE 

– L ’étape 9 est toujours sous responsabilité MOA 

⇒ L ’étape fondamentale est celle de modélisation (étape 

2), car elle est complètement structurante pour 

l ’identification des modules à développer. 



Page 12

• Généralités 

Ratios de productivité (1/4) 

– Une difficulté importante consiste à utiliser le bon ratio de 

productivité (étape 3 pour obtenir les h.j bruts). Ce ratio peut 

varier dans un rapport de 1 à 15 (ou plus), et est décroissant 

par rapport à la taille et à la complexité. 

– Dans le modèle COCOMO, l ’estimation de charge est 

donnée par : 

effort = A (KLS) b , où A et B sont des « constantes » 

KLS = taille en K.lignes source 

A croit avec la complexité 

B est un facteur d ’échelle (1,05-1,2) 

⇒ Dans la pratique, on utilise des formule simplifiées 

linéaire dans une fourchette de taille et complexité 

connues 



Page 13

Courbe de productivité 


Productivité 

Complexité 

Taille 



Page 14


Ratios de productivité COCOMO 

Type 

S 

P 

E 

FT 

Rappel de la 

définition 

Programme à 

spécification 

connue 

Nature combinatoire 

et optimisations 

spécifiques 

Gestion 

d’événements 

Tolérance aux 

fautes 

Productivité 

en KLS par 

an 

Pourcentage de 

Conception, 

Codage + tests 

unitaires, Intégration 

4 40/40/20 

2 40/30/30 

1 45/20/35 

0,25 40/10/50 



Page 15


• Ratios de productivité pour points de fonctions 

– Les ratios de productivité utilisées dans les estimations en 

points de fonctions sont souvent exprimées en PF/h.j 

– Dans la pratique on va de 0,2 PF/h.j (grands projets 

complexes) à 3 PF/h.j (petits projets sur PC). 

• Utilisation des facteurs d ’ajustement 

– Des facteurs d ’ajustement peuvent être utilisés avec 

COCOMO (5 facteurs) ou les points de fonction (14 facteurs). 

Dans la pratique, on applique souvent un facteur 

d ’ajustement global à la charge nominale brute pour obtenir 

la charge nette. 



Page 16

Charges additionnelles 

• Dans l ’estimation, on doit comptabiliser toutes les 

activités, mais ne les compter qu ’une seule fois. 

• En particulier, le ratio de productivité inclut une valeur 

moyenne pour l ’activité de management projet MOE. 

Cependant dans certains cas, on considèrera des 

charge complémentaires, non incluses dans la 

productivité moyenne. Par exemple : 

– Activités liées à l ’amélioration de la qualité (CMM, ..) 

– Activités d ’assistance à la MOA (support aux pilotes, support 

au déploiement) 

• Les charges MOA elles mêmes sont toujours 

comptées séparément. Elles ne sont pas 

négligeables (couramment supérieures à 20%). 



Page 17

Estimation et suivi des délais 

de développement (1/2) 

• Estimation du délai nominal 

– Par référence au modèle COCOMO, on calcule souvent une 

valeur du délai de développement dite « nominale », qui est 

plutôt interprétée comme le « minimum raisonnable ». Une 

formule couramment utilisée est : 

» Effort en h.mois 

» Délai en mois 

• Délai planifié 

Délai nominal = 2,5 (Effort) 0,38 

– Pour déterminer le délai planifié (et le calendrier), on tient 

compte des contraintes du projet. Par exemples certaines 

activités doivent être sérialisées, ou ont une date butée. 



Page 18

Estimation et suivi des délais 

de développement (2/2) 

• Phénomène de dérive du calendrier 

– Le phénomène de dérive du calendrier de développement 

est parmi les plus fréquents problèmes de gestion de projet. 

Sa détection se fait à travers des outils de suivi du type 

« Tableau de bord » 

– Le syndrome classiques : 

» Question : Quel est l ’état d ’avancement de l ’activité X ? 

» Réponse : Il est terminé à 80% 

» Même question 1, 2, 3 ..mois plus tard 

» Même réponse 

– Comment éviter les dérive 

⇒ L ’analyse des risques projet permet d ’anticiper les 

problèmes, et d ’apporter les mesures correctives, 

éliminant ainsi les causes de dérive. 



Page 19

• Durée de vie totale d ’un SI 

Coût total de possession (1/4) 

– Après développement et mise en service du SI, celui ci va vivre, recevoir des nouvelles 

fonctions (maintenance applicative), recevoir des corrections d ’erreurs (maintenance 

corrective), être supporté (fonction support), et finalement après obsolescence, il sera 

« démonté » et retiré du service. Pour les systèmes actuels, malgré l ’accélération des 

introductions de nouvelles technologies, la durée de vie d ’un système est souvent d ’au 

moins 5 ans (durée amortissement comptable). 

– Rappel du cycle de vie nominal (ISO 1207) 

Développement 

Pilote 

Maintenance 

Fin de vie 

Expression 

de besoins 

Déploiement 

Utilisation 



Page 20

• Pourquoi un coût total de possession 


– Dans la plupart des projets de SI, on distingue les coûts de développement, 

qui sont dépensés de façon non-récurrente durant les phases de 

conception/développement/déploiement, des coûts de fonctionnement, qui 

sont de nature récurrente, durant la durée de vie du système. Pour comparer 

réellement des alternatives d ’architecture, il faut alors comparer les coûts 

totaux sur une période significative. On prend souvent 5 ans qui correspond 

aussi à la durée d ’amortissement comptable. 

• Modèles d ’estimation des charges et coûts 

– Pour faire l ’estimation du coût total, on utilise en général les modèles 

d ’estimation suivants: 

» Conception/Développement: COCOMO, Points de fonction 

» Déploiement: métrique basée sur le nombre de sites à déployer. 

• Cas particulier des coûts de migration qui peuvent être très importants et/ou entachés 

d ’incertitude. 

» Fonctionnement: métrique basée sur les utilisateurs (nombre), l ’architecture 

(nombre et nature des sites à administre), les volumétries (flux réseau en 

particulier). 



Page 21


• Exemples de postes de coûts de fonctionnement (récurrents) 

– Maintenance applicative 

– Maintenance Systèmes 

– Support utilisateurs (1er et 2e niveau) 

– Exploitation (ou hébergement) et administration des systèmes 

– Télécommunications (abonnements et volumes transportés) 

• Impact de l ’architecture sur les coûts 

– L ’architecture, en particulier s ’il s ’agit d ’architecture client/serveur, peut être 

très structurante pour les coûts, y compris sur les coûts de fonctionnement 

(administration, réseaux). 

– Dans l ’exemple réel suivant, des duplications journalières de référentiels de 

données vers des serveurs régionaux conduisent à des volumes transférés sur 

les lignes de télécommunication très importants, avec les coûts 

correspondants. Dans ce genre de situation, l ’architecture pourrait être revue 

pour diminuer les transferts (par exemple par gestion incrémentale des 

référentiels de données). Il s ’agit donc de procéder à une véritable ingénierie 

des coûts. 



Page 22


• Exemple de bilan économique d ’un projet avec serveurs 

régionaux 

– Les chiffres suivants sont ceux d ’un projet réel de développement/déploiement d ’un 

système d ’information sur 25 serveurs régionaux et 1000 postes de travail (architecture 

client/serveur). 

Poste de coût Coût Total 

Matériel 


Déploiement 

45 MF 

30 MF 

5 MF 

Total non récurrents 

80 MF 

Maintenance sur 5 ans 15 MF 

Support sur 5 ans 10 MF 

Exploitation sur 5 ans 20 MF 

Télécom. Sur 5 ans 40 MF 

Total récurrents sur 5 ans 

85 MF 

Grand total 

165 MF 



Page 23

ETUDES DE CAS 



Page 24

• Tableau des cas étudiés 

Typologie à travers 3 cas 

Projet moyen 

Effort = 1-10 

h.ans 

Grand projet 

Effort = 10-100 

h.ans 

Très grand 

projet 

Effort > 100 

h.ans 

Modèle 

d’estimation 

Applications de 

gestion 

STARTALERT 

Supervision de 

trafic et diffusion 

d’alertes 

GESTMAT 

Maintenance 

d’équipements 

matériels 

Applications 

techniques 

Intégration de 

systèmes 

GROUPWORK 

Système intégré 

de travail 

coopératif sur 

objets complexes 

Points de fonction COCOMO Points de fonctions 

+ COCOMO 



Page 25

Récapitulatif des charges 

et délais 

Projet étudié Caractéristiques projet Charge 

nette de 

développe 

ment 

STARTALERT 

GESTMAT 

GROUPWORK 

Métho. Objet 

JAVA 

Archi. N-tiers 

Métho. MERISE 

AGL = UNIFACE 

Archi. Distribuée 

Objets complexes 

IHM graphiques et 

cartographiques 

Goupware/CORBA 

Progr. C++ 

Délai de 

développement 

68 h.mois Nominal : 10 mois 

Projet non lancé 

321 h.mois Nominal : 1,7 ans 

Planifié : 2 ans 

Réel après retard : 3 

ans 

150 h.ans Nominal : 2,6 ans 

Planifié : 3 ans 

Réel : 3 ans 

Ratio de 

productivité 

PF : 

0,5 PF/h.j 

PF : 

0,4 PF/h.j 

PF : 

0,255 PF/h.j 

COCOMO : 

1,7 KLS/h.an 



Page 26

GESTMAT - Etape 1/Cadrage 

• GESTMAT est un grand projet de gestion 

– GESTMAT concerne la base de données de référence et les 

processus fondamentaux pour la maintenance des matériels 

fixes d ’une grande entreprise de transport. 

– Le nombre maximum d ’utilisateurs est 2000 répartis en 

France, suivant une structure organisationnelle hiérarchisée : 

centrale, régionale, locale. 

– Au moment où l ’estimation est faite (début de conception 

générale), l ’architecture distribuée cible n ’est pas encore 

arrêtée : le choix pourrait être entre client/serveur classique 

et client léger. 

– Il existe une très forte contrainte de migration de bases de 

données et applications existantes. 

– La réalisation est d ’emblée envisagée en plusieurs phases 

fonctionnelles. 



Page 27

GESTMAT - Etape 2/Modélisation 

• GESTMAT suit un cycle de vie de type MERISE 

– L ’estimation par les points de fonction a été réalisée 

classiquement à partir du MCD (Modèle Conceptuel de 

Données) et du MOT (Modèle Organisationnel de 

Traitements). 

– La représentation « Entités-Relations-Attributs » du MCD est 

bien adaptée à l ’identification des Groupes de Données 

internes et externes. 

– Pour l ’identification et le comptage des traitements, le MOT 

donne le bon niveau de détails : 

» Les entrées sont les transactions de mise à jour spécialisées 

(création, modification, suppression) pour chaque type d ’entité. 

» Les sorties sont les états et visualisation avec calcul, ainsi que 

les interfaces en sortie 

» Les Interrogations sont les transactions de consultation et les 

listes. 



Page 28

GESTMAT - Etape 3/Estimation 

(1/4 Données internes) 

Groupe de 

données 

Poids 

Groupe de 

données 

Poids 

Groupe de 

données 

Poids 

Coeur Simple Appareil de 

signalisation 

Simple Sous-station Simple 

Découpage Simple Signal Simple Ouvrage d’art Complexe 

Installation 

affectée 

Simple 

Fonction AS en 

voie 

Simple PN Complexe 

Comptages Simple Poste Simple Canton Simple 

Point voie Simple CTV Simple Transfo Simple 

Accès Simple Châssis Simple Câble Simple 

Noeud T, X, Y Simple Constituant Simple Ouvrage en terre Complexe 

Quai Simple Fonction sur 1 

châssis 

Simple Cellule Simple 

Requête 

Simple 



Page 29


(2/4 Données externes) 

Groupe de données Poids Groupe de données Poids 

Ligne Complexe Spécialité Simple 

Voie Complexe Installation générique Complexe 

SAF Simple Structure de compétence Complexe 

Installation 

Simple 

Compétence 

Moyen 

Segment de gestion 

Moyen 



Page 30


(3/4 Traitements) 

Poids notés x-y avec x=(Entrée, Sortie, Interrogation) et y=(Simple, Moyen, Complexe) 

Traitements Poids Traitements Poids Traitements Poids 

Gestion des 

installations 

Gestion des 

coeurs 

Intégrité 

GESTGEO 

Intégrité interne 

Interrogation 

« mono 

installation » 

Interrogation 

« multi 

installations » 

Gestion des 

requêtes 

Accès GESTGEO 

+autres accès 

10x3 E-C 

Compléments 

gestion des 

installations 

8x3 E-C 

Compléments 

gestion des 

installations 

4 E-C Gestion des AS 4x E-C Compléments 

interrogation 

mono 

E-C 

+ S-C 

E-C 

+ S-C 

50 I-M 

10 I-C 

3 E-S 

+ 2 I-S 

+ E-C 

+ S-C 

9 I-C 

Compléments 

interrogation 

mono 

Compléments 

interrogation multi 

40 I-M Compléments 

interrogation multi 

8x3 E-C 

35 I-M 

7 I-C 

8 I-C Purge E-C 



Page 31


(4/4 Récapitulatif) 

Simple Moyen Complexe 

Données internes 24x7 0x10 3x15 213 

Données externes 3x5 2x7 4x10 69 

Entrées 3x3 0x4 90x6 549 

Sorties 0x4 0x5 3x7 21 

Interrogations 2x3 125x4 34x6 710 

Total 1562 



Page 32

GESTMAT - Etape 4/Charges 

additionnelles 

• Développement d ’un prototype 

– Dans le cas de GESTMAT, le prototype sert à valider 

l ’ergonomie générale. Sa charge de développement est 

estimée (par analogie avec d ’autres projets) à 40 h.jours. 

• Outils de reprise et migration 

– Une stratégie de migration de type « BIGBANG » est 

envisagée. La charge globale de développement des outils 

de reprise est estimée (par analogie avec d ’autres projets) à 

500 PF. 



Page 33


projet brute 

• A ce niveau de l ’estimation, on obtient les comptages 

bruts suivants : 

– Application GESTMAT : 1562 PF 

» Remarque : Le ratio PF données/PF total =(213+69)/1562=18% 

est assez classique en gestion 

– Outils de reprise 500 PF 

– Prototype : 40 h.j 



Page 34

GESTMAT - Etape 6/Charge nette 

• Facteurs correcteurs 

– Les 14 facteurs correcteurs théoriques ne sont pas 

utilisés. Néanmoins, par analogie avec d ’autres grands 

projets déjà réalisés, on admet une expansion 

fonctionnelle de 30% d ’ici la fin de réalisation. 

• Facteur de productivité 

– Les autres projets réalisés du même type ont permis de 

mesurer a posteriori un facteur de productivité de 0,40 

PF/h.j. Ce chiffre est donc pris comme facteur de 

productivité. 

• Charge nette 

– GESTMAT : (1562x1,3)/0,4 = 5075 h.j 

– Outils de reprise : (500x1,3)/0,4 = 1625 h.j 

– Prototype : 40 h.j 

– Soit un total de 5866/21 = 321 h.mois 



Page 35

GESTMAT - Etape 7/Délais 

• Délai nominal 

– Les outils de reprise sont développés en parallèle. Le délai 

optimal est donc calculé comme : 2,5x(239) 0,38 = 20 mois 

• Délai planifié 

– Par ailleurs, l ’objectif de délai est de 24 mois. Le plan projet 

est donc aligné sur ce chiffre. 

• Délai réel 

– Voir étape 8 



Page 36

GESTMAT - Etape 8/Analyse de 

risques 

• Conséquence d ’une non prise en compte des risques 

– Un risque élevé lié à l ’incertitude sur l ’architecture technique 

cible avait été identifié très tôt. En fait, les aspects 

d ’architecture, de performance réseau, de volumétrie ont 

tardé à être abordés et les choix n ’ont pu être faits à temps. 

… En bref, un exemple classique de sous estimation des 

aspects non fonctionnels. 

– Finalement, la prise en compte tardive de l ’architecture a fini 

par provoquer un retard de 6 mois sur le début de conception 

détaillée, puis une dérive permanente s ’est installée. Six 

mois ont de nouveau été perdus. 

– Après stabilisation du retard et redémarrage du projet, le 

délai global s ’est finalement établi à 3 ans au lieu de 2. 



Page 37

GESTMAT - Etape 9/Analyse de la valeur 

• Une analyse du coût total de possession sur 5 ans a été effectuée 

par le responsable maîtrise d ’ouvrage. 

– Les chiffres suivants font apparaître le poids relatif très important des coûts de 

télécommunication du développement (40/165 = 25%) par rapport au coût total sur 5 

ans. 

Poste de coût Coût Total 

Matériel 


Déploiement 

Total non récurrents 

Maintenance sur 5 ans 

Support sur 5 ans 

Exploitation sur 5 ans 

Télécom. Sur 5 ans 

Total récurrents sur 5 ans 

Grand total 

45 MF 

30 MF 

5 MF 

15 MF 

10 MF 

20 MF 

40 MF 

80 MF 

85 MF 

165 MF 



Page 38

STARTALERT - Etape 1/Cadrage 

• STARTALERT est un système qui collecte des 

informations (y compris des alertes) de trafic 

maritime venant de plusieurs sources, les stocke, 

et les rediffuse vers des organisations abonnées. 

• Certaines des informations se présentent comme 

des messages venant de messageries classiques, 

alors que d ’autres proviennent de collectes 

automatiques. 

• L ’estimation est faite à partir d ’un cahier des 

charges d ’appel d ’offre (CCTP), en vue de 

produire une proposition commerciale de 

réalisation au forfait. 

• La proposition a finalement été rejetée par le client, 

car jugée trop chère. 



Page 39

STARTALERT - Etape 2/Modelisation 

• Le cahier des charges fonctionnel (CCTP) contient 

une description précise des messages à traiter. 

• Dans la mesure, où dans la première phase du 

projet, il n ’y a pas de traduction de formats à faire, 

la modélisation se simplifie, car finalement, la 

complexité des données est portée directement 

dans la définition des « messages à plat » 

(messages POLREP, SITEREP …). 

• Par compte, pour la complexité fonctionnelle des 

traitements (en gros un écran = un traitement), il 

faut faire une analyse fine pour les dériver à partir 

des descriptions plutôt conceptuelles du CCTP 

(concepts d ’émission, réception, transmission, 

notification,interrogation, consultation ..). 



Page 40

STARTALERT - Etape 3/Estimation 

(1/5 données internes) 

Groupe de données internes Nombre de champs Complexité 

Identification du contrôle 14 F 

Port 7 F 

Navire 11 F 

Voyage 30 F 

Matière Dangereuse (MD) 23 F 

Situation (infos SITREP) 13 F 

Inspection 9 F 

Pollution 9 F 

Déchet 9 F 

Pedigree navire 8 F 

Compte rendu 2 F 

Total 11*F 



Page 41


(2/5 données externes) 

Donnée externe Nombre de champs Complexité 

Base « Manifeste des matières 

dangereuses » 

Déjà compté 

en GDI 

Base Navire 24 F 

Annuaire « autorité » 24 F 

Total 2*F 

Soit un total pour les données internes/externes de 13*F = 13*7 = 91 PF 

A ce niveau de granularité, on prend une marge de 20%^pour tenir compte des oublis. 

Soit 91*1.2 = 110 PF de données 



Page 42


(3/5 traitements d ’entrée ) 

Les traitements d ’entrée sont essentiellement les messages en émission/réception tels que 

définis par le CCTP (questionnaires de saisie et traducteurs). 

On admet que les 40 messages de poids moyen suivants englobent les charges de 

développement d ’un éditeur et traducteur simples. 

Acteurs Message Commentaire Complexité 

Autorités MOUV M 

MOUV INF 

Traduction automatique 

par IED 

M 

CROSS 

6 messages dont certains à 

champs optionnels. 

Reserve pour 20 

messages potentiels 

20*M 

Procès Verbal 

M 

CROSS 

Prévision 

M 

Ports 

Départ 

2*M 

Arrivée 

SafeSeaNet Réserve pour 14 

messages 

14*M 

Total 40*M 



Page 43


(4/5 autres traitements ) 

Sorties 

Au sens des points de fonction, les sorties sont les messages de notification et certaines 

retransmission avec traduction. 

Sans autres approfondissements, supposons une vingtaine de messages de notification de 

complexité moyenne. 

Soit 20*5 = 100 PF 

Interrogations 

les interrogations et consultations sont décrites dans le CCTP, avec des exigences 

spécifiques sur filtrages et fonctions du requêteur. 

En première approximation, on suppose une complexité équivalente à une trentaine 

d ’interrogations complexes. 

Soit 30*6 = 180 PF 

Administration/Supervision 

L ’acteur principal pour ces traitements est l ’administrateur. 

On fait une hypothèse globale de 50 PF pour ces traitements 

Statistiques 

Les statistiques représentent une douzaine d ’états complexes. 

Soit 12*7 = 84 PF 



Page 44


(5/5 Récapitulatif ) 

Domaine Poids en PF Commentaire 

Données 110 

Entrées 160 

Sorties 100 

Interrogations 180 

Administration 134 

Total 

684 PF 



Page 45

STARTALERT -Etapes 4 -5 -6 -7 

• Etape 4 - Charges additionnelles 

– A priori pas de charges additionnelles détectées dans le CCTP 

• Etape 5 - Estimation projet brute 

– On obtient donc le comptage brut de : 684 PF 

• Etape 6 - Charge nette 

– Par analogies avec d ’autres projets développés par la même 

équipe (méthodes objet, JAVA, développeurs expérimentés), 

on admet un facteur de productivité de 0,5 PF/h.j. 

– Soit une charge de 684/0,5 = 1368 h.j = 68,4 h.m 

• Etape 7 - Délai nominal 

– Le délai nominal sur la phase de développement sera donc : 

» Dnom = 2,5*(68,4) 0,33 = 10 mois 



Page 46

STARTALERT - Etape 8/Analyse de 

risques (1/2) 

• Risques liés à l ’estimation en avant vente 

– Pour un projet en avant-vente, on pourrait distinguer deux 

types d’analyse de risques. La première considère les risques 

de ne pas remporter l’affaire, alors que la deuxième considère 

l’affaire remportée, le projet lancé, et veut identifier et anticiper 

les risques durant la réalisation du projet. 

– Les deux analyses sont complémentaires. En particulier, si on 

baisse le prix de la proposition à périmètre constant pour 

diminuer le risque de ne pas être sélectionné, on augmente le 

risque financier sur le projet de réalisation. 

– De toutes manière, même en avant-vente, il est intéressant 

d’anticiper au maximum sur les risques du projet de réalisation 

de façon à négocier en vue de la meilleure contractualisation 

possible. 



Page 47

STARTALERT - Etape 8/Analyse 

de risques (2/2) 

• Ce qui s ’est passé !! 

– Pour couvrir le risque de sous-estimation sur ce projet au 

forfait, la proposition au client a été faite avec un coefficient de 

marge de 2 soit 140 h.mois …. Avec le même calendrier de 10 

mois. 

» Le risque était réel car les développements liés à la traduction 

des messages (par exemple en XML) n ’étaient pas bien définis 

dans le CCTP 

– Mais finalement, le client a confié le projet à une autre SSII, qui 

proposait un devis plus réduit. 

» Les exigences clients ont semble-t-il été réduites ultérieurement, 

et le système réalisé a plutôt été un prototype qu ’un système 

complètement opérationnel. 



Page 48

PRATIQUE DE L ’ESTIMATION DES COUTS DE PROJETS DE SI

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?