Iulia-Cristina Stanica, PhD

Ingénierie des iulia.stanica@gmail.com /

iulia.stanica@upb.ro

Systèmes – Cours 4
Faculté d’Ingénierie en Langues
Etrangères
Université POLITEHNICA de Bucarest
 Objectifs pour aujourd’hui

+ Risques dans l’IS

+ La gestion des risques (Risk management)
 Risques…
indispensables dans
l’IS
“Si un projet ne comporte
aucun risque, ne le faites pas.
Les risques et les avantages
vont toujours de pair.”

“Waltzing with bears” – Managing Risk on

software projects, Tom DeMarco & Timothy
Lister
 Risques - discussions
• Pensez a vos projets de fin
d’études. Quel sont les
risques possibles?
• Ou a vos projets de l’IS?

• Discutons aussi un peu sur

les catégories des risques
que vous avez identifiés
Kahoot 
 Risques – définition
+ Le risque est défini comme la combinaison de :
+ La probabilité qu'un programme ou un projet connaisse une événement
indésirable et
+ Les conséquences, l'impact ou la gravité de l'événement indésirable, s’il va se
produire

+ Raisons d’apparition: sources techniques ou programmatiques (par

exemple, un dépassement de coût, un retard de calendrier, un incident de
sécurité, un problème de santé, des activités malveillantes, un impact sur
l'environnement ou l'incapacité à atteindre un objectif scientifique ou
technologique nécessaire ou des critères de réussite)
 Risques – définition (suite)
+ Le risque est une mesure des incertitudes futures
dans la réalisation des objectifs de performance
technique du programme dans le cadre de
contraintes de coût et de calendrier définies
+ Risque = une possibilité de perte
+ Les risques ont trois composantes :
1. Cause future de production
2. Probabilité ou vraisemblance que cette cause
fondamentale future se produise
3. Conséquences (ou effet) de cette occurrence future
Source: Riskit method
http://www.jyrkikontio.fi/attachments/File/
riskittr.pdf
 Risque vs. Problème (Issue)
+ Pas synonymes!!!
Risk Issue
+ Quelle est la différence?

+ Risque - incertitude qui pourrait se produire

+ Issue – il n’y a pas de probabilité (c’est sur ); c’est un
problème qui affecte maintenant le projet
+ Le choix parmi les décisions a un impact sur le budget, le calendrier ou
la portée du projet
 Comment on tient un registre avec les problèmes?
(« Issue log »)
+ La description du problème
+ Catégorie / type de problème
+ Priorité
+ Temps d’identification
+ Responsabilité
+ Date de résolution prévue
+ Description du progrès / état actuel
+ Décision / résolution finale
Plus tard…
+ Planifier des révisions périodiques des
problèmes
+ Réunions d'équipe
+ Rapports d'état
+ Passer à l'action
+ Communiquez les résultats ! Vérifiez votre
plan de communication !
+ Mettre à jour les tâches/jalons
+ Faire les investissements nécessaires
+ Gérer les attentes du but du projet
 Gestion des risques – pourquoi nécessaire pour
l’IS?
+ Le développement d'un nouveau système complexe nécessite
l'acquisition de connaissances sur des dispositifs/processus avancés.

+ L'objectif final des processus SE est de développer un produit

intelligent fiable à un coût abordable.

+ Des événements imprévisibles peuvent survenir à n'importe quel

moment du cycle de vie du système, des événements qui peuvent
entraîner des baisses de performances, des changements dans le coût
global et le calendrier du projet qui développe le système complexe.
 Comment on établit la priorité des risques?
+ Ca dépend de la probabilité et de l’impact
(gravité)
+ Une méthode généralement recommandée d'analyse
des risques consiste à attribuer 2 notes à chaque
risque identifié, un pour la probabilité et un pour la
gravité.
+ Le risque peut être analysé soit graphiquement soit
comme la somme des 2 notes. Si nous utilisons une
échelle de 1 à 10, et qu'un événement reçoit un score
de 16, il doit certainement être considéré.
+ Si la probabilité (%) du risque et son impact sur le
projet (nombre de jours ou coûts) sont connus, le
risque sera calculé comme le produit de la
probabilité d'occurrence du risque et de l'effet
produit.
Decomposition des Risques – Analyse Riskit

Source: Riskit method

http://www.jyrkikontio.fi/attachments/File/riskittr.pdf
 Decomposition des Risques – Analyse Riskit
(Concepts)
+ Risk factor est une caractéristique qui affecte la probabilité qu'un événement négatif
(c'est-à-dire un événement à risque) se produise
+ Risk event représente la survenance d'un incident négatif ou la découverte
d'informations révélant des circonstances négatives.
+ Risk outcome représente la situation d'un projet après que l'événement à risque s'est
produit mais avant que toute mesure corrective ne soit prise pour réduire les effets
d'un événement à risque.
+ Risk reaction décrit une action possible qui peut être entreprise en réponse à un
événement à risque
+ Risk effect set représente l'impact final d'un événement à risque sur le projet.
+ Utility loss représente la gravité de l'impact global des effets sur le but, les couts, le
temps du projet etc
 Élément de Exemples généraux (médicine, géographie etc.)
risque
Risk factor • un régime riche en cholestérol
• vivant près d'une ligne de faille des plaques terrestres
(par exemple, San Francisco)
• conditions de conduite glissantes (pluie, neige)
Risk event • le diagnostic d'un problème cardiaque d'un patient par un
médecin Pensons
• un tremblement de terre
• un accident de voiture maintenant aux
Risk outcome • une maladie cardiaque diagnostiquée existe
exemples pour
• certains bâtiments et routes détruits
• une scène d'accident : personnel non traité
l’ingénierie des
Risk reaction
blessés, véhicules endommagés
• traitement des problèmes cardiaques
systèmes 
• reconstruction de routes et de bâtiments
• traitement des blessures, achat d'une nouvelle voiture
Risk effect set • séjour à l'hôpital, coût des soins médicaux
• coût et inconvénient de
reconstruction, pertes en vies humaines,
frais médicaux
• frais médicaux, séquelles permanentes,
augmentation des primes d'assurance
Utility loss • L'effet net de la douleur, du temps perdu et des dépenses subi
 La gestion des risques – c’est quoi?
+ La méthodologie employée pour
identifier et minimiser les risques
dans le développement des systèmes
complexes
+ La gestion des risques implique la
définition d'une stratégie de gestion
des risques, l'identification et
l'analyse des risques, la gestion des
Source:
risques sélectionnés et le suivi des
https://www.revuegestion.ca/gestion-des-risques-
progrès dans la réduction des pourquoi-s-en-preoccuper
risques à un niveau acceptable (SEI
2010)
"L'ingénierie des risques [la gestion] ne
traite pas des décisions futures, mais de
l'avenir des décisions présentes." -
Robert Charette
 La gestion des risques – comment?
(parfois on mentionne avant
« planification » d’une stratégie de
gestion des risques)
1. Identification (quelles sont les
risques)
2. Evaluation / Analyse (a propos de
la probabilité et de l’impact)
3. Réponses / Actions / Contrôle (ce
qu’on fait pour gérer le risque)
4. Surveillance (Monitoring) (du
projet, des statuts des risques etc.)
 1. Identification des risques
+ L'identification des risques est le processus d’examen des produits, des
processus et des exigences du projet pour identifier et documenter les
risques potentiels.
+ L'identification des risques doit être effectuée en continu
+ Méthodes:
+ Brainstorming
+ Listes de contrôle d'autres projets
+ Interviewer des participants expérimentés au projet et des experts commerciaux /
techniques
+ Analyse des hypothèses
 1. Identification des risques - Categories
+ Risques techniques
+ liés aux exigences, technologies, complexité, performance, stabilité, qualité, intégration avec d’autres
systèmes etc.
+ Risques économiques
+ budget, finances, couts, sponsors
+ Risques juridiques
+ Risques d'attentats terroristes/criminels
+ Risques organisationnels
+ manque de soutien politique, engagements de ressources inadéquats ou variables, manque de
formateurs/personnel de soutien, rejet possible du système, procédures ou application médiocres,
utilisation inefficace par les utilisateurs
+ Risques de gestion de projet
+ estimation, planning, contrôle, communication etc.
1. Identification des risques - Categories
 La gestion des risques – discussion

+ Rappelons-nous des risques possibles que vous avez

proposé a propos de vos projets de l’IS
+ Vous pensez qu’ils ont une gravité élevée?
+ Dans quel catégorie on peut les classifier?
+ Qu’est-ce qu’on peut faire pour les gérer?
1. Identification des risques (utile pour le projet)
Risk Breakdown Structure
 2. Evaluation / Analyse des risques
+ L'analyse des risques est le processus d'évaluation systématique
de chaque risque identifié et approuvé afin d'estimer la
probabilité d'occurrence et la conséquence de l'occurrence
(impact), puis de convertir les résultats dans un niveau ou une
cote de risque correspondant.
+ Contient l’analyse qualitative et l’analyse quantitative
 Analyse qualitative
+ Quelle probabilité a ce risque ?
+ Élevé : se produira probablement
+ Moyen : peut arriver
+ Faible : ne se produira probablement pas, mais c’est possible
+ Quel est l'impact sur le délai/coût/qualité ?
+ Élevé : susceptible d'avoir un impact significatif sur le calendrier/le coût/la
portée/la qualité
+ Modéré : a le potentiel d'avoir un impact sur le calendrier/le coût/la portée/la
qualité
+ Faible : a un impact potentiel limité sur le calendrier/le coût/la portée/la qualité
 Analyse qualitative

Probability
High=3 Medium= Low=1
+ On peut avoir Impact 2
une échelle avec High=3 9 6 3
5 valeurs Medium=2 6 4 2
Low=1 3 2 1
 Analyse quantitative - techniques
+ Estimation numérique de l’effet
(cout, planification) du risque en Impact -
fonction de la probabilité Risque Probabilité EMV
coût
+ Ex: A (Risque) 20% $100,000 $20,000
+ Three point estimate - une technique
qui utilise les valeurs optimistes, les
B
40% ($10,000) ($4,000)
plus probables et pessimistes pour (Opportunité)
déterminer la meilleure estimation
C (Risque) 30% $50,000 $15,000
+ Decision Tree Analysis – diagramme
avec les implications Total EMV     $31,000
+ Expected monetary value (a droit) -
une méthode utilisée pour établir Expected monetary value
les réserves pour les imprévus dans
un certain budget et un calendrier
de projet
 Qualitative vs Quantitative
Qualitative Quantitative

+ Doit toujours être exécuté + Optionnel

+ Subjectif + Objectif
+ Rapide + Prend plus de temps
+ Plus détaillée
+ Valeurs concrets pour coûts,
planification etc.
 Optionnel – Autres critères pour Priorisation des
Risques
+ En dehors de la probabilité et de l’impact, il y a aussi d’autres critères
qu’on doit prendre en considération: la durée jusqu’au moment de
l’apparition, la fréquence d'occurrence et l'interrelation avec
d'autres risques
+ Par exemple, on peut avoir des risques qui ne peuvent être visibles
que près du moment du lancement
 3. Réponses / Actions / Contrôle
+ Évitez-les (idéal) - par ex. meilleure planification,
communication, etc.
+ Atténuez-les (angl. mitigation; contrôle + minimiser
l'impact) - par ex. tests, trainings
+ Transférez-les - par exemple assurances
+ Acceptez-les => essayez de les gérer quand ils deviennent
des problèmes
 Exemple – tests unitaires
+Atténuer les risques liés au code
+Junit – tests unitaires (pour les composants)
 4. Surveillance / Monitoring
+ Dans certains cas, les résultats de la surveillance peuvent également être utilisés
pour identifier de nouveaux risques, réviser un risque existant ou réviser certains
aspects de la planification des risques
+Assurez-vous que les informations pour chaque risque sont mises à jour et exactes
+ Si le risque n'est plus valable, retirer le risque
+ Si la probabilité/l'impact ou l'atténuation/l'éventualité ont changé ou doivent être mis à jour,
changez-les
+Répétez les étapes pour examiner et mettre à jour les risques au moins sur une base
périodique comme spécifié par l'adaptation du projet
+ Les risques doivent être examinés et mis à jour avant chaque période de rapport d'état
Risk Log – plus de détails au TP 
 Conclusions
+ Risque = "Un événement ou une condition incertaine qui, s'il se
produit, a un effet sur les objectifs d'un projet." => influence la
qualité (prochain cours !!!)

+ Vous ne pouvez pas éliminer le risque, mais vous pouvez le

gérer intelligemment.
 Références utiles
+ Jyrki Kontio, “The Riskit Method for Software Risk Management, version 1.00”
+ Olivier L de Weck, ”Fundamentals of Systems Engineering”, Verification and
Validation
+ Kasse Initiatives, “Risk Management for Systems Engineering”, 2004
+ SEBoK Guide to the Systems Engineering Body of Knowledge, “Risk
Management”
+ Evaluating Risks Using Quantitative Risk Analysis
https://projectriskcoach.com/evaluating-risks-using-quantitative-risk-analysis/
+ Systems Engineering Guide, “Risk Impact Assessment And Prioritization”,
https://www.mitre.org/publications/systems-engineering-guide/acquisition-syste
ms-engineering/risk-management/risk-impact-assessment-and-prioritization