gestion de projet troisième partie : estimation de la charge, des délais et des coûts 2004-2005
Post on 04-Apr-2015
113 Views
Preview:
TRANSCRIPT
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
1 Identification des modules à réaliser2 Décomposition de chaque module en programmes3 Décomposition des programmes en fonctions types4 Estimation de la charge de développement d'une fonction type5 Somme en ajoutant la charge d'intégration
Application
Module 1 Module n
Prog 1 Prog n
Fonct 1 Fonct n
1 J/H 2 J/H
Gestion de projetEstimation empirique de la charge
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.MHM = 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. De base : utilisation de formules
standards2. Intermédiaire : formules selon le type
de programme3. 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
0 ou 1Faible Faible Moyen
2 à 3Faible Moyen Élevé
4 et plus
Moyen Élevé Élevé
Calcul des points de fonction brutsComplexit
éNombre Total par complexité Totaux
FLI F ___ x 7 = ___
M ___ x 10 = ___
E ___ x 15 = ___
FI F ___ x 5 = ___
M ___ x 7 = ___
E ___ x 10 = ___
ENT F ___ x 3 = ___
M ___ x 4 = ___
E ___ x 6 = ___
SOR F ___ x 4 = ___
M ___ x 5 = ___
E ___ x 7 = ___
INT 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
Délai en mois
Charge en H.M
Zone impossible
Limite de faisabilité Délai maximal
Risque acceptable Faible
rentabilité
Risque de « ne jamais finir »
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 70% des projets sont des échecs
Parce que l'évaluation est une aide au pilotage
Parce que l'évaluation est un moyen de communication
Investissement en SI
Efficacité de conversion
Performance globale de l'entreprise
Performance organisationnelle de
l'entreprise
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
Évaluer chaque projet (1)
Initialisation
Etude préalable
ConceptionConstruction
RecetteDémarrage
Evaluation de la valeur
du projet
Justification Choix
OBJECTIFS
Contrôle
Qualité
ApprentissageExploitation
É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é L'investissement de développement Les coûts d'exploitation Les bénéfices (recettes) d'utilisation La rentabilité (VAN, TRI, …)
Les bénéfices qualitatifs Non traduisibles en francs
Les risques Qui peuvent diminuer la rentabilité
• 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 coûts d'un projet
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 actuelle
Performance Prévue
Performance Réelle
Ajustement
Les autres coûts de développement
InvestissementLa 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 J/H MOE Coût J/HMOE
J/H MOA Coût J/HMOA
Etude préalable
InvestissementLa 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 Fixe /variable
Direct /indirect
Développement /
Maintenance
Informatique /Fonctionnel
Matériel
InvestissementLa 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
InvestissementLa 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 Année 2 Année 3Dépense 1Dépense 2
Bénéfice 1Bénéfice 2
Cash flow (dep - bénef)
InvestissementLa 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
Année 1 Année 2 Année 3 Dépense 1 Dépense 2 Bénéfice 1 Bénéfice 2 Cash flow (bénef - dép)
Investissement en ANNEE 0 = XXX €
É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 critère Note /10
Le projet est en accord avec la stratégie de l'entrepriseLa Direction générale est fortement impliquéeLe projet peut modifier la stratégie d'entrepriseLe projet donne un avantage concurrentiel
Évaluer les Bénéfices Qualitatifs (2)
Affirmation / bénéfice Critère Note /10
Les utilisateurs vont participer activement au projetLes utilisateurs attendent beaucoup du projetLes utilisateurs se serviront beaucoup du futur système
Affirmation / bénéfice Critère Note /10
Le projet va améliorer grandement la qualité des produitsLe projet va améliorer grandement la qualité du serviceclientLe projet permet directement d'obtenir une norme dequalité
É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
Le matériel informatique utilisé est maîtrisé en interneL'architecture matérielle est maîtrisée en interneLes logiciels utilisés sont maîtrisés en interneLa complexité technologique a le niveau usuel pour la MELe matériel utilisé est maîtrisé par le prestataire externeLa méthode de développement est maîtriséeL'utilisation d'AGL est maîtrisé en interne
Affirmation / facteur de risque Note /10
La taille de l'équipe de projet est la taille usuelleLe nombre et l'importance de partenaires externes (MO et ME) estfaibleLe nombre de programme à réaliser est le nombre usuel pour MELe nombre d'interfaces avec d'autres système est faible
Analyse de l'évaluation1 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)
2 Comparer avec le précédent positionnement
Bénéfices : 3,37
Risques : 4,22 VM : 319 K€
INTERNET
Analyse de l'évaluation Exemple d'un Projet INTERNET
Évolution du projet
Bénéfices : 3,37
Risques : 4,22 VM : 319 K€
100 K€
top related