Voici quelques aperçus de la valeur de la recherche défauts d'exigences avant la conception ou le codage.
Pour une équipe de développement de logiciels, il est très utile de détecter les défauts le plus tôt possible. Mieux encore, il s’agit de prévenir complètement les défauts. D’excellentes exigences constituent une forme efficace de prévention des défauts et prévention des reprises. Une exigence ambiguë peut conduire à un gaspillage d’efforts substantiel.
Les défauts surviennent avant le début du codage
Des défauts surviennent dans les exigences et l’architecture avant même le début du codage. Imaginons que nous soyons dans une entreprise d'assurance et que les gens d'affaires ont décidé qu'un système nouveau (ou modifié) était nécessaire. Ils ont décidé de décrire ce qu'ils voulaient et de le transmettre au service informatique pour estimation. De telles exigences sont souvent écrites sous forme de user stories, généralement dans un format cohérent : « En tant que « … », je dois « …. "de sorte que" …
Dès la prise de la plume, des ambiguïtés et des omissions apparaissent, c'est inévitable. Ces erreurs dans les exigences écrites (si elles ne sont pas découvertes) peuvent entraîner des retouches coûteuses plus tard dans le projet. Le coût de ces défauts n’est pas négligeable : le Royaume-Uni est sur le point de perdre 37 milliards de livres sterling en raison de l’échec de projets informatiques (agiles) (référence). Pour éviter ces coûts évitables, nous devons veiller à ce que les exigences soient aussi claires et complètes que possible. Même les rédacteurs d’exigences les plus compétents commettent des erreurs involontaires, et il n’est pas si facile de les corriger. C’est là que l’automatisation peut désormais aider.
Avantages de la détection précoce des défauts des exigences
L’évaluation d’une découverte précoce d’un défaut d’exigence n’est ni simple ni définitive. La raison principale est que cela dépend de la date à laquelle (dans le processus de développement) ces défauts auraient pu être découverts. Si un défaut n'est détecté que beaucoup plus tard, sa réparation nécessitera beaucoup plus d'efforts, coûtant des milliers de dollars. S'il suffit de détecter une étape du SDLC plus tôt, quelques heures d'efforts pourront peut-être être économisées. En moyenne, nous estimons que 4 heures de personnel économisées pour chaque défaut d'exigence découvert tôt – environ $200.
Effort typique de recherche, de réparation et de vérification du correctif de :
un défaut d'exigence trouvé lors de la exigences étape : 20 minutes – 4 heures
un défaut d'exigence trouvé lors de la conception étape : 1 à 10 heures
un défaut d'exigence trouvé lors de la développement étape : 2 – 15 heures
un défaut d'exigence trouvé lors de la test du système étape : 4 heures à la hausse
un défaut d'exigence trouvé lors de la production étape : 8 heures à la hausse
Notez que cela ne représente que le travail supplémentaire pour résoudre le problème, cela ne répond pas aux conséquences du défaut.
Coût des besoins Défauts constatés en production
Lorsqu'un défaut d'exigence est constaté en production, il est généralement signalé par un utilisateur, et nous devons prendre en compte :
- Combien d’utilisateurs ont été concernés avant que cela nous soit signalé.
- Combien d'utilisateurs supplémentaires seront affectés jusqu'à ce que le problème soit résolu.
- Quels sont les coûts liés à la fourniture d’une solution de contournement à ceux qui ont été concernés.
- Quelle est la perte consécutive de ce défaut pour les clients et notre organisation.
- L'effet d'entraînement (coût d'opportunité) de détourner l'attention sur ce problème par rapport à d'autres opportunités.
La somme de ces coûts dépasse généralement de loin le coût de réparation du correctif. Dans certains cas extrêmes, la survie d’une entreprise peut être menacée par un seul défaut dans une application client majeure. par exemple, un système bancaire qui a perdu la trace des soldes des comptes
Défauts de sécurité – un cas particulier
Les défauts de sécurité non détectés avant la production seront toujours coûteux à corriger, peuvent souvent impliquer des poursuites judiciaires contre l'organisation et sont généralement mesurés en des millions de dollars. La détection précoce des défauts de sécurité (en particulier lors de la phase d’exigences) peut donc potentiellement éviter des incidents pouvant coûter des millions de dollars.
Valeur des défauts des exigences de recherche de ScopeMaster
Tournons-nous vers la valeur fournie par ScopeMaster en exposant précocement les défauts des exigences. Il y a en fait de multiples avantages à utiliser ScopeMaster selon vos besoins :
- Un moyen très rapide de qualité assurer exigences
- Trouve (certaines) exigences manquantes potentielles – automatiquement. (Rappelez-vous : une exigence manquante est un défaut).
- En améliorant les exigences, il y aura moins de défauts ailleurs, dans les calendriers, dans le développement et les tests. les coûts réduiront.
- Améliorer la clarté des exigences, réduit les discordes potentielles entre les membres de l’équipe en raison d’exigences ambiguës.
- Génère une métrique de taille fonctionnelle automatisée sans effort manuel, qui peut être utilisée pour donner plus de contrôle du projet.
- Améliore le rapidité de mesure de la taille fonctionnelle par 200-400% (pour les projets qui mesurent la taille fonctionnelle)
- Modifie le langage utilisé par les auteurs des exigences de telle sorte qu'au fil du temps, prévenir les défauts des exigences d’être introduit.
Ces éléments n’ont pas tous la même valeur et leur importance relative varie d’un projet à l’autre. Dans de nombreux cas, le dernier point est peut-être le plus important. Si vous parvenez à prévenir les défauts en spécifiant les exigences de manière plus précise et plus complète, il y aura moins de défauts à rechercher plus tard.
Alors que les avantages potentiels de l'utilisation de ScopeMaster sur un projet pourraient se chiffrer en millions, un modeste $200/défaut est une estimation très prudente de l’intérêt d’exposer le défaut le plus tôt possible.
- La découverte des défauts des exigences dans la phase des exigences se fait normalement avec les 3-4 amigos qui en discutent ; par la suite, il faut quelques minutes pour réparer. 15 minutes de discussion entre amis représentent 1 heure de temps de travail du personnel. (Beaucoup de ces problèmes pourraient être trouvés et corrigés en 4 à 10 minutes avec ScopeMaster.)
Trouver et corriger les défauts des exigences lors des tests du système
- La détection des défauts liés aux exigences lors de la phase de test du système peut encore prendre seulement 1 heure, mais la correction prendra beaucoup plus de temps car :
- Lorsqu'un (défaut d'exigences) est détecté dans le test du système, il doit être copieusement documenté, puis nécessite une coordination extraordinaire des testeurs et des développeurs de SME pour trier et vérifier qu'il s'agit d'un défaut d'exigence réel, puis enfin l'exigence est corrigée.
- La mise en œuvre du correctif peut représenter un travail de configuration modeste, mais les nouvelles couches de test autour de ce défaut, ainsi que toutes les fonctionnalités associées qui doivent également être testées à nouveau par régression, ne sont pas triviales.
- La découverte tardive d’un défaut lié aux exigences signifie qu’il existe une probabilité plus élevée de mauvais correctifs. c'est à dire. un défaut en entraîne un ou deux autres (chacun avec sa propre documentation, son propre cycle de triage et de correction-vérification).
- Il existe une tendance humaine à ne pas remettre en question les exigences ultérieurement. Les testeurs ont tendance à accepter les exigences comme étant correctes et sont plus susceptibles de remettre en question la conformité du codage/configuration avec les exigences, et non avec les exigences elles-mêmes. La conséquence est que les défauts (causés par de mauvaises exigences) sont plus susceptibles de se retrouver en production, avec de très mauvaises conséquences.
