Ch2 - Activité de Planification

•Département : Informatique
•Module : Gestion de projet

•Année universitaire: 2020/2021
•Département
Informatique
Gestion de projet : Chapitre 2
FSTBM 2020-2021
Conduite de Projet
Plan
• Les bases de la gestion de projet
• Activité de Planification Projet
• Activité d’Organisation
• Activité de Production
• Activité de Pilotage
Conduite de Projet 2
Activité de Planification
• Principes
• Délimitation du Projet
• Détermination des tâches
• Estimation des charges
• Ordonnancement des tâches
• Planification des tâches
• Établissement des prévisions de charge
• Qualification de l ’équipe de projet
Principes
• Objectifs
– Essayer de prévoir comment se déroulera la future
réalisation du projet
• Personnes concernées
– Chef de projet
– Maître d ’œuvre
– Maître d ’ouvrage
•Maitre d’ouvrage – Maitre d’oeuve
•Le client •Le fournisseur
 Le rôle de la MOA  Le rôle de la MOE

 Evaluer et exprimer les besoins avec les  Concevoir des solutions
utilisateurs
 Réaliser le planning
 Etablir un cahier des charges
 Trouver les moyens (internes ou
 Contrôler le planning produit par la MOE
externes)
 Faire du reporting pour indiquer les retards
éventuels  Réaliser la solution choisie
 Vérifier l’adéquation des solutions proposées  Assister la maîtrise d’ouvrage
 Effectuer la recette fonctionnelle
 Conduire le changement
 Piloter
 Payer
Délimitation du Projet (1)
• Étudier les clauses techniques du contrat
• Établir une liste des principales activités à réaliser
• Établir une liste des principales prestations à servir
• Distinguer les responsabilités du maître d ’œuvre et
celles du maître d ’ouvrage.

Six critères pour identifier un projet :
• Grand ou petit
• Directeur ou sous-projet
• Collectif ou individuel
• ouvert ou fermé
• Développement ou résolution
• Pluridisciplinaire ou spécialisé

On peut rencontrer des projets combinant plusieurs critères :
• Petit sous-projet ouvert, collectif, de développement spécialisé (ex.
développement d ’une fonctionnalité d ’une application)
• Grand projet directeur, collectif et ouvert, de développement,
pluridisciplinaire (ex. restructuration d ’une entreprise)
• Petit sous-projet fermé individuel de résolution spécialisé (ex.
dépanner une machine)
Détermination des Activités (1)

• Principes du découpage
• Organigramme des Produits
• Organigramme des Tâches
• Organigramme des Ressources
• Les modèles de développement

Activité de Planification / Déterminer les activités
Principes du découpage (1)

Objectifs :
• Découper le projet afin de planifier les tâches et les ressources en
attachant à chaque élément de décomposition :
– une date de début et
– une date de fin et
– un résultat à atteindre à l’appui d’un engagement contractuel
• Baliser le déroulement du projet : la fin de chaque tranche est un jalon
où on vérifie l’état de santé du projet (mesure de dérive)
• Aider le Maître d’ouvrage à s’assurer progressivement de la conformité
des résultats produits
Principes du découpage (2)

Les sous-ensembles identifiés sont tels que :
• Chaque sous-ensemble du projet donne lieu à un résultat
bien identifié
• La charge propre à chacun peut être évaluée
• Les parallélismes ou les priorités d’antériorité de tâches sont
repérables
• Chaque sous–ensemble est éventuellement décomposé à son
tour.
Les modèles de développement (1)
Cycle de vie classique Intervenants

• Consultants
• Étude de faisabilité (ne dure pas très longtemps)
• Utilisateurs
• Étude préalable (10 % de la charge du projet) • Direction
• Étude détaillée (20 à 30 % de la charge du projet) • Qualiticiens
• Chefs de projet
• Étude technique (5 à 15 % de la charge de réalisation)
• Organisateurs
• Réalisation (2 fois la charge de l’étude détaillée)
• Analystes
• Mise en œuvre (30 à 40 % de la charge de réalisation) • Programmeurs
• Maintenance • BDA
• Exploitants

Le modèle de la cascade
Définition et
analyse des besoins
Conception
de la solution
Réalisation /
Programmation
Tests Unitaires
et d ’Intégration
Recettes finales et
Mise en œuvre

Le modèle en V
Expression des besoins Maintenance
Etude d’opportunité Mise en oeuvre
Etude fonctionnelle et prototypage Recette Utilisateur
Conception technique globale Tests d’intégration
Conception technique détaillée Tests Unitaires
Programmation

Le modèle de prototypage incrémental
Spécification
initiale
Sélection d ’un point
ou d ’une caractéristique
Construction
du prototype
Evaluation
Une version allégée Confirmation ou affinement
du prototypage est des spécifications
le cod-and-fix
Estimation des charges

• Estimation
• Pourquoi la sous-estimation
• Conditions d ’une estimation sérieuse
• Les méthodes d’estimation
• Séquences d ’étapes d’estimation
• Choix d’une technique d’estimation
• Passage des charges aux coûts
• Démarche pour l ’estimation des projets de développement
logiciel
Activité de Planification/ Estimation des charges
Estimation
• Définition : Mesure de la quantité de travail à fournir pour
réaliser une tâche ou une activité donnée
• Estimer un projet de type « développement logiciel », c ’est
chiffrer approximativement à l ’avance :
– la charge de travail en jours*homme
– les ressources en nombre d informaticiens à affecter
– la durée en mois
• Constat :
– Prévoir est un art difficile
– La majeure partie des projets dérivent
Pourquoi la sous-estimation
• Désir de plaire
• Besoin d ’emporter le contrat
• Optimisme
• Expérience limitée de l ’ensemble du projet
• Réflexion basée sur les fonctions principales
• Oubli des utilitaires
• Oubli de la documentation
• Sous-estimation des efforts de mise au point
• Raisons personnelles
• Absences de méthodes et de standards.
Le dérapage est souvent dû à une mauvaise estimation
initiales, plutôt qu’à une mauvaise réalisation
Conditions d’une estimation sérieuse

• Refus de toute estimation arbitraire
• Borner les ambitions de l’utilisateur / client
• Une définition assez précise des fonctions à réaliser
• Une bonne connaissance des contraintes
• Des standards liés aux méthodes
• Une méthode d’estimation
Les méthodes d ’estimation(1)

Méthodes dites « par loi de PARKINSON »
• Principes :
– Le travail se dilate jusqu’à remplir le temps disponible
– 12 mois pour faire un projet, 5 personnes disponibles  Evaluations
: 60 M*H
• Avantages : Aucun
• Inconvénients : Tous
Les méthodes d ’estimation (2)

Méthodes « imposées par le marché »
• Principes :
– La charge correspond au prix idéal pour emporter le contrat
– Désir de séduire le client
• Avantages :
– Plus de chances d ’avoir le contrat
• Inconvénients :
– Ecarts importants possibles
– Perte d ’argent si rente de situation non confirmée
– Risque pour le maître d ’ouvrage

Méthodes d’expertise et de consensus(1)
• Principes :
– Demander à plusieurs chefs de projet d’estimer individuellement
– Rechercher, dans un deuxième temps, un consensus
• Avantages :
– Prise en compte des différents contextes
– Prise en compte des exceptions
– Estimation en fonction de la qualité des experts
– Les experts sont influençables
Les méthodes d’estimation (4)

Méthodes d’expertise et de consensus(2)
• Le consensus : (Technique DELPHI)

– Le coordinateur présente les spécifications à chaque expert
– Chaque expert fait son évaluation et remplit une fiche anonyme
– Le coordinateur prépare une synthèse de toutes les estimations
– Chaque expert est à nouveau consulté pour réviser son
estimation
– On réitère jusqu’à l ’obtention du consensus

Méthodes dites « par analogie »
• Principes :
– Tenir une historique des projets
– Mettre en évidence les différences
– Evaluer les écarts
• Avantages :
– Prise en compte de l ’expérience
– Prise en compte du contexte spécifique de la société
– Degré de signification des projets passés (évolution, etc.)
– Pas de prise en compte des situations exceptionnelles

Méthodes algorithmiques
• Principes :
– Fonction mathématique d ’un certain nombre de variables
– Exemple : COCOMO, ELYS
• Avantages :
– Objectivité grâce aux formules
– Fidélité (mêmes données ==> mêmes résultats)
– Simplicité d ’application , basé sur le passé
– Pas de prise en compte des exceptions
– Expériences issues d ’autres sociétés (USA)
Séquences d ’étapes d ’estimation (1)

1. Déterminer le format de l’estimation
2. Analyser les données anciennes, expériences précédentes
3. Valider les données anciennes
4. Définir un cycle de vie pour le projet
5. Identifier les spécialistes nécessaires
6. Identifier les contraintes majeures du projet
Séquences d ’étapes d ’estimation(2)

7. Établir des analyses du type « Points de fonction »
8. Évaluer les compétences de l ’équipe (COCOMO)
9. Évaluer l ’environnement (COCOMO)
10. Évaluer les méthodes (COCOMO)
11. Évaluer les langages de programmation (PFA)
12. Prédire la taille du code (PFA)
13. Prédire la taille des autres livrables : documentation, tests, etc.
Séquences d ’étapes d’estimation (3)

14. Prédire le personnel, la charge, les coûts, les calendriers
– Expérience passée
– COCOMO
– FPA
15. Documenter les résultats et le contexte de l ’estimation, les

hypothèses faites sur :
– l ’environnement de développement
– les méthodes
– les « skills »
– les outils
Choix d ’une technique d ’estimation (1)
Un facteur clé permettant de faire le choix d’une technique

d’estimation est le choix du point du cycle de vie où la
technique sera utilisé :
• Techniques utilisées au moment de l’établissement de l ’offre
• Techniques utilisées dans les phases amont du projet
• Techniques utilisées pendant le développement du projet
Choix d ’une technique d ’estimation(2)

Techniques niveau offre
• Les techniques suivantes sont utiles pendant

l ’établissement de la proposition d ’offre au client :
– Le jugement professionnel
– La technique Delphi
– Estimation Bottom-Up
– Approches standards

Techniques niveau amont(1)
La technique d’Analyse par points de fonctions (FPA) est

utile pour les phases amont :
•Méthode utilisée pour estimer la taille et l ’effort de
développement nécessaires pour des projets software de
toutes tailles

Techniques niveau amont(2)
• FPA est basée sur une évaluation pondérée des paramètres projets :
– Entrées
– Sorties
– Fichiers
– Interfaces avec les autres systèmes
– Demande de renseignements
• Voir annexe A1
• L ’influence de 14 facteurs complémentaires, tels que données
distribuées, transactions « online », multi-installations, performances, etc.,
est prise en compte.

Techniques en développement
• La technique d ’estimation la plus connue est basée sur le

nombre de lignes de code à écrire.
• Quand le développement a bien débuté, les estimations

faites avec cette méthode sont justes.
• COCOMO : Constructive Cost Method
Méthode COCOMO (1)
• Principe :
– Effort = a*(KISL)b
– Lesparamètres a et b dépendent de la version de COCOMO
appliquée
– KISL : Kilo Instructions Source Livrées
• Origine :
– 1ère version : 63 projets en 1964 et 1979
– Charge variant de 6 à 11400 M*H
– L ’usage d ’un outil est obligatoire (COSTAR)
Méthode COCOMO (2)
COCOMO possède 3 niveaux d ’estimation
• Basic COCOMO :
– correct pour des estimations de coût de projet rapides,
– ne prend pas en compte les contraintes hardware, la qualité du personnel,
l ’expérience, l ’usage d ’outils (facteurs conducteurs de coût)
• Intermediate COCOMO :
– inclut les 15 facteurs conducteurs de coût en prenant en compte leur impact sur le
coût global du projet.
• Detailed COCOMO :
– prend en plus en compte l ’influence individuelle de ces facteurs sur chaque phase
du projet
Méthode COCOMO (2)

Application du COCOMO intermédiaire
• Déterminer la taille en KISL du logiciel : ISL –Cobol) = 118,7*PFA-6490

• Calculer la charge brute
– Mode organique (équipe petite taille, domaine maîtrisé, taille inférieure à 50
KISL), MHB = 3,2*KISL1,05
– Mode semi détaché (maîtrisé limitée dudomaine, taille inférieure à 300 KISL),
MHB = 3,0*KISL1,12
– Mode contraint (système complexe, contraintes temps-réel, coût de validation très
élevé), MHB = 2,8*KISL1,20
• Déterminer les facteurs d’ajustement (FA) : VTA = Produit (Fai), (i de 1 à 15)
• Calculer la charge nette : MHN = MHB*VTA
Passage des charges aux coûts

• Une fois connus le prix unitaire et la charge, on peut
calculer les coûts prévisionnels.
A titre indicatif :
Type de fonction Prix Unitaire Charge prévue Coût prévisionnel
Chef de Projet
Expert
Concepteur
Analyste
Programmeur
Opérateurr
Secrétaire
Documentaliste
Moyenne
Démarche pour l ’estimation des projets de
développement logiciel
• Démarche empirique:
– Estimer la charge de travail liste des programmes à réaliser
de l ’étape de réalisation seule ratios de réalisation par type de programme
– Calculer à partir de ce chiffre ratios d ’étude préalable, étude détaillée,

la charge de travail pour recette et mise en oeuvre
les autres étapes
– Calculer à partir de la charge règle de la « racine carrée »

totale : l ’effectif et la durée optimaux
Charge de travail de l ’étape de réalisation seule (1)
Lister ou compter grossièrement les programmes à réaliser :
• par type de programme

– transactions de saisie, transactions de consultation seule
– module de calcul, batchs de mise à jour
– programmes d ’édition
• par niveau de complexité :

– simple ( un seul fichiers lu/écrit, contrôles « standards »)
– moyen (deux ou trois fichiers lus/écrits, quelques contrôles et calculs spécifiques)
– complexe (nombreux fichiers accédés, contrôles, calculs et enchaînements)
• Exemple : pour réaliser l ’application X, il faut environ 22 programmes

– 5 transactions de saisie simples
– 1 transaction de saisie complexe
– 3 transactions de consultation moyennes
– 2 modules de calcul moyens
– 2 batchs de mise à jour moyens
– 8 éditions simples
– 1 édition complexe
Charge de travail de l ’étape de réalisation seule (2)
Appliquer des ratios de réalisation standards en jours-homme, pour chaque niveau de complexité (si nécessaire
pour chaque type de programme). Exemple :
– 2 j*h pour un programme simple, 5 j*h pour un programme moyen, 15 j*h pour un programme complexe
Les ratios utilisés devront :

– comprendre la réalisation seule (sans les études, la recette et la mise en œuvre)
– comprendre toute la réalisation (codage, commentaires, tests programmeur)
– être commun s à tous les projets
– correspondre à la performance d ’un programmeur « moyen »
– être issus de l ’expérience de projets précédents, et remis à jour en fonction des techniques de programmation
(COBOL/SINDIA, AGL, ORACLE/D2000…)
Exemple : pour réaliser l ’application X, il faut environ 90 jours * homme

– 5 transactions de saisie simples x2 j = 10j
– 1 transaction de saisie complexe x 15 j =15j
– 3 transactions de consultation moyennes x5j = 15j
– 2 modules de calcul moyens x5 j = 10j
– 2 batchs de mise à jour moyens x5j = 10j
– 8 éditions simples x2 j = 16j
– 1 édition complexe x15 j = 15j
Charge de travail des autres étapes
Appliquer des ratios standard pour les autres étapes du projet
– 10% de la charge de travail de réalisation pour l ’étude préalable
– 40% pour l ’étude détaillée
– 20% pour la recette (avec les tests de recette)
– 30% à 80% pour la mise en œuvre selon la difficulté (déploiement, reprise des données, formation …)
Approximations utiles :
– la charge d ’étude est la moitié de la charge de réalisation
– la charge totale du projet est le double de la charge de réalisation
Exemple : pour mener tout le projet de développement de l ’application X, il faut environ

180 jours-homme
– 90 jours pour la réalisation
plus
– 9 jours pour l ’étude préalable (10%)
– 36 jours pour l ’étude détaillée (40%)
– 18 jours pour la recette (20%)
– 27 jours pour la mise en œuvre (30% pour une reprise des données et un déploiement faciles )
Ressources à affecter et délai (1)

• Règle empirique de « la racine carrée » : pour mener un projet
de N mois * homme, il faut mobiliser
– une équipe comprenant au maximum « racine carrée de N » informaticiens
– sur une durée d ’au moins « racine carrée de N » mois
• Si l’on veut mener le projet sur une durée inférieure, il faut y
affecter un plus grand nombre d’informaticiens : l’expérience
montre qu’il est alors difficile de les coordonner sur une durée
aussi courte; le projet risque l’échec.
Ressources à affecter et délai (2)

Exemple :
• pour mener le projet de développement de l’application X, il faut
180 jours*homme, soit 9 mois-homme (1 mois*homme= environ
20 jours*homme)
et mobiliser
• une équipe de 3 informaticiens au maximum

• sur une durée d’au moins 3 mois
Ordonnancement des étapes
• Définitions
• Diagramme de Gantt
• Liens entre tâches
• Techniques de planification
• Planification par les tâches PERT - Temps
• Planification par les tâches PERT - Charges
Activité de Planification / Ordonnancement des étapes
Définitions
• But :
– Maîtriser les problèmes d ’articulation et de synchronisation entre les
différents sous-ensembles à réaliser.
• Procédé :
– Déterminer les priorités ou les parallélismes possibles entre l ’exécution
des diverses tâches ou missions précédemment identifiées.
• Besoins : le chef de projet doit connaître :

– Les difficultés inhérentes à chaque tâche.
– Les techniques et outils de réalisation des tâches.
– Les techniques d ’ordonnancement.
• Techniques: GANTT, PERT, Potentiels, etc.

Diagramme de Gantt(1)
Principes :
• Un diagramme de Gantt = tableau à deux dimensions :
– En abscisses, l ’écoulement du temps depuis le début du projet.
– En ordonnées :
• soit les tâches,
• soit les moyens de production,
• soit les ressources humaines.
Diagramme de Gantt(2)
Les tâches sont représentées par des « barres » horizontales de
longueur proportionnelle à leur durée.
0 1 2 3 4 5 6 7 8
Tâche A
Tâche B
Tâche C
Tâche D
Tâche E
0 1 2 3 4 5 6 7 8
Moyen 1 A B
Moyen2 D E
Moyen 3 C
Liens entre tâches (1)

Les techniques de planification de tâches et des ressources
s ’appuient sur 2 types de représentation :
– Méthode des Potentiels
– Méthode PERT (Project Evaluation & Review Technique)
Pert
Date début Date fin
Activité

Fin à Début ( 85% des cas )
A B B peut débuter lorsque A est terminée
ex : A = pose charpente, B = Couverture
A Début à Début ( 5% des cas )
B peut débuter lorsque A est commencée

B
ex : A = série d ’interview, B = Compte rendus
A Fin à Fin ( 5% des cas )
B peut se terminer lorsque A est terminée

B ex : A négociation, B Préparation d ’un contrat
Début à Fin ( 5% des cas )
B A B peut se terminer lorsque A est commencée
ex : A = Exploitation nouveau système,

B = Exploitation ancien système
A Délai + ( Retard ou « Lag » )
B B peut débuter un jour après le début de A
ex : A= série d ’interview, B= Comptes Rendus
A Délais - ( Avance ou « lead » )

-1 j
B peut débuter un jour avant la fin de A
B
ex : A= pose charpente, B= couverture
Nota : l ’avance ou le retard sont parfois exprimés en % de la tâche

antécédente.
Liens entre tâches (5) - Exercice
1) « Tant que A n ’est pas terminée, B doit se poursuivre »
2) « Tant que A n ’est pas terminée, B ne peut pas commencer »
3) « B doit se poursuivre Tant que A n ’est pas commencée»
4) «A ne peut pas commencer Tant que B n ’est pas démarré »
5) «à 50% de A, B peut démarrer »
Liens entre tâches (5) - Corrigé

1) « Tant que A n ’est pas terminée, B doit se poursuivre » A
Fin à Fin
B
A
2) « Tant que A n ’est pas terminée, B ne peut pas commencer » Fin à Début
B
A
3) « B doit se poursuivre Tant que A n ’est pas commencer » Début à Fin
B
A
4) «A ne peut pas commencer Tant que B n ’est pas démarré» Début à Début
B
A A
5) «à 50% de A, B peut démarrer » + 50%
B B
Début à Début Fin à Début
Techniques de planification
• Deux approches symétriques :

– Planification par tâches : partir de tâches puis organiser les
ressources au mieux
– Planification par les ressources : partir des ressources

disponibles puis organiser les tâches au mieux
• Point commun : la logique d’enchaînement des tâches
Planification par les tâches PERT-Temps (1)

Préalables
–Logique « métier » d’enchaînement des tâches
–Les durées des tâches
4 étapes
• "dates au plus tôt " : si le projet démarre à t0, quand se termine-t-il
au plus tôt ?
• "dates au plus tard " : si le projet doit se se terminer à tf, quand
doit-t-il commencer au plus tard ?
• " marge " : pour une tâche, différence entre date de début au plus
tard et date de début au plus tôt
• " chemin critique " : ensemble des tâches de marge nulle
Planification par les tâches PERT - Temps (2)

B
A 20 D
10 C 10
10
Au plus tôt MARGE
A Au plus tard 0
A B
0
B
C +10
C
D
D 0
T0 T0+10 T0+20 T0+30 T0+40

Tf-40 Tf-30 Tf-20 Tf-10 Tf
Planification par les tâches PERT - Charges (1)
• La technique PERT - Charges est une extension de la technique PERT-

Temps qui permet de prendre en compte les ressources affectées au projet.
• Dans un projet, le terme « Ressources » désigne un moyen nécessaire au

déroulement et à l ’aboutissement d ’une tâche :
– une personne
– une équipe
– un service de l ’entreprise
– un sous traitant
– une machine
– un stock
– un budget

R2 100%
B
R1 100% R2 100%
20
A D
10
10 C 10
R1 100%
AU PLUS TOT
A
B
C
D
t0 to+10 to+20 to+30 to+40

100%
R1 A A C C
100%
R2 B B B B D D
Même démarche par AU PLUS TARD
PERT-Temps :
- Maître d’œuvre qui sous traite au forfait
PERT-Charges :
- Maître d ’œuvre qui utilise des ressources internes
- Permet d ’anticiper les moyens supplémentaires en début de projet
(recrutements, etc.).
- Très utile pour l ’établissement d ’un tableau de marche
prévisionnel : la référence
- Lissage peu pratique et peu pratiqué en Mise à jour périodique
Planification des tâches

• But :
– Représentation calendaire de l ’enchaînement des tâches.
• Critères de performance :
– L ’expérience personnelle du chef de projet.
– Le nombre de personnes par équipe (7 à 10 maximum )
– La gestion du temps est plus aisée que la gestion des hommes.
• Règle pratique de la « Racine Carrée »
– C= T * D, où C: charge totale du projet, T: taille moyenne de l ’équipe et D : durée

totale du projet
où :
– C/n  T  C T: taille moyenne idéale, D : durée totale idéale (en mois)
n : contrainte de délai, avec 2 n
– C  T  n* C n = 2 , si la contrainte de délai est forte
n = 4, si la contrainte de délai est faible
Établissement des prévisions de charges

• Établir un budget, un compte d ’exploitation et une trésorerie
prévisionnels.
• Positionner avec précision les points de contrôle correspondant aux

périodes d ’activités successives.
• Valider dès le départ, la rentabilité attendue du projet.
• Vérifier que dette rentabilité se maintient.
Qualification de l’équipe de projet
• Mettre en place une structure, généralement hiérarchique, de

fonctionnement.
• Assurer la meilleure communication entre le chef de projet et ses

collaborateurs.
• Assurer la meilleure communication entre les collaborateurs ayant

à atteindre les objectifs communs. (Transmission des documents,
remise de comptes-rendus, relation avec l ’extérieur, etc.).

Ch2 - Activité de Planification

Transféré par

Droits d'auteur :

Formats disponibles

Ch2 - Activité de Planification

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ch2 - Activité de Planification

Transféré par

Droits d'auteur :

Formats disponibles

•Département : Informatique

•Module : Gestion de projet

Gestion de projet : Chapitre 2

• Les bases de la gestion de projet

• Activité de Planification Projet

•Le client •Le fournisseur

 Le rôle de la MOA  Le rôle de la MOE

Délimitation du Projet (1)

• Étudier les clauses techniques du contrat

• Établir une liste des principales activités à réaliser

• Établir une liste des principales prestations à servir

• Distinguer les responsabilités du maître d ’œuvre et

celles du maître d ’ouvrage.

Délimitation du Projet (2)

Délimitation du Projet (3)

Détermination des Activités (1)

• Organigramme des Produits

• Organigramme des Tâches

• Organigramme des Ressources

• Les modèles de développement

Principes du découpage (1)

Principes du découpage (2)

Les modèles de développement (1)

Cycle de vie classique Intervenants

Les modèles de développement (2)

Les modèles de développement (3)

Etude d’opportunité Mise en oeuvre

Etude fonctionnelle et prototypage Recette Utilisateur

Conception technique globale Tests d’intégration

Conception technique détaillée Tests Unitaires

Les modèles de développement (4)

Une version allégée Confirmation ou affinement

du prototypage est des spécifications

Estimation des charges

Conditions d’une estimation sérieuse

• Borner les ambitions de l’utilisateur / client

• Une définition assez précise des fonctions à réaliser

• Une bonne connaissance des contraintes

• Des standards liés aux méthodes

• Une méthode d’estimation

Les méthodes d ’estimation(1)

Les méthodes d ’estimation (2)

Les méthodes d ’estimation (3)

Les méthodes d’estimation (4)

• Le consensus : (Technique DELPHI)

Les méthodes d ’estimation (5)

Les méthodes d ’estimation (6)

Séquences d ’étapes d ’estimation (1)

2. Analyser les données anciennes, expériences précédentes

3. Valider les données anciennes

4. Définir un cycle de vie pour le projet

5. Identifier les spécialistes nécessaires

6. Identifier les contraintes majeures du projet

Séquences d ’étapes d ’estimation(2)

8. Évaluer les compétences de l ’équipe (COCOMO)

9. Évaluer l ’environnement (COCOMO)

10. Évaluer les méthodes (COCOMO)

11. Évaluer les langages de programmation (PFA)