Transcript Projet3 - estimatio..

Gestion de projet
troisième partie : estimation de la
charge, des délais et des coûts
2004-2005
Gestion de projet
PARTIE 1 : Estimation de la charge
Estimation de la charge (1)


La charge de développement est en jour / homme (J.H)
Elle permet ENSUITE d’estimer le coût de réalisation
et le délai en tenant compte des ressources
disponibles.



Un informaticien sait qu'il lui faut ½ journée pour réaliser un écran de
mise à jour d'une table Oracle. Il compte le nombre de tables (30) et en
déduit que le codage des écrans de MAJ prendra 15 J.H. Soit une
charge de 15 J.H
Ce type de codage est fait par des Analyste Programmeurs (AP) qui
coûtent 300 Euros par jour. Le coût de développement des écrans sera
donc de 15*300 = 4 500 Euros.
Si on dispose de 3 AP compétents sur ce domaine, le délai de réalisation
des écrans de MAJ sera de 5 Jours et le coût de développement sera
toujours de 4500.
Les méthodes d’estimation de la
charge





Estimation personnelle
Prévisions d’experts
Homothétie (règle de trois)
Méthode de Parkinson : faire le pari
que les ressources disponibles
suffiront pour mener à bien le projet
Méthodes semi – formelles de
modélisation de la charge
Gestion de projet
Estimation empirique de la charge
1 Identification des modules à réaliser
2 Décomposition de chaque module en programmes
3 Décomposition des programmes en fonctions types
4 Estimation de la charge de développement d'une fonction type
5 Somme en ajoutant la charge d'intégration
Application
Module 1
Prog 1
Prog n
Fonct 1
Fonct n
1 J/H
2 J/H
Module n
Choix d’un modèle




Statique (charge totale)  dynamique
(charge en fonction du temps)
Monovariable (nombres d’instructions) 
multivariable (plusieurs paramètres)
Empirique (expérimental)  théorique
(déductif)
Globale (charge brute)  détaillé
(charges par qualification des ressources)
Quelques modèles d’estimation en
informatique de gestion


COCOMO
Points de fonctions d’Albrecht
COCOMO (Constructive Cost Model)




Mis au point et publié par Barry BOEHM
en 1981
Statique, monovariable, empirique,
global, construit à partir d’un échantillon
de 63 projets de 20 000 à 100 000 lignes
de code
Les étapes couvertes sont l’étude
technique, la programmation, et les tests
Seule variable d’entrée = taille du
programme, exprimée en kilo instructions
(Kisl)
COCOMO (suite)

Charge de travail exprimées en H.M
HM = k (KISL)b
b, voisin de 1, est un coefficient
lié au type de projet
 K est un facteur correctif
composite qui représente les
spécificités du développement

COCOMO (suite)

Trois versions :
1.
2.
3.
De base : utilisation de formules
standards
Intermédiaire : formules selon le type
de programme
Détaillé : introduction de facteurs
correctifs et décomposition en sous projets
COCOMO – facteurs correctifs

Répartis en quatre classes :





Le produit à développer (par exemple : niveau
de fiabilité requis, taille de la base de
données…)
L’environnement matériel de fonctionnement
(contrainte taille mémoire, instabilité machine
virtuelle…)
Le personnel (qualification des analystes,
expérience du langage…)
Les contraintes du projet (respect du planning)
Décrits dans un tableau présentant leur
facteur d’influence : très faible, faible,
moyen, fort, etc.
COCOMO (suite)


Méthode maintenant dépassée
Difficile à utiliser car s’appuie sur une
évaluation de la taille future du logiciel :



Par analogie, expérience, « pifomètre »
Formule de B. Londeix
Utilisation des ratios de C. Jones :
 Appel d’un écran = 10 ISL
 Accès aux données = 20 ISL
 Appel d’une transaction = 5 LS
 Message d’erreur = 5 LS
 Etc.
COCOMO II



En 1998, basé sur l’analyse statistique de 161
projets
Mieux adapté au développement objet et à la
réutilisation des composants
Constitué de 3 modèles




Modèle de composition d'application : modèle utilisé pour
les projets fabriqués à l'aide des toolkits d'outils graphiques.
Il est basé sur les nouveaux 'Object Points'.
Modèle avant projet : Modèle utilisé pour obtenir une
estimation approximative avant de connaître l'architecture
définitive. Il utilise un sous ensemble de facteurs de
productivité (cost drivers). Il est basé sur le nombre de lignes
de code ou les points de fonction non ajustés.
Modèle post-architecture : modèle le plus détaillé de
COCOMO II. A utiliser après le développement de
l'architecture générale du projet. Il utilise des facteurs de
productivité (cost drivers) et des formules. Les facteurs
utilisés sont classés en : Facteurs d'échelle, Urgence,
Flexibilité de développement, résolution
d'architecture/Risque, Cohésion d'équipe et Maturité de
Processus.
Quasi inconnu en Europe, et peu répandu aux EU (Nasa)
Les points de fonction




1979, par Alan Albrecht
Le point de fonction est maintenant
normalisé par l’AFNOR, sous la référence
normative expérimentale XP Z 67-160
Mesure objective de l’œuvre en nombre
de points
Méthode fondée sur une mesure :



Indépendante du langage de programmation
Indépendante de la technologie
Qui « appréhende » la complexité fonctionnelle
du logiciel
Points de fonction (suite)


Recommandations de l’IFPUG (International Function
Points User Group) - 1986
Classification des fonctions selon les types:




Entrées : écrans de saisie, formulaires, bordereaux ;
comptabiliser une entrée par fonctionnalité : création,
modification, suppression
Sorties : écrans de consultations, ou états imprimés
Fichiers logiques internes (entités, associations porteuses
d’attributs et associations N-N, mêmes si elles ne portent
pas d’attributs)
Fichiers d’interface (ou fichiers logiques externes)




Fichiers utilisés par l’application, mais mis à jour par une
autre
Interfaces entre applications, s’appuyant sur des données
ou des messages
Routines d’import et d’export
Interrogations (=1 entrée + 1 sortie) : Pas de mise à jour
de fichiers logiques internes, pas de traitements
spécifiques autres que des extractions de données
Les points de fonction (suite)




Évaluation de la complexité des
fonctions : faible, moyen, fort
Calcul des points de fonction bruts
Prise en compte de facteurs
correctifs
Calculs des points de fonction
ajustés
Exemple de calcul : les fonctions
d’entrée
Nombre de champs en entrée (« attributs » au sens
du modèle Entités - Associations)
Nombre de fichiers
logiques
impliqués dans
le formulaire
ou l’écran de
saisie
1-4
5-15
16 et plus
Faible
Faible
Moyen
Faible
Moyen
Élevé
Moyen
Élevé
Élevé
0 ou 1
2à3
4 et plus
Calcul des points de fonction bruts
Complexité
FLI
FI
ENT
SOR
INT
Nombre
Total par complexité
Totaux
F
___
x
7
=
___
M
___
x
10
=
___
E
___
x
15
=
___
F
___
x
5
=
___
M
___
x
7
=
___
E
___
x
10
=
___
F
___
x
3
=
___
M
___
x
4
=
___
E
___
x
6
=
___
F
___
x
4
=
___
M
___
x
5
=
___
E
___
x
7
=
___
F
___
x
3
=
___
M
___
x
4
=
___
E
___
x
6
=
___
___________
_______
_______
Nombre de points de fonction bruts
=
Critères d’ajustement des points de
fonction




14 facteurs d’ajustement
Pour chaque facteur, note de 0 à 5
Le facteur d’ajustement est égal à
0,65 + (somme des notes / 100)
Nombre de points de fonction
ajustés : PFA = PFB x FA
Calcul de la charge

L’effort dépend du nombre de HM
par point de fonction






Meilleurs projets RAD => 200 PFA / HM
Projets RAD courants => 100 PFA / HM
Projets L4G courants => 35 PFA / HM
Projets L3G courants => 15 PFA / HM
Projets COBOL => 8 PFA / HM
Grands projets gouvernementaux = >
2 PFA / HM
Gestion de projet
Partie 2 : estimation des délais
Relation entre la charge et le délai





Le délai est une fonction de l’effort : D =
F(E)
Selon modèle COCOMO par ex. : Délai =
2,5 * (Charge)0,35
Pour une charge donnée, il existe une
plage de faisabilité
En deçà, le risque d’échec est certain par
impossibilité de coordonner les ressources
nécessaires
Au delà, le risque de ne jamais finir le
projet est grand. La rentabilité du projet
sera de toute façon obérée
Estimation du délai
Charge en H.M
Limite de faisabilité
Zone
impossible
Risque
acceptable
Délai maximal
Faible
rentabilité
Risque de
« ne
jamais
finir »
Délai en mois
Gestion de projet
Partie 3
 estimation des coûts et de la
rentabilité du projet : évaluation de
la valeur du projet
Pourquoi Évaluer ?

Parce que les SI coûtent cher !

Parce que les SI sont "stratégiques"

Parce qu'il n'y a pas de règles simples
I nv e st isse m en t
e n SI
E ff ic ac it é de
c on v er si on
P er fo rm a n c e g lo b al e
d e l'e n tre p rise
P er fo rm a n c e
o rg an isa tio n ne ll e d e
l' en tr ep ri se

Parce que 70% des projets sont des échecs

Parce que l'évaluation est une aide au pilotage

Parce que l'évaluation est un moyen de communication
Évaluer chaque projet (1)
OBJECTIFS
Justification Choix
Initialisation
Etude préalable
Conception
Construction
Evaluation
de la valeur
du projet
Contrôle
Qualité
Recette
Démarrage
Exploitation
Apprentissage
Évaluer chaque projet (2)




Penser en termes de valeur et pas QUE en termes
de coûts
Un projet = un Développement + une Application
Le coût est technique et dans l'organisation
(utilisateurs)
Les aspects organisationnels et humains sont
traités autant que la technique
La Valeur d'un projet

La rentabilité





Les bénéfices qualitatifs


L'investissement de développement
Les coûts d'exploitation
Les bénéfices (recettes) d'utilisation
La rentabilité (VAN, TRI, …)
Non traduisibles en francs
Les risques

Qui peuvent diminuer la rentabilité
Les coûts d'un projet
•
•
•
•
•
•
•
•
•
•
•
Personnel interne ou externe
Formation
Matériel
Logiciel
Installation
– Reprise des données
Environnement
– Câblage / climatisation / porte / ...
Coût d'exploitation
Maintenance
Sécurité
– Backup : reprise à chaud - à froid / ...
Réseau
Organisation
– Nouveau processus / baisse de production / augmentation
de salaire
Les autres coûts de développement

Les coûts les plus importants :
 Coûts dus aux ajustements organisationnels
 Coûts d ’exploitation sur la durée de vie

Les coûts les plus visibles ne sont pas les plus grands :
 Coûts sur factures externes
 Coûts directs
Performance
Prévue
Performance
actuelle
Ajustement
Performance
Réelle
Investissement
La démarche de calcul de l'investissement

1 Le coût de développement


J/H MOE et J/H MOA
Si plusieurs profils de compétences travaillent sur le
projet (Chef de projet, analyse, consultant externe, etc.),
il faudra les différencier.
Etape du projet
Etude préalable
J/H MOE
Coût J/H
MOE
J/H MOA
Coût J/H
MOA
Investissement
La démarche de calcul de l'investissement
(suite)

2 Les autres coûts



Séparer Développement et exploitation
Identifier fixe et variable
Identifier Direct et indirect
Type de coût
Matériel
Fixe /
variable
Direct / Développemen Informatique /
indirect
t/
Fonctionnel
Maintenance
Investissement
La démarche de calcul de l'investissement
(suite)

3 Calcul du budget d'investissement


SOMME de tous les coûts de développement
Coûts J/H + Autres coûts de DEVELOPPEMENT
Investissement
La démarche de calcul de l'investissement
(suite)

4 Calcul du tableau des cash-flow (FNT)



Tous les coûts d'exploitation par année
Les recettes estimées par année
L'investissement est en année 0
Année 1
Dépense 1
Dépense 2
Bénéfice 1
Bénéfice 2
Cash flow (dep - bénef)
Année 2
Année 3
Investissement
La démarche de calcul de l'investissement
(suite)

5 Calcul de la rentabilité


Comparaison entre l'investissement et les cash-flow générés
VAN, DRC, TRI
Investissement en ANNEE 0 = XXX €
Année 1
Dépense 1
Dépense 2
Bénéfice 1
Bénéfice 2
Cash flow (bénef - dép)
Année 2
Année 3
Évaluer les Bénéfices Qualitatifs (1)


Les 3 domaines de Facteurs de Qualité:
 Lien du projet avec la stratégie (DIRECTION)
 Qualité du service rendu (CLIENT)
 Impact sur l'organisation (UtILISATEUR)
En amont : estimation / en aval : mesure et
comparaison
Affirmation / bénéfice
Le projet est en accord avec la stratégie de l'entreprise
La Direction générale est fortement impliquée
Le projet peut modifier la stratégie d'entreprise
Le projet donne un avantage concurrentiel
critère
Note /
10
Évaluer les Bénéfices Qualitatifs (2)
Affirmation / bénéfice
Critère
Note /
10
Les utilisateurs vont participer activement au projet
Les utilisateurs attendent beaucoup du projet
Les utilisateurs se serviront beaucoup du futur système
Affirmation / bénéfice
Le projet va améliorer grandement la qualité des produits
Le projet va améliorer grandement la qualité du service
client
Le projet permet directement d'obtenir une norme de
qualité
Critère
Note /
10
Évaluer les risques (1)



Famille technique :
 Taille
 Technologie
 Structure
Famille Projet
 Impact humain / social
 Impact financier
 Impact sur l ’organisation
Famille Environnement :
 Evolution législative non prévue
 Attaque concurrent non prévue
Évaluer les risques (2)
Affirmation / facteur de risque
Note /
10
La taille de l'équipe de projet est la taille usuelle
Le nombre et l'importance de partenaires externes (MO et ME) est
faible
Le nombre de programme à réaliser est le nombre usuel pour ME
Le nombre d'interfaces avec d'autres système est faible
Affirmation / facteur de risque
Le matériel informatique utilisé est maîtrisé en interne
L'architecture matérielle est maîtrisée en interne
Les logiciels utilisés sont maîtrisés en interne
La complexité technologique a le niveau usuel pour la ME
Le matériel utilisé est maîtrisé par le prestataire externe
La méthode de développement est maîtrisée
L'utilisation d'AGL est maîtrisé en interne
Note /
10
Analyse de l'évaluation
1 Reporter dans un graphique comme ci-dessous
la
Rentabilité (dans le rond)
Le Résultat de l'analyse de la valeur (axe des X)
Le Poids des risques (Axe des Y)
Risques : 4,22
VM : 319 K€
INTERNET
Bénéfices : 3,37
2 Comparer avec le précédent positionnement
Analyse de l'évaluation
Exemple d'un Projet INTERNET
Évolution
Risques : 4,22
du projet
VM : 319 K€
100 K€
Bénéfices : 3,37