Rubriques

Introduction Haut de la page

"Le tout est d'être prêt." - Hamlet Acte V scène 2, v. 215

Un projet, comme la vie, est incertain. Nous identifions des risques par pour eux-mêmes, mais pour les anticiper et les limiter, si possible, ou y répondre lorsque nos stratégies de limitation ne suffisent pas.

Le risque détermine les plans d'itérations ; les itérations sont prévues pour traiter des risques spécifiques, en tentant de le borner ou de le réduire. La liste des risques est révisée de façon périodique pour évaluer l'efficacité des stratégies de limitation des risques, ce qui entraîne ensuite des révisions du plan de projet et des plans d'itérations supplémentaires.

La clé de la gestion du risque est de ne pas attendre qu'un risque se matérialise (et devienne un problème ou un échec) pour décider ce qu'il faut faire pour le résoudre. De la même façon qu'une modification de quelques degrés dans la trajectoire d'un vol transcontinental a un effet important sur l'endroit où l'avion atterrira, gérer un risque tôt est presque toujours moins coûteux et douloureux que nettoyer après qu'il se soit réalisé.

Stratégies de gestion des risques Haut de la page

Il existe trois stratégies principales [BOE91]:

  • Eviter le risque. Réorganisez le projet afin qu'il ne puisse plus être affecté par ce risque.
  • Transférer le risque. Réorganisez le projet afin que quelqu'un ou quelque chose d'autre ait la responsabilité du risque (client, fournisseur, banque, autre élément, etc.) Stratégie spécifique permettant d'éviter le risque.
  • Accepter le risque. Décider d'accepter l'éventualité du risque. Suivez les symptômes du risque et décidez dans un plan de secours de quoi faire si un risque apparaît.

    Si vous décidez d'accepter le risque, vous souhaiterez peut-être tout de même le limiter, c'est-à-dire prendre des mesures immédiates pour réduire son impact.

Types de risqueHaut de la page

Il est important de distinguer les risques directs et indirects. Pour simplifier, nous avons un certain degré de contrôle sur les risques directs ; alors que nous ne pouvons contrôler les risques indirects.

Nous devons connaître les risques indirects, cependant, ils ont des conséquences limitées du point de vue pratique : comme nous ne pouvons pas les changer, il ne sert pas à grand chose de s'inquiéter à leur sujet. Il est possible que cela soit la fin du monde demain, mais il est aussi possible que cela ne soit pas le cas, et si ce n'est pas le cas nous devons continuer notre travail !

Parfois, un risque direct peut se camoufler en risque indirect. Par exemple, nous dépendons peut-être d'un fournisseur externe pour un composant ou un ensemble de composants. Il semblerait que ce soit un risque indirect, mais si nous avons des plans de secours pour ces composants, nous pouvons contrôler le risque : choisir des fournisseurs alternatifs ou décider de développer nous-même la fonctionnalité. Bien souvent, nous contrôlons les événements plus que nous le croyons !

Avec des risques indirects, vous devez trouver comment obtenir un certain contrôle sur les risques ou simplement les noter et passer à la suite. Il est inutile de s'inquiéter à propos de ce qu'on ne peut pas changer.

Risques de ressourceHaut de la page

Organisation
  • L'implication dans ce projet est-elle suffisante (y compris des dirigeants, des testeurs, de l'assurance qualité, et d'autres parties externes mais impliquées)?
  • Est-ce le projet le plus important que cette organisation ait jamais effectué ?
  • Existe-t-il un processus bien défini pour l'ingénierie logicielle ? La consignation des exigences et la gestion ?
Financement
  • Le financement permettant d'effectuer le projet est-il en place ?
  • Un financement a-t-il été attribué pour la formation et le mentorat ?
  • Y a-t-il des limitations de budget obligeant par exemple le système à être livré à un coût fixe ou risquer d'être annulé ?
  • Les estimations de coût sont-elles correctes ?
Personnes
  • Y a-t-il suffisamment de personnes disponibles ?
  • Possèdent-ils des compétences et une expérience appropriés ?
  • Ont-ils travaillé ensemble auparavant ?
  • Pensent-ils que le projet peut réussir ?
  • Des représentants des utilisateurs sont-ils disponibles pour les revues ?
  • Des experts du domaine sont-ils disponibles ?
Temps
  • Le calendrier est-il réaliste ?
  • La fonctionnalité peut-elle être gérée selon la portée pour répondre au calendrier ?
  • Quelle est l'importance de la date de livraison ?
  • Y a-t-il assez de temps pour "faire le travail correctement"?

Risques métierHaut de la page

  • Que se passe-t-il si un concurrent atteint le marché en premier ?
  • Que faire si le financement du projet est en péril (cette question peut se également se poser sous la forme "qu'est-ce qui assure un financement approprié")?
  • La valeur prévue du système est-elle supérieure au coût prévu ? (assurez-vous de prendre en compte la valeur temporelle de l'argent et le coût du capital).
  • Que se passe-t-il si les contrats avec les fournisseurs principaux ne peuvent pas être effectués ?

Risques techniquesHaut de la page

Risque de portée
  • Le succès peut-il se mesurer ?
  • Existe-t-il un accord sur la manière de mesurer le succès ?
  • Les exigences sont-elles relativement stables et bien comprises ?
  • La portée du projet est-elle ferme où peut-elle s'accroître ?
  • Les échelles de temps du développement du projet sont-elles réduites et rigides ?
Risques technologiques
  • La technologie a-t-elle fait ses preuves ?
  • Les objectifs de réutilisation sont-ils raisonnables ?
    • Un artefact doit être utilisé une fois avant d'être réutilisé.
    • Il peut falloir plusieurs versions d'un composant avant qu'il soit suffisamment stable pour être réutilisé sans changements significatifs.
  • Les volumes de transaction des exigences sont-ils raisonnables ?
  • Les estimations du taux de transaction sont-elles crédibles ? Sont-elles trop optimistes ?
  • Les volumes de données sont-ils raisonnables ? Peuvent-ils être contenus dans les ordinateurs centraux actuellement disponibles ou bien, si les exigences vous amènent à penser qu'une station de travail ou qu'un système départemental fera partie de la conception, les données peuvent-elles être raisonnablement contenues à cet endroit ?
  • Existe-t-il des exigences techniques inhabituelles ou représentant un défi et demandant à l'équipe du projet de traiter des problèmes qu'ils ne connaissent pas bien ?
  • Le succès dépend-t-il de produits, de technologies ou de services nouveaux ou jamais expérimentés, de matériel, de techniques ou de logiciels nouveaux ou qui n'ont pas fait leurs preuves ?
  • Existe-t-il des dépendances externes à des interfaces d'autres systèmes, y compris externes à l'entreprise ?  Les interfaces requises existent-elles ou doivent-elles être créées ?
  • Certaines exigences de disponibilité et de sécurité sont-elles extrêmement rigides (par exemple, "le système ne doit jamais échouer")?
  • Les utilisateurs du système sont-ils novices par rapport au type de système développé actuellement ?
  • Existe-t-il un risque accru du fait de la taille ou de la complexité de l'application ou de la nouveauté de la technologie ?
  • Existe-t-il une exigence de prise en charge de la langue nationale ?
  • Est-il possible de concevoir, d'implémenter, et d'exécuter ce système ? Certains systèmes sont tout simplement trop gros ou trop complexes pour fonctionner correctement.
Risque de dépendance externe
  • Le projet dépend-il d'autres projets de développement (parallèles) ?
  • Le succès dépend-il de produits standards ou de composants développés en externe ?
  • Le succès dépend-il de l'intégration réussie d'outils de développement (outils de conception, compilateurs, etc.), de technologies d'implémentation (systèmes d'exploitation, bases de données, mécanismes de communication interprocessus, etc.) Possédez-vous un plan de secours pour livrer le projet sans ces technologies ?

Risques liés au calendrier Haut de la page

L'expérience montre que 85% des risques ont un impact direct ou indirect sur le calendrier, et donc implicitement sur le coût. Environ 5% ont uniquement un impact sur le coût. Les risques restants n'ont aucun impact direct sur le coût ou le calendrier, mais sur la qualité par exemple.

Si vous considérez la date de tombée comme un ennemi, adoptez une approche douce avec des livraisons incrémentielles. Eviter de faire une livraison massive peut permettre de respecter les délais.

Certains projets ont des dates de tombée véritablement "vitales". Les logiciels analysant "en direct" le résultat d'une élection pendant la soirée électorale, par exemple, ont peu de valeur s'ils sont mis en vente la semaine après l'élection. Vos logiciels peuvent aussi être distancés par des concurrents : ils peuvent lancer un meilleur produit que le vôtre alors que vous êtes toujours en pleine construction. Brusquement, vous n'êtes plus dans la course - et vous n'y pouvez pas grand chose. En général, cependant, les dates de tombée ne sont pas aussi vitales. Les retards affectent principalement les coûts.

En général, établissez votre engagement en terme de calendrier selon votre meilleure estimation, en vous laissant une marge de sécurité raisonnable.

engagement = estimation + marge de sécurité

On conseille parfois de définir les attentes en terme de calendrier par rapport à votre stratégie de repli, c'est-à-dire de les baser sur vos plans de secours, mais c'est un peu trop pessimiste car tous les risques ne se réaliseront pas.

Les risques en terme de calendrier sont intégrés dans certains outils d'estimation des prix de revient. Par exemple, dans le modèle COCOMO, de nombreux inducteurs de coûts comme :

  • complexité (cplx)
  • contraintes en temps réel (temps)
  • contraintes de stockage (stoc)
  • expérience (Vexp)
  • disponibilité d'outils de qualités (outil)
  • pression du calendrier (calend)

sont en fait des facteurs de risques.

D'autres techniques sophistiquées de gestion des risques incluent l'utilisation d'une simulation Monte Carlo, dans laquelle un grand nombre de "scénarios" sont exécutés par un outil de simulation pour calculer les risques globaux et les plans de secours [KAR96].



RUP (Rational Unified Process)   2003.06.15