Gestion des risques pour le développement de logiciels

La gestion des risques est un système permettant d’identifier, de traiter et d’éliminer les problèmes susceptibles de nuire au coût, au calendrier ou au succès technique d’un projet ou au moral de l’équipe de projet.

« Les problèmes de demain sont les risques d’aujourd’hui. » Par conséquent, le « risque » est clairement défini comme un problème qui pourrait causer des dommages ou menacer le calendrier du projet, mais qui ne s’est pas encore produit.

Si vous ne prenez pas l’initiative de gérer les risques, vous ferez face à des risques.

Le développement de logiciels  est une activité à haut risque, et il peut y avoir des risques à n’importe quelle étape du processus de développement du projet. L’adoption d’une méthode de gestion active des risques peut rendre le processus de projet plus stable, obtenir une grande capacité de suivi et de contrôle du projet, et peut éviter et transférer les risques, ou atténuer les effets néfastes des risques.

La gestion des risques est le processus d’identification, d’analyse, de réponse et de suivi des risques du projet. C’est une activité de gestion très importante dans la gestion de projet. La mise en place efficace de la gestion des risques logiciels est la garantie du bon déroulement du développement du projet logiciel.

La réalisation de la gestion des risques doit comprendre trois éléments :

  • Un plan de gestion des risques doit être formulé dans le plan de développement du projet ;
  • Le budget du projet doit inclure les fonds nécessaires pour résoudre le risque ;
  • Lors de l’évaluation du risque, l’impact du risque doit également être inclus dans la planification du projet.

Voyons comment nous pouvons prendre des mesures préventives pour atténuer les risques qui surviennent souvent lors du développement de logiciels.

  1. Exigences peu claires  — Les exigences peu claires sont des problèmes fréquemment rencontrés dans le processus de développement logiciel. De tels problèmes se manifestent souvent sous de nombreux aspects tels que la portée non définie des exigences, les exigences non affinées, la description des exigences peu claire, les exigences manquantes et les exigences contradictoires. Dans le cycle de vie du processus de développement logiciel, le gaspillage causé par des exigences peu claires est le plus important et doit être résolu dès que possible. Il est très difficile de déterminer les besoins des utilisateurs.

Actions préventives

  • Laissez les utilisateurs participer au développement par le biais de discussions et de réunions courtes et plus fréquentes
  • Développer et communiquer avec les parties prenantes à l’aide de prototypes filaires / d’interface utilisateur

2. Pour les projets avec une large distribution d’utilisateurs et un grand nombre d’utilisateurs, il est souvent difficile de collecter de manière exhaustive les besoins des utilisateurs, et des réunions de recherche sur les besoins sont généralement adoptées pour confirmer les besoins.

Actions préventives

Quelques semaines avant la réunion, nous avons sondé les besoins des utilisateurs dans diverses régions et départements, puis avons réuni des représentants des utilisateurs de toutes les régions ou départements pour organiser un séminaire sur les exigences afin de recueillir les exigences tout au long de la réunion. Cette méthode convient aux utilisateurs qui ont une certaine expérience informatique.

2.  Piège 80/20  — Lorsqu’un chef de projet ou un développeur dit que 80 % de la tâche a été accomplie, vous devez être prudent. Parce que les 20% restants peuvent prendre 80% du temps, ou cela peut ne jamais être terminé.

Les projets de développement logiciel manquent souvent de visibilité en termes d’avancement du projet et de qualité logicielle. Moins le projet est visible, plus il est difficile de contrôler le projet et plus il est susceptible d’échouer. Nous pouvons améliorer la visibilité du projet grâce au développement itératif, à l’examen technique et à l’intégration continue.

Actions préventives:

  • Développement itératif À l’aide d’un modèle de développement itératif, le processus de livraison du produit est divisé en plusieurs étapes et livré de manière incrémentielle selon les fonctions.
  • L’examen technique est un élément important pour garantir la qualité du logiciel. L’examen technique comprend l’exercice de code, l’examen des réunions et l’examen par les pairs. La revue de code peut être une revue croisée entre développeurs ou une revue de développeurs ordinaires par des développeurs seniors ; Le bilan de la réunion est généralement réalisé au moins une fois toutes les deux semaines, et la durée de chaque bilan ne doit pas être trop longue, ce qui est une garantie importante pour la réussite du projet.
  • L’intégration continue peut disperser le processus final d’intégration et de mise en service à grande échelle dans l’avancement du développement hebdomadaire et quotidien du projet. Ainsi, tout le monde dans le projet peut saisir à tout moment l’avancement global actuel, et trouver et résoudre rapidement les problèmes dans le processus d’intégration.

3.  L’innovation technologique  est une activité technologique et économique exploratoire et créative. Dans le processus de développement, l’introduction de nouvelles technologies se heurtera inévitablement à divers risques. Des mesures telles que le développement de logiciels en forme de T et le prototypage avec de nouvelles technologies avec des témoignages d’utilisateurs de pointe.

4.  Problèmes de performances  — En raison du manque d’informations sur la conception logicielle, des problèmes de performances sont souvent exposés après le déploiement du système ou l’utilisation d’un nouveau système pendant un certain temps. Les problèmes de performances nécessitent généralement beaucoup de travail d’optimisation, voire une refonte partielle ou complète. Ni les utilisateurs ni les développeurs ne veulent de problèmes de performances. L’équipe doit être consciente de ce problème, mettre en œuvre une planification et des tests de performance tout au long du processus de développement et inclure des exigences de performance dans les exigences non fonctionnelles.

5.  Problèmes d’utilisabilité -  L’utilisabilité du logiciel comprend de nombreux facteurs tels que l’efficacité, la facilité d’apprentissage, la facilité de mémorisation, l’agréable et la difficulté de commettre des erreurs. Souvent en raison de la mauvaise ergonomie du logiciel, les utilisateurs sont insatisfaits voire éliminés par le marché. Dans le développement de projet, une attention particulière doit être accordée aux problèmes d’utilisabilité pour éviter les risques d’utilisabilité du logiciel.

Structure de répartition des risques

Nous pouvons utiliser la structure de répartition des risques pour classer le risque potentiel pour différents aspects :

La structure de répartition des risques est la décomposition hiérarchique des risques, en partant de l’élément nœud racine qui représente le projet, en descendant vers les différentes catégories de risques, puis les risques de niveau plus fin.

En plus de présenter les risques du projet dans une structure de répartition des risques, il est possible de combiner l’utilisation de la légende des couleurs pour représenter l’impact du risque. Jetez un œil à l’exemple de structure de répartition des risques ci-dessous, une légende d’impact avec cinq éléments a été configurée, représentant les cinq niveaux d’impacts que les risques peuvent avoir sur le projet avec cinq codes de couleur distincts.

Voici un exemple de structure de répartition des risques :

Exemple de structure de répartition des risques

Modifier cette structure de répartition des risques en ligne )

Il existe de nombreux outils de gestion des risques que vous pouvez utiliser pour structurer les risques. Outre la structure de répartition des risques, vous pouvez également envisager d’utiliser le  diagramme de cause à effet  (également appelé diagramme en arête de poisson).

Conclusion

Plus le risque est identifié et géré tôt, plus il est probable qu’il soit évité ou réduit l’impact du risque lorsqu’il se produit. En particulier dans les projets complexes avec un grand nombre de participants au projet, un large éventail d’implications et un contenu technique élevé doivent être renforcés.


Leave a Reply

Votre adresse e-mail ne sera pas publiée.