PDF TF - GESTION PROJETS ESTIMATION CHARGES

Transcription

ESTIMATIONS DES CHARGES
D’ UN PROJET DE SYSTEME
D’ INFORMATIONS
05/09/2007 V1.0
Gestion projets - Estimation charges
1
Sommaire:
- Risques projets
- Estimation des charges
- Méthodes d’Estimation
05/09/2007 V1.0
2
ANALYSE DU RISQUE
Qu’est ce que le risque dans le cadre d’un
projet de développement d’un système
d’informations?
05/09/2007 V1.0
3
ANALYSE DU RISQUE
- Définition générale
– Risque =(coût des conséquences d ’un
événement craint) x (probabilité d’apparition)
– Apparition du risque peut mettre en cause le
processus projet, notion de risque d ’échec.
05/09/2007 V1.0
4
ANALYSE DU RISQUE
- Constats d’échecs ou dérives
• Taux d’échec = 3/4 environ.
– 1/10 par abandon,
– 3/4 en dépassement de budget et/ou délai,
– 1/2 n’ayant pas atteint les objectifs,
- Objectif du chef de Projet: identifier les
facteurs de risque d ’échec d’un projet.
05/09/2007 V1.0
5
ANALYSE DU RISQUE
- Facteurs de risque
– Liés aux caractéristiques du projet
•
•
•
•
•
05/09/2007 V1.0
Taille du projet
Etendue fonctionnelle
Choix technologiques
Complexité de l’intégration
Effectifs
6
ANALYSE DU RISQUE
- Facteurs de risque
– Liés à l ’environnement du projet
• Etendue du projet par rapport à l’entreprise cliente
• Incidence des changements liés au projet sur
l’organisation
• Stabilité de l ’équipe du projet
05/09/2007 V1.0
7
ANALYSE DU RISQUE
- Profil de risque d ’un projet (exemple)
Degré du risque / projet
Nature Risque
0
1
2
Taille du projet
3
4
¤
Difficulté technique
¤
Degré d’intégration
¤
Contraintes organisationnelles
Changement
¤
¤
Stabilité équipe projet
05/09/2007 V1.0
5
¤
8
STRATÉGIE DE
DÉVELOPPEMENT
- Choix d’un modèle de développement
- Mise en place du dispositif de coordination
- Choix des modalités de participation des
utilisateurs
- Mise en place de tableaux de bord de
pilotage du projet
05/09/2007 V1.0
9
STRATÉGIE DE
DÉVELOPPEMENT
- Gérer le risque par les biais des choix précédents
– Risque lié à la taille :
• Faible visibilité => développement par itérations, modèle en
spirale, attention au mode de facturation du projet,
dépassement des charges,
• Équipe importante => dispositif de coordination formelle,
tableaux de bord formalisés,
– Risque technique :
• Résultante de la complexité => nécessite une bonne maîtrise
des compétences de son équipe et une affectation de
chaque membre au poste le mieux approprié – matrices de
compétences
• Problématique liée à la programmation ou la nouveauté =>
développement en cascade avec deux étapes majeures,
modèle en W
05/09/2007 V1.0
10
STRATÉGIE DE
DÉVELOPPEMENT
– Risque lié à l ’intégration :
• appelle une coordination personnelle.
• Modèle en V (facilite l ’intégration modulaire).
– Configuration organisationnelle
• Recherche d ’un consensus décisionnel
• Modèle du cycle RAD
– Risque lié au changement :
• Participation des différents acteurs,
• Modèle de développement évolutif (si les contraintes de
budget et de délai sont faibles).
– Instabilité de l ’équipe du projet
• Management des hommes,
• Doublonnage des compétences
• Documentation du projet,
05/09/2007 V1.0
11
STRATÉGIE DE
DÉVELOPPEMENT
- Cas particulier: projet à très court délai
– Démarche qualité efficace et pragmatique
– Possibilité de mettre en œuvre une
méthode RAD
=> s ’assurer de la participation active des
utilisateurs.
05/09/2007 V1.0
12
PLAN DE DÉVELOPPEMENT
- Mise en oeuvre de la stratégie de
développement
- Trois actions
– Valider la production,
– Décider de l’organisation du projet,
– Gérer l’avancement du projet, changement
05/09/2007 V1.0
13
PLAN DE DÉVELOPPEMENT
Analyse des risques
du projet
Objectifs du
Processus de
décision
Objectifs du
Processus de
production
Objectifs du
Processus
de changement
Stratégie de développement:
Modèle de développement
Dispositif de coordination
Modalité de participation
Tableau de bord
Fin du plan de développement
05/09/2007 V1.0
14
ESTIMATION DES CHARGES
- Charge et durée / délai
– Charge
• La CHARGE d’un projet, est la quantité de travail à fournir
pour conduire le projet, indépendamment du nombre
d’intervenants au sein de l’équipe,
• La Charge, est exprimée en Jours Homme, Mois Homme, ou
Années Homme, elle permet:
– D ’obtenir un budget projet,
– De définir la taille, et les enjeux humains (équipe) d ’un projet.
» Projet < 3 m/H => très petit projet
» Projet < 9 m/H => petit projet
» Projet < 40 m/H => projet moyen
» Projet < 100 m/H => grand projet
» Projet > 100 m/H => très grand projet
05/09/2007 V1.0
15
- Charge et durée/ délai
– Durée, délai
• La Durée ou le Délai du projet, correspond au
temps nécessaire pour le conduire en terme
d’espace de temporel,
• La durée / délai, dépend de l’effectif de l’équipe
projet, évaluation non isotrope
– (9 personnes pendant un mois ne sont pas équivalentes
à 1 personne pendant 9 mois)
05/09/2007 V1.0
16
- Au niveau du projet global
- Au niveau de l ’étape
– Ordre de grandeur : jours/homme
– Ajuster le découpage
– Sous-traiter
– Prévoir le temps de gestion du projet:
• Ordonnancement, planification,
• Ré-estimé, reste à faire, consommé,
• affectations
05/09/2007 V1.0
17
- Au niveau de la phase
– Planification détaillée de la phase,
– Planification des livrables intermédiaires,
– Planification du pilotage de projet, du suivi,
mesure des écarts,
– Affectation des ressources,
05/09/2007 V1.0
18
- Au niveau de la tâche
– Affectation des ressources individuelles,
– Planification fine de la tâche,
- Utilisation de techniques d’estimation
adaptées au niveau de granularité
05/09/2007 V1.0
19
LES MÉTHODES
D ’ESTIMATION
• Loi de Parkinson : « le travail se dilate
jusqu ’à remplir le temps disponible »
• « loi du marché »: la charge correspond
au prix à proposer pour remporter l ’appel
d ’offres,
• Méthodes classiques:
– Delphi, Cocomo / Diebold, évaluation
analytique et « points de fonction »
05/09/2007 V1.0
20
LES MÉTHODES
D ’ESTIMATION
• Principe
– Construire un référentiel d’estimation
rassemblant l ’expertise des projets antérieurs
– Faire une estimation de la taille du projet à
l ’aide d ’une unité de mesure
– Ajuster la taille ou la charge brute en fonction
des spécificités du projet
– Répartir la charge entre les différentes
étapes.
05/09/2007 V1.0
21
DELPHI
• Méthode élaborée en 1948 par la Rand
Corporation, basée sur le jugement
d ’experts
• Principe est de rechercher des analogies
avec des projets antérieurs, et d’affiner
successivement les ratios énoncés par
plusieurs experts jusqu ’à obtention d ’une
convergence,
05/09/2007 V1.0
22
Répartition Proportionnelle
C h a r g e s p r o je té e s ( = le to ta l)
C h a rg e s c o n n e x e s
S p é c ific a tio n
C o n c e p tio n
In té g r a tio n
V a lid a tio n
R é a lis a tio n
In té g r a tio n u s in e
s ite
s ite
V A B F T
V a lid a tio n u s in e
M a n u e ls
M a îtr is e d ’o e u v r e
E n c a d r e m e n t d e s é q u ip e s
Q u a lité
C h a rg e s tra n s v e rs e s
05/09/2007 V1.0
23
C o e ffic ie n ts d u c y c le e n " V "
Phase
C h a rg e s c o n n e x e s
C e s c h a r g e s s 'é v a l u e n t d i r e c t e m e n t .
R a tio
S p é c ific a tio n s
X%
C o n c e p tio n
Y%
R é a lis a tio n ( C h a r g e p iv o t)
Z%
In té g r a tio n u s in e
T%
V a lid a ti o n u s in e
V%
T O T A L (C h a r g e p r o je té e )
100%
Il e n r é s u lt e q u e l'o n o b t ie n t la c h a r g e p r o j e t é e p a r :
C h a r g e p iv o t =
Z%
x
C h a r g e p r o je t é e
1 0 0 /Z
x C h a rg e p iv o t
S o it:
C h a r g e p r o je té e =
C harg e co n nexe =
n h xj
C o e ffic ie n ts d e s c h a r g e s tr a n s v e r s e s
L e s c o e ffic ie n ts c i- d e s s o u s s o n t a p p li q u é s a u x c h a r g e s c i- d e s s u s
( C h a r g e s p r o je t é e s e t C h a r g e s c o n n e x e s )
Tâches
R a tio
M a î t r i s e d 'œ u v r e
A%
E n c a d r e m e n t d e s é q u ip e s
B%
Q u a lit é
C%
I l e n r é s u l t e q u e l ' o n o b t i e n t l a c o n t r i b u t i o n a u i x c h a r g e s t r a n s v e r s e s d 'u n e c h a r g e p r o j e t é e o u c h a r g e c o n n e x e p a r l a f o r m u l e :
C h a r g e s tr a n s v e rs e s =
05/09/2007 V1.0
(A + B + C )%
x
[C h a r g e s p ro je té e s + C h a r g e s c o n n e x e s ]
24
CYCLE EN « V »
05/09/2007 V1.0
25
CYCLE EN « V »
05/09/2007 V1.0
26
Les charges projet correspondant à un cycle en V s’évaluent
approximativement de la façon suivante:
Phases
Spécifications
Conception
Réalisation +TU
Intégration
Validation
Ratio :
10
21
47
11
11
Total
100 %
05/09/2007 V1.0
27
Charges transversales:
Tâches
Maîtrise d’œuvre
Encadrement des équipes
Qualité
Ratio
4%
6%
3%
Total
13 %
Charges connexes:
généralement de l’ordre de:
7- 15%,
dont :
3-5% documentation,
formation utilisateurs,
charte ergonomique,
maquettage,
accompagnement au démarrage,
05/09/2007 V1.0
28
La charge globale du projet, en fonction du niveau de maîtrise de
l’environnement, de l’équipe de réalisation et conception, de compétence du
client, varie entre:
2 et 3 fois la charge de développement,
estimée pour une équipe moyenne.
Retenir la méthode 2.5 (/charge de développement),
pour obtenir la charge globale maxi avec une équipe normale,
elle baissera généralement à 2.2 avec une équipe expérimentée en
environnement connu.
05/09/2007 V1.0
29
Répartition
Proportionnelle
Tâches élémentaires
Charges Réalisation
Charges Totales
L’ergonomie des écrans
• Création d’un simple (1 à 4):
• Création d’un moyen (5 à 6):
• Création d’un complexe (7 à 8):
• Modification d’un écran :
0,75 J
1J
1,5 J
0.3 J
2J
2,5 J
3,75 J
0,75 J
Les sources TP/Batchs (programmes et sous-programmes)
En Création
• Les sources simples (1 à 4):
1J
• Les sources moyens (5 à 6):
2J
• Les sources complexes (7 à 8):
3J
2,5 J
5J
7,5 J
En Modification
• Les sources simples :
• Les sources moyens :
• Les sources complexes :
0,3 J
0,75 J
1,5 J
0,75J
2J
3,75 J
30
05/09/2007 V1.0
On admet généralement que le délai incompressible pour réaliser un projet est :
Tmin = 2,5 x (Chm)
1/3
où Tmin est exprimé en mois et Chm en hommes x mois.
Le délai optimum correspond au meilleur compromis entre délai, encadrement et prise
de risques :
Topt = 1,4 x Tmin
Les unités d’œuvre sont évaluées dans le cadre du délai optimum
05/09/2007 V1.0
31
LES MÉTHODES À MODÈLE :
COCOMO ET DIEBOLD
• Constructive Cost Model (COCOMO)
Boehm 1981
• Deux hypothèses :
– Un informaticien évalue mieux la taille du
logiciel à développer que la quantité de travail
nécessaire
– Il faut toujours le même effort pour écrire un
nombre donné de lignes de programme, quel
que soit le langage (3eme génération)
05/09/2007 V1.0
32
COCOMO ET DIEBOLD
• L ’unité : l ’instruction source
• Le modèle permet d ’obtenir la charge de
réalisation en m/H et le délai normal
recommandé
• Formules de calcul :
Charge en mois/Homme = a (Kisl)b
– Kisl = kilo instruction source testée
05/09/2007 V1.0
33
COCOMO ET DIEBOLD
• Durée normale en mois = c(charge)d
• Les paramètres a, b, c et d dépendent
de la catégorie du projet. Soit l la taille
du logiciel.
– Projet simple si l< 50 Kisl, spécifications
stables, petite équipe.
– Projet moyen si 300 Kisl >l > =50 Kisl,
spécifications stables, petite équipe.
– Projet complexe si l >300 Kisl, grande
équipe.
05/09/2007 V1.0
34
COCOMO
Type de projet
Charge en mois
homme
Durée en mois
Simple
C= 3,2 (Kisl)1,05
D= 2 ,5( C )0,38
Moyen
C= 3 (Kisl)1,12
D= 2 ,5( C )0,35
Complexe
C= 2,8 (Kisl)1,2
D= 2 ,5( C )0,32
05/09/2007 V1.0
35
Exemple COCOMO
• Soit un projet visant à
développer un logiciel
de 100 000
instructions sources
• C ’est un projet
MOYEN par la taille
du logiciel.
05/09/2007 V1.0
• Charge = 3*(100)1,12 =
521 mois/homme
• Durée normale =
2,5* (521)0,35 = 22 mois
• Ce qui donne une taille
moyenne de l ’équipe =
521 / 22 = 23 personnes.
36
COCOMO
• Il faut tenir compte des « facteurs
correcteurs » d ’estimation de charge.
• Quatre sources de risque sur l ’estimation
– Exigences attendues du logiciel
– caractéristiques de l ’environnement
technique (matériel)
– Caractéristiques de l ’équipe projet
– Environnement du projet lui-même
05/09/2007 V1.0
37
COCOMO
• Les facteurs logiciels sont :
– Fiabilité du logiciel : influence forte si
exigence dans ce sens
– Base de données : mesuré par le ratio
– (volume de données gérées en octets) /(taille du
logiciel en lignes)
– L ’influence du facteur est faible si le ratio<10, très
forte si ratio>1000
– Complexité : celle des algorithmes
– Temps d ’exécution : crucial si temps réel
05/09/2007 V1.0
38
COCOMO
• Les facteurs matériels sont :
– Taille mémoire : optimisation
– Stabilité de l ’environnement : logiciel de
base
– Contrainte de délai : par rapport au délai
calculé « théorique ».
05/09/2007 V1.0
39
COCOMO
• La correction intervient dans la formule :
– Charge nette = produit (valeurs des
facteurs correcteurs) * Charge brute
• Démarche en cinq étapes:
– Estimation du nombre d ’instructions
source,
– Calcul de la charge « brute »,
– Sélection des facteurs correcteurs,
– Calcul de la charge nette,
– Evaluation de la durée sur la charge nette,
05/09/2007 V1.0
40
DIEBOLD
• Version antérieure et simplifiée de
COCOMO.
• Connaît le nombre d ’instructions à écrire
et donne le temps en jours
• Temps(jours) = (complexité)*(savoirfaire)*(connaissance)*(kisl)
05/09/2007 V1.0
41
DIEBOLD
• Complexité du logiciel.
– 10<=c<=40
• Savoir-faire, expérience du programmeur
• Forte expérience: 0,65
• Faible expérience: 2
• Connaissance de l ’environnement
technique :
• 1 = bonne
• 2 = faible
05/09/2007 V1.0
42
POINTS de FONCTION
• A. Albrecht (IBM) 1979
• Principe :
– Estimation à partir d ’une description externe
du futur système, et de ses fonctions.
– 5 types d ’unité d ’œuvre et 3 degrés de
complexité
05/09/2007 V1.0
43
POINTS de FONCTION
Détermination du périmètre de l’application
Identification du composant
Evaluation complexité de chaque composant
Calcul poids en points de fonction pour chaque composant
Calcul nombre brut de points de fonction
05/09/2007 V1.0
44
POINTS de FONCTION
• Pour un projet donné on calcule son
poids en « points de fonction ».
• Méthode:
– Comptage des points au début du projet
– Comptage en fin
– Ecart = changement d ’envergure
– Evaluation :
• Calcul de la taille,
• Ajustement de la taille,
• Transformation en charge.
05/09/2007 V1.0
45
POINTS de FONCTION
• Composants fonctionnels :
– Groupe logique de données internes (GDI)
– Groupe logique de données externes (GDE)
– Entrée de traitement (ENT)
– Sortie de traitement (SORT)
– Interrogation (INT)
05/09/2007 V1.0
46
POINTS de FONCTION
• Complexité d ’un composant :
– Faible
– Moyenne
– Elevée
• Nombre de points de fonction du
composant :
– Tableau de correspondance entre la
complexité et le type du composant = > poids
05/09/2007 V1.0
47
Calcul du nombre de points de
fonction brut : exemple
Entité
Complexité Nb de
composants
A dénombrer
GDI (Groupe logique de Faible
2
données internes)
Moyenne
1
Elevée
1
GDE (Groupe logique de Faible
2
données externes)
Moyenne
2
Elevée
1
ENT (Entrée de
Faible
3
traitement)
Moyenne
5
Elevée
2
SORT (Sortie de
Faible
2
traitement)
Moyenne
1
Elevée
0
INT (Interrogation)
Faible
1
Moyenne
5
Elevée
5
PFB (Points fonction
bruts)
05/09/2007 V1.0
Poids
Fixé
Nb de Points
de fonction
7
10
15
5
7
10
3
4
6
4
5
7
3
4
6
14
10
15
10
14
10
9
20
12
8
5
0
3
20
30
180
48
POINTS de FONCTION
Composants des points de fonction
Utilisateurs
entrées
sorties
Application
interrogations
GDI
entrées sorties interrogations
Autres applications
05/09/2007 V1.0
GDE
49
POINTS de FONCTION
• Le Point de Fonction Brut est ensuite ajusté
par une appréciation des spécificités du
projet.
– 14 facteurs d’influence sont identifiés, auxquels
sont attribués une note de 0 à 5 en fonction du
degré d ’influence. (leur somme DIT est nommée
degré d’influence total= SOMME (Dii, i = 1 à 14))
• Le Point de Fonction Ajusté ou nombre
ajusté de points
– PFA = (0,65 +DIT/100)* PFB
05/09/2007 V1.0
50
POINTS de FONCTION
Degrés d’influence du système
Transmission des données
Système distribué
Contrainte de performance
Configuration à utilisation intensive
Taux de transaction
Saisie interactive
Convivialité
Mise à jour en temps réel
Complexité des traitements
Réutilisation
Facilité d’exploitation
Portabilité de l’application
Flexibilité de modification
05/09/2007 V1.0
51
POINTS de FONCTION
Echelle de 0 à 5 des degrés d’influence
0 inexistante ou sans influence
1 influence secondaire
2 influence restreinte
3 influence moyenne
4 influence importante
5 influence intensive partout
05/09/2007 V1.0
52
POINTS de FONCTION
• Le Point de Fonction permet de donner le
nombre d ’instructions source utiles (ISL)
pour COCOMO ou DIEBOLD avec la
formule :
– ISL (lprocédural)= 118, 7 * PFA - 6490.
05/09/2007 V1.0
53
POINTS de FONCTION
• En fin d ’étude préalable
– 3 jH si projet moyen/PF
– 2 jH si petit projet/PF
– 4 jH si grand projet/PF
• En fin d ’étude détaillée : 1 à 2 jH / PF selon
l ’environnement
• Réalisation en L4G 1jH/10 PF
• Conception + Réalisation en RAD : 0,5 jH/PF
05/09/2007 V1.0
54
Questions / Réponses
05/09/2007 V1.0
55

PDF TF - GESTION PROJETS ESTIMATION CHARGES

Transcription

Documents pareils

Gestion Projet cours S5-S6

81 BD Vauban, 59000 Lille tel : 03 20 54 32 32 fax : 03 20 57 16 05

Conseil habitat santé : Objectif et retour d`expérience

Ile aux enfants

Curriculum Vitae - Olical14

bourse armes et militaria - Ligue Régionale de Tir du Languedoc

Télécharger le document PDF affiche_credavis_forum_2016

Revitalisation centre-ville Info travaux #4.pub

Letras d`oc => passage en bilingue d`un sitedit

La production du yaourt