Chapitre 2

La gestion plus
2 classique d’un projet

logiciel
Dans ce chapitre, les sujets suivants sont abordés:

– Un modèle de référence pour décrire les enjeux de la gestion d’un projet logiciel;
– Les sujets de planification d’un projet logiciel, incluant : le WBS, le RACI, l’organigramme fonctionnel, l’estimé
et le chemin critique;
– Mesurer et contrôler le progrès et les livrables;
– La fermeture d’un projet;
– Les autres sections d’un plan de projet;
– Un court exemple de contenu d'un plan de projet pour la modification d'un site Web existant.
2.1 INTRODUCTION
La plupart des problèmes que vous rencontrez ou avez rencontrés dans les projets logiciels sont
causés par des difficultés de gestion et de direction (c.-à-d. planification, estimation, mesure,
contrôle, communication, coordination et gestion des risques) plutôt que par des problèmes
techniques (par exemple, analyse, conception, codage et test). Ces difficultés proviennent de sources
multiples; certains que vous pouvez contrôler en tant que chef de projet et d’autres que vous ne
pouvez pas. Les facteurs que vous ne pouvez pas contrôler sont appelés des contraintes. Il s’agit de
limitations imposées par des forces externes sur tout ou une partie du domaine opérationnel, des
exigences opérationnelles, des exigences du produit, de la portée du projet, du budget, des
ressources, de la date d’achèvement et de la technologie de la plateforme.
Le domaine opérationnel est l’environnement dans lequel le logiciel livré sera utilisé. Les domaines
opérationnels (aussi nommé domaine d’affaires) englobent pratiquement tous les domaines de la
société moderne, y compris les environnements de soins de santé, de finances, de transport, de
communication, de divertissement, d’affaires et de fabrication. Comprendre le domaine dans lequel
le logiciel fonctionnera est essentiel au succès d’un projet. Les exigences opérationnelles décrivent
les connaissances et besoins des utilisateurs (c’est-à-dire la vue externe et les règles d’affaires) du
système à livrer. Certaines des caractéristiques souhaitées, spécifiées dans les exigences, peuvent
dépasser l’état actuel des connaissances des développeurs, que ce soit dans leur ensemble ou au
sein de votre organisation. Les spécifications du produit sont la vue des développeurs (c’est-à-dire
la vue interne) du système à construire; elles incluent les capacités fonctionnelles et les attributs
de qualité (exigences non fonctionnelles) que le produit livré doit posséder pour satisfaire les clients.
Les normes de processus et de cycles de vie spécifient les manières de mener les activités de travail
des projets logiciels. Votre organisation peut avoir des méthodes normalisées pour mener des
activités spécifiques, telles que la planification et l’estimation de projets à l’aide de points de
fonction, et pour mesurer des aspects du projet tel que la conformité au calendrier, l’utilisation des
ressources et la mesure des attributs de qualité du produit avant son acceptation. Dans certains
© Alain April, PhD, 2020 - Tous droits réservés

cas, le client peut exiger des normes et des directives pour la réalisation d’un projet que ce soit
dans un contrat ou non. Quatre des normes et modèles de pratiques exemplaires les plus
couramment utilisés pour le logiciel sont le modèle de maturité de la capacité (CMMI), la norme
ISO/IEEE 12207, la norme IEEE 1058 de gestion de projet et le corpus de connaissances de la
gestion de projet (PMBOK) du Project Management Institute (PMI). Nous pourrons couvrir plus en
détail ces documents dans le chapitre sur les normes et modèles.
La portée d’un projet est l’ensemble des activités qui doivent être accomplies pour livrer un produit
acceptable dans les délais et dans les limites du budget. Les ressources sont les actifs, à la fois
corporatifs et externes, qui peuvent être appliqués au projet. Les ressources ont souvent des
attributs de qualité et de quantité; par exemple, vous pouvez avoir un nombre suffisant de
développeurs de logiciels disponibles (quantité d’actifs), mais certains peuvent ne pas avoir les
compétences nécessaires (qualité des actifs). Le budget est l’argent disponible pour acquérir et
utiliser des ressources; le budget de votre projet peut être limité, de sorte que les ressources
disponibles au sein de l’organisation ne peuvent pas être utilisées. La date d’achèvement visée est
le jour où le produit doit être fini et prêt à être livré. Dans certains cas, il peut y avoir plusieurs
dates d’achèvement auxquelles des sous-ensembles du produit final doivent être livrés. La date de
livraison limitée peut être irréaliste.
La technologie de la plateforme de développement logiciel inclut l’ensemble des méthodes, outils et

technologies de développement utilisées pour produire un produit logiciel. Les exemples incluent
des outils pour développer et documenter les exigences et les conceptions, des compilateurs et des
débogueurs pour générer et vérifier le code, des outils de contrôle de version pour suivre les versions
en constante évolution des produits de travail du projet et des outils de test permettant de tester le
logiciel. Ces technologies de incluent également les processeurs matériels et les systèmes
d’exploitation sur lesquels le logiciel est développé et sur lesquels il fonctionnera (qui peuvent être
identiques ou différents). Un ou plusieurs aspects de la technologie de la plateforme imposée
peuvent être obsolètes ou inappropriés pour le travail à effectuer.
Les objectifs commerciaux peuvent contraindre votre projet à terminer le produit le plus rapidement
possible (afin de maximiser les revenus à court terme) ou à produire la meilleure qualité possible
(pour maintenir la crédibilité auprès des clients existants). Des considérations éthiques peuvent
empêcher votre projet de fournir un produit présentant des défauts connus ou d’intégrer la
connaissance du produit d’un concurrent acquise par des méthodes contraires à l’éthique.
Certains des problèmes les plus difficiles que vous rencontrerez dans la gestion de projets logiciels
découlent de l’établissement et du maintien d’un équilibre entre les contraintes relatives à la portée
du projet, au budget, aux ressources, à la technologie et à la date de livraison prévue. Comme nous
l’avons introduit au chapitre précédent, le compromis entre ces facteurs doit être établi dans votre
plan de projet initial. La portée de votre projet peut changer au cours de son exécution en raison
de modifications apportées aux exigences du produit ou d’autres facteurs tels que le budget ou la
date de livraison. Les contraintes pesant sur votre budget, vos ressources et votre calendrier
peuvent changer en raison de facteurs internes à votre organisation, de changements dans
l’environnement opérationnel du produit à livrer ou de pressions concurrentielles. Les modifications
de la portée du projet doivent toujours être accompagnées des modifications correspondantes du
calendrier, du budget, des ressources et (éventuellement) de la technologie. Par exemple, il peut ne
pas être possible de livrer un produit satisfaisant avec 10 personnes pendant 12 mois, mais cela
pourrait être possible si le calendrier était prolongé à 15 mois ou si le nombre de personnes passait
de 10 à 15, ou si les exigences pour le produit ont été réduites à la fonctionnalité qui peut être
livrée avec une qualité acceptable par 10 personnes en 12 mois.
Les principales activités de la gestion de projet sont la planification et l’estimation, la mesure et le

contrôle, la communication et l’animation et la gestion des facteurs de risque. La planification et
l’estimation s’attachent à déterminer l’étendue des activités à réaliser, à estimer les efforts et le

calendrier de l’ensemble du projet et à élaborer des estimations et des plans pour chaque activité
principale. La planification des mesures implique la mise en place d’un système de collecte de
données et de rapports qui sera utilisé pour déterminer et rendre compte de l’état actuel des
activités de travail et des produits de travail de manière continue. Le contrôle implique l’application
d’actions correctives lorsque l’état réel, comme indiqué par les mesures, ne correspond pas à l’état
planifié.
La communication implique la mise en place et le maintien de canaux de communication adéquats

entre toutes les parties impliquées, afin que chacun soit au courant des progrès et des problèmes
et qu’il soit constamment rappelé aux objectifs et aux critères de réussite du projet. Diriger consiste
à orienter, à éliminer les obstacles et à maintenir le moral du personnel du projet.
La gestion des risques consiste à identifier les facteurs de risque (problèmes potentiels), à la fois
initialement et de manière continue; surveillance des facteurs de risque identifiés; et entreprendre
des activités d’atténuation des risques, telles que la préparation de plans d’urgence et leur réduction
si nécessaire.
2.2 MODÈLE DES ENJEUX DE GESTION DE PROJET LOGICIEL

L’objectif principal d’un projet logiciel est de développer et de fournir un ou plusieurs produits de
travail acceptables dans les limites des fonctionnalités requises, des attributs de qualité, de la
portée du projet, du budget, des ressources, de la date d’achèvement, de la technologie et d’autres
facteurs. Les produits de travail à livrer (c.-à-d. code d’objet, matériel de formation et instructions
d’installation, par exemple) résultent du flux de produits de travail intermédiaires produits selon
les processus de travail (exigences, conception, code source et scénarios de test).
Le modèle des activités de gestion de projets logiciels utilisés dans ce chapitre est présenté à la
figure 2.1. Tous les modèles, y compris celui de la figure 2.1, sont des abstractions de situations
réelles qui soulignent certains aspects d’intérêt et suppriment des détails qui n’ont aucune
importance pour les objectifs du modèle. Les détails importants peuvent être exprimés dans des
modèles subordonnés. Les modèles subordonnés à la figure 2.1 sont présentés tout au long de ce
livre.
La figure 2.1 indique certains des processus qui soutiennent l’activité principale du développement
de produits; elles comprennent la vérification et la validation (V&V et Tests), l’assurance qualité
logicielle (AQL), la gestion de la configuration (GC), etc. Chaque processus de soutien doit être
accompli conformément à un modèle bien défini pour la réalisation des activités de travail de ce
processus.
Le modèle de la figure 2.1 s’appelle un modèle d’activités, car il met l’accent sur les activités de
travail et le flux de produits de travail entre les activités de travail. Chaque activité de travail dans
un modèle de processus génère un ou plusieurs produits de travail qui fournissent des intrants
pour les activités de travail suivant. Par produit de travail, nous entendons tout document produit
par un projet logiciel (y compris le code source). Certains produits de travail sont livrés au client
(appelés produits de travail livrables), tandis que d’autres sont des produits de travail
intermédiaires développés pour faire avancer le processus de résolution créative de problèmes de
manière ordonnée.

Demandes de
changements Rapports de problèmes
exigences
Processus
Clients Planification
Définir les Développement
et Assigner le
activités travail
Patrons Ajustements
Vérification et
contraintes
Validation
Estimer Contrôler Assurance

Qualité (AQL)
Rapports de projets Rapports de statuts

Rapporter Mesurer
Figure 2.1 – Modèle des activités de gestion de projets logiciels
Comme illustré dans le modèle de flux de travail décrit à la figure 2.1, un projet logiciel est lancé
par le client et les responsables. Un client est la personne ou l’organisation qui fournit les exigences
relatives aux produits livrables et les accepte. Les clients peuvent imposer des contraintes à un
projet, telles que la spécification d’une interface de base de données requise (contrainte de produit)
où la date à laquelle le système livré doit être disponible pour utilisation (contrainte de processus).
Les gestionnaires incluent votre direction et vous, le chef de projet. Les gestionnaires spécifient des
contraintes et des directives. Une contrainte de processus émanant de votre responsable peut
limiter le nombre de personnes disponibles pour mener à bien le projet. Une directive de gestion
peut nécessiter que tous les projets de logiciel de l’organisation exécutent une activité de
conception. En tant que responsable de projet, vous pouvez émettre des directives exigeant que la
conception soit documentée à l’aide de UML (Universal Modeling Language) et qu’une ou plusieurs
revues de conception soient organisées.
Les exigences, les contraintes et les directives fournissent les entrées au processus de planification,
qui est (ou devrait être) une activité de groupe dirigée par vous, le chef de projet. Vous devez
impliquer le client, des membres sélectionnés de l’équipe de développement et d’autres intervenants
principaux dans le processus de planification. La planification implique une estimation. Les
facteurs à évaluer initialement comprennent un calendrier pour la réalisation des principales
activités de travail; types et nombre de ressources nécessaires, quand et le temps nécessaire; et les
jalons du projet (moments où les progrès sont évalués). L’estimation est mieux réalisée en utilisant
les données historiques d’un référentiel de données. Les données à la fin de votre projet peuvent
être placées dans un référentiel pour aider à l’estimation des projets futurs. Les données
intermédiaires peuvent être conservées pour évaluer les progrès et préparer des estimations
d’achèvement, ce qui peut entrainer une replanification.
Les résultats de votre processus de planification incluront l’identification des rôles à jouer dans la
conduite du projet, ce qui aboutira à l’affectation de personnel à ces rôles. Au cours de la
planification initiale, les principales activités à planifier comprennent le développement de logiciels
et les divers processus d’appui telles que la gestion de la configuration, l’assurance de la qualité
des processus et des produits, la vérification, la validation, la formation des utilisateurs; plus
d’autres activités nécessaires qui constituent la portée de votre projet. Les plans détaillés de ces
activités évolueront en même temps que le projet.
Au cours de l’exécution du projet, les données sont collectées et les rapports de statut sont préparés
périodiquement par vous et votre personnel. Les rapports d’état seront utilisés par vous (c.-à-d. le

responsable du projet), votre client, vos responsables, les groupes de support et d’autres parties
prenantes du projet. Les rapports de situation comparent les progrès prévus aux progrès réels; en
travaillant ensemble, vous et votre client pouvez alors réviser les plans et les exigences ou vous
pouvez, par exemple, réaffecter du personnel à différents rôles de projet (par exemple, un
concepteur de logiciel peut être déplacé vers l’équipe de validation indépendante). Les données de
statut servent également à fournir une base pour estimer les progrès futurs en fonction des progrès
réalisés à ce jour (ce qui peut entrainer une replanification), et sont conservées afin de fournir une
base d’estimation pour les projets futurs.
Les rapports de problèmes sont générés pour documenter les défauts découverts dans les produits
de travail qui doivent être retravaillés. Les rapports d’état, les nouvelles exigences et les
modifications des exigences, des contraintes, des directives et des rapports d’incidents fournissent
les données nécessaires à la mise à jour, à l’élaboration et à la révision continues de votre plan de
projet.
Chaque organisation qui développe et met à jour des logiciels, y compris le vôtre, doit disposer d’un
ou de plusieurs modèles de développement de logiciels qui décrivent les principales activités et le
flux de produits de travail. Chaque membre de l’organisation doit connaitre le(s) modèle(s) de flux
de travail et comprendre comment ses activités et produits de travail s’intègrent dans le(s) modèle(s).
Tous les membres de votre organisation de développement de logiciels devraient être en mesure de
décrire et de décrire le ou les modèles de flux de travail utilisés dans l’organisation. S’il existe
plusieurs modèles de flux de travail, tout le monde devrait comprendre les types de projets pour
lesquels les différents modèles sont appropriés.
2.3 LE PROCESSUS DE PLANIFICATION DU PROJET

Les entrées de la planification (voir figure 2.1) incluent : 1) les exigences du client; ainsi que 2) les
directives/contraintes des gestionnaires (c.-à-d. vos patrons). Les exigences système, la conception
du système et les exigences logicielles peuvent également être disponibles ou développées au début
du projet. Comme indiqué au chapitre X, les exigences du client incluent des fonctionnalités
opérationnelles, des attributs de qualité et des contraintes de conception pour le projet. Les
contraintes imposées par le client peuvent inclure à la fois des contraintes de produit et de
processus.
Une contrainte de produit peut nécessiter que le système soit développé à l’aide d’une version
spécifiée d’un système d’exploitation ou que le système nouveau ou modifié fournisse une interface
SQL à une base de données existante. Une contrainte de processus peut nécessiter que le système
soit livré dans une séquence progressive de fonctionnalités croissantes ou que le code source du
logiciel livrable, ainsi que les spécifications et la documentation de conception, soit fourni à un
agent indépendant pour vérification et validation finales. Les directives/contraintes de gestion
peuvent inclure une déclaration de politique générale selon laquelle tous les projets doivent
produire une documentation de conception et en vérifier l’exhaustivité, l’exactitude et la cohérence
au moyen d’examens par des pairs. Une contrainte de gestion peut limiter les ressources de votre
projet à un effectif de 10 développeurs de logiciels.
Certaines de vos premières tâches, en tant que chef de projet, consistent à établir un processus de
communication permanente avec le représentant du client désigné (c.-à-d. votre principal point de
contact) et à clarifier avec lui les exigences opérationnelles, les contraintes de développement et les
critères de succès pour le projet.
Chaque besoin opérationnel doit être priorisé par catégorie : essentiel, souhaitable ou optionnel
pour faciliter la réalisation d’un équilibre entre les besoins, le calendrier et le budget. Il faut

suffisamment de temps et de ressources pour mettre en œuvre toutes les exigences essentielles et
autant d’exigences souhaitables que le client le souhaite.
En fonction de la nature et de la portée de votre projet, clarifier les exigences opérationnelles et

développer les exigences système, l’architecture système et les exigences logicielles peuvent être
votre tâche. Sinon, vous pouvez les déléguer à un ou plusieurs membres de votre équipe, s’ils ont
déjà été assignés. Votre compréhension des exigences opérationnelles et des contraintes de
développement influera votre choix du modèle de cycle de vie de développement logiciel à utiliser et
des procédures à suivre pour le projet. De plus, chaque type de plan doit être soumis à une revue
formelle et accepté par les parties prenantes appropriées, y compris la version initiale du plan et
ses modifications ultérieures. Parallèlement à la préparation des informations génériques
énumérées ci-dessus, la planification des spécifications d’un projet de logiciel devrait inclure
typiquement les activités décrites dans la table des matières suivante :
– 1.0 Introduction
– 2.0 Contenu du projet :
– 2.1 Description de la situation actuelle : Cette section décrit le contexte actuel, rappel de la
problématique et des circonstances qui amènent le projet; forces, faiblesses, menaces, compétition.
– 2.2 Objectifs d’affaires : Cette section démontre les raisons pour lesquelles le projet doit être
entrepris.
– 2.3 Description du produit (logiciel) : Cette section image les caractéristiques du système
- 2.3.1 Vue schématique du système existant/futur
- 2.3.2 Explication de la vue schématique
– 2.4 Les limites du projet : Cette section documente ce qui est inclus dans le projet et énonce
explicitement les exclus du projet, au cas où une partie prenante pourrait supposer qu’un produit,
service ou un résultat particulier puisse être un composant du projet.
– 2.5 Structure de découpage du projet (WBS)
– 2.6 Produits livrables du projet : Cette section décrit les grandes phases du projet ainsi que leur
date de début et date de fin.
– 2.7 Critères d’acceptation du produit : Cette section décrit les critères d’acceptation du produit
fini. Ce sont les critères parmi lesquels les exigences de performance et les conditions essentielles
doivent être satisfaits avant de pouvoir accepter les livrables d’un projet.
– 3.0 Contraintes : Cette section décrit les contraintes du projet. Une contrainte est un état, une
qualité ou une sensation de restriction à une action déterminée ou à l’inaction. Une restriction ou
une limitation, interne ou externe au projet, affectant les performances du projet ou d’un
processus.
– 4.0 Hypothèses : Dans un but de planification, les hypothèses sont des facteurs considérés vrais,
réels ou certains sans preuve ni démonstration. Elles ont un impact sur tous les aspects de la
planification du projet et font partie de son élaboration progressive. Les équipes de projet émettent,
documentent et confirment souvent les hypothèses lors du processus de planification. Les
hypothèses comportent en général un degré de risque.
– 5.0 Organigramme fonctionel du projet
– 6.0 Parties prenantes et équipes de projet :
– 6.1 Comité de direction de projet (CDP) : Le rôle du comité de direction de projet (CDP) est
principalement d'approuver les objectifs d'affaires, d’identifier les priorités et prendre des décisions
lorsque des risques au niveau du budget, du temps et des ressources humaines ou des points en
suspens sont signalés. Il approuve également toutes les demandes de changement qui ont un
impact sur la portée du projet et donne son approbation pour la clôture du projet.
– 6.2 Comité de projet (CP) : Le rôle du comité de projet est de coordonner les efforts des
participants durant toutes les étapes du projet (Démarrage, planification, exécution, surveillance

et maitrise, analyse, développement, essai, pilote, déploiement et clôture). Le comité de projet
escaladera toutes les demandes de changement et les points en suspens qui affectent la portée du
projet, le budget, les délais, les ressources au comité de direction de projet (CDP).
– 6.3 Analyse et développement : Cette section identifie toutes personnes impliquées dans le projet
comme analyste d’affaire, analyste, analyste-programmeur, ou programmeur dont le rôle est de
développer les livrables du projet.
– 6.4 Procédures : Cette section identifie toutes personnes responsables dans la définition et
l’écriture des procédures requise par le projet.
– 6.5 Formation : Cette section identifie toutes personnes responsables de la définition et
l’exécution de la formation requise dans le projet.
– 6.6 Tests : Cette section identifie toutes personnes responsables des tests (unitaire, système,
intégré, etc.).
– 6.7 Pilote et déploiement : Cette section identifie le(s) pilote(s) associés au projet et toutes
personnes responsables du déploiement.
– 7.0 Mécanisme de gestion de projet :
– 7.1 Gestion de l’intégration : Cette activité consiste à coordonner adéquatement les divers
éléments du projet. Elle comporte la mise en œuvre du plan de projet et le contrôle intégré des
changements. Les décisions suite à une demande de changement devraient être prises à l’intérieur
de 5 jours suivant la date de la demande. La même durée doit être allouée pour la prise de décision
d’un point en suspens.
– 7.2 Gestion du contenu : Cette activité consiste à s’assurer que toutes les activités nécessaires
au succès du projet, et seulement celles-ci, font partie du projet. Elle comporte le démarrage, la
planification du contenu, la définition, la vérification du contenu, et le contrôle des modifications
du contenu.
– 7.3 Gestion des délais : Cette activité comprend les processus nécessaires pour s’assurer que le
projet contient tout le travail requis, et uniquement celui-ci, pour assurer la bonne fin du projet.
Elle comporte l’identification et le séquencement des activités, l’estimation de la durée des activités,
l’élaboration et le contrôle de l’échéancier.
– 7.4 Gestion des couts : Cette activité consiste à effectuer le suivi des couts nécessaires à la
réalisation du projet pour s’assurer que le projet soit réalisé en respectant le budget approuvé.
Elle est constituée de la planification des ressources, l’estimation des couts, la budgétisation et le
contrôle des couts.
– 7.5 Gestion de la qualité : Cette activité consiste à s’assurer que le projet réponde aux besoins
pour lesquels il a été entrepris. Elle comporte la planification, l’assurance et le contrôle de la qualité
(revues, audits, ..).
– 7.6 Gestion des ressources humaines : Cette activité consiste à s’assurer de l’utilisation la plus
efficace possible des ressources dans le projet. Elle comporte la planification de l’organisation,
l’obtention des ressources humaines et le développement de l’équipe.
– 7.7 Gestion des communications : Cette activité consiste à effectuer, la collecte, la diffusion,
l’archivage et, par la suite, le traitement final des informations concernant le projet, de façon
adéquate et en temps voulu. Elle est constituée de la planification de la communication, la
diffusion de l’information (gestion du changement), les rapports d’avancement et la clôture
administrative.
– 7.8 Gestion des risques : Cette activité consiste à identifier, à analyser et à répondre aux risques
du projet. Elle implique qu’on augmente la probabilité et l’impact des évènements positifs et de
diminuer la probabilité et l’impact des évènements défavorables au projet. Elle comporte la
planification de la gestion des risques, l’identification, l’analyse qualitative et l’analyse quantitative
des risques, la planification des stratégies de réponse, et le suivi et le contrôle des risques.
– 7.9 Gestion des approvisionnements : Cette activité consiste à assurer l’obtention des produits
et des services qui permettent de réaliser le contenu du projet, de l’extérieur de l’entreprise. Elle

comporte la planification des approvisionnements, la préparation des appels d’offres, les appels
d’offres, le choix des fournisseurs, la gestion administrative des contrats et la clôture des contrats.
– 8.0 Réalisation : Cette section indique les articles, produits ou résultats mesurables, tangibles et
vérifiables devant être produits pour mener à bien le projet.
– 8.1 Cycle de vie : Cette section indique le cycle de vie qui sera utilisé durant le projet.
– 9.0 Historique des révisions
Bien sûr cette table des matières peut être personnalisée. La personnalisation consiste à ajouter,
supprimer et modifier des éléments du modèle pour votre plan de projet. Si vous planifiez un projet
pour un client interne dans un environnement de développement familier et bien défini en utilisant
une petite équipe de développeurs de logiciels expérimentés et un ensemble standard de processus
de support, votre adaptation pourrait supprimer des items. Personnaliser ne signifie pas que les
éléments supprimés sont sans importance, mais qu’ils se dérouleront de la manière habituelle et
habituelle (par exemple, gestion de la configuration, vérification et validation) et qu’ils ne doivent
pas être documentés dans le plan de projet ils ne sont pas applicables à ce projet (par exemple, il
n’y a pas de plan de sous-traitance, car il n’y a pas de sous-traitants). Les cas où les éléments ne
seraient pas supprimés sont, par exemple, les cas où le processus à utiliser (par exemple, pour la
gestion de contenu (configuration) ou l’AQL) diffère du processus organisationnel standard.
Les petits projets ont de petits plans, car le nombre d’activités à planifier et à coordonner est plus
faible et ces projets se déroulent souvent dans des environnements stables et bien définis. Les
grands projets, par contre, ont des plans de projets plus étoffés. Si vous êtes le responsable d’un
grand projet, l’activité de planification peut nécessiter la coordination des efforts d’une équipe et
l’intégration de leur travail dans un plan de gestion de projet complet. Les membres de l’équipe
peuvent comprendre des spécialistes des domaines mentionnés ci-dessus (ingénierie des exigences,
adaptation du processus de développement standard de l’organisation, estimation des couts et du
calendrier, gestion des risques, gestion de la configuration, adaptation et préparation des plans de
projet, etc.) et même des disciplines spécialisées telles que ressources humaines, sécurité, sureté
et fiabilité.
Le plan de projet initial doit être suffisamment complet pour inclure toutes les activités prévues
dans le cadre de votre projet. Le niveau de détail de votre plan initial doit répondre aux critères
suivants:
– la portée du plan comprend toutes les tâches principales à accomplir;
– les possibilités de réutilisation des composants existants sont identifiées;
– les efforts, le calendrier et les ressources pour chaque activité identifiée ont été estimés avec
confiance;
– les activités prédécentes et successives de chaque activité sont spécifiées et le calendrier est
déterminé; et
– les complexités prévues et les facteurs de risque sont identifiés.
Ainsi les différentes activités du projet peuvent être décomposées à différents niveaux. Les activités
à effectuer seront précisées dans les cartographies de processus de cycle de vie de l’entreprise. Des
travaux inconnus, des facteurs de risque fondés sur des incertitudes et l’utilisation de nouvelles
technologies peuvent indiquer la nécessité d’incorporer des activités additionnelles d’études ou de
prototypage additionnels. Pendant l’exécution du projet, ce plan sera mis à jour à chaque grande
étape (de l’anglais Gate). Il est possible que le plan doive être réévalué avant la fin d’une grande
étape, par exemple, lorsque des facteurs externes tels que des modifications des exigences du client,
des difficultés avec les sous-traitants ou des retards dans la livraison des composants matériels
dictent la nécessité d’une nouvelle planification.

2.4 LES TECHNIQUES DE PLANIFICATION DU PROJET
La portée de votre projet peut comprendre l’élaboration des exigences, la négociation du calendrier
et du budget, l’acquisition d’équipement et de ressources humaines, le développement logiciel, son
installation, la formation des utilisateurs et le support/maintenance après implémentation.
D’autres projets logiciels sont plutôt de grands projets de maintenance d’un logiciel existant. Ainsi
vous allez recevoir un ensemble de modifications à effectuer, ainsi qu’un calendrier et un budget,
et vous aurez la responsabilité de gérer un projet de maintenance. Quoi qu’il en soit, ce chapitre (et
l’ensemble de ce livre) considère l’ensemble des activités pouvant être nécessaires à la gestion de
grands projets logiciels qui sont volumineux et complexes. Comme souligné tout au long de ce texte,
les activités de gestion de projet doivent être adaptées et adaptées aux besoins de chaque projet.
La première étape d’un projet est sa planification. La planification en versions reconnait qu’il est
impossible d’élaborer des plans complets, dès le départ, à un grand niveau de détail au cours de la
phase de planification initiale du projet. Ainsi un plan de haut niveau comportant des plans
détaillés pour le mois à venir, pour le mois suivant et pour trois mois est assez courant. Chaque
mois, les plans avancent d’un mois, c’est-à-dire en versions. Bien sûr, les plans pour le mois
prochain devraient être détaillés et plus précis que le plan d’ensemble. Les plans pour deux et trois
mois doivent donc être aussi précis que possible. Faire avancer le plan progressivement, en
versions, aide à avancer sans à avoir à tout planifier en détail dès le début.
LA STRUCTURE DE DÉCOUPAGE DU PROJET (WBS)

Afin d’en arriver à un plan détaillé, il est nécessaire de bien connaitre les activités qui vont devoir
être exécutées. Nous verrons, dans le chapitre 12, que les entreprises qui possèdent des
cartographies de processus des activités de développement logiciel ont déjà pris le temps de décrire
en détail les activités à faire lors des étapes du projet (voir un exemple d’étape d’analyse à la figure
8.14). Nous avons vu à la section précédente que la gestion d’un projet est facilitée si ce dernier est
divisé en plusieurs parties.
La technique du WBS - Work Breakdown Structure permet de mettre en oeuvre ce principe en

proposant une méthode opérationnelle pour décrire les activités d’un projet en le subdivisant en
unités gérables. Si vous n’avez pas la liste des activités publiées déjà, le PMI (Project Management
Institute, éditeur du guide PMBOK), s’inspirant des pratiques de la NASA, recommande de
décomposer le projet en sous-ensembles ordonnés à l’aide de cette technique. Cette approche est
aussi nommée le jalonnement de projet qui permet de bien structurer le projet, en le séparant en
nombreuses parties.
Nous verrons, avec l’exemple des tests, qu’un jalon est associé avec l’activité qui va permettre de faire
le point sur l’avancement des tests, c’est-à-dire quand le client approuve les résultats de tests. Ce
jalon permet un temps d’arrêt au projet et le contraint à s’engager dans les activités qui suivent que
si tout va bien. Cette notion d’arrêt est appelée une barrière (de l’anglais Gate) pour que les
gestionnaires puissent avoir le temps de donner l’approbation de continuer si tout va bien. Le
jalonnement se préoccupe moins du contenu de chaque étape, que de l’appréciation de la qualité et
complétude de son résultat, ou le client, et les dirigeants TI sont amenés à se prononcer. Ce
découpage aboutit sur des sous-projets (ou tâches, missions, phases, composants, lots de travail...),
organisés sous forme d’arborescence et représentant des livrables ou des tâches à effectuer.
Dans la littérature, plusieurs visions s’affrontent sur ce que devrait contenir un WBS. Pour certains
un WBS ne devrait contenir que des livrables. Pour d’autres on y ajoute les ressources qui font le
travail et même l’effort associé. Peu importe votre approche, le principal avantage du WBS est de
simplifier la planification du projet en le réduisant en parties plus facilement appréhendables par
l’équipe et autres parties. Il facilite l’organisation en permettant de progressivement attribuer un

budget, des rôles et des responsabilités pour chaque activité ou branche. Les bénéfices de la
décomposition hiérarchique sont :
– meilleure planification: la décomposition facilite l’estimation des durées à accorder à chaque
opération. Elle donne en outre une vision globale du travail à faire grâce à une représentation
visuelle;
– maitrise du suivi : la décomposition des livrables facilite le management global du projet : affecter
des jalons, revoir l’articulation des travaux, etc.;
– meilleure communication: elle simplifie les échanges entre les parties prenantes du projet et fait
gagner du temps à tous en offrant une vision exhaustive des différentes phases;
– meilleure gestion des couts: l’allocation des moyens et leur suivi sont plus précis. L’élaboration
d’un budget prévisionnel est facilitée;
– gestion des risques: identification des zones critiques et mise en place de scénarios préventifs.
Alors, comment mettre en oeuvre un WBS. Dans cette approche, nous partons du principal livrable
puis de nous le décomposons en livrables intermédiaires, avant de les décliner en lots de travail. Il
est également possible de débuter la correspondance hiérarchique par les activités majeures à
réaliser et les décomposer en tâches. D’autres critères de décomposition sont possibles : par métier,
par fonction, par procédé, par finalité... Un point important est que le niveau supérieur doit
représenter 100% de la décomposition inférieure. Il s’agit de la "règle du 100%". Sans cela il ne
saurait pas possible de consolider l’ensemble des durées de réalisation et des ressources
budgétaires pour obtenir la vision complète du projet.
Projet Bancaire –
Commerce
Électronique
1.0 Démarrage 2.0 Planifier le 4.0 Suivi et 5.0 Accepter 6.0 Leçons
du Projet Projet 3.0 Exécuter
Contrôle et Finaliser Apprises
3.5
3.1 Analyse 3.2 Conception 3.3 Dév 3.4 Tests
Implantation
Figure 2.2 – Exemple de WBS de haut niveau
Premièrement, identifiez les activités majeures. Posez-vous des questions telles que: quels sont les
grandes activités pour mener à bien mon projet? Par exemple, le WBS haut niveau de la figure 2.2,
le projet bancaire est principalement constitué des activités du PMI et une fois que vous avez choisi
votre modèle de cycle de vie de développement logiciel vous allez devoir effectuer les étapes
d’analyse, de conception, de développement, de test et d’implantation. À haut niveau un WBS n’est
pas utile pour vous aider à estimer le projet. Il va donc falloir décomposer ces activités et livrables
en composants (c.-à-d. sous-livrables). Prenons par exemple les tests. Interrogez-vous sur les
compositions de ce livrable. Ils peuvent être subdivisés en :
3.4 Tests
3.4.1 Plan de Test
3.4.2 Rapport de résultats des tests
3.4.2.1 Réviser le plan de test avec le client

3.4.2.2 Effectuer les tests (selon les scénarios de plan de tests)
3.4.2.3 Analyser les résultats de tests
3.4.2.4 Préparer le rapport de résultats de tests et la présentation
3.4.2.5 Présenter les résultats au client
3.4.2.6 Traiter les problèmes/Défauts et retester
3.4.2.7 Jalon: Le client approuve les résultats de tests
3.4.3 Jalon: Le client approuve les résultats de tests
3.5 Implantation
4.0 Contrôler
5.0 Accepter et finaliser
6.0 Leçons apprises
Chaque grande activité donne lieu à une liste de sous-livrables. Cette décomposition doit permettre
de créer des niveaux pour lesquels il est possible d’affecter: une responsabilité, une estimation de
temps et des ressources. Le WBS final doit être orienté vers les produits livrables. N’oubliez pas
qu’un projet doit avoir pour objectif de produire quelque chose, et pas seulement d’exécuter des
activités. Bien que le WBS ne prévoie aucune boucle explicite, certaines activités peuvent devoir
être répétées jusqu’à ce qu’un jalon soit atteint. Par exemple, les tests logiciels peuvent révéler un
certain nombre de problèmes ou de défauts rendant le logiciel inacceptable pour le client. En
conséquence, ces problèmes devront être résolus et les mêmes tests pourraient devoir être effectués
à nouveau (voir l’activité 3.4.2.6). Ce processus peut être répété plusieurs fois (tout en consommant
des jours calendrier et du budget de projet) jusqu’à ce que les objectifs qualité établis soient
respectés.
La satisfaction de ces conditions valide chaque niveau du WBS. Sans cela, il n’est pas pertinent
d’aller au-delà du niveau actuel. Il est donc important de trouver un équilibre entre un niveau trop
haut de détail, ne permettant pas d’obtenir tous les bénéfices de la méthode et un niveau de détail
trop bas, ingérables, complexifiant inutilement le projet. Il est également conseillé de subdiviser un
niveau si sa durée totale représente une part majeure de la durée du projet (essayer d’équilibrer
l’effort prévu par branche).
ÉTABLIR LES RESPONSABILITÉS POUR LES ACTIVITÉS DU WBS

À la suite de la création du WBS, il est important d’établir les rôles et les responsabilités de projet
qui doivent être attribués aux participants. Concernant les participants, aussi nommées parties
prenantes d’un projet logiciel, une partie prenante (ou stakeholder en anglais) est une personne,
un groupe de personnes ou une organisation qui impacte ou peut être impactée par le projet. Elle
peut être externe ou interne à l’entreprise responsable du projet. Une partie prenante a des attentes
et/ou des interactions sur le projet. Elle peut affecter ou être affectée directement ou indirectement,
de façon positive ou négative, par un ou plusieurs aspects du projet. Elle a donc des intérêts dans
le projet et a une influence sur la prise de décision. Ne pas prendre en considération, écouter ou
simplement respecter les parties prenantes peut compromettre les chances de réussite du projet.
Le PMI représente les parties prenantes à la figure 2.3.

Figure 2.3 – Relations entre les parties prenantes et le projet (PMI fig. 2-6)
Chaque acteur a ses objectifs, une certaine autorité et un intérêt pour le projet. Il est important de
bien situer chaque intervenant, les accompagner dans des discussions pour bien cibler leur
implication future ce qui peut être fait lors de la planification du projet et la rédaction du cahier
des charges. En pratique, les participants peuvent varier dans le temps. Le PMI recommande
toutefois que le niveau stratégique soit utilisé par rapport au niveau opérationnel, où cette variation
se produit plus fréquemment. Ainsi, il est également recommandé, dans l’attribution par l’autre
auteur des rôles de responsabilités, aux participants impliqués dans la réussite du projet. En outre,
ses fonctions et les responsabilités du chef de projet sont généralement plus critiques; cependant,
ils peuvent varier en fonction du domaine d’application du projet. La matrice d’attribution de
responsabilité (RACI) a été créée par l’entreprise General Electric à la suite d’une observation qu’il
y avait beaucoup de confusion quant aux rôles et responsabilités dans les projets et pour la prise
de décision. Elle sert à garantir que chaque composant de gestion de projet est attribué à un
personnel responsable. La figure 2.4 suivante montre une RACI générique. On peut y voir les
activités du PMI sur l’axe des X et les intervenants de l’entreprise sur l’axe des Y.
Figure 2.4 – Exemple de matrice RACI pour le projet
L’objectif est de remplir la matrice à l’intersection avec le rôle que va jouer l’intervenant de
l’entreprise :
– Confirmer les activités du projet;
– Définir et allouer les responsabilités;
– Améliorer la communication;
– Éliminer la duplication d’effort;

– Faire le travail correctement et à temps;
– Éliminer le blâme et le stress.
On veut savoir qui va faire quoi plus précisément. Vous pouvez le faire en équipe c’est mieux, car
les gens vont bien comprendre leur rôle. De plus cela aide à clarifier les activités sur l’axe des X
quand on veut l’assigner à une personne dans le projet. Les rôles qui peuvent être attribués sont :
R : Responsable : est la personne qui fait le travail. Il relève de la personne imputable pour faire
autoriser son résultat, A : Accountable (c.-à-d. imputable) est la personne qui a le cou sur la buche
si le travail n’est pas fait correctement. Cette personne possède un véto et une seule personne de
type A peut être assignée à une activité, C : Consulté est le rôle donné aux personnes qui doivent
être consultées avant que la décision finale soit prise. Cette personne peut être à l’extérieur du
projet. Et finalement, I : Informé, ce sont les personnes qui sont informées après qu’une décision
soit prise (communication à un sens).
Voici comment vous remplissez cette matrice. Étape 1 : Identifiez les activités clés du projet. Étape
2 : Déterminez les rôles qui vont être impliqués dans la création et l’approbation de produits clés.
Étape 3 : pour chaque activité, identifiez un seul A et les R, C, et I nécessaires. Placez les A et R au
niveau hiérarchique le plus bas possible. Étape 4 : Assurez-vous d’obtenir le consensus de cette
matrice avec les personnes concernées dans votre projet. Étape 5 : faites le suivi de son application
dans le projet et observez la facilité de gestion avec cette technique. La figure 2.5 suivante montre
un exemple de matrice RACI pour l’activité de test.
Figure 2.5 – Exemple d’une matrice RACI pour les activités de test
REPRÉSENTER L’ORGANIGRAMME FONCTIONNEL DU PROEJET
Maintenant que les responsabilités sont assignées, il est maintenant possible de représenter la
structure organisationnelle du projet. En vue de réaliser le projet, diverses structures sont créées.
Pour chacune d’elles sont fixés la mission, la composition et les rôles prépondérants. À la suite de
l’approbation du plan de projet, la mise en place de ces structures est achevée durant la phase de
lancement du projet (c.-à-d. le démarrage de projet - PMI). Typiquement un projet logiciel est géré
par deux entités : le comité de pilotage et le comité de projet. Le rôle du comité de direction/pilotage
de projet est principalement d’approuver les objectifs d’affaires, d’identifier les priorités et prendre
des décisions lorsque des risques au niveau du budget, du temps et des ressources humaines ou
des points en suspens sont signalés. Il approuve également toutes les demandes de changement

qui ont un impact sur la portée du projet et donne son approbation pour la clôture du projet. La
mission et les responsabilités du comité de pilotage portent ainsi sur les éléments suivants :
– la validation des orientations du projet;
– la responsabilité de l’engagement et du suivi financiers;
– la vérification globale de la qualité du projet, la validation des résultats et la réception du projet;
– la liaison entre les organismes;
– la réalisation, au besoin, des arbitrages nécessaires en cours de projet.
Il est avisé de préciser les informations suivantes, dans le plan de projet, pour les membres de ces
deux comités :
Rôle dans le Courrier

Nom Fonction Effort prévu
projet électronique
[email protected]
Jean Lemay Chef Qualité Client Principal 5 h/sem
m
Analyste
Patrice Dion Support technique Sur demande [email protected]
sysadmin
Figure 2.6 – Tableau des participants au projet
Le rôle du comité de projet est de coordonner les efforts des participants durant toutes les étapes
du projet (Démarrage, planification, exécution, surveillance et maitrise, analyse, développement,
essai, pilote, déploiement et clôture). Le comité de projet escaladera toutes les demandes de
changement et les points en suspens qui affectent la portée du projet, le budget, les délais, les
ressources au comité de direction de projet (CDP). Ainsi la mission et les responsabilités du comité
de projet portent sur les éléments suivants :
– le suivi du bon déroulement des travaux, du respect des livraisons et de leur validation;
– la vérification de l’utilisation des ressources allouées;
– le suivi des éléments réalisés en fonction de la planification et l’analyse des écarts;
– la présentation des problèmes (techniques, organisationnels ou de planification), variations dans
l’échéancier et la résolution des problèmes ponctuels;
– la coordination de l’équipe du projet pour des actions interdépendantes;
– la planification détaillée de la prochaine étape (détermination des tâches, définition précise,
ordonnancement);
– le recensement des informations nécessitant une décision concernant le pilotage du projet.
Il est aussi indiqué qu’un comité utilisateur soit mis en place dans le cas de grands projets. La
mission et les responsabilités du comité utilisateur portent sur les éléments suivants :
– la formulation des besoins des utilisateurs;

– la désignation d’un coordonnateur du groupe utilisateur;
– la préparation et l’arbitrage des choix;
– la validation des livrables;
– l’organisation de la mise en œuvre : processus, migration, déploiement;
– la participation aux démonstrations organisées par l’équipe du projet;

– la préparation et la mise en œuvre de nouvelles procédures fonctionnelles et organisationnelles
(gestion du changement);
– la formalisation et l’annonce des résultats de tests d’acceptation;
– la décision sur les points à soumettre au comité de pilotage.
Project Management VP in charge of

Committee change
IT consulting
Project Main project

committee leader
Technology /
Security
Co-pilot Pilot IT responsible
IT experts
Participant Participant Participant Operations
(Revy) (Réno-Dépôt) (Rona)
Quality Asurance
Solution architect Analyst Analyst Analyst

P.M.O.
Key user Programmer Programmer Programmer

analyst analyst analyst
People & Culture
Figure 2.7 – Exemple d’une structure organisationnelle de projet
Finalement, il est possible que des fournisseurs externes fassent partie de votre projet. Nous
verrons cet aspect en détail au chapitre 7. Les prestataires de services sont des entreprises privées
qui sont mandatées pour contribuer au processus de gestion de projet ou pour réaliser certaines
activités du projet. Les clients et les prestataires de services s’engagent dans une entente
contractuelle qui définit les obligations réciproques et qui fixe les niveaux de risque de chaque
partie. Les responsabilités de ces prestataires de services sont :
– réaliser les travaux comme prévu dans le contrat;

– réaliser les travaux avec le personnel désigné au contrat;
– assurer, de façon régulière, un suivi du contrat avec le client;
– assumer une part des risques associés à l’exécution du contrat;
– faire approuver, par le client, toute demande de changement avant son exécution.

Figure 2.8 – Exemple de structure organisationnelle - projet étudiants au CHU Sainte-Justine
L’ESTIMATION D’UN PROJET LOGICIEL

Maintenant que les responsabilités sont assignées et aussi que les personnes ont eu l’opportunité
de valider les activités du WBS, il est maintenant temps d’effectuer une estimation pour chaque
activité. Nous savons que faire une estimation sans trop connaitre les détails entraine des écarts
assez importants. Il est même suggéré d’effectuer deux estimations à partir de techniques
différentes, par exemple à l’aide du WBS et à l’aide de la technique des points de fonction pour
valider l’estimé. Nous voyons dans les nouvelles fréquemment que même si des consultants
professionnels sont impliqués il y a d’importants risques de dépassements des projets logiciels.
Rappelons-nous du projet de registre des armes à feu du gouvernement du Canada qui a dépassé
sa planification de 50,000%, il a été 500 fois plus couteux qu’initialement prévu. On peut donc
constater qu’effectuer des estimations sans avoir assez de détail sur le travail à faire est une activité
risquée. Pour faire un jeu, essayez de répondre aux questions suivantes sans utiliser l’internet (les
solutions sont à la section 2.8 à la fin de ce chapitre):
– quelle est la température à la surface du soleil?
– quelle est la surface de l’Asie?
– quelle est l’année de naissance de Alexandre Le Grand?
– quelle est la valeur totale des dollars américains en circulation?
– quel est le volume total des Grands Lacs?
Vous avez surement eu de la difficulté à trouver ces réponses. Cet exercice vise à vous conscientiser
que c’est difficile de trouver des réponses à une question quand nous n’avons pas de repères. Et
c’est souvent ce qu’on fait en estimant, sans repères, un projet logiciel. Les causes principales de
la difficulté à bien estimer sont :
– il n’y a pas d’enseignement précis sur les techniques d’estimation dans le domaine du logiciel;
– les ingénieurs logiciels n’ont pas les détails requis pour appuyer leur estimation;
– « Scope Creep » les exigences changent (augmentent) tout au long du projet;
– Il y a des surprises : techniques, qualité, tests difficiles à estimer à l’avance.

Il a été prouvé que si vous n’avez pas de données historiques concernant vos projets logiciels vos
estimations seront beaucoup plus erronées (+ 20% à +145% d’erreur présentée par Boeing).
Conséquemment vous êtes dans la situation représentée par la figure 2.9 :
+200%
Avant-projet Exigences Conception Codage Tests MEP
-200%
Figure 2.9 – L’incertitude des exigences et des estimés initaux d’un projet logiciel
Comme proposé par le PMI, la gestion du temps de projet comprend:
– Définition de l’activité - identifiant les activités devant être terminées afin de produire les livrables
de la portée du projet;
– Séquencement des activités: déterminez si les activités peuvent être complétées de manière
séquentielle ou parallèle, ainsi que les dépendances pouvant exister entre elles;
– Estimation de la durée de l’activité: estimation du temps nécessaire pour terminer chaque activité;
– Élaboration du calendrier: en fonction de la disponibilité des ressources, des activités, de leur
ordre chronologique et de l’estimation de leur durée, un calendrier peut être élaboré pour
l’ensemble du budget;
– Contrôle du calendrier: veille à ce que les processus et procédures appropriées soient en place afin
de contrôler les modifications apportées au calendrier du projet.
Donc, la pratique courante est d’assigner un effort, en jours, à chaque activité du WBS au meilleur
de votre connaissance. Le domaine de connaissances en gestion de projet (PMBOK), publié par le
PMI, appelé gestion du temps de projet se concentre sur les processus nécessaires pour élaborer le
calendrier du projet et pour garantir que le projet est terminé à temps. Il y a plusieurs approches
classiques d’estimation de projet dont :
La Technique Delphi : Qui implique plusieurs experts qui parviennent à un consensus sur un
sujet ou une question en particulier. Bien que la technique de Delphi soit généralement utilisée
pour la prise de décision en groupe, elle peut être un outil utile pour estimer quand le temps et
l’argent justifient l’effort supplémentaire. Pour estimer la technique Delphi, plusieurs experts
doivent être recrutés pour estimer le même élément. Sur la base des informations fournies, chaque
expert établit un bilan et compare ensuite tous les résultats. Si les estimations sont
raisonnablement proches, elles peuvent être moyennées et utilisées comme estimation. Sinon, les
estimations sont redistribuées aux experts qui discutent des différences puis font une autre
estimation. En général, ces tours sont anonymes et plusieurs tours peuvent avoir lieu jusqu’à ce
qu’un consensus soit atteint. Sans surprise, l’utilisation de la technique Delphi peut prendre plus

de temps et couter plus cher que la plupart des méthodes d’estimation, mais elle peut être très
efficace et fournir une assurance raisonnable lorsque les enjeux sont élevés et que la marge d’erreur
est faible.
La boite temporelle (Time Boxing) : Est une technique par laquelle une estimation de temps fixe
est allouée pour une activité ou une tâche spécifique. Cette allocation est davantage basée sur une
exigence que sur de simples suppositions. Par exemple, une équipe de projet peut disposer de deux
(et seulement deux) semaines pour construire un prototype. À la fin des deux semaines, les travaux
sur le prototype s’arrêtent, que le prototype soit terminé à 100% ou non. Utilisée efficacement, la
boxe temporelle peut aider à concentrer les efforts de l’équipe de projet sur une tâche importante
et critique. La pression du calendrier pour respecter un délai particulier peut toutefois entrainer de
longues heures de travail et une pression pour réussir. Utilisés de manière inappropriée ou trop
souvent, les membres de l’équipe de projet sont épuisés et frustrés.
L’estimation descendante (Top Down) : Cette approche consiste à estimer le calendrier e/ ou le

cout de l’ensemble du projet en termes de durée ou de cout. L’estimation descendante est un
phénomène très courant qui résulte souvent d’un mandat confié par la direction (par exemple, vous
devez terminer le projet en six mois et ne pas dépenser plus de 500 000 $!). Souvent, le calendrier
et/ou l’estimation des couts sont le produit d’un plan stratégique ùu parce que quelqu’un pense
que cela devrait prendre un certain temps ou couter un certain montant. D’un autre côté,
l’estimation top-down pourrait être une réaction à l’environnement des affaires. Par exemple, il se
peut que le projet doive être achevé dans un délai de six mois à la suite des actions d’un concurrent
ou pour gagner les affaires d’un client (c’est-à-dire que le client en a besoin dans six mois). Une fois
que les objectifs cibles en termes de calendrier ou de budget sont identifiés, il appartient au chef
de projet d’affecter des pourcentages aux différentes phases du cycle de vie du projet et aux tâches
ou activités associées. Les données de projets antérieurs peuvent être très utiles pour appliquer
des pourcentages et garantir que les estimations sont raisonnables. Il est important de garder à
l’esprit que l’estimation top-down fonctionne bien lorsque les objectifs cibles sont raisonnables,
réalistes et réalisables. Toutefois, lorsque ces objectifs sont définis par des personnes
indépendantes de l’équipe du projet, ils sont souvent trop optimistes ou trop agressifs.
L’estimation à l’aide de la taille fonctionnelle (Point de fonction): Cette approche consiste à

assigner un certain nombre de points aux fonctionnalités du logiciel à développer. Plus les
fonctionnalités détaillées à développer sont connues et bien définit plus la dimension ou la taille du
logiciel sera précise. L’idée principale derrière la mesure de taille fonctionnelle d’un logiciel COSMIC
www.cosmic-sizing.org est que le logiciel est constitué de dizaine, de centaine voire de millier de
processus. Tout processus comprend des « données » à l’entrée, des traitements et des résultats.
Par exemple, une alarme est le résultat d’un processus qui comprend une ou des données d’entrée
(par exemple la coupure d’un rayon laser) qui se déclenche une réaction (c.-à-dé des traitements).
Autre exemple, je peux demander un rapport sur un client. Pour ce faire je dois demander le rapport
(entrer des données sur le client), qui déclenche une recherche dans une base de données pour
obtenir des informations prédéfinies (c.-à-d. une lecture) et obtenir mon rapport (une sortie). Ces
processus peuvent être visibles ou non à un utilisateur/client, mais les spécialistes en génie logiciel
savent que ces actions devront être codées. COSMIC s’intéresse donc à détailler les exigences
fonctionnelles ou processus fonctionnels qui sont typiquement décrits dans des diagrammes UML.
Que mesure la méthode COSMIC ? Elle mesure les mouvements de données à l’intérieur d’un
processus fonctionnel. Il y a quatre types de mouvements de données pour COSMIC: 1) entrée; 2)
sortie; 3) lecture; et 4) écritures. Que faut-il savoir pour mesurer la taille fonctionnelle avec
COSMIC ?
– les exigences fonctionnelles des utilisateurs (souvent définies dans un document sur les
exigences). Elles peuvent aussi se présenter sous forme de stories (agile) ou de cas d’utilisation en
UML par exemple;

– la liste des processus fonctionnels qui sont tirés des informations sur les exigences fonctionnelles
des utilisateurs;
– la liste de entités de données qui sont utilisées par le logiciel ainsi que les données. Ces entités se
trouvent dans un modèle de données ou son équivalent.
Comment peut se faire la mesure COSMIC pour un projet ? Prenons l’exemple d’un logiciel comme
Kijiji, qui permet la gestion des annonces et la recherche d’une annonce d’achat/vente de biens
personnels, on peut rapidement déterminer un modèle de données de haut niveau ainsi que les cas
d’utilisation à développer (voir figure 2.10)
Figure 2.10 – Modèle de données et cas d’utilisation d’un logiciel similaire à Kijiji
Le modèle de données identifie les groupes de données: Annonce, Catégorie, Région et Utilisateur
(user). Les 7 cas d’utilisation identifient 17 processus fonctionnels (dans la colonne de droite du
tableau de la figure 2.10). La figure suivante décrit le calcul de la taille fonctionnelle totale de ce
projet à partir de ces informations.
Processus Fonctionnel Entrée Lecture Écriture Sortie Total

1-Créer un compte utilisateur 1 1 1 1 4
2-Modifier un compte utilisateur 1 1 1 1 4
3-Supprimer un compte utilisateur 1 1 1 1 4
4-Lire les comptes utilisateurs 1 1 2 4
5-Ajouter une catégorie d’annonce 1 1 1 1 4
6-Modifier une catégorie d’annonce 1 1 1 1 4
7-Supprimer une catégorie d’annonce 1 1 1 1 4
8-Lire les catégories d’annonce 1 1 2 4
9-Ajouter une région 1 1 1 1 4
10-Modifier une région 1 1 1 1 4
11-Supprimer une région 1 1 1 1 4
12-Lire les régions 1 1 2 4
13-Créer une annonce 1 1 1 1 4
14-Modifier une annonce 1 1 1 1 4
15-Supprimer une annonce 1 1 1 1 3
16-Lire une annonce 1 1 2 4
17-Rechercher plusieurs annonces par 3 3 4 10
différents critères
Total 19 19 12 24 74
Figure 2.11 – Exemple de l’estimé de la taille fonctionnelle du projet

Avec une taille fonctionnelle de 74PF il est possible d’estimer que ce projet prendra environ 592
heures (74PF X 8heures/PF). Comment a-t-on obtenu la valeur de 8 heures par point de fonction?
Normalement vous devriez obtenir cette valeur (heures/point de fonction) en fonction de vos
données et expérience dans votre entreprise. Si vous n’avez pas de données à l’interne, il y a un
référentiel d’analyse comparative (www.isbsg.org) qui contient des données pour près de 10,000
projets logiciels. Ce référentiel possède un large éventail de types de projets provenant de
nombreuses industries et de nombreux secteurs d’activité. Vous pouvez l’utiliser pour valider vos
estimés, comparer vos projets, comparer la productivité de différentes plateformes/cadriciels et de
langages de programmation. Par exemple, en 2019 cette base de données a ajouté environ 1,000
projets logiciels qui proviennent de plus de trente pays. Les données dans le référentiel de ISBSG
vous permettent de répondre à des questions telles que:
– quelle est la productivité de l’industrie pour les projets Java dans le secteur bancaire?
– mon organisation est meilleure ou pire que la moyenne de l'industrie en agile avec .Net?
– mon fournisseur cite un prix par point de fonction prix de 350$. Est-ce réaliste?
– mon fournisseur dit qu’il peut faire le projet agile en 6 mois avec 5 personnes. Quelle est la
probabilité qu’il peut le faire? Ce genre de productivité a-t-elle été réalisée auparavant dans ce
genre de projet?
– quelle serait la taille de l’équipe moyenne optimale pour un projet d’amélioration, en Oracle, qui
comporte 80 points de fonction?
– combien vais-je obtenir des fonctionnalités environ après 6 sprints de deux semaines dans un
projet agile avec 4 membres d’équipe?
Parfois il est sage d’utiliser plus d’une technique d’estimation pour améliorer la précision de
l’estimé. Nous pouvons effectuer un estimé, tel que décrit dans ce chapitre à partir du WBS du
projet et comparons-le avec l’estimé obtenu par la technique des points de fonction (qui a estimé
592 heures pour le projet). La figure 2.12 présente le WBS de ce même projet.
Projet de vente/achat d’items personnels
1.0 Démarrer le projet 2.0 Inception 3.0 Élaboration 4.0 Construction 5.0 Transition
Mettre en place -Identifier les -Définir -Implémenter, -tester et corriger

l'environnement besoins (14h) l’architecture intégrer et tester les problèmes (16h)
de travail (12h) -Déterminer système (27h) les CUs les plus -Faire les tests
les CUs (14h) -Détailler les risqués (58h) Bêta(28h)
-Définir les CUs (27h) -Faire la démo du
Cus (14h) -Vérifier que le CUs premier prototype(6h)
-Préparer la phase correspondent aux -Implémenter,
d’élaboration (14h) Besoin (20h) intégrer et tester
-Préparer la phase les CUs suivants (58h)
de construction (14h) -Faire la démo du
second prototype(6h)
-Implémenter,
intégrer et tester
les CUs restants (45h)
-Créer le manuel
d’utilisateur (13h)
-Préparer la phase
de transition (13h)
Figure 2.12 – WBS du projet de développement d’un logiciel similaire à Kijiji
L’équipe de projet estime 12 heures pour l’étape 1, 56 heures pour l’étape 2, de conception, 88
heures pour l’étape d’élaboration, 204 heures pour l’étape de construction et 44 heures pour l’étape

de transition. L’estimé est donc de 404 heures. Il y a donc un écart de 188 heures entre ces deux
estimés.
Conséquemment on peut voir que différentes approches vont donner des estimés différents.
L’ingénieur logiciel pourra ainsi, avec le temps et l’expérience identifier les facteurs qui font varier
ces estimés et tenter d’améliorer leur précision avec le temps.
Les story points : Les story points permettent aux équipes de s’accorder sur la taille relative des
user stories. Estimer le travail en jours/personne, va les forcer à se poser la question « Qui ferait la
tâche ? ». La story 1 représente 3 fois plus d’effort que la story 2, et ce, même si le temps réel de
réalisation varie en fonction des membres de l’équipe. En résumé, on choisit de faire une estimation
relative plutôt qu’absolue. Estimer l’effort de manière relative a une seconde vertu : prendre en
compte l’imprécision. Le calcul d'incertitude est imprécis par nature puisqu’il est impossible de
prévoir l’avenir. Pour un projet Agile c’est plus simple. La philosophie est : pourquoi perdre notre
temps et notre énergie à tenter d’estimer précisément le temps que prendra chaque tâche d’un
projet dès lors qu’on admet que le résultat de l’estimation de toute façon vraisemblablement faux ?
Les estimations relatives, plus grossières, sont nettement suffisantes étant donné la marge d’erreur.
Elles nous fournissent d’abord un ordre d’idée de la taille d’un projet et cette vision s’affinera
ensuite progressivement lors des phases de réalisation. Autrement dit, on apprend à partir de
données réelles et cela nous permet de préciser nos plans. À l’aide de la technique d’estimation de
« story points », on utilise d’ailleurs le plus souvent une estimée inspirée de la suite de Fibonacci :
1, 2, 3, 5, 8, 13, 20, 40, 100. Cette suite propose des valeurs de plus en plus éloignées les unes des
autres, donc des estimations de plus en plus imprécises lorsque la valeur augmente en durée
prévue. Cela permet de prendre en compte que plus une « user story » est imprécise ou complexe,
plus elle devient difficile à estimer. Notons pour terminer qu’il est possible au début d’un projet
d’utiliser des macros estimations, par exemple en s’inspirant des tailles de T-shirt (c.-à-d. XS, S,
M, L, XL) pour comparer des Epics ou des Features entre elles.
Estimer l’effort de manière relative a une seconde vertu : prendre en compte l’imprécision. Faire
des estimations n’est, par essence, pas précis puisqu’il est impossible de prévoir l’avenir.
Les êtres humains sont meilleurs pour réaliser des estimations relatives que des estimations
absolues. C’est plus simple. Par exemple, si je vous demande d’estimer la quantité d’eau dans le
verre ci-dessous, c’est difficile. En revanche, si je vous demande d’estimer cette quantité par rapport
à celle d’un autre verre pour déterminer si elle est équivalente, supérieure ou inférieure, cela devient
plus facile et naturel.
L’estimation ascendante (Bottom-up): La plupart des estimations dans le monde réel sont
effectuées à l’aide d’estimations ascendantes. L’estimation ascendante implique de diviser le projet
en modules plus petits, puis d’estimer directement le temps et les efforts en heures-personnes, en
semaines-personnes ou en mois-personnes pour chaque module. La structure de répartition du
travail constitue la base de l’estimation ascendante, car toutes les phases et activités du projet sont
définies. Le chef de projet, ou mieux encore l’équipe de projet, peut fournir une estimation du temps
raisonnable pour chaque activité. En bref, l’estimation ascendante commence par une liste de
toutes les tâches ou activités requises, puis une estimation de la quantité d’effort est effectuée. Le
temps total et le cout associé pour chaque activité constituent la base du calendrier et du budget
ciblé du projet. Bien que l’estimation ascendante soit simple, il peut être difficile de confondre les
efforts avec les progrès. En reprenant notre exemple précédent, supposons qu’après la réunion avec
nos testeurs de logiciels, les durées suivantes aient été estimées pour chacune des activités
suivantes:
3.4.2 Rapport de résultats des tests

3.4.2.1 Réviser le plan de test avec le client 1 jour
3.4.2.2 Effectuer les tests (selon les scénarios de plan de tests) 5 jours
3.4.2.3 Analyser les résultats de tests 2 jours
3.4.2.4 Préparer le rapport de résultats de tests et la présentation 3 jours
3.4.2.5 Présenter les résultats au client 1 jour
3.4.2.6 Traiter les problèmes/Défauts et retester 5 jours
Si nous additionnons toutes les durées estimées, nous constatons que la création du rapport de
résultats de test prendra dix-sept jours. Comment avons-nous élaboré ces estimations? Les avons-
nous estimées? Heureusement non! Ces estimations pourraient être basées sur l’expérience. Les
testeurs de logiciels ont peut-être déjà effectué ces activités à plusieurs reprises afin de savoir
quelles activités doivent être effectuées et combien de temps chaque activité prendra. Ces
estimations pourraient être basées sur des projets similaires ou analogues. Une estimation
analogue fait référence à l’élaboration d’estimations basées sur l’opinion selon laquelle il existe une
similitude significative entre le projet actuel et les anciens projets.
N’oubliez pas que les estimations sont fonction de l’activité elle-même, des ressources et du support
fourni. Plus spécifiquement, la durée estimée d’une activité dépendra d’abord de la nature de
l’activité, en termes de complexité et de degré de structure. En général, les activités très complexes
et non structurées prendront plus de temps que des activités simples et bien structurées. Les
ressources affectées à une activité particulière influenceront également une estimation. Par
exemple, l’affectation d’une personne expérimentée et bien formée à une tâche particulière devrait
signifier moins de temps pour la mener à bien que si un novice était affecté. Cependant, l’expérience
et l’expertise ne sont qu’une partie de l’équation. Nous devons également considérer des facteurs
tels que le niveau de motivation et d’enthousiasme d’une personne. Enfin, le soutien que nous
fournissons influence également nos estimations. L’assistance peut inclure la technologie, les
outils, la formation et l’environnement de travail physique.
Ce ne sont que quelques-unes des variables que nous devons prendre en compte lors de
l’estimation. Vous pouvez probablement en proposer plusieurs autres. Par la suite, les estimations
seront toujours des prévisions. Il serait alors sage d’en utiliser plus qu’une. Il est très probable qu'il
y ait une différence entre l'estimé provenant d’un modèle (par exemple à partir de la mesure en
points de fonction) et d’un modèle à partir des activités (par exemple avec le WBS). Il faut noter ici
qu’il s'agit d’estimer l’ensemble du projet et non seulement une itération de livraison de type agile.
Premières questions à se poser:
1- Est-ce que la différence vient de mon modèle d'estimation basé sur les points de fonction? Il est
possible que l'envergure des exigences (en point de fonction) ait été sous (ou sur) estimé;
2- Est-ce que la différence vient de mon modèle basé sur les activités. Est-ce que mon modèle
comprend toutes les activités ? Est-ce que j'ai sur (ou sous) estimé l'effort par activité?
Il y a une dernière hypothèse. Les deux modèles de mesure ne visent probablement pas les mêmes
aspects du projet. Par exemple, exclure dans le WBS, pour fins de comparaison, les efforts des
activités techniques (non fonctionnelles). Il faut alors enlever des efforts du WBS pour ces activités.
Par exemple, des activités qualitatives telles la sécurité, la fiabilité, la maintenabilité, etc. Il est
aussi possible que les activités ne visent qu’un certain nombre de fonctionnalités, les autres ayant
été complétées antérieurement. Il faut alors enlever du calcul des points de fonction ces
fonctionnalités.

Pour répondre à la première question: Quelle est la qualité de mon estimé? Est-ce que j’ai eu à
estimer la taille des processus/fonctionnalité? il est possible que je n’aie pas obtenu toutes les
informations pour estimer ces fonctionnalités? Par exemple le modèle de données est manquant,
incomplet ou peu fiable.
Est-ce que tous les processus fonctionnels ont été considérés? Ainsi il faut revoir toutes les
exigences et s’assurer que les processus sont alignés avec chacune des exigences.
Est-ce que l’effort par point de fonction a été sur (ou sous) estimé? On peut regarder dans la base
de données de ISBSG (www.isbsg.org) pour trouver des projets similaires et voir les tailles
fonctionnelles qui correspondent le mieux à notre type de projet.
Pour répondre à la deuxième question, il faut s’assurer que l’on a une bonne vision de l’ensemble
des activités. Un graphique montrant la hiérarchie des activités est souhaitable. On peut comparer
ce graphique à des projets similaires et voir ce qui manque ou ce qu’il y a en trop en termes
d’activités.
Il faut avoir une idée, lorsque l’on estime les activités, de l’envergure du projet. Chacune des
activités d’un projet de grande envergure demande plus d’effort qu’un projet de faible envergure. Il
est donc possible que les efforts par activité n’aient pas tenu compte de l’envergure du projet. On
peut se demander si le projet est de moins de 6 mois avec 2 ou 3 personnes, ou si c’est un projet
de plus d’un an (c.-à-d. plutôt rare aujourd’hui) avec une dizaine de personnes.
LISTER LES LIVRABLES (GESTION ET TECHNIQUE) ET LEURS RESPONSABLES
À partir du découpage des tâches, il est maintenant possible de préciser les livrables principaux,
qui comme les jalons pour les activités devront faire l’objet d’une attention particulière, c’est-à-dire
qu’ils feront l’objet d’une gestion plus serrée afin de s’assurer que le projet sera bien contrôlé et que
ces livrables seront de qualité:
Figure 2.12 – Tableau sommaire des livrables du projet
REPRÉSENTER L’ÉCHÉANCIER DU PROJET

À partir du découpage des tâches, il faut déterminer la durée de chaque activité. Il y a multiples
techniques qui permettent d’aider à concevoir différentes représentations d’échéancier de projet et
de l’occupation des ressources humaines:
– la technique du chemin critique;
– la représentation Gantt des tâches;
– la représentation Gantt des ressources?
Les lots de travaux du WBS sont établis, pour chaque tâche, les durées estimées des tâches. De
plus, nous pouvons préciser leurs tâches prédécesseurs et successeurs. Avec un ensemble de lots
de travaux, une liste de tâches détaillées peut être représentée:
# Description Prédécesseurs Durée # employés

2.1 Recevoir l’approbation
3.1 Analyser les exigences 2.1 1 2
3.2 Conception
3.2.1 Revoir les composants 3.1 6 4
3.2.2 Concevoir composants 3.1 3 1
3.2.3 Concevoir interfaces 3.2.2 1 2
3.3 Développement
3.3.1 Coder les composants 3.2.2 6 2
3.2.1 Ajuster code existant 3.2.1, 3.2.3 5 1
3.4 Intégration
3.4.1 Développer le plan 3.2.2 2 2
3.4.2 Terminer tests unitaires 3.3.1, 3.3.2 2 2
3.4.3 Maj documents 3.3.1, 3.3.2 2 3
3.5 Tests d’intégration
3.5.1 Développer les tests 3.4.1 1 3
3.5.1 Effectuer les tests 3.4.2, 3.4.3, 3.5.1 1 2
3.6 Effectuer tests d’acceptation 3.5.2 1 1
Il est maintenant possible de voir précisément les informations de prédécesseur et de successeur

contenues dans le WBS. Sinon, vous pouvez créer cette liste de tâches vous-même. Une liste de
tâches peut être décrite comme un réseau planifié tel que celui de la figure 2.13; la figure contient
les informations du tableau précédent, mais offre une représentation visuelle différente. Notez que
seules les tâches (éléments de niveau le plus bas) du tableau sont illustrées.
Un réseau de planification de votre projet bien formé est un graphe orienté acyclique. Les flèches
sont annotées avec les numéros des activités du WBS et les durées des tâches correspondants. Les
chiffres dans les bulles du graphique représentent des jalons du projet. L’évènement externe 2.1
doit survenir avant que le projet puisse commencer. Certains de vos projets peuvent avoir d’autres
évènements externes (c’est-à-dire des évènements qui ne sont pas sous votre contrôle) qui doivent
se produire à des jalons intermédiaires pour que le projet puisse continuer, par exemple, la
disponibilité d’une spécification d’interface ou la livraison du matériel nécessaire. Notez également
la tâche fictive de durée nulle reliant les jalons 7 et 8. L’insertion du jalon 7 et d’une tâche de durée
nulle permet de générer un rapport séparé sur l’achèvement des tâches pour les tâches 3.4.2 et
3.4.3. Comme ces tâches peuvent se retrouver sur le chemin critique (voir la section suivante), il
est important de savoir quand chaque tâche est terminée et, si le jalon 8 n’est pas atteint comme
prévu, quelle tâche a été retardée. Des jalons et des tâches fictives supplémentaires peuvent être
insérés dans un réseau de planification, à volonté, afin d’améliorer la granularité des rapports
d’avancement. Les chiffres dans les cercles sont des jalons de projet utilisés comme indicateurs de
progrès lors de l’exécution du projet. La réalisation d’un jalon est déterminée en vérifiant que toutes
les tâches le long du chemin menant à ce jalon ont été terminées avec succès. Une tâche est

accomplie avec succès en satisfaisant aux critères d’acceptation des produits produits par cette
tâche, tels que spécifiés dans le lot de tâches de la tâche.
LA TECHNIQUE DU CHEMIN CRITIQUE
La durée de chaque chemin à travers le réseau peut être déterminée en faisant la somme des durées
des tâches le long de ce chemin. Le chemin qui a la plus longue durée est le chemin critique. Le
chemin critique est critique en ce sens que tout retard dans l’exécution des tâches le long de ce
chemin retardera l’achèvement prévu du projet à moins d’être compensé par l’achèvement rapide
d’autres tâches sur ce chemin.
5
3.4.1 (2)
3.5.1 (1)
2.1 3
3.2.2 (3)
3.3.1 (6)
3.1 (1) 3.5.2 (1) 3.6 (1)
1 2 8 9 10
3.2.3 (1)
3.4.2 (2)
(0)
3.2.1 (6)
16 semaines
4 6 7
3.3.2 (5) 3.4.3 (2)
m.n (x) = numéro d’activité avec (durée)
n = Jalon
Figure 2.13 – Réseau des activités du projet
Le chemin critique de la figure 2.13 est 1-2-4-6-7-8-9-10. C’est la durée estimée du projet. Cette
approche pour déterminer un calendrier de projet s’appelle la méthode du chemin critique (CPM).
Tout dépassement d’horaire pour une tâche sur un chemin critique étendra la planification
complète à moins que d’autres tâches de ce chemin critique soient terminées en moins de temps
que prévu pour compenser les dépassements. Chaque chemin d’un réseau CPM qui n’est pas
critique a un temps mort non nul associé. Par exemple, la somme des durées des tâches le long du
chemin le plus haut dans la figure 2.13 (indiquée par les jalons 1, 2, 3, 5, 8) indique que le jalon 8
peut être atteint en 7 semaines. Toutefois, le projet ne peut pas continuer tant que les tâches 3.4.2
et 3.4.3 n’atteignent pas le jalon 8 à la 14e semaine. Le chemin le plus long comporte donc 7
semaines de temps libre entre les jalons 0 et 8. Le temps mort peut être utilisé pour ajuster la
planification des tâches non critiques. Par exemple, la tâche 3.4.1 peut être programmée pour les
semaines 8 et 9 si les ressources ne sont pas disponibles pour exécuter la tâche au cours des
semaines 5 et 6 (heure de début la plus ancienne pour la tâche 3.4.1).
LA REPRÉSENTATION GANTT DES TÂCHES
Il existe deux types de diagrammes de Gantt: les Gantts de tâches et les Gantts de ressources. Le
diagramme de Gantt de tâches (le plus couramment utilisé des deux) est un tracé des tâches par
rapport aux heures auxquelles elles doivent se dérouler. Un exemple de Gantt de tâche à la figure
2.14 est dérivé du réseau CPM de la figure 2.13.

Figure 2.14 – Gantt des tâches des activités du projet de la figure 2.9 projet
Notez que l’axe vertical décrit la structure du WBS. Notez également que seules les tâches (éléments
de plus bas niveau du WBS) sont illustrées; les calendriers des activités de niveau supérieur sont
indiqués par des flèches qui couvrent l’étendue des tâches subordonnées aux activités. Les tâches
hachurées sont celles des chemins critiques.
La figure 2.15 est une version augmentée de la figure 2.14; elle ne contient que les tâches. Les
nombres associés aux tâches dans cette figure représentent le nombre de personnes nécessaires
pour effectuer les tâches. Ils ont été obtenus à partir du tableau initial du début.
Les nombres près de l’axe des x, en bas, sont les sommes des personnes nécessaires pour effectuer
toutes les tâches dans les périodes indiquées. Ils sont obtenus en faisant la somme des nombres
de chaque colonne. C’est ainsi qu’on se rapproche de l’activité de la planification des ressources
pour le projet qui est notre prochaine tâche de planification à titre de chef du projet.
Figure 2.15 – Gantt des tâches augmenté

LA REPRÉSENTATION GANTT DES RESSOURCES
Le profil de la demande en personnel représenté à la figure 2.15 n’est pas réaliste pour la plupart
des projets et la plupart des organisations. Il n’est pas réaliste de s’attendre à ce que les personnes
puissent être programmées pour « démarrer » et pour « arrêter » abruptement de participer à un
projet sur une base hebdomadaire. L’alternative plus réaliste consiste à planifier pour les effectifs
maximums, au haut de la demande et les occuper ailleurs. Mais quel est l’impact de la
rémunération du personnel en cas de temps improductif? Ils peuvent travailler sur d’autres projets,
mais la planification des ressources pour plusieurs projets à ce niveau de granularité n’est pas
facile ni pratique.
Il faut donc plutôt développer des graphes d’implication des ressources individuellement.
Michel Lemay
Figure 2.16 – Gantt de ressource individuelle
2.5 MESURER ET CONTRÔLER LE PROJET
MESURER ET CONTRÔLER L’EFFORT, L’ÉCHÉANCIER ET LES COUTS

Nous avons vu que la gestion d’un projet logiciel implique la planification et l’estimation. Une des
raisons pour lesquelles vous devez établir des plans et des estimations pour votre projet est de
fournir des objectifs objectifs en fonction desquels l’avancement du travail et la qualité des produits
du travail peuvent être déterminés. Les sections suivantes doivent apparaitre dans le plan de
projet :
– Le processus de gestion de la portée : Cette activité consiste à s’assurer que toutes les activités
nécessaires au succès du projet, et seulement celles-ci font partie du projet. Elle comporte le
démarrage, la planification du contenu, la définition, la vérification du contenu, et le contrôle des
modifications du contenu;
– Le processus de gestion des délais : Cette activité comprend les processus nécessaires pour
s’assurer que le projet contient tout le travail requis, et uniquement celui-ci, pour assurer la bonne
fin du projet. Elle comporte l’identification et le séquencement des activités, l’estimation de la
taille/effort/durée des activités, l’élaboration et le contrôle de l’échéancier;
– Le processus de gestion des couts : Cette activité consiste à effectuer le suivi des couts nécessaires
à la réalisation du projet pour s’assurer que le projet soit réalisé en respectant le budget approuvé.

Elle est constituée de la planification des ressources, l’estimation des couts, la budgétisation et le
contrôle des couts;
– Le processus de gestion des ressources du projet : Cette activité consiste à s’assurer de l’utilisation
la plus efficace possible des ressources et de leur contrôle dans le projet. Elle comporte la
planification de l’organisation, l’obtention des bonnes personnes et le développement de l’équipe;
La progression est mesurée en déterminant périodiquement le statut actuel de chaque attribut et

en comparant son statut actuel au statut planifié. Le statut du projet est généralement mesuré et
communiqué hebdomadairement, toutes les deux semaines ou tous les mois. Le rapport
d’avancement a pour but d’indiquer quels sont les facteurs du projet qui ont été planifiés et ceux
qui doivent faire l’objet d’un suivi plus intensif en vue d’une éventuelle action corrective si
nécessaire. Vous devez, par exemple, surveiller à la fois les efforts et les couts de personnel. Si, au
cours d’une période de rapport donnée, les efforts sont conformes aux prévisions, mais que les
couts de personnel sont plus élevés que prévu, vous utilisez des développeurs de logiciels plus
couteux (plus qualifiés) que prévu; le travail est peut-être plus difficile que prévu ou peut-être le
travail de concepteurs hautement qualifiés et couteux prend-il plus de temps que prévu.
Inversement, si, au cours d’une période de rapport donnée, les efforts sont conformes aux
prévisions, mais que les couts de personnel sont inférieurs aux prévisions, il se peut que vous
n’ayez pas été en mesure d’acquérir le niveau de compétence requis ou que le travail soit plus facile
que prévu et hautement un personnel qualifié n’est pas nécessaire. Si les efforts et les couts sont
inférieurs aux prévisions, cela peut indiquer que vous n’avez pas été en mesure d’acquérir le nombre
prévu de développeurs de logiciels et, par conséquent, la progression de la planification est plus
lente que prévu. Ou bien, il se peut que les efforts et les couts soient plus élevés que prévu en
raison de la volonté d’accélérer la progression du calendrier. Les autres couts doivent également
être mesurés et comparés au plan. Les frais de déplacement peuvent être plus élevés (ou plus bas)
que prévu; les couts d’équipement peuvent également différer des prévisions. Dans tous les cas,
vous devrez étudier ces écarts par rapport au plan.
Le contrôle du projet s’exerce en appliquant une action corrective lorsqu’une ou plusieurs

dimensions de progression s’écartent du plan par rapport à un montant acceptable ou lorsque les
relations entre les attributs du projet ne sont plus équilibrées. Par exemple, un retard de deux jours
dans l’atteinte d’un jalon majeur peut ne pas nécessiter d’action corrective, mais un retard de deux
semaines peut constituer un retard inacceptable pour lequel des mesures correctives doivent être
prises. De même, un dépassement de 2% de la mémoire allouée pour une version incrémentielle de
logiciel embarqué peut être acceptable, mais un dépassement de 20% ne l’est probablement pas.
Selon la nature de l’écart par rapport au plan, les actions correctives peuvent impliquer un ou
plusieurs des :
– prolonger la durée du projet;

– ajouter plus de ressources;
– utilisant des ressources plus spécialisées;
– améliorer divers éléments du processus de développement;
– améliorer la technologie; et/ou
– réduire les fonctionnalités à livrer.
Les ressources à améliorer, ajouter ou remplacer comprennent les personnes (respectant la loi de
Brooks), les composants logiciels (par exemple, la refonte d’un composant pour améliorer les
performances), les composants matériels (par exemple, davantage de mémoire, un processeur plus
rapide) et outils logiciels (par exemple, un processeur de langage ou un outil de test).

La réduction des fonctionnalités promises peut être réalisée facilement si vous avez hiérarchisé les
exigences et si vous utilisez un processus de développement itératif par lequel vous avez d’abord
implémenté les fonctionnalités les plus importantes. Si la date de livraison est courte et fixe, vous
pouvez constater qu’il est acceptable de livrer un sous-ensemble des fonctions plus prioritaires
dans ces délais, avec la livraison d’une version complète suivante prévue pour une date négociée
ultérieure.
Bien sûr, vous devez être attentif aux compromis impliqués dans les actions correctives. Par
exemple, modifier le processus de test ou ajouter un nouvel outil de test peut augmenter le nombre
de défauts détectés sur le long terme, mais cela peut avoir un impact inacceptable sur l’effort qui
résulte du temps requis pour apprendre et assimiler le nouveau processus ou le nouvel outil de
test.
Lorsque vous planifiez, estimez, mesurez et contrôlez un projet logiciel, vous pratiquez une gestion
des risques institutionnalisée. La gestion des risques est institutionnalisée parce que, grâce à
l’expérience, nous avons appris que la planification, l’estimation, la mesure et le contrôle
systématiques d’un projet informatique augmentent la probabilité d’obtenir un résultat positif.
Autrement dit, il vaut mieux planifier, estimer, mesurer et contrôler que de ne pas le faire. La
mesure et le contrôle de l’effort, du calendrier, des couts, des caractéristiques du produit et des
attributs de qualité constituent donc une forme de gestion des risques. Cependant, comme expliqué
au chapitre de la gestion des risques présente d’autres aspects qui complètent la planification,
l’estimation, la mesure et le contrôle systématique que vous devez exercer sur vos projets de
logiciels.
Il est possible, bien que cela ne soit pas hautement probable, que vous puissiez être en mesure de
livrer un produit acceptable sans planification, estimation, mesure ou contrôle. Le cout de la
planification, de l’estimation, de la mesure et du contrôle, tout comme le cout de la gestion du
risque, est un investissement que vous effectuez pour augmenter les chances de succès.
MESURER ET CONTRÔLER LES LIVRABLES
Il y a plusieurs raisons pour lesquelles vous devez mesurer divers attributs de vos projets logiciels:
– fournir des indicateurs fréquents de progrès (ou d’absence de progrès);

– signaler rapidement les problèmes;
– permettre l’analyse des tendances de votre projet;
– permettre une estimation du cout final et de la date d’achèvement de votre projet; et
– créer un référentiel de données d’historique de projets pour votre organisation.
La fréquence de mesure peut varier d’une journée à l’autre, par exemple, en comptant le nombre
de fonctionnalités mises en œuvre via le processus de développement agile; hebdomadaire, par
exemple, en comptant le nombre de cas d’utilisation mis en œuvre à l’aide d’un processus de
développement classique. Les équipes peuvent se rencontrer brièvement chaque jour pour faire le
point sur les progrès réalisés et les zones à problèmes; les chefs d’équipe et vous, responsable de
projet, pouvez vous rencontrer une fois par semaine pour examiner le projet et chaque mois pour
planifier les détails du travail du mois à venir. Vous, le chef de projet et certains membres de votre
personnel clé pouvez rencontrer la haute direction et les clients tous les mois pour examiner les
progrès et identifier les problèmes.
Une mesure fréquente de l’état fournit une alerte précoce des problèmes lorsque l’état actuel ne
correspond pas à l’état prévu. L’identification précoce des problèmes est souhaitable, car les

problèmes sont plus faciles à résoudre lorsqu’ils sont identifiés tôt, c’est-à-dire avant que les
défauts des produits du travail ne puissent se propager aux produits du travail suivants. La collecte
périodique d’informations sur le statut permet de prévoir les tendances des attributs du projet, tels
que les défauts, les couts et le calendrier. Si, par exemple, il est déterminé que votre projet a deux
semaines de retard, si on estime que le projet est à moitié achevé et si les progrès se poursuivent
au rythme actuel, le projet aura quatre semaines de retard. Les énoncés « if » de l’exemple précédent
sont des facteurs à surveiller et à mettre à jour en permanence.
La mesure est un moyen pour comprendre le passé, superviser les activités et les produits en
développement et permettre de prédire le futur. Ces capacités seront d’un grand bénéfice pour le
domaine du développement ou de maintenance, un domaine trop souvent blâmé pour des
échéanciers imprécis, des dépassements de budget, des taux de défaillance importants. Dans le
passé, plusieurs organismes de logiciels ont considéré la mesure comme une tâche à valeur non
ajoutée, alors que la mesure est une pratique de base dans le génie logiciel comme dans les autres
disciplines du génie. Les organismes performants conçoivent leurs processus techniques et de
management pour utiliser des données objectives de mesure. Les données de mesure et les résultats
qui en sont dérivés servent d’assise aux décisions à court terme, pour la livraison d’un logiciel, et
à moyen et long terme pour l’amélioration des processus et produits logiciels. Comme présenté aux
sections précédentes, toutes les estimations sont des projections du passé vers le futur,
correctement ajustées pour tenir compte des différences entre le passé et le futur. Les estimations
basées sur des données locales seront plus précises que celles basées sur des modèles empiriques
ou des moyennes de l’industrie. Une raison importante pour la mesure est donc de construire un
référentiel de données sur lequel des estimations pour des projets futurs pourront être basées. De
plus, l’analyse des données de projet collectées dans votre organisation peut révéler des problèmes
courants et récurrents qu’il convient de résoudre au niveau organisationnel. Par exemple, une
analyse peut montrer que pour la plupart des projets, un grand pourcentage du total des défauts
se trouve dans les interfaces entre les modules de code. L’amélioration de la formation et des outils
de conception d’interfaces pourraient permettre de réduire considérablement le total des défauts
des logiciels de l’organisation. Les attributs que vous mesurez et contrôlez dépendent des critères
de réussite de votre projet: la fiabilité et les performances du logiciel livré peuvent être les critères
de réussite les plus importants, ou bien le contrôle du calendrier et du cout du projet est primordial.
Cependant, il est difficile d’imaginer un projet pour lequel un certain niveau de mesure et de
contrôle de chacun des attributs suivants n’est pas important pour un résultat réussi:
– effort (en Jours): quantité de travail dépensée pour diverses activités;

– calendrier (en Jours): réalisation des jalons (c.-à-d. activités clés) mesurés de manière objective
(activités effectuées, activités en cours et activités restantes à faire);
– cout (en $): dépense pour divers types de ressources, y compris les efforts;
– progrès (en %): travaux terminés, acceptés et définis;
– caractéristiques du produit: exigences mises en œuvre et dont l’efficacité a été démontrée;
– attributs de qualité du produit: défauts (nombre), fiabilité (%), disponibilité (%), temps de réponse
(secondes), débit (kb/sec), etc., tels que spécifiés;
– risque (en jours ou en $ supplémentaires): état des facteurs de risque et action d’atténuation.
En règle générale, les attributs de processus (effort, planification, cout et progression) sont mis en
balance avec les attributs du produit (caractéristiques et attributs de qualité). Parmi les attributs
de processus, la planification peut (ou non) être plus importante que l’effort ou le cout, et la sécurité
peut être un attribut de produit plus important que la performance. Selon l’importance relative des
divers attributs de processus et de produit, des efforts supplémentaires peuvent être déployés pour
mesurer et contrôler certains attributs plutôt que pour en mesurer et contrôler d’autres. Certains
outils peuvent aider à obtenir la vue d’ensemble de vos projets.

Figure 2.17 – Exemple de Jira Core – tableau des indicateurs de projet
Les mesures relatives aux produits et aux processus sont ou devraient être des sous-produits des
procédures, méthodes, outils et techniques utilisés pour développer des logiciels; sinon, les
processus de développement et de gestion doivent être améliorés. Le temps, les efforts et les couts
excessifs consacrés à l’obtention, à l’analyse et à la mise en œuvre de mesures de produits et de
processus sont le symptôme de processus de développement et de gestion inefficaces.
Des conseils supplémentaires concernant le choix et la mise en œuvre de mesures logicielles sont
fournis sur le site Web de et dans les publications de Systems Engineering Leading indicator Guide
(www.psmsc.com). Il est recommandé de mesurer :
Les courbes d’avancements : La courbe d’avancement sert à montrer la tendance obtenue aussi
la courbe de progrès réel. Mais alors, comment savoir si l’on est toujours dans un bon déroulement
d’avancement ou non? À partir de quand risque-t-on vraiment un retard de planification. Une
solution consiste à venir ajouter une courbe sur le graphique : l’avancement au plus tard.
L’avancement planifié représentant dans la majorité des cas l’avancement au plus tôt. Ainsi nous
obtiendrons le graphique suivant.

Figure 2.18 – Graphe de courbe d’avancement d’un projet
2.6 LA FERMETURE DU PROJET
Le projet atteint la fermeture quand tous les plans et processus incorporés ont été exécutés et
complétés. À ce stade, les critères pour le succès du projet sont revisités. Une fois que la fermeture
est établie, des activités d’archivage, d’analyse post mortem et d’amélioration des processus sont
exécutées.
Les tâches comme indiquées dans les plans sont accomplies, et l’accomplissement satisfaisant des
critères d’accomplissement est confirmé. Tous les produits prévus ont été livrés avec des
caractéristiques acceptables. Des exigences sont identifiées et confirmées comme satisfaites, et les
objectifs du projet ont été atteints. Ces processus généralement font participer tous les mandataires
et ont comme conséquence la documentation de l’acceptation de client et de tous rapports connus
restants de problème.
Après que la fermeture ait été confirmée, l’archivage du matériel de projet a lieu en conformité avec
les méthodes, l’endroit, et la durée convenue avec les mandataires. La base de données des mesures
de l’organisation est mise à jour avec des données finales de projet et des analyses après-projet
sont entreprises. Un projet post mortem est entrepris de sorte que les problématiques, les
problèmes, et les opportunités produites pendant le processus (en particulier par l’intermédiaire de
la revue et l’évaluation, voir le sous-domaine 4 la revue et l’évaluation) sont analysés, et des leçons
sont tirées et introduites dans le processus organisationnel d’apprentissage et des projets
d’amélioration.
2.7 LES AUTRES SECTIONS DU PLAN DE PROJET
Finalement, certains mécanismes de gestion de projet qui se traduisent par des outils et des
méthodes nécessaires à la gestion de projet permettent de mieux supporter et accompagner le chef
de projet durant toutes les phases du projet, et ce, dans le but de respecter les échéances, les
budgets et la qualité. Ils sont :
– Le processus de gestion de l’intégration : Cette activité consiste à coordonner adéquatement les

divers éléments du projet. Elle comporte : 1) la mise en œuvre d’une chartre de projet; 2) d’un plan
de projet; 3) la direction et la gestion des travaux; 4) la gestion des connaissances du projet; 5) le
suivi et le contrôle des travaux; 6) la gestion intégrée des changements et 7) l’activité de clôture du
projet;
– Le processus de gestion de la qualité : Cette activité consiste à s’assurer que le projet réponde aux
besoins pour lesquels il a été entrepris. Elle comporte la planification, l’assurance et le contrôle de
la qualité. Puisqu’atteindre la satisfaction des mandataires (utilisateur et client) est un des
principaux objectifs du projet, il est important que le progrès vers ce but soit évalué formellement
et périodiquement. Ceci se produit lors de l’atteinte des jalons importants principaux du projet
(par exemple, confirmation de la conception de l’architecture du logiciel, revue technique
d’intégration du logiciel). Les variations par rapport aux exigences établies sont identifiées et les
actions appropriées d’ajustements sont mises en œuvre; de réponse (secondes), débit (kb/sec),
etc., tels que spécifiés;

– Le processus de gestion des communications : Cette activité consiste à effectuer, la collecte, la
diffusion, l’archivage et, par la suite, le traitement final des informations concernant le projet, de
façon adéquate et en temps voulu. Elle est constituée de la planification de la communication, la
diffusion de l’information (gestion du changement), les rapports d’avancement et la clôture
administrative;
– Le processus de gestion des risques : Cette activité sera décrite en détail au chapitre 6. Elle consiste
à identifier, à analyser et à répondre aux risques du projet. Elle implique qu’on augmente la
probabilité et l’impact des évènements positifs et de diminuer la probabilité et l’impact des
évènements défavorables au projet. Elle comporte la planification de la gestion des risques,
l’identification, l’analyse qualitative et l’analyse quantitative des risques, la planification des
stratégies de réponse, et le suivi et le contrôle des risques. Le chapitre 4 sera dédié à ce sujet.
– Le processus de gestion des approvisionnements : Cette activité sera décrite en détail au chapitre
7. Elle consiste à assurer l’obtention des produits et des services qui permettent de réaliser le
contenu du projet, de l’extérieur de l’entreprise. Elle comporte la planification des
approvisionnements, la préparation des appels d’offres, les appels d’offres, le choix des
fournisseurs, la gestion administrative des contrats et la clôture des contrats. Préparer et exécuter
les contrats avec des fournisseurs, surveiller l’exécution du fournisseur, et accepter les produits
de fournisseur, les incorporants comme appropriés.
2.8 RÉPONSES AUX QUESTIONS D’ESTIMATION DE LA SECTION 2.4.4
– quelle est la température à la surface du soleil? 10,000 °F / 6,000 °C;

– quelle est la surface de l’Asie? 17,139,000 miles carrés / 44,390,000 kilomètres carrés;
– quelle est l’année de naissance de Alexandre Le Grand? 356 BC;
– quelle est la valeur totale des dollars américains en circulation? $1.5 trillion;
– quel est le volume total des Grands Lacs? 8 X 1014 pieds cubes.

Chapitre 2

Transféré par

Droits d'auteur :

Formats disponibles

Chapitre 2

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre 2

Transféré par

Droits d'auteur :

Formats disponibles

La gestion plus

2 classique d’un projet

Dans ce chapitre, les sujets suivants sont abordés:

© Alain April, PhD, 2020 - Tous droits réservés

La technologie de la plateforme de développement logiciel inclut l’ensemble des méthodes, outils et

Les principales activités de la gestion de projet sont la planification et l’estimation, la mesure et le

© Alain April, PhD, 2020 - Tous droits réservés

La communication implique la mise en place et le maintien de canaux de communication adéquats

2.2 MODÈLE DES ENJEUX DE GESTION DE PROJET LOGICIEL

© Alain April, PhD, 2020 - Tous droits réservés

Estimer Contrôler Assurance

Rapports de projets Rapports de statuts

Figure 2.1 – Modèle des activités de gestion de projets logiciels

© Alain April, PhD, 2020 - Tous droits réservés

2.3 LE PROCESSUS DE PLANIFICATION DU PROJET

© Alain April, PhD, 2020 - Tous droits réservés

En fonction de la nature et de la portée de votre projet, clarifier les exigences opérationnelles et

© Alain April, PhD, 2020 - Tous droits réservés

© Alain April, PhD, 2020 - Tous droits réservés

© Alain April, PhD, 2020 - Tous droits réservés

LA STRUCTURE DE DÉCOUPAGE DU PROJET (WBS)

La technique du WBS - Work Breakdown Structure permet de mettre en oeuvre ce principe en

© Alain April, PhD, 2020 - Tous droits réservés

Figure 2.2 – Exemple de WBS de haut niveau

© Alain April, PhD, 2020 - Tous droits réservés

ÉTABLIR LES RESPONSABILITÉS POUR LES ACTIVITÉS DU WBS

© Alain April, PhD, 2020 - Tous droits réservés

Figure 2.4 – Exemple de matrice RACI pour le projet

© Alain April, PhD, 2020 - Tous droits réservés

REPRÉSENTER L’ORGANIGRAMME FONCTIONNEL DU PROEJET

© Alain April, PhD, 2020 - Tous droits réservés

Rôle dans le Courrier

Figure 2.6 – Tableau des participants au projet

– la formulation des besoins des utilisateurs;

© Alain April, PhD, 2020 - Tous droits réservés

Project Management VP in charge of

Project Main project

Co-pilot Pilot IT responsible

Participant Participant Participant Operations

(Revy) (Réno-Dépôt) (Rona)

(Revy) (Réno-Dépôt) (Rona)

Key user Programmer Programmer Programmer

– réaliser les travaux comme prévu dans le contrat;

© Alain April, PhD, 2020 - Tous droits réservés

L’ESTIMATION D’UN PROJET LOGICIEL

© Alain April, PhD, 2020 - Tous droits réservés

Avant-projet Exigences Conception Codage Tests MEP

Comme proposé par le PMI, la gestion du temps de projet comprend:

© Alain April, PhD, 2020 - Tous droits réservés

L’estimation descendante (Top Down) : Cette approche consiste à estimer le calendrier e/ ou le

L’estimation à l’aide de la taille fonctionnelle (Point de fonction): Cette approche consiste à

© Alain April, PhD, 2020 - Tous droits réservés

Processus Fonctionnel Entrée Lecture Écriture Sortie Total

Figure 2.11 – Exemple de l’estimé de la taille fonctionnelle du projet

© Alain April, PhD, 2020 - Tous droits réservés

Projet de vente/achat d’items personnels

Mettre en place -Identifier les -Définir -Implémenter, -tester et corriger

Figure 2.12 – WBS du projet de développement d’un logiciel similaire à Kijiji

© Alain April, PhD, 2020 - Tous droits réservés

3.4.2 Rapport de résultats des tests