Maitrise d'ouvrage et maitrise d'oeuvre dans la conduite des projets informatiques

Maîtrise d’ouvrage et
maîtrise d’œuvre dans la
conduite des projets
informatiques

---

Définitions Maîtrise d’œuvre MOE
 Maître d’œuvre Prime Contractor
 Personne morale (entreprise, direction etc.) garant
de la bonne réalisation technique des solutions. Il a
un devoir de conseil vis-à-vis du Maître d’ouvrage.
En cas de pluralité de fournitures, il veille à leur
cohérence et à la qualité des interfaces. Il
coordonne l’action des fournisseurs en optimisant la
qualité technique, en minimisant les risques et en
assurant le respect des délais fixés par le Maître
d’ouvrage. Il valide la recette technique des
solutions.

---

Définition Maîtrise D’ouvrage MOA

Maître d’ouvrage Customer

Personne morale (entreprise, direction etc.) chargée d’une
mission. Le maître d’ouvrage est responsable de l’efficacité de
son organisation, de ses méthodes de travail et de son système
d’information. Il fait appel à des maîtres d’œuvre* pour obtenir
les solutions qui lui permettent de réaliser sa mission. Il leur
fournit les spécifications fonctionnelles, et valide la recette
fonctionnel e de ces solutions.

Les fonctions du maître d'ouvrage sont remplies par des
personnes ou des équipes : le maître d'ouvrage stratégique* est
le patron de la personne morale considérée ; le maître d'ouvrage
délégué* est l'expert qui assiste le maître d'ouvrage stratégique
pour lui permettre d'exercer ses responsabilités ; le maître
d'ouvrage opérationnel est un expert spécialisé dans
l'automatisation d'un processus (Voir ci-dessous les définitions).

---

Définition Maîtrise d’ouvrage
délégué
 Maître d'ouvrage délégué Business Technologist
 Le maître d’ouvrage délégué (MOAD) est une
personne, soit seule, soit à la tête d’une équipe, qui
veille à la qualité du SI de l’entité tant du point de
vue de la conception que de la façon dont il est
utilisé. Il assiste le maître d’ouvrage stratégique en
lui fournissant les éléments nécessaires à la
décision et à l’alignement stratégique du SI.
 Ses interlocuteurs naturels au sein de l’entité sont
les chefs de service et les maîtres d’ouvrage
opérationnels. Son interlocuteur naturel au sein de
la direction informatique est le responsable de
domaine

---

Définition Maîtrise d’ouvrage
opérationnel
 Maître d'ouvrage opérationnel
 Le maître d’ouvrage opérationnel (MOAO)
est, dans l’entité, un expert qui connaît à fond
l’un des grands processus du métier. Il
recueille les demandes des utilisateurs et
établit ou supervise les spécifications
générales. Il a pour interlocuteur naturel à la
direction informatique le chef de projet
maîtrise d’œuvre*.

---

Définition Maîtrise d’ouvrage stratégique

Maître d'ouvrage stratégique

Le maître d’ouvrage stratégique (MOAS) du SI d'une entité est le
dirigeant de cette entité : PDG ou DG pour l’entreprise, DGA ou
directeur pour une direction de l’entreprise, chef de service pour
les unités qui constituent la direction etc. Le SI étant à la fois la
concrétisation de la stratégie et la condition de sa mise en
œuvre, le MOAS prend les décisions essentiel es concernant la
maîtrise d'ouvrage (notamment pour le lancement des grands
projets). Il arbitre les différends entre ses collaborateurs et signe
le contrat avec la maîtrise d'œuvre.

Le MOAS n’est pas, en général, un expert en matière de SI. Il se
fait assister par un maître d’ouvrage délégué (MOAD) auquel il
délègue (c’est le sens même de l’expression) l’expertise en
matière de SI.

---

Missions de la maîtrise d’ouvrage
 Assurer la pertinence du SI en regard des
priorités du métier, de la « stratégie »
 Suivi et contrôle de la mise en œuvre du SI
 Spécification fonctionnelle des évolutions et
suivi des projets
 Déploiement et formation des utilisateurs

---

Missions de la maîtrise d’œuvre
 Assurer l’exploitation de la plate-forme
informatique
 Performance, disponibilité, support aux
utilisateurs
 Assurer l’évolution du SI
 Qualité des développements, recette, mise en
exploitation

---

Spécifications
 Spécifications générales (modèle métier)
 Responsable : MOA
 Spécifications détaillées (modèle d’analyse)
 Responsable : MOE, validée par MOA
 Spécifications techniques (modèle technique)
 Responsable : MOE

---

Maîtrise d’ouvrage
Maîtrise d’oeuvre
Modèle métier
Modèle d’analyse
Modèle technique
Maîtrise d’ouvrage
Maîtrise d’oeuvre
Production
Validation

---

MOA / MOE

---

Nouvelles relations entre
maîtrise d’ouvrage et
maîtrise d’œuvre

---

Nouveaux rôles
 L ’entreprise s ’organise autour des processus et
des composants
 Les métiers modélisent leur système d ’information
 Le système d ’information s ’ajuste pour équiper
les processus des métiers
 Émergence de la « maîtrise d ’ouvrage »
Organisation et sémantique : des règles simples
aux applications diversifiées
 Professionnalisation de la maîtrise d ’ouvrage et
de l ’informatique

---

Nouveaux rôles
 Généralisation de l ’assisté par ordinateur

Articulation de l ’homme organisé et de l ’automate programmable
 Un nouveau professionnalisme de la MOA...

Équiper la stratégie d ’entreprise

Élucider les processus des métiers

Veille SI
 … en relation avec celui de l ’informatique

Solide plate-forme technique

Maîtrise des coûts

Veille techno : langages, middleware, solutions,

Maîtrise des fournisseurs

---

Principes de la MOA
 Axes fondamentaux
 Sobriété
 Fermeté et disponibilité
 Esprit de coopération
 Méthodes
 Spécifications, validations, qualité de la validation
 recettes, déploiement

---

Problèmes essentiels
 Priorité : « domaines » ou « projets » ?
 Frontière de l ’externalisation
 Maîtrise de la diversification des
compétences techniques
 Vers un nouveau type d ’entreprise

---

Relation entre la maîtrise
d’ouvrage et ses utilisateurs

---

Relation MOA - utilisateurs
 2 utilisateurs : « terrain » et « concepteur »
 étapes de la relation :
 expression des besoins,
 recette fonctionnelle,
 formation,
 déploiement,
 conduite du changement,
 aide aux utilisateurs,
 exploitation technique de proximité

---

Étapes de l’expression des besoins
 Expression informelle
 Validation par les responsables
 Formalisation du besoin
 Convergence MOA
 Convergence MOA-MOE

---

Formalisation du besoin
 vers la modélisation métier
 professionnalisation du maître d'ouvrage
 transcription de la stratégie de l'entreprise
dans le système d'information

---

Modèle UML
Présentation stratégique
Présentation des processus
Explication de la modélisation
Modèle formel

---

Convergence MOA
Expression
Modèle
des besoins
formel
E1
M1
E2
M2
E3
E
M
stabilisée
stabilisé
cohérence
temps
En : n-ème expression des besoins
M
Premier modèle

n : n-ème version du modèle formel

métier livrable

---

Convergence MOA-MOE
Maîtrise d’o A
uvr N
ag P
e E
Maî A
tr T
i O
se S
d’œuvre
M1
Q1
M2
Q
M
2
3
temps
Mn : n-ème version du modèle
Qn : n-ème émission de remarques
Modèle métier
stabilisé

---

Suite de l ’histoire
 modèle métier -> modèle d ’analyse
 (spécifications générales -> spécifications
détaillées)
 modèle d ’analyse -> modèle technique
 (specs détaillées -> specs techniques)
 specs techniques -> développement
 etc.

---

Qualité Logiciel
 AFNOR X50-151 : Cahier des charges
Fonctionnel
 ISO9001/ISO 12207 :Cycle de vie du Logiciel
 ISO15504 : L’assurance qualité

---

Qualité Logiciel
 La maîtrise de la qualité à pour objectifs
pratiques de réduire les coûts par la
réduction des dysfonctionnements et par
la même de garantir une régularité de
production. La maîtrise de la qualité
implique en premier lieu la maîtrise des
processus d'ingénierie du logiciel. Celle-ci
se base désormais sur la normalisation
ISO 15504 ou CMM qui représente
actuellement l’état de l’art

---

ISO 15504

L’assurance qualité « ISO 15504 - CMM »

Dans une organisation impliquée dans la normalisation de sa
chaîne de production de logiciel, la notion de Plan Qualité
s’applique à l’organisation. La notion de Plan d’assurance
Qualité s’applique toujours au projet et correspond à un
document décrivant le protocole du projet en incluant les points
suivants :

la formalisation des Exigences et des contraintes du projet,

l’organisation de la communication,

la précision de la méthodes et du processus de production,

la description des livrables et des conditions de recette à chaque
étape,

la planification de contrôles systématiques de qualité appliqués
aux livrables.

---

ISO 15504
La documentation ISO 15504 se compose de 9 parties auxquelles correspondent autant de documents :
· 1 - Introduction aux concepts fondamentaux.
· 2 - Modèle de gestion de l’ingénierie des processus.
· 3 - Processus d’évaluation du niveau d’aptitude.
· 4 - Guide de conduite de l’évaluation.
· 5 - Modèle d'évaluation, guide des indicateurs, outils.
· 6 - Guide pour la qualification des évaluateurs.
· 7 - Guide de mise en œuvre de l’amélioration des processus.
· 8 - Guide de détermination des aptitudes des fournisseurs.
· 9 - Dictionnaire, vocabulaire et terminologie.
La figure suivante décrit les principes d’interaction des 9 parties.
A ces 9 parties s'ajoute un fascicule de documentation, élaboré en France, dont l'objet est de présenter de manière
synthétique l'utilisation de la norme.

---

Critères qualité d’un Logiciel

l'adaptabilité mesure l'aptitude du logiciel à faciliter l'adjonction de nouvel es
fonctionnalités ou la modification de fonctionnalités existantes (cet aspect couvre
la correction des défauts provenant d'une mauvaise expression des besoins),

la confidentialité mesure l'aptitude d'un logiciel à être protégé contre tout accès
non autorisé ,

la correction mesure le degré de conformité par rapport aux spécifications,

la couplabilité mesure l'aptitude d'un logiciel à être intégré dans un ensemble
plus vaste,

l'efficacité mesure l'aptitude d'un logiciel à minimiser la consommation des
ressources qu'il utilise,

l’ergonomie mesure l'aptitude d'un logiciel à être d'une utilisation agréable et
facile pour l'utilisateur à qui il est destiné,

la maintenabilité mesure l'aptitude d'un logiciel à faciliter la localisation et la
correction d'erreurs résiduel es (il s'agit bien là de correction de défauts de non-
conformité par rapport aux spécifications et non de défauts provenant d'une
mauvaise expression des besoins),

la portabilité mesure l'aptitude du logiciel à minimiser les conséquences d'un
changement d'environnement technique,

la réutilisabilité mesure l'aptitude du logiciel à une réutilisation de tout ou partie
de ses composants dans le cadre d'un autre projet,

la robustesse mesure l'aptitude du logiciel à conserver un comportement
conforme aux besoins dans le cas d'événements imprévus,

la testabilité mesure l'aptitude d'un logiciel à faciliter la vérification de son
comportement par rapp
ort à des critères de test et de recette.

---

Qualité Logiciel
 L’assurance qualité regroupe l’ensemble de ces
préoccupations dans un cadre générique dont
l’aboutissement opérationnel peut s’exprimer par la
production d’un document spécifique à un projet
particulier : le plan d’assurance qualité. Ce plan est
constitué de la description systématique des
conditions d’exécution du projet et du pilotage
permanent des processus. L’adaptation permanente
de ces deux activités s’effectue dynamiquement par
l'élimination des défauts ou des déviations mis en
évidence lors de leur exécution.
Une responsabilité formel e doit être chargée des
activités d'assurance qualité.·

---

Assurance Qualité

Qualité applicative et qualité technique
En termes de qualité de la production, il importe de dissocier la qualité
applicative de la qualité technique.

La qualité applicative se mesure par le degré de satisfaction de l’utilisateur à
l'égard :

de la couverture fonctionnel e de ses besoins réels,

de l’ergonomie générale et des facilités d’appropriation,

des temps de réponse de l’application,

De divers autres facteurs d’appréciation.

La qualité technique est un ensemble de critères qui couvre :

le nombre de « bugs » résiduels,

la lisibilité du code et sa documentation,

la concision des modules programmés,

’unicité et la hiérarchisation des fonctions internes,

la non-redondance des appels de fonctions,

la réduction des parties d’interfaces similaires,

la généralisation et la sécurité des procédures d’erreur.

---

Assurance Qualité

Une direction des études informatiques soucieuse de sa
performance s'attache à définir, préalablement à chaque projet,
son niveau de besoin en terme de suivi et de qualité. Cette
notion de « niveaux de services » recouvre entre autres :

le niveau de conduite de projet,

le niveau de levée des risques,

le niveau de qualité documentaire,

le niveau de qualité applicative.

Les deux liste suivantes présentent un exemple plus détail é de
cette vision « à la carte » de la rigueur « juste nécessaire » que
requiert la qualité assujettie à des conditions de performance
économique.

---

Assurance Qualité
1. Niveau de service « projet »
 Planification et suivi de l'avancement.
 Planification et suivi des risques.
 Planification et suivi de la sécurité.
 Formalisation des activités de conduite de projet.
 Formalisation de la gestion des changements.
 Formalisation de la gestion de la configuration.
 Formalisation de la gestion des tests.

---

Assurance Qualité
2. Niveau de service « application »
 Production de l'application, qualité
technique.
 Production de l'application, qualité
fonctionnelle.
 Production de la documentation technique.
 Production de la documentation d'utilisation.

---

ISO 12207
 La norme ISO 12207 établit un référentiel pour les
processus associés au cycle de vie des produits
logiciels et ceci avec une terminologie bien définie,
pour l’industrie du logiciel. La norme contient des
processus, activités et tâches qui se doivent d’être
appliqué lors de l’acquisition d’un système
contenant des composantes logiciels, d’un produit
logiciel ainsi que lors des services informatiques
pour les étapes d’approvisionnement, de
développement, de mise à disposition et de
maintenance des ces produits logiciels. La norme
propose également un processus afin de définir,
contrôler et améliorer les processus du cycle de vie
des produits logiciels.

---

ISO 12207

La norme présente trois groupes de processus qui sont requis
durant le cycle de vie des produits logiciels. Pour chacun des
processus, un ensemble d’activités y est décrit et pour chaque
activité, un ensemble de tâches. Voici maintenant une courte
description des trois groupes:

Le premier groupe constitue les processus primaires du cycle de
vie et contient les processus suivants : acquisition,
approvisionnement, développement, mise à disposition et
maintenance.

Le deuxième groupe comprend les processus de support qui
sont: la documentation, la gestion de la configuration,
l’assurance qualité, la vérification, la validation, les revues
conjointes, les audits et la résolution des problèmes.

Finalement, le troisième groupe contient les processus
organisationnels qui sont: gestion, organisation, amélioration et
formation.

La norme est applicable pour l’acquisition de systèmes, de
produits et de services logiciels qui peut comprendre les étapes
d’approvisionnement, de développement, de mise à disposition
et finalement de

maintenance, autant à effectuer au sein de
l’entreprise qu’à l’extérieur.

---

ISO 12207

Quels sont les avantages?

La norme ISO 12207 permet de sélectionner les processus, les
activités et les tâches qui sont applicables pour des projets
spécifiques. Elle permet la mise en place et l’amélioration
continue des processus nécessaires, au sein de l’entreprise
ainsi qu’à l’extérieur de l’entreprise, pour les différentes étapes
de développement et de maintenance des produits logiciels.

Quelles sont les limites?

La norme ISO 12207 définit une architecture des processus
requis mais ne spécifie pas les détails d’implantation ou
d’exécution des activités et des tâches qui sont incluses dans
les processus. Elle ne prescrit pas le nom, le format et de façon
explicite le contenu des documents à produire et ne prescrit pas
un modèle de cycle de vie ou de méthodologie de
développement.

Quels sont les coûts associés?

Les coûts de formation sont estimés à $ 1,5K par personne pour
une formation d'une durée de trois jours. L'élaboration des
processus peut prendre de 40 à 100 heures par processus.
Sans oublier les frais reliés au support externe, qui peuvent
atteindre entre $ 30K et $ 75K.

---

Traçabilité

La traçabilité est une procédure visant à suivre automatiquement
un produit ou un service depuis sa naissance jusqu'à sa
valorisation finale

L’objectif premier de la traçabilité est de pouvoir identifier un
produit, un lot de produits ou encore un service afin de pouvoir le
retirer très rapidement et avec un maximum de sécurité en cas
de non conformité, de danger.

La traçabilité offre également l’avantage de pouvoir intervenir en
amont de la distribution en permettant par exemple de contrôler
la qualité du produit depuis l’origine des ses matières premières.
Ce qui autorise une nette diminution des coûts de non qualité
intervenant traditionnellement sur les produits finis.

De nombreuses statistiques peuvent ressortir d’une traçabilité,
très utile pour un service S.A.V. ou un service marketing. Les
flux de matières premières, de produits finis sont également
mieux identifiés.

En résumé, la traçabilité permet d’améliorer la qualité, le service
et l’efficacité global e d’une entreprise.

---

Maintenance

---

Maintenance Préventive
La maintenance préventive est axée sur la correction des défauts
des applications, en vue de minimiser le risque d'une répétition des problèmes.
La maintenance corrective apporte des solutions ponctuelles pour garder les
applications en fonction, tandis que la maintenance préventive fait l'analyse
détail ée des problèmes récurrents et s'attaque aux « causes profondes ».
Les interventions de maintenance préventive comprennent la restructuration
des codes sources, la réorganisation des bases de données et la réécriture des
programmes. Maintenance pour l’amélioration
La maintenance pour l’amélioration est un processus d'amélioration continuelle
qui a pour but d'optimiser le rendement d'une application. Ce genre de maintenance
produit une application à haute performance, stable, qui procure un degré élevé
de satisfaction des utilisateurs.

---

Maintenance Corrective
La maintenance corrective consiste à réparer
les défauts qui empêchent une application
de traiter correctement les données ou de
produire des résultats exacts. Elle consiste à
régler des problèmes opérationnels ou à
corriger des anomalies qui entravent
l'exécution d'un processus. La maintenance
corrective exige un soutien 7 jours/24 heures,
afin de maintenir les applications à leur
efficacité maximale.

---

Maintenance Adaptative
La maintenance adaptative a pour but d'améliorer
constamment les applications selon l'évolution des
besoins de l'entreprise. Les améliorations peuvent
prendre diverses formes : les mises à niveau
logicielles, les modifications exigées par la
réglementation, l’intégration de systèmes, etc.
La maintenance adaptative s’assure que les
applications progressent au rythme des changements
constants qui surviennent, que ceux-ci soient d'origine
commerciale, technologique ou réglementaire.

---

Récapitulatif de Méthodes de gestion de
projets informatique
 1. Les origines
 2. Notion de projet et caractéristiques d'un projet
 3. Lancement d'un projet et évaluation d'un projet
 4. Les causes d'échecs et la perte de contrôle
 5. Le triangle projet : les objectifs, les délais, les
moyens
 6. Parmi les moyens : les acteurs
 7. Le contexte psychologique, motiver l'équipe de
projet

---

Les origines
 années 1950 : réflexion pour les grands projets
industriels (aéronautique,
 armement, travaux public)
 aujourd'hui : projets de plus en plus importants
 besoin de méthode : constat d'échec et situation de
crise (coûts, délais,non-fiabilité...)
 influence organisationnelle : certaines organisations
se structurent en mode projet

---

Outils de gestion de projets informatique
 1. Le contexte de la gestion de projet
 2. Découper pour estimer
 3. Estimer pour planifier
 4. La planification du projet
 5. Le suivi et le contrôle

---

Caractéristiques d’un projet
 une action unique et ponctuel e, non répétitive
 limité dans le temps : dates de début et de fin
 une démarche spécifique : atteindre l'objectif en
maîtrisant la qualité du produit fini, les coûts et les
délais grâce à des étapes et des jalons
 mobilise des compétences multiples et
complémentaires

---

Lancement d’un Projet
 Avant acceptation ou lancement, se poser
des questions :
 Toute difficulté identifiée devra faire l'objet
d'un dialogue approfondi avec le demandeur
pour soit annuler, infléchir ou différer le projet
soit négocier des moyens de réussite à la
hauteur des enjeux et des conditions de
réussite identifiées.

---

Evaluer un projet
 Évaluer sous différents angles :
 Evaluer par le résultat attendu et les enjeux
générateur de résultats économiques ?
 initiateur de changements dans les structures et
comportements ?
 Evaluer par la pertinence de la demande : est t-elle
mûre ?
 identifier le demandeur (initiateur,
décideur,destinataire)
 cerner la demande : demande énoncée
clairement,nature de la demande, cadre de la
demande, les délais
 Evaluer par la cohérence du projet dans le contexte
de l'organisation
 Evaluer par la conduite de projet

---

Causes des Echecs
 Côté utilisateur
 l'incapacité à dialoguer entre partenaires
 la mauvaise dénition des objectifs
 l'absence d'implication des utilisateurs
 le manque de qualité du produit livré
 l'absence de calcul des risques

---

Causes des Echecs
 Côté fournisseur
 mise en oeuvre de moyens inadaptés
 contraintes de délais, charges et coûts
 démotivation de l'équipe
 absence d'outils

---

Perte de contrôle
 Quelques symptômes :
 perte de contrôle sur certains responsables
 on ne peut plus s'engager sur la date de
livraison
 la qualité du produit en développement est
incertaine
 non-détection à temps des écarts de délai, de
coûts ou de conformité aux spécifications

---

Triangle Projet

---

Les Acteurs
Diversité d'acteurs et d'intérêts :
parmi les clients :
 les décideurs
 le chef de projet
 les usagers
parmi les fournisseurs :
 le chef de projet
 les concepteurs
 les équipes de fabrication

---

Les Acteurs

---

Les Objectifs
Quoi faire ?
 Définir le domaine couvert en termes de
fonctionnalités
 La difficulté réside dans les détails
techniques : temps de réponse d'un système
informatique
évolution des volumes traités
Difficulté à les prévoir en termes de
faisabilité, délais, et coûts

---

Motiver l’équipe Projet
Chaque acteur s'engagera d'autant plus que :
 le résultat de son action est visible
 le résultat envisagé est désiré
 sa confiance dans sa capacité à agir est grande
Provoquer ces trois facteurs :
 s'accorder sur le chemin à parcourir
 assurer la continuité du processus
 faire adhérer les équipes
 agir par la hiérarchie
 investir en ressources humaines, temps, argent

---

Découpage d’un Projet
 1. Pourquoi découper ?
 2. Principes du découpage
 3. Les difficultés du découpage
 4. Choisir une méthode de découpage
 5. Découpage PBS, WBS et OBS
 6. Découpage selon norme AFNOR

---

Découpage d’un Projet
 Faire face à la complexité des activités (diviser pour
régner)
 Aborder le projet en termes d'unités de fabrication
(Toujours se souvenir de l'objectif initial)
 Diminuer les risques de dérives (Cloisonnement des
activités)
 Affecter des activités aux acteurs
(Faire correspondre besoins et compétences)
 Ordonnancer
(Planifier le travail sur un calendrier)

---

Difficulté du découpage
 Identifier précisément les tâches
 Recenser les lots à fabriquer

---

Principe du découpage
 Objets du découpage : des éléments
autonomes
Méthodes courantes de découpage
 sur critère temporel : succession d'étapes et
de phases
 sur critère structurel : définition des modules

---

Choisir une Méthode de découpage
Méthodes générales
 1. PBS (Product Breakdown Structure)
 2. WBS (Work Breakdown Structure)
 3. OBS (Organisation Breakdown Structure)
Méthodes de conception spécique métier :
Exemple développements informatiques :
 Merise
 UML
Méthode plus spécifique, ex : Norme de conduite de projet
AFNOR Z67-101

---

Exemple WBS (Work)

division hiérarchique du travail global à réaliser en work packages, qui peuvent être estimés, planifés, et affectés à un responsable (personne ou service).

---

PBS
 Vue hiérarchique des composants, parties,
sous-parties,
 nécessaires à la construction du produit.

---

OBS
 hierarchie de l'organisation qui mène le
projet, qui permet de mettre en relation PBS
avec WBS pour identifier les responsabilités
vis-à-vis des work-packages.

---

Relation OBS/WBS

---

Synthèse WBS/OBS/PBS

La méthode est générale, et peut s'appliquer à tout projet.

Certaines spéficités du métiers ne sont pas prises en compte
(trop générale).

La structure hiérarchique arborescente favorise un découpage
récursif des éléments.

Dans la pratique, on utilise des patrons (templates) dénis pour un
type de projet donné.

Exemple : l'armée U.S. demande à ses sous-traitants de se
conformer

au WBS normalsé US MIL-STD-881

(http://www.defence.gov.au/dmo/esd/evm/DefAust5655.pdf)

---

Découpage temporel du projet
Méthode pour projets industriels

1. Étude de faisabilité
(analyse, recherche, études de terrain)

2. Définition des solutions
(représentation précise de l'objectif, solutions possibles)

3. Conception détail ée
(contrats de réalisation, cahier des charges fournisseurs)

4. Réalisation
(exécutions des contrats achevées par des recettes)
L'étape 4 occupe généralement 90% des efforts et dépenses

---

Estimer un Projet
Pourquoi estimer ?
 Cerner la durée du projet
 Déterminer les ressources à mettre en oeuvre
 Déterminer la faisabilité technique du projet
 Pouvoir négocier
 Éviter les dérives de coûts

---

Estimer a différents Niveau
Niveau projet
 déterminer enveloppe budgétaire
 poids du projet en termes d'effort
 estimation de la rentabilité
 évaluer une durée vraisemblable
Niveau étape
 planification précise
 calendrier des fournitures intermédiaires
 prévoir suivi de projet
 prévoir les montées/baisses en charge

---

Norme AFNOR pour estimer
Norme Z67-101 "recommandations pour la conduite de projets
informatiques" s'inspire de la méthode Merise et normalise le découpage
du processus de développement.

---

Méthode DELPHI
 Chaque expert donne anonymement une
estimation
 Les résultats sont rassemblés et exposés au
groupe
 Chaque expert argumente sur son estimation
 Les experts s'accordent sur une estimation
consensuelle

---

Méthode de répartition Proportionnelle

---

Méthode COCOMO

Soit t le nombre de mil iers de lignes de code livrées (sans les
commentaires). Le type de projet est alors :

tail e t type de projet

t < 50 simple

> 50 < 300 moyen

t > 300 complexe

La charge c et le délai d sont estimés par :
Type projet Charge en mois/homme Délai en mois

---

Méthode Pert

---

Méthode Gantt

---