Trousse de déploiement-Gestion de projet

Trousse de déploiement
Gestion de projet
Profil basique
Remarque :
Ce document est la propriété intellectuelle de l'organisation des auteurs. Cependant,
l'information de ce document peut être utilisée de manière libre. La distribution du document
complet ou des parties individuelles est autorisée pour l'utilisation non commerciale pourvue que
la notification suivante soit mentionnée:
© École de technologie supérieure
L'utilisation commerciale de ce document est strictement interdite. Ce document est distribué
afin d'augmenter l'échange d'information technique et scientifique.
Ce matériel est fourni «tel quel». L'auteur n’offre aucune garantie d'aucune sorte, explicite ou
implicite, quant à toute question, y compris, mais sans s'y limiter, à la garantie de performance,
à l'usage ou de qualité marchande, l'exclusivité, ou les résultats obtenus par l'utilisation du
matériel.
Les processus décrits dans cette trousse de déploiement ne visent pas à empêcher ou à
décourager l'utilisation de processus additionnels dont les très petits organismes pourraient
trouver utiles.
Auteurs
N. Tremblay - École de technologie supérieure (ÉTS), Canada.
Éditeur
C. Y. LAPORTE – École de technologie supérieure (ÉTS), Canada.
Date de création
14 décembre 2012
Dernière mise à jour
23 décembre 2012
État
Ébauche
Version
0.1
© Prénom, nom
Historique des versions
Date
Versio
n
Auteur
Modification
14/12/2012
0.1
N. Tremblay
Création de la version initiale
24/12/2012
0.2
Guypacome Gbelai
Modifications, ajouts
02/02/2013
0.3
Guypacome Gbelai
Modifications, ajouts
02/02/2013
0.4
Guypacome Gbelai
Modifications matrices de couverture
15/05/2013
0.5
Guypacome Gbelai
Révision du document
Abréviations/acronymes
Abré./Acro.
Définitions
TD
Trousse de Déploiement – Un ensemble d’artefacts développés pour faciliter
l’implémentation dans un très petit organisme, un ensemble de pratiques
provenant d’un cadre de référence sélectionné.
TPO
Très Petit Organisme – Une entreprise, une organisation, un département ou un
projet de 25 personnes ou moins.
ISO
Organisation internationale de normalisation/International Organization for
Standardization
IEC/CEI
International Electrotechnical Commission/Commission Électrotechnique
Internationale
TR
Technical Report
PM
Gestion de Projet
(vient de l'anglais Project Management)
SDP
Structure de Découpage du Projet
(bien connu en anglais sous le nom de WBS - Work Breakdown Structure)
PMI
Project Management Institute
PMBOK
Project Management Body Of Knowledge
SWEBOK
Software Engineering Body Of Knowledge
© Prénom, nom
Table des matières
1.
Description technique ................................................................................... 4
1.1.
But de ce document ....................................................................................... 4
1.2.
Pourquoi la gestion de projet est importante? .................................................... 4
2.
Définitions .................................................................................................... 7
2.1.
Termes génériques ......................................................................................... 7
2.2.
Termes spécifiques ......................................................................................... 7
3.
Liens avec la norme ISO/IEC 29110 ............................................................. 8
4.
Description des processus, activités, tâches, étapes, rôles et produits ......... 9
4.1.
Processus de gestion de projet ........................................................................ 9
4.2.
Activités de gestion de projet ........................................................................ 10
4.2.1.
Activité PM.1 Planification du projet .......................................................... 10
4.2.2.
Activité PM.2 Exécution du plan du projet ................................................. 21
4.2.3.
Activité PM.3 Évaluation et contrôle du projet ............................................ 25
4.2.4.
Activité PM.4 Clôture du projet ................................................................ 28
4.3.
Description des rôles .................................................................................... 29
4.4.
Description des artefacts et des produits ......................................................... 29
5.
Gabarit et outils .......................................................................................... 34
5.1.
Gabarit ....................................................................................................... 34
5.2.
Outils ......................................................................................................... 43
6.
Exemple de la mise en œuvre de tâches ...................................................... 44
7.
Liste de vérification .................................................................................... 46
8.
Matrices de couverture ............................................................................... 47
8.1.
Matrice de couverture de l'ISO 9001 ............................................................... 47
8.2.
Matrice de couverture de l’ISO/IEC 12207 ....................................................... 48
8.4.
Matrice de couverture du modèle CMMI pour le développement ......................... 50
9.
Références .................................................................................................. 52
10.
Formulaire d’évaluation de la trousse ......................................................... 53
© Prénom, nom
1. Description technique
1.1.But de ce document
Cette trousse de déploiement (TD) soutient le profil basique tel que défini dans le document
ISO/IEC TR 29110-5-1-1:2011 - Guide de gestion et d'ingénierie: Groupe de profil
générique: Profil basique [ISO/IEC 29110-5-1-2]. Le profil basique est un profil du groupe
des profils génériques. Le groupe des profils génériques est applicable aux très petits
organismes (TPO) qui ne développent pas des logiciels critiques. Le groupe des profils
génériques est composé de 4 profils : entrée (Entry), basique (Basic), intermédiaire
(Intermediate) et avancé (Advanced). Le groupe des profils génériques n'implique pas un
domaine spécifique d'applications. Le profil basique est destiné aux TPO qui développent un
seul projet à la fois.
Le profil basique fournit une base pour une migration vers les processus du profil
intermédiaire. Le profil basique est composé de deux processus : le processus de gestion de
projet et le processus d’implémentation du logiciel. Cette trousse de déploiement fournit un
support pour le processus de gestion de projet. D'autres trousses fournissent un support
pour le processus d’implémentation du logiciel.
Une trousse de déploiement est un ensemble d’artefacts qui facilitent l’implémentation d’un
ensemble de pratiques dans un très petit organisme (TPO). Une trousse de déploiement
n’est pas un modèle de référence de processus (c.-à-d. qu'elle n’est pas prescriptive). Les
éléments d’une TD sont : la description du processus, les activités, les tâches, les étapes,
les rôles et les produits, les gabarits, les listes de vérification (check-lists), les exemples et
les outils.
Le contenu de ce document n’est pas normatif, ce document est informatif.
Ce document est destiné à être utilisé par un TPO pour établir des processus pour mettre en
œuvre une approche de développement ou une méthodologie, par exemple, agile, évolutive,
itérative, développement dirigé par les tests, etc. sur la base des besoins de l'organisme ou
du projet d'un TPO.
Le document ISO/IEC TR 29110-5-1-2 :2011 est disponible sans frais sur le site de l'ISO
suivant:
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
1.2.Pourquoi la gestion de projet est importante?
«
De nombreux produits logiciels échouent non pas à cause de l'absence de demande dans
le marché, mais parce que le coût de leur création dépasse de loin tout profit.
Actuellement, environ un demi-million de gestionnaires de projets dans le monde sont
responsables d'un million de projets logiciels chaque année [O'Connor 12]. Ces projets
produisent des logiciels d’une valeur de 600 milliards de dollars [O'Connor 12]. La plupart
de ces projets ne satisfont pas aux attentes des clients ou ne réussissent pas à livrer les
logiciels en respectant le budget et l'échéancier préétablis. Il a aussi été constaté
qu'environ un tiers des projets ont des dépassements de coûts et de calendrier de plus
de 125 % [Putnam97].
» ([TD PM ENTREE], p.4)
© Prénom, nom
«
Malheureusement, les projets de logiciels ont la réputation (souvent mérité) de coûter
plus cher que prévu, de prendre plus de temps que prévu, et de livrer moins en quantité
et des produits de moins bonne qualité que prévu ou nécessaire. Le challenge pour
gérer et de diriger des projets logiciels est d'éviter cette situation stéréotypée.
» ([Richard E. (Dick) Fairley], P.1)
La gestion de projet est donc importante afin de rencontrer les exigences du client tant au
niveau financier, de la date de livraison, la qualité ainsi que les fonctionnalités.
Pour y arriver le gestionnaire de projet doit prendre en considération les activités suivantes:




Planifier et estimer
Mesurer et contrôler
Communiquer, coordonner et diriger
Gérer les risques

La défaillance de la gestion de projet
«
L’échec d’un projet logiciel est souvent dévastateur pour un organisme. Des situations
comme le décalage du calendrier, l’apparition d’erreurs et des fonctionnalités
manquantes peuvent signifier la fin du projet ou même la ruine financière d'un
organisme. Certaines des principales raisons pour lesquelles les projets ont des
dérapages incontrôlables sont: des objectifs peu clairs, une mauvaise planification, de
nouvelles technologies, l’absence d'une méthodologie de gestion de projet et l’absence
d’un nombre adéquat de personnes [Jalote02]. Au moins trois de ces cinq raisons sont
reliées à la gestion de projet.
Parmi les nombreuses raisons pour lesquelles des projets logiciels échouent, l'une des
plus importantes est la gestion incorrecte du projet. Bien qu'une bonne gestion de projet
ne puisse pas garantir le succès d’un projet, la mauvaise gestion de projet entraîne
habituellement l'échec du projet. Le produit logiciel est souvent livré en retard, coûte
plus que prévu et n'arrive pas à satisfaire aux exigences du client [Sommerville06]. De
toute évidence, l'utilisation de techniques efficaces de gestion de projet peut aider
l'organisation dans ses chances de succès de ses projets.
Une étude menée par Capers Jones [Jones04] entre 1995 et 2004, concernant
approximativement 250 projets logiciels, montre une tendance intéressante. En
comparant les projets qui ont réussi à respecter les coûts estimés et les calendriers avec
ceux qui ont dépassé le budget, ont eu une livraison tardive ou ont été annulés avant la
fin; on a observé six problèmes communs : une pauvre planification du projet, une
pauvre estimation du coût, de pauvres mesures, un pauvre suivi des étapes importantes,
un pauvre contrôle des changements et de la qualité. En revanche, les projets logiciels
réussis ont tendance à être supérieurs à la moyenne dans les six domaines. Peut-être,
l'aspect le plus intéressant de ces six domaines problématiques est qu’ils sont tous reliés
à la gestion de projet plutôt qu'à l'équipe de travail.
» ([TD PM ENTREE], p.5)
© Prénom, nom

Le succès de gestion de projet
«
Il y a plusieurs façons de faire échouer de grands projets logiciels. Il n’y a que quelques
façons de les faire réussir. Il est communément admis que la gestion de projet soit un
facteur clé qui tend à amener des projets sur la voie de la réussite ou de l'échec. Parmi
les pratiques, les plus importantes de la gestion de projet menant à la réussite sont ceux
de la planification et l'estimation avant le début de l'exécution du projet, du suivi du
projet et du contrôle des changements et l'assurance et le contrôle de qualité pour
minimiser les erreurs et les défauts. Les projets qui réussissent excellent toujours dans
ces activités. En revanche, les projets retardataires ou qui ont échoués ont des plans
déficients ou optimistes, ne gèrent pas les changements ou ne contrôlent pas la qualité
[Jones04].
» ([TD PM ENTREE], p.5)
© Prénom, nom
2. Définitions
Dans cette section, le lecteur trouvera deux groupes de définitions. Le premier groupe
définit les termes utilisés dans toutes les trousses de déploiement, des termes génériques.
Le deuxième groupe, ce sont les termes utilisés dans cette trousse de déploiement, ce sont
les termes spécifiques.
2.1.Termes génériques
Activité : Ensemble de tâches liées d'un processus [ISO/IEC 12207].
Artefact : Une information qui n’est décrite dans l’ISO/IEC TR 29110-5-1-2, mais qui peut
aider un TPO lors de l'exécution d'un projet.
Étape : Dans une trousse de déploiement, une tâche/sous-tâche est décomposée en une
suite d’étapes.
Processus : Un ensemble d’activités corrélées ou en interaction, qui transforment des
éléments d’entrée en éléments de sortie [ISO/IEC 12207].
Produit : Un ensemble d'information ou livrable qui peut être produit (de manière non
obligatoire) par une ou plusieurs tâches (p. ex. le document de conception, le code source.)
Rôle : Fonction définie, destinée à être exécutée par un membre de l’équipe du projet. Par
exemple : testeur, inspecteur, codeur [ISO/IEC 24765].
Sous-tâche : Lorsqu’une tâche est complexe, elle est divisée en sous-tâches.
Tâche : Une action requise, recommandée ou permise destinée à contribuer
l’accomplissement d’un ou plusieurs résultats d’un processus [ISO/IEC 12207].
à
2.2.Termes spécifiques
Client :
Personne
[ISO 12207]
ou
organisation
qui
reçoit
un
produit
ou
un
service.
Durée : Nombre de périodes de travail (hors jours fériés et autres jours d’inactivité)
nécessaires à l’achèvement d’une activité de l’échéancier ou d’un composant de la SDP.
Généralement exprimée en jours ou semaines de travail, et quelque fois confondue avec le
temps écoulé [PMBOK 2008].
Énoncé de travaux : Description narrative de produits, des services ou des résultats à
fournir [PMBOK 2008].
Projet : L'effort, avec des dates de début et de fin définies, entrepris afin de créer un
produit ou un service en conformité avec les ressources et les exigences spécifiées [ISO
12207].
Ressource : Actif qui est utilisé ou consommé lors de l'exécution d'un processus
[ISO 12207].
Structure de Découpage du Projet (SDP) : Décomposition hiérarchique, axée sur les
livrables, du travail que l'équipe du projet doit exécuter pour atteindre les objectifs du
projet et produire les livrables voulus. La SDP organise et définit le contenu total du projet
[PMBOK 2008].
© Prénom, nom
3. Liens avec la norme ISO/IEC 29110
Cette trousse de déploiement présente les activités liées à la gestion de projet du Rapport
Technique ISO/IEC TR 29110 Partie 5-1-2 pour les très petits organismes (TPO) - groupe de
profils génériques: profil basique [ISO/IEC 29110-5-1-2].
Le rapport technique, le Guide de gestion et d'ingénierie, fournit un processus de gestion de
projet et un processus de mise en œuvre du logiciel. Ces processus intègrent des pratiques
basées sur la sélection de processus du standard ISO/IEC 12207:2008 - Ingénierie des
systèmes et du logiciel - Processus du cycle de vie du logiciel et de produits de
documentation du standard ISO/IEC 15289:2011 - Ingénierie des systèmes et du logiciel Contenu des systèmes et produits d'information du processus de cycle de vie du logiciel
(documentation).
Le but du processus de gestion de projet est d’établir et de réaliser, systématiquement, les
tâches inhérentes au projet de déploiement du logiciel, lesquelles permettent d’assurer la
conformité avec les objectifs du projet en matière de qualité, de durée et de budget.
Le but du processus de mise en œuvre du logiciel consiste à assurer la performance
systématique des activités d'analyse, de conception, de développement, d'intégration et de
tests de produits logiciels, nouveaux ou modifiés, selon les exigences établies. D'autres
trousses de déploiement décrivent le processus de mise en œuvre du logiciel.
Les deux processus sont en interaction (voir Figure 1).
Énoncé des travaux
Gestion de
projet
Mise en oeuvre
du logiciel
Configuration
du logiciel
Figure 1: Guide de processus du profil basique [ISO/IEC 29110-5-1-2]
© Prénom, nom
4. Description des processus, activités, tâches, étapes,
rôles et produits
4.1.Processus de gestion de projet
Le diagramme suivant montre le flux d'information entre les activités du processus de
gestion de projet, y compris les produits les plus importants et leurs relations.
Figure 2: Diagramme du processus de gestion de projet du profil basique,
[ISO/IEC 29110-5-1-2]
Tel que défini dans [ISO/IEC 29110-5-1-2, p.5], « le but du processus de [gestion de projet]
est d’établir et de réaliser, systématiquement, les Tâches inhérentes au projet de
déploiement du logiciel, lesquelles permettent d’assurer la conformité avec les Objectifs du
projet en matière de qualité, de durée et de budget. »
© Prénom, nom
Comme le montre la Figure 2, le processus de gestion de projet comporte les 4 activités
suivantes :

PM.1 Planification du projet

PM.2 Exécution du plan du projet

PM.3 Évaluation et contrôle du projet

PM.4 Clôture du projet.
Chacune de ces activités seront décrites en détail lors des prochaines sections.
4.2.Activités de gestion de projet
4.2.1. Activité PM.1 Planification du projet
Les tâches associées à cette activité sont identifiées dans le Tableau 1 ci-dessous:
Tableau 1:
Tâches associées à l'activité
Planification du projet, tiré de
[ISO/IEC 29110-5-1-2]
Rôle
PM
Produits d’entrée
Liste des tâches
PM.1.1 Réviser l’Énoncé des travaux
TL
Énoncé des travaux
[révisé]
PM
PM.1.2 Définir, avec le client, les Directives de livraison pour chacun Énoncé des travaux
[révisé]
CUS des Livrables déterminés dans l'Énoncé des travaux.
Plan de projet
PM
PM.1.3 Déterminer les Tâches précises à effectuer afin de fournir les Énoncé des travaux
Livrables ainsi que les Composants logiciels indiqués dans l’Énoncé [révisé]
des travaux. Intégrer les Tâches dans le processus de SI ainsi que la
vérification, la validation et les révisions des Tâches qui incombent au
client et à l'équipe de travail pour assurer la qualité des produits.
Déterminer les Tâches visant l'application des Directives de livraison.
Document les Tâches.
Plan de projet
PM.1.4 Établir la Durée estimée pour la réalisation de chacune des Plan de projet
tâches.
- Tâches
Plan de projet
PM.1.5 Déterminer et documenter les Ressources humaines et Énoncé des travaux
matérielles nécessaires ainsi que l'équipement et les outils requis et les
normes à appliquer ainsi que la formation dont ont besoin les
membres de l'équipe de travail pour réaliser le projet. Intégrer au
calendrier les dates auxquelles ces Ressources et cette formation sont
requises.
Plan de projet
PM.1.6 Établir la Composition de l’équipe de travail et en assigner les Plan de projet
Plan de projet
TL
PM
TL
PM
TL
PM
Énoncé des travaux
Produits de sortie
© Prénom, nom
- Directives de
livraison
- Tâches
- Durée estimée
- Ressources
Rôle
Produits d’entrée
Liste des tâches
- Ressources
TL
rôles et les responsabilités en fonction des Ressources.
PM
PM.1.7 Fixer les dates prévues de commencement et de fin pour Plan de projet
chacune des Tâches afin de créer le Calendrier des tâches du projet
- Tâches
en tenant compte des Ressources qui y sont affectées, de la séquence
- Durée estimée
des Tâches et de leur dépendance.
- Composition de
l’équipe de
travail
TL
PM
PM.1.8 Calculer et documenter les Coûts et les efforts estimés.
Plan de projet
- Calendrier des
tâches du projet
- Ressources
Produits de sortie
- Composition de
l’équipe de travail
Plan de projet
- Calendrier des
tâches du projet
Plan de projet
- Coûts et efforts
estimés
Plan de projet
TL
PM.1.9 Déterminer et documenter les risques qui peuvent avoir une Tous les éléments
incidence sur le projet.
précédemment
définis
PM
PM.1.10 Documenter la Stratégie de contrôle des versions dans le
Plan de projet.
Plan de projet
PM.1.11 Produire le Plan de projet en y intégrant les éléments Tous les éléments
précédemment définis et documentés.
précédemment
définis
Plan de projet
PM
TL
PM
- Détermination des
risques que
comporte le projet
- Stratégie de
contrôle des
versions
-
-
-
PM
TL
PM.1.12 Inclure la Description du produit, la Portée, les Objectifs et Énoncé des travaux
les Livrables au Plan de projet.
- Description du
produit
- Portée
© Prénom, nom
Tâches
Durée estimée
Ressources
Composition de
l’équipe de travail
Calendrier des
tâches du projet
Coûts et efforts
estimés
Détermination des
risques que
comporte le projet
Stratégie de
contrôle des
versions
Directives de
livraison
Plan de projet
- Description du
produit
- Portée
Rôle
Produits d’entrée
Liste des tâches
- Objectifs
- Livrables
PM
PM.1.13 Vérifier le Plan de projet et en obtenir l'approbation.
TL
S’assurer que tous les éléments du Plan de projet sont viables et
cohérents. Les résultats sont documentés dans les Résultats de la
vérification et des corrections sont apportées jusqu’à ce que le
document reçoive l’approbation du PM.
PM
Plan de projet
Plan de projet
CUS Le client examine et accepte le Plan de projet en s'assurant que les [vérifié]
éléments qui y sont énoncés correspondent à ceux de l'Énoncé des
travaux.
PM
TL
PM.1.14 Réviser et accepter le Plan de projet.
PM.1.15 Établir un Dépôt d’information du projet en utilisant la Stratégie de contrôle
Stratégie de contrôle des versions.
des versions
Produits de sortie
- Objectifs
- Livrables
Résultats
vérification
de
la
Plan de projet [vérifié]
Compte rendu de
réunion
Plan de projet [accepté]
Dépôt d’information du
projet
Chacune de ces tâches seront décrites en détails dans la prochaine section à l'exception des
tâches suivantes qui seront expliquées de façon plus générale:
PM.1.2 Définir, avec le client, les Directives de livraison pour chacun des Livrables
déterminés dans l'Énoncé des travaux.
PM.1.10 Documenter la Stratégie de contrôle des versions dans le Plan de projet.
PM.1.13 Vérifier le Plan de projet et en obtenir l'approbation.
PM.1.14 Réviser et accepter le Plan de projet.
PM.1.15 Établir un Dépôt d’information du projet en utilisant la Stratégie de contrôle des
versions.
La raison est que ces tâches sont décrites dans d'autres trousses de déploiement qui
regroupent ces tâches et d'autres tâches similaires. Le tableau suivant indique le nom de la
trousse de déploiement associée à chacune de ces tâches.
© Prénom, nom
Tableau 2:
Correspondance entre les tâches de
gestion de projet avec d'autres
trousses de déploiement
Tâches
Trousse de déploiement associée
PM.1.2 Définir, avec le client, les Directives de livraison
pour chacun des Livrables déterminés dans l'Énoncé des
travaux.
Livraison du produit
[TD LIVRAISON]
PM.1.10 Documenter la Stratégie de contrôle des versions
dans le Plan de projet.
PM.1.13 Vérifier le Plan de projet et en obtenir
l'approbation.
Contrôle des versions
[TD VERSION]
Vérification et validation
[TD VER/VAL]
PM.1.14 Réviser et accepter le Plan de projet.
Vérification et validation
[TD VER/VAL]
PM.1.15 Établir un Dépôt d’information du projet en
utilisant la Stratégie de contrôle des versions.
Contrôle des versions
[TD VERSION]
Planification du projet
But :
Tel que défini dans [ISO/IEC 29110-5-1-2], « l’activité Planification du projet vise à documenter les
détails de planification nécessaires à la gestion du projet. »
Plus spécifiquement, un plan de projet spécifie, entre autres, la durée du projet, le besoin de ressources,
et la façon dont les ressources seront utilisées pour atteindre les objectifs fixés.
Le plan de projet se veut un document de référence pour identifier la portée du projet, l'échéancier, le
budget, les ressources, les risques et les activités de vérification et de validation.
C'est aussi à ce moment que la stratégie de gestion des versions est définie et ajoutée dans le plan de
projet.
Justification :
Il est reconnu qu'une bonne planification de projet améliore grandement les chances de succès d'un
projet. Une bonne planification permet de définir les étapes de mise en œuvre tout en équilibrant les
différentes contraintes du projet soient l'échéancier, le budget, la portée, la qualité, les ressources et les
risques. Le plan de projet sert à établir une référence pour le déroulement du projet en plus d'obtenir
l'accord du client avant le démarrage du projet.
Rôles :
Client (CUS)
Gestionnaire de projet (PM)
Chef technique (TL)
Équipe de travail (WT)
Produits d'entrée :
Énoncé des travaux
Produits de sortie
Plan de projet
© Prénom, nom
Résultats de vérification du Plan de projet
Compte rendu de réunion sur l'acceptation du Plan de projet
Dépôt d'information du projet
Étape 1. Réviser l’Énoncé des travaux
Tel que défini dans Étape 2. Définir, avec le client, les Directives de livraison pour chacun des Livrables déterminés dans
[ISO/IEC 29110-5-1- l'Énoncé des travaux.
2]
Étape 3. Déterminer les Tâches précises à effectuer afin de fournir les Livrables ainsi que les
Composants logiciels indiqués dans l’Énoncé des travaux.
Étapes :
Étape 4. Établir la Durée estimée pour la réalisation de chacune des tâches.
Étape 5. Déterminer et documenter les Ressources humaines et matérielles nécessaires ainsi que
l'équipement et les outils requis et les normes à appliquer ainsi que la formation dont ont besoin les
membres de l'équipe de travail pour réaliser le projet. Intégrer au calendrier les dates auxquelles ces
Ressources et cette formation sont requises.
Étape 6. Établir la Composition de l’équipe de travail et en assigner les rôles et les responsabilités en
fonction des Ressources.
Étape 7. Fixer les dates prévues de commencement et de fin pour chacune des Tâches afin de créer le
Calendrier des tâches du projet en tenant compte des Ressources qui y sont affectées, de la séquence des
Tâches et de leur dépendance.
Étape 8. Calculer et documenter les Coûts et les efforts estimés.
Étape 9. Déterminer et documenter les risques qui peuvent avoir une incidence sur le projet.
Étape 10. Documenter la Stratégie de contrôle des versions dans le Plan de projet.
Étape 11. Produire le Plan de projet en y intégrant les éléments précédemment définis et documentés.
Étape 12. Inclure la Description du produit, la Portée, les Objectifs et les Livrables au Plan de projet.
Étape 13. Vérifier le Plan de projet et en obtenir l'approbation.
Étape 14. Réviser et accepter le Plan de projet.
Étape 15. Établir un Dépôt d’information du projet en utilisant la Stratégie de contrôle des versions.
Description
étapes :
des Étape 1. Réviser l’Énoncé des travaux
La révision des travaux inclut les étapes suivantes:

Réviser l'énoncé des travaux reçu de la part du client. Le but est de bien comprendre les
objectifs, la portée et les livrables du projet ainsi que les exigences du client.

Demander des éclaircissements au client, au besoin, concernant la description du produit, la
portée, les objectifs, les livrables, les exigences ou les fonctionnalités.

Continuer jusqu'à temps que les demandes du client soit suffisamment précises et complètes
pour entamer la planification du projet.
Étape 2. Définir, avec le client, les Directives de livraison pour chacun des Livrables déterminés
dans l'Énoncé des travaux.
La définition des directions de livraison inclut les étapes suivantes:

Définir les composants logiciels ainsi les documents qui devront être remis à la fin du projet.

Définir les composants logiciels ainsi les documents qui devront être remis pendant la mise
en œuvre du projet.
© Prénom, nom
o

Définir les dates ou les moments clés dans le temps que les livrables devront être
remis.
Définir la procédure de livraison:
o
Définir les exigences du client quant au(x) types de média(s) utilisé(s) pour la
remise des livrables.
o
Définir la méthode d'installation. Il faut établir si le client installe lui-même le
produit ou demande au TPO de le faire.
o
Définir l'environnement et les configurations matérielles et logicielles nécessaires
pour le bon fonctionnement et utilisation des livrables.
o
Définir les tâches qui devront être exécutées pour rencontrer les étapes mentionnées
ci-haut.
D'autres informations se trouvent dans la trousse de déploiement portant sur la livraison du produit [TD
LIVRAISON].
Étape 3. Déterminer les Tâches précises à effectuer afin de fournir les Livrables ainsi que les
Composants logiciels indiqués dans l’Énoncé des travaux.
Le gestionnaire de projet identifie les tâches nécessaires pour la production des livrables ainsi que
l'atteinte des objectifs du projet. Une méthode bien connue pour identifier les tâches du projet est la
méthode de découpage du travail (WBS en anglais, ce qui signifie Work Breakdown Structure). Cette
méthode permet de décomposer le produit en plus petits livrables, ce qui est plus facile à gérer et plus
facile à estimer du même coup.
Dans la trousse de déploiement de gestion de projet du profil d'entrée [TD PM ENTREE], il est
mentionné que:
«
Cette technique vise à organiser les tâches dans une structure hiérarchique, où les sous-tâches
contribuent à la réalisation d'une plus grande tâche à un niveau supérieur.
Une SDP typique est composé de :





Projet
Tâche
Sous tâche
Lot de travail (Work Package)
Effort
» ([TD PM ENTREE], p.12)
Il est très important pour le gestionnaire de projet de faire participer l'équipe de travail à cette étape.
L'équipe de travail est la mieux placée pour aider le gestionnaire de projet à découper les livrables en
plus petits livrables. Le gestionnaire de projet pourrait rencontrer chacun des membres de l'équipe de
travail afin de décomposer les livrables rattachés à leurs spécialités respectives.
Cette étape se poursuit jusqu'à temps que la décomposition est suffisante pour planifier le déroulement
du projet. Le gestionnaire du projet doit faire attention pour ne pas décomposer les livrables trop en
détail pour tomber en mode micro-management. Voici 2 raisons. La première qu'à ce stade-ci du projet,
les tâches vont nécessairement varier dans l'avenir au fur et à mesure que le projet avancera. Il ne sert
donc à rien de perdre du temps à vouloir définir toutes les tâches à venir alors qu'elles pourraient varier.
La deuxième raison est que ce n'est pas une bonne pratique dans le domaine. Faire du micromanagement est gourmand en temps et les tâches se termineront rarement au moment prévu. Vaut
mieux donc garder un niveau de décomposition un peu moins précis, mais suffisant pour faire une
bonne planification de projet.
© Prénom, nom
Étape 4. Établir la Durée estimée pour la réalisation de chacune des tâches.
À l'aide du chef technique, le gestionnaire de projet définit la durée de chaque tâche au cours de l'étape
précédente. Le gestionnaire de projet ne doit pas hésiter pour demander l'avis des membres de l'équipe
au sujet de la durée de chaque tâche. Le fait de demander l'avis à l'équipe de travail crée une atmosphère
de confiance en plus d'augmenter l'engagement de chacun des membres. En effet, les membres de
l'équipe seront motivés à rencontrer les durées qu'ils ont eux-mêmes données au lieu de critiquer les
contraintes de temps dont ils se sont fait imposées.
Les approches agiles suggèrent une méthode appelée "Planning Poker" qui permet à chaque membre de
l'équipe de donner son avis au sujet de la durée d'une tâche. Cette méthode est rapide et pourrait être
utilisée pour estimer la durée de chaque tâche. Le site Web suivant peut être consulté pour obtenir plus
de détails sur la méthode et offre une plateforme gratuite pour faire participer les membres de votre
équipe à cette méthode.
http://www.planningpoker.com/
D'autres méthodes pourraient être utilisées pour estimer la durée des tâches. Les corpus de
connaissances [SWEBOK 2004] et [PMBOK 2008, p.149] définissent ensemble 5 méthodes pour
estimer:
–
–
–
–
–
Jugement d'expert
Estimation par comparables
Estimation paramétrique
Estimations en 3 points
Analyse par réserves
Étape 5. Déterminer et documenter les Ressources humaines et matérielles nécessaires ainsi que
l'équipement et les outils requis et les normes à appliquer ainsi que la formation dont ont besoin
les membres de l'équipe de travail pour réaliser le projet.
Le gestionnaire de projet et le chef technique déterminent toutes les ressources nécessaires pour réaliser
le projet. Les Ressources peuvent être autant les ressources humaines, matérielles, logicielles y compris
les équipements, les outils et les normes.
Dans la trousse de déploiement de gestion de projet du profil d'entrée [TD PM ENTREE], il est
recommandé de:
«

Ne pas faire des estimations [des ressources] au hasard. Prenez le temps d’estimer les
ressources nécessaires au projet.

Réaliser en collaboration avec l’équipe de travail une liste de personnes, matérielles, outils,
etc. requis pour le projet. Ceci vous donnera un meilleur aperçu des vrais besoins. Un remueméninge (brainstorming) pourrait être un outil efficace.

Donner le nom et le rôle des personnes responsables d’exécuter les tâches.

[...]

Valider la disponibilité de ressources (humaines, matérielles, techniques et outils). La
disponibilité de ressources humaines a été une de principales problématiques rencontrées dans
les TPO. Alors il est recommandé d’élaborer un calendrier indiquant quand les ressources
seront nécessaires et de faire un suivi périodique de celui-ci afin de prendre les mesures
nécessaires lorsqu'il y a un problème de non disponibilité.
»
En ce qui concerne les ressources humaines, il est important d'analyser si des besoins de formation sont
requis pour rencontrer les objectifs du projet. Cela peut se faire de la façon suivante:
© Prénom, nom

Faire une liste des compétences de l'équipe de travail

Comparer les compétences de l'équipe de travail avec les compétences nécessaires pour la
réalisation du projet

Identifier les lacunes et les besoins de formation

Identifier les formations offertes pour combler les lacunes

Identifier les personnes qui suivront la formation

Conserver la/les date(s) de formation afin de les tenir compte dans le calendrier du projet
Étape 6. Établir la Composition de l’équipe de travail et en assigner les rôles et les responsabilités
en fonction des Ressources.
Cette étape consiste à identifier les personnes qui participeront au projet. Cette étape semble banale,
mais elle importante pour la création de l'échéancier du projet. Dépendamment de la disponibilité des
ressources dans le temps et en fonction de leurs compétences, cela peut avoir un impact non négligeable
sur l'échéancier.
Le fait d'associer des rôles et des responsabilités à chacun des membres de l'équipe fera en sorte que
chacun saura le moment où il interviendra et les tâches typiques qu'il devra accomplir. Les rôles sont
des chapeaux que l'on attribue à chaque membre de l'équipe. Par exemple, "Responsable du contrôle des
versions", "Développeur". Ces rôles ne sont pas mentionnés explicitement dans [ISO/IEC 29110-5-1-2],
mais votre TPO peut en définir au besoin pour y associer des responsabilités.
Les responsabilités sont une liste de tâches commençant par un verbe d'action comme par exemple,
"Produire des copies de sécurité du Dépôt d'information du projet" et "Documenter et mettre à jour la
conception du logiciel". Ces responsabilités sont rattachées aux rôles définis dans l'organisation.
Étape 7. Fixer les dates prévues de commencement et de fin pour chacune des Tâches afin de
créer le Calendrier des tâches du projet en tenant compte des Ressources qui y sont affectées, de
la séquence des Tâches et de leur dépendance.
Comme il est mentionné dans la trousse de déploiement de gestion de projet du profil d'entrée:
« Le Gestionnaire de projet procède à l'organisation des tâches dans une séquence cohérente en
tenant compte leur dépendance (obligatoire ou facultative). Ceci permettra de bien connaître
l’ordre d’exécution de tâches.
Une fois la séquence des tâches déterminée, le gestionnaire du projet pourra identifier et faire
attention aux tâches qui ont une influence directe sur la durée du projet [chemin critique].
Conseil: Il existe des logiciels en gestion de projets (p.ex. MS Project) qui peuvent générer
automatiquement des représentations graphiques des tâches en séquence.
» ([TD PM ENTREE], p.12)
Une fois que les tâches sont mises en ordre, le gestionnaire peut placer les activités dans un calendrier
en tenant des disponibilités des ressources, des besoins de formation et des dates importantes pouvant
être imposées par le client. Pour ce faire,
« Le gestionnaire de projet et le chef technique estiment la date de début et la date de fin de
chacune des tâches afin d’établir le calendrier du projet. Il sera recommandé :



Faire une revue de l’information que servira à créer le calendrier : par exemple, si
toutes les tâches du projet ont été identifiées et leur durée, si les ressources à chaque
tâche sont appropriées et disponibles, si les facteurs de risque ont été pris en compte,
entre autres.
Organiser les tâches de façon cohérente en utilisant leur dépendance y compris les
activités parallèles;
Mettre les tâches en relation avec la durée et les ressources estimées (humaines,
© Prénom, nom
matérielles, techniques, outils).
Conseil : plusieurs logiciels tels que MS Project peuvent calculer la chronologie globale du projet
du début à la fin.
» ([TD PM ENTREE], p.14)
Il existe d'autres outils pour représenter graphiques des tâches en séquence et dans un calendrier, dont
OpenProj (http://sourceforge.net/projects/openproj/) et Ace Project (http://www.aceproject.com/), tous
les deux gratuits.
Étape 8. Calculer et documenter les Coûts et les efforts estimés.
Dans l'estimation des coûts, le gestionnaire de projet doit tenir compte des éléments suivants:

Coûts des ressources humaines en fonction des tâches à accomplir (nombre d'heures travaillés
estimés x taux horaire)

Coûts reliés à la formation des ressources humaines

Coûts du matériel et des équipements

Coûts des licences de logiciels et outils à acheter

Coûts reliés à l'achat de normes

Coûts reliés aux risques pesant sur le projet

Tous autres coûts qui s'appliquent au projet
Étape 9. Déterminer et documenter les risques qui peuvent avoir une incidence sur le projet.
Le gestionnaire du projet ainsi que le chef technique doit évaluer les événements qui pourraient survenir
en cours de projet et qui pourrait avoir un impact sur les objectifs du projet. Dans le [PMBOK 2008,
p.286], différentes techniques d'identification des risques sont mentionnés. Ces techniques sont les
suivantes:

Remue-méninges

Technique Delphi

Analyse des risques des projets antérieurs

Analyse des hypothèses

Techniques par diagramme
o
Diagramme de cause et effet
o
Flux du processus
o
Diagramme d'influence

Analyse SWOT

Jugement d'expert
Pour chaque risque identifié, le gestionnaire de projet doit attribuer une probabilité d'occurrence ainsi
que le degré l'impact sur les objectifs du projet. Ensuite, une stratégie de réponse aux risques doit être
associée pour chacun d'entre eux. Les stratégies possibles sont les suivantes [PMBOK 2008, p.303]:
© Prénom, nom

Éviter le risque

Transférer le risque

Mitiger le risque

Accepter le risque
La façon dont vous allez répondre aux risques dépend de la gravité du risque sur votre TPO et sur le
projet.
Étape 10. Documenter la Stratégie de contrôle des versions dans le Plan de projet.
Une stratégie de contrôle des versions doit être élaborée en début de projet afin de garantir l'intégrité
des documents et du code source du projet. Cette stratégie doit couvrir les éléments suivants, tels que
définis dans [ISO/IEC 29110-5-1-2] p.40:

Outils ou mécanismes du dépôt d’information du produit

Emplacement du dépôt et des mécanismes pour y accéder

Méthodes d’identification et de contrôle des versions

Mécanismes de sauvegarde et de récupération

Mécanismes de stockage, de traitement et de livraison (comprenant l'archivage et la
recherche)
Plus de détails sont fournis dans la trousse de contrôle des versions [TD VERSION].
Étape 11. Produire le Plan de projet en y intégrant les éléments précédemment définis et
documentés.
Le gestionnaire de projet crée le plan de projet en y intégrant les éléments suivants:
«
- Tâches, comprenant la vérification, la validation et les revues avec le client et l’équipe de
travail pour veiller à la qualité des produits. Les Tâches peuvent être représentées dans une
SDP (structure de découpage du projet).
- Durée prévue des tâches
- Ressources (humaines, matérielles, en matière de normes, d'équipement et d'outils) dont la
formation nécessaire et le calendrier d’utilisation des ressources
- Composition de l’équipe de travail
- Calendrier des tâches du projet indiquant la date prévue de commencement et d’achèvement
de chaque tâche ainsi que les liens entre les tâches et leurs interdépendances.
- Évaluation des efforts nécessaires et des coûts
- Détermination des risques associés au projet
- Stratégie de contrôle des versions:
- Directives de livraison
» ([ISO/IEC 29110-5-1-2] p.40)
Étape 12. Inclure la Description du produit, la Portée, les Objectifs et les Livrables au Plan de
projet.
Le gestionnaire de projet intègre la description du produit, la portée, les objectifs et les livrables dans le
plan de projet.
© Prénom, nom
Étape 13. Vérifier le Plan de projet et en obtenir l'approbation.
« S’assurer que tous les éléments du Plan de projet sont viables et cohérents. Les résultats sont
documentés dans les Résultats de la vérification et des corrections sont apportées jusqu’à ce que le
document reçoive l’approbation du PM. » ([ISO/IEC 29110-5-1-2] p.13)
Plus de détails sont fournis dans la trousse de contrôle des versions [TD VER/VAL].
Étape 14. Réviser et accepter le Plan de projet.
«Le client examine et accepte le Plan de projet en s’assurant que les éléments qui y sont énoncés
correspondent à ceux de l’Énoncé des travaux. » ([ISO/IEC 29110-5-1-2] p.13)
Étape 15. Établir un Dépôt d’information du projet en utilisant la Stratégie de contrôle des
versions.
Le chef technique crée le dépôt d'information du projet de façon à ce que l'équipe de travail puisse
conserver l'intégrité des documents et code source du projet.
Plus de détails sont fournis dans la trousse de contrôle des versions [TD VERSION].
© Prénom, nom
4.2.2. Activité PM.2 Exécution du plan du projet
Les tâches associées à cette activité sont les suivantes, tiré de [ISO/IEC 29110-5-1-2]:
Rôle
PM
TL
Produits d’entrée
Liste des tâches
Produits de sortie
PM.2.1 Surveiller l’exécution du Plan de projet et consigner Plan de projet
les données réelles dans le Rapport d’avancement.
Rapport d’avancement
PM 2.2 Analyser et évaluer la Demande de changement dans Demande de
la perspective de l’incidence sur le coût, le calendrier et les changement [initiée]
exigences techniques.
Demande de
changement [évaluée]
La Demande de changement peut provenir de l'externe (du
client) ou de l'interne (de l'équipe de travail). Si le
changement, une fois accepté, n’a pas d’incidence sur les
ententes avec le client, mettre le Plan de projet à jour.
Plan de projet [mis à
jour]
WT
PM
TL
La Demande de changement qui a une incidence sur ces
ententes doit faire l’objet de négociations entre les deux
parties (voir PM.2.4).
PM
TL
WT
PM.2.3 Tenir des réunions de revue avec l’équipe de travail, Plan de projet
cerner les problèmes, examiner l'état des risques, consigner
les ententes et en assurer le suivi jusqu'à la clôture du projet.
Rapport d'avancement
Compte rendu de
réunion [mis à jour]
Registre des corrections
PM
CUS
TL
WT
Compte rendu de
réunion
PM.2.4 Tenir des réunions de revue avec le client, consigner Plan de projet
les ententes et en assurer le suivi jusqu'à la clôture du projet.
Rapport d’avancement
La demande de changement, présentée par le client ou par
l'équipe de travail, ayant une incidence sur le client, doit
Demande de
faire l'objet de négociations et être acceptée par les deux
changement [évaluée]
parties.
Compte rendu de
réunion [mis à jour]
Demande de
changement [acceptée]
Plan de projet [mis à
jour]
S’il y a lieu, mettre le Plan de projet à jour en fonction de la Compte rendu de
réunion
nouvelle entente avec le client.
PM
PM.2.5 Produire des copies de sécurité en fonction de la Stratégie de
Stratégie de contrôle des versions.
des versions
contrôle Copie de sécurité du
Dépôt d’information du
projet
PM
PM.2.6 S’il y a lieu, effectuer la récupération du Dépôt Copie de sécurité du Plan
de
d’information du projet en utilisant les Copies de sécurité.
Dépôt d’information du [récupéré]
projet
projet
Chacune de ces tâches seront décrites en détails dans la prochaine section à l'exception de
la tâche suivante qui sera expliquée de façon plus générale:
© Prénom, nom
PM 2.2 Analyser et évaluer la Demande de changement dans la perspective de l’incidence
sur le coût, le calendrier et les exigences techniques.
La raison est que cette tâche est décrite dans une autre trousse de déploiement qui
regroupe cette tâche et d'autres tâches similaires. Le tableau suivant indique le nom de la
trousse de déploiement associée à cette tâche.
Tableau 3:
Correspondance entre les tâches de
gestion de projet avec d'autres
trousses de déploiement
Tâches
Trousse de déploiement associée
PM 2.2 Analyser et évaluer la Demande de changement
dans la perspective de l’incidence sur le coût, le calendrier
et les exigences techniques.
Vérification et validation
[TD VER/VAL]
Les tâches PM.2.5 et PM.2.6 devraient également être définies dans une autre trousse de
déploiement, soit la trousse de contrôle des versions [TD VERSION]. Toutefois, pour
l'instant, elles ne sont pas couvertes par ces trousses. Par conséquent, elles seront traitées
dans cette présente trousse.
© Prénom, nom
Exécution du plan de projet
But :
Tel que défini dans [ISO/IEC 29110-5-1-2],
«
l’activité Exécution du plan de projet vise à mettre en œuvre le plan documenté permettant la
réalisation du projet. Cette activité permet d'obtenir :

Une mise à jour du Rapport d'avancement du projet

Des demandes de changement au plan analysées et évalués ayant une incidence sur le coût, le
calendrier et les exigences techniques.

Des changements au plan approuvés.

Des révisions et des ententes avec l'équipe de travail (WT) et le client (CUS).

Une copie de sécurité du Dépôt d'information du projet et sa récupération, au besoin.
» ([ISO/IEC 29110-5-1-2] p.13, 14)
Justification :
Pour rencontrer les objectifs du projet, les tâches définies dans le plan de projet doivent être mises à
l'exécution. Une bonne exécution du projet n'implique pas seulement l'exécution tâches définies dans le
plan de projet, mais comprend également le suivi du progrès des différents paramètres du projet. Ce
suivi permet aux gestionnaires de projets de connaître l'état du projet et réagir rapidement si des
déviations sont observées.
Des réunions de revue périodiques avec le client et l'équipe de travail aident à repérer les problèmes,
évaluer l'état des risques et l'impact des demandes de changements.
Tout au long de l'exécution du projet, les artefacts de travail sont conservés dans le Dépôt d'information
du projet et les copies de sécurités sont effectuées sur une base régulière
Rôles :
Client (CUS)
Gestionnaire de projet (PM)
Chef technique (TL)
Équipe de travail (WT)
Produits d'entrée :
Plan de projet
Registre des corrections
Stratégie de contrôle des versions
Produits de sortie
Plan de projet [mis à jour]
Rapport d'avancement
Demande de changement [évaluée, acceptée]
Compte rendu de réunion
Copie de sécurité du Dépôt d'information du projet
Étape 1. Surveiller l’exécution du Plan de projet et consigner les données réelles dans le Rapport
Tel que défini dans d’avancement.
[ISO/IEC 29110-5-1Étape 2. Analyser et évaluer la Demande de changement dans la perspective de l’incidence sur le coût,
2]
le calendrier et les exigences techniques.
Étapes :
© Prénom, nom
Étape 3. Tenir des réunions de revue avec l’équipe de travail, cerner les problèmes, examiner l'état des
risques, consigner les ententes et en assurer le suivi jusqu'à la clôture du projet.
Étape 4. Tenir des réunions de revue avec le client, consigner les ententes et en assurer le suivi jusqu'à
la clôture du projet.
Étape 5. Produire des copies de sécurité en fonction de la Stratégie de contrôle des versions.
Étape 6. S’il y a lieu, effectuer la récupération du Dépôt d’information du projet en utilisant les Copies
de sécurité.
Description
étapes :
des Étape 1. Surveiller l’exécution du Plan de projet et consigner les données réelles dans le Rapport
d’avancement.
Il est important de noter périodiquement l'avancement des paramètres du projet dans le Rapport
d'avancement. Les paramètres à suivre sont les suivants:




Avancement des tâches dans le temps (l'échéancier)
Les coûts réels dépensés jusqu'à maintenant
Les ressources actuellement affectées
L'état des risques
Ces informations serviront à évaluer si des déviations par rapport au plan de projet sont présentes. Si
c'est le cas, des demandes de changements seront initiées et des actions correctives seront entreprises.
(voir Étape 2)
Étape 2. Analyser et évaluer la Demande de changement dans la perspective de l’incidence sur le
coût, le calendrier et les exigences techniques
Cette étape consiste à évaluer l'impact d'une ou des demandes de changement sur les objectifs du projet.
Cela se traduit par:




Recevoir une demande de changement (en provenance du client ou de l'équipe de travail)
Analyser la demande de changement. Cela signifie que le gestionnaire de projet ou le chef
technique prend connaissance de la demande de changement et s'assure que la demande est
claire et précise. Autrement, des éclaircissements doivent être obtenus avant d'évaluer
l'impact sur le projet.
Évaluer l'impact de la demande de changement sur les paramètres du projet (c'est-à-dire sur la
portée, les coûts, l'échéancier, la qualité, les risques)
Accepter la demande de changement si aucun impact sur les paramètres du projet, autrement
conserver la demande de changement et la présenter au client pour acceptation.
Un gabarit de demande de changement est présenté à la section 5. Plus de détails sont fournis dans la
trousse de vérification et de validation [TD VER/VAL].
Étape 3. Tenir des réunions de revue avec l’équipe de travail, cerner les problèmes, examiner
l'état des risques, consigner les ententes et en assurer le suivi jusqu'à la clôture du projet.
Peu importe la façon dont les réunions sont effectuées dans le TPO, l'important est que le gestionnaire
de projet ait le feedback de tous les membres de l'équipe de travail. L'important est que ce feedback se
fasse sur une base régulière de façon à soulever les problèmes rapidement en vue de prendre des
décisions.
Le gestionnaire de projet doit produire un Compte rendu de réunion après la tenue de chaque réunion et
le placer dans le Dépôt d'information du projet.
Étape 4. Tenir des réunions de revue avec le client, consigner les ententes et en assurer le suivi
jusqu'à la clôture du projet.
« La demande de changement, présentée par le client ou par l’équipe de travail, ayant une incidence sur
le client, doit faire l'objet de négociations et être acceptée par les deux parties. S’il y a lieu, mettre le
Plan de projet à jour en fonction de la nouvelle entente avec le client. » ([ISO/IEC 29110-5-1-2] p.1415)
© Prénom, nom
Étape 5. Produire des copies de sécurité en fonction de la Stratégie de contrôle des versions.
Les données de projet est ce qui donne de la valeur au client. Une bonne stratégie de contrôle de
versions devrait prévoir au minimum des copies quotidiennes du Dépôt d'information du projet. Une
bonne pratique serait de planifier automatiquement des copies de sécurité sur une base quotidienne.
Pour l'instant, aucun détail n'est fourni dans la trousse de contrôle des versions [TD VERSION]. À
venir sous peu...??
Étape 6. S’il y a lieu, effectuer la récupération du Dépôt d’information du projet en utilisant les
Copies de sécurité.
Si un problème survient dans le Dépôt d'information du projet ou si les livrables doivent revenir à un
état antérieur, utilisez les copies de sécurité pour restaurer les livrables du projet à l'état voulu.
Pour l'instant, aucun détail n'est fourni dans la trousse de contrôle des versions [TD VERSION]. À
venir sous peu...??
4.2.3. Activité PM.3 Évaluation et contrôle du projet
Les tâches associées à cette activité sont les suivantes, tiré de [ISO/IEC 29110-5-1-2]:
Rôle
PM
TL
WT
PM
TL
WT
PM
TL
WT
Produits d’entrée
Liste des tâches
Produits de sortie
PM.3.1 Évaluer l’avancement du projet par rapport au Plan de Plan de projet
Rapport d’avancement
projet en comparant :
[évalué]
Rapport d’avancement
-les Tâches réelles par rapport aux Tâches planifiées
-les résultats réels par rapport aux Objectifs du projet
-les ressources réellement affectées au projet par rapport
aux Ressources planifiées
-les coûts réels par rapport aux estimations budgétaires
-les écarts par rapport à l’échéancier établi
-les risques réels par rapport aux risques précédemment
déterminés
PM.3.2 Établir des mesures visant à corriger les écarts ou à Rapport d’avancement Registre des
résoudre les problèmes et à éviter les risques déterminés [évalué]
corrections
susceptibles de compromettre la réalisation du plan, s’il y a
lieu, les consigner dans le Registre des corrections, puis en
assurer le suivi jusqu’à la clôture du projet.
PM.3.3 Repérer les changements apportés aux exigences et au Rapport d’avancement Demande de
Plan de projet afin de corriger les écarts importants ou [évalué]
changement [initiée]
résoudre les problèmes et éviter les risques susceptibles de
compromettre la réalisation du plan, consigner le tout dans la
Demande de changement, puis en assurer le suivi jusqu’à la
clôture du projet.
© Prénom, nom
Évaluation et contrôle du projet
But :
Tel que défini dans [ISO/IEC 29110-5-1-2],
« l’activité Évaluation et contrôle du projet vise à évaluer la performance du plan. Cette activité
permet d’obtenir :

Une évaluation de la performance du plan et de l'avancement réel par rapport aux cibles.

La détermination et l'évaluation des problèmes et des écarts importants en ce qui concerne les
coûts, le calendrier et la performance technique.

Un examen des risques que comportent le projet et la détermination des risques nouveaux.

Des demandes de changement documentées, des mesures correctives définies et appropriées
et un suivi des changements jusqu'à la clôture du projet.
» ([ISO/IEC 29110-5-1-2] p.15)
Justification :
Si le projet dévie de ses objectifs en cours d'exécution, des actions doivent être entreprises pour corriger
les écarts. Au besoin, des demandes de changements sont initiées.
Rôles :
Gestionnaire de projet (PM)
Chef technique (TL)
Équipe de travail (WT)
Produits d'entrée :
Plan de projet
Rapport d'avancement
Produits de sortie
Rapport d'avancement [évalué]
Registre des corrections
Demande de changement [initiée]
Étapes :
Étape 1. Évaluer l’avancement du projet par rapport au Plan de projet
Tel que défini dans
[ISO/IEC 29110-5-1- Étape 2. Établir des mesures visant à corriger les écarts ou à résoudre les problèmes et à éviter les
risques déterminés susceptibles de compromettre la réalisation du plan
2]
Étape 3. Repérer les changements apportés aux exigences et au Plan de projet afin de corriger les écarts
importants ou résoudre les problèmes et éviter les risques susceptibles de compromettre la réalisation du
plan
Description
étapes :
des Étape 1. Évaluer l’avancement du projet par rapport au Plan de projet
« Périodiquement, le gestionnaire de projet et l’équipe de travail évaluent la performance du plan, c’està-dire, mesurer le progrès du projet contre le plan initial (tâches exécutés contre les tâches planifiés;
ressources actuellement allouées contre les planifiées; temps/coût actuel consommé contre le
temps/coût prévu; risques actuels contre les identifiés).
Une déviation par rapport à l’avancement prévu peut exiger la prise de mesures correctives, et par
conséquent, la mise à jour du plan du projet. » ([TD PM ENTREE], p.17)
Les indicateurs d'avancement du projet sont conservés dans un Rapport d'avancement.
Étape 2. Établir des mesures visant à corriger les écarts ou à résoudre les problèmes et à éviter
les risques déterminés susceptibles de compromettre la réalisation du plan
Cette étape consiste à :


Évaluer le rapport d'avancement pour repérer les problèmes et les écarts du projet
Assigner une priorité aux problèmes en fonction de l'impact sur les objectifs du projet
© Prénom, nom



Déterminer des mesures pour corriger la situation
o Dépendamment du type de problème, des séances de remue-méninges pourraient
être tenues pour obtenir le maximum d'idées et de solutions.
Décider les mesures à entreprendre pour corriger la situation
Enregistrer les décisions et les actions entreprises dans un Registre de corrections.
Étape 3. Repérer les changements apportés aux exigences et au Plan de projet afin de corriger les
écarts importants ou résoudre les problèmes et éviter les risques susceptibles de compromettre la
réalisation du plan
À partir du rapport d'avancement et du registre des corrections, générer les demandes de changements
qui doivent être apportées aux exigences du projet ou au plan de projet. Pour ce faire, il s'agit:

D'évaluer le rapport d'avancement et du registre des corrections

Identifier les changements dans les fonctionnalités du logiciel et les changements dans les
paramètres du projet

Initier des demandes de changement et y ajouter tous les détails nécessaires afin qu'elle soit
évaluée et priorisée par l'équipe de travail et/ou le client.
© Prénom, nom
4.2.4. Activité PM.4 Clôture du projet
Les tâches associées à cette activité sont les suivantes, tiré de [ISO/IEC 29110-5-1-2]:
Rôle
PM
CUS
PM
Produits d’entrée
Liste des tâches
PM.4.1 Officialiser la clôture du projet selon
les Directives de livraison établies dans le
Plan de projet, offrir le soutien nécessaire à
l’acceptation du produit et faire signer
l'enregistrement de réception.
PM.4.2 Mettre à jour le Dépôt d’information
du projet.
Produits de sortie
Plan de projet
Procès-verbal de réception
- Directives de livraison
Configuration du logiciel
(livrée)
Configuration du logiciel
(acceptée)
Dépôt
projet
d’information
Configuration du logiciel
(acceptée)
Dépôt d’information
projet [mis à jour]
du
du
Clôture du projet
But :
Tel que défini dans [ISO/IEC 29110-5-1-2],
«
l’activité Clôture du projet vise à produire la documentation et les produits conformes aux
exigences stipulées au contrat. Cette activité permet d'obtenir :

La livraison des produits telle que définie dans les Directives de livraison.

Un soutien à l'acceptation du produit par le client conformément aux Directives de livraison.

L'achèvement du projet et la signature de l'enregistrement (record) de réception. »
» ([ISO/IEC 29110-5-1-2] p.16)
Justification :
Sans clôture du projet, le client ne recevrait jamais le produit auquel il paye. Cette activité consiste donc
à livrer la configuration du logiciel au client telle que définie dans les instructions de livraison. La
clôture du projet permet d'obtenir l'acceptation du client et de libérer les ressources.
Rôles :
Gestionnaire de projet (PM)
Client (CUS)
Produits d'entrée :
Plan de projet, directives de livraison
Configuration du logiciel
Produits de sortie
Procès-verbal de réception
Configuration du logiciel [acceptée]
Dépôt d'information du projet [mis à jour]
Étapes :
Tel que défini dans Étape 1. Officialiser la clôture du projet selon les Directives de livraison établies dans le Plan de projet,
[ISO/IEC 29110-5-1- offrir le soutien nécessaire à l’acceptation du produit et faire signer l'enregistrement de réception.
2]
Étape 2. Mettre à jour le Dépôt d’information du projet.
© Prénom, nom
Description
étapes :
des Étape 1. Officialiser la clôture du projet selon les Directives de livraison établies dans le Plan de
projet, offrir le soutien nécessaire à l’acceptation du produit et faire signer l'enregistrement de
réception.
Cette étape consiste à




Livrer la configuration logicielle selon les directives de livraison. Le gestionnaire de projet et
le client devrait chacun avoir une liste de vérification pour s'assurer que tous les directives
établies sont respectés.
Obtenir l'acceptation finale du client quant à la configuration logicielle
Faire signer l'enregistrement de réception par le client
Ajouter l'enregistrement de réception dans le Dépôt d'information du projet.
Étape 2. Mettre à jour le Dépôt d’information du projet.
Créer une référence dans le Dépôt d'information du projet avec la configuration logicielle livrée au
client. Cette référence pourra servir de première version pour la maintenance du logiciel.
Au besoin, créer une copie de sécurité sur un média externe (ex: CD, DVD).
4.3.Description des rôles
Cette section donne une liste alphabétique des rôles, des abréviations et de la description
des compétences souhaitées telles que définies dans le guide de gestion et d'ingénierie
[ISO/IEC 29110-5-1-2, p.36-37].
Rôle
Abréviation
Compétences
1
Gestionnaire de projet
PM
Aptitude à diriger et expérience dans la prise de décisions, la
planification, la gestion du personnel, la délégation et la supervision,
les finances et le développement de logiciel.
2
Chef technique
TL
Connaissance du domaine du logiciel et expérience connexe.
3
Équipe de travail
WT
Connaissance et expérience selon les rôles du projet: TL, AN, DES
ou PR.
Connaissance des normes appliquées par le client et/ou le TPO.
4
Client
CUS
Connaissance des processus du client et aptitude à expliquer les
exigences du client.
Le client (ou son représentant) doit avoir le pouvoir d’approuver les
exigences et les changements à apporter.
Le terme « client » comprend les personnes qui représentent les
utilisateurs pour veiller à ce que l'environnement d’opération soit mis
à l’étude.
Connaissance du domaine du logiciel et expérience connexe.
4.4.Description des artefacts et des produits
Cette section donne une liste alphabétique des artefacts et des produits, (c.-à-d. des
documents papier ou électroniques) nécessaires à la réalisation des tâches décrites cidessus. Ce sont les intrants, les extrants et les documents produits pendant l’exécution des
tâches. Les descriptions sont tirées de [ISO/IEC 29110-5-1-2, p.37-46].
© Prénom, nom
1.
Nom de l'artefact
Description
Enregistrement de
réception
Documente l’acceptation des Livrables du projet par le client. Il peut être doté des
caractéristiques suivantes:
-
2.
Demande de
changement
Preuve de la réception du produit
Mention de la date de réception
Liste des éléments livrés
Fait état de la vérification de tout critère d’acceptation défini par le client
Enregistrement de tout problème non réglé ou de toute question restée sans réponse (s’il
y a lieu)
Signature du client qui a réceptionné le produit
Indique un problème relatif au Logiciel ou à la documentation, ou une amélioration requise et
énonce la demande du changement. Elle peut faire état des points suivants:
-
Détermination de l'objectif du changement demandé
Détermination de l'état de la demande
Détermination des coordonnées du demandeur
Détermination du système ou systèmes touchés
Définition de l’incidence sur les opérations du ou des systèmes existants
Définition de l'incidence sur la documentation connexe
Degré d’importance de la demande, date à laquelle le changement est requis
Les états possibles sont: initiée, évaluée et acceptée.
3.
Registre des
corrections
Indique les activités déterminées visant à corriger un écart ou un problème en ce qui concerne
la réalisation du plan. Il peut faire état des points suivants:
-
4.
Enregistrement de
réunion
Détermination du problème initial
Détermination d'une solution
Détermination des mesures correctives mises en œuvre
Détermination de l'imputabilité de l’achèvement des mesures établies
Détermination de la date d’ouverture et date de clôture ciblées
Comporte un indicateur de l’état
Détermination des mesures de suivi
Documente les ententes conclues entre le client et l’équipe de travail. Il peut faire état des
points suivants:
-
But de la réunion
Participants
Date, lieu de la rencontre
Références à des comptes rendus précédents
Accomplissements
Problèmes ou questions soulevés
Tout problème non réglé ou toute question restée sans réponse
Ententes
Date de la prochaine réunion, s’il y a lieu.
L’état possible est: mis à jour
5.
Enregistrement
Documente l'état d'avancement du projet par rapport au Plan de projet. Il peut faire état des
© Prénom, nom
Nom de l'artefact
Description
d’avancement
points suivants:
-
L'état des Tâches réelles par rapport aux tâches planifiées
L'état des résultats réels par rapport aux objectifs et aux buts établis
L'état des ressources réellement affectées au projet par rapport aux Ressources planifiées
L'état des coûts réels par rapport aux coûts prévus au budget
L'état de la durée réelle par rapport à celle prévue
L'état des risques réels par rapport aux risques précédemment identifiés
L'enregistrement de tout écart par rapport aux tâches planifiées et la justification de cet
écart
L'état possible est: évalué.
© Prénom, nom
6.
Nom de l'artefact
Description
Plan de projet
Indique la façon dont les processus et les activités nécessaires à la réalisation du projet seront
exécutés afin d'assurer l'achèvement réussi du projet et la qualité des produits livrés. Il
comprend les éléments suivants qui peuvent faire état des points suivants:
-
-
-
Description de produit
But
Exigences générales du client
Description de la Portée; ce qui fait partie de l’entente et ce qui n’en fait pas partie
Objectifs du projet
Livrables: une liste des produits à livrer au client
Tâches, comprenant la vérification, la validation et les revues avec le client et l’équipe de
travail pour veiller à la qualité des produits. Les Tâches peuvent être représentées dans
une SDP (structure de découpage du projet).
Durée prévue des tâches
Ressources (humaines, matérielles, en matière de normes, d'équipement et d'outils) dont
la formation nécessaire et le calendrier d’utilisation des ressources
Composition de l’équipe de travail
Calendrier des tâches du projet indiquant la date prévue de commencement et
d’achèvement de chaque tâche ainsi que les liens entre les tâches et leurs
interdépendances.
Évaluation des efforts nécessaires et des coûts
Détermination des risques associés au projet
Stratégie de contrôle des versions:
Outils ou mécanismes du dépôt d’information du produit
Emplacement du dépôt et des mécanismes pour y accéder
Méthodes d’identification et de contrôle des versions
Mécanismes de sauvegarde et de récupération
Mécanismes de stockage, de traitement et de livraison (comprenant l'archivage et la
recherche)
Directives de livraison
Détermination des éléments nécessaires à la mise en circulation du produit (c.-à-d.,
matériel, logiciel, documentation, etc.)
Exigences en matière de livraison
Ordre séquentiel des Tâches à exécuter
Détermination des versions applicables
Détermination des Composants logiciels livrés avec les renseignements déterminant la
version
Détermination des procédures de sauvegarde ou de récupération nécessaires
Les états possibles sont: vérifiés, accepté, mis à jour et révisé.
7.
Dépôt d’information Un média électronique dans lequel les produits et les livrables du projet sont stockés. Il peut
du projet
être doté des caractéristiques suivantes:
-
Capacité de stockage des produits de travail du projet
Capacité de stockage des produits livrables mis en circulation
Capacités de stockage et de récupération (retrieval)
Possibilité de naviguer dans son contenu
Liste du contenu avec description des attributs
Possibilité de partager et de transférer des produits de travail entre les groupes concernés
Contrôles d'accès efficaces
© Prénom, nom
Nom de l'artefact
Description
-
Maintien à jour des descriptions de produits de travail
Possibilité de récupérer des versions archivées des produits de travail
Capacité de communiquer l’état des produits de travail
Changements apportés aux produits de travail sont tracés (tracked) avec les Demandes de
changement
Les états possibles sont: récupérés et mis à jour.
8.
Version de sécurité du
Dépôt d’information
du projet
Un référentiel utilisé comme copie de sécurité du Dépôt d’information du projet et, au besoin,
pour y récupérer l’information.
9.
Énoncé des travaux
Description des travaux à effectuer dans le cadre de la Construction du logiciel. Il peut
comprendre:
-
-
Description de produit
- But
- Exigences générales du client
Description de la Portée de ce qui fait partie de l’entente et de ce qui n’en fait pas partie
Objectifs du projet
Livrables: la liste des produits à livrer au client
L’état possible est: révisé.
10.
Résultats
vérification
de
la Servent à documenter l’exécution des activités de vérification, ce qui peut comprendre:
-
Participants
Date
Lieu
Durée
Liste de vérification
Éléments de vérification réussis
Éléments de vérification échoués
Éléments de vérification en attente
Défauts repérés au cours de la vérification
© Prénom, nom
5. Gabarit et outils
Cette section décrit les gabarits et outils qui facilitent la mise en œuvre du contenu de cette
trousse.
5.1.Gabarit
Lettre d’acceptation, tiré de ([TD PM ENTREE], p.29)
1. Identification du projet
<Énoncer le nom de la compagnie et le nom du projet. Inclure les noms du(es) responsable(s),
leur(s) courriel et leur(s) numéro(s) de téléphone.>
2. Portée du projet
<Énoncer une courte description du logiciel concerné et de ses intentions, incluant les bénéfices,
les objectifs et les buts escomptés. Mettre en relation le logiciel et les buts et les stratégies de la
compagnie>
3. Product Perspective
<Décrire le contexte et l’origine du produit concerné par ce document. Par exemple, établir si ce
produit est un membre d’une famille de produits, le remplacement d’un système existant précis,
ou bien un nouveau produit à part entière. Un diagramme simple montrant les composants
principaux du système complet peut être utile.>
4. Caractéristiques du produit
<Résumer les principales caractéristiques que le produit offre ou bien les fonctionnalités
significatives que le logiciel fournit ou que l’utilisateur peut réaliser. Cela peut inclure : des
exigences de performance ou des exigences de sécurité ou de sûreté de fonctionnement, etc. Pour
chacune d’entre elles, indiquer le niveau d’importance (haut, moyen, bas). Organiser les fonctions
de manière à les rendre compréhensible par le lecteur de ce document.>
5. Environnement opérationnel (Optionnel)
<Décrire l’environnement dans lequel le logiciel devra opérer, en incluant la plate-forme
matérielle, le système d’exploitation avec la version, ainsi que n’importe quels composants
logiciels ou application avec lesquels le logiciel doit cohabiter sans problème.>
6. Contraintes (Optionnel)
<Décrire n’importe quels items ou faits qui limiteraient les options offertes aux développeurs.
Cela peut inclure : politiques de la compagnie ou réglementaires, limitations dues au matériel
(exigences temporelles, exigences en mémoire), etc.>
7. Autres exigences (Optionnel)
<Définir n’importe quelles exigences qui ne sont pas traitées ailleurs dans ce document. Cela peut
inclure des exigences d’internationalisation, des exigences légales, des objectifs de réutilisation
pour le projet, etc. Ajouter n’importe quelle section pertinente pour le projet.>
© Prénom, nom
Structure de découpage du projet (SDP), tiré de ([TD PM ENTREE], p.30)
Ceci peut être utilisé par exemple dans un tableau Excel :
Numéro
de la
tâche
Type de
tâche
Description de la
tâche
Produits associés
Estimation
(personnejour)
Exemple partiel de la SDP, tiré de ([TD PM ENTREE], p.30)
Numéro
de la
tâche
1
1.1
1.2
2
2.1
2.2
2.3
2.4
3
Type de
tâche
Tâche
principale
Sous Tâche
Sous Tâche
Tâche
principale
Sous
Sous
Sous
Sous
Tâche
Tâche
Tâche
Tâche
Tâche
principale
3.1
Sous Tâche
3.2
Sous Tâche
3.3
4
4.1
4.2
4.3
5.
Sous Tâche
Tâche
principale
Sous Tâche
Sous Tâche
Sous Tâche
...
Description de Tâche
Initialisation de l’implémentation du
logiciel
Revue du plan de projet
Établir l’environnement de mise en
œuvre
Analyse des exigences logicielles
Collecte d'information
Identification de la portée du projet
Identification et capture d’exigences
Structurer et prioriser les exigences
Identification des composants logiciels
Comprendre la spécification des
exigences
Documenter l'identification des
composants
Incorporation des composants
Construction logicielle
Conception
Codage
Vérification
...
© Prénom, nom
Estimation
(personne-jour)
3 (2+1)
2
1
12 (5+2+3+2)
5
2
3
2
21 (10+6+5)
10
6
5
45 (15+25+5)
15
25
5
...
Exemple partiel d’une SDP graphique, tiré de ([TD PM ENTREE], p.31)
Exemple partiel du calendrier d’un projet, tiré de ([TD PM ENTREE], p.30)
Le schéma suivant montre un diagramme du GANTT, outil en gestion de projets utilisé pour
représenter toutes les tâches requis pour l’achèvement d’un projet. Il permet de visualiser
l’avancement de ce dernier.
© Prénom, nom
Planification et suivi d’avancement d’un projet, tiré de ([TD PM ENTREE],
p.32)
Le tableau suivant permet de faire un suivi de l’avancement des tâches d’un projet.
Nom du projet : ____________
Tâche
Date de
début
Prévu
Date (aaaa-mm-jj) : ___________
Date de
Fin
prévu
Date de
début
réelle
Avanceme
nt (%)
Date
de fin
réelle
Écart
Le pourcentage (%) d’avancement = durée réelle consommé à ce jour /Durée estimée
Note : Ceci peut être réalisé en Excel dans le cas où un logiciel en gestion de projets n’soit
pas utilisé. On peut réaliser le même tableau pour faire le suivi des coûts et ressources
alloués aussi.
© Prénom, nom
Plan de projet – Exemple de table de matières, tiré de ([TD PM ENTREE],
p.33)
1 Survol du projet
1.1 But, portée et objectifs
- Définition du but et de la portée du projet.
- Liste de membres de l’équipe de travail.
1.2 Livrables du projet
- Liste de items (par exemple documentation, code) à être livrés.
- Spécification de media de livraison.
2 Organisation du projet
2.1 Model du processus
Description du processus à appliquer sur le projet.
2.2 Responsabilités
Identification des rôles et des responsabilités spécifiques à endosser par chaque membre
de l'équipe du projet.
2.3 Procédures de contrôle de changement
Description de la façon dont les changements seront gérés
2.4 Gestion de la configuration
Description de la façon dont la gestion de configuration sera mise en œuvre.
3 Trousse de travail, calendrier et budget
3.1 Trousse de travail
Description de la SDP et des livrables.
3.2 Ressource
Allocation des ressources aux tâches.
3.3 Calendrier
Énumération des tâches du projet et définition des dates de début et de fin de chacune
d’elles.
3.4 Budget
Plan financier du projet
© Prénom, nom
Demande de Changement – Exemple de contenu, tiré de ([TD PM ENTREE],
p.34)
Nom du projet : ____________
Date (aaaa-mm-jj) : ___________
Demande de changement – Explication : ________________________
___________________________________________________________________
__________________________________________________
___________________________________________________________________
__________________________________________________
Impact : ___________________________________________________
__________________________________________________________
__________________________________________________________
Criticité, date requise : _______________________________________
__________________________________________________________
__________________________________________________________
Statut :
Acceptée
Reportée
Rejetée
Commentaires : ____________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
© Prénom, nom
Compte-rendu de réunions – Exemple de contenu, tiré de ([TD PM
ENTREE], p.35)
Nom du projet :
Date (aaaa-mm-jj) :_____________
lieu :_____________
Nom des participants : ________________________
________________________
________________________
But (s):____________________________________________________
__________________________________________________________
__________________________________________________________
Accords : __________________________________________________
__________________________________________________________
__________________________________________________________
Commentaires : ____________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
__________________________________________________________
Prochaine réunion (date, lieu, participants, buts) : ________________
___________________________________________________________________
__________________________________________________
___________________________________________________________________
__________________________________________________
© Prénom, nom
Liste des responsable d’exécuter les tâches, tiré de ([TD PM ENTREE],
p.36)
Cette liste permet d’identifier les responsables de réaliser les tâches du projet ainsi que leur
rôle dans ce dernier. Le but étant d’identifier qui fait quoi.
Nom du projet : ____________
___________
Tâche
Responsable
Date (aaaa-mm-jj) :
Rôle
Rôle : PM : Gestionnaire de projet; WT : Équipe de travail; CUS : Client
Note : Ceci peut être utilisé dans un tableau Excel
© Prénom, nom
Tableau d’identification des risques, tiré de ([TD PM ENTREE], p.37)
Ce tableau permet d’identifier les risques associés aux tâches du projet ainsi que d’identifier
les actionnes requis pour y faire face.
Nom du projet : ____________
Risque
probabilité
Date (aaaa-mm-jj) : ___________
Impact
Action à entreprendre
Note : Ceci peut être utilisé dans un tableau Excel
© Prénom, nom
Responsable
5.2.Outils
«
Il existe une grande variété d’outils de gestion de projet disponibles tant en
versions libres (Open Source) qu’en versions propriétaires. On peut les trouver en
ligne (sur Internet). Une bonne comparaison informelle de ces outils est disponible
en Wikipédia sur le titre de « Gestion de projet » à l’adresse suivante :
http://en.wikipedia.org/wiki/Comparison_of_project_management_software
Les deux principales utilisations des logiciels de gestion de projet concernent la
planification et la fourniture des informations d'état du projet. Les fonctions
typiques de ce type de logiciels sont :

Échéancier de projet : une des tâches les plus courantes consiste à planifier une
série d'événements (tâches, livrables, jalons). La complexité de cette tâche peut
varier considérablement selon l'outil utilisé. Parmi les défis qu’on trouve souvent,
il y a :

Planifier des événements qui dépendent les uns des autres de différentes façons
ou avec différentes dépendances
Planifier le travail des personnes et les ressources qui sont requises par les
différentes tâches
Gérer les incertitudes d’estimation de la durée de chaque tâche
Ranger les tâches pour répondre aux différentes échéances
Jongler avec plusieurs projets simultanés pour répondre à une variété d'exigences










Fournir des informations sur l'état du projet : la planification du projet
logiciel doit fournir beaucoup d'informations à diverses personnes, pour justifier le
temps passé à cette planification. Les données requises peuvent inclure :
Listes de tâches pour chaque membre de l’équipe et le calendrier d’affectation des
ressources.
Information sur le temps restant pour chaque tâche.
Information sur la charge de travail pour la planification de vacances
Information sur la relation entre la performance planifiée et la performance réelle
Utilisation optimale des ressources disponibles
» ([TD PM ENTREE], p.38)
© Prénom, nom
6. Exemple de la mise en œuvre de tâches
Note: Cette section fournit un exemple d'une représentation graphique de la mise en œuvre
de tâches. Cet exemple vise à aider le lecteur à mettre en œuvre son propre cycle de
développement en l’adaptant au contexte de son projet.
Figure 3 - Flux de gestion de projets logiciels ([Richard E. (Dick) Fairley])
Exemple de la mise en œuvre de tâches
[Ceci est un exemple qui utilise le patron SPEM de Microsoft Visio (http://
www.pa.icar.cnr.it/cossentino/FIPAmeth/docs/SPEM.vss) pour produire ce diagramme.
© Prénom, nom
Chef de Projet
Équipe de Travail
Réviser le plan
du projet
Préparer
l’environnement
d’Implémentation
Collecter
l’information
Analyste
Programmeur
Préparer
l’environnement
d’Implémentation
Identifier et
prioriser les
exigences
logicielles
Identifier les
composants
Construire le
logiciel
© Prénom, nom
Tester le
logiciel
Tester le
logiciel
Livrer le produit
final
7. Liste de vérification
Cette section présente des listes de vérification afin d'aider à la mise en œuvre des tâches
de cette trousse.
Liste de vérification d’un plan de projet, tiré de ([TD PM ENTREE], p.37)
Traduit et adapté de : Gilb, T., Graham, D., Software Inspection, Addison-Wesley, 1993.
PP 1 (BUTS)
Le plan énonce les objectifs du projet, en référence aux besoins du client.
PP 2 (SDP)
Le plan contient la structure de découpage du projet (SDP) pour toutes les tâches.
PP 3 (RESSOURCES)
Toutes les ressources sont spécifiées.
PP 4 (CALENDRIER)
Le plan inclut la date d’initiation et de fin de chaque tâche et le membre de l’équipe de travail
qui l’exécutera.
PP 5 (LIVRABLES)
Le plan spécifie tous les livrables et les formats de livraison.
PP 6 (BUDGET)
Le plan financier du projet est spécifié
PP 7 (RESPONSABILITÉS)
Tous les rôles et les responsabilités spécifiques à adopter par chaque membre de l'équipe du
projet sont identifiés.
PP
8
(CONTRÔLE
CHANGEMENT)
DE
La façon dont les changements seront gérés est décrite.
PP
9
(GESTION
CONFIGURATION)
LA
La façon dont la gestion de configuration sera mise en œuvre est décrite.
DE
PP 10 (APPROBATION)
Le plan est approuvé par le chef du projet
Liste de vérification pour la structure de découpage des tâches (SDP)
SDP 1 (COMPLÈTE)
Est-ce que tous les éléments du SDP sont définis en termes de livrables?
SDP 2 (COMPLÈTE)
Est-ce que tous les livrables ont été inclus dans le SDP?
SDP 3 (UNIQUE)
Est-ce que tous les éléments du SDP sont clairs et uniques?
SDP 4 (RESPONSABILITÉ)
Y-a-t-il seulement 1 groupe ou 1 personne responsable pour chaque élément du SDP?
SDP 5 (NIVEAU DE DÉTAILS)
Est-ce que chaque élément du SDP est à un niveau de décomposition approprié
permettant l'estimation de la durée et des coûts avec suffisamment d'assurance?
SDP 6 (ATTRIBUTS)
Est-ce que chaque élément du SDP a une date de début et une date de fin?
SDP 7 (MESURE)
Est-ce que le progrès de chaque élément du SDP peut être mesuré facilement durant le
suivi du projet?
© Prénom, nom
8. Matrices de couverture
Cette annexe démontre la traçabilité de cette trousse de déploiement avec des standards de
l'ISO et avec le CMMI® pour le développement, version 1.3. Pour chacun des éléments, sa
couverture est indiquée selon la convention suivante:
o
Couverture complète = C
o
Couverture partielle
= P
o
Aucune couverture
=A
8.1.Matrice de couverture de l'ISO 9001
Titre de la tâche et étape1
Couverture
Clause de l'ISO 9001
C/P/A
PM.1.1 Réviser l’Énoncé des travaux
PM.1.2 Définir, avec le client, les
Directives de livraison pour chacun des
Livrables déterminés dans l'Énoncé des
travaux.
PM.1.3 Déterminer les Tâches précises à
effectuer afin de fournir les Livrables ainsi
que les Composants logiciels indiqués
dans l’Énoncé des travaux. Intégrer les
Tâches dans le processus de SI ainsi que la
vérification, la validation et les révisions
des Tâches qui incombent au client et à
l'équipe de travail pour assurer la qualité
des produits. Déterminer les Tâches visant
l'application des Directives de livraison.
Document les Tâches.
PM.1.4 Établir la Durée estimée pour la
réalisation de chacune des tâches.
PM.1.5 Déterminer et documenter les
Ressources humaines et matérielles
nécessaires ainsi que l'équipement et les
outils requis et les normes à appliquer
ainsi que la formation dont ont besoin les
membres de l'équipe de travail pour
réaliser le projet. Intégrer au calendrier les
dates auxquelles ces Ressources et cette
formation sont requises.
P
Meeting de faisabilité
7.2.2.1-a
Structure et répartition
du travail
7.3.1.1- f - 2
P
P
Estimation
4.2.4.2-b
Gestion des ressources
C
6
7.3.1.1- c
7.3.1.1- f - 3
PM.1.6 Établir la Composition de l’équipe
de travail et en assigner les rôles et les
responsabilités
en
fonction
des
Ressources.
© Prénom, nom
Commentaires
PM.1.7 Fixer les dates prévues de
commencement et de fin pour chacune des
Tâches afin de créer le Calendrier des
tâches du projet en tenant compte des
Ressources qui y sont affectées, de la
séquence des Tâches et de leur
dépendance.
PM.1.8 Calculer et documenter les Coûts
et les efforts estimés.
P
Déterminer les étapes
importantes
7.3.1.1- f - 5
P
Estimation
4.2.4.2-b
Gestion des risques
PM.1.9 Déterminer et documenter les
risques qui peuvent avoir une incidence
sur le projet.
C
PM.1.11 Produire le Plan de projet en y
intégrant les éléments précédemment
définis et documentés.
A
PM.1.12 Inclure la Description du produit,
la Portée, les Objectifs et les Livrables au
Plan de projet.
A
7.2.2.1-h-1
7.2.2.2
PM.1.13 Vérifier le Plan de projet et en
obtenir l'approbation.
S’assurer que tous les éléments du Plan de
projet sont viables et cohérents. Les
résultats sont documentés dans les
Résultats de la vérification et des
corrections sont apportées jusqu’à ce que
le document reçoive l’approbation du PM.
A
PM.1.14 Réviser et accepter le Plan de
projet.
Le client examine et accepte le Plan de
projet en s'assurant que les éléments qui y
sont énoncés correspondent à ceux de
l'Énoncé des travaux.
PM.1.10 Documenter la Stratégie de
contrôle des versions dans le Plan de
projet.
PM.1.15 Établir un Dépôt d’information
du projet en utilisant la Stratégie de
contrôle des versions.
A
A
8.2.Matrice de couverture de l’ISO/IEC 12207
Titre de la tâche et étape1
Étape 1, Étape 2
Couverture
C/P/A
C
Tâches de l'ISO/IEC 12207
Lancement du projet
6.3.1.3.1
© Prénom, nom
Commentaires
PM.1.7 Fixer les dates prévues de
commencement et de fin pour chacune des
Tâches afin de créer le Calendrier des
tâches du projet en tenant compte des
Ressources qui y sont affectées, de la
séquence des Tâches et de leur
dépendance.
C
Planification de l’achèvement
des taches
6.3.1.3.2.1 - a
Étape 7
PM.1.4 Établir la Durée estimée pour la
réalisation de chacune des tâches.
C
Étape 4
PM.1.6 Établir la Composition de l’équipe
de travail et en assigner les rôles et les
responsabilités en fonction des
Ressources.
P
Estimation de l’effort
6.3.1.3.2.1 - b
Allocation des taches
6.3.1.3.2.1 - c
Étape 6
PM.1.6 Établir la Composition de l’équipe
de travail et en assigner les rôles et les
responsabilités en fonction des
Ressources.
P
Assigner les rôles et les
responsabilités
6.3.1.3.2.1 - d
Étape 6
PM.1.9 Déterminer et documenter les
risques qui peuvent avoir une incidence
sur le projet.
C
6.3.1.3.2.1 - f
Étape 9
PM.1.8 Calculer et documenter les Coûts
et les efforts estimés
Étape8
Identification des risques
inhérents au projet et aux
différentes taches
C
Estimation des couts de
réalisation
6.3.1.3.2.1 - h
© Prénom, nom
8.4.Matrice de couverture du modèle CMMI pour le développement
Titre de la tâche et étape1
Couverture
C/P/A
Objectifs / Pratiques du
modèle CMMI V1.2
PM.1.3 Déterminer les Tâches précises à
effectuer afin de fournir les Livrables ainsi
que les Composants logiciels indiqués
dans l’Énoncé des travaux. Intégrer les
Tâches dans le processus de SI ainsi que la
vérification, la validation et les révisions
des Tâches qui incombent au client et à
l'équipe de travail pour assurer la qualité
des produits. Déterminer les Tâches visant
l'application des Directives de livraison.
Document les Tâches.
C
PM.1.4 Établir la Durée estimée pour la
réalisation de chacune des tâches.
P
SP 1.2 Etablir les estimes
pour les taches
A
SP 1.3 Définir cycle de vie du
projet
C
SP 1.4 Estimation des couts et
des efforts
PM.1.8 Calculer et documenter les Coûts
et les efforts estimés
PM.1.7 Fixer les dates prévues de
commencement et de fin pour chacune des
Tâches afin de créer le Calendrier des
tâches du projet en tenant compte des
Ressources qui y sont affectées, de la
séquence des Tâches et de leur
dépendance.
Commentaires
SP 1.1 Estime la portée du
projet
SP 2.1 Etablir le budget et la
planification
P
PM.1.9 Déterminer et documenter les
risques qui peuvent avoir une incidence
sur le projet.
C
PM.1.10 Documenter la Stratégie de
contrôle des versions dans le Plan de
projet.
C
PM.1.6 Établir la Composition de l’équipe
de travail et en assigner les rôles et les
responsabilités
en
fonction
des
Ressources.
C
SP 2.2 Identification des
risques
SP 2.3 Plan de gestion
SP 2.4 Plan de la gestion des
ressources reliées au projet
SM
CMM Integration est une marque de service de Carnegie Mellon University.
®
Capability Maturity Model, CMMI est enregistré U.S. Patent and Trademark Office par
Carnegie Mellon University.
1
Ceci est le titre de la tâche de la section 4 de cette trousse.
© Prénom, nom
PM.1.5 Déterminer et documenter les
Ressources humaines et matérielles
nécessaires ainsi que l'équipement et les
outils requis et les normes à appliquer
ainsi que la formation dont ont besoin les
membres de l'équipe de travail pour
réaliser le projet. Intégrer au calendrier les
dates auxquelles ces Ressources et cette
formation sont requises.
SP 2.5 Plan de gestion des
connaissances et des
compétences
A
A
SP 2.6 Plan de gestion de
l’implication des parties
prenantes
PM.1.11 Produire le Plan de projet en y
intégrant les éléments précédemment
définis et documentés.
SP 2.7 Etablir un plan de
gestion de projet
PM.1.13 Vérifier le Plan de projet et en
obtenir l'approbation.
SP 3.1 Revue des plans qui
affectent le projet
S’assurer que tous les éléments du Plan de
projet sont viables et cohérents. Les
résultats sont documentés dans les
Résultats de la vérification et des
corrections sont apportées jusqu’à ce que
le document reçoive l’approbation du PM.
PM.1.6 Établir la Composition de l’équipe
de travail et en assigner les rôles et les
responsabilités
en
fonction
des
Ressources.
P
SP 3.2 Concilier travail et les
niveaux de ressources
P
SP 3.3 Obtenir l’approbation
du plan
PM.1.14 Réviser et accepter le Plan de
projet.
Le client examine et accepte le Plan de
projet en s'assurant que les éléments qui y
sont énoncés correspondent à ceux de
l'Énoncé des travaux.
C
© Prénom, nom
9. Références
Acronyme
Référence
[ISO/IEC 12207]
ISO/IEC 12207 Systems and software engineering - Software life cycle processes.
[ISO/IEC 15289]
ISO/IEC 15289 Systems and software engineering - Content of systems and software life cycle process
information products (Documentation)
[ISO/IEC 24765]
ISO/IEC 24765:2011, Systems and Software Engineering Vocabulary.
Une
version
électronique
de
ce
document
http://pascal.computer.org/sev_display/index.action
est
disponible
à:
[ISO/IEC 29110-5-1-2]
ISO/IEC TR 29110-5-1-2:2012, Ingénierie du logiciel — Profils de cycle de vie pour les très petits
organismes (TPO) —Partie 5-1-2 : Guide de gestion et d'ingénierie— Groupe de profils génériques :
Profil basique.
Ce document est disponible gratuitement sur le site suivant:
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
[Jalote02]
Software Project Management in Practice, P. Jalote, Addison-Wesley, 2002
[Jones04]
Software Project Management Practices: Failure Versus Success,C. Jones, CrossTalk, octobre 2004.
[PMBOK 2008]
Guide du corpus des connaissances en management de projet (Guide PMBOK), quatrième édition, version
anglaise, Project Management Institute, Pennsylvanie, 2008.
[Putnam97]
Industrial Strength Software: Effective Management Using Measurement, L. H. Putnam and W. Myers,
IEEE, 1997.
[Sommerville06]
Software Engineering (8 édition), I. Sommerville, Addison-Wesley, 2006.
[O'Connor 12]
Software Project Management in Very Small Entities with ISO/IEC 29110, Springer 2012.
Ce document est disponible sur Internet à l'adresse suivante:
http://link.springer.com/chapter/10.1007%2F978-3-642-31199-4_29
[PMI 2012]
PMI'S Pulse of the Profession, Driving Success in Challenging Times, March 2012
Ce document est disponible sur Internet à l'adresse suivante:
http://www.pmi.org/~/media/PDF/Research/2012_Pulse_of_the_profession.ashx
[TD PM ENTREE]
Hernandez, G., Gonzalez, W. 2010, Trousse de déploiement, Gestion de projet, Profil d'entrée. Version
française. En ligne. 42p. http://profs.etsmtl.ca/claporte/VSE/Groupe24-menu.html. Consulté le 15
décembre 2012.
[TD VER/VAL]
Trousse de déploiement, Vérification et Validation, Profil basique, version anglaise
Ce document est disponible sur Internet à l'adresse suivante:
http://profs.etsmtl.ca/claporte/VSE/Groupe24-menu.html
[TD VERSION]
Trousse de déploiement, Contrôle des versions, Profil basique, version anglaise
Ce document est disponible sur Internet à l'adresse suivante:
http://profs.etsmtl.ca/claporte/VSE/Groupe24-menu.html
[TD LIVRAISON]
Trousse de déploiement, Livraison du produit, Profil basique, version anglaise
Ce document est disponible sur Internet à l'adresse suivante:
http://profs.etsmtl.ca/claporte/VSE/Groupe24-menu.html
[SWEBOK 2004]
Guide to the Software Engineering Body of Knowledge, Version 2004
Ce document est disponible sur Internet à l'adresse suivante:
http://www.swebok.org
[Richard
Fairley]
E.
(Dick)
Managing and Leading SoftwareProjects
© Prénom, nom
10. Formulaire d’évaluation de la trousse
Trousse de déploiement - Gestion de projet – Profil basique Version 0.5
Vos commentaires nous permettront d'améliorer cette trousse de déploiement; vos
suggestions sont les bienvenues.
1. Est-ce que le contenu de cette trousse de déploiement vous satisfait?
Satisfait
Ni Satisfait ni insatisfait
satisfait
Très Insatisfait
2. Par rapport à la SÉQUENCE dans laquelle les sujets sont discutés, vous êtes ?
3. Par rapport à l’APPARENCE/FORMAT de cette trousse de déploiement, vous êtes?
Satisfait
4.
Ni Satisfait ni insatisfait
satisfait
Très Insatisfait
Considérez-vous que cette trousse contient des sujets inutiles?
(décrivez-les
S.V.P.)
5.
Considérez-vous que cette trousse manque de sujets importants? (décrivez-les
S.V.P.)
 Sujet proposé :
 Justification du nouveau sujet:
6. Considérez-vous que cette trousse a des erreurs?

S’il vous plaît indiquez:
 Description de l’erreur:
 Position de l’erreur dans le document (section #, figure #, table #) :
7. Avez-vous d’autres informations ou commentaires?
8.
Est-ce que vous recommanderez cette trousse de déploiement à un collègue
d’une autre TPO?
Certainement
Probablement
Peut-être
Probablement non
© Prénom, nom
Certainement non