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

9

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.

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

project-management documentation

— setzamora
source

1

Il me semble que quelqu'un a préparé un terme de fantaisie pour vous mettre sur la sellette et vous permettre de corriger ce bug sans aucun argument.

— Aditya P

4

Cette question et sa réponse me font plaisir de ne pas travailler dans un tel environnement. "Matrice de traçabilité bidirectionnelle"? "Formulaires d'analyse et de résolution des décisions"? Vraiment? De combien de façons différentes de ne pas faire le travail avez-vous besoin?

— Rein Henrichs

2

@Rein, tout est travail. Le travail n'est pas seulement du codage. De plus, ce n'est pas celui d'une seule personne. Dans les petites organisations où l'analyse, la conception, le codage et l'estimation sont effectués par une seule personne, c'est vraiment l'enfer, mais avec de grandes équipes spécialisées, ce n'est pas grave.

— M.Sameer

4

@AdityaGameProgrammer, @Rein Henrichs: Je ne comprends pas vos commentaires. Suggérez-vous de ne pas faire du tout de planification et de gestion? Bien sûr, il est correct de commencer à coder directement si le projet est réalisé par une seule personne, et le changement est facile à mettre en œuvre. Mais qu'en est-il des projets à grande échelle et des changements qui peuvent avoir un impact important sur les différentes parties d'un projet?

— Arseni Mourzenko

5

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.

— M.Sameer
source

1

Cela semble… burro-cratique. (Autrement dit, il semble que vous soyez dirigé par des ânes.)

— Donal Fellows

3

@Donal Fellows, Cela a été recommandé par les consultants CMMi et par les consultants en amélioration de processus d'IBM.

— M.Sameer

3

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.

— Bernard Dy
source

-1

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.

— Raghu
source

-2

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é

— Nano
source

Lecture recommandée: Votre réponse est dans un autre château: quand une réponse n'est-elle pas une réponse? "laissez-moi être clair: ce genre de réponse n'est pas une réponse . Si vous voyez cela, signalez-le. Modérateurs, si vous le voyez signalé, supprimez-le "

— gnat

En fait, je ne suis pas d'accord. Mon message EST une réponse, une réponse spécifiquement pour la puce # 3 de la question d'origine "Existe-t-il des formats / modèles connus pour ce document?". Donc, vous en avez un sur une carte Telco. Peut-être n'est pas spécifiquement conçu pour le développement de logiciels, mais il y a quelques sections intéressantes dans ce pdf qui peuvent être utilisées comme inspiration pour construire votre propre modèle d'analyse d'impact. Avant de décourager les articles analysés par votre propre opinion biaisée, il serait intéressant de savoir ce que l'utilisateur d'origine qui a posé la question pense de ma contribution. À votre santé.

— Nano

bon point - convient que cela le rend effectivement admissible comme réponse (tout en faisant la partie de la question, il répond à une demande de ressources manifestement hors sujet )

— moucher