Vous êtes sur la page 1sur 70

‫الجمهورية الجزائرية الديمقراطية الشعبية‬

‫وزارة التعليم العالي والبحث العلمي‬


People’s Democratic Republic of Algeria
Ministry of Higher Education and Scientific Research
University of Algiers 1 Ben
Benyoucef Benkhedda

Faculté des Sciences


Département : Mathématiques et Informatique
Domaine : Mathématiques et Informatique
Filière : Informatique
Spécialité : Licence Ingénierie des Systèmes d'Information et des Logiciels, L3

Cours, TD : Gestion de projet logiciel

Dr ZEMALI Elamine

Année universitaire: 2019/2020

1
Avant propos

Dans notre sphère privée ou professionnelle, on est tous amené à réaliser des activités
qui rentrent dans le cadre de ce qu'on appelle « un projet ». On peut définir un projet
comme étant un ensemble d'activités fortement liées, visant à satisfaire un objectif
commun. Chaque projet qu'il rentre dans le cadre informatique ou non, doit satisfaire
certaines contraintes qui tournent autour de trois catégories : la durée, le coût et la
qualité. Cependant, les études ont montré que trois projets sur quatre échouent en termes
de satisfaction des exigences tracées avant le lancement, malgré la présence de toutes
les compétences nécessaires.

Pour cela, la gestion de projet intervient comme un ensemble d'outils qui permet
de tracer un plan de réalisation, qui vise à assurer la livraison dans les délais, le respect
du budget et la bonne qualité. La gestion de projet est l’ensemble des taches
administratives, organisationnelles, prédictives et de contrôle qui assistent le projet
avant son lancement, jusqu'à sa clôture.

Ce support de cours intitulé « gestion de projet logiciel » rentre dans le cadre de la


formation licence informatique dédiée aux étudiants de la spécialité ISIL. Ce cours a
principalement comme objectif de présenter un aperçu global sur les concepts liés à la
gestion de projet logiciel en présentant les notions indispensables par la compréhension.
Il présente également les différents modèles de gestion de projet logiciel et les
différentes formes organisationnelles qui existent. Ce cours vise aussi à présenter les
étapes de gestion de projet et les éléments clés d’un plan de projet. Ce module est
enseigné en tant qu’unité fondamentale « UF2 », avec un volume horaire de 1h30 de
cours magistral, 1h30 des travaux dirigés et 1h30 de travaux pratiques.

2
Sommaire
Avant propos ..................................................................................................................... 2
Listes de figures ................................................................................................................ 6
Liste des tableaux.............................................................................................................. 7
Liste des abréviations........................................................................................................ 8
Résumé.............................................................................................................................. 9
Chapitre 1 : Introduction à la gestion de projet .............................................................. 10
Introduction ................................................................................................................. 10
1. Définition d’un projet .............................................................................................. 10
1.1 Les aspects d’un projet ...................................................................................... 11
1. 2 Types de projets ................................................................................................ 11
2. Gestion de projet ..................................................................................................... 12
2.1 Les acteurs de la gestion de projet ..................................................................... 12
3. Les étapes d’un projet ............................................................................................. 14
a) Phase préparatoire ............................................................................................... 14
b) Phase de réalisation ............................................................................................. 14
c) Phase de fin de projet (mise en œuvre) ............................................................... 14
4. Définitions ............................................................................................................... 14
Chapitre 2 : Les modèles de gestion de projet. ............................................................... 16
Introduction ................................................................................................................. 16
2. Notion de cycle de vie ............................................................................................. 16
2.1 Pourquoi un tel découpage ?.............................................................................. 17
2.2 Les phases du cycle de vie................................................................................. 17
3. Les approches de développement............................................................................ 18
3.1 Approche séquentielle ....................................................................................... 18
3.2 Méthode Agile : ................................................................................................. 20
3.3 Autres approches de développement : ............................................................... 23
Chapitre 3 Les éléments de gestion de projet ................................................................. 24
Introduction ................................................................................................................. 24
2. Qu’est-ce qu’un plan de projet ? ............................................................................. 24
3. Pourquoi faut-il un plan de projet ?......................................................................... 25
4. Les éléments clés d’un plan de projet : ................................................................... 25
4.1 La charte d’un projet : ....................................................................................... 25
4.2 Le calendrier d’activités .................................................................................... 26
4.3 L’horaire de travail ............................................................................................ 26
4.4 La matrice de responsabilités ............................................................................ 26

3
4.5 Le budget ........................................................................................................... 27
4.6 Les étapes importantes, avec les dates cibles .................................................... 27
4.7 La stratégie de gestion de risque ....................................................................... 27
Série de TD 1 : Introduction ........................................................................................... 31
Série de TD 1 : Introduction (Corrigé) ........................................................................... 33
Chapitre 4 : L’organisation des équipes de programmation ........................................... 36
Introduction ................................................................................................................. 36
2. L’analyse organisationnelle du projet ..................................................................... 36
2.1 Structure hiérarchique ....................................................................................... 37
2.2 Structure fonctionnelle ...................................................................................... 37
3. Les aspects de gestion de personnel ........................................................................ 38
3.1 Divergence d’objectif ........................................................................................ 38
3.2 Productivité........................................................................................................ 38
3.3 Evaluation du travail.......................................................................................... 38
3.4 Coordination et communication ....................................................................... 38
4. L’organisation d’une équipe ................................................................................... 40
4.1 Organisation hiérarchique ................................................................................. 40
4.2 Organisation matricielle .................................................................................... 41
4.3 Équipe du programmeur en chef ....................................................................... 42
4.4 Equipe SWAT ................................................................................................... 42
4.5 Une équipe agile ................................................................................................ 42
4.6 Développement de logiciels Open Source ......................................................... 43
Série TD 2 : Gestion des personnes et organisation de l’équipe .................................... 44
Série TD 2 : Gestion des personnes et organisation de l’équipe (corrigé) ..................... 45
Chapitre 5 : Le processus de planification ...................................................................... 47
Introduction ................................................................................................................. 47
2. Définition de la planification .................................................................................. 47
3. Pourquoi planifier ? ................................................................................................. 48
4. Le processus de planification .................................................................................. 48
4.1 Etablir les objectifs et les contraintes ................................................................ 49
4.2 Effectuer une estimation initiale ........................................................................ 49
4.3 Définir les tâches, les étapes clés et les livrables .............................................. 50
4.4 Dresser un horaire pour les tâches à effectuer ................................................... 51
4.5 L'ordonnancement des taches ............................................................................ 52
Série TD 3 : la planification ............................................................................................ 66
Références ....................................................................................................................... 70

4
5
Listes de figures

Figure 1 Exemple d’un processus en cascade ................................................................. 19


Figure 2 Exemple d’un processus en V .......................................................................... 20
Figure 3 Processus de gestion de risques ........................................................................ 29
Figure 4 Exemple d’une structure hiérarchique .............................................................. 37
Figure 5 Exemple d’une structure fonctionnelle............................................................. 37
Figure 6 Exemple d’une organisation hiérarchique de développement logiciel ............. 40
Figure 7 Organigramme de planification ........................................................................ 49
Figure 8 La modélisation de l’ordonnancement par Gantt ............................................. 56
Figure 9 Diagramme PERT pour un ordonnancement ................................................... 57
Figure 10 Diagramme CPM pour un ordonnancement ................................................... 58
Figure 11 Diagramme de CPM ....................................................................................... 59
Figure 12 Diagramme de CPM pour l’affectation de ressources.................................... 63
Figure 13 Diagramme de Gantt pour l’affectation de ressources ................................... 63
Figure 14 Elimination de surcharge par un nivellement par date ................................... 64
Figure 15 Elimination de surcharge par lissage .............................................................. 65

6
Liste des tableaux

Tableau 1 Exemple d’une matrice de responsabilité ...................................................... 27


Tableau 2 Exemple d’un Tableau d'étapes clés .............................................................. 54
Tableau 3 Exemple d’un tableau de tâches ..................................................................... 54
Tableau 4 Exemple d’un tableau d’allocation ................................................................ 55
Tableau 5 Exemple d’un ordonnancement ..................................................................... 56
Tableau 6 2 eme exemple d’un ordonnancement .......................................................... 57
Tableau 7 Exemple de calcul des marges ....................................................................... 61
Tableau 8 Exemple d’affectation de ressource ............................................................... 62

7
Liste des abréviations

CPM : Critical Path Method

DTA : Début au plus tard

DTO : Début au plus tôt

FTA : Fin au plus tard

FTO : Fin au plus tôt

PBS : Product Breakdown Structure

PERT : Program Evaluation and Review Technique

WBD : Wide Bande Delphi

WBS : Work Breakdown Structure

8
Résumé

L’élaboration et la réalisation d’un projet quelque soit sa nature passe par plusieurs
étapes dans lesquelles plusieurs personnes contribues dans le but d’atteindre un objectif
commun.
Généralement, un projet est la conséquence d’un besoin ou une problématique. Ceci est
fixé par ce qu’on appelle le maitre d’ouvrage ou le propriétaire. Ce dernier explique
soigneusement les grandes lignes de ce qui va être le produit final, les contraintes
temporelles imposées et le budget alloué.
Une fois établis, ces informations seront communiquées au maitre d’œuvre qui reçoit la
commande et entame les opérations nécessaires à la production. Le responsable de
projet, sur la base d’analyse des besoins et contraintes imposées, modélise sa vision sur
la manière dont le projet sera réalisé. Cette tache est vraiment critique puisque la
réussite du projet en dépend largement. Généralement, le résultat est modélisé sous
forme d’un plan de travail opérationnel qui répond à plusieurs questions :

• Pourquoi ? Quel est le besoin ? Quel service rendu ? Quelles sont les fonctions
attendues ?
• Quoi ? Quel système ? Quels éléments à construire ?
• Comment ? Quelles activités pour réaliser le projet ?
• Qui ? Quelles compétences ?
• Combien ? Quel budget ?
• Quand ? Quel calendrier ?

Le chef de projet doit être vigilant en préparant des plans et des stratégies de secours
pour tous les imprévus qui puissent mettre en péril l’élan de son projet. Il commence par
identifier tous les risques et les analyser en précisant leur probabilité d’appariation et
leur impact. Ensuite, les risques seront traités par des plans d’évitement, plans de
réduction et plans de secoure. Le chef de projet assure le pilotage de son projet en
suivant le plus strictement possible le plan pour livrer l’ouvrage suivant le calendrier
prévu, sans dépasser les coûts budgétés.

9
Chapitre 1 : Introduction à la gestion de projet

Introduction

Dans le monde entier, environ un demi-million de responsables de projets exécutent


environ un million de projets logiciels par an, produisant des logiciels qui coutent des
milliards de dollars. Cependant, une grande partie de ces projets échouent en termes de
satisfaction des attentes des clients en matière de qualité, ou consomme le délai et le
budget initialement alloués. Une étude annonce qu’environ un tiers des projets
dépassent les couts et le calendrier initialement établis (Vliet, 2007).
Donc la question qui se pose, Pourquoi tant de projets qui échouent ?, la réponse à cette
question nécessite beaucoup de réflexions. Mais toutes les idées convergent vers une
évidence qui correspond au fait que l’échec est principalement une conséquence d’une
mauvaise gestion. En effet, la plupart des chefs de projet affirment que les principaux
causes d’échec sont des objectifs peu clairs, une mauvaise planification, manque de
personnel ou de ressource et la non maitrise d’une nouvelle technologie. On peut
clairement déduire que les trois premières causes sont directement liées à la mauvaise
gestion, tandis que la dernière est considérée comme un risque fréquent qui est traité
dans le cadre de la gestion des risques et qui fait partie de la gestion de projet.
Avant de détailler tout cela, il est impératif de connaitre toutes les notions de base qui
sont liée à la gestion de projet. En effet, plusieurs notions seront traitées dans ce
chapitre, afin de cerner les frontières d’un projet, comprendre ses objectifs et ses
aspects. Ce chapitre offre également une définition de la gestion de projet, son rôle et
les parties prenantes impliquées dans la réalisation du projet.

1. Définition d’un projet

Un projet par définition est un ensemble d’activités organisées en phases ou étapes,


formant l’unité de gestion permettant la réalisation d’un objectif défini et précis et cela
dans le cadre des délais fixés et dans la limite de l’enveloppe budgétaire alloué.

« Une séquence d’activités uniques, complexes et connectées, avec pour but d’atteindre
un objectif. Ceci devant être réalisé à l’intérieur d’un cadre temporel, d’un budget et en
respect de spécifications » (boussaid, 2010).

10
Un projet comprend un objectif défini devant être livré dans un délai et à un coût
convenu
Un système dynamique à maintenir en équilibre

En partant de ces définitions, on peut souligner que la vraie difficulté n’est pas liée à la
complexité mais au fait de respecter les délais, le cout en offrant tout la qualité requise.
Généralement ces trois contraintes sont liées. Pour certains projets, avec un budget
limité, le but est principalement de maximiser la qualité du produit final avec les
moyens disponibles. Cela affectera directement la durée de réalisation. Pour d'autres,
les contraintes de qualité sont fixées à l'avance et l'objectif est de produire un produit
qui répond à ces contraintes de qualité.

1.1 Les aspects d’un projet


Le projet est un objectif extraordinaire (au sens littéral du mot) qui combine cinq
aspects :

- Fonctionnel : réponse à un besoin, ce qui représente le but principal de la création


d’un projet.
- Technique : respect des spécifications et des contraintes de mise en œuvre
- Organisationnel : respect d'un mode de fonctionnement (rôles, fonctions, culture,
résistance au changement) de la structure cible. Il existe plusieurs cas de figure : de la
plus simple à la plus complexe en fonction de la taille du projet.
- Délais : respect des échéances (planning)
- Coûts : respect du budget

1. 2 Types de projets
Les projets prennent des formes différentes (CLET, 2005), selon l’objectif visé :

-Ouvrage : Le résultat généré est unique, tel que la réalisation d’un portail web pour
une entreprise.

-Produit : mise au point d’une gamme de produit. Un seul projet pour générer
plusieurs copies du même résultat.
Exemple : nouveau modèle de voiture, nouvelle création de haute couture, une
application mobile.

11
-Opération : le résultat n’est pas forcement un objet concret. Tel que la configuration
d’un réseau, fusion de deux entreprises, automatisation des processus.

-Evénement : le but du projet est de réaliser un événement, tel qu’une conférence, une
compétition et des formations.

2. Gestion de projet

Définition : On appelle « gestion de projet » ou « conduite de projet » l’organisation


méthodologique mise en œuvre pour faire en sorte que l’ouvrage répond aux attentes et
qu’il soit livré dans les conditions de coût et de délais prévues initialement. Pour ce
faire, la gestion de projet à pour objectifs d’assurer la coordination des acteurs et des
tâches dans un souci d’efficacité et de rentabilité.

La gestion de projet est défini aussi par PMBOK (American National Standard, 2004)
comme :

« Le management de projet est l'application de connaissances, de compétences, d'outils et


de techniques aux activités du projet afin d'en respecter les exigences. Le management de
projet est accompli par l'application et l'intégration des processus de management de projet
groupés en : démarrage, planification, exécution, surveillance et maîtrise, et clôture. Le
chef de projet est la personne responsable de l’atteinte des objectifs du projet. »

La direction de projet est assurée par un chef de projet assisté parfois d’une équipe. La
mission de cette direction de projet est quadruple :

1. fixer les objectifs du projet en termes de délais, de performances techniques


(notamment le choix des solutions techniques),

2. définir les moyens à mettre en œuvre en ce qui concerne les ressources matérielles et
humaines. Ce qui implique directement d’attribuer un budget à la réalisation du projet.

3. d’apprécier les risques encourus et de mettre en œuvre des procédures de surveillance


(par exemple, définir des indicateurs de tenue des délais et des coûts),

4. d’animer les hommes qui travaillent sur le projet en coordonnant leurs activités, en
faisant des évaluations régulières qui conduisent parfois à réviser les objectifs du projet.

2.1 Les acteurs de la gestion de projet


La gestion d’un projet est conduite par des acteurs, en étapes, à l’aide d’outils et
méthodes d’organisation spécifiques.

On trouve essentiellement :

12
a) Maître d’ouvrage (MOA)
Tout simplement c’est le client, c’est la personne physique ou morale qui demande la
réalisation d’un produit. C’est le maître d'ouvrage ou la maîtrise d'ouvrage qui définit le
besoin, l’objectif et le budget de l’ouvrage demandé au projet.

Le maître d'ouvrage a pour rôle (Durand, 2004):


• De fournir une expression de besoin fonctionnel.
• De prendre les décisions impactant fondamentalement le projet
• De représenter les utilisateurs et valider les résultats du projet.

b) Maître d’œuvre (MOE)


C’est la personne physique ou morale qui a en charge la réalisation d'un ouvrage en
respectant les délais, les coûts et le niveau de qualité fixés par le maître d’ouvrage. Le
maître d'œuvre est responsable des choix techniques du projet. Il est souvent appelé chef
de projet.

Le maître d'œuvre a pour rôle (Durand, 2004):

• De répondre à l’expression de besoin fonctionnel en proposant une


solution technique.
• De respecter les délais, les coûts et le niveau de qualité du projet
• D’organiser le quotidien du projet.

Un chef de projet est un responsable qui pilote le projet en prenant toutes les décisions
nécessaires. Il doit être multi compétents, c’est-a-dire maitriser des techniques de
gestion de projet et être un bon leader. Pour bien mener un projet à son terme, un chef
de projet a comme rôle :

- Organiser : il doit faire preuve d’une bonne capacité d’analyse et d’organisation. Il


adaptera son style de management en fonction du contexte ; c’est ce qu’on appelle le
management situationnel, qui répond à la nécessité d’exercer différents modes de
management, à différents moments (rota, 2008).

- Planifier : le chef de projet établie un plan de projet spécifiant en détail


l’enchainement des taches à réaliser, l’estimation des durées, la qualité et le cout
nécessaire.

- Piloter : A tout moment le chef de projet doit suivre et surveiller l’accomplissement


des taches. En cas d’un imprévu, il prendra toutes les diapositives nécessaires pour
garder l’élan du projet.

- Anticiper : Il évalue les contraintes et les risques, il établit des plans de secours.

- Négocier : Le chef de projet doit négocier pour obtenir les ressources qui lui sont
nécessaires, avec des profils et des expertises spécifiques.

- Animer : Un chef de projet doit animer une équipe composée de plusieurs profils
différents afin de réaliser une œuvre collective, en leur donnant un rythme commun.

13
3. Les étapes d’un projet

Pour qu’il soit géré dans un contexte de qualité, un projet doit être découpé en plusieurs
phases. De façon très basique, un projet est généralement découpé en trois phases (Jean
Yves Moine, 2012) :

a) Phase préparatoire
À ce stade, le but est de déterminer le périmètre du projet et sa faisabilité, c’est-à-dire de
définir ce qui sera inclus dans les objectifs du projet, ce qui ne le sera pas et si le projet
doit bien être lancé.
L’objectif de la gestion de projet doit être précisé de façon claire, chiffrée et datée. Le
résultat doit être conforme à des normes de qualité et de performances prédéfinies, pour
le moindre coût et dans le meilleur délai possible.
D’autre part, l’étude de faisabilité détermine également si l’organisation est bien en
mesure de mener le projet à son terme. On cherche en particulier à savoir si elle dispose
des compétences, des ressources et des fonds nécessaires.

b) Phase de réalisation
C’est lors de cette phase que le projet est réalisé ou fabriqué, c’est-à-dire que les tâches
permettant de mettre en œuvre le nouveau produit, bien ou service, sont réalisées. Dans
les projets informatiques, c’est cette phase qui permet la construction du logiciel. Pour
contrôler l’avancement de ces tâches et le respect des délais, on utilise des outils de
gestion de projet notamment des logiciels qui permettent, en cas de retard ou
dépassement des délais, de planifier à nouveau la suite du projet.
Dans cette phase sont également réalisés les tests : test unitaire, test d'intégration, test de
performance.

c) Phase de fin de projet (mise en œuvre)


Dès la mise à disposition ou la réception du livrable, il est nécessaire de procéder à des
vérifications de manière à contrôler la conformité du résultat fabriqué avec la
commande qui avait été passée lors des spécifications. Les contrôles s’effectuent sous
forme de tests rigoureux à partir des cahiers de tests qui ont été préparés.

4. Définitions
Cahier des charges : c’est un document qui permet de formaliser avec précision le
besoin du maitre d’ouvrage en termes de fonctionnalités, attentes et contraintes.

Ressources: toute entité contribuant à la réalisation d’une tache. Cela inclut les
ressources humaines (personnes travaillant sur un projet à un instant t, équipe Projet) et
les ressource matérielles (outils, matériaux, financements..)

14
Charge : quantité de travail à effectuer. Cette quantité est définie en termes de moyen
affecté à une action pour l'exécuter; elle est exprimée généralement en nombre
d'hommes-mois, ou en heures de main-d’œuvre.

Tâche : Une ou ensemble d’actions menées pour aboutir à un résultat ou un objectif


bien précis. On associe à chaque tache, une durée, date de début et les ressources
nécessaires.

Jalon: c’est des événements clés programmés afin de contrôler l’état de progression.
Les jalons sont généralement programmés à la fin ou début d’une tache importante ou
pour contrôler la réalisation d’un objet concret tel qu’un document ou produit.

Livrable : c’est tous les produits ou documents générés que ce soit à la fin du projet
ou dans une phase intermédiaire. Exemples : manuel d’utilisation, version de logiciel.

15
Chapitre 2 : Les modèles de gestion de projet.

Introduction

Les entreprises et les organisations à succès ont tendance à développer des projets qui
produisent les résultats escomptés dans les délais impartis en utilisant les ressources
prévues. Les entreprises sont de ce fait de plus en plus désireuses de suivre un modèle
ou une méthode de gestion efficace afin d’évoluer dans un environnement flexible axé
sur des projets. Une telle approche garantie un processus de développement plus
structuré et mieux rationalisé, ce qui rend la collaboration plus souple et plus efficace.
Suivre un modèle de gestion est un raccourci qui englobe toutes les expériences
acquises par d’autres organismes et évite en conséquence les causes d’échecs (basic).
En général, un modèle de gestion n’est pas un ensemble d’activités ou de taches à
réaliser machinalement, il reflète un niveau de gestion d’une couche plus abstraite, c’est
une stratégie, une vision, une pratique.
Certainement un projet comporte plusieurs défis (gestion des risques, plan de
projet, estimation..) ou plusieurs suggestions et conseils peuvent être fournie pour les
surpassés. La combinaison de ces conseils peut ne pas s’avérer efficace si elle n’est pas
homogène ou si elle représente des idées conflictuelles ou contradictoires. Pour
résumer, suivre une méthodologie de gestion de projet permet de bien organiser un
projet dans un processus bien structuré et plus optimal. De plus, elle rend la
collaboration entre les parties prenantes plus pertinente et plus efficace, et cela en
mettant au clair leurs rôles et leur degré d’implication.
Tous les projets varient en termes de défis, contraintes et environnement. De ce
fait, aucune méthode de gestion ne peut être efficace pour tous les projets; ce qui est
aussi valable dans le sens inverse : toutes les méthodes de gestion ne fonctionneront pas
pour n’importe quel type de projet. Pour cela, il est indispensable pour un chef de projet
de connaitre les caractéristiques, les avantages et les inconvénients de chaque méthode.
L’objectif de ce cours est de :
- Présenter les phases de développement d’un projet logiciel, en guise de rappel
ou d’information, un chef de projet doit impérativement connaitre le processus
général pour produire un logiciel.
- Présenter les méthodes de gestion en mettant l’accent sur leurs avantages et
inconvénients

2. Notion de cycle de vie


Parmi les qualités intellectuelles qui sont indispensables pour un chef de projet logiciel
c’est de connaitre les différentes phases de développement d’un logiciel ou système
informatique. C’est ce qu’on appelle « cycle de vie d’un logiciel ». Le cycle de vie d'un
logiciel, désigne toutes les étapes du développement d'un logiciel, de sa spécification
jusqu’à sa disparition (Anne-Marie, 2002). L'objectif d'un tel découpage est de
permettre de définir des jalons intermédiaires permettant la validation du
16
développement logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés,
et la vérification du processus de développement, c'est-à-dire l'adéquation des méthodes
mises en œuvre.
Les phases du cycle de vie d’un projet sont différentes des groupes de processus du
management de projet. Elles sont également différentes de celles du cycle de vie d’un
produit, la vie d’un produit étant généralement plus longue que celle du projet duquel il
est issu.

2.1 Pourquoi un tel découpage ?


L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus
élevé quand elles sont détectées tardivement dans le processus de réalisation. Le cycle
de vie permet de détecter les erreurs au plus tôt et ainsi maîtriser la qualité du logiciel,
les délais de sa réalisation et les coûts associés.

2.2 Les phases du cycle de vie


Un cycle de vie du logiciel comprend les activités suivantes :

1-Objectifs : consiste à définir la finalité du projet et son inscription dans une stratégie
globale. C'est pendant cette phase qu'on défini un schéma directeur dans le cas de la
création ou de la rénovation d'un système informatique.

2-Définition des besoins : Un cahier des charges est établi par le client après
consultation des divers intervenants du projet (utilisateurs, encadrement...), un appel
d'offre est éventuellement lancé. Le cahier des charges décrit, en langage naturel, les
fonctionnalités attendues du produit ainsi que les contraintes non fonctionnelles (temps
de réponse, contraintes, mémoire...).

3-Analyse des besoins : il s’agit de formaliser les besoins des demandeurs et de


l’ensemble des contraintes, et étudier leur faisabilité.

4- Planification : La phase de planification permet de découper le projet en tâches, de


décrire leur enchaînement dans le temps, d'affecter à chacune une durée et un effort
calculé en homme*mois. Il est également important de définir les normes de qualité qui
seront appliquées comme la méthode de conception choisie ou les règles qui régiront les
tests. On notera également les dépendances extérieures (comme par exemple l'arrivée
d'une nouvelle machine ou d'un nouveau logiciel) afin de mesurer les risques encourus

5- Conception : Pendant cette phase l'architecture du logiciel est définie ainsi que les
interfaces entre les différents modules. On veillera tout particulièrement à rendre les
différents constituants du produit aussi indépendant que possible de manière à faciliter à
la fois le développement parallèle et la maintenance future.

6- Implémentation et tests unitaires : Chaque module est ensuite codé et testé


indépendamment des autres.

7- Validation et Intégration : Chaque module testé est intégré avec les autres suivant le
plan d'intégration et l'ensemble est testé conformément au plan de tests.

17
8- Qualification : Lorsque le logiciel est terminé et les phases d'intégration
matériel/logiciel achevées, le produit est qualifié, c'est à dire testé en vraie grandeur
dans des conditions normales d'utilisation. Cette phase termine le développement. A
l'issue de cette phase le logiciel est prêt à la mise en exploitation

9- Mise en exploitation : Lorsque le produit a été accepté, il passe en phase de


maintenance jusqu'à son retrait. C'est pendant cette phase que tous les efforts de
documentation faits pendant le développement seront particulièrement appréciés de
même que la transparence de l'architecture et du code.

3. Les approches de développement


Approche de développement consiste à la manière dont les étapes sont organisées pour
réaliser un logiciel, il existe plusieurs pratiques, plusieurs méthodologies ou démarches
qu’on peut les regrouper en deux grandes familles (Anne-Marie, 2002) :
 Approche séquentielle (cartésienne, déterministe)
 Approche Agile

3.1 Approche séquentielle


C’est une approche de gestion traditionnelle et classique qui consiste à évaluer et
analyser les différentes taches requises pour réaliser le projet. Ensuite, fournir un plan
pour superviser et surveiller l’accomplissement de ces tâches. Ce genre de méthode de
gestion est appliqué sur les projets qui ne nécessite aucune personnalisation avec des
objectifs clairs dés le début, et un faible taux de changement. Cette méthodologie se
caractérise par un attachement à tout planifier, Un plan de management du projet décrit
de façon détaillée comment et quand le travail sera réalisé, les modalités de
planification, d’exécution, de suivi et de clôture du projet. Les acteurs de cette
démarche ont tendance à fournir leur effort pour rester conforme au plan initial. Pour
cela ce genre de méthode est parfois qualifié de prédictive. La réussite d’un projet dans
ce contexte dépend largement de la qualité du plan établi. Parmi les méthodes basées sur
cette approche, on trouve principalement :

- Méthode en cascade
- Méthode en V

a) Méthode en cascade :
Le modèle de développement logiciel en cascade décrit une méthode de développement
séquentielle qui est souvent considérée comme l'approche classique du cycle de vie du
développement logiciel. Il a été décrit formellement par le Dr Winston W. Royce en
1970.
L’idée globale d’une telle méthode repose sur le fait que le processus global est divisé
en plusieurs phases successives (Figure 1). Le développement du logiciel passe d'une
phase à l'étape suivante d'une manière purement séquentielle. Le projet s’achève une
fois que toutes ces phases seront exécutées, vérifiées et validées. Par exemple, l'équipe
de développement remplit d'abord les exigences et lorsque toutes les exigences
souhaitées sont entièrement remplies, examinées et approuvées, l'équipe informatique
passe à la phase de conception.

18
Figure 1 Exemple d’un processus en cascade

Le chef de projet qui opte pour ce modèle doit avoir le contrôle total sur tous les aspects
de son projet. Les phases de développement sont ensuite effectuées les unes après les
autres, avec un retour sur les précédentes seulement. Le processus de développement
utilisant un cycle en cascade exécute des phases qui ont pour caractéristiques :

 de produire des livrables définis au préalable ;


 de se terminer à une date précise ;
 de ne se terminer ququee lorsque les livrables sont jugés satisfaisants lors d'une
étape de validation
validation-vérification.

Avantage :
En plus d’être une approche simple et directe, la gestion de projet traditionnelle
fonctionne bien avec de nombreuses entreprises qui utilisent des paramètres de petit
groupe, et les membres de l'équipe ne sont pas dépendants les uns des autres pour aller
de l'avant avec le projet. Si les communications au sein de l'équipe peuvent rester
minimes, la gestion traditionnelle des projets peut se dérouler sans problème.
La gestion de projet traditionnelle a tout ce qu'il faut pour gérer et exécuter avec
succès un projet qui ne nécessite aucune personnalisation. DoncDonc, le chef de projet peut
planifier l'ensemble du projet, établir un calendrier et indiquer leless ressources requises.
De plus, le coût sera élaboré à la haute direction, de sorte que tout le monde sait à quoi
s'attendre dans le projet. En plus des activités régulières du projet, le chef de projet
s'occupera également de la gestion des risques. Si certains risques ont un impact sur les
processus d'affaires, le gestionnaire de projet proposera des critères d'atténuation
appropriés.

b) Modèle en V :
Ce modèle est une amélioration du modèle en cascade qui permet en cas d'anomalie, de
limiter le retour aux étapes précédentes. Les phases de la partie montante doivent
renvoyer de l'information sur les phases en vis
vis-à-vis
vis lorsque des défauts sont détectés
afin d'améliorer le logiciel (Figure 2).

19
De plus, le cycle en V met en évidence la nécessité d'anticip
d'anticiper
er et de préparer dans les
étapes descendantes les mesures et les mécanismes de validation des étapes
ascendantes. Cela se concrétise par l’établissement de différents niveaux tests : les tests
de validation sont définis lors des spécifications, les tests unitaires sont définis lors de la
conception, etc.

Figure 2 Exemple d’un processus en V

Les limites de la méthode séquentielle :


L’approche « en cascade » est trop rigide pour permettre des retours en arrière ; elle
suppose que l’on fait bien du premier coup. Une décision ou une anomalie détectée dans
une phase aval de la cascade peuvent remettre en cause partiellement ou totalement des
travaux validés précédemment et considérés comme définitifs.
L’effet tunnel est une autre des caractéristiques de l’approche « en cascade » : un projet
dure un an, la phase de recueil des besoins dure deux mois et le client ne voit le résultat
que neuf mois plus tard (rota, 2008) !
Que s’est-il passé entre--temps ? « On ne sait pas trop ce qu’ils font ces informaticiens !
»,
« Que va-t-il
il sortir de la « boîte » ? », « Mais, ce n’est pas ce que l’on attendait ! » ou
bien « C’est ce que nous voulions mais notre besoin a un peu évolué depuis ! »

La levée tardive des facteu


facteurs à risques : L’impact des risques augmente avec
l’avancement du projet, puisque plus une anomalie est détectée tardivement, plus le
retour arrière est complexe, plus sa correction coûtera cher et plus les effets de bords
seront menaçants.

3.2 Méthode Agile :


Les méthodes précédemment présentées, malgré leur facilité, restent moins efficace
dans un enivrement instable. Ces méthodes se caractérisent par un pilotage basé sur des
plans (plan-driven
driven development
development).
). Et cela, par conséquence, engendre un sentiment
sentim
d’attachement au plan et s’opposer systématiquement à tout changement dans le
périmètre du projet.
Pour faire face aux différents défis d’instabilité, de doute et d’évolution, notamment
dans le cas des besoins qui évoluent en permanence pour répondre aaux changements du
marché. Adapter une approche souple et moins rigide est indispensable (rota, 2008).
Ceci a favorisé l’émergence de nouvelles approches dites « agiles».

20
L’approche agile est un processus populaire pour aligner le développement d’un projet
logiciel en corrélation parfaite avec les besoins des clients. Ce manifeste Agile a été
élaboré par dix-sept leaders de l'industrie du développement de logiciels qui ont mis en
place un processus basé sur leurs succès et leurs échecs dans la gestion de projets de
développement de logiciels. Les dix-sept participants se sont mis d’accord sur les
valeurs suivantes :
- Les individus et leurs interactions plutôt que des outils et des processus ;
- Des fonctionnalités opérationnelles plutôt qu’une documentation abondante ;
- La collaboration avec le client plutôt que la négociation d’un contrat ;
- S’adapter au changement plutôt que suivre un plan.

Le manifeste agile repose sur un ensemble de rôles comprenant:


- Le propriétaire du projet, qui représente le client et clarifie les exigences
- Chef de projet dont le rôle est de soutenir l'équipe de projet
- L'équipe du projet, qui est le groupe qui exécute le projet
- Les parties prenantes, étant toute personne ayant un intérêt dans le projet.

Le processus Agile peut être divisé en sept étapes. Les quatre dernières étapes sont en
fait un cycle, qui sera répété et ne prendra fin que lorsque le projet sera jugé terminé
(Roger Pressman, 2001).

La première étape consiste à identifier la vision du projet. Cette étape est typiquement
réalisée par le propriétaire du projet qui doit définit le projet, la stratégie commerciale
globale, qui bénéficiera du projet et comment cela se produira.

La deuxième étape consiste à construire une feuille de route de projet ou plan de travail
qui sera agile. Cette étape est nécessaire pour que la méthodologie fonctionne. Les
exigences du projet doivent être définies, avec un calendrier. Cependant, tout cela
devrait être considéré comme une estimation approximative, dans le cadre de la
méthode Agile est de s'adapter à la réponse du client.

La troisième étape consiste à créer un plan de livraison. Le plan de livraison consiste


en un calendrier pour les sprints. Les sprints sont des versions itératives du produit /
service construit par l'équipe afin d'obtenir les commentaires des clients. Le plan de
publication devrait indiquer le rythme de la diffusion de ces itérations aux clients pour
obtenir des commentaires.

La quatrième étape consiste à planifier et exécuter chaque sprint. Dans chaque sprint,
les exigences sont classées en fonction du retour client (feedback) et de la feuille de
route originale.

La cinquième étape consiste à tenir des réunions quotidiennes. Ces réunions devraient
durer environ 15 minutes et inclure toute l'équipe du projet à discuter de ce qui a été fait
la veille et de ce qui sera fait ce jour-là. Cela donne aussi l'occasion aux membres de
l'équipe de discuter les obstacles et d'autres problèmes.

La sixième étape consiste à organiser des examens de sprint. Ceux-ci se produisent à la


fin de chaque sprint et consistent à diffuser la nouvelle version du produit / service aux
parties prenantes pour un retour d'information.

21
La septième étape consiste à organiser un sprint rétrospectif. Cette réunion discute du
sprint précédent et identifie ce qui s'est bien passé et ce qui a mal tourné pour améliorer
le sprint suivant

Les avantages:
-Agile offre plus de flexibilité par rapport à d'autres méthodologies, telles que Cascade.
Par exemple, le processus Cascade définit la portée et les caractéristiques avant la
conception et la mise en œuvre. Ces deux caractéristiques sont non négociables.
Contrairement à la méthode Agile, la portée change afin de répondre aux demandes de
l'entreprise. (En cas de non visibilité de l’ensemble du produit et évolution des besoins).

-En outre, la méthodologie Agile fonctionne mieux sur les produits dont les cycles de
réalisation sont plus rapides. Les corrections et les suggestions sont rapidement
partagées avec l'équipe de projet et le propriétaire du projet qui fait ensuite le jugement
final sur la viabilité et l'efficacité des suggestions.

-Lorsque ce type de collaboration se déroule de manière continue, le produit final se


révèle souvent avec moins de défauts. C'est parce que l'assurance qualité est testée tout
au long de chaque cycle. Chaque itération propose un produit ou un service fini. En
conséquence, les défauts sont repérés plus tôt dans le processus.

Les inconvénients
-Agile est vraiment l'une des méthodologies de gestion de projet les plus populaires,
mais il y a des cas où des améliorations peuvent être apportées.

Par exemple, les utilisateurs finaux peuvent faire des suggestions continues qui mettent
en danger la portée du projet. Quand ils voient à quel point il est facile de mettre en
œuvre des changements, à n'importe quelle itération, ils peuvent bientôt devenir
insatiables. Pourquoi se contenter de cette itération alors qu'une autre pourrait être
encore mieux? Cela se résume à la gestion des attentes. Si le chef de projet ne sait pas
comment dire non, le développement peut ne jamais s'arrêter.

-Ensuite, il y a la question de la documentation. L'agilité n'est pas un moyen d'éviter la


documentation, mais elle peut facilement la négliger. L'utilisation d'Agile rend le
développement assez fluide, avec des changements de portée rapides. La
communication se déroule tout au long du projet, mais une grande partie est laissée sans
document.

-Et tenir des réunions de stand-up quotidiennes peut potentiellement nuire aux progrès,
surtout s'ils ne sont pas gérés correctement. Pour la plupart des membres du projet, ces
réunions prennent du temps qui pourrait être utilisé pour faire le travail. Il peut arriver
un moment où les réunions quotidiennes doivent être transférées à des réunions
hebdomadaires ou bihebdomadaires afin qu'ils puissent se concentrer sur le travail à la
place.

22
3.3 Autres approches de développement :

A) Adaptative
La gestion de projet adaptative fait exactement ce que le titre suggère: il s'adapte.
Deux mots clés important pour comprendre cette approche sont : l’adaptation et
l’hybridation.
L’adaptation : L'adaptation de l'approche du projet à l'effort spécifique est un concept
fondamental.
Hybridation : incorporer certains aspects de la méthode traditionnelle dans l’approche
agile.
L’idée de l’approche adaptative repose sur le fait que tout projet peut contenir un
ensemble de variables telles que : stabilité du marché, valeur commerciale, implication
du client, but et clarté de la solution. Ces composants varient considérablement d’un
projet à un autre et d’un client et un autre. Les gestionnaires de projets doivent être prêts
à adapter l’approche du projet adéquate pour assurer un bon ajustement avec l’effort et
les exigences en fonction de la valeur de ces variables.

B) Chemin critique
Chemin critique est une méthode étape par étape qui fonctionne bien pour les projets
qui ont des tâches qui dépendent les uns des autres. Avec le style de gestion du chemin
critique, les activités interdépendantes sont facilement gérées. Le travail peut être
décomposé à l'aide d'une structure qui suit le calendrier nécessaire à l'achèvement de ces
dépendances, de leurs jalons et de leurs livrables.
La gestion de projet de chemin critique est un style qui décrit les activités critiques et
non critiques nécessaires pour le projet en calculant celles qui ont le plus long et le plus
court temps pour accomplir diverses tâches. Ce style de gestion de projet est
couramment utilisé par les scientifiques et les fabricants, car l'accent est mis sur la durée
des tâches.
Cette technique est utilisée pour terminer des projets à temps en se concentrant sur des
tâches clés. Un chemin à travers toutes les tâches interconnectées est le chemin la plus
rapide à prendre lors de l'achèvement de tout projet. En se concentrant sur les tâches qui
constituent le chemin critique, le gestionnaire de projet maximise les chances de
terminer le projet à temps.
L’avantage de la gestion de projet de chemin critique est qu'il aide à identifier la durée
minimale nécessaire pour terminer un projet et identifier les étapes du projet qui doivent
être réalisées d’abord pour terminer le projet dans les délais impartis.
L'inconvénient :
- elle ne prend pas en considération les autres contraintes.
- Mauvaise gestion des tâches non critiques engendre d’autres taches critiques.

23
Chapitre 3 Les éléments de gestion de projet

Introduction
Le processus global de management de projet peut être divisé en cinq grands groupes
de processus : démarrage, planification, exécution, contrôle et clôture. Chacun des 5
groupes de processus fait appel à des connaissances appartenant à neuf (9) domaines
distincts : management de l’intégration, du contenu, des délais, des coûts, de la qualité,
des ressources humaines, des communications, des risques, des approvisionnements
(Boulet, Mai 2006).
Les groupes de processus sont des guides qui aident à appliquer correctement au cours
du projet la connaissance et les compétences en management de projet. Le chef de
projet et son équipe ont la responsabilité de déterminer quels processus, dans les
groupes de processus, seront employés, par qui, et avec quelle rigueur ils seront
exécutés pour réaliser l'objet voulu du projet.
 le groupe de processus de démarrage, qui définit et autorise le projet ou une phase
du projet,
 le groupe de processus de planification, qui définit et affine les objectifs, et planifie
le déroulement des actions requises pour atteindre ces objectifs ainsi que le contenu
pour lequel le projet a été entrepris,
 le groupe de processus d'exécution, qui intègre les personnes et autres ressources
pour exécuter le plan de management du projet,
 le groupe de processus de surveillance et de maîtrise, qui mesure et surveille
régulièrement la progression du projet pour identifier les écarts par rapport au plan
de management du projet, de manière à permettre les actions correctives nécessaires
et à atteindre les objectifs du projet,
 le groupe de processus de clôture, qui formalise l'acceptation du produit, du service
ou du résultat, et qui conclut le projet ou une de ses phases de manière ordonnée.

2. Qu’est-ce qu’un plan de projet ?


Un plan de projet, c'est un document dont on sert pour gérer un projet de technologie de
l'information. C’est une feuille de route qui définit la façon dont le chef de projet va
piloter le projet. Il se base sur le cahier des charges qui sert à formaliser les besoins et
les exigences du client. Le plan de projet présente les objectifs à atteindre, les
différentes phases du projet ainsi que les parties prenantes. Il décrit le budget, le
calendrier et les tâches à exécuter ainsi que le rôle de chaque collaborateur impliqué.

Il décrit :
• les biens que doit livrer le projet tant qu'il n'est pas terminé et lorsqu'il est terminé,
• les processus techniques et de gestion qu'exigent les biens livrables du projet,
• les ressources permettant de fournir les biens livrables du projet,
• les autres plans nécessaires à la réalisation du projet (gestion de risque).

24
3. Pourquoi faut-il un plan de projet ?
Parce que les décisions doivent être fondées et qu'un plan met en évidence les lacunes et
les incohérences. Un plan de projet comporte d'habitude des centaines de petites
décisions contribuant à la clarté du projet. Le plan de projet permet d'informer des
décisions. Il arrive, en effet, que d'autres membres de l'équipe ne soient pas au courant
de ce que nous considérons comme un fait connu de tous. Essentiellement, le
gestionnaire du projet doit veiller à ce que tous les membres du projet monde travaillent
dans la même direction, et, pour cela, la communication est essentielle (Bureau des
technologies d’apprentissage, 2003).

Le plan de projet facilite beaucoup la communication. Un plan de projet, c'est une mine
d'information et une liste de contrôle. L'examen du plan (autant de fois qu'il le faut)
permet au gestionnaire de savoir où en est le projet et de déterminer les correctifs ou les
changements de priorité ou d'orientation nécessaires.

4. Les éléments clés d’un plan de projet :


Un plan de projet doit être pertinent, compréhensible et il comprend l’importance et la
complexité du projet. Le plan inclut essentiellement les éléments suivants (Bureau des
technologies d’apprentissage, 2003):
1. La charte d’un projet
2. Le calendrier d’activités
3. L’horaire de travail
4. La matrice de responsabilités
5. Le budget de plan de projet
6. Les étapes importantes, avec les dates cibles
7. La stratégie de gestion du risque

4.1 La charte d’un projet :


«Document émis par l’initiateur ou le commanditaire du projet, qui en autorise
formellement l’existence et donne autorité au chef de projet pour affecter des
ressources de l’organisation aux activités de ce projet» Guide PMBOK (American
National Standard, 2004).
La charte du projet est un document qui concrétise l’existence du projet. C’est le
témoigne formel de l’accord entre le maitre d’œuvre et le maitre d’ouvrage. Elle est
établie en début de projet, est approuvée par les intervenants. Elle contient
principalement des informations sur les deux organismes, le nom, le but du projet et les
participants. Une fois signée par la haute direction, elle doit être largement diffusée à
tous ceux qui sont concernés par ce projet. Ensuite, elle sera consultée tout au long du
projet. C’est le chef de projet qui doit s’assurer que charte soit élaborée et dûment
approuvée.
La charte du projet identifie, définit et décrit:
• les partenaires et les intervenants;
• le cadre de gestion à appliquer;
• les rôles, responsabilités et activités des principaux membres de l'équipe;

25
• les mécanismes de communications et de contrôle.

4.2 Le calendrier d’activités


Le calendrier d’activités est un calendrier qui illustre toutes les activités et les actions
engendrées par le découpage du projet en mentionnant aussi leur interconnexion.
Concrètement, c’est un diagramme qui représente la répartition des taches dans un axe
de temps, ou on assigne à chaque tache, une durée et une date de début,
On peut préciser la date de début de façon implicite en définissant sa relation avec les
autres taches.
Ce calendrier permet de :
 Offrir une vision précise de l’envergure du projet.
 Permet de savoir précisément ce qui est terminé et ce qui reste à faire.
 permet de suivre de près le travail, les échéances et les coûts associés à chaque
tâche.
 permet de confier la responsabilité de tâches précises aux membres de l’équipe.
 permet aux membres de l’équipe de comprendre leur rôle dans l’ensemble du
tableau.

4.3 L’horaire de travail


L’horaire de travail précis le lien logique entre les activités du projet, assure que le
personnel est disponible au moment approprié et vous aide à gérer le temps de façon
efficace afin de terminer le projet au moment prévu (Stattner, 2013).
Par exemple : pour une tache qui dure 6h, elle nécessite un jour de travail si le
développeur travaille 8h par jour, ou deux jours s’il travaille 4 heure par jours.

4.4 La matrice de responsabilités


Votre projet nécessitera la collaboration d'un grand nombre de personnes et
d'organismes qui travaillent à un but commun. La gestion d’une équipe variée, souvent
dispersée à plusieurs endroits, peut présenter des défis particuliers (Stattner, 2013).
La matrice de responsabilités est un outil précieux de gestion de projet destiné à vous
aider à relever les défis. Une matrice de responsabilités attribue à quelqu’un la
responsabilité de chaque activité principale du projet, évitant ainsi que certains éléments
« échappent à votre surveillance ». Il n’est pas nécessaire qu’elle soit complexe et peut
être facilement réalisée en se rapportant à l’horaire de travail du projet. La matrice de
responsabilité est une matrice ou les colonnes représentent les personnes impliquées et
les lignes, les taches à réaliser. Chaque case dans la matrice contiendra le rôle de chaque
personne dans la réalisation de chaque tache (Tableau 1).

26
Tableau 1 Exemple d’une matrice de responsabilité
Analyste Chef d’equipe Developpeur 1 Concepteur
Planification A R C C
Rédaction C A - C
Développement C A R
Tests A A -
installation C A -
*A : Actif, R : Responsable , C : Commentaire

4.5 Le budget
Il est important d’avoir l’estimation la plus détaillée et la plus précise possible des
principaux coûts du projet (habituellement les salaires, les machines, les logiciels..), dès
le début du projet. Puisque il est plus facile d’estimer le cout d’une tache, le cout global
est calculé en additionnant le cout de chaque tache inclut dans le plan de projet.

4.6 Les étapes importantes, avec les dates cibles


Apres l’établissement d’un calendrier des taches, le chef de projet doit mettre en
évidence les taches cruciales afin que tous les acteurs prennent connaissance et
conscience de leur ampleur et leur importance dans le projet,
Le respect des dates de ces taches permet :

-éviter le gaspillage des ressources


-maintenir l’élan de projet
-gagner plus crédibilité par rapport aux partenaires potentiels

Cette étape inclut principalement la définition de :


- Les taches critiques
- Les jalons
- Les échéances.

4.7 La stratégie de gestion de risque


Tout projet de développement, de rénovation ou d’évolution d’un système
d’informatique, présente un potentiel de risque interne ou externe qui auront des effets
négatifs qui peuvent menacer le projet, le logiciel en cours de développement ou
l'organisation (Roger Pressman, 2001).

Le « risque » désigne une condition ou un événement incertain ayant une cause et,
lorsqu’il se produit, a un effet négatif sur les objectifs du projet ainsi qu’une incidence
sur les coûts, l’échéancier ou la qualité du projet.
Un chef de projet doit toujours chercher à anticiper en établissant des stratégies de
gestion des risques. Pour la simple raison que les actions de prévention coutent moins
cher que des actions de réparation.

Il n’est pas toujours aisé d’exercer un véritable « pilotage de projet par les risques »,
mais il est recommandé d’effectuer un pilotage du projet en intégrant un traitement des
risques. Autrement dit, on ne va pas établir notre plan en fonction des risques qui
peuvent ne pas arrivés mais il est recommandé d’établir un traitement des risques.
27
Il existe plusieurs façons et facteurs pour classifier les risques dans un projet, parmi les
classifications on trouve classification par rapport à l’entité affectée :

 Risques liés au projet : Risques qui affectent le calendrier ou les ressources du


projet.

Par exemple : La perte d'un concepteur expérimenté est un exemple de risque lié au
projet. Trouver un concepteur de remplacement possédant les compétences et
l'expérience appropriées peut prendre un certain temps et, par conséquent, la conception
du logiciel prendra plus de temps.

 Risques liés au produit: Risques qui affectent la qualité ou les performances du


logiciel en cours de développement.

Par exemple : Un exemple de risque produit est l’incapacité d’un composant acheté de
fonctionner comme prévu. Cela peut affecter les performances globales du système, de
sorte qu'il est plus lent que prévu

 Risques commerciaux : Risques qui affectent l'organisation en développement ou en


acquisition du logiciel.

Par exemple : L’introduction d’un produit concurrentiel peut signifier que les
hypothèses retenues sur les ventes de logiciels existants peuvent être excessivement
optimistes.

Bien entendu, ces types de risques se chevauchent. Si un programmeur expérimenté


quitte un projet, cela peut être un risque car, même s'il est immédiatement remplacé, le
planning sera affecté. Il faut inévitablement un certain temps pour qu'un nouveau
membre du projet comprenne le travail qui a été effectué et ne peut donc pas être
immédiatement productif.

Par conséquent, la livraison du système peut être retardée. La perte d'un membre de
l'équipe peut également être un risque produit car un remplaçant peut ne pas être aussi
expérimenté et donc écrire un code plein d’erreurs. Enfin, cela peut être un risque pour
l’entreprise, car l’expérience de ce programmeur peut être cruciale pour remporter de
nouveaux contrats.

Le processus de gestion de risque comporte principalement les étapes suivantes


(Figure3) (Roger Pressman, 2001) :
1. Identification des risques : Identifier les risques liés au projet, au produit et à
l'entreprise.
2. Analyse des risques : Evaluer la probabilité et les conséquences de ces risques.
3. Planification des risques : Elaborer des plans pour faire face aux risques, soit en les
évitant, soit en minimisant leurs effets sur le projet.
4. Surveillance des risques : Evaluer régulièrement les risques et les plans d'atténuation
des risques et les réviser lorsque vous en saurez plus sur les risques.

28
Figure 3 Processus de gestion de risques
Les informations collectées en cours de ces étapes sont documentées dans un document
qu’on appelle plan de gestion des risques Cela devrait inclure : une discussion sur les
risques encourus par le projet, une analyse de ces risques et des informations sur la
manière dont vous proposez de gérer le risque si cela semble susceptible de poser
problème.
Il faut savoir que la gestion des risques est un processus itératif qui se poursuit tout au
long du projet:
Une fois que vous avez établi un plan initial de gestion des risques, vous surveillez la
situation pour détecter les risques émergents. Si d‘ autres informations sur les risques
deviennent disponibles, vous devez les analyser à nouveau et décider si la priorité du
risque a changé.

A. Identification de risque
L’identification des risques est la première étape du processus de gestion des risques. Il
s'agit d'identifier les risques pouvant constituer une menace majeure pour le processus
de développement, le logiciel en cours de développement ou l'organisation de
développement. L'identification des risques peut être un processus d'équipe où une
équipe se réunit pour réfléchir aux risques possibles. Alternativement, le chef de projet
peut simplement utiliser son expérience pour identifier les risques les plus probables ou
les plus critiques.
Une liste de contrôle des différents types de risques peut être utilisée comme point de
départ pour l’identification des risques. Au moins cinq types de risques peuvent être
inclus dans une liste de contrôle des risques:

 Risques technologiques : Risques liés aux technologies logicielles ou matérielles


utilisées pour développer le système.

 Risques liés aux personnes Risques associés aux membres de l'équipe de


développement.

 Risques organisationnels : Risques provenant de l'environnement


organisationnel dans lequel le logiciel est en cours de développement.

 Risques liés aux exigences : Les risques résultant de modifications des exigences
du client et du processus de gestion de ses derniers changements.

 Risques d'estimation : Risques découlant des estimations de la direction des


ressources nécessaires à la mise en place du système.

29
B. Analyse
Au cours du processus d'analyse des risques, vous devez prendre en compte chaque
risque identifié et émettre un jugement sur la probabilité et la gravité de ce risque. Il n'y
a pas de moyen facile de faire cela. Vous devez vous fier à votre propre jugement et à
votre expérience des projets précédents et des problèmes qui y ont surgi (Durand, 2004).

 La gravité représente l’ampleur des conséquences sur le déroulement du projet et


le coût nécessaire pour une réparation ou une solution de remplacement (plan de
correction).

 La probabilité représente le facteur de certitude d’apparition du risque, en


fonction des facteurs de risques et de la situation globale du projet

C. Planification
Le processus de planification des risques prend en compte chacun des principaux
risques identifiés et élabore des stratégies pour gérer ces risques. Pour chacun des
risques, vous devez penser aux actions que vous pourriez entreprendre pour minimiser
les perturbations du projet si le problème identifié dans le risque se produit. Vous devez
également penser aux informations que vous devrez peut-être collecter lors du suivi de
projet afin de pouvoir anticiper les problèmes (Jean Yves Moine, 2012).

Encore une fois, aucun processus simple ne peut être suivi pour la planification
d’urgence. Il s’appuie sur le jugement et l’expérience du chef de projet.
Il existe trois types d’action :

1- Suivre ces stratégies signifie que la probabilité que le risque survienne sera réduite.

2-Suivre ces stratégies signifie que l'impact du risque sera réduit.

3-Plans d'urgence Si vous suivez ces stratégies, vous êtes prêt à faire face au pire et à
mettre en place une stratégie pour y faire face.

De toute évidence, il est préférable d’utiliser une stratégie qui évite les risques. Si cela
n'est pas possible, vous devez utiliser une stratégie qui réduit les effets.

D. Contrôler et suivre
Vous devez évaluer régulièrement chacun des risques identifiés pour décider si ce
risque devient plus ou moins probable. Vous devez également vous demander si les
effets du risque ont changé ou non. Pour ce faire, vous devez examiner d'autres facteurs,
tels que le nombre de demandes de modification des exigences, qui vous fournissent des
indices sur la probabilité de risque et ses effets. Ces facteurs dépendent évidemment des
types de risque.

30
Série de TD 1 : Introduction

Exercice 1 :

1. Quelles sont les trois contraintes fondamentales d’un projet?

2. Indiquer pour les phases de développement suivantes les documents qu’elles


génèrent : spécification des besoins, conception, validation et intégration et
implémentation.

3. Quelle est la différence entre un projet et une production ?

4. Discutez les principales différences entre le développement itératif et le


développement incrémental.

5. C’est quoi la différence entre la validation et la vérification.

Exercice 2 :

Choisissez la bonne réponse :

1. Parmi les qualificatifs suivants, sélectionnez celui qui est incompatible avec la notion
de projet :
a) original
b) singulier
c) autonome
d) permanent
e) novateur
f) complexe
g) évolutif

2. La caractéristique essentielle d'un projet est d'avoir un début et une fin :


a) vrai
b) faux

3. Les modifications qui surviennent au cours d'un projet sont toujours la conséquence
d'une mauvaise estimation ou d'une mauvaise gestion :
a) vrai
b) faux

4. Au sens du management de projet, on appelle une œuvre :


a) l'ensemble des actions réalisées au cours du projet
b) la méthode utilisée pour réaliser le projet
c) un élément matériel constitutif du projet
d) l'objet physique ou intellectuel du projet

5. Dans la réalisation d'un projet, le maître d'ouvrage est celui qui :


a) définit le cahier des charges d'ouvrage

31
b) est responsable de la coordination des intervenants
c) assure les études de conception
d) dirige le chantier de construction de l'ouvrage

6. La première étape de la planification consiste à :


a) définir les jalons du projet
b) établir l'organigramme des tâches
c) tracer la logique d'enchaînement des tâches
d) choisir les systèmes outils de contrôle

7. Les tests d’intégration :


a) Ne peuvent être fait correctement que si les tests unitaires ont été faits correctement.
b) Remplacent les tests unitaires.
c) Sont incompatibles avec les tests unitaires.
d) Se font avant les tests unitaires.

Exercice 3 :
Donner le type de risque qui correspond à chacun des risques suivants :

Risque Description Type


Changement du personnel Un personnel expérimenté
quittera le projet avant la fin.
changement de direction Il y aura un changement de
gestion organisationnelle avec
des priorités différentes.
Indisponibilité du matériel Le matériel essentiel au projet
ne sera pas livré dans les
délais
Modification des exigences Les modifications apportées
aux exigences seront plus
nombreuses que prévu
Délais de spécification Des spécifications essentielles
ne sont pas disponibles dans
les délais.
Taille sous-estimée La taille du système a été
sous-estimée
Sous-performance des outils Les outils de production ne
fonctionnent pas comme
prévu.

Changement technologique La technologie sur laquelle le


système est construit est
remplacée par la nouvelle
technologie
Concurrence entre produits Un produit concurrent est
commercialisé avant la
finalisation du système

32
Série de TD 1 : Introduction (Corrigé)

Exercice 2 :

Choisissez la bonne réponse :

1. Parmi les qualificatifs suivants, sélectionnez celui qui est incompatible avec la notion
de projet :
a) original
b) singulier
c) autonome
d) permanent
e) novateur
f) complexe
g) évolutif

2. La caractéristique essentielle d'un projet est d'avoir un début et une fin :


a) vrai
b) faux

3. Les modifications qui surviennent au cours d'un projet sont toujours la conséquence
d'une mauvaise estimation ou d'une mauvaise gestion :
a) vrai
b) faux

4. Au sens du management de projet, on appelle une œuvre :


a) l'ensemble des actions réalisées au cours du projet
b) la méthode utilisée pour réaliser le projet
c) un élément matériel constitutif du projet
d) l'objet physique ou intellectuel du projet

5. Dans la réalisation d'un projet, le maître d'ouvrage est celui qui :


a) définit le cahier des charges d'ouvrage
b) est responsable de la coordination des intervenants
c) assure les études de conception
d) dirige le chantier de construction de l'ouvrage

6. La première étape de la planification consiste à :


a) définir les jalons du projet
b) établir l'organigramme des tâches
c) tracer la logique d'enchaînement des tâches
d) choisir les systèmes outils de contrôle

7. Les tests d’intégration :


a) Ne peuvent être fait correctement que si les tests unitaires ont été faits correctement.
b) Remplacent les tests unitaires.
c) Sont incompatibles avec les tests unitaires.
d) Se font avant les tests unitaires.

33
Exercice 3 :
Donner le type de risque qui correspond à chacun des risques suivants :

Risque Description Type


Changement du personnel Un personnel expérimenté Risque lié au personnel
quittera le projet avant la
fin.
changement de direction Il y aura un changement de Risque lié à l’organisation
gestion organisationnelle
avec des priorités
différentes.
Indisponibilité du matériel Le matériel essentiel au Risque lié à l’estimation
projet ne sera pas livré dans
les délais
Modification des exigences Les modifications apportées Risque lié aux exigences
aux exigences seront plus
nombreuses que prévu
Délais de spécification Des spécifications Risque lié à l’estimation
essentielles ne sont pas
disponibles dans les délais.
Taille sous-estimée La taille du système a été Risque lié à l’estimation
sous-estimée
Sous-performance des Les outils de production ne Risque lié à la technologie
outils fonctionnent pas comme
prévu.

Changement technologique La technologie sur laquelle Risque lié à la technologie


le système est construit est
remplacée par la nouvelle
technologie
Concurrence entre produits Un produit concurrent est Risque lié à l’estimation
commercialisé avant la
finalisation du système

34
35
Chapitre 4 : L’organisation des équipes de programmation

Introduction

« Trouver le meilleure cadre de travail en termes d’organisation et de la bonne


combinaison entre les compétences de l’équipe de développement est une tâche
vraiment difficile, d’autant plus que peu de théorie efficace sont disponible pour cet
objectif. Cependant, de nombreuses histoires de projets réussis et moins réussis
discernent certaines complexités pour gérer l'équipe de projet. » People are the
organization’s most important asset (Humphrey, 1997a)

Dans la plupart des organisations qui développent des logiciels : les programmeurs, les
analystes et autres professionnels travaillent ensemble en équipe. Cependant, la
formation d’une équipe de travail adéquate dépend de plusieurs facteurs tel que le
nombre de personnes impliquées, leur expérience, leur implication dans le projet, le
type de projet. Ces facteurs influencent également la façon dont les projets doivent être
gérés.

Le travail à effectuer dans le cadre d'un projet, qu'il s'agisse d'un projet de
développement de logiciel, de la construction d'une maison ou de la conception d'une
nouvelle voiture, implique un certain nombre de tâches. Une partie critique de la
responsabilité de gestionnaire est de coordonner les tâches de tous les participants. Cette
coordination peut être réalisée de plusieurs façons suivant deux types de facteurs qui
s'appliquent sur le mécanisme de coordination. Les facteurs internes proviennent à partir
des caractéristiques du projet. Les facteurs externes proviennent des environnements
organisationnels du projet.

2. L’analyse organisationnelle du projet


La plupart des projets se déroulent dans un cadre organisationnel où ils coexistent avec
d’autres projets ou d’autres activités à l’intérieur de l’entreprise, Ces projets se trouvent
fréquemment en concurrence pour l’affectation des ressources et pour l’exercice de
l’autorité hiérarchique. Les contraintes posées par une telle situation varient selon la
structure que l’organisation ou l’entreprise s’est donnée. En effet, cette forme détermine
en grande partie la nature des liens entre le projet et les autres composantes de
l’organisation. Il existe plusieurs façons de présenter les organisations (Durand, 2004) :
 Structure hiérarchique
 Structure fonctionnelle

36
2.1 Structure hiérarchique
Le principe de la structure hiérarchique est que chaque
haque individu est responsable de tous
ceux qui sont placés au au-dessous
dessous de lui. Chacun des exécutants ne connaît qu'un seul
chef (Figure 4).. L'autorité et la responsabilité se trouvent divisées entre divers ser
services.
Dans ce genre d’organisation le chef de projet, ggère ère une équipe assurant une fonction
précise de l’entreprise au quotidien
quotidien. Il a une autorité directe sur ses collaborateurs.
collaborateurs

Figure 4 Exemple d’une structure hiérarchique

2.2 Structure fonctionnelle


Cette structure est issue des besoins en compétences nécessaires à la réalisation des
activités du cycle de vie de production des livrables
livrables.. La structure fonctionnelle est la
forme de structure
ture la plus ancienne et la plus répandue pour diviser une entreprise en
plusieurs fonctions de travail générales et strictement séparées. Cela signifie, par
exemple, que tous les responsables marketing sont regroupés dans un département
marketing, tous les développeurs dans le département production (Figure 5).

Figure 5 Exemple d’une structure fonctionnelle

37
3. Les aspects de gestion de personnel
Pour bien gérer son équipe, le chef de projet doit maitriser certain aspects comme
(Vliet, 2007) :

3.1 Divergence d’objectif


Une équipe est composée de personnes, dont chacune a des objectifs personnels. C'est la
tâche de la gestion de projet de former une équipe d'individus, où les objectifs
individuels sont réconciliés dans un objectif commun pour la totalité du projet.
Il est important d'identifier les objectifs du projet à la phase d’étude et de les
communiquer sans ambiguïté aux membres du projet. Les membres du projet doivent
savoir ce que l'on attend d'eux. S'il y a une incertitude à cet égard, les membres de
l'équipe détermineront leurs propres objectifs ce qui laisse place aux conflits. Par
exemple, Un programmeur peut décider que l’ergonomie est la plus prioritaire, un autre
peut choisir l'utilisation efficace de la mémoire, alors qu'un troisième décidera que
l'écriture de beaucoup de code est ce qui compte. Des objectifs aussi divergents peuvent
entraîner des graves problèmes.

3.2 Productivité
Une fois que les objectifs du projet sont établis et que le projet est en cours, le
rendement des membres du projet par rapport aux objectifs du projet doit être surveillés
et évalués. Cela peut être difficile, car une grande partie de ce qui est fait, est invisible
et le progrès est difficile à mesurer.
La productivité est définie comme la quantité de fonctionnalités livrées par unité de
temps. Dans le domaine de développement logiciel, la productivité est principalement
définie comme le nombre de lignes de code livrées par homme-mois. Cependant, cette
mesure n'est pas optimale, elle encourage les gens à écrire plus de code et décourage la
réutilisation du code existant. Une autre alternative consiste à découper le projet en
plusieurs fonctions. Ensuite attribuer des points à chaque fonction selon sa difficulté.
Dans ce cas, la productivité est le nombre de points achevés en réalisant des fonctions
dans une unité de temps.

3.3 Evaluation du travail


Un autre aspect de l'évaluation des personnes se produit dans les processus de groupe
tels que les examens par paires, les inspections et les contrôles. Ces techniques sont
utilisées lors des activités de vérification et de validation, pour découvrir des erreurs ou
évaluer la qualité du code et la qualité de la documentation. Afin de rendre ces
processus efficaces, il est nécessaire de séparer clairement les livrables à évaluer de
leurs auteurs (egoless).

3.4 Coordination et communication


L'un des problèmes majeurs dans le développement de logiciels est la coordination des
activités des membres de l'équipe. À mesure que les projets de développement prennent
de l'ampleur et deviennent plus complexes, les problèmes de coordination s'accumulent
rapidement. Pour contrer ces problèmes, la direction doit formaliser la communication,

38
et cela en organisant des réunions formelles, des inspections strictement surveillées et
mettre en place un comité de contrôle. Cependant, la communication informelle et
interpersonnelle est connue pour être un moyen primaire par lequel l'information circule
dans et à travers une organisation de développement. Pour cela, il est imprudent
d'exclure totalement ce type de communication.

En revanche, les gens ont tendance à échanger la facilité avec laquelle l'information
peut être obtenue contre sa qualité. Ils accepteront facilement les conseils de leurs
voisins, même s'ils savent que de meilleurs conseils peuvent être trouvés à l'étage
suivant. Pour éviter cela, il est sage de rassembler diverses parties prenantes de manière
contrôlée, par exemple en faisant appel à des experts du domaine dans l'équipe de
conception, en demandant aux utilisateurs de tester les logiciels ou en adoptant des
approches de conception participatives.

Dans ce contexte, Mintzberg (MINTZBERG, 1987) distingue cinq types de mécanismes


de coordination qui servent à coordonner les tâches à effectuer au sein d’une
organisation. Les mécanismes de coordination associés sont les suivants:

a- Simple structure : Dans une structure simple, il peut y avoir un ou quelques


gestionnaires, et des personnes qui font le travail. Le mécanisme de coordination
correspondant est appelé supervision directe. Cette configuration est souvent trouvée
dans de nouvelles organisations relativement petites. Il y a peu de spécialisation, de
formation et de formalisation. La coordination repose sur des personnes distinctes,
responsables du travail des autres.

b- La bureaucratie mécanique : Lorsque le contenu du travail est complètement


spécifié, il devient possible d'exécuter et d'évaluer les tâches sur la base d'instructions
précises. Les lignes de production de masse et d'assemblage sont des exemples typiques
de ce type de configuration. Il y a peu de formation et beaucoup de spécialisation et de
formalisation. La coordination est réalisée par la standardisation des processus de
travail.

c- Forme divisée : Dans ce type de configuration, chaque division (ou projet) bénéficie
d'une autonomie considérable quant à la manière d'atteindre les objectifs fixés. Les
détails de fonctionnement sont laissés à la division elle-même. La coordination est
assurée par la normalisation des résultats du travail. Le contrôle est exécuté en mesurant
régulièrement la performance de la division. Ce mécanisme de coordination n'est
possible que lorsque le résultat final est spécifié avec précision.

d- La bureaucratie professionnelle : S'il n'est pas possible de spécifier le résultat final


ou le contenu du travail, la coordination peut être réalisée par la standardisation des
compétences des travailleurs. Dans une bureaucratie professionnelle, les professionnels
qualifiés sont une très grande liberté quant à la façon dont ils effectuent leur travail. Les
hôpitaux sont des exemples typiques de ce type de configuration.

e- L’ajustement mutuel : Dans les projets de grande envergure ou novateurs, le travail


est réparti entre de nombreux spécialistes. Nous ne sommes peut-être pas en mesure de
dire exactement ce que chaque spécialiste doit faire, ou comment il doit exécuter les
tâches qui lui sont assignées. Le succès du projet dépend de la capacité du groupe dans

39
son ensemble à atteindre un objectif non spécifié d'une manière non spécifiée. La
coordination est réalisée grâce à un ajustement mutuel.

4. L’organisation d’une équipe


Au sein d'une équipe,
ipe, différents rôles peuvent être distingués. Il y a des gestionnaires,
des testeurs, des concepteurs, des programmeurs et ainsi de suite. Selon la taille du
projet, plus d'un rôle peut être joué par une personne ou différentes personnes peuvent
jouer le même rôle. Les responsabilités et les tâches de chacun de ces rôles doivent être
définies avec précision dans le plan de projet (matrice des responsabilités).

Les gens coopèrent au sein d'une équipe afin d'obtenir un résultat optimal. Pourtant, il
est conseillé
seillé de séparer strictement certains rôles. C'est une bonne idée de créer une
équipe de test indépendante de l'équipe de développement. De même, l'assurance qualité
devrait, en principe, être menée par des personnes qui ne sont pas directement
impliquées dans le processus de développement.

De plus, les grandes équipes sont difficiles à gérer et sont donc souvent divisées en
équipes plus petites. En définissant clairement les tâches et les responsabilités des
différentes sous-équipes,
équipes, la communication peu peutt se limiter en grande partie à la
communication entre les membres d'une même sous sous-équipe.
équipe. Quantifier le coût de la
communication interpersonnelle donne un aperçu des effets de la taille de l'équipe sur la
productivité et aide à structurer efficacement les grandes équipes de développement.
Dans les sous-sections
sections suivantes, nous discutons quelques formes organisationnelles
pour les équipes de développement de logiciels (Vliet, 2007).

4.1
.1 Organisation hiérarchique
Dans un environnement entièrement dédié à la production de logiciels, nous rencontrons
souvent des structures hiérarchiques d'équipes. Selon la taille de l'organisation ou du
projet, différents niveaux de gestion peuvent être distingués.
La figure 6 donne un exemp
exemplele d'organisation hiérarchique. Les rectangles désignent les
différentes sous-équipes
équipes dans lesquelles le travail est effectué. Les nœuds désignent les
gestionnaires. Dans cet exemple, deux niveaux de gestion peuvent être distingués. Au
niveau inférieur, différentes
fférentes équipes sont responsables de différentes parties du projet.

Figure 6 Exemple d’une organisation hiérarchique de développement logiciel

40
Les gestionnaires de ce niveau ont la responsabilité principale de coordonner le travail
au sein de leurs équipes respectives. Dans un niveau plus élevé, on trouve les
gestionnaires ou les responsables qui ont comme mission de coordonner le travail de
l’ensemble d’équipes.
Un point critique dans toute organisation hiérarchique est la distance entre le haut et le
bas de la pyramide hiérarchique. Le «vrai» travail se fait généralement aux niveaux
inférieurs de cette pyramide. Les gens à ces niveaux inférieurs possèdent généralement
la connaissance réelle de l'application. Plus la hiérarchie monte dans la hiérarchie,
moins la connaissance devient spécifique. Pourtant, la plupart des décisions sont prises
à un niveau assez élevé.

Si l'information s'infiltre à travers les différents niveaux de la hiérarchie, elle tend à


devenir de plus en plus rose. Le scénario suivant n'est pas entièrement fictif:
- en bas: nous avons de sérieux problèmes à implémenter le module X;
- niveau 1: il y a quelques problèmes avec le module X;
- niveau 2: les progrès sont réguliers, je ne prévois aucun problème réel;
- top: tout se déroule selon notre plan.

Ces types de distorsion sont renforcés par le fait que la ligne organisationnelle sur
laquelle les progrès sont spécifiés est aussi la ligne sur laquelle la performance des
membres de l'équipe est mesurée et évaluée. Si les données sur les progrès d'un projet
sont recueillies et traitées par des personnes qui ne sont pas directement impliquées dans
l'évaluation des membres de l'équipe, vous avez beaucoup plus de chances que les
informations recueillies soient suffisamment fiables.

Un aspect également problématique des organisations hiérarchiques réside dans le fait


que l'on est jugé, socialement et financièrement, selon le niveau auquel on se situe au
sein de l'organisation. Il est donc naturel d'aspirer à des niveaux de plus en plus élevés
dans la hiérarchie. Cependant, il n'est pas du tout clair que cela soit souhaitable. Un bon
programmeur n'a pas forcement un bon manager. Il semble plus sage de maintenir les
gens à un niveau auquel ils se comportent bien et de les récompenser.

4.2 Organisation matricielle


Dans un environnement où le logiciel est un simple produit, nous rencontrons souvent
une sorte d'organisation matricielle (Jean Yves Moine, 2012). Il s’agit d’affecter des
personnes de différents départements à un projet ou plusieurs projets de développement
logiciel à temps partiel. L'unité de base est donc un petit groupe spécialisé (Il peut y
avoir plus d'une unité avec la même spécialisation) ou juste une seule personne
spécialisée. Parmi les spécialisations possibles développement logiciel on trouve :
programmation graphique, bases de données, interfaces utilisateur, contrôle qualité. Les
projets peuvent impliquer des unités avec des spécialités différentes et une seule
spécialité peut être sollicitée dans la réalisation de plusieurs projets. L’affectation des
individus est représentée par une matrice à deux dimensions, la première dimension
représente les différents groupes et spécialités tandis que la deuxième est dédiée pour
les projets auxquels ils sont affectés.
Dans ce type d'organisation, il est parfois difficile de contrôler le progrès à cause de la
disponibilité de personnels et leur niveau d’implication. Dans une telle situation, le chef
de projet doit élargir les connaissances et les compétences des membres de son équipe.

41
4.3 Équipe du programmeur en chef
Vers les années 70, Harlan Mills proposa une organisation d'équipe connue sous le nom
d'équipe de programmeurs en chef. Le noyau d'une telle équipe se compose de trois
personnes. Le programmeur en chef qui est le chef d'équipe ; il prend en charge la
conception et implémente les parties clés du système. Le programmeur en chef a un
assistant qui peut remplacer le programmeur en chef, si nécessaire. La troisième
personne, un bibliothécaire s'occupe de l'administration et de la documentation. Outre
ces trois personnes, un nombre supplémentaire d'experts peut être ajouté à l'équipe du
programmeur en chef.
Dans ce type d'organisation, des exigences assez élevées sont imposées au programmeur
en chef. Le programmeur en chef doit être très compétent dans le domaine technique,
mais il doit aussi avoir des capacités de gestion suffisantes. Cela ressemble à une
équipe de chirurgiens qui réalise des tâches hautement spécialisées et un leadership
charismatique.

4.4 Equipe SWAT


Dans les projets avec un modèle de processus évolutif ou itératif tel que RAD, une
organisation de projet connue sous le nom d'équipe SWAT est parfois utilisée. SWAT
signifie Skilled With Advanced Tools. Nous pouvons considérer l'équipe SWAT
comme une équipe de projet dans laquelle la direction des tâches et des relations est
élevée.
Une équipe SWAT est relativement petite. Elle a généralement quatre ou cinq membres.
De préférence, l'équipe occupe la même pièce. Les canaux de communication sont
maintenus très courts. L'équipe n'a pas de longues réunions formelles avec des procès-
verbaux formels. Au lieu de cela, elle utilise des ateliers et des sessions de
brainstorming .afin de récolter d'idées originales.

Le travail des membres de l'équipe est soutenu et coordonné par un logiciel de


groupware ou de gestion de workflow. Comme dans l'équipe des programmeurs en chef,
le chef d'une équipe SWAT est à la fois un manager et un collègue. Les membres d'une
équipe SWAT sont des généralistes. Ils peuvent avoir certaines spécialités, mais ils
doivent aussi être capables de faire une variété de tâches, comme participer à un atelier
avec les clients, construire un prototype et de tester un logiciel.

4.5 Une équipe agile


Une équipe agile a beaucoup en commun avec une équipe SWAT: co-localisée, canaux
de communication courts, une attitude axée sur les gens plutôt qu’une approche
formaliste.
Dans une équipe agile :
- Les gens travaillent deux par deux, un pilote et un copilote, mais sans hiérarchie.
- Les équipes agiles sont auto gérées.
- Si une paire de programmeurs développe du code et que les tests échouent, ils
doivent prendre du recul et refaire leur travail.
- une équipe agile a besoin de personnels compétant par rapport à une équipe
basée sur la planification.
Dans une approche basée sur la planification, le plan fonctionne comme un gilet de
sauvetage. Dans une équipe agile, aucun gilet de sauvetage n'est disponible, et les gens
doivent avoir des compétences de natation.

42
4.6 Développement de logiciels Open Source
Le développement de logiciel open source est souvent considéré comme une entreprise
sans mur, ni frontière, l’équipe open source est composée de :

L'équipe de base : elle se compose d'une petite équipe de développeurs expérimentés


qui agit également en tant qu'équipe de gestion. Les changements dans les composants
du noyau du logiciel ne peuvent être effectués que par les membres de l'équipe de base.

Les co-développeurs : ils sont un groupe plus important de personnes entourant l'équipe
de base. Les co-développeurs examinent le code et corrigent des bugs.

Les utilisateurs actifs sont les utilisateurs de la version la plus récente du système. Ils
soumettent des rapports de bugs et des demandes de fonctionnalités, mais ne participe
pas à la programmation du système.

Les utilisateurs passifs : c’est les utilisateurs de la version stables du logiciel. Ils
n'interagissent pas avec les développeurs.

Le caractère volontaire du développement open source soulève des défis spécifiques:


- Motivation pour rester actif
- Désaccord entre les développeurs
-Communication entre les développeurs

43
Série TD 2 : Gestion des personnes et organisation de l’équipe

Exercice 1 :
Proposez votre propre organisation pour gérer :
- Un projet très complexe au volume d’information très important.
- Un système d’information

Exercice 2 :
Soit un représentant de 5000 lignes de code dans un langage machine ou 1500 lignes
dans un langage évolué (pascal,..)
- L’analyse, la conception et la documentation prend 10 semaines.
- La programmation en langage machine prend 8 semaines
- La programmation en langage évolué prend 4 semaines
- Le test pour le langage machine prend 10 semaines
- Le test pour le langage évolué prend 6 semaines.

1. Déduire la durée du projet pour chaque langage


2. Calculer la productivité de développement pour chaque type de langage
3. Comparer les résultats, que peut-on conclure.

Exercice 3 :
A partir des données suivantes, calculez la productivité du programmeur en LOC/j.
On suppose en outre que :
- Le projet 1 contenait 120 LOC et le projet 2 en contenait 80 ;
- Les réunions ne sont pas comptabilisées pour le calcul de la productivité

44
Série TD 2 : Gestion des personnes et organisation de l’équipe (corrigé)

Exercice 1 :

Proposez votre propre organisation pour gérer :


- Un projet très complexe au volume d’information très important.

- Un système d’information

La fonction de « réalisation du système » qui a la charge de produire les livrables.


• le support « qualité » qui va mettre en place les règles de fonctionnement et veiller à
l’application de celles-ci tout au long du projet avec la recherche de la plus grande
efficacité.

45
• le support « budget » qui doit distribuer et contrôler les coûts de réalisation en cours et
prévisionnels. Ces coûts seront calculés suivant les consommations et le reste à faire.
La « direction technique » qui assure la production proprement dite des livrables
composés de logiciels et de matériels à travers les fonctions de réalisation (réalisation en
sous-projets). Ces fonctions de réalisation sont elles-mêmes découpées en fonction
élémentaires.
• La « formation » qui a en charge la préparation de l’arrivée du nouveau système dans
les services utilisateurs.
• La fonction « administration projet » qui établit et contrôle le planning et le suivi de
l’avancement. Elle fait remonter les données de production aux fonctions de niveaux
supérieurs.
• La fonction « assistance » qui couvre tous les travaux de gestion du dossier projet et de
secrétariat au bénéfice de l’équipe de réalisation.

Exercice 2 :
1- Durée de chaque projet :
a. Durée projet en langage machine = 10 semaines + 8 semaines+ 10
semaines

= 28 semaines
b. Durée projet en langage évolué = 10 semaines + 6 semaines + 4
semaines
= 20 semaines
2- Productivité :
a. Productivité en langage machine = 5000 / 8 = 625 loc/semaine
b. Productivité en langage évolué = 1500 / 4 = 375 loc/semaine
3- On remarque que selon les calcules, la programmation en utilisant langage
machine est plus productive, ce qui pénalise la réutilisation du code et nouvelles
technologies. La solution est l’utilisation de d’autres métriques telles que point
de fonction.

Exercice 3 :
Mesure de productivité :
Nombre d’heurs du projet 1 = 14.5 h
Nombre de LOCs du projet1 = 120 LOC
Nombre d’heurs du projet 2 = 11.5 h
Nombre de LOC du projet 2 = 80 LOC
Nombre total d’heurs pour les deux projets = 14.5+11.5=26 h
Nombre totale d’heurs équivalent en jours travaillés = 26h/8 = 3.25 jours
Nombre total de LOCs pour les deux projets = 14.5+11.5 = 120+80 = 200 LOC
Productivité du projet = 200/4.25 = 61.53 LOC/J

46
Chapitre 5 : Le processus de planification

Introduction

La réalisation d’un projet quelque soit sa nature nécessite l’établissement d’un plan qui
vise à décrire, de façon plus au moins détaillée, le chemin qui mène à son achèvement,
en respectant les exigences de client, les ressource disponibles, les normes et standards
de qualité. La planification est définie comme l’étape ou l’élément clé pour réussir un
projet. Elle représente la vision du chef de projet, un plan de vol, un plan de route, pour
facilité l’estimation de la durée, l’affectation des ressources, la gestion des risques.
C’est un tableau de bord pour le suivi et le contrôle de la réalisation et la qualité finale
du produit. Sans planifications, on risque d’exécuter des taches cruciales dans l’ombre.
La planification malgré qu’elle soit une estimation initiale est souvent considérée
comme un engagement. En effet, à partir de son estimation initiale, le chef de projet
engage son équipe, son organisation, son client et lui-même sur un cout estimé et une
date probable de livraison.

2. Définition de la planification
Par définition une planification est une organisation des taches dans le temps pour la
réalisation d’objectifs dans un domaine précis, avec les différents moyens mis en œuvre
et sur une durée (et des étapes) précise(s).
Les caractéristique principale de la planification est la dimension temps mais on peut
également optimiser des éléments et des ressources sans utiliser la notion de temps ou
de la durée. Par exemple, on peut optimiser l’espace pour mettre le maximum nombre
de cartons dans un camion. Cependant, la notion de planification est souvent
indissociable de la notion du temps. C’est souvent une liste des choses à faire qui se
concrétise par un plan répondant de façon détaillée et concrète aux principaux aspects
opérationnels du type QQOQCC : qui, quoi, ou, quand, comment, combien. Qui répond
a tous les questions liée au projet.
Le plan peut faire partie d’une stratégie, la notion de stratégie est plus générale,
permanente et moins détaillée, on parle toutefois de planification stratégique lorsqu’une
stratégie est particulièrement concrète et précise. (rota, 2008)
Plusieurs notions sont directement ou indirectement liées à la planification tel que :
 L’analyse : on fait une étude sur ce qui existe, des études sur les objectifs, les
contraintes.
 La prévision
 Le budget : la planification permet d’avoir une valeur proche du cout réel.
 Les scénarios : on énumère les différentes solutions possibles pour mettre en
œuvre ce projet.
 Les probabilités : on essaie d’identifier les risques et leur probabilité.

47
La planification est la tâche la plus exigeante de la gestion de projet puisque on va
planifier tous les aspects du projet depuis son lancement jusqu'à sa livraison finale, donc
c’est une tâche continue qui est exécutée durant tout le projet.
La planification vise à identifier tous d’abord les objectifs, les contraintes ou les risques,
les tâches à effectuer pour réaliser les objectifs, les étapes clés (milestones), les livrables
(deliverables) produits par le projet, l’affectation des ressource, l’affectation des
responsabilités (rota, 2008).
La planification est une activité itérative qui se raffine au cours de réalisation de projet.
Le chef de projet organise dans le temps les activités de ses équipes. Le processus de
cette planification doit être dynamique, en fonction de la situation réelle et en fonction
des nouvelles informations qui changent à tout moment.

3. Pourquoi planifier ?
L’utilité de la planification peut apparaitre sous plusieurs angles de vision qu’on peut
les regrouper en :
 Outil d’aide à la décision : Le plan initial assiste les décideurs dans leur prise de
décision sur l’investissement en offrant des informations approchées sur le cout
du projet, la date à laquelle on disposera du produit final, le déroulement, les
personnes qui vont y être associées.
 Un plan qui rassure ; Le plan, avec les échéances principales, permet au client de
programmer ses actions futures en fonction des dates de livraisons
prévisionnelles et de planifier sa disponibilité pour les tests ou les validations
 Outil de pilotage ; Le chef de projet met en place les modalités et les techniques
de mesure qui l’aideront à suivre l’état d’avancement et les problèmes
rencontrés afin d’entreprendre les actions correctives.
 Un plan est un support de communication ; le plan donne les moyens de
discuter, de négocier le périmètre, les coûts, les délais et les engagements des
uns et des autres.

Sans plan, personne ne sait quand ni comment l’objectif sera atteint ; les dates ne sont
ni précises ni respectées par la suite ; la gestion est approximative, les décisions
souvent prises dans l’urgence ; les ressources ne sont pas efficacement allouées ; les
engagements ne sont pas fixés ni honorés, les budgets sont dépassés. Au final, le client
n’est pas satisfait et le projet risque d’échouer (rota, 2008).

4. Le processus de planification
Le processus de planification peut être divisé en plusieurs étapes, qui sont illustrées par
l’organigramme dans la figure 9.

48
Figure 7 Organigramme de planification

Chaque phase est détaillée dans ce qui suit :

4.1 Etablir les objectifs et les contraintes


La première étape consiste à établir les objectifs et les contraintes du projet. Les
objectifs identifient les buts généraux du pro projet
jet ainsi que les fonctions essentielles que
le logiciel doit accomplir, sans préciser comment ils seront réalisés. La définition des
objectifs doit être validée et acceptée par toutes les parties prenantes. Il est important,
dans le cas d’objectifs contr
contradictoires,
adictoires, de les faire converger vers le même objectif.
Une fois que les objectifs sont identifiés, il faut mettre au clair les contraintes et les
limites du projet en termes de date de livraison, disponibilité du personnel, budget
alloué et méthodes de communication avec le client

4.2 Effectuer une estimation initiale


Apres l’identification des objectifs, un chef de projet fait une estimation globale et
générale pour définir les principaux paramètres liée au projet, tel que sa taille, le budget
estimé,
é, le nombre de personnes impliqués et la répartition des taches mais tous cela de
façon approximative. Une autre estimation plus détaillé
détaillée doit être fait en fonction du
plan de projet et le calendrier des taches.

49
4.3 Définir les tâches, les étapes clés et les livrables
Afin de maitriser sa complexité, le projet doit être divisé en tâches (ou activités).
Cependant, il faut opter pour une division normalisée et homogène, c'est-à-dire on ne
peut avoir des taches d’une durée trop petite ni d’une durée considérablement grande.
Les taches considérées comme trop petite peuvent être regroupées en une seule tache.
De l’autre coté, les grandes taches seront divisées en sous taches jusqu'à ce qu’on
obtienne des sous-tâches qui sont traitables. Une tâche traitable est une tache qui se
caractérise par un résultat facile à juger (p.e. succès, échec), une durée et des ressources
facile à estimer.

Parmi les méthodes utilisées pour représenter le découpage des taches, on trouve la
méthode de découpage par travail, WBS (work breakdown structure) (Durand, 2004).

La représentation WBS (work breakdown structure) est une représentation hiérarchique


des taches à réaliser, elle représente principalement tout ce que le projet va engendrer en
termes de livrable.
Une telle technique offre l’avantages d’être simple à appliquer, il suffit d’identifier tous
les livrables et les taches qui les génèrent. De plus, Le fait d’illustrer les livrables
donnera une idée plus claire sur les risques cachés.
La manière la plus simple pour créer un WBS est d’établir la liste des livrables (du
produit, du contrat, de cahier des charges) tout ce que peut être produit par le projet. La
liste générée sera plus raffinée en ajoutant les sous-produits.

Pour établir un découpage cohérent, il est conseillé de consulter les experts ou du


personnel compétent de tous les domaines de votre projet. Pour un projet de
développement logiciel on doit au moins demander l’avis d’au moins trois personnes :
le concepteur de l'interface utilisateur, le développeur, le testeur.
Ensuite, il faut les interroger afin d’obtenir des réponses (quoi? ensuite? Combien de
temps? Avec qui? Etc).

La méthode WBS est basée sur la règle 8/80 comme bonne règle générale qui garantit
qu'aucune tâche n'est inférieure à 8 heures ou supérieure à 80 heures. Si une tâche est
supérieure à 80 heures, elle doit ensuite être décomposée en lots de travail.

Exemple d’un découpage en se basant sur la méthode WBS :

 Y est un fabricant de fils, de rubans et d'autres matériaux. Son chef de projet a


géré un projet logiciel pour créer une application Web permettant aux clients de
placer et de suivre les commandes.

 La première étape que CP a prise était de convoquer son équipe de projet. Son
équipe de projet était composée de personnes provenant des secteurs des ventes,
du marketing, de l'informatique et de la fabrication.

 CP a expliqué à son équipe que le but de la réunion était de créer une structure
initiale de répartition du travail (WBS) pour représenter tous les produits
livrables promis par le projet.

50
Solution :
 Son équipe a déterminé que ce projet comportait :
 Livrables Web:
 Interface utilisateur
 Interface administrateur
 Catalogue de produits en ligne
 Programmes Java

 Livrables de base de données:


 Serveurs SQL
 Bases de données de produits
 Bases de données de fabrication
 Mesures de sécurité

 Livrables de la gestion de projet:


 Plans de gestion de projet
 Calendriers de projet
 Contrats

4.4 Dresser un horaire pour les tâches à effectuer


Cette tache consiste à faire une estimation sur la durée d’une tache et indiquer sa date
de début soit de façon explicite (échéance) ou de façon implicite et cela en mettant au
clair ses dépendances.
Dans le cas général, l’estimation dépend en grande partie de l'intuition et de l'expérience
du gestionnaire de projet. Autrement dit, un chef de projet peut s’inspirer d’un
précédent projet en tenant en compte l’environnement, les outils, les conditions et les
contraintes (Roger Pressman, 2001).
La fiabilité totale de l’estimation ne peut jamais être atteinte, quelque soit l’effort
fourni, d’autre part, qu’avec un effort limité, on peut atteindre un niveau de fiabilité
satisfaisant (plus de 50 %). La fiabilité peut même décroître avec un effort trop
important.

Le chef de projet peut opter pour la technique de wide bande delphi pour avoir un
intervalle approchée de son estimation (Durand, 2004).
La méthode WBD est basée sur la collaboration entre plusieurs intervenants (rota,
2008). Généralement, c’est trois experts ou chacun propose une estimation
indépendamment des autres. Ensuite, un facilitateur recueille anonymement chaque
estimation et publie une moyenne des valeurs collectées. La moyenne sera affichée pour
que chaque personne explique la différence entre son estimation et la moyenne affichée
dans le but de faire émerger l’estimation la plus fiable, qui prendrait en compte le
maximum d’éléments objectifs. À la fin de la discussion, chaque expert, influencé ou
pas, convaincu ou pas par les arguments de ses pairs, procède à une nouvelle estimation
; la moyenne de cette nouvelle estimation est, à nouveau, mise en commun par le
facilitateur au cours d’un deuxième round. Au final, au terme de deux ou trois sessions,
si nécessaire, le modérateur applique aux dernières valeurs recueillies, la formule
suivante :

51
[P + (4 I) + O] / 6

Où P = estimation pessimiste, I = estimation intermédiaire, celle considérée comme la


plus probable, et O = estimation optimiste, pour obtenir l’estimation la plus
représentative et la plus consensuelle.

L’avantage de chaque méthode est la convergence vers l’estimation fiable en se basant


sur le principe qu’affirme que l’intelligence du groupe est supérieure à la somme des
intelligences individuelles.

4.5 L'ordonnancement des taches


L’ordonnancement consiste à énumérer les tâches à réaliser dans l'ordre ou elles doivent
être réalisées en spécifiant les dépendances entre les taches afin de déterminer la date de
début et la date de la fin d’un projet.
Généralement dans un projet certaines taches ne peuvent s’exécuter qu’après que
d’autres soient terminées. Par exemple, on ne peut commencer les fondations que
lorsque le terrassement est fini. Cependant, d’autres tâches peuvent s’exécuter
simultanément. La prise de conscience de ses aspects permet de :
 Minimiser le temps de réalisation
 Optimiser l’utilisation des ressources (p.e. du personnel, du matériel).
 Eviter les retards causés par une tâche attendant une autre qui n'a pas encore
terminée.

A) Formulation mathématique
 Nous avons n tâches à exécuter (i = 1,..., n).
-di : la durée d’exécution de la tâche i.
-ti : le temps de début d’exécution de la tâche i,
-tf : note le temps de fin de projet
Objectif : min z = tf − t0.
 Règles :
 𝑡 ≥ 𝑡 , ∀ 𝑖 = 1,2, … 𝑛
 𝑡 + 𝑑 ≤ 𝑡 , ∀ 𝑡𝑎𝑐ℎ𝑒 𝑖 𝑎𝑛𝑡é𝑟𝑖𝑒𝑢𝑟𝑒 à 𝑙𝑎 𝑡𝑎𝑐ℎ𝑒 𝑗
 𝑡 + 𝑑 ≤ 𝑡 , ∀ 𝑖 = 1,2, … 𝑛

B) Contrainte d’ordonnancement
Afin d’obtenir un ordonnancement fiable, il faut prendre en considération les différentes
type de contraintes qui affecte le choix de la date de début et date de fin de chaque
tache. On capte généralement 4 types de contraintes (Vliet, 2007) :

- Les contraintes de succession temporelle expriment les relations d’antériorité entre


les taches : une telle tache ne peut commencer avant la fin d’une autre. La date de fin de
la première tache désigne implicitement la date de début de la tache suivante. Il existe
quatre type de relation qui peut exister entre deux taches (P ;S ) (Durand, 2004):

52
- Début – Début (DD) : c’est une relation pour indiquer qu’on ne peut entamer
la réalisation de la tache S avant le début de la tache P.

- Début – Fin (DF) : c’est une relation pour indiquer qu’on ne peut terminer
la réalisation de la tache S avant le début de la tache P.

- Fin- Début (FD) : c’est une relation pour indiquer qu’on ne peut entamer la
réalisation de la tache S avant la fin de la tache P.

- Fin-Fin (FF) : C’est une relation pour indiquer qu’on ne peut terminer la
réalisation de la tache S avant la fin de la tache P.

-Les contraintes de localisation temporelle expriment la localisation d’une tache dans


le temps : une tache ne peut commencer avant une telle date, ou après une telle.
Exemple : Date de début de la phase de conception est le 01/11/2019.

- Les contraintes cumulatives imposent la prise en compte de la disponibilité de


ressources non stockables, par exemple des heures de travail en personnel ou
d’´equipement dont on peut disposer au cours d’une période et qui sont perdues si elles
ne sont pas utilisées durant cette période.

-Les contraintes disjonctives expriment le fait que deux tâches ne peuvent avoir lieu en
même temps sans que l’on puisse dire laquelle doit être effectuée avant l’autre (par
exemple, plusieurs tests qu’on doit les exécuter sur la même machine).

53
C) Représentation d’un ordonnancement
La représentation d’un ordonnancement vise à mettre en évidence l’organisation des
taches en précisant principalement la date de début et la durée. Cette représentation peut
prendre deux formes : notation textuelle (tableau) et notation graphique.

1- Notation textuelle
Tableau d'étapes clés (key-events table) : Un ordonnancement est modélisé sous
forme d’un tableau avec deux colonnes. Comme son nom l’indique on ne s’intéresse
qu’aux dates clés dans notre ordonnancement, La première colonne est réservée pour les
dates tandis que la deuxième colonne contient les titres des taches. C’est un tableau très
simple à réaliser mais utiles pour le chef de projets surtout dans le cas de suivi.

Exemple :
Tableau 2 Exemple d’un Tableau d'étapes clés
Date étape clé
14 Janvier Démarrage du projet
16 janvier Analyse des besoins
20 Janvier Conception générale
23 Janvier Etablir les diagrammes
27 Janvier Réunion de validation
31 Janvier Test statique

Tableau de tâches (task table) : C’est représentation plus détaillée de tableau de tache
clés, cette représentation montre toutes les tâches avec leur date de début et leur date de
fin.

Exemple :
Tableau 3 Exemple d’un tableau de tâches
Date Tâche
Jul 17-Aug 23 Preplanning Phase
Aug 26 - Sep 24 Project Planning
Sep 11-Oct 8 Requirements Analysis
Oct 9 - Oct 26 System Design
Oct 28-Nov 7 Object Design
Nov 8 - Nov 20 Implementation & Unit Testing
Nov 22 - Dec 4 System Integration Testing

Tableau d'allocation : c’est un tableau plus détaillé, qui montre l’affectation des
taches, la durée et leur dépendance. Ce tableau montre à chaque personne impliquée
dans la réalisation, ses responsabilités et son taux d’implication.

54
Exemple :

Tableau 4 Exemple d’un tableau d’allocation


Tache Allocation Durée Dépendances
T1 Zakaria (75%) 8j
T2 Houssem 15j
T3 Mohamed (80%) 15j T1
T4 Youness 10j
T5 Zakaria 10j T2, T4
T6 Mohamed 5j T1, T2
T7 Youness 20j T1
T8 Houssem 25j T3, T6
T9 Houssem 15j T7

2-Notation de diagramme

Aussi bien pour sa formulation que pour sa résolution, l’ordonnancement peut être
modélisé sous forme de graphe. On peut, en effet, représenter le problème sur un graphe
et, ensuite, résoudre le problème graphiquement. De plus, la présentation du résultat de
calcul (l’ordonnancement des taches) sera beaucoup plus claire sur ce graphique que sur
un tableau de chiffres. Généralement, trois différents types de diagrammes sont utilisés :
Diagramme de Gantt, diagramme PERT et diagramme CPM.

Les diagrammes de Gantt : Outil de planification qui permet de visualiser les relations
temporelles des tâches et du personnel. Ce diagramme a été développé et popularisé
autour de 1910 par Henry L. Gantt. Le diagramme de Gantt est très utilisé par les chefs
de projet quelque soit leur secteur d’activité afin de modéliser et visualiser la
planification des tâches d’un projet donné.

 Le diagramme de Gantt permet :


- De visualiser l’avancement des tâches d’un projet de manière simple.
- De planifier ses besoins en ressources humaines, matérielles
- D’aider dans la construction du budget projet
- Suivre les coûts de projet : consommation de ressources humaines J/h,
équipement…
- De communiquer simplement sur l’avancement du projet

Les diagrammes de Gantt visualisent les relations temporelles de chaque tâche. Dans le
diagramme de Gantt l'axe horizontal représente le temps, l'axe vertical représente les
tâches à exécuter. Les tâches sont représentées par des barres horizontales qui
visualisent le début et la fin de chaque tâche. Il est possible aussi de représenter les
étapes clés par des losanges.

55
Exemple :
Soit un projet qui démarre le 11/11
11/11/2019 avec l’ordonnancement représenté dans le
tableau suivant :

Tableau 5 Exemple d’un ordonnancement

Tâchee Durée Prédécesseurs

A 5j -
B 10j 1FD

C 5j 1FD

D 5j 2FD ; 3FD

Le diagramme de Gantt qui correspond à cet ordonnancement est illustré dans la figure
8.

Figure 8 La modélisation de l’ordonnancement par Gantt

Le diagramme de PERT ERT : PERT (Program Evaluation and Review Technique) a été
inventée à la fin des années 1950 par la marine américaine (US Navy) pour coordonner
les travaux du projet POLARIS (réalisation de m missiles
issiles à ogives nucléaires) (Durand,
2004).. La méthode de PERT est un outil de gestion de projet qui permet aussi de
modéliser et gérer l'ordonnancement au sein d’un projet. Cette méthode contrairement à
la précédente modélisee en plus des tâches, les liens et les dépendances entre les
différentes taches de projet en formant un réseau appelé Réseau PERT ou Diagramme
PERT. Dans ce diagramme, chaque nœud du graphe représente une étape et les arcs
montrent les tâches.

56
Exemple
Tableau 6 2 eme exemple d’un ordonnancement
Tâche Prédécesseurs

A -

B -

C A

D A

E D

F B, C

G F, E

H F

Le réseau PERT qui représente cet ordonnancement est illustré dans la Figure 9.

Figure 9 Diagramme PERT pour un ordonnancement

Méthode CPM : L’établissement de ce réseau correspond à la méthode des potentiels


tâches ou méthode du Chemin critique ou encore CPM (Critical Path Method). Ce
réseau est aussi appelé PDM (P (Precedence Diagramming Method) (rota, 2008). 2008) Chaque
activité est représentée par une boîte. Cette boite comporte toutes les informations
relatives à une tache, tel que titre, durée, date de début, cout et ressource.
Les activités sont liées entre elles par des liaisons de dépendances représentées par des
flèches. C’est une représentation synthétique des relations logiques entre activités,
construit de gauche à droite pour représenter la chronologie d’un projet. L’avantage de
ce réseau des antécédents est qu’il permet une visualisation claire de la logique des
dépendances, il donne la possibilité de représenter les quatre relations avec des délais
(écart/recouvrement).
Exemple :
Pour le même ordonnancement présenté dans le tableau précédent, le graphe CPM est
illustré dans la figure 10.

57
Figure 10 Diagramme CPM pour un ordonnancement

D) Calcul de l’ordonnancement
L’objectif principal d’un ordonnancement est de maitriser l’aspect temps dans un projet.
Une fois que l’ordonnancement est établi, le chef de projet doit calculer toutes les dates
nécessaires afin de prendre conscience de toutes les informations relatives au projet, tel
que la date prévu pour terminer le projet, le retard qu’on peut ef
effectuer
fectuer sur une tache
sans retarder la date de fin de projet et les taches critiques. Le calcul d’un
ordonnancement consiste à calculer (Gérard Casanova, 2012):
- Ordonnancement au plus tôt (début/fin)
- Ordonnancement au plus tard (début/fin)
- Chemin critique
- Marge de retard (marge libre/ marge totale)

1-Ordonnancement
Ordonnancement au plus tôt tôt: La date au plus tôt est considérée comme le minimum
de retard qu’on peut effectuer avant le début d’une tache. Elle est obtenue en calculant
le temps le plus long nécessaire pour parvenir à cette tache. Autrement dit, s’il existe
plusieurs chemins dans le graphe qui précède l’exécution d’une tache, alors sa date de
début au plus tôt est le chemin le plus long.
En résumé, la technique de calcul des dates au plus tôt est la suivante :
Partant de la tâche de début, il s'agit de calculer de la gauche vers la droite les dates au
plus tôt. Pour cela, il suffit de respecter les deux règles :

- la date de début au plus tôt d'une tâche est égale à la plus grande ddes dates de fin
au plus tôt des tâches qui la précèdent.

- la date de fin au plus tôt est ensuite obtenue en additionnant la durée de la tâche
à sa date de début au plus tôt.

Exemple : Soit quatre tâches AA, B, C et D de durées respectives 5, 5 2,3 et 4 jours. B


ayant pour antécédent A
A, C ayant pour antécédent A et B, D ayant pour antécédent C.
Le graphe généré par cet ordonnancement est illustré dans la figure 11.
11

58
Figure 11 Diagramme de CPM

Calculons dans un premier temps les dates au plus tôt de la tâche A :


Elle se trouve au début de projet la date de début au plus tôt (DTO) sera donc de 0, pour
déterminer la date de fin au plus tôt (FTO) :
FTO = DTO + D
FTO (A) = DTO (A) + D (A) = 0 + 5 = 5
*D étant la durée de la tâche

Calculons les dates au plus tôt de B et C :


DTO (B) = FTO (A) car nous sommes dans l'hypothèse que les liaisons entre les tâches
sont du type fin-début de délai nul.

Pour calculer FTO (B) le principe est identique à celui de A :


FTO (B) = DTO (B) + D (B) = 5 + 2 = 7

Calcul des dates de C :


C a deux antécédents A et B sa date de début au plus tôt peut donc être la date de fin au
plus tôt de A ou de B.

Comme elle ne peut débuter que lorsque A (et, ou) B sont finies sa date de début au plus
tôt sera donc la plus grande des deux dates de fin au plus tôt :
DTO (C) = FTO (B) = 7

Pour calculer FTO (C) le principe est identique à celui de A :


FTO (C) = DTO (C) + D (C) = 7 + 3= 10

2-Ordonnancement au plus tard (début/fin) : il consiste à définir la date de début et


la date de fin à ne jamais dépasser pour chaque tâche si l'on veut respecter l'objectif
temps de la fin de projet. C’est-à-dire le maximum de retard possible sans affecter la
durée du projet. Généralement, pour obtenir la date au plus tard, on effectue la retro-
planification, c'est-à-dire on commence par la dernière tache, ensuite on recalcule les
dates en prenant toujours, la plus petite date.
Exemple : reprenons le même exemple, on commence par calculer la date au plus tard
de la dernière tache, en occurrence la tache D. la date de fin du projet correspond à la
date de fin de la tache D. Donc :
FTA = Date fin du projet = 14
DTA = FTA – D = 10

59
La tache D a un seul prédécesseur qui est la tache C.

-Calculons les dates au plus tard de C :


DTA (D) = FTA (C) car nous sommes dans l'hypothèse que les liaisons entre les tâches
sont du type fin-début de délai nul.
FTA(C) = 10
DTA (C) = FTA – D = 7

-Pour calculer FTA (B) le principe est identique à celui de C :


FTA (B) = DTA (C) = 7
DTA (B) = FTA – D = 7- 2 = 5

C-Calcul des marges : Parmi les intérêts du calcul des dates au plus tôt et date au plus
tard c’est déduire la durée du retard possible dans la réalisation des taches sans qu’on
affecte la date de fin du projet, ce type de retard est nommé la marge. Dans un projet, il
existe deux types de marge:
Marge totale: le retard que peut prendre une tache sans retarder la date de fin de projet.

Marge libre : marge de retard dont dispose une tache sans retarder ses successeurs. Si la
tache n’a pas de successeurs, c’est le retard que peut prendre une tache sans retarder la
date de fin de projet.

Les formules utilisées pour calculer les marges dépendent de la notation utilisée :
- Graphe de Pert :
o Marge total = DTA « étape j » - DTO « étape i » - Durée tâche ij"
o Marge libre = DTO "étape j" - DTO "étape i" - Durée tâche "ij"
- CPM :
o Marge libre =min (a , b , c - e , d - e) - DTO (T)
Où:
o a = min (date de début au plus tôt des successeurs avec liaison DD)
o b = min (date de fin au plus tôt des successeurs avec liaison DF)
o c = min (date de début au plus tôt des successeurs avec liaison FD)
o d = min (date de fin au plus tôt des successeurs avec liaison FF)
o e = durée de la tâche T

D-Notion de tâche critique : Les taches critiques sont celles qui si on les glisse dans le
temps on va affecter directement la durée du projet. Autrement dit, c’est des taches avec
une marge nulle.

E-Notion de chemin critique : On appelle chemin critique tout chemin liant le nœud
début de projet au nœud fin de projet tel que l’en faisant la somme des durées des tâches
le long de ce chemin critique on obtienne la durée minimale du projet.

Exemple :
Pour l’ordonnancement présenté dans la table, les marges sont :

60
Tableau 7 Exemple de calcul des marges
Nom de la tache Marge totale Marge libre Tache critique
A 0j 0j Oui
B 0j 0j Oui
C 10j 10j Non
D 0j 0j Oui

E) Affectation des ressources

Dans la partie contrainte d’ordonnancement, on a souligné le fait que la date de début


d’une tache peut dépendre de ses relations avec les autres ainsi que de la disponibilité
des ressources (Les contraintes cumulatives et contraintes disjonctives). Donc, le
processus décrit précédemment ne peut être terminé sans l’affectation de toutes les
ressources, en tenant compte de leur disponibilité et leur rôle. Une ressource dans un
projet est le moyen nécessaire au bon déroulement d’une tâche. On peut trouver deux
types de ressource : humaine et matérielle. Mais on peut étendre la définition pour
inclure aussi d’autres types de ressource tel que, des salles, des services et outils
spéciales qui sont nécessaires dans une période seulement, qui font pas parti du projet
mais qu’on utilise à un certain moment.

La première étape dans le processus d’affection consiste à identifier les


ressources nécessaires pour la réalisation des taches. Un chef de projet doit affecter à
chaque tache son ensemble de ressources nécessaires. Lorsqu’une tâche est affectée à
une personne, cette personne ne sera plus disponible tout au long de la période de
réalisation. Dans le processus d’affectation, une ou plusieurs ressources peuvent être
allouées à une ou plusieurs tâches. Il est possible aussi d’allouer une ressource à
plusieurs taches en même temps, en indiquant le pourcentage d’implication.

Pour l’affectation de personne, avant de faire l’affectation, un chef de projet doit


connaitre les compétences et les préférences de chaque membre de son équipe ainsi que
le développement professionnel. Le chef de projet doit tenir compte des jours fériés et
les jours de congé. De plus, il doit prendre conscience que certaines taches peuvent être
réalisées par n’importe quelle personne, contrairement à d’autre qui nécessite des
spécialistes. La productivité de la personne affectée est un facteur important pour
ajuster l’estimation de la durée d’une tache. Et finalement, si deux taches nécessitent la
même ressource dans la même période, la tache avec la plus grande marge doit être
décalée.
Les notions du travail, capacité et durée sont interconnectées. On désigne par le
travail l’effort nécessaire pour réaliser une tache. Généralement, l’estimation de l’effort
est indépendante des ressources utilisées. Pour la capacité, c’est la quantité de
ressources disponible pour réaliser une tache. Lorsqu’on parle de ressource humaine,
elle est considérée comme étant le taux d’intervention, ou unité de travail. Et
finalement, la durée d’une tache est la quantité de temps nécessaire pour la réaliser.
Dans une prévision pilotée par le travail (ou effort), la durée d’un projet dépend de la
charge de travail, du nombre de ressources affectées, et leur capacité pour réaliser ce
travail. Plus on a de ressources et plus la capacité augmente et on a tendance à terminer
tôt. Plus concrètement :

61
Durée = travail / capacité

L’affectation des ressources peut être modélisée par un diagramme de Gantt ou un


diagramme de CPM.

Exemple
Pour le tableau d’allocation suivant (Table 8).

Tableau 8 Exemple d’affectation de ressource

N ° Nom de la tache Travail Prédécesseurs Ressource

1 A 10 j R1(100%)

2 B 15 j 1DD R2(100%)

3 C 20 j 1FD R1(100%)

4 D 5j 1FD R2(100%)

5 E 5j 2FD R2(50%)

6 F 10 j 3FD ; 4FD R1(50%)

7 G 15 j 4FD ; 5FD R2(50%)

8 H 10 j 7DD R1(50%)

9 I 10 j 6FD ; 7FD ; 10FF R1(100%)

10 J 20 j 8FD R2(100%)

L’affectation des ressources est modélisée par le diagramme CPM avec une prévision
piloté par le travail (Figure 12). On peut constater que la durée des taches avec un taux
d’implication 50% a doublé.

62
Figure 12 Diagramme de CPM pour l’affectation de ressources

La même affectation peut être modélisée par un diagramme de Gantt.

Figure 13 Diagramme de Gantt pour l’affectation de ressources

On peut constater également une sur sur-utilisation


utilisation (ou surcharge) dans la ressource R1 à la
sixième semaine en réalisant la tache C et la tache H simultanément. Le taux
d’utilisation de la ressource R1 est de 150%. Autrement dit, pour terminer la tache dans
les délais, cette personne doit travailler 12h par jour, pendant la sixième semaine. Une
des solutions possibles, c’est d’utiliser une nouvelle ressource. Cependant, dans un
cadre budgétaire
ire serré, qui nn’autorise pas l’ajout d’autres ressources,, le chef de projet a
recours à des techniques de nivellement.

Techniqueue de suppression de surcharge


Afin d’éviter des surcharges, deux techniques sont utilisées : le nivellement par date et
lissage (Sincère, 2005).

63
-Le
Le nivellement par date : il consiste à effectuer des décalages afin de maintenir les
ressources en dessous d’une certaine limite. On commence par identifie
identifier les surcharges.
Ensuite, on décale la tache ave
avecc une marge positive, tout en respectant les dépendances
et les échéances. Il est important de noter que le nivellement par date n’a aucun effet sur
les durées.
Exemple : on applique cette technique sur le diagramme de Gantt illustré dans la figure
13. Le résultat est illustré dans la figure 14.

Figure 14 Elimination de surcharge par un nivellement par date

On remarque que pour éliminer la première surcharge


surcharge,, on décale D et non pas le B (la
(
marge de D est supérieure à celle de B), avant G (D est un prédécesseur de G, avec
liaison FD) et après E (tâche critique). Le fait de décaler le G, affecte date de début de
H, ce qu’il élimine implicitement le deuxième cas de surcharge. En ce qui conc concerne le
cas de J, la tache est décalée jusqu'à l’élimination de surcharge, mais ceci implique aussi
un retard sur l’exécution de I (liaison FF).

Le lissage (le nivellement par charge) : il consiste à répartir pour chaque ressource sa
charge de travail pour
ur éviter les surcharges et les sous
sous-charges.
charges. Dans ce cas, la durée
d’une tache peut augmenter, mais le travail reste le même. Il est impossible d’effectuer
le nivellement par charge pour les taches avec une durée fixe (tel que le transport).
Exemple : pour la même modélisation, les surcharges sont éliminées par le lissage
(Figure 15).

64
Figure 15 Elimination de surcharge par lissage

On remarque que la tache D est décalée avec un changement dans la capacité (réduite à
50%), une telle manœuvre a engendré une augmentation de la durée (10 jours au lieu de
5), mais une utilisation optimal
optimale de laa ressource R2 durant la 5 ème et 6 ème semaine.
semaine
Cependant, il est impossible d’appliquer un lissage dans la surcharge de H et J, donc
donc, on
applique un simple nivellement.

F) Coût planifié du projet


Parmi les finalités d’une planification est d’avoir une vision plus claire sur le cout du
projet. Avant le lancement, le chef de projet peut établir une estimation sur le cout
global en effectuant
ectuant une estimation de la taille globale. Une fois le plan établi, il aura
une vision plus claire, qui lui permet d’ajuster son estimation initiale. Le cout planifié
est calculé en faisant la somme des couts de chaque ressource affectée au projet. Cel Cela
englobe généralement le salaire des employés, les couts de matériels, le cout des
spécialistes. On se réfère au diagramme de Gantt de ressource pour calculer le cout
planifié (Sincère, 2005)..
Exemple : pour le diagramme de Gantt après nivellement, si le salaire de R1 et R2 est
égal à 1739 DA et 860 DA par heure :
Cout de R1 = 12 * 35* 1739 = 730380
Cout de R2 = (8*35 + 8*17.5) * 860 = 420 * 860=361200
Cout planifié = Cout de R1 + Cout de R2 = 1091580 DA
*On suppose quee la ressource travaille 35h par semaine.

65
Série TD 3 : la planification

Exercice 1 :

La première étape dans un ordonnancement consiste à découper le projet en un


ensemble de taches de taille maitrisable afin de facilité le processus d’estimation.
Parmi les méthodes de découpage, on trouve : PBS et WBS.

Proposer un découpage de votre projet de fin d’étude suivant ces deux techniques.

Exercice 2 :

Pour repeindre une pièce, on identifie les sous-tâches suivantes :


1- Choisir la couleur ;
2- Acheter la peinture ;
3- Nettoyer les murs ;
4- Mélanger la peinture ;
5- Peindre les murs.
On pourra considérer que les artefacts produits sont :
A- Choix de peinture ;
B- Pots de peinture achetés ;
C- Murs propres ;
D- Peinture mélangée ;
E- Murs peints.

Partie 1 :
Nous allons représenter un processus ainsi que ses entrés et sorties comme suit :

1- Appliquer cette représentation sur l’ensemble des taches ci-dessus.

Partie 2 :
1- Estimer la durée de chaque tâche en précisant la technique utilisée.
2- Modéliser l’ordonnancement par :
- Diagramme de gant
- Diagramme de pert
- Diagramme de réseau.
3-Déterminer DTO, FTO, DTA et FTA, pour chaque tache.
66
Exercice 3 :
A partir de ces deux tableaux :
Pour Faire A B C D E F G H I J
Il faut avoir fait E E A A D,E B G J,C,H,F A

Taches A B C D E F G H I J
Durée en jours 1 6 3 2 8 2 5 7 2 4

1- Modéliser l’ordonnancement par :


- Diagramme de GANTT
- Diagramme de réseau

2- Déterminer DTO, FTO, DTA et FTA, pour chaque tache.


3- Calculer la marge totale et la marge libre pour chaque tache

Exercice 4 :
N° Nom de la tache Durée Prédécesseurs
1 A 10 j
2 B 15 j 1DD
3 C 20 j 1FD
4 D 5j 1FD
5 E 10 j 2FD
6 F 15 j 3FD ; 4FD
7 G 25 j 4FD ; 5FD
8 H 20 j 7DD
9 I 10 j 6FD ; 7FD ; 10FF
10 J 20 j 8FD

- Modéliser l’ordonnancement par un diagramme de réseau.


- Calculer les dates au plus tôt et les dates au plus tard.
- Calculer la marge totale et la marge libre pour chaque tache.
- Recalculer les dates et les marges en ajoutant les deux contraintes suivantes :
o la tâche F : « début au plus tôt à t0 + 50 j »
o la tâche I : « fin au plus tard à t0 + 70 j »

Exercice 5 :

Conception et installaion d’un web services


Un concepteur de réseau a pour tache d’élaborer le planning de son prochain projet
réseau. Les taches qui doivent étres effectuées sont :
A.Ecriture détaillées des services WEB à développer (définition du projet) 28jours
B. Sélection des développeurs sous critère de qualification 6 jours ne peut
commencer que 24 jour après le début de A
C. Détermination du matériel requis et de la topologie réseau 06 jours ne peut
commencer que 30 jours après le début de A.
67
D. Conception et mise en place de la topologie requise 12 jours après A
et C
E. Développement des interfaces typiques IO jours après
A et B
F. Traitement et configuration des accès externes 10 jours après C
et D.
G. Traitement des problèmes de synchronisation d'accès 12 jours après F
H. Mise en place des WEB services 06 jours après
E et G.
I. Adaptation et installation d'une politique de sécurité 07 jours après
H.

Date du démarrage du projet : Mardi 08 Janvier 2019


I. Etablir le planning. N.B. à considérer vendredi comme jour chômé.
2. Déduire les retards possibles des tâches.

Exercice 6 :

Numéro Nom Durée Prédécesseur Ressource (%)


1 A 15j - R1(100%)
2 B 15j 1DD-5j R2(100%)
3 C 10j 2FD R1(100%)
4 D 20j 1FD R1(50%) R2(50%)
5 E 10j 2FD R2(100%)
6 F 15j 4FD R2(100%)
7 G 20j 6DD R2(100%)
8 H 10j 6FD R1(100%)
9 I 20j 7FD R1(100%)
10 J 25j 8FD R2(100%)
11 K 15j 10FD R1(50%) R2(50%)

- Etablir un diagramme d’affectation des ressources pour le tableau ci-dessus.

-Y a-t-il une surcharge dans la répartition des ressources ? proposer une modification
dans l’ordonnancement en appliquant :

- Nivellement par charge


- Nivellement par durée

-Si le coût de R1 = 300 DA/h et R2= 250 DA/h calculer le coût du projet. (1 semaine =
35h ).

68
Exercice 7

Développement de produits logiciels


Un responsable logiciel a pour tâche d'élaborer le planning de développement. Les
tâches qui doivent être effectuées sont :

1. Découpage technique du logiciel 7 jours


2. Développement de l'interface 10 jours après 1
3. Traitement des problèmes d'accès 10 jours après 1
4. codage du système 20jours après 2,3
5. Test d'intégration 15 jours après 3 et ne peut commencer que 10
jours après le début de 4

6. Déploiement du logiciel 7 jours après 5


7. installation du service de maintenance 5jours ne peut commencer que 05
jours après 4

- Proposer un diagramme d'affectation du personnel avec le minimum de personales


sans surcharge.

69
Références

American National Standard. (2004). Guide du Corpus des connaissances en


management de projet. Pennsylvania: Project Management Institute.

Anne-Marie. (2002). Génie logiciel . Paris: Hugues.

Boulet, G. (Mai 2006). ÉLÉMENTS DE GESTION DE PROJET. Paris: PMP.

boussaid, I. (2010). GESTION DE PROJET pour Master 1 RSD. Alger: Université des
sciences et technologies houari boumediene.

Bureau des technologies d’apprentissage. (2003). Initiation aux principes fondamentaux


de la gestion de projet. Paris.

CLET, H.-P. M. (2005). Pratiquer la conduite de projet. Paris: Éditions d’Organisation.

Durand, A. (2004). MAÎTRISE D’OEUVRE DES PROJETS INFORMATIQUES. Paris:


Dunod.

Gérard Casanova, D. A. (2012). Gestion de projet:calcul des dates et calcul des marges.
Université de Lorraine.

Jean Yves Moine, X. L. (2012). Le grand livre de la gestion de projet. Paris: Editions
afnor.

khemissa, H. (2005). Cours gestion de projets,. Alger: Université des sciences et


technologie Houari Boumediene.

MINTZBERG, H. (1987). Le pouvoir dans les organisations. editions d'Organisation.

Roger Pressman, B. M. (2001). Software Engineering A Practitioners Approach. New


York: McGraw-hill Education.

Rota, V. m. (2008). Gestion de projet Vers les méthodes agiles. Paris: ÉDITIONS
EYROLLES.

Sincère, F. (2005). Techniques de planification de projets,Gestion de projet.


Qualité,logistique industrielle et organisation.

Stattner, E. (2013). Cours Initiation aux Principes Fondamentaux de la Conduite de


Projet. Université des Antilles et de la Guyane.

Vliet, H. v. (2007). Software Engineering: Principles and Practice. New york: Wiley.

70