SlideShare une entreprise Scribd logo
1  sur  130
Télécharger pour lire hors ligne
Sana REFAI
sana.refai@gmail.com
2016-2017
Gestion de projets
DSI3
1
Objectifs du cours
 Connaitre et comprendre les enjeux de la gestion de
projets informatiques
 Permettre à l’étudiant d’avoir une réflexion critique sur le
processus de développement des systèmes
informatiques et sur les outils de gestion de projets
2
Sana REFAI
sana.refai@gmail.com
2016-2017
Chapitre 1
Introduction à la gestion de projets
3
Définition et terminologie
 Définition et terminologie
 qu'est-ce qu’un projet ?
 gestion d'un projet
 pilotage/conduite d'un projet
 Un projet (informatique)
 un objectif
 des moyens
 des contraintes Espace
défini
par le projet
Objectif
moyens contraintes
4
Définition et terminologie
 Mais un projet c’est avant tout
 un besoin  objectif
 un processus
moyens
contraintes
Objectif
atteint
besoin
5
Définition et terminologie
 Qu’est ce qu’un projet?
 Une articulation de ressources humaines, intellectuelles et
matérielles agencées dans une organisation temporaire
dont le résultat escompté est un état final (finalisé ?) du
système tel que l’objectif prévu soit atteint dans l’espace
défini par les objectifs, moyens, et contraintes (un objectif
est caractérisé par un coût, un délai et des performances)
6
Définition et terminologie
 Autre définition
7
Définition et terminologie
 Etudier un projet c'est
 recenser et/ou définir les moyens
 recenser les contraintes
 définir un plan de développement du processus
 Gérer un projet c'est
 contrôler les moyens,
gérer les contraintes et
suivre le plan de développement
8
Définition et terminologie
 Etudier un projet c'est
 recenser et/ou définir les moyens
 recenser les contraintes
 définir un plan de développement du processus
 Gérer un projet c'est
 contrôler les moyens,
gérer les contraintes et
suivre le plan de développement
ESTIMATION
PLANIFICATION
ORGANISATION
PILOTAGE
SUIVI
9
Définition et terminologie
 Piloter/conduire un projet c'est
 comprendre les exigences stratégiques
 gérer le projet
 +
 animer (une équipe)
 vérifier la qualité
 traiter avec les fournisseurs (cadre juridique)
10
Crise de gestion de projets et GL
 Constats
 1994 : Rapport CHAOS (étude américaine sur 8000 projets)
 16% finalisés dans les temps et le budget prévus
 32% interrompus en cours de route
 Diagnostic
 Spécifications ambitieuses et Conception poussée
 Remise en cause de choix initiaux
 Mise à mal de la conception proposée
 Effet Tunnel
 Le processus correspond il aux besoins du projet ?
11
Etat des lieux
12
Crise de gestion de projets et GL
 Faits
 Sources principales de problèmes dans les spécifications :
 Erreurs
 Oublis
 Changements
 Définir un logiciel a priori est un exercice difficile sauf
dans le cas :
 D’applications extrêmement simples
 De rares contextes connus et maitrisés
 Le client a du mal à imaginer ce que sera l’application
 Conséquences
 Remises en question des spécifications
 Risques pour la conception liés au changement
13
Quelques Valeurs …
 Communication
 Développement: travail de groupe, effort collectif
 Avoir une vision commune et pouvoir se synchroniser
 Qualité de la communication
 Simplicité
 Eviter la complexité inutile dans le code
 Toute duplication doit être éliminée
 Retour d’information (Feedback)
 Boucles de feedback pour réduire les risques
 Connaître l’état du projet
 Apporter des rectifications si nécessaire
 Facteur de qualité
 Acquisition d’expérience
 Amélioration constante du travail
14
Gestion de projets: Motivations
15
Sana REFAI
sana.refai@gmail.com
2016-2017
Chapitre 2
Gestion de projets
16
Définition
17
 la discipline de gestion de projets poursuit la
satisfaction du client par la planification,
l'organisation, la direction et le contrôle des
ressources de l'entreprise afin de
compléter un projet spécifique à temp, avec le
budget alloué et selon les standrds de qualité de la
société
Gestion de projets: préoccupations
18
Les étapes de Gestion du projet
19
1. Initiation du projet
2. Estimation
3. Gestion des risques
4. Planification du projet
5. L’aspect humaine de gestion du projet
6. Exécution, progresse, contrôle et rapport du projet
7. Clôture du projet
Gestion de projets - intervenants
20
21
Etude préalable de projet
22
Initiation du projet , Etude de
faisabilité et définition du
projet
Avant-projet
23
 L’étape d’avant-projet représente
 l’étape initiale de tout projet. Elle est appelée également étape d’
 Étude préalable du projet
 Phase d’inception du projet
 l'ensemble des étapes préparatoires nécessaires au lancement du
projet
Idée du projet
Etude préalable du
projet
Lancer le projet
Abandonner le
projet
Avant-projet
24
 Avant-projet
 Il s'agit de définir précisément ce que sera le projet afin
d'aboutir à la mise au point de documents contractuels (faisant
lieu d'un contrat) permettant d'engager la maîtrise d'œuvre
(responsables de gestion et suivi projet) et la maîtrise
d'ouvrage (responsables des activités techniques du projet)
dans le lancement du projet
 Cette phase formalise donc la décision de commencer le
projet.
Etude préalable du projet
25
 L’étude préalable d’un projet intervient avant la phase
d’expression des besoins
 La plupart des projets nécessitent un stade initial au cours
duquel il faut répondre à certaines questions
 Quelle est la vision (objectif et contexte) du projet et quelle est
son opportunité?
 Le projet est-i-il réalisable?
 Faut-il construire et/ou acheter ?
 Quelle est l’estimation grossière du coût: doit-on envisager des
dizaines de milliers, des centaines de milliers ou des millions de
dinars?
 Faut-il poursuivre jusqu’à la réalisation du projet ou renoncer?
Etude préalable du projet
26
 A l’étape d’avant-projet ou étude préalable du projet, il faut
étudier quelques peu les besoins. Mais, cette étape n’a pas
pour but de définir tous les besoins et élaborer un plan de
projet
 L’idée est d’effectuer le minimum d’investigations pour
formuler une opinion rationnelle et justifiable de la finalité et
faisabilité du projet et du nouveau système potentiel associé
 L’objectif de cette phase est de
 décider s’il est raisonnable d’investir dans une étude plus
approfondie (l’objectif de la phase d’élaboration du projet)
 établir une vision initiale comme des objectifs du projet, de
déterminer si celui-ci est faisable (tenant compte des ressources
disponibles)
 étudier le contexte du projet et établir ses motivations
Etude préalable du projet
27
 L’étude préalable permet donc d'identifier les conditions de
développement de ces activités :
 Étude des marchés des produits et services,
 Viabilité technico-économique du projet,
 Compétences disponibles/requises,
 Outils et moyens de financement de l'activité,
 Impact social
 ...
Etude préalable du projet
28
 Etude de marché et de l’existant
 L’étude préalable consiste principalement à recenser
l’existant c'est-à-dire les solutions informatiques déjà mises
en œuvre dans l’entreprise et à recenser les besoins
notamment en termes de fonctionnalités nouvelles.
 Elle comprend également l’étude des applications similaires
sur le marché
 Elle peut être l’occasion d’une étude de rentabilité du
projet.
 L'étude préalable identifie les contraintes budgétaires, les
contraintes d'environnement et les contraintes juridiques.
Etude préalable du projet
29
 Remarques
 La phase d’étude préalable est relativement courte. Elle ne
dépasse pas généralement quelques semaines
 Dans de nombreux projets si cette phase dépasse une
semaine, c’est un signe que son objectif n’a pas été bien
compris. Il s’agit de décider si le projet mérite une étude
sérieuse ou non
 Si la décision de réaliser le projet a été déjà prise et si sa
faisabilité est évidente, la phase d’étude préalable sera
particulièrement brève
 La phase d’étude préalable peut inclure un certain volume de
programmation destinée à créer des prototypes (interfaces
utilisateur) afin d’expliquer et mieux illustrer un certain nombre
de besoins
Comment le processus commence?
30
 Raffiner l’idée du projet en des objectifs à atteindre:
- fonctionnels et qualité
- cout et gain
- Temps
• Les acteurs de cette phase sont :
Les différents acteurs
Equipe de projet
Autres groupes
Chef de projet
Mandant
Direction
Client(s)
31
Acteurs d’un projet
 a
 b
32
Acteurs d’un projet
33
Les étapes de l’étude de la faisabilité
34
 Comprendre la complexité du projet.
 Allouer les bonnes ressources pour faire l’étude de
faisabilité du projet.
 Raffiner et détailler tous les objectifs du projet.(
cahier des charges et rapport de spécifications )
 Evaluer l’acheivement, le temps et les risques.( on
peut concevoir un prototype).
 Ecrire un document qui synthétise cette étude de
faisabilité.
Phase de resourcement
35
 Ressources de différentes équipes: toute type
d’expertise est demandé pour achever le projet.
 La mauvaise allocation des ressources va impacter:
- La date de début du projet.
- Mal évaluation du projet.
- générer un cout extra
- peut causer l’échec du projet.
Analyse des problèmes
Adaptation de [Buttrick]
Pas de structure
de projet
Pas de stratégie
claire
Projets pas alignés
sur la stratégie
Projets commencés ne sont
pas les bons
Projets échouent, annulés,
retardés
Manque de rigueur et de
méthodes
Critères de décisions
inadéquats
Trop de projets
commencés
Ressources surexploitées
36
Gestion des exigences( requirement)
37
 Les objectifs d’un projet doivent être :
o Specific: Spécifique
o Measurable: Mesurable
o Ambitious: Ambitieux
o Reaslistic: Réaliste
o Time-bound: Dans le temps
Gestion des exigences( requirement)
38
 Construire le bon produit
 Comprendre ce que vous devez construire.
 Construire les objectifs le plus important d’abord.
 Gérer le changement des exigences.
 Reduire le retravail , faciliter le test, Minimiser l’impact de
changement des exigences, ne pas perdre l’usage des ressources
Exigences spécification, vérification et
évaluation
39
 Ecrire les exigences dans un document structuré:
o Label + identifiant unique
o Identifier l’origine de chaque exigence ( créer une matrice
de traçabilité)
Initiation du projet : objectif
40
 Décider si le projet va continuer ou non.
 Annoncer l’affectation des ressources et les dates.
 Annoncer l’équipe du projet.
 Cette phase a comme sortie: un document de spécification des
exigences ( cahier des charges), définiton des responsabilités (
chef du projet, équipe).
 Un document de planification du temps et des ressources.
41
Estimation
Introduction
42
 Principe de l’estimation:
 Pourquoi estimer quand, qui va faire ça?
 C’est quoi l’estimation.
 Qu’est on va estimer
 Estimation de l’effort
 Les techniques d’estimation
 Aspects humaines de l’estimation
Pourquoi estimer quand, qui va faire ça?
43
Pourquoi? Quand estimer ? Qui estime ?
Définir le budget et l’espace
temporelle
 Durant l’initiation du
projet
Chef du projet + les
experts
Aider dans le processus de
planification
Au lancement du projet  Chef du projet + l’équipe
de travail( nouvelle estimation
ou garder la même)
Prendre en considération des
événements particulières qui
peuvent avoir lieu
 Durant le déroulement du
projet
Aider à suivre le pogrés du
projet.
C’est quoi l’estimation
44
 Un engagement: pas une simple prédiction
 Une ligne de base: pour suivre les progrès futurs
 Non seulement un numéro:
Hypothèses
Conditions préalables
raisonnement
Qu’est on va estimer
45
 On peut estimer 3 caractéristiques du projet: l’effort
( travail à faire), la durée et le coût.
 Les 3 sont inter-dependants mais l’estimation de
l’effort reste la plus pertinente.
 Quand on estime l’effort, on calcule généralement la
durée et le coût.
Comment estimer l’effort?
46
 Effort = travail à faire
 Effort exprimé en homme.temp ( Homme.jour,
homme.semaine, homme.mois) pour un travail fait
par une personne.
 Relation entre Effort et durée:
 Durée = Effort /Resource allouée
 Pour une personne à plein temps: Durée= Effort
 Pour une personne à moitié temps: Durée= Effort/0,5
 Pour 2 personnes à plein temps: Durée= Effort/2
Les techniques d’estimation
47
 Delphi
 Proxy-based méthodes
 Bottom-up méthodes
Comment estimer ? Delphi(1/2)
48
 Un coordinateur et 5 à 10 estimateurs (experts et
spécialistes).
 Identifier qu’est on va estimer.
 Après, chaque estimateur donne son estimation
sans communiquer aux autres.
 3 tours(Round) d’estimation avec retour
d’information( feedbacks)
 la moyenne finale est le résultat
Comment estimer ? Delphi(2/2)
49
 Round 1: estimation libre
 Le coordinateur demande une estimation de chaque expert.
 Le coordinateur calcule et annonce la moyenne
 Round2: Argument
 Ayant connu la première moyenne, chaque expert donne son estimation
avec des arguments( Les raisons pour être >ou < à la moyenne).
 Le coordinateur calcule et annonce la nouvelle moyenne et une liste des
pilotes ( arguments pour être <) et des risques ( arguments pour être >)
 Round 3: Evaluation
 Le coordinateur demande les dernières estimations
 la moyenne finale est le résultat
Comment estimer ? Proxy-based méthodes (1/2)
50
 C’est quoi est le proxy?
Quelque chose qui représente la taille /la
complexité de la chose que vous voulez estimer.
 Exemples de proxies:
 Nombre de ligne de code.
 Nombre de use-case
 Nombre d’interface graphique
 Nombre des tables dans une BD
Comment estimer ? Proxy-based
méthodes (2/2)
51
 Estimer la taille en utilisant le proxy convenable.
 Appliquer un facteur d'échelle pour calculer l'effort
de développement
 Peut être utilisée pour dériver d'autres indicateurs
utiles
 Quantité de la documentation attendues.
 Nombre des tests.
 Nombre d’erreurs prévus
Comment estimer ? Bottom-up méthodes
52
 Décomposer le projet en tâches compréhensibles
 Fournir des estimations pour chaque tâche
individuelle:
 Delphi
 Best Case/Most likely/Worst case
 Calculer l'effort probable de la tâche:
 Additionner les résultats pour obtenir une estimation
globale
 Calcule de la déviation(optionnelle)
E= (Best case + (4*Most likely) +Worst Case)/6
S= (Worst Case - best Case) / 6
Quelle technique dans quel but?
53
Niveau Technique Pourquoi
Dans
l'ensemble du
projet
Delphi
Proxy-based
Méthodes
idée générale
de
l'estimation
détaillé Botton-up
Méthode
ordonnancem
ent détaillé,
suivi du projet
(estimation
précise
requise)
54
Gestion des risques
Gestion des risques
55
 Principe de gestion des risques:
 Terminologies
 But de gestion des risques
 Processus de gestion des risques.
 FMEA: Techniques de gestion de risque
Terminologies(1/2)
56
 Risque:
 un effet réel ou potentiel qui implique une perte ou un
dommage
 Un résultat indésirable, un danger
 Il est caractérisée par sa sévérité
 Facteur de risque:
 A cause de l'effet potentiel (il peut y avoir des causes
multiples pour le même effet )
 Une origine, une source
 Il est caractérisée par sa probabilité et la gravité (la
sévérité) de l'effet qu’il peut générer.
Remarque: par voie orale, nous utilisons risque pour décrire
quelque chose qui peut être un facteur de risque
Terminologies(2/2)
57
 Exemple:
Risque Facteur de risque
Le logiciel est livré en
retard
Le développeur est
nouveau
Le produit est sur le
marché en retard
Insuffisance des
ressources (
ingénieurs)
Objectifs de gestion des risques
58
 Anticiper les problèmes: concernant le projet, le
produit et le processus
 Déployer des actions correctives pour minimiser la
perte de l'entreprise ( Il ne faut pas dépenser plus
que vous gagner)
 Réduire les risques
Rôle du chef du projet
59
 Outils de suivi intègrent l'analyse des risques en
mesurant Coût du projet , le calendrier et la qualité
(obtenue vs ciblée).
 Le chef du projet a pour rôle de faire en sorte que
les risques sont suivis, documentés, visés et
atténués
 dans l'analyse de faisabilité
 pendant toute la durée du projet
Méthode de gestion des risques
60
 Qu'est-ce qui peut aller mal?
 Que pouvons-nous faire pour nous assurer que cela
ne se produira pas?
 S’il arrive ?
 Ce que je peux apprendre pour le futur
Processus de gestion des risques
61
1-identifié
2-analyser
3-Plannifier
4-Suivre
5-Contrôler
1-Identifier les risques
62
 Histoire passée
 votre expérience de projet précédent
 d'autres projets similaires
 liste de contrôle des risques génériques
 utiliser un existant de projets antérieurs
 construit un nouveau en améliorant un existant
 Recherche sur internet
 brainstorming d'équipe
 analyse interne
2-Analyser les risques
63
 Comment saurez-vous si cela se produit?
 Quand cessera il d'être un risque?
 Priorisation
 Probabilité (fréquence ou occurrence)
 Impact
 ces facteurs vont influencer votre choix de la
stratégie de gestion des risques.
3-Planifier les risques (stratégie)
64
 Eliminer les risques.( prévention)
 Contrôler les risques(réduire la probabilité et
l’impact)
 Monitorer les risques: faire des évaluations
périodiques des risques.
 Accepter les risques: prendre en considération les
conséquences.( dans certains cas de figures)
3-Planifier les risques (Résultats)
65
 Plan de gestion des risques(règles, cycle de revue,
organisation et responsabilité)
 Registre des risques: une liste de priorité des
risques identifiés:
 Description
 Probabilité, impact, numéro de priorité de risque
 Stratégie de réduction des risques
 Actions préventives
 Actions correctives
 Liste des actions
4-5 Suivre et contrôler les risques(1/3)
66
 Objectif: réduire le nombre de risque dans un projet.
 Des revues internes régulières ( …et dans les cas
nécessaires) .
 Suivre:
 Re-Évaluation des risques.
 Vérification de l’exécution de la stratégie de réduction
des risques.
 Suivre l’évolution de l’indice de priorité de risque par
rapport aux actions prises.
4-5 Suivre et contrôler les risques(2/3)
67
 Contrôler:
 Identifier et analyser des nouveaux risques.
 Re-planifier les actions de réduction des risques.
 Identifier et affecter des nouvelles actions si
nécessaire.
 Des rapports réguliers à travers le réunion de révu
du projet.
4-5 Suivre et contrôler les risques(3/3)
68
Entrée
-Plan de gestion
de risques
-Registre des
risques
-- les rapports de
weekly
-- liste des
actions
Étape de suivi et
de contrôle des
risques
Sortie
-Une liste de
actions( mis à
jour)
-- le registre
des risques
(mis à jour)
69
FMEA (Failure Mode and Effect Analysis)
AMDEC (Analyse des modes de défaillance, de leurs effets &
criticité)
défaillance, de leurs effets & criticité
Introduction
70
 L'AMDEC,est l'équivalent français de la FMEA Failure
Mode, Effects, and Criticality Analysis.
 Comme son intitulé l'indique clairement, il s'agit d'une
méthode conçue spécifiquement pour identifier les
modes de défaillance d'un produit ou d'un processus.
 Cette démarche exige rigueur et précision, son efficacité
est à ce prix. L'AMDEC, ou plutôt son équivalent
américain le FMEA, est née au sein de l'industrie
aéronautique durant les années 1960. L'industrie
automobile l'a ensuite rapidement adoptée. Aujourd'hui,
les applications de l'AMDEC comme outil d'analyse des
risques sont aujourd'hui multiples.
C’est quoi AMDEC ?
71
 Une démarche préventive
Cette méthode est à vocation préventive. C'est un
précieux outil pour s'assurer de la faisabilité d'un
cahier des charges en respect des spécifications
clients et des exigences réglementaires.
 Le principe
La démarche est complète. Elle propose de lister puis
d'organiser les modes de défaillances prévisibles et
les conséquences lors de la conception d'un produit
ou de la mise en oeuvre d'un processus.
Déroulement de l'analyse AMDEC(1/4)
72
Déroulement de l'analyse AMDEC(2/4)
73
Cause → Mode de défaillance → Effet
 Une analyse de type AMDEC se déroule en un mode participatif. Il
s'agit de profiter de l'expérience de tous.
 La méthode se déroule en 5 temps majeurs selon le processus ci-
après :
1) Préparation
 Préparation et constitution des groupes de travail.
C'est une étude exigeante. Les participants devront s'impliquer
sérieusement et accorder le temps nécessaire pour réaliser
correctement la part d'étude dont ils ont la charge.
 Précision de l'objet de l'étude, de son périmètre et de sa portée
Les objectifs attendus seront énoncés concrètement et en accord
avec les besoins des commanditaires de l'étude et des participants à
sa réalisation.
Déroulement de l'analyse AMDEC(3/4)
74
2) Analyse fonctionnelle et Préparation de l'étude de
défaillance
Découpage fonctionnel: Comme son intitulé l'indique
clairement, il s'agit de lister et de mettre en relation toutes
les fonctions du produit ou les phases du processus afin
d'identifier les causes de dysfonctionnement potentiel
3) Identification
Identification des défaillances potentielles : Il s'agit de
réaliser une étude rationnelle des modes de défaillance
potentiels, des causes et des effets. La réussite de cette
troisième étape est directement dépendante du soin apporté au
découpage fonctionnel. Elle exige une participation élargie de
toutes les personnes susceptibles d'apporter un enseignement
le plus souvent issu de leur propre expérience.
Déroulement de l'analyse AMDEC(4/4)
75
4) Valorisation des défaillances potentielles et Etude de la criticité
Etude de la criticité en tenant compte de la gravité, de la probabilité
d'occurrence et de la capacité de détection (warning)
Au cours d'une démarche participative, on établi:
 la gravité potentielle sur une échelle de 1 à 4 (de mineure à
gravissime),
 la fréquence estimée sur une échelle de 1 à 4 (exceptionnelle à
certain)
 la capacité de détection sur une échelle de 1 à 4 (Evident à
indetectable)
 La criticité est le produit de ces trois évaluations.
5) Actions Correctives
Identification des actions préventives à conduire, des Identification des
actions palliatives possibles et Identification des actions correctives
.(sans oublier la question du coût de chacune des actions envisagées)
La criticité
76
 La criticité, fréquence, gravité et détection, s'exprime
habituellement sur une échelle limitée pouvant atteindre
jusqu'à 10 niveaux selon les cas (bien que 4 niveaux
soient suffisants pour les cas les plus courants).
 La criticité permet de hiérarchiser les différentes causes
de défaillances et contribue à évaluer les actions à
entreprendre.(Les niveaux 9 et 10, les plus élevés)
 NPR (Nombre pour Prioriser les Risques) NPR =
S*O*D = criticité*fréquence*gravité et détection
 S( Severity), O ( Occurence), D(Detection)
Le formalisme AMDEC(1/3)
77
R
P
N
D
e
t
O
c
c
Se
v
Redondanc
e
DétectionCauseEffetModeItem/fonction
Le formalisme AMDEC(2/3)
78
Mode
de
défaillance
Item/Function
Effet 1
Effet 2
Cause 1
Cause2
Prévention Détection
Le formalisme AMDEC(3/3)
79
 L’évaluation du risque
Mode
de
défaillance
Item/Function
Effet 1Cause 1
Prévention Détection
Sev
Occ
Det
*
*
RPN
Calcul de la criticité IPR (Indice de Priorisation du Risque)
IPR = G x O x N
(G : Gravité, O : probabilité d'occurrence, N : non détection)
G Gravité
1 Effets mineurs
2 Effets significatifs
3 Effets critiques
4 Effets catastrophiques
O Probabilité d'occurrence
1 Très faible
2 Faible
3 Moyenne
4 Forte
N Non détection
1 Très efficace
2 Efficace
3 Détection peu fiable
4 Aucune détection possible
Évaluation des défaillances – Analyse de la criticité
Évaluation des défaillances – Analyse de la
criticité
 Cotation de la criticité souvent effectuée en fonction des deux seuls critères de gravité et de
probabilité d’occurrence de la défaillance.
 Représentation de la criticité sous forme matricielle (Grille de criticité).
Calcul de la criticité IPR (Indice de Priorisation du Risque)
GRAVITE
G
1 2 3 4
O
O 1
C
C
U 2 I
R
R
E 3 II
N
C
E 4
I : Zone non critique
II : Zone critique
Grille pour la sévérité
82
Hazardous without warning
Very high severity ranking when a potential failure
mode effects safe system operation without warning
10
Hazardous with warning
Very high severity ranking when a potential failure
mode affects safe system operation with warning
9
Very High
System inoperable with destructive failure without
compromising safety
8
High System inoperable with equipment damage 7
Moderate System inoperable with minor damage 6
Low System inoperable without damage 5
Very Low
System operable with significant degradation of
performance
4
Minor
System operable with some degradation of
performance
3
Very Minor System operable with minimal interference 2
None No effect 1
Grille pour l’occurence
83
PROBABILITY of Failure Failure Prob Ranking
Very High: Failure is almost inevitable >1 in 2 10
1 in 3 9
High: Repeated failures 1 in 8 8
1 in 20 7
Moderate: Occasional failures 1 in 80 6
1 in 400 5
1 in 2,000 4
Low: Relatively few failures 1 in 15,000 3
1 in 150,000 2
Remote: Failure is unlikely <1 in 1,500,000 1
Grille de la détection
84
Detection Likelihood of DETECTION by Design Control Ranking
Absolute Uncertainty
Design control cannot detect potential
cause/mechanism and subsequent failure mode
10
Very Remote
Very remote chance the design control will detect
potential cause/mechanism and subsequent failure
mode
9
Remote
Remote chance the design control will detect potential
cause/mechanism and subsequent failure mode
8
Very Low
Very low chance the design control will detect potential
cause/mechanism and subsequent failure mode
7
Low
Low chance the design control will detect potential
cause/mechanism and subsequent failure mode
6
Moderate
Moderate chance the design control will detect potential
cause/mechanism and subsequent failure mode
5
Moderately High
Moderately High chance the design control will detect
potential cause/mechanism and subsequent failure
mode
4
High
High chance the design control will detect potential
cause/mechanism and subsequent failure mode
3
Very High
Very high chance the design control will detect potential
cause/mechanism and subsequent failure mode
2
Almost Certain
Design control will detect potential cause/mechanism
and subsequent failure mode
1
Proposition d’actions en réduction de
risques
85
 Mise en place d’actions correctives.
 Diminution de la criticité des causes de défaillance :
 Réduction de la probabilité d’occurrence des modes
de défaillances ou,
 réduction de la gravité des effets.
 Réactualisation de la cotation de la criticité à chaque
mesure prise.
Les mesures correctives
Optimiser et développer
la maintenance
Corrective
Préventive
Améliorative
 Diminution du MTTR
 Meilleure gestion des pièces
de rechange
 Développement d'un système
d'aide au diagnostic
 Optimisation des opérations de
maintenance préventive
 Mise en oeuvre de nouvelles
opérations
 Augmentation de la SdF
 Augmentation du MTBF
 Amélioration de la sécurité
des opérateurs
Proposition d’actions en réduction de risques
Suivi et contrôle des actions
• Formulation de recommandations qui font l’objet de
plans d’actions.
• Vérification de la bonne mise en œuvre de ces plans
d’actions.
• Analyse de l’impact des modifications proposées
Exploitation de l’AMDEC
• L’AMDE(C) permet de générer une base d’informations
de référence tout au long de la vie du produit.
• L’exploitation se traduit par une liste de synthèses :
• Liste des effets de défaillances,
• Liste des articles critiques,
• Liste des symptômes observables,
• Liste des points de panne unique,
• Liste des défaillances non détectées,
• Liste des modes communs, …
Limites de l’AMDEC
• N’est pas une méthode de résolution de problèmes.
• Ne peut pas garantir l’exhaustivité de l’étude.
• Est une méthode fastidieuse pour l’étude des systèmes
complexes.
Etude de cas
90
……
 ( risques humaines et Risques naturels)
91
Planification du projet
Rappel
92
Définition de la planification du projet
93
 Discipline ayant pour objectif de positionner les
activités ou tâches d’un projet les unes par rapport
aux autres.
 La planification a pour objectif de prévoir, suivre et
maitriser la réalisation d’un ouvrage en délais et en
coût.
Construire le planning
Comment s’y prendre
94
 REPONDRE AU «QUOI»
•Que doit-on faire ?
 REPONDRE AU «QUAND»
•Ordre des tâches ?
 REPONDRE AU «QUI»
•Qui peut faire quoi ? De qui ai-je besoin ?
 REPONDRE AU «COMBIEN DE TEMPS»
•Durée des tâches ?
Outils d’aide à la structuration
95
 Product Breakdown Structure (PBS) Ou
Organigramme de produit ou Arbre produit
 Work Breakdown Structure (WBS) Organigramme
des tâches
 Organisation Breakdown Structure (OBS)
Product Breakdown Structure (PBS)
96
 Qu’est-ce que c’est ?
Une décomposition Hiérarchique (structure d’arbre)
et Exhaustive de l’ensemble des livrables du projet
(physique, fonctionnel ou conceptuel)
 Dans quel but ?Simplifier le projet pour:
•Le rendre gérable / maitrisable
•Valider la compréhension du besoin
•Communiquer / Echanger
•Etablir le worksharing industriel
•Identifier les niveaux d’intégration
WorkBreakdown Structure (WBS)
97
 Qu’est ce que c’est?
Une décomposition •Exhaustive •Hiérarchique, •Axée
sur les tâches et activités, du travail à réaliser pour
atteindre les objectifs du projet
 Dans quel but ?
 Aider à: •Organiser le projet, •Bâtir le macro-
planning •Établir le budget prévisionnel. •Identifier
les travaux sous-traités
Organisation Breakdown Structure (OBS)
98
 QU’EST-CE C’EST ?
Structuration organisationnelle des responsabilités
 A CHAQUE ELEMENT DU WBS (work package, lot,
sous-projet)
• Un responsable (Accountable)
-Un individu
-Un service de l’entreprise
-Un prestataire extérieur
• En charge de sa gestion de projet
-Organisation -Planning -Suivi
Lien entre PBS et WBS
99
99
Project
Subproject
System
subsystem
Task
PBS
WBSPhase
Work Batch COHERENCY:
→Tasks must realize subsystem
←Subsystem must be built by
tasks
100
100
Need
System
Sub System
Product
Task
Involved agency
Steering comity
Office
Team
People
Flux
PBS-WBS / OBS
Structuration d’un projet
101
Exemple1
102
Projet info :
Logiciel version 2.0
Management
projet
Spécification
produit
Conception
détaillée
Planification
Réunions
Gestion
Logiciel
Manuel
d’utilisateur
Documents
de formation
Logiciel
Manuel
d’utilisateur
Documents
de formation
Réalisation
Logiciel
Manuel
d’utilisateur
Documents
de formation
Intégration
et tests
Logiciel
Manuel
d’utilisateur
Documents
de formation
Projet info :
Logiciel version 2.0
Management
projet
Spécification
produit
Conception
détaillée
Planification
Réunions
Gestion
Logiciel
Manuel
d’utilisateur
Documents
de formation
Logiciel
Manuel
d’utilisateur
Documents
de formation
Réalisation
Logiciel
Manuel
d’utilisateur
Documents
de formation
Intégration
et tests
Logiciel
Manuel
d’utilisateur
Documents
de formation
Work breakdown structure-WBS
(Organigramme des tâches de projet)
 Objectifs
 Identifier les travaux à compléter
 Traduire la définition du projet en une liste de tâches à accomplir
 La planification structurelle consiste à préparer une liste
exhaustive, documentée et structurée des travaux dont
l’accomplissement est nécessaire à la production des biens
livrables du projet
 Caractéristiques
 Constitution d’une base de données des travaux
 Sert de base aux autres étapes de planification
 Principal instrument de communication entre les intervenants
 Identification et description des lots principaux de travail
 Identification et description des tâches élémentaires
103
Etapes
104
 Planification structurelle sommaire
 Subdiviser le projet en lots de travail
 Un lot = un bien livrable du projet
 Toujours prévoir les lots de support pour tâches
ponctuelles
 Planification structurelle détaillée
 Subdiviser les lots de travail principaux jusqu’à
l’identification de tâches élémentaires
 Représentation à l’aide d’un organigramme de tâche
(Work Breakdown Structure)
Planification en lots de travail
105
 Principe de base
 Découpage du projet en paquet de tâches tout d'abord
à un niveau global
 pour ensuite découper chacun de ces paquets en un
2ème niveau plus détaillé
 et ensuite encore en paquets plus élémentaires, etc.
 Critères de découpage : 1ère condition
 « Tout ce qui peut donner lieu à des dépenses, à des
lots de travail quelle qu'en soit la nature tout ce qui
peut constituer un délai d'attente, une durée, doit
donner lieu à un paquet dans l'OT »
OT: Organigramme de
tâches
Tâches
106
 Tâche élémentaire
 Travail ponctuel
 Résultat est un produit concret (information, rapport,
composante du produit, etc.)
 Tâches de support
 Pas des préoccupations continues (contrôle financier,
gestion, etc.)
 Tâches ponctuelles de gestion (approbations,
révisions,etc.)
Exemple de décomposition
Application de commerce électronique
107
 Organigramme
Exemple de décomposition
Application de commerce électronique
108
Activités du support du niveau 1
 Gestion de configuration
 Gestion des changements
 Établissement et gestion des espaces de travail
 Définition des situations de base
 Gestion de projet
 Gestion des risques
 Gestion des échéanciers
 Gestion du budget
 Contrôle de l’avancement
 …….
Exemple de décomposition
Application de commerce électronique
109
 Décomposition niveau 2
Exemple de décomposition
Application de commerce électronique
110
 Activités niveau 3
 Activités liées au développement du produit pour
chacun des composantes
 À partir d’un processus défini
 Activités de développement technique
 Activités de support
 Activités spécifiques de gestion de configuration
 Activités spécifiques de gestion de projet
Exemple de décomposition
Application de commerce électronique
111
 Décomposition - Niveau 3
Exemple de décomposition
Application de commerce électronique
112
 Gestion de configuration
Exemple de décomposition
Application de commerce électronique
113
 Tâche élémentaire – Niveau 4
114
PERT
Program Evaluation and Review Technic
Introduction
115
Le réseau PERT
 Program Evaluation and Review Technic
 Les tâches sont représentées par des flèches
 Le réseau visualise des dépendances entre tâches
Réseau PERT
116
 Les paramètres clés
 Recherche du chemin critique
 Met en évidence les tâches qui risquent de retarder la
fin du projet si elles sont en retard.
 Pour chaque tâche dont on a estimé la durée on
calcule :
 Les dates de début et de fin « au plus tôt » et « au
plus tard »
 La marge
Quelques notions(1/2)
117
 Date au plus tôt : c’est la date à laquelle on peut
commencer en fonction des dépendances aux
autres tâches
 Date au plus tard : date à laquelle une tâche peut
commencer au plus tard sans remettre en cause la
date de fin de projet
 Marge totale
Date début plus tard - date début plus tôt
Quelques notions(2/2)
118
 Chemin critique
Constitué d’une suite des tâches ayant une marge
totale égale à zéro
Tout retard sur une tâche du chemin critique
affecte la date de fin du projet
Graphe Pert : calcul des dates au plus tôt
119
 Calcul de proche en proche à partir de la date de début au plus
tôt du projet
 Pour les tâches Ti, de durée estimée di qui se trouvent en début de
projet
 Date de début au plus tôt avec t0 = date de début de projet
 Début_au_plus_tôt (Ti) = t0
 Date de fin au plus tôt
 Fin_au_plus_tôt (Ti) = t0+ di
 Pour une tâche Ti, de durée estimée di
 Date de début au plus tôt
 Début_au_plus_tôt (Ti) = sup (Fin_au_plus_tôt (prédécesseurs (Ti)))
 Date de fin au plus tôt
 Fin_au_plus_tôt(Ti) = Début_au_plus_tôt (Ti) + di
Graphe Pert : calcul des dates au plus
tard
120
 On fait l ’hypothèse d ’une date de fin de projet
(fonctionnement par date limite)
 On parcourt le graphe en sens inverse
 Pour les dernières tâches, si tf est la date limite de fin du
projet,
 Fin_au_plus_tard (Tfi) = tf
 Pour les autres tâches
 Fin_au_plus_tard (Ti) = inf (Début_au_plus_tard (successeurs))
 Début_au_plus_tard (Ti) = Fin_au_plus_tard (Ti) – di
Exemple 1
121
de A …. Jusqu’à Z
Analyse du projet(1/2)
122
122
Project
FurnitureStudies ToolingFacility layout Acceptance
Machining
Supplies
Assembly
Supplies
Machining
substructure
Machining
installation
Assembly
substructure
Assembly
installation
Acceptance
tests
Layout
Studies
Ganty
crane
installation
Analyse du projet(2/2)
123
FurnitureStudies Tooling
Facility
layout
Acceptance
A
Machining
Supplies
B
Assembly
Supplies
D
Machining
substructure
E
Machining
installation
F
Assembly
substructure
G
Assembly
installation
I
Acceptance
tests
C
Layout Studies
H
Ganty crane
installation
Identifier les tâches(1/2)
124
N° Label
Deb Start
A Purchase & receipt of machining tools
B Purchase & receipt of assembly tool
C Study the facility layout
D Execute the facility layout for machining
E Install machining tools
F Execute the facility layout for assembly
G install assembly tools
H Install the gantry crane
I Perform acceptance tests
Fin End
Identifier les tâches(2/2)
125
Deb Start NIL
A Purchase & receipt of machining tools Deb
B Purchase & receipt of assembly tool Deb
C Study the facility layout Deb
D Execute the facility layout for machining C
E Install machining tools A,D
F Execute the facility layout for assembly C
G install assembly tools B,F
H Install the gantry crane C
I Perform acceptance tests E,G,H
Fin End I
N° Label Anterior
tasks
Tracer le réseau
126
A
D
C
B
F
E
H
G
I
0
Start
Estimation de durée
127
Deb Start / 0
A Purchase & receipt of machining tools Deb 7
B Purchase & receipt of assembly tool Deb 3
C Study the facility layout Deb 5
D Execute the facility layout for machining C 5
E Install machining tools A,D 5
F Execute the facility layout for assembly C 3
G Install assembly tools B,F 3
H Install the gantry crane C 7
I Perform acceptance tests E,G,H 1
Fin End I 0
N° Label Anterior Duration
tasks
Calcul des dates
128
A
D
C
B
F
E
H
G
I
0
7 5
5
3
5
3
7
3
1
Dtot
Début au plus tôt
Ftot
Fin au plus tôt
Ftard
Fin au plus tard
Dtard
Début au plus tard
Duration
Début Fin
Chemin Critique
129
A
D
C
B
F
E
H
G
I
0
7 5
5
3
5
3
7
3
1
0
0
0
7
5
3
5 10
5 8
10 15
5 12
8 11
15 16
16 16
1615
1510
158
1512
105
129
103
50
0
129
0
0
0
0
3
3
4
49
130
GANTT

Contenu connexe

Tendances

Chapitre2 les formes entrepreneuriales
Chapitre2 les formes entrepreneurialesChapitre2 les formes entrepreneuriales
Chapitre2 les formes entrepreneurialesCharfi Mohamed Amin
 
Conduite et gestion de projet
Conduite et gestion de projetConduite et gestion de projet
Conduite et gestion de projetJCI Ariana
 
Le secteur bancaire au maroc
Le secteur bancaire au marocLe secteur bancaire au maroc
Le secteur bancaire au marocCherradi -
 
Le Pouvoir en Entreprise
Le Pouvoir en EntrepriseLe Pouvoir en Entreprise
Le Pouvoir en EntrepriseHR SCOPE
 
Gestion des Ressources Humaines et RSE
Gestion des Ressources Humaines et RSEGestion des Ressources Humaines et RSE
Gestion des Ressources Humaines et RSEADHERE RH
 
Entrepreunariat, une solution de développement pour la région
Entrepreunariat, une solution de développement pour la régionEntrepreunariat, une solution de développement pour la région
Entrepreunariat, une solution de développement pour la régionMohamed Amin Ouni
 
LEADERSHIP.ppt
LEADERSHIP.pptLEADERSHIP.ppt
LEADERSHIP.pptmoha750516
 
Projet de création d'entreprise: exemple
Projet de création d'entreprise: exempleProjet de création d'entreprise: exemple
Projet de création d'entreprise: exempleYassineHammoucha
 
Webinaire - La matrice pouvoir et intérêt
Webinaire - La matrice pouvoir et intérêtWebinaire - La matrice pouvoir et intérêt
Webinaire - La matrice pouvoir et intérêtPMI-Montréal
 
Gestion des connaissances (Knowledge Management)
Gestion des connaissances  (Knowledge Management)Gestion des connaissances  (Knowledge Management)
Gestion des connaissances (Knowledge Management)Hanen Bensaad
 
Redaction technique administrative
Redaction technique administrativeRedaction technique administrative
Redaction technique administrativeRabah HELAL
 
management qualité
management qualitémanagement qualité
management qualitéIhab Anfawi
 
Plan d'action pour le management de la qualite
Plan d'action pour le management de la qualitePlan d'action pour le management de la qualite
Plan d'action pour le management de la qualitePaul Henri KOUAKOU
 

Tendances (20)

Communication professionnelle
Communication professionnelleCommunication professionnelle
Communication professionnelle
 
Chapitre2 les formes entrepreneuriales
Chapitre2 les formes entrepreneurialesChapitre2 les formes entrepreneuriales
Chapitre2 les formes entrepreneuriales
 
Conduite et gestion de projet
Conduite et gestion de projetConduite et gestion de projet
Conduite et gestion de projet
 
Le secteur bancaire au maroc
Le secteur bancaire au marocLe secteur bancaire au maroc
Le secteur bancaire au maroc
 
Le Pouvoir en Entreprise
Le Pouvoir en EntrepriseLe Pouvoir en Entreprise
Le Pouvoir en Entreprise
 
Gestion des Ressources Humaines et RSE
Gestion des Ressources Humaines et RSEGestion des Ressources Humaines et RSE
Gestion des Ressources Humaines et RSE
 
Initiation à la gestion de projet
Initiation à la gestion de projetInitiation à la gestion de projet
Initiation à la gestion de projet
 
Entrepreunariat, une solution de développement pour la région
Entrepreunariat, une solution de développement pour la régionEntrepreunariat, une solution de développement pour la région
Entrepreunariat, une solution de développement pour la région
 
LEADERSHIP.ppt
LEADERSHIP.pptLEADERSHIP.ppt
LEADERSHIP.ppt
 
Projet de création d'entreprise: exemple
Projet de création d'entreprise: exempleProjet de création d'entreprise: exemple
Projet de création d'entreprise: exemple
 
Formation Gestion de projet
Formation Gestion de projetFormation Gestion de projet
Formation Gestion de projet
 
Webinaire - La matrice pouvoir et intérêt
Webinaire - La matrice pouvoir et intérêtWebinaire - La matrice pouvoir et intérêt
Webinaire - La matrice pouvoir et intérêt
 
Gestion des connaissances (Knowledge Management)
Gestion des connaissances  (Knowledge Management)Gestion des connaissances  (Knowledge Management)
Gestion des connaissances (Knowledge Management)
 
Redaction technique administrative
Redaction technique administrativeRedaction technique administrative
Redaction technique administrative
 
Exo pert
Exo pertExo pert
Exo pert
 
controle de gestion.pptx
controle de gestion.pptxcontrole de gestion.pptx
controle de gestion.pptx
 
management qualité
management qualitémanagement qualité
management qualité
 
La planification du projet
La planification du projetLa planification du projet
La planification du projet
 
Plan d'action pour le management de la qualite
Plan d'action pour le management de la qualitePlan d'action pour le management de la qualite
Plan d'action pour le management de la qualite
 
Memoire de master en GRH
Memoire de master en GRHMemoire de master en GRH
Memoire de master en GRH
 

Similaire à Gestion de projets

Gestion de Projets
Gestion de Projets Gestion de Projets
Gestion de Projets Said Sadik
 
Gestion_de_projet_manager_Le_leader.pptx
Gestion_de_projet_manager_Le_leader.pptxGestion_de_projet_manager_Le_leader.pptx
Gestion_de_projet_manager_Le_leader.pptxmazuyabernard83
 
Gestion_de_projetOK.pptx
Gestion_de_projetOK.pptxGestion_de_projetOK.pptx
Gestion_de_projetOK.pptxOlyvierNzighou1
 
Gp 04 Le Plan Directeur
Gp 04   Le Plan DirecteurGp 04   Le Plan Directeur
Gp 04 Le Plan DirecteurClaude Michaud
 
Acquisition, Conception et Implantation des SI
Acquisition, Conception et Implantation des SIAcquisition, Conception et Implantation des SI
Acquisition, Conception et Implantation des SIArsène Ngato
 
Fondamentaux de la gestion de projet (cours 2)
Fondamentaux de la gestion de projet (cours 2)Fondamentaux de la gestion de projet (cours 2)
Fondamentaux de la gestion de projet (cours 2)Françoise Gouzi
 
Conduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & OutilsConduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & Outilsstephanie vincent
 
Gp 08 La Finalisation Du Projet
Gp 08   La Finalisation Du ProjetGp 08   La Finalisation Du Projet
Gp 08 La Finalisation Du ProjetClaude Michaud
 
Cours GP BELASLA El Mehdi 1.pptedeeededed
Cours GP BELASLA El Mehdi 1.pptedeeedededCours GP BELASLA El Mehdi 1.pptedeeededed
Cours GP BELASLA El Mehdi 1.pptedeeedededSiratiSoufiane
 
2008-11-04 Jean-Gynse Bolivar Cadre logique comme outil de gestion
2008-11-04 Jean-Gynse Bolivar Cadre logique comme outil de gestion2008-11-04 Jean-Gynse Bolivar Cadre logique comme outil de gestion
2008-11-04 Jean-Gynse Bolivar Cadre logique comme outil de gestionPMI Lévis-Québec
 
Les principales méthodes de gestion de projets
Les principales méthodes de gestion de projetsLes principales méthodes de gestion de projets
Les principales méthodes de gestion de projetsLaurence Genty
 
2015-04-29 Jean Cloutier Structure de découpage de projet
2015-04-29 Jean Cloutier Structure de découpage de projet2015-04-29 Jean Cloutier Structure de découpage de projet
2015-04-29 Jean Cloutier Structure de découpage de projetPMI Lévis-Québec
 
Résumé Théorique - M110 - Adopter Approche Agile.pdf
Résumé Théorique - M110 - Adopter Approche Agile.pdfRésumé Théorique - M110 - Adopter Approche Agile.pdf
Résumé Théorique - M110 - Adopter Approche Agile.pdfJussefFF1
 
Diaporama le projet.ppt......................
Diaporama le projet.ppt......................Diaporama le projet.ppt......................
Diaporama le projet.ppt......................Naoufal BELRHAZI
 
Gp 03 Les Domaines De Gestion
Gp 03   Les Domaines De GestionGp 03   Les Domaines De Gestion
Gp 03 Les Domaines De GestionClaude Michaud
 
c10-adopter-lapproche-agile-resume-theorique-6311e1a767ead.pptx
c10-adopter-lapproche-agile-resume-theorique-6311e1a767ead.pptxc10-adopter-lapproche-agile-resume-theorique-6311e1a767ead.pptx
c10-adopter-lapproche-agile-resume-theorique-6311e1a767ead.pptxSpartRaw
 

Similaire à Gestion de projets (20)

Gestion de Projets
Gestion de Projets Gestion de Projets
Gestion de Projets
 
Gestion_de_projet_manager_Le_leader.pptx
Gestion_de_projet_manager_Le_leader.pptxGestion_de_projet_manager_Le_leader.pptx
Gestion_de_projet_manager_Le_leader.pptx
 
Gestion_de_projetOK.pptx
Gestion_de_projetOK.pptxGestion_de_projetOK.pptx
Gestion_de_projetOK.pptx
 
Gp 04 Le Plan Directeur
Gp 04   Le Plan DirecteurGp 04   Le Plan Directeur
Gp 04 Le Plan Directeur
 
Acquisition, Conception et Implantation des SI
Acquisition, Conception et Implantation des SIAcquisition, Conception et Implantation des SI
Acquisition, Conception et Implantation des SI
 
Fondamentaux de la gestion de projet (cours 2)
Fondamentaux de la gestion de projet (cours 2)Fondamentaux de la gestion de projet (cours 2)
Fondamentaux de la gestion de projet (cours 2)
 
Conduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & OutilsConduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & Outils
 
Gp 08 La Finalisation Du Projet
Gp 08   La Finalisation Du ProjetGp 08   La Finalisation Du Projet
Gp 08 La Finalisation Du Projet
 
La Conduite de projet
La Conduite de projetLa Conduite de projet
La Conduite de projet
 
Cours GP BELASLA El Mehdi 1.pptedeeededed
Cours GP BELASLA El Mehdi 1.pptedeeedededCours GP BELASLA El Mehdi 1.pptedeeededed
Cours GP BELASLA El Mehdi 1.pptedeeededed
 
2008-11-04 Jean-Gynse Bolivar Cadre logique comme outil de gestion
2008-11-04 Jean-Gynse Bolivar Cadre logique comme outil de gestion2008-11-04 Jean-Gynse Bolivar Cadre logique comme outil de gestion
2008-11-04 Jean-Gynse Bolivar Cadre logique comme outil de gestion
 
Les principales méthodes de gestion de projets
Les principales méthodes de gestion de projetsLes principales méthodes de gestion de projets
Les principales méthodes de gestion de projets
 
Le management de projet
Le management de projetLe management de projet
Le management de projet
 
Audit des projets informatiques
Audit des projets informatiquesAudit des projets informatiques
Audit des projets informatiques
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
 
2015-04-29 Jean Cloutier Structure de découpage de projet
2015-04-29 Jean Cloutier Structure de découpage de projet2015-04-29 Jean Cloutier Structure de découpage de projet
2015-04-29 Jean Cloutier Structure de découpage de projet
 
Résumé Théorique - M110 - Adopter Approche Agile.pdf
Résumé Théorique - M110 - Adopter Approche Agile.pdfRésumé Théorique - M110 - Adopter Approche Agile.pdf
Résumé Théorique - M110 - Adopter Approche Agile.pdf
 
Diaporama le projet.ppt......................
Diaporama le projet.ppt......................Diaporama le projet.ppt......................
Diaporama le projet.ppt......................
 
Gp 03 Les Domaines De Gestion
Gp 03   Les Domaines De GestionGp 03   Les Domaines De Gestion
Gp 03 Les Domaines De Gestion
 
c10-adopter-lapproche-agile-resume-theorique-6311e1a767ead.pptx
c10-adopter-lapproche-agile-resume-theorique-6311e1a767ead.pptxc10-adopter-lapproche-agile-resume-theorique-6311e1a767ead.pptx
c10-adopter-lapproche-agile-resume-theorique-6311e1a767ead.pptx
 

Plus de Sana REFAI

Chapitre 2 : Les Listes chainées en Algo et C
Chapitre 2 : Les Listes chainées en Algo et CChapitre 2 : Les Listes chainées en Algo et C
Chapitre 2 : Les Listes chainées en Algo et CSana REFAI
 
la complexité des algorithmes en toute simplicité
la complexité des algorithmes en toute simplicitéla complexité des algorithmes en toute simplicité
la complexité des algorithmes en toute simplicitéSana REFAI
 
Chap2: lescollections
Chap2: lescollections Chap2: lescollections
Chap2: lescollections Sana REFAI
 
Chap1lla génèricité.pptx
Chap1lla génèricité.pptxChap1lla génèricité.pptx
Chap1lla génèricité.pptxSana REFAI
 
Cours algo: Les pointeurs
Cours algo: Les pointeursCours algo: Les pointeurs
Cours algo: Les pointeursSana REFAI
 

Plus de Sana REFAI (7)

Chapitre 2 : Les Listes chainées en Algo et C
Chapitre 2 : Les Listes chainées en Algo et CChapitre 2 : Les Listes chainées en Algo et C
Chapitre 2 : Les Listes chainées en Algo et C
 
la complexité des algorithmes en toute simplicité
la complexité des algorithmes en toute simplicitéla complexité des algorithmes en toute simplicité
la complexité des algorithmes en toute simplicité
 
Chap2: lescollections
Chap2: lescollections Chap2: lescollections
Chap2: lescollections
 
Chap1lla génèricité.pptx
Chap1lla génèricité.pptxChap1lla génèricité.pptx
Chap1lla génèricité.pptx
 
Pfe
PfePfe
Pfe
 
Cours algo: Les pointeurs
Cours algo: Les pointeursCours algo: Les pointeurs
Cours algo: Les pointeurs
 
Kinect
Kinect Kinect
Kinect
 

Gestion de projets

  • 2. Objectifs du cours  Connaitre et comprendre les enjeux de la gestion de projets informatiques  Permettre à l’étudiant d’avoir une réflexion critique sur le processus de développement des systèmes informatiques et sur les outils de gestion de projets 2
  • 4. Définition et terminologie  Définition et terminologie  qu'est-ce qu’un projet ?  gestion d'un projet  pilotage/conduite d'un projet  Un projet (informatique)  un objectif  des moyens  des contraintes Espace défini par le projet Objectif moyens contraintes 4
  • 5. Définition et terminologie  Mais un projet c’est avant tout  un besoin  objectif  un processus moyens contraintes Objectif atteint besoin 5
  • 6. Définition et terminologie  Qu’est ce qu’un projet?  Une articulation de ressources humaines, intellectuelles et matérielles agencées dans une organisation temporaire dont le résultat escompté est un état final (finalisé ?) du système tel que l’objectif prévu soit atteint dans l’espace défini par les objectifs, moyens, et contraintes (un objectif est caractérisé par un coût, un délai et des performances) 6
  • 7. Définition et terminologie  Autre définition 7
  • 8. Définition et terminologie  Etudier un projet c'est  recenser et/ou définir les moyens  recenser les contraintes  définir un plan de développement du processus  Gérer un projet c'est  contrôler les moyens, gérer les contraintes et suivre le plan de développement 8
  • 9. Définition et terminologie  Etudier un projet c'est  recenser et/ou définir les moyens  recenser les contraintes  définir un plan de développement du processus  Gérer un projet c'est  contrôler les moyens, gérer les contraintes et suivre le plan de développement ESTIMATION PLANIFICATION ORGANISATION PILOTAGE SUIVI 9
  • 10. Définition et terminologie  Piloter/conduire un projet c'est  comprendre les exigences stratégiques  gérer le projet  +  animer (une équipe)  vérifier la qualité  traiter avec les fournisseurs (cadre juridique) 10
  • 11. Crise de gestion de projets et GL  Constats  1994 : Rapport CHAOS (étude américaine sur 8000 projets)  16% finalisés dans les temps et le budget prévus  32% interrompus en cours de route  Diagnostic  Spécifications ambitieuses et Conception poussée  Remise en cause de choix initiaux  Mise à mal de la conception proposée  Effet Tunnel  Le processus correspond il aux besoins du projet ? 11
  • 13. Crise de gestion de projets et GL  Faits  Sources principales de problèmes dans les spécifications :  Erreurs  Oublis  Changements  Définir un logiciel a priori est un exercice difficile sauf dans le cas :  D’applications extrêmement simples  De rares contextes connus et maitrisés  Le client a du mal à imaginer ce que sera l’application  Conséquences  Remises en question des spécifications  Risques pour la conception liés au changement 13
  • 14. Quelques Valeurs …  Communication  Développement: travail de groupe, effort collectif  Avoir une vision commune et pouvoir se synchroniser  Qualité de la communication  Simplicité  Eviter la complexité inutile dans le code  Toute duplication doit être éliminée  Retour d’information (Feedback)  Boucles de feedback pour réduire les risques  Connaître l’état du projet  Apporter des rectifications si nécessaire  Facteur de qualité  Acquisition d’expérience  Amélioration constante du travail 14
  • 15. Gestion de projets: Motivations 15
  • 17. Définition 17  la discipline de gestion de projets poursuit la satisfaction du client par la planification, l'organisation, la direction et le contrôle des ressources de l'entreprise afin de compléter un projet spécifique à temp, avec le budget alloué et selon les standrds de qualité de la société
  • 18. Gestion de projets: préoccupations 18
  • 19. Les étapes de Gestion du projet 19 1. Initiation du projet 2. Estimation 3. Gestion des risques 4. Planification du projet 5. L’aspect humaine de gestion du projet 6. Exécution, progresse, contrôle et rapport du projet 7. Clôture du projet
  • 20. Gestion de projets - intervenants 20
  • 22. 22 Initiation du projet , Etude de faisabilité et définition du projet
  • 23. Avant-projet 23  L’étape d’avant-projet représente  l’étape initiale de tout projet. Elle est appelée également étape d’  Étude préalable du projet  Phase d’inception du projet  l'ensemble des étapes préparatoires nécessaires au lancement du projet Idée du projet Etude préalable du projet Lancer le projet Abandonner le projet
  • 24. Avant-projet 24  Avant-projet  Il s'agit de définir précisément ce que sera le projet afin d'aboutir à la mise au point de documents contractuels (faisant lieu d'un contrat) permettant d'engager la maîtrise d'œuvre (responsables de gestion et suivi projet) et la maîtrise d'ouvrage (responsables des activités techniques du projet) dans le lancement du projet  Cette phase formalise donc la décision de commencer le projet.
  • 25. Etude préalable du projet 25  L’étude préalable d’un projet intervient avant la phase d’expression des besoins  La plupart des projets nécessitent un stade initial au cours duquel il faut répondre à certaines questions  Quelle est la vision (objectif et contexte) du projet et quelle est son opportunité?  Le projet est-i-il réalisable?  Faut-il construire et/ou acheter ?  Quelle est l’estimation grossière du coût: doit-on envisager des dizaines de milliers, des centaines de milliers ou des millions de dinars?  Faut-il poursuivre jusqu’à la réalisation du projet ou renoncer?
  • 26. Etude préalable du projet 26  A l’étape d’avant-projet ou étude préalable du projet, il faut étudier quelques peu les besoins. Mais, cette étape n’a pas pour but de définir tous les besoins et élaborer un plan de projet  L’idée est d’effectuer le minimum d’investigations pour formuler une opinion rationnelle et justifiable de la finalité et faisabilité du projet et du nouveau système potentiel associé  L’objectif de cette phase est de  décider s’il est raisonnable d’investir dans une étude plus approfondie (l’objectif de la phase d’élaboration du projet)  établir une vision initiale comme des objectifs du projet, de déterminer si celui-ci est faisable (tenant compte des ressources disponibles)  étudier le contexte du projet et établir ses motivations
  • 27. Etude préalable du projet 27  L’étude préalable permet donc d'identifier les conditions de développement de ces activités :  Étude des marchés des produits et services,  Viabilité technico-économique du projet,  Compétences disponibles/requises,  Outils et moyens de financement de l'activité,  Impact social  ...
  • 28. Etude préalable du projet 28  Etude de marché et de l’existant  L’étude préalable consiste principalement à recenser l’existant c'est-à-dire les solutions informatiques déjà mises en œuvre dans l’entreprise et à recenser les besoins notamment en termes de fonctionnalités nouvelles.  Elle comprend également l’étude des applications similaires sur le marché  Elle peut être l’occasion d’une étude de rentabilité du projet.  L'étude préalable identifie les contraintes budgétaires, les contraintes d'environnement et les contraintes juridiques.
  • 29. Etude préalable du projet 29  Remarques  La phase d’étude préalable est relativement courte. Elle ne dépasse pas généralement quelques semaines  Dans de nombreux projets si cette phase dépasse une semaine, c’est un signe que son objectif n’a pas été bien compris. Il s’agit de décider si le projet mérite une étude sérieuse ou non  Si la décision de réaliser le projet a été déjà prise et si sa faisabilité est évidente, la phase d’étude préalable sera particulièrement brève  La phase d’étude préalable peut inclure un certain volume de programmation destinée à créer des prototypes (interfaces utilisateur) afin d’expliquer et mieux illustrer un certain nombre de besoins
  • 30. Comment le processus commence? 30  Raffiner l’idée du projet en des objectifs à atteindre: - fonctionnels et qualité - cout et gain - Temps • Les acteurs de cette phase sont :
  • 31. Les différents acteurs Equipe de projet Autres groupes Chef de projet Mandant Direction Client(s) 31
  • 34. Les étapes de l’étude de la faisabilité 34  Comprendre la complexité du projet.  Allouer les bonnes ressources pour faire l’étude de faisabilité du projet.  Raffiner et détailler tous les objectifs du projet.( cahier des charges et rapport de spécifications )  Evaluer l’acheivement, le temps et les risques.( on peut concevoir un prototype).  Ecrire un document qui synthétise cette étude de faisabilité.
  • 35. Phase de resourcement 35  Ressources de différentes équipes: toute type d’expertise est demandé pour achever le projet.  La mauvaise allocation des ressources va impacter: - La date de début du projet. - Mal évaluation du projet. - générer un cout extra - peut causer l’échec du projet.
  • 36. Analyse des problèmes Adaptation de [Buttrick] Pas de structure de projet Pas de stratégie claire Projets pas alignés sur la stratégie Projets commencés ne sont pas les bons Projets échouent, annulés, retardés Manque de rigueur et de méthodes Critères de décisions inadéquats Trop de projets commencés Ressources surexploitées 36
  • 37. Gestion des exigences( requirement) 37  Les objectifs d’un projet doivent être : o Specific: Spécifique o Measurable: Mesurable o Ambitious: Ambitieux o Reaslistic: Réaliste o Time-bound: Dans le temps
  • 38. Gestion des exigences( requirement) 38  Construire le bon produit  Comprendre ce que vous devez construire.  Construire les objectifs le plus important d’abord.  Gérer le changement des exigences.  Reduire le retravail , faciliter le test, Minimiser l’impact de changement des exigences, ne pas perdre l’usage des ressources
  • 39. Exigences spécification, vérification et évaluation 39  Ecrire les exigences dans un document structuré: o Label + identifiant unique o Identifier l’origine de chaque exigence ( créer une matrice de traçabilité)
  • 40. Initiation du projet : objectif 40  Décider si le projet va continuer ou non.  Annoncer l’affectation des ressources et les dates.  Annoncer l’équipe du projet.  Cette phase a comme sortie: un document de spécification des exigences ( cahier des charges), définiton des responsabilités ( chef du projet, équipe).  Un document de planification du temps et des ressources.
  • 42. Introduction 42  Principe de l’estimation:  Pourquoi estimer quand, qui va faire ça?  C’est quoi l’estimation.  Qu’est on va estimer  Estimation de l’effort  Les techniques d’estimation  Aspects humaines de l’estimation
  • 43. Pourquoi estimer quand, qui va faire ça? 43 Pourquoi? Quand estimer ? Qui estime ? Définir le budget et l’espace temporelle  Durant l’initiation du projet Chef du projet + les experts Aider dans le processus de planification Au lancement du projet  Chef du projet + l’équipe de travail( nouvelle estimation ou garder la même) Prendre en considération des événements particulières qui peuvent avoir lieu  Durant le déroulement du projet Aider à suivre le pogrés du projet.
  • 44. C’est quoi l’estimation 44  Un engagement: pas une simple prédiction  Une ligne de base: pour suivre les progrès futurs  Non seulement un numéro: Hypothèses Conditions préalables raisonnement
  • 45. Qu’est on va estimer 45  On peut estimer 3 caractéristiques du projet: l’effort ( travail à faire), la durée et le coût.  Les 3 sont inter-dependants mais l’estimation de l’effort reste la plus pertinente.  Quand on estime l’effort, on calcule généralement la durée et le coût.
  • 46. Comment estimer l’effort? 46  Effort = travail à faire  Effort exprimé en homme.temp ( Homme.jour, homme.semaine, homme.mois) pour un travail fait par une personne.  Relation entre Effort et durée:  Durée = Effort /Resource allouée  Pour une personne à plein temps: Durée= Effort  Pour une personne à moitié temps: Durée= Effort/0,5  Pour 2 personnes à plein temps: Durée= Effort/2
  • 47. Les techniques d’estimation 47  Delphi  Proxy-based méthodes  Bottom-up méthodes
  • 48. Comment estimer ? Delphi(1/2) 48  Un coordinateur et 5 à 10 estimateurs (experts et spécialistes).  Identifier qu’est on va estimer.  Après, chaque estimateur donne son estimation sans communiquer aux autres.  3 tours(Round) d’estimation avec retour d’information( feedbacks)  la moyenne finale est le résultat
  • 49. Comment estimer ? Delphi(2/2) 49  Round 1: estimation libre  Le coordinateur demande une estimation de chaque expert.  Le coordinateur calcule et annonce la moyenne  Round2: Argument  Ayant connu la première moyenne, chaque expert donne son estimation avec des arguments( Les raisons pour être >ou < à la moyenne).  Le coordinateur calcule et annonce la nouvelle moyenne et une liste des pilotes ( arguments pour être <) et des risques ( arguments pour être >)  Round 3: Evaluation  Le coordinateur demande les dernières estimations  la moyenne finale est le résultat
  • 50. Comment estimer ? Proxy-based méthodes (1/2) 50  C’est quoi est le proxy? Quelque chose qui représente la taille /la complexité de la chose que vous voulez estimer.  Exemples de proxies:  Nombre de ligne de code.  Nombre de use-case  Nombre d’interface graphique  Nombre des tables dans une BD
  • 51. Comment estimer ? Proxy-based méthodes (2/2) 51  Estimer la taille en utilisant le proxy convenable.  Appliquer un facteur d'échelle pour calculer l'effort de développement  Peut être utilisée pour dériver d'autres indicateurs utiles  Quantité de la documentation attendues.  Nombre des tests.  Nombre d’erreurs prévus
  • 52. Comment estimer ? Bottom-up méthodes 52  Décomposer le projet en tâches compréhensibles  Fournir des estimations pour chaque tâche individuelle:  Delphi  Best Case/Most likely/Worst case  Calculer l'effort probable de la tâche:  Additionner les résultats pour obtenir une estimation globale  Calcule de la déviation(optionnelle) E= (Best case + (4*Most likely) +Worst Case)/6 S= (Worst Case - best Case) / 6
  • 53. Quelle technique dans quel but? 53 Niveau Technique Pourquoi Dans l'ensemble du projet Delphi Proxy-based Méthodes idée générale de l'estimation détaillé Botton-up Méthode ordonnancem ent détaillé, suivi du projet (estimation précise requise)
  • 55. Gestion des risques 55  Principe de gestion des risques:  Terminologies  But de gestion des risques  Processus de gestion des risques.  FMEA: Techniques de gestion de risque
  • 56. Terminologies(1/2) 56  Risque:  un effet réel ou potentiel qui implique une perte ou un dommage  Un résultat indésirable, un danger  Il est caractérisée par sa sévérité  Facteur de risque:  A cause de l'effet potentiel (il peut y avoir des causes multiples pour le même effet )  Une origine, une source  Il est caractérisée par sa probabilité et la gravité (la sévérité) de l'effet qu’il peut générer. Remarque: par voie orale, nous utilisons risque pour décrire quelque chose qui peut être un facteur de risque
  • 57. Terminologies(2/2) 57  Exemple: Risque Facteur de risque Le logiciel est livré en retard Le développeur est nouveau Le produit est sur le marché en retard Insuffisance des ressources ( ingénieurs)
  • 58. Objectifs de gestion des risques 58  Anticiper les problèmes: concernant le projet, le produit et le processus  Déployer des actions correctives pour minimiser la perte de l'entreprise ( Il ne faut pas dépenser plus que vous gagner)  Réduire les risques
  • 59. Rôle du chef du projet 59  Outils de suivi intègrent l'analyse des risques en mesurant Coût du projet , le calendrier et la qualité (obtenue vs ciblée).  Le chef du projet a pour rôle de faire en sorte que les risques sont suivis, documentés, visés et atténués  dans l'analyse de faisabilité  pendant toute la durée du projet
  • 60. Méthode de gestion des risques 60  Qu'est-ce qui peut aller mal?  Que pouvons-nous faire pour nous assurer que cela ne se produira pas?  S’il arrive ?  Ce que je peux apprendre pour le futur
  • 61. Processus de gestion des risques 61 1-identifié 2-analyser 3-Plannifier 4-Suivre 5-Contrôler
  • 62. 1-Identifier les risques 62  Histoire passée  votre expérience de projet précédent  d'autres projets similaires  liste de contrôle des risques génériques  utiliser un existant de projets antérieurs  construit un nouveau en améliorant un existant  Recherche sur internet  brainstorming d'équipe  analyse interne
  • 63. 2-Analyser les risques 63  Comment saurez-vous si cela se produit?  Quand cessera il d'être un risque?  Priorisation  Probabilité (fréquence ou occurrence)  Impact  ces facteurs vont influencer votre choix de la stratégie de gestion des risques.
  • 64. 3-Planifier les risques (stratégie) 64  Eliminer les risques.( prévention)  Contrôler les risques(réduire la probabilité et l’impact)  Monitorer les risques: faire des évaluations périodiques des risques.  Accepter les risques: prendre en considération les conséquences.( dans certains cas de figures)
  • 65. 3-Planifier les risques (Résultats) 65  Plan de gestion des risques(règles, cycle de revue, organisation et responsabilité)  Registre des risques: une liste de priorité des risques identifiés:  Description  Probabilité, impact, numéro de priorité de risque  Stratégie de réduction des risques  Actions préventives  Actions correctives  Liste des actions
  • 66. 4-5 Suivre et contrôler les risques(1/3) 66  Objectif: réduire le nombre de risque dans un projet.  Des revues internes régulières ( …et dans les cas nécessaires) .  Suivre:  Re-Évaluation des risques.  Vérification de l’exécution de la stratégie de réduction des risques.  Suivre l’évolution de l’indice de priorité de risque par rapport aux actions prises.
  • 67. 4-5 Suivre et contrôler les risques(2/3) 67  Contrôler:  Identifier et analyser des nouveaux risques.  Re-planifier les actions de réduction des risques.  Identifier et affecter des nouvelles actions si nécessaire.  Des rapports réguliers à travers le réunion de révu du projet.
  • 68. 4-5 Suivre et contrôler les risques(3/3) 68 Entrée -Plan de gestion de risques -Registre des risques -- les rapports de weekly -- liste des actions Étape de suivi et de contrôle des risques Sortie -Une liste de actions( mis à jour) -- le registre des risques (mis à jour)
  • 69. 69 FMEA (Failure Mode and Effect Analysis) AMDEC (Analyse des modes de défaillance, de leurs effets & criticité) défaillance, de leurs effets & criticité
  • 70. Introduction 70  L'AMDEC,est l'équivalent français de la FMEA Failure Mode, Effects, and Criticality Analysis.  Comme son intitulé l'indique clairement, il s'agit d'une méthode conçue spécifiquement pour identifier les modes de défaillance d'un produit ou d'un processus.  Cette démarche exige rigueur et précision, son efficacité est à ce prix. L'AMDEC, ou plutôt son équivalent américain le FMEA, est née au sein de l'industrie aéronautique durant les années 1960. L'industrie automobile l'a ensuite rapidement adoptée. Aujourd'hui, les applications de l'AMDEC comme outil d'analyse des risques sont aujourd'hui multiples.
  • 71. C’est quoi AMDEC ? 71  Une démarche préventive Cette méthode est à vocation préventive. C'est un précieux outil pour s'assurer de la faisabilité d'un cahier des charges en respect des spécifications clients et des exigences réglementaires.  Le principe La démarche est complète. Elle propose de lister puis d'organiser les modes de défaillances prévisibles et les conséquences lors de la conception d'un produit ou de la mise en oeuvre d'un processus.
  • 72. Déroulement de l'analyse AMDEC(1/4) 72
  • 73. Déroulement de l'analyse AMDEC(2/4) 73 Cause → Mode de défaillance → Effet  Une analyse de type AMDEC se déroule en un mode participatif. Il s'agit de profiter de l'expérience de tous.  La méthode se déroule en 5 temps majeurs selon le processus ci- après : 1) Préparation  Préparation et constitution des groupes de travail. C'est une étude exigeante. Les participants devront s'impliquer sérieusement et accorder le temps nécessaire pour réaliser correctement la part d'étude dont ils ont la charge.  Précision de l'objet de l'étude, de son périmètre et de sa portée Les objectifs attendus seront énoncés concrètement et en accord avec les besoins des commanditaires de l'étude et des participants à sa réalisation.
  • 74. Déroulement de l'analyse AMDEC(3/4) 74 2) Analyse fonctionnelle et Préparation de l'étude de défaillance Découpage fonctionnel: Comme son intitulé l'indique clairement, il s'agit de lister et de mettre en relation toutes les fonctions du produit ou les phases du processus afin d'identifier les causes de dysfonctionnement potentiel 3) Identification Identification des défaillances potentielles : Il s'agit de réaliser une étude rationnelle des modes de défaillance potentiels, des causes et des effets. La réussite de cette troisième étape est directement dépendante du soin apporté au découpage fonctionnel. Elle exige une participation élargie de toutes les personnes susceptibles d'apporter un enseignement le plus souvent issu de leur propre expérience.
  • 75. Déroulement de l'analyse AMDEC(4/4) 75 4) Valorisation des défaillances potentielles et Etude de la criticité Etude de la criticité en tenant compte de la gravité, de la probabilité d'occurrence et de la capacité de détection (warning) Au cours d'une démarche participative, on établi:  la gravité potentielle sur une échelle de 1 à 4 (de mineure à gravissime),  la fréquence estimée sur une échelle de 1 à 4 (exceptionnelle à certain)  la capacité de détection sur une échelle de 1 à 4 (Evident à indetectable)  La criticité est le produit de ces trois évaluations. 5) Actions Correctives Identification des actions préventives à conduire, des Identification des actions palliatives possibles et Identification des actions correctives .(sans oublier la question du coût de chacune des actions envisagées)
  • 76. La criticité 76  La criticité, fréquence, gravité et détection, s'exprime habituellement sur une échelle limitée pouvant atteindre jusqu'à 10 niveaux selon les cas (bien que 4 niveaux soient suffisants pour les cas les plus courants).  La criticité permet de hiérarchiser les différentes causes de défaillances et contribue à évaluer les actions à entreprendre.(Les niveaux 9 et 10, les plus élevés)  NPR (Nombre pour Prioriser les Risques) NPR = S*O*D = criticité*fréquence*gravité et détection  S( Severity), O ( Occurence), D(Detection)
  • 78. Le formalisme AMDEC(2/3) 78 Mode de défaillance Item/Function Effet 1 Effet 2 Cause 1 Cause2 Prévention Détection
  • 79. Le formalisme AMDEC(3/3) 79  L’évaluation du risque Mode de défaillance Item/Function Effet 1Cause 1 Prévention Détection Sev Occ Det * * RPN
  • 80. Calcul de la criticité IPR (Indice de Priorisation du Risque) IPR = G x O x N (G : Gravité, O : probabilité d'occurrence, N : non détection) G Gravité 1 Effets mineurs 2 Effets significatifs 3 Effets critiques 4 Effets catastrophiques O Probabilité d'occurrence 1 Très faible 2 Faible 3 Moyenne 4 Forte N Non détection 1 Très efficace 2 Efficace 3 Détection peu fiable 4 Aucune détection possible Évaluation des défaillances – Analyse de la criticité
  • 81. Évaluation des défaillances – Analyse de la criticité  Cotation de la criticité souvent effectuée en fonction des deux seuls critères de gravité et de probabilité d’occurrence de la défaillance.  Représentation de la criticité sous forme matricielle (Grille de criticité). Calcul de la criticité IPR (Indice de Priorisation du Risque) GRAVITE G 1 2 3 4 O O 1 C C U 2 I R R E 3 II N C E 4 I : Zone non critique II : Zone critique
  • 82. Grille pour la sévérité 82 Hazardous without warning Very high severity ranking when a potential failure mode effects safe system operation without warning 10 Hazardous with warning Very high severity ranking when a potential failure mode affects safe system operation with warning 9 Very High System inoperable with destructive failure without compromising safety 8 High System inoperable with equipment damage 7 Moderate System inoperable with minor damage 6 Low System inoperable without damage 5 Very Low System operable with significant degradation of performance 4 Minor System operable with some degradation of performance 3 Very Minor System operable with minimal interference 2 None No effect 1
  • 83. Grille pour l’occurence 83 PROBABILITY of Failure Failure Prob Ranking Very High: Failure is almost inevitable >1 in 2 10 1 in 3 9 High: Repeated failures 1 in 8 8 1 in 20 7 Moderate: Occasional failures 1 in 80 6 1 in 400 5 1 in 2,000 4 Low: Relatively few failures 1 in 15,000 3 1 in 150,000 2 Remote: Failure is unlikely <1 in 1,500,000 1
  • 84. Grille de la détection 84 Detection Likelihood of DETECTION by Design Control Ranking Absolute Uncertainty Design control cannot detect potential cause/mechanism and subsequent failure mode 10 Very Remote Very remote chance the design control will detect potential cause/mechanism and subsequent failure mode 9 Remote Remote chance the design control will detect potential cause/mechanism and subsequent failure mode 8 Very Low Very low chance the design control will detect potential cause/mechanism and subsequent failure mode 7 Low Low chance the design control will detect potential cause/mechanism and subsequent failure mode 6 Moderate Moderate chance the design control will detect potential cause/mechanism and subsequent failure mode 5 Moderately High Moderately High chance the design control will detect potential cause/mechanism and subsequent failure mode 4 High High chance the design control will detect potential cause/mechanism and subsequent failure mode 3 Very High Very high chance the design control will detect potential cause/mechanism and subsequent failure mode 2 Almost Certain Design control will detect potential cause/mechanism and subsequent failure mode 1
  • 85. Proposition d’actions en réduction de risques 85  Mise en place d’actions correctives.  Diminution de la criticité des causes de défaillance :  Réduction de la probabilité d’occurrence des modes de défaillances ou,  réduction de la gravité des effets.  Réactualisation de la cotation de la criticité à chaque mesure prise.
  • 86. Les mesures correctives Optimiser et développer la maintenance Corrective Préventive Améliorative  Diminution du MTTR  Meilleure gestion des pièces de rechange  Développement d'un système d'aide au diagnostic  Optimisation des opérations de maintenance préventive  Mise en oeuvre de nouvelles opérations  Augmentation de la SdF  Augmentation du MTBF  Amélioration de la sécurité des opérateurs Proposition d’actions en réduction de risques
  • 87. Suivi et contrôle des actions • Formulation de recommandations qui font l’objet de plans d’actions. • Vérification de la bonne mise en œuvre de ces plans d’actions. • Analyse de l’impact des modifications proposées
  • 88. Exploitation de l’AMDEC • L’AMDE(C) permet de générer une base d’informations de référence tout au long de la vie du produit. • L’exploitation se traduit par une liste de synthèses : • Liste des effets de défaillances, • Liste des articles critiques, • Liste des symptômes observables, • Liste des points de panne unique, • Liste des défaillances non détectées, • Liste des modes communs, …
  • 89. Limites de l’AMDEC • N’est pas une méthode de résolution de problèmes. • Ne peut pas garantir l’exhaustivité de l’étude. • Est une méthode fastidieuse pour l’étude des systèmes complexes.
  • 90. Etude de cas 90 ……  ( risques humaines et Risques naturels)
  • 93. Définition de la planification du projet 93  Discipline ayant pour objectif de positionner les activités ou tâches d’un projet les unes par rapport aux autres.  La planification a pour objectif de prévoir, suivre et maitriser la réalisation d’un ouvrage en délais et en coût.
  • 94. Construire le planning Comment s’y prendre 94  REPONDRE AU «QUOI» •Que doit-on faire ?  REPONDRE AU «QUAND» •Ordre des tâches ?  REPONDRE AU «QUI» •Qui peut faire quoi ? De qui ai-je besoin ?  REPONDRE AU «COMBIEN DE TEMPS» •Durée des tâches ?
  • 95. Outils d’aide à la structuration 95  Product Breakdown Structure (PBS) Ou Organigramme de produit ou Arbre produit  Work Breakdown Structure (WBS) Organigramme des tâches  Organisation Breakdown Structure (OBS)
  • 96. Product Breakdown Structure (PBS) 96  Qu’est-ce que c’est ? Une décomposition Hiérarchique (structure d’arbre) et Exhaustive de l’ensemble des livrables du projet (physique, fonctionnel ou conceptuel)  Dans quel but ?Simplifier le projet pour: •Le rendre gérable / maitrisable •Valider la compréhension du besoin •Communiquer / Echanger •Etablir le worksharing industriel •Identifier les niveaux d’intégration
  • 97. WorkBreakdown Structure (WBS) 97  Qu’est ce que c’est? Une décomposition •Exhaustive •Hiérarchique, •Axée sur les tâches et activités, du travail à réaliser pour atteindre les objectifs du projet  Dans quel but ?  Aider à: •Organiser le projet, •Bâtir le macro- planning •Établir le budget prévisionnel. •Identifier les travaux sous-traités
  • 98. Organisation Breakdown Structure (OBS) 98  QU’EST-CE C’EST ? Structuration organisationnelle des responsabilités  A CHAQUE ELEMENT DU WBS (work package, lot, sous-projet) • Un responsable (Accountable) -Un individu -Un service de l’entreprise -Un prestataire extérieur • En charge de sa gestion de projet -Organisation -Planning -Suivi
  • 99. Lien entre PBS et WBS 99 99 Project Subproject System subsystem Task PBS WBSPhase Work Batch COHERENCY: →Tasks must realize subsystem ←Subsystem must be built by tasks
  • 100. 100 100 Need System Sub System Product Task Involved agency Steering comity Office Team People Flux PBS-WBS / OBS
  • 102. Exemple1 102 Projet info : Logiciel version 2.0 Management projet Spécification produit Conception détaillée Planification Réunions Gestion Logiciel Manuel d’utilisateur Documents de formation Logiciel Manuel d’utilisateur Documents de formation Réalisation Logiciel Manuel d’utilisateur Documents de formation Intégration et tests Logiciel Manuel d’utilisateur Documents de formation Projet info : Logiciel version 2.0 Management projet Spécification produit Conception détaillée Planification Réunions Gestion Logiciel Manuel d’utilisateur Documents de formation Logiciel Manuel d’utilisateur Documents de formation Réalisation Logiciel Manuel d’utilisateur Documents de formation Intégration et tests Logiciel Manuel d’utilisateur Documents de formation
  • 103. Work breakdown structure-WBS (Organigramme des tâches de projet)  Objectifs  Identifier les travaux à compléter  Traduire la définition du projet en une liste de tâches à accomplir  La planification structurelle consiste à préparer une liste exhaustive, documentée et structurée des travaux dont l’accomplissement est nécessaire à la production des biens livrables du projet  Caractéristiques  Constitution d’une base de données des travaux  Sert de base aux autres étapes de planification  Principal instrument de communication entre les intervenants  Identification et description des lots principaux de travail  Identification et description des tâches élémentaires 103
  • 104. Etapes 104  Planification structurelle sommaire  Subdiviser le projet en lots de travail  Un lot = un bien livrable du projet  Toujours prévoir les lots de support pour tâches ponctuelles  Planification structurelle détaillée  Subdiviser les lots de travail principaux jusqu’à l’identification de tâches élémentaires  Représentation à l’aide d’un organigramme de tâche (Work Breakdown Structure)
  • 105. Planification en lots de travail 105  Principe de base  Découpage du projet en paquet de tâches tout d'abord à un niveau global  pour ensuite découper chacun de ces paquets en un 2ème niveau plus détaillé  et ensuite encore en paquets plus élémentaires, etc.  Critères de découpage : 1ère condition  « Tout ce qui peut donner lieu à des dépenses, à des lots de travail quelle qu'en soit la nature tout ce qui peut constituer un délai d'attente, une durée, doit donner lieu à un paquet dans l'OT » OT: Organigramme de tâches
  • 106. Tâches 106  Tâche élémentaire  Travail ponctuel  Résultat est un produit concret (information, rapport, composante du produit, etc.)  Tâches de support  Pas des préoccupations continues (contrôle financier, gestion, etc.)  Tâches ponctuelles de gestion (approbations, révisions,etc.)
  • 107. Exemple de décomposition Application de commerce électronique 107  Organigramme
  • 108. Exemple de décomposition Application de commerce électronique 108 Activités du support du niveau 1  Gestion de configuration  Gestion des changements  Établissement et gestion des espaces de travail  Définition des situations de base  Gestion de projet  Gestion des risques  Gestion des échéanciers  Gestion du budget  Contrôle de l’avancement  …….
  • 109. Exemple de décomposition Application de commerce électronique 109  Décomposition niveau 2
  • 110. Exemple de décomposition Application de commerce électronique 110  Activités niveau 3  Activités liées au développement du produit pour chacun des composantes  À partir d’un processus défini  Activités de développement technique  Activités de support  Activités spécifiques de gestion de configuration  Activités spécifiques de gestion de projet
  • 111. Exemple de décomposition Application de commerce électronique 111  Décomposition - Niveau 3
  • 112. Exemple de décomposition Application de commerce électronique 112  Gestion de configuration
  • 113. Exemple de décomposition Application de commerce électronique 113  Tâche élémentaire – Niveau 4
  • 115. Introduction 115 Le réseau PERT  Program Evaluation and Review Technic  Les tâches sont représentées par des flèches  Le réseau visualise des dépendances entre tâches
  • 116. Réseau PERT 116  Les paramètres clés  Recherche du chemin critique  Met en évidence les tâches qui risquent de retarder la fin du projet si elles sont en retard.  Pour chaque tâche dont on a estimé la durée on calcule :  Les dates de début et de fin « au plus tôt » et « au plus tard »  La marge
  • 117. Quelques notions(1/2) 117  Date au plus tôt : c’est la date à laquelle on peut commencer en fonction des dépendances aux autres tâches  Date au plus tard : date à laquelle une tâche peut commencer au plus tard sans remettre en cause la date de fin de projet  Marge totale Date début plus tard - date début plus tôt
  • 118. Quelques notions(2/2) 118  Chemin critique Constitué d’une suite des tâches ayant une marge totale égale à zéro Tout retard sur une tâche du chemin critique affecte la date de fin du projet
  • 119. Graphe Pert : calcul des dates au plus tôt 119  Calcul de proche en proche à partir de la date de début au plus tôt du projet  Pour les tâches Ti, de durée estimée di qui se trouvent en début de projet  Date de début au plus tôt avec t0 = date de début de projet  Début_au_plus_tôt (Ti) = t0  Date de fin au plus tôt  Fin_au_plus_tôt (Ti) = t0+ di  Pour une tâche Ti, de durée estimée di  Date de début au plus tôt  Début_au_plus_tôt (Ti) = sup (Fin_au_plus_tôt (prédécesseurs (Ti)))  Date de fin au plus tôt  Fin_au_plus_tôt(Ti) = Début_au_plus_tôt (Ti) + di
  • 120. Graphe Pert : calcul des dates au plus tard 120  On fait l ’hypothèse d ’une date de fin de projet (fonctionnement par date limite)  On parcourt le graphe en sens inverse  Pour les dernières tâches, si tf est la date limite de fin du projet,  Fin_au_plus_tard (Tfi) = tf  Pour les autres tâches  Fin_au_plus_tard (Ti) = inf (Début_au_plus_tard (successeurs))  Début_au_plus_tard (Ti) = Fin_au_plus_tard (Ti) – di
  • 121. Exemple 1 121 de A …. Jusqu’à Z
  • 122. Analyse du projet(1/2) 122 122 Project FurnitureStudies ToolingFacility layout Acceptance Machining Supplies Assembly Supplies Machining substructure Machining installation Assembly substructure Assembly installation Acceptance tests Layout Studies Ganty crane installation
  • 123. Analyse du projet(2/2) 123 FurnitureStudies Tooling Facility layout Acceptance A Machining Supplies B Assembly Supplies D Machining substructure E Machining installation F Assembly substructure G Assembly installation I Acceptance tests C Layout Studies H Ganty crane installation
  • 124. Identifier les tâches(1/2) 124 N° Label Deb Start A Purchase & receipt of machining tools B Purchase & receipt of assembly tool C Study the facility layout D Execute the facility layout for machining E Install machining tools F Execute the facility layout for assembly G install assembly tools H Install the gantry crane I Perform acceptance tests Fin End
  • 125. Identifier les tâches(2/2) 125 Deb Start NIL A Purchase & receipt of machining tools Deb B Purchase & receipt of assembly tool Deb C Study the facility layout Deb D Execute the facility layout for machining C E Install machining tools A,D F Execute the facility layout for assembly C G install assembly tools B,F H Install the gantry crane C I Perform acceptance tests E,G,H Fin End I N° Label Anterior tasks
  • 127. Estimation de durée 127 Deb Start / 0 A Purchase & receipt of machining tools Deb 7 B Purchase & receipt of assembly tool Deb 3 C Study the facility layout Deb 5 D Execute the facility layout for machining C 5 E Install machining tools A,D 5 F Execute the facility layout for assembly C 3 G Install assembly tools B,F 3 H Install the gantry crane C 7 I Perform acceptance tests E,G,H 1 Fin End I 0 N° Label Anterior Duration tasks
  • 128. Calcul des dates 128 A D C B F E H G I 0 7 5 5 3 5 3 7 3 1 Dtot Début au plus tôt Ftot Fin au plus tôt Ftard Fin au plus tard Dtard Début au plus tard Duration Début Fin
  • 129. Chemin Critique 129 A D C B F E H G I 0 7 5 5 3 5 3 7 3 1 0 0 0 7 5 3 5 10 5 8 10 15 5 12 8 11 15 16 16 16 1615 1510 158 1512 105 129 103 50 0 129 0 0 0 0 3 3 4 49