Quelles sont les choses que vous mettez sur un document d'analyse d'impact?

Vous corrigez donc des bogues, puis vous en avez rencontré un qui pourrait affecter d'autres modules du produit logiciel. Vos données ne sont pas suffisantes pour étayer votre affirmation concernant les effets du correctif et vous avez été invité à créer un document d'analyse d'impact.

1. Existe-t-il un processus défini sur la façon de procéder?
2. Quelles sont les informations clés nécessaires?
3. Existe-t-il des formats / modèles connus pour ce document?

Les modèles que j'ai vus pour l'analyse d'impact ont été créés dans l'entreprise pour laquelle je travaille. Nous l'utilisons pour évaluer les demandes de changement et avant d'y travailler (et éventuellement pour en rejeter). Il y avait des sections comme celle-ci:

• Impact sur les exigences: dans cette section, l'analyste écrit ce qui doit être modifié dans les cas d'utilisation pour prendre en charge la modification demandée.
• Impact sur la conception et l'architecture: dans cette section, l'architecte et le concepteur mentionnent quelles parties du modèle doivent être modifiées ou refaites pour prendre en charge le changement.
• Impact sur le test: le QC écrit que les cas de test doivent être mis à jour.
• Estimation et impact sur l'échéancier: Le chef de projet estime l'effort nécessaire et le coût du changement et l'impact sur l'échéancier du projet.

Pour couvrir tous les impacts possibles, vous devez parcourir les dépendances. Si vous avez une matrice de traçabilité bidirectionnelle, cela vous facilitera la tâche.

Nous avons utilisé l'ordre ci-dessus car le concepteur devra connaître l'impact du point de vue de l'analyste pour avoir une meilleure idée du changement et le testeur doit également connaître l'opinion de l'analyste et de l'architecte. De même, le PM a besoin de toutes les informations pour connaître le coût et le calendrier.

Nous l'avons utilisé avec les CR, mais vous pouvez l'utiliser avec des bogues de la même manière. De plus, si vous devez le faire pour choisir entre plusieurs solutions de correction pour résoudre le bogue, vous devrez répéter l'analyse d'impact pour chaque solution possible et consolider toutes les données dans un formulaire DAR (Decision Analysis and Resolution) pour savoir quelle solution est le meilleur. Dans le formulaire DAR, vous devez ajouter certains facteurs d'évaluation tels que la maintenabilité future ou d'autres facteurs qui ne sont pas implicitement inclus dans l'analyse d'impact. Donnez ensuite le poids de chaque facteur et donnez chaque score de solution dans chaque facteur. Enfin, multipliez et additionnez le score * poids et choisissez le meilleur. Notez que le coût peut être inclus dans les facteurs ou le PM peut avoir une autre opinion.

Je pense qu'avec toute documentation, l'approche agile est bonne. Maintenant, il y a certaines idées fausses selon lesquelles agile signifie "pas de documentation ou d'analyse du tout", mais ce n'est pas le cas. Les choses que j'ai lues sur Agile disent: «utilisez ce qui fonctionne». Je suppose que cela signifie que le document doit être long et détaillé à la hauteur de la tâche.

Les modèles peuvent être utiles en tant que liste de contrôle, mais je n'exigerais pas que chaque section soit remplie pour les changements mineurs ou à faible risque. Pour un changement d'une ligne, vous n'avez peut-être pas du tout besoin d'un document. Je n'ai jamais utilisé de modèle pour un document d'analyse d'impact, mais je traite régulièrement des exigences métier ou des spécifications techniques. Un modèle peut être trop restrictif; une bonne ligne directrice est plutôt de considérer qui sera le public. S'il s'agit de gestionnaires qui ne sont pas techniques, concentrez-vous sur la justification commerciale du changement. Si c'est pour les techniciens, fournissez un peu de fond pour qu'une nouvelle personne dans l'équipe ne soit pas perdue et donnez-leur suffisamment pour démarrer s'ils doivent soutenir le changement. De plus, si vous voulez quelque chose d'encore plus léger et sans friction, n'utilisez pas du tout de document, mettez-le sur un wiki.

Informations à inclure:

• Brève description du problème
• Expliquer ou montrer un exemple de la façon dont un défaut provoque une défaillance et / ou une inefficacité
• Inclure une estimation de la complexité
• Inclure une estimation du coût et du temps de réparation

C'est un minimum décent. L'autre article a mis en évidence des trucs CMMi assez lourds d'IBM; c'est génial si vous avez le temps et les ressources pour cela (et quand vous construisez des systèmes pour la NASA où la vie humaine est en jeu, alors les gens devraient être sérieux à ce sujet) mais pour les petites équipes, vous n'avez probablement pas besoin d'être aussi lourd . Soyez prudent avec l'estimation, comme toujours. Les gestionnaires sont enclins à supposer qu'une estimation est la réalité.

Notez qu'il y a des dangers dans l'approche agile. Certains développeurs pensent que cela signifie, "aucun document nécessaire, commencez simplement à pirater" (ce qui pourrait être OK dans certaines situations). En outre, d'autres prendront la latitude compte tenu de la tâche et rédigeront simplement des documents vraiment merdiques qui n'aident pas vraiment (pas nécessairement OK dans la plupart des situations). Le problème tient en partie au fait que bien écrire exige un certain effort, des compétences et du temps; la plupart d'entre nous sont à court d'au moins deux de ces choses;)

J'ai toujours été très attaché à la documentation, car cela prouve que vous avez au moins suffisamment réfléchi pour être admissible à un plan. Mais dans ma vieillesse, j'ai également compris que trop de documentation peut elle-même devenir un problème de maintenance, et que pas assez de gens se soucient suffisamment de maintenir la documentation à jour.

Le document d'analyse d'impact est en effet requis dans les projets à grande échelle, spécialement lorsque les programmeurs travaillent géographiquement à différents endroits.

Le document d'analyse d'impact doit être approuvé par le responsable pour s'assurer que le changement n'affectera pas l'autre composant qui fonctionne bien en production.

Une analyse d'impact est nécessaire pour s'assurer que l'exigence est complètement comprise et que tous les composants à changer sont identifiés pour éviter un nouveau travail

L'analyse d'impact est également requise pour la responsabilisation des parties prenantes clientes. Sinon, lorsqu'un problème survient après le déploiement, le développeur devient le bouc émissaire.

L'analyse d'impact est la base d'estimation. Sans cela, l'estimation n'a pas de support. Il peut être trop élevé ou trop bas. Avec l'analyse d'impact, si l'effort réel dépasse, il est également facile de l'expliquer.

Ici, vous avez un modèle normé pour un rapport d'analyse d'impact. Il est personnalisé pour une branche spécifique de l'industrie, mais contient néanmoins des sections utiles qui peuvent servir d'inspiration pour écrire votre propre document.

Le lien: http://www.itu.int/en/itu-d/projects/documents/templateimpactanalysis.pdf

À votre santé