4411 21 févr.

08

Belin Pierre
Berthoulat Rémi
Martinon Luc
Nguyen Anh‐Quan
Poizat François
Werlen Maxime
Carpentieri Giuseppe (EE)

PLAN DE MANAGEMENT DE PROJET

Rédacteur Maxime Werlen Date de création 18/02/2008 Version 2.28

Identification CERISE/GE/PMP Dernière modification 21/02/2008 État V
Objet Nom du validateur Maxime Werlen Visa

Date de validation 22/02/2008

Insa Lyon – IF 1/19

4411 21 févr. 08

Table des matières

I ‐ Introduction .......................................................................................................3
1. Suivi, références et conventions..........................................................................3
2. But, domaine d’application et responsabilités du PMP......................................3
3. Contexte du Projet..............................................................................................4
II ‐ Présentation du projet........................................................................................6
1. Liste des références contractuelles.....................................................................6
2. Enjeux économiques...........................................................................................6
3. Partage des responsabilités entre MOE et MOA................................................6
4. Procédures d'intégration des évolutions du PMP...............................................6
III ‐ Organisation du projet et structure décisionnelle..............................................7
IV ‐ Démarche de développement du système.........................................................8
1. Cycle de vie du système......................................................................................8
2. Décomposition Logicielle, Matérielle, Temporelle............................................10
V ‐ Supports méthodologiques et moyens à mettre en oeuvre..............................12
1. Support méthodologique..................................................................................12
2. Moyens matériels.............................................................................................12
3. Moyens logiciels...............................................................................................12
4. Moyens Humains..............................................................................................12
VI ‐ Les  contraintes...............................................................................................15
1. Contraintes liées à l'organisation.....................................................................15
2. Contraintes liées à la planification...................................................................15
VII ‐ Gestion de configuration au niveau système..................................................16
VIII ‐ Facteurs de risques .......................................................................................17
IX ‐ Organisation et documents de suivi.................................................................18
1. Les règles de suivi ............................................................................................18
1. Les outils utilisés...............................................................................................18
2. Les procédures de révision du planning............................................................18
X ‐ Bilan de projet système....................................................................................19

Insa Lyon – IF 2/19

4411 21 févr. 08

I ‐ Introduction 
1. Suivi, références et conventions

A Modalités de gestion du PMP
Ce document est destiné à être diffusé uniquement à l'intérieur de l'équipe de réalisation du projet et
de ses commanditaires. Seuls la MOA et la MOE sont habilité à lire ce document.
Ce document est susceptible d'être révisé par le chef de projet à tout moment. Chaque modification
importante fera l'objet d'un changement de version du document. Le document portera aussi la date
de dernière modification.

B Documents Applicables et documents de référence
Documents de référence :
● Plan type de Plan de Management de Projet
● Cours de Gestion de Projet (4IF)
● Cours de Génie Logiciel (3IF)
● « Documents complémentaires concernant l’estimation de charges »

Documents applicables
● Dossier de Gestion de la Documentation

C Terminologie
MOA : Maîtrise d'ouvrage (COPEVUE).
MOE : Maîtrise d'oeuvre (nous).
CdP : Chef de projet

2. But, domaine d’application et responsabilités du PMP

A But du document
Le PMP est un guide pour la réalisation du projet. Il s’agit d’un repère pour les personnes chargées
de mener le projet. Les objectifs de ce document sont multiples :
● Identifier & ordonnancer les activités/tâches
● Définir & adapter les méthodes de travail à appliquer
● Gérer les ressources, définir les responsabilités
● Organiser le projet, séquencer les tâches

Insa Lyon – IF 3/19

4411 21 févr. 08

● Définir un suivi des avancements

● Identifier les différents composants du projet
● Évaluer la charge et sa répartition
L'objectif du Plan de Management de Projet est de fournir l’assurance que le projet est géré
correctement. Il est une possibilité pour le client de voir quels mécanismes sont mis en place pour
conduire le projet. Il s’agit également d’un document qui permettra de valoriser le projet tout en
s’assurant qu’il est pourra être mené à bien.

B Domaine d'application
Le projet se limitera à la conception et la réalisation d'un système de maintenance et de surveillance
à distances de sites isolés (ici des réservoirs). La maintenance se limitera à la maintenance
matérielle des systèmes de surveillance et à l'envoi d'ordres de maintenance/remplissage pour les
réservoirs.

C Responsabilité du PMP
La responsabilité du présent document incombe au Chef de Projet de la MOA. Il s'assurera du bon
déroulement du projet tout au long de ce dernier.
Il devra également coordonner et piloter le travail des différents intervenants et sous-traitants du
projet. Il doit délimiter le champ du projet, spécifier les résultats à produire et garantir la réalisation
d’un système en conformité avec les attentes du client.
Le chef de projet assume l'entière responsabilité de la bonne réalisation du projet, et doit répondre à
des contraintes de budget, de délai et de bon fonctionnement de la future solution.
En cas de sous-traitance, le rôle du chef de projet est également de s’assurer du respect des
contraintes et des besoins du projet. Il doit mettre en place les validations pour les sous-systèmes. Il
pourra distribuer des responsabilités à ses collaborateurs, mais endossera toujours la responsabilité
finale face au client.

3. Contexte du Projet

A Champs du projet
Au vue des problèmes posés par la gestion de sites se trouvant dans des zones peu habitées et afin
de réduire les coûts logistique et d'améliorer la fiabilité dans l'exploitation de ces zones:
Le COPEVUE a décidé de développer un outil permettant la surveillance de sites se trouvant dans
des zones peu habitées et peu accessibles. Cet outil doit permettre a ces sites de rester autonomes
que ce soit du point de vue énergétique, des déchets etc...
(Le respect de cette autonomie est un des points très important du projet)

B Les objectifs
Dans le but de répondre au mieux au exigence engendrer par les conditions de travail de ces zones
isolées, il s'agit concevoir un système complet, autonome et générique de mesure et de surveillance

Insa Lyon – IF 4/19

4411 21 févr. 08

à distance de stations ainsi que le pilotage/configuration/maintenance à distance de ces stations. Le

résultat doit constituer une solution évolutive, autonome et fiable.

C Environnement opérationnel du système futur
Le futur système sera opérationnel dans de multiples environnements différents. Le projet étant de
réaliser un système de surveillance de sites isolés. L'environnement pourra être hostile : le grand
nord, une forêt...
La résistance à l'environnement fera l'objet d'un sous-projet matériel du projet.

D Limites du système concerné par le projet
Le système n'inclue pas la gestion des réservoirs pour leur remplacement, installation, entretien
régulier.. ni la gestion de la société de maintenance de ces réservoirs (remplissage, vidange).
Nous communiquerons avec cette société pour lui remettre des ordres de maintenance.

Insa Lyon – IF 5/19

4411 21 févr. 08

II ‐ Présentation du projet
1. Liste des références contractuelles
Pas de références contractuelles actuellement.

2. Enjeux économiques
L'enjeu économique pour la COPEVUE est la réduction du coût de surveillance de site isolés en
Europe. Le gain proviendra principalement de l'optimisation des tournées de maintenance des
réservoirs et de la surveillance par des humains de ces derniers.
Les risques encourus par le client sont assez faibles. Le seul point critique serait atteint si le système
informatique tombait en panne de façon durable et irréversible dans plusieurs années lorsque toute
expérience de surveillance pré-informatique aurait été oubliée. Il faudrait retrouver un système
manuel capable de palier aux défaillances du systèmes informatique.
Le délai de réalisation du projet est d'un an. Le produit devra être livré à la fin du mois de février
2009. La solution est sensée fonctionner pour une durée longue indéterminée.

3. Partage des responsabilités entre MOE et MOA
La MOE doit réaliser le projet grâces aux informations fournies par la MOA. La mise en service de
des applications se fera par la MOE avec l'appui du service technique de la MOA. La formation du
personnel initial de la MOA sera pris en charge par la MOE.
Le déploiement des stations se fera par la MOA avec l'aide au début de la MOE. Le MOA se charge
de la formation de ses nouveaux employés. La MOA doit répondre aux demandes d'informations de
la MOE dans le cadre du projet.

4. Procédures d'intégration des évolutions du PMP
Chaque modification majeure du projet fera l'objet d'un avenant au contrat initial. Cet avenant devra
être discuté par les deux parties et prendre en compte les modifications éventuelles de délais,
livrables, risques ou d'objectifs.

Insa Lyon – IF 6/19

4411 21 févr. 08

III ‐ Organisation   du   projet   et   structure

décisionnelle
Société de
maintenance

Réunions
régulières

Groupe de
Groupe projet de la COPEVUE
projet CdP CERISE + Équipe de gestion

spécification Concepteurs
Surveillants

Réalisation
Intégration
Technicien de intégrateurs
maintenance

Service IT Formation
formateurs

Maitrise d’ouvrage Maitrise d’oeuvre

COPEVUE CERISE
La COPEVUE et CERISE ont tous les deux des structure de gestion du projet.
● La COPEVUE met à disposition un groupe de travail sur le projet CERISE. Ce groupe est
constitué de divers intervenants de la COPEVUE (surveillants, administratifs, techniciens,
consultants, experts...). Ce groupe ne doit pas être trop grand (pas plus de 6-7 personnes) en
temps normal, élargie lors des jalons importants à une dizaine de personnes.
● Dans la société CERISE, le projet est piloté par le CdP entouré de son équipe de gestion
(Responsable qualité, ingénieurs consultants...)
Les deux entités forment le groupe de projet qui prend toutes les décisions importantes et mène les
revues régulières et veillent au respect des jalons.
Chaque structure s'entoure des ressources nécessaires : surveillants, techniciens et administratifs
pour la COPEVUE et ingénieurs, technicien et formateurs pour le société CERISE.

Insa Lyon – IF 7/19

4411 21 févr. 08

IV ‐ Démarche de développement du système
1. Cycle de vie du système
Le système suivra un cycle classique, « en V », qui est détaillé de la façon suivante :
- Cahier des Charges
- PAQP

Spécifications Validation
- Dossier Spécifications - Bilan de projet
- PAQL - Cahier de recette final
- Plan de validation
Conception
Intégration
Préliminaire
- Dossier de recette
- Dossier Conception 1
- Manuels utilisateurs
- Plan d’intégration
Conception
Test Unitaires
Détaillée
- Dossier de jeux
- Dossier Conception 2
d’essai détaillés
- Plan de tests unitaires

Codage

Sources
commentées

Chaque étape du cycle sera jalonnée.

On peut définir des phases de vie spécialisées pour notre projet :

● Phase 1: Analyse globale des besoins : Il s’agit de l’analyse des besoins globaux du
système. Une première planification du développement du système est effectuée (définition
des principaux choix organisationnels et techniques).
● Phase 2 : Architecture globale : Durant cette phase d'étude préalable a lieu l’analyse
détaillée des besoins du système. On esquisse la solution dans ses grandes lignes. Une
première version de l’architecture du système doit être fournie afin de définir un premier
dimensionnement des sous-projets (délais, budget...)
● Phase 3 : Spécification des sous-systèmes : Durant cette phase, le système doit être défini
jusqu’à un détail suffisant pour maîtriser sa réalisation (spécification du système et
définition détaillée de l’architecture fonctionnelle et technique). On découpe le projet en
sous ensembles (sous-projets) qui seront détaillés et planifiés.
● Phase 4 : Recherche des sous-ensembles : Cette phase consiste à obtenir (par achat ou
création) chaque sous-ensemble validé et conforme à sa définition en respectant les coûts et
les délais définis. Cette phase couvre donc la réalisation interne ou la coordination technique
pour l’acquisition de progiciel.
● Phase 5 : Intégration et validation du système : Lors de cette étape les sous ensembles
acquis lors de la phase 4 seront intégrés et validés. On veillera à réaliser des plans de tests
les plus proches possibles de l'exhaustivité !

Insa Lyon – IF 8/19

4411 21 févr. 08

● Phase 6 : Recette et installation sur site : Le client reçoit le produit qu'il a commandé. Le
système doit s'intégrer aux systèmes existants (maintenance...). Un plan de déploiement est
indispensable pour prévenir les perturbations induites. Prévoir également la formation aux
utilisateurs.
● Phase 7 : Exploitation et maintenance : Cette phase de « vie » à proprement parler devra
voir la validation des performances du système en exploitation sur site. Cette phase consiste
aussi à effectuer le suivi technique et la prise en compte des évolutions (assistance et
maintenance) jusqu’au retrait du système. La durée de cette phase dépend essentiellement
des durées des contrats de maintenance et de support.

Insa Lyon – IF 9/19

4411 21 févr. 08

2. Décomposition Logicielle, Matérielle, Temporelle

A Sous‐projets applicatifs

Insa Lyon – IF 10/19

4411 21 févr. 08

B Sous‐projets matériels

Projet CERISE

Sous-projets
matériels

PDA des agents Capteur et

station Serveurs
de maintenance connectique

Protection contre
Alimentation Électronique communication
les EMP

Raccord réseau Batterie Carte liaison

220V Carte mère Carte GPS/GSM
ADSL

Générateur Batterie de
photovoltaique secours processseur Carte Wimax Carte GPS

Générateur éolien

C Autres sous‐projets

Projet CERISE

Autres sous-
projets

Tests unitaires
Impacts Formation du Intégration et test Communication
des différents
environnementaux personnel du système avec le prestataire
modules

Insa Lyon – IF 11/19

4411 21 févr. 08

V ‐ Supports méthodologiques et moyens à
mettre en oeuvre
1. Support méthodologique
Le cycle de développement préconisé est celui du « cycle en V ». Pour le projet système, cette
démarche est imposée.
Pour chacun des sous projets, le choix de la démarche sera laissée au responsable du sous-projet. Il
est fortement recommandé de suivre le PAQP.

2. Moyens matériels
Les moyens matériels ne sont pas extraordinaires : des PC pour tous les moyens humains et lorsque
cela sera possible quelques prototypes d'une station.

3. Moyens logiciels
L'utilisation d'une suite logicielle simple de traitement de texte paraît être une base nécessaire à
laquelle viendra s'ajouter des environnement de développement et des outils de gestion de projet
pour le CdP (MS Project, Project GANTT...)

4. Moyens Humains
Quatre étapes composent l’évaluation de la charge.
1. Découpe en « unités d’évaluation » (UE).
2. Évaluation de chaque UE : simple (S) ou complexe (C). La complexité globale d’une UE est
obtenue par sommation des complexités des classes et est comprise entre 1 et 5.
3. Évaluation de la complexité en une charge déterminée en nombre de jours.
4. Répartition la charge par qualification.

Insa Lyon – IF 12/19

4411 21 févr. 08

Entrée Validation Sortie Traitement Total

Unités d'évaluation S C S C S C S C
1 2 1 3 1 2 2 3 <= 5
Synoptique ☺ ☺ ☺ 4
Archivage des données ☺ ☺ 3
Maintenance depuis PDA ☺ ☺ ☺ ☺ 4
Gestions des demandes d'IT ☺ ☺ ☺ 4
OS ☺ ☺ ☺ ☺ 5
Application de stats ☺ ☺ ☺ 4
PDA ☺ ☺ ☺ 3
Station ☺ ☺ ☺ ☺ 5
Serveur ☺ 1
Capteurs ☺ 3
TOTAL ∑UE
36
La somme des unités d’évaluation s’élève à 36. Nous allons désormais répartir cette complexité sur
des charges en fonction des différentes activités (postes) dans le tableau ci-après.
Postes Calcul Charge
Analyse fonctionnelle générale (SFG) Appréciation du Chef de projet 8
Analyse fonctionnelle détaillée (SFD) Σ UE / 4 9
Analyse organique générale (CD) Σ UE / 4 9

Analyse organique détaillée (AOD) Nb d’UE de

complexité: I Vecteur V IxV
1 1 1 1
2 0 2 0
3 2 4 8 49
4 4 6 24
5 2 8 16

Programmation et tests Nb d’UE de

complexité: I Vecteur V IxV
1 1 1 1
2 0 3 0
3 2 5 10 P = 63
4 4 8 32
5 2 10 20
Tests d’intégration Σ UE / 4 9
Recette Technique Σ UE / 4 9
Documentation Σ UE / 4 9
Suivi du projet P / 10 6
Total : 171 j
L'estimation sur la charge initiale est donc de 171 jours / homme. Il reste à appliquer la dernière
étape à ce chiffre.

Insa Lyon – IF 13/19

4411 21 févr. 08

Qualification Répartition Nb Jours

Chef de Projet SFD+CD+(Recette+Suivi)/2 26
Analyse (CD+PET+Documentation)/7+(AOD+Tests+Recette+Suivi)/2 48
Analyse – Programmeur (CD+PET+Documentation)*2/7 + (AOD+Tests) /2 53
Programmeur (CD+PET+Documentation ) * 4 / 7 48
Total : 175 j
La charge de l’analyse fonctionnelle générale est confiée à un consultant : 8 jours.
Total Final : 183 jours. Ce total est supérieure à la charge initiale de 12 jours. Il faut donc revoir la
charge légèrement à la hausse.
Charge totale : 183 jh.

Insa Lyon – IF 14/19

4411 21 févr. 08

VI ‐ Les  contraintes
1. Contraintes liées à l'organisation
Partie non traitée par manque de temps.

2. Contraintes liées à la planification
Partie non traitée par manque de temps.

Insa Lyon – IF 15/19

4411 21 févr. 08

VII ‐ Gestion de configuration au niveau
système
Partie non traitée par manque de temps.

Insa Lyon – IF 16/19

4411 21 févr. 08

VIII ‐ Facteurs de risques 
Partie non traitée par manque de temps.
Une première estimation des risques peut-être trouvé dans le dossier d'initialisation. Il faudrait
néanmoins ajouter à ces derniers de nombreux autres spécifiques.

Insa Lyon – IF 17/19

4411 21 févr. 08

IX ‐ Organisation et documents de suivi
Par manque de temps cette section ne sera pas détaillée.

1. Les règles de suivi
Pour assurer un suivi régulier et continu du projet plusieurs outils vont être mis en place. Le but
étant de pouvoir suivre l'avancement du projet pour estimer au fur et à mesure le temps nécessaire à
sa réalisation et pouvoir ainsi réajuster régulièrement le planning.
Ces outils permettent aussi de prévoir l'ordre du jour de chaque séance de travail en repartant sur
des bases saines et sans se décaler petit à petit.

1. Les outils utilisés
Fiches tâches pour les tâches complexes et longues, pour être certains de donner toute l'information
nécessaire.
CR de réunion lors des réunion pour avoir une trace écrite des décision.
Bilan régulier d'avancement par équipe pour le suivi général, et par personne pour un suivi par
équipe.

2. Les procédures de révision du planning
La procédure de révision du planning doit être contrôlée et nécessite de recalculer le diagramme de
PERT. Les révisions du planning doivent être les plus rares possibles.

Insa Lyon – IF 18/19

4411 21 févr. 08

X ‐ Bilan de projet système
Non réalisé, par manque de temps, c'est un draft... ça ne demande qu'à s'améliorer.

Insa Lyon – IF 19/19