Université de BBA Master 2 - Ingénierie de l’informatique décisionnelle

Matière : Techniques de gestion de projets logiciels TD2. Cycle de vie & Gestion des risques

Exercice 1: Choix d’un modèle de cycle de vie

a) Si les utilisateurs d’un logiciel à développer sont hésitants sur ce qu’ils veulent, quel(s) modèle(s) de cycle
de vie est (sont) à privilégier ?
(1) prototypage, (2) cascade, (3) modèle en V.
b) Si on dispose d’une équipe de développeurs expérimentée dans le domaine d’application concerné et qu’on
doit développer un grand logiciel assez similaire à ce que cette équipe a déjà développé dans le passé, quel(s)
modèle(s) de cycle de vie est (sont) à privilégier ?
(1) prototypage, (2) cascade, (3) modèle en V.

Exercice 2: Caractéristiques des modèles de cycle de vie

Associer les modèles de cycle de vie à gauche aux caractéristiques qui leur conviennent à droite.

Cascade projet classique

V projet innovant
Spirale projet critique
Incrémental projet mal défini
Prototypage projet de grande taille
Agile projet de petite ou moyenne taille

Exercice 3: QCM Scrum (une seule réponse possible par question)

Q1. Quel rôle est responsable de la définition des priorités au sein du product backlog ?
a) Product Owner b) Project Manager c) Lead Developer d) Scrum Master
Q2. Quel rôle n’est pas défini dans Scrum ?
a) Product Owner b) Scrum Master c) Product Manager d) Team
Q3. Quel est le nom de la réunion dans laquelle l’équipe démontre au Product owner et aux autres
personnes intéressées ce qui a été accompli durant le sprint ?
a) Sprint retrospective meeting b) Product review meeting
c) Sprint review meeting d) Stakeholder review meeting
Q4. Quand l’exécution d’un sprint est-elle finie ?
a) Cela dépend des événements b) Quand tous les items du product backlog sont « faits » (done)
c) Quand toutes les tâches planifiées sont finies d) À la fin de la durée prévue (timebox)
Q5. Quelle est la taille recommandée pour une équipe Scrum ?
a) 9 ± 3 b)10± 3 c)7± 2 d) Peu importe
Q6. Comment le product backlog est organisé ?
a) Items par importance décroissante b) Items par taille décroissante c) Au hasard
d) Par catégories
Q7. Qui estime l’effort nécessaire pour réaliser un item du product backlog ?
a) Product owner b) Scrum master c) Team d) Le développeur le plus expérimenté

Exercice 4: Gestion des risques

1- Qui doit gérer les risques inhérents à la stratégie, les risques reliés à la gestion et les risques inhérents aux
aspects technique dans un projet informatique ?
2- Qu’arrive-t-il si on ne gère pas les risques d’un projet ?
3- Donner quelques exemples de risques (conséquences défavorables) caractérisant les projets informatiques ?

1/2
4- Proposer des solutions pour réduire les risques suivants :

Description Priorité Gravité Facteurs (causes) Action(s) proposée(s)

Ne pas délivrer le Haute Haute  Mauvaise analyse de la
produit situation

Le produit ne répond Haute Haute  Pas assez de

pas aux besoins des communication entre les
partenaires (échoué) utilisateurs et les
développeurs
Rendre le produit Haute Moyenne  Pas assez de temps à
souhaité, mais hors consacrer au projet
délai

Rendre un produit Haute Moyenne  Ne pas avoir les bons

incomplet produits de
développement

Ne pas arriver à Moyenne Moyenne  Prendre trop de temps

développer le produit dans le développement
dans le budget (bugs, erreurs d’analyses)
planifié
Rendre un produit Moyenne Moyenne  Ne pas respecter les
qui n’a pas le niveau standards de «naming ».
de qualité souhaité ne pas écrire assez de
commentaires et
documents sur le produit

5- Dans le tableau ci-dessous on présente la gestion des risques selon les critères exposés :
Probabilité 1 = Minimale, 2 = Faible, 3 = Moyenne, 4 = Elevée, 5 = Maximale
Gravité 1 = Négligeable, 2 = Significatif, 3 = Majeure, 4 = Critique, 5 = Catastrophique
Magnitude = Probabilité x Gravité : On considère une gravité significative à partir d’une valeur 12
Proposer les actions à prendre pour traiter ces risques.

Risque cause (Facteur Probabilité Gravité Magnitude Action(s) proposée(s)

de risque) (criticité)
Ergonomie des 3 4 12
interfaces
homme- machine
inadaptés

Le temps de 3 3 9
réponse de
Rejet de l’application n'est
l'application pas acceptable
par les
utilisateurs

Mauvaise 2 3 6
compréhension
du but de
l’application

2/2