¿Cuáles son las cosas que pones en un documento de análisis de impacto?

9

Entonces está solucionando errores, luego encontró uno que podría afectar a otros módulos del producto de software. Sus datos no son suficientes para respaldar su reclamo sobre los efectos de la corrección y se le pidió que creara un documento de análisis de impacto.

¿Hay un proceso definido sobre cómo hacer esto?
¿Cuál es la información clave necesaria?
¿Hay algún formato / plantilla conocido para este documento?

project-management documentation

— Setzamora
fuente

1

Me parece que alguien inventó un término sofisticado para ponerlo en el lugar y hacer que arregle ese error sin ningún argumento.

— Aditya P

44

Esta pregunta y su respuesta me hacen feliz de no trabajar en un entorno así. ¿"Matriz de trazabilidad bidireccional"? ¿"Formas de análisis y resolución de decisiones"? De Verdad? ¿Cuántas formas diferentes de no hacer el trabajo necesita?

— Rein Henrichs el

2

@Rein, todo es trabajo. El trabajo no es solo codificación. Además, no es de una persona. En organizaciones pequeñas donde el Análisis, Diseño, Codificación, Estimación es realizado por una persona, es realmente un infierno, pero con grandes equipos con especialización no es gran cosa.

— M.Sameer

44

@AdityaGameProgrammer, @Rein Henrichs: No entiendo tus comentarios. ¿Sugiere no hacer planificación y gestión en absoluto? Por supuesto, está bien comenzar a codificar directamente si el proyecto lo realiza una sola persona, y el cambio es fácil de implementar. Pero, ¿qué pasa con los proyectos a gran escala y los cambios que pueden tener un gran impacto en las diferentes partes de un proyecto?

— Arseni Mourzenko

5

Las plantillas que he visto para el análisis de impacto se hicieron dentro de la empresa para la que trabajo. Lo usamos para evaluar las solicitudes de cambio y antes de trabajar en ellas (y posiblemente para rechazar algunas). Tenía secciones como esta:

Impacto en los requisitos: en esta sección, el analista escribe lo que debe modificarse en los casos de uso para respaldar el cambio solicitado.
Impacto en el diseño y la arquitectura: en esta sección, el arquitecto y el diseñador mencionan qué partes del modelo deben modificarse o rehacerse para respaldar el cambio.
Impacto en la prueba: el control de calidad escribe que los casos de prueba deben actualizarse.
Estimación e impacto en el cronograma: el gerente del proyecto estima el esfuerzo necesario y el costo del cambio y el impacto en el cronograma del proyecto.

Para cubrir todos los posibles impactos, debe recorrer las dependencias. Si tiene una matriz de trazabilidad bidireccional, será más fácil.

Usamos el orden anterior porque el diseñador necesitará conocer el impacto desde el punto de vista del analista para obtener una mejor comprensión del cambio y también el probador necesita conocer la opinión del analista y el arquitecto. Del mismo modo, el primer ministro necesita toda la información para conocer el costo y el cronograma.

Usamos esto con CR pero puedes usarlo con errores de la misma manera. Además, si necesita hacer esto para elegir entre varias soluciones de solución para resolver el error, deberá repetir el análisis de impacto para cada solución posible y consolidar todos los datos en un formulario de Análisis de Decisión y Resolución (DAR) para saber qué solución es el mejor. En el formulario DAR, debe agregar algunos factores de evaluación, como la mantenibilidad futura u otros factores que no se incluyen implícitamente en el análisis de impacto. Luego asigne peso a cada factor y asigne a cada solución el puntaje de cada factor. Finalmente multiplique y sume puntaje * peso y elija el mejor. Tenga en cuenta que el costo puede estar incluido en los factores o el PM puede tener otra opinión.

— M.Sameer
fuente

1

Eso suena ... burrocrático. (Es decir, parece que te están manejando burros)

— Donal Fellows

3

@Donal Fellows, Eso fue recomendado por los consultores de CMMi y por los consultores de mejora de procesos de IBM.

— M.Sameer

3

Creo con cualquier documentación que el enfoque ágil es bueno. Ahora, hay algunos conceptos erróneos que ágil significa "no hay documentación o análisis en absoluto", pero ese no es el caso. Las cosas que he leído sobre ágil dicen: "usa lo que funciona". Supongo que significa que el documento debe ser extenso y detallado en proporción a la tarea.

Las plantillas pueden ser útiles como una lista de verificación, pero no requeriría que se completen todas las secciones para cambios pequeños o de bajo riesgo. Para un cambio de una línea, tal vez no necesite un documento en absoluto. Nunca he usado una plantilla para un documento de análisis de impacto, pero regularmente trato con requisitos comerciales o especificaciones técnicas. Una plantilla puede ser demasiado restrictiva; una buena pauta es considerar quién será la audiencia Si se trata de gerentes que no son técnicos, concéntrese en la justificación comercial del cambio. Si se trata de personas técnicas, proporcione un poco de información para que una nueva persona en el equipo no se pierda y bríndeles lo suficiente para ponerse en marcha si tienen que apoyar el cambio. Además, si quieres algo aún más liviano y sin fricción, no uses un documento, ponlo en un wiki.

Información a incluir:

Breve descripción del problema
Explicar o mostrar un ejemplo de cómo el defecto está causando falla y / o ineficiencia
Incluir estimación de complejidad
Incluya una estimación del costo y el tiempo de reparación

Eso es un mínimo decente. La otra publicación destacó algunas cosas bastante pesadas de CMMi de IBM; eso es genial si tienes el tiempo y los recursos para ello (y cuando estás construyendo sistemas para la NASA donde la vida humana está en juego, entonces es mejor que la gente se lo tome en serio), pero para equipos pequeños probablemente no necesites ser tan pesado . Tenga cuidado con la estimación, como siempre. Los gerentes tienden a suponer que una estimación es la real.

Tenga en cuenta que hay peligros en el enfoque ágil. Algunos desarrolladores piensan que significa "no se necesitan documentos, simplemente comience a hackear" (lo cual podría estar bien en algunas situaciones). Además, otros tomarán la libertad dada la tarea y simplemente escribirán documentos realmente malos que realmente no ayudan (no necesariamente en la mayoría de las situaciones). Parte del problema es que escribir bien requiere algo de esfuerzo, habilidad y tiempo; la mayoría de nosotros nos faltan al menos dos de esas cosas;)

Siempre me ha gustado la documentación porque demuestra que al menos has pensado lo suficiente como para tener un plan. Pero en mi vejez también he llegado a apreciar que demasiada documentación puede convertirse en una molestia de mantenimiento, y que no hay suficientes personas que se preocupen lo suficiente como para mantener la documentación actualizada.

— Bernard Dy
fuente

-1

El documento de análisis de impacto es realmente necesario en proyectos a gran escala, especialmente donde los programadores trabajan geográficamente en diferentes ubicaciones.

El líder debe aprobar el documento de Análisis de Impacto para asegurarse de que el cambio no afecte al otro componente que funciona bien en la producción.

Se requiere un análisis de impacto para asegurarse de que se comprende completamente el requisito y se identifican todos los componentes que se van a cambiar para evitar la reelaboración

El Análisis de Impacto también se requiere para la rendición de cuentas de los interesados del cliente. De lo contrario, cuando ocurre un problema después de la implementación, el desarrollador se convierte en el chivo expiatorio.

El análisis de impacto es la base para la estimación. Sin eso, la estimación no tiene ningún soporte. Puede ser demasiado alto o demasiado bajo. Con el Análisis de Impacto, si el esfuerzo real excede, también es fácil de explicar.

— Raghu
fuente

-2

Aquí tiene una plantilla normalizada para un informe de análisis de impacto. Está personalizado para una rama específica de la industria, pero tiene secciones útiles que pueden servir de inspiración para escribir su propio documento.

El enlace: http://www.itu.int/en/itu-d/projects/documents/templateimpactanalysis.pdf

Salud

— Nano
fuente

Lectura recomendada: Tu respuesta está en otro castillo: ¿cuándo es una respuesta no una respuesta? "déjenme ser claro: este tipo de respuesta no es una respuesta . Si ve esto, márquelo. Moderadores, si lo ve marcado, elimínelo "

— mosquito

En realidad no estoy de acuerdo. Mi publicación ES una respuesta, una respuesta específica para la viñeta n. ° 3 de la pregunta original "¿Hay algún formato / plantilla conocido para este documento?". Entonces ahí tienes uno de la junta de Telco. Tal vez no está específicamente diseñado para el desarrollo de software, pero hay algunas secciones interesantes en ese pdf que pueden usarse como inspiración para crear su propia plantilla de Análisis de Impacto. Antes de desalentar las publicaciones analizadas por su propia opinión parcial, sería interesante saber qué piensa el usuario original que publicó la pregunta sobre mi opinión. Salud.

— Nano

buen punto - de acuerdo en que este hecho hace que sea formalmente califica como una respuesta (al tiempo que la parte de la pregunta se dirige a una petición de recursos manifiestamente fuera de tema )

— mosquito