Instructions: Liste de risques
Ces instructions expliquent comment identifier et gérer les risques d'un projet logiciel.
Relations
Eléments connexes
Description principale

Introduction

"Soyons prêts, voilà tout." - Hamlet V:ii:215

Un projet, comme la vie, est incertain. Nous n'identifions pas les risques pour eux, mais pour les anticiper et les atténuer, si possible, ou pour y répondre lorsque nous ne pouvons pas les anticiper.

Les risques décident des plans d'itérations car elles sont destinées à répondre à certains risques en les limitant ou les réduisant. La liste de risques est revue régulièrement pour évaluer l'efficacité des plans d'atténuation, ce qui décide des révisions du planning de projet et des itérations suivantes.

Le point clé de la gestion de risques est de ne pas attendre qu'un risque se matérialise (et devienne un problème ou un échec) pour décider de la manière de le résoudre. Tout comme une modification de cap de quelques degrés d'un vol transcontinental a un effet considérable sur l'endroit où il atterrit, gérer un risque tôt est pratiquement toujours moins cher et moins compliqué que de devoir le résoudre par la suite.

Stratégies de gestion de risque

Il existe trois stratégies principales [BOE91] :

  • Suppression du risque. Réorganiser le projet pour qu'il ne puisse pas être affecté par ce risque.
  • Transfert du risque. Réorganiser le projet pour que le risque devienne du ressort d'une autre personne ou organisation (client, sous-traitant, banque, autre élément...). Stratégie de suppression de risque particulière.
  • Acceptation du risque. Décider de laisser le risque comme éventualité. Surveiller les symptômes du risque et décider d'un plan de réponse s'il se matérialise.

Si vous décidez d'accepter le risque, vous pouvez également choisir d'atténuer le risque, de prendre des mesures concrètes permettant de réduire un impact éventuel.

Types de risques

Il est important de faire la différence entre les risques directs et indirects. Pour simplifier, un risque direct est un risque sur lequel vous avez un certain degré de contrôle tandis que vous n'en avez aucun sur un risque indirect.

Bien qu'il ne faille pas ignorer les risques indirects, ils n'ont que peu de conséquences sur le plan pratique : comme ils sont hors de notre contrôle il est inutile de s'en préoccuper. Malgré le fait que le monde puisse disparaître demain, il est également possible qu'il ne disparaisse pas et il est donc préférable de continuer à travailler !

Dans certains cas un risque indirect est en fait un risque direct déguisé. Par exemple, certains composants dépendent peut-être d'un fournisseur externe. Ce risque semble être indirect, mais si nous disposons d'un programme d'urgence pour ces composants, nous pouvons prendre contrôle de ce risque : nous pouvons choisir un autre fournisseur ou décider de développer les fonctions nous-même. Dans de nombreux cas, nous avons plus de contrôle que nous ne le pensons !

Pour gérer les risques indirects, vous devez essayer de gagner un certain degré de contrôle sur le risque ou le noter et continuer. Il est inutile de s'étendre sur ce que vous ne pouvez pas changer.

Risques de ressources

Organisation
  • Le projet reçoit-il l'engagement requis (y compris au niveau de la direction, des testeurs, de la garantie de qualité et autres parties prenantes externes) ?
  • S'agit-il du plus grand projet jamais entrepris par la société ?
  • Existe-t-il un processus de génie logiciel bien défini ? De capture et gestion des exigences ?
Financement
  • Le financement du projet est-il en place ?
  • Disposez-vous de financement pour la formation et le mentorat ?
  • Avez-vous reçu des contraintes budgétaires comme un coût fixe, le projet est-il sujet à annulation ?
  • Les estimations sont-elles précises ?
Ressources
  • Disposez-vous de suffisamment de personnes ?
  • Ont-ils les connaissances requises ?
  • Ont-ils déjà travaillé ensemble ?
  • Croient-ils dans la réussite du projet ?
  • Disposez-vous d'utilisateurs types pour les revues ?
  • Disposez-vous d'experts dans le domaine ?
Temps
  • Le calendrier est-il réaliste ?
  • Pouvez-vous faire varier les fonctionnalités pour adhérer au calendrier ?
  • La date de livraison est-elle critique ?
  • Disposez-vous de suffisamment de temps pour le faire correctement ?

Risques de type affaires

  • Que se passe-t-il si un concurrent est prêt avant ?
  • Que se passera-t-il si le financement du projet rencontre des difficultés (une variante est "comment assurer un financement correct") ?
  • La valeur projetée du système est-elle supérieure au coût envisagé ? (veillez à inclure la valeur-temps de l'argent et le coût des capitaux).
  • Que se passera-t-il si vous ne pouvez pas passer de contrat avec les fournisseurs principaux ?

Risques techniques Début de la page

Risques de portée
  • Pouvez-vous mesurer la réussite ?
  • Toutes les parties sont-elles d'accord sur la mesure de la réussite ?
  • Les exigences sont-elles suffisamment stables et bien comprises ?
  • La portée du projet est-elle figée ou continue-t-elle à croître ?
  • La durée prévue de développement est-elle courte et inflexible ?
Risques technologiques
  • La technologie est-elle éprouvée ?
  • Les objectifs de réutilisation sont-ils raisonnables ?
    • Un produit doit être utilisé avant d'être réutilisé.
    • Il faut parfois plusieurs versions significatives d'un composant avant qu'il ne soit suffisamment stable pour être réutilisé sans trop de modifications.
  • Les volumes de transactions des exigences sont-ils raisonnables ?
  • Les estimations de taux de transactions sont-elles raisonnables ? Sont-elles trop optimistes ?
  • Les volumes de données sont-ils raisonnables ? Peuvent-ils être gérés par les ordinateurs disponibles, ou, si les exigences vous indiquent qu'un poste de travail ou un système départemental fera partie de la conception, pourront-ils gérer les données ?
  • Existe-t-il des exigences inhabituelles ou complexes qui demanderont à l'équipe de projet de résoudre des problèmes avec lesquels elle n'est pas familière ?
  • La réussite dépend-elle de produits, technologies ou services nouveaux ou de matériel, techniques ou logiciel qui n'ont pas été mis à l'épreuve ?
  • Existe-t-il des dépendances externes sur des interfaces vers d'autres systèmes, y compris d'autres entreprises ?  Les interfaces existent t'elles ou doivent-elles être créées ?
  • Existe-t-il des exigences de disponibilité et de sécurité extrêmement inflexibles (par exemple, "le système ne peut pas tomber en panne") ?
  • Les utilisateurs du système ont-ils l'expérience du type de système créé ?
  • Existe-t-il un risque lié à la taille et à la complexité de l'application ou à la nouveauté de la technologie ?
  • Existe-t-il une exigence pour la prise en charge de langues nationales ?
  • Est-il possible de concevoir, installer et utiliser ce système ? Certains systèmes sont simplement trop grands ou trop complexes pour fonctionner correctement.
Risque lié aux dépendances externes
  • Le projet dépend-il d'autres projets en développement (parallèles) ?
  • La réussite dépend-elle de produits disponibles sur le marché ou de composants développés à l'extérieur ?
  • La réussite dépend-elle de l'intégration d'outils de développement (outils de conception, compilateurs...), de technologies d'application (systèmes d'exploitation, bases de données, mécanismes de communications entre processus...). Disposez-vous d'un plan de secours pour livrer le projet sans ces technologies ?

Risques de planification

L'expérience montre que 85 % des risques ont un impact direct ou indirect sur le calendrier et donc également sur le coût. Environs 5 % des risques n'affectent que le coût. Le reste n'a pas d'impact direct sur le coût ou le calendrier mais sur la qualité, par exemple.

Si l'ennemi est le calendrier, approchez-le en douceur par des livraisons incrémentales. Evitez les livraisons massives uniques pour essayer de vous tenir au calendrier.

Certains projets ont de véritable "dates de péremption". Un logiciel pour analyser le résultat d'une élection en direct, par exemple, ne sera pas très utile s'il sort la semaine suivant l'élection. Un logiciel peut également être rendu obsolète par vos concurrents : ils lancent un logiciel meilleur que le vôtre alors que vous êtes toujours en cours de développement. Soudainement, vous n'êtes plus dans le coup, et vous ne pouvez rien y faire. Généralement, peu de projets ont de telles échéances. Les délais affectent principalement le coût.

En règle générale, votre engagement doit être égal à l'estimation la plus précise, plus une réserve raisonnable.

engagement = estimation + réserve

D'autres conseillent de baser votre engagement sur la stratégie de récupération, c'est à dire sur votre plan de réserve, mais c'est un peu trop pessimiste car tous les risques ne se matérialiseront pas.

Les risques de planifications sont intégrés dans certains outils d'estimation. Par exemple, dans le modèle COCOMO, des éléments de coûts comme :

  • complexité (cplx)
  • contraintes en temps réel (time)
  • contraintes de stockage (stor)
  • expérience (Vexp)
  • disponibilité de bons outils (tool)
  • pressions du calendrier (sced)

sont en réalité des facteurs de risque.

Des techniques de gestion de risque plus sophistiquées impliquent l'utilisation de la simulation Monte Carlo, dans laquelle un nombre très élevé de "scénarios" est passé par un outil de simulation pour calculer le risque global et les imprévus [KAR96].