Vous êtes sur la page 1sur 15

Estimation des projets informatiques

Estimation des charges :


méthode COCOMO
I- Introduction

L’estimation des projets informatiques est l’une des plus importantes activités du
développement de logiciels. La planification rigoureuse et le pilotage du projet ne sont pas
envisageables en absence d’une estimation sérieuse et fiable. En règle générale, l’industrie du
logiciel ne sait pas estimer correctement les projets et n’utilise pas convenablement les estimations.
Nous souffrons de ces conséquences et nous devons focaliser nos efforts sur l’amélioration de la
situation.

La sous-estimation d’un projet entraîne :

 Un sous-effectif, provoquant la surchauffe de l’équipe ;


 Une sous-appréciation de la charge d’assurance qualité, avec le risque de livrables de
médiocre qualité ;
 L’établissement d’un planning trop serré, qui dégradera votre crédibilité, lorsque ces
délais présomptueux sont largement dépassés.

Pour ceux qui pensent éviter cette situation en gonflant l’estimation, la surestimation d’un
projet peut s’avérer aussi néfaste pour l’Organisme. Si vous accordez à un projet plus de ressources
que nécessaires sans contrôler l’utilisation de ces ressources, le projet :

 Coûtera beaucoup plus cher (en grevant le bilan du projet) ;


 Durera plus longtemps que nécessaire (en manquant les opportunités ciblées) ;
 Diffèrera la disponibilité de vos ressources pour le prochain projet.

II- Généralités

L’estimation d’un projet informatique comprend quatre étapes :


 Estimer la taille du produit à développer :

Celle-ci se mesure généralement en nombre d’instructions (lignes de code) ou en points de


fonction, mais il existe d’autres unités de mesure possibles.

 Estimer la charge en mois-hommes ou en jours-hommes.


 Construire le calendrier du planning.
 Estimer le coût du projet en monnaie locale.
1. Estimation de la taille :

Le premier stade d’une opération d’estimation consiste à estimer, le plus précisément


possible, la taille du logiciel à développer. Les sources d’information, relatives au périmètre du
projet, naissent avec une description formelle des besoins (spécification des besoins des clients,
appel d’offres, spécification du système, spécification des exigences du logiciel).

Lors de la ré estimation du projet dans les phases ultérieures du cycle de vie, les documents
de conception vous fourniront des détails additionnels.

Les deux principaux moyens d’estimation de la taille de l’ouvrage sont :

a) L’analogie :

Si vous avez déjà fait un projet similaire dont vous connaissez la taille, vous estimerez chaque
partie principale du nouveau projet comme un pourcentage de la taille de la partie similaire du
précédent projet. Vous estimerez la taille totale d’un nouveau projet en cumulant les estimations
des tailles de toutes les parties. Un estimateur chevronné peut produire des estimations
convenables, par analogie, s’il connaît les valeurs précises des tailles des parties d’un projet
précédent et si le nouveau projet est suffisamment voisin de ce précédent.

b) La comptabilisation des caractéristiques quantitatives de l’ouvrage :

On peut utiliser une approche algorithmique telle que celle des points de fonction pour convertir le
total en une mesure de la taille.

2. Estimation de la charge :

Après avoir estimé la taille de l’ouvrage à produire, vous pouvez en déduire l’estimation de
la charge. Cette conversion de la taille du logiciel en charge totale du projet ne peut s’envisager
qu’après définition d’un cycle de vie de développement du logiciel et définition d’un processus de
développement de la solution pour spécifier, concevoir, réaliser et tester le logiciel.

Il existe deux manières de déduire la charge à partir de la taille :

a) La meilleure façon est d’utiliser l’historique de votre Organisme pour recenser les
charges réelles consommées par les précédents projets pour réaliser les ouvrages. Ceci suppose
évidemment :
 Que votre Organisme ait documenté les résultats réels des précédents projets ;
 Que vous ayez réalisé, au moins, un projet de taille équivalente - disposer de
plusieurs projets de taille équivalente, renforce la conviction qu’il existe une
relation stable entre la taille d’un ouvrage et la charge nécessaire à sa réalisation
;
 Que vous suivez un cycle de vie de développement similaire en utilisant la même
méthodologie et les mêmes outils, grâce à une équipe qui possède les mêmes
compétences et les mêmes expériences.
b) Il se peut que vous ne disposiez pas d’un historique utilisable, parce que votre
Organisme n’a pas encore commencé à le constituer ou parce que ce nouveau projet est nettement
différent des précédents sur un ou plusieurs aspects fondamentaux. Vous pouvez appliquer une
approche algorithmique reconnue telle :
 La méthode Delphi
 La méthode de la répartition proportionnelle
 La méthode d'évaluation analytique
 La méthode COCOMO
 La méthode des points fonctionnels

Ces modèles ont été élaborés en étudiant un nombre significatif de projets terminés par divers
Organismes, pour en extraire la relation entre les tailles et les charges. Ces modèles, issus des
données de l’industrie du logiciel, peuvent ne pas être aussi précis que ceux de votre historique,
mais ils vous donneront, toutefois, une première approche des estimations de charges.

3. Estimation des délais :


La troisième étape de l’estimation consiste à déterminer les délais à partir de la charge
estimée. Ce qui implique généralement d’estimer les ressources affectées au projet (la Structure de
Contribution) ce qu’elles devront faire (le WBS – Work Breakdown Structure – Organigramme
des Tâches) quand elles commenceront à travailler au projet et quand elles le termineront. Lorsque
vous aurez ces informations, vous devez planifier les tâches. À nouveau, les historiques des projets
passés, réalisés par votre Organisme ou, à défaut, des modèles classiques, peuvent être utilisés pour
déterminer le nombre de personnes dont vous aurez besoin pour un projet d’une taille donnée et
pour ordonnancer ces travaux.

4. Estimation du coût :

Il faut prendre en compte de nombreux facteurs pour estimer le coût total d’un projet. Ces
facteurs incluent les charges des travaux, les acquisitions ou les locations de matériels et de
logiciels, les frais de déplacements (réunions et essais) les télécommunications (appels à longue
distance, vidéoconférences, lignes dédiées aux tests, etc.) les formations, les frais de locaux etc.

L’estimation exacte du coût total du projet dépend de la façon dont votre Organisme affecte
les coûts. Au lieu d’être affectés aux projets, certains coûts peuvent être pris en compte en les
intégrant dans les taux horaires (en FCFA par heure). Souvent, un Directeur de projet estimera
seulement le coût du travail et n’identifiera que les coûts additionnels qui ne sont pas considérés,
par l’Organisme, comme des frais généraux.

Le coût du travail peut être obtenu en multipliant, simplement, l’estimation de charge en


heures par un taux en FCFA par heure. Un calcul plus précis de coût de la charge résulte de
l’utilisation d’un taux pour chaque catégorie de personnel (technicien, qualiticien, encadrement,
documentation, support, etc.). Vous devrez déterminer quel pourcentage de la charge totale du
projet doit être affecté à chaque profil. À nouveau, les données historiques ou des modèles
classiques peuvent apporter une aide.

III- Méthode COCOMO (COnstructive COst Model)


1. Définition :
COnstructive COst Model (modèle des constructions des couts en français) est une méthode
pour estimer le coût d'un projet logiciel dans le but d'éviter les erreurs de budget et les retards de
livraison, qui sont malheureusement habituels dans l'industrie de développement logiciel.

Le premier modèle COCOMO date de 1981, elle a été développée par Dr. Barry Boehm pour
:

 Estimer l'effort
 Estimer la durée
 Estimer l’effectif
 Estimer la productivité de développement d'un produit logiciel.

Aujourd'hui, COCOMO II est un nouveau produit beaucoup plus adapté à l'aspect réutilisation des
composants (modules existants). La version 1998 a été calibrée sur 161 points de données, en
utilisant l'approche statistique 'Bayesian' pour combiner les données empiriques avec les avis
experts. De plus elle peut être re-calibrée sur les données de l'entreprise.

Cette méthode, qui ne s'applique qu'à l'étape de réalisation, suppose l'existence d'une corrélation
entre la taille (en instructions source) d'un programme et la charge consommée.

2. Principe :

Le modèle COCOMO 81 est en fait constitué de trois modèles :

 Le modèle de base : petit projet


 Le modèle intermédiaire : projet de taille moyenne
 Le Modèle expert « détaillé » : grand projet

Pour chaque modèle, on a 3 modes de développement :

 Mode organique (S) : petite équipe expérimentée et environnement familier (traitement


classique).
 Mode semi-détaché (P) : équipe assez expérimentée, environnement connu.
 Mode imbriqué (E) : projet à contraintes serrées, dues à l'environnement ou une certaine
nouveauté de l'application (temps réel, ...)
Type Taille Description
Organique < 50 KLOC projets simples menés avec de
petites équipes
Médian (Semi-détaché) < 300 KLOC projets intermédiaires menés
avec
des équipes mixtes
Imbriqué > 300 KLOC Projets complexes devant
obéir à
des ensembles de contraintes

KLOC représente le nombre, en milliers, de lignes de code (LOC = Lines Of Code) ; en fait il
s'agit du nombre d'instructions source.

2.1. Modèle de base :

Il faut identifier le mode de développement : organique, médian ou imbriqué. Le résultat s'exprime


par la formule suivante dans le modèle de base Cocomo81 :

= ∗( ) En hommes-mois

= 2.5 ∗ ( ) En mois (Le délais)

Boehem a déterminé les valeurs a, b et c à partir des résultats d’analyse statistique sur un échantillon
significatif de projets :

Type a b c
Organique 2.4 1.05 0.38
Médian (Semi-détaché) 3.0 1.12 0.35
Imbriqué 3.6 1.20 0.32

L’effort et le délai sont donnés dans le tableau suivant :

Type Effort Délais


. .
Organique = 2.4 ∗ ( ) = 2.5 ∗ ( )
. .
Médian (Semi-détaché) =3∗( ) = 2.5 ∗ ( )
. .
Imbriqué = 3.6 ∗ ( ) = 2.5 ∗ ( )

Exemple1:
Soit un projet estimé à 32000 lignes de code.

Effort ?

.
 Effort = Charge = 2.4 ∗ (32) = 91hm
Temps de développement ?
.
 TDEV = Délais = 2.5 ∗ (91) = 14mois
Productivité ?
( )
 Productivité = = = 352

Nombre Moyen de personnel ?

 Taille de l’équipe = = = 7 Personnes.

2.2. Le modèle intermédiaire :

Le modèle intermédiaire Cocomo 81 est plus élaboré et prend en compte des facteurs d'ajustement
intégrant les conditions de développement. L'équation donnant la charge est alors :

= ∗( )∗( ) En homme-mois

On utilise des directeurs de coûts. On a 15 modèles en plus par rapport modèle de base. On définit
l’effort ajusté EAF par :

= ∏ , Ci étant le facteur d’ajustement du modèle i.

EAF (Effort Adjustment Factor) est le facteur d’ajustement qui vaut 1 dans le modèle de base, est
calculé à partir de 15 critères regroupés en 4 catégories :

 Produit (logiciel) :
 Fiabilité requise (RELY),
 Taille de la base de données (DATA),
 Complexité globale (CPLX).
 Ordinateur (Matériel) :
 Temps d'exécution (TIME),
 Mémoire principale (STOR),
 Stabilité de l'environnement (VIRT),
 Interactivité des moyens de développement (TURN).
 Personnel :
 Compétence et cohérence de l'équipe d'analystes (ACAP),
 Expérience du domaine d'application (AEXP),
 Expérience des programmeurs (PCAP),
 Connaissance du système d'exploitation (VEXP),
 Connaissance du langage de programmation (LEXP).
 Projet :
 Utilisation de techniques modernes de développement (MODP),
 Niveau de sophistication des outils de développements (TOOL),
 Délai de mise à disposition (SCED).

Le tableau ci-après donne les valeurs affectées à chaque paramètre suivant son importance. EAF
est le produit de toutes ces valeurs.

Evaluation

Facteurs de Très Bas Nominal Haut Très Extrêmement


productivité bas haut haut

Produit

RELY 0.75 0.88 1.00 1.15 1.40

DATA 0.94 1.00 1.08 1.16

CPLX 1.70 0.85 1.00 1.15 1.30 1.65


Ordinateur

TIME 1.00 1.11 1.30 1.66

STOR 1.00 1.06 1.21 1.56

VIRT 0.87 1.00 1.15 1.30

TURN 0.87 1.00 1.07 1.15

Personnel

ACAP 1.46 1.19 1.00 0.86 0.71

AEXP 1.29 1.13 1.00 0.91 0.82

PCAP 1.42 1.17 1.00 0.86 0.70

VEXP 2.21 1.10 1.00 0.90

LEXP 1.14 1.07 1.000.95

Projet

MODP 1.24 1.10 1.00 0.91 0.82

TOOL 1.24 1.10 1.00 0.91 0.83

SCED 1.23 1.08 1.00 1.04 1.10

Par ailleurs, les valeurs de a, b et c sont données par le tableau ci-dessous :

Type a b c
Organique 3.2 1.05 0.38
Médian (Semi-détaché) 3.0 1.12 0.35
Imbriqué 2.8 1.20 0.32
Exemple :

 RELY : fiabilité requise pour le logiciel


 Projet de 10 KLOC.
 Effort ?

.
Effort nominal = Charge = 3.2 ∗ (10) = 36h-m
Choix du facteur correcteur :

 Très faible fiabilité : Effort = Effort nominal * 0.75= 27 h-m


 Très forte fiabilité : Effort = Effort nominal * 1.4 = 50.4 h-m

Les étapes :

 Identifier le mode du développement


 Estimer le nombre de LOC
 Calculer la charge (effort) en nombre de mois-hommes
 Estimer les 15 facteurs de productivité
 Calculer le facteur d’ajustement (EAF)
 Multiplier l’effort nominal par le facteur d’ajustement.
2.3. Le mode détaillé :

Le modèle expert ou détaillé inclut toutes les caractéristiques du modèle intermédiaire avec
une estimation de l'impact de la conduite des coûts sur chaque étape du cycle de développement :
définition initiale du produit, définition détaillée, codage, intégration. De plus, le projet est analysé
en terme d'une hiérarchie : module, sous système et système. Il permet une véritable gestion de
projet, utile pour de grands projets.

IV- Exercices

Exercice 1 :
En appliquant la méthode COCOMO estimer la taille moyenne de l'équipe qui faudrait
prévoir pour développer un logiciel estimé à environ 40 000 instructions sources (LOC),
le projet est simple et l’équipe du développement est relativement réduite.

Exercice 2 :

Soit à développer un logiciel de gestion d’un système de gestion de manutention dans un


atelier d’assemblage de voiture (ateliers flexibles). Le système logiciel doit fonctionner
sous des contraintes particulièrement fortes. Le système à développer est une partie d'un
système complexe et fortement connecté de matériels et de logiciels se trouvant dans
l’atelier entre autre le système de pilotage des robots. Des normes et des procédures
opérationnelles surtout de sécurité doivent être prises en compte. En conséquence, les
modifications de spécifications destinées à contourner des problèmes logiciels sont en
général impossibles et les coûts de validation extrêmement élevés.

Nous avons calculé les PF (Points de Fonction) de ce système. Cette tâche de comptage nous
a coûté 2 jours
de travail (5 heures/jour) ; la productivité de l’équipe d’estimation était de 200
PF/heures. Le système est développé avec les langages C et C++. Admettons qu’un PF
correspond à 65 lignes de code C++ et 85 lignes de code C. On prévoit que 70% du
système serait développé avec C++.

Les consignes données par les responsables de l’atelier sont les suivantes :

 Une défaillance pose de sérieux problème particulièrement de sécurité. Une


défaillance peut mettre en péril la vie humaine.
 Le système fonctionne 16h/j et 65% de la puissance matérielle disponible sera
utilisée.
 La taille de la base de données à utiliser (en octets) est entre 8 à 10 fois le nombre
de lignes sources livrées.

Les conditions de développement se caractérisent par :

 Des outils CASE couvrant l'intégralité du cycle de vie sont disponibles.


 Méthode de programmation moderne, évoluée et expérimentée par l’équipe de
développement.

La complexité du produit est très élevée à cause de traitement parallèle et gestion de


données complexes.

1) Après avoir déterminé le type de projet, calculer l’estimation de l’effort et de la charge


ainsi que la taille moyenne de l’équipe en utilisant COCOMO de base.

2) Identifier les facteurs qui influencent les estimations dans ce projet ainsi que leurs
valeurs respectives (voir tableau ci-dessous).

3) Calculer l’effort, la durée et la taille moyenne de l’équipe de développement en tenant


compte des contraintes et consignes données dans le texte

V- Corrigés

Exercice 1 :

Nous appliquons la méthode COCOMO et nous nous apercevons que c'est un projet
organique. Nous avons donc pour le calcul de l’effort et la durée, les formules suivantes :
.
E = 2.4 ∗ (KLOC)

.
D = 2.5 ∗ E
.
Donc selon la formule de la charge: E = 2.4 ∗ (40) ≈ 115 Personne-Mois
.
D = 2.5 (115) ≈ 15 Mois

Ce qui nous donne: Taille équipe = = ≈ 7.6 soit 8 Personnes.

Exercice 2 :

1) Type de projet :

En examinant les définitions et les caractéristiques suivantes des trois classes de projet :

a) Projets de mode organique : Ces projets sont réalisés par une équipe de taille
relativement petite travaillant dans un environnement familier et dans un domaine
d'application connu de l'équipe. En conséquence, le surcoût dû à la communication est
faible, les membres de l'équipe savent ce qu'ils ont à faire et le font rapidement
b) Projets de mode semi-détaché : Ce mode représente un intermédiaire entre le mode
organique et le mode embarqué décrit ci-dessous. Pour des projets de mode semi-détaché,
l'équipe projet peut être composée de programmeurs de divers niveaux d'expérience. Les
membres de l'équipe ont une expérience limitée de ce type de système. Ils peuvent être
totalement inexpérimentés en ce qui concerne quelques-uns des aspects du système à
développer, mais pas tous.

c) Projets de mode embarqué : La caractéristique principale d'un projet de mode


embarqué est que le système doit fonctionner sous des contraintes particulièrement fortes.
Le système à développer est une partie d'un système complexe et fortement connecté de
matériels et de logiciels, de normes et de procédures opérationnelles. En conséquence, les
modifications de spécifications destinées à contourner des problèmes logiciels sont en
général impossibles et les coûts de validation extrêmement élevées. Du fait de la nature
même de ces projets, il est habituel de disposer d'ingénieurs logiciels expérimentés dans
le domaine d'application.

Nous concluons que le projet est de type embarqué vu sa complexité, ses contraintes
fortes de sécurité et surtout sa forte connexion avec le matériel et les autres systèmes de
l’atelier.

Donc les formules de l’effort et la durée sont les suivantes :

.
E = 3.6 ∗ (KLOC)

.
D = 2.5 ∗ E

Calcul de la taille de projet en PF :

PF =200*5*2=2000 PF

Calcul de la taille de projet en KLOC :

2000 ∗ 0.7 ∗ 65 + 2000 ∗ 0.3 ∗ 85 = 142000 LOC = 142 KLOC

Calcul de l’effort et de la durée :

.
E = 3.6 ∗ (142) = 1377.363 PM
.
D = 2.5 ∗ (1377.363) = 33.728 Mois

Taille moyenne de l’équipe :

= 40.83 (41 Personnes)

2) Les facteurs d’influences selon le texte sont :

RELY = 1.40

DATA = 0.94

CPXL = 1.65

TIME = 1.11

MODP = 0.82

TOOL = 0.83

3) Calcul de l’effort, de la durée et de la taille moyenne de l’équipe (COCOMO


intermédiaire)

E = Enominal ∗ EAF

EAF = ∏ Ci

EAF = RELY ∗ DATA ∗ CLPX ∗ TIME ∗ MODP ∗ TOOL = 1.40 ∗ 0.94 ∗ 1.65 ∗ 1.11 ∗ 0.82 ∗
0.83 = 1.62

E = 1377.363 ∗ 1.62 = 2238.87 Personne-mois

.
D = 2.5 ∗ (2238.87) = 40.17Mois

Taille moyenne de l’équipe :

= 55.7 (56 Personnes)

P (Productivité) :
Taille en KLOC 142 KLOC LOC
= = = 0.06342 = 63.42
Effort 2238.87 PM PM
PM = Personne-mois.

Vous aimerez peut-être aussi