Gestión de cambios en requerimientos: proceso y control

Cambio e impacto en los requerimientos: Su objetivo es proporcionar un mecanismo riguroso para controlar los cambios

Documentación del diseño: Consiste en registrar ideas y conceptos de diseño, no sólo con el fin de posibilitar su comunicación, sino también de preservar ese conocimiento

Entrevista: Debe contener información suficiente para determinar gran utilidad en la investigación cualitativa para recabar datos

Análisis de impacto

Priorización de atención

Solicitud de corrección

Procesos de solicitud de cambio

Propuesta de cambio

Aprobación

Aspectos

1. Que los stakeholders decidan lo esencial para el sistema.

2. Planear requerimientos ordenados y óptimos para una implementación exitosa.

3. Estimar la satisfacción esperada del cliente.

4. Poder manejar requerimientos contradictorios. 5. Intentar obtener el mayor valor para el sistema al menor costo

Análisis de trazabilidad de dependencias

1. Se debe especificar porque se necesita el cambio

2. Qué hay que cambiar

3. Se debe saber quién es la persona solicita

4. La descripción del problema debe estar suficientemente detallada como para que se pueda recomendar una solución

1. Reportante: quien es el que reporta el error

2. Debe tener la fecha de reporte de cuando es.

3. Grado de importancia del proceso involucrado que tan urgente es.

4, Circunstancias que condujeron al error y la frecuencia del error deben estar detalladas

1. El Jefe del Proyecto registrará la solicitud y evaluará el grado de urgencia e importancia.

2. Se dará seguimiento de acuerdo a la realidad del proyecto en el instante de la solicitud y la disponibilidad de recursos

3. Se asigna una fecha para la evaluación de la solicitud

4. Todo el resultante se pondrá en un solo documento

Trazabilidad de los requerimientos

Cambios en los requerimientos

Proceso del análisis trazabilidad de dependencias

Tipos de cambios

Matriz de impacto

1. Ayuda a obtener el producto en el dominio de la solución lo más exacto y fiable posible a las necesidades expresadas por el cliente en el dominio del problema.

2. Está condicionada por los cambios y las validaciones.

3. Asegura el cumplimiento de los requisitos validados.

4. Puede cambiar con el tiempo y se lleva el registro de estos cambios desde su inicio hasta su consecución

1. Analizar lo que son el alcance y el tiempo, esto con el fin de identificar si la solicitud es viable realizarla sobre el mismo requerimiento o si por el contrario es mejor manejarla como un requerimiento nuevo

2. Valora la factibilidad de la solicitud realizada ya sea por un cliente interno o uno externo.

3. Analiza la modificación, el líder de implementación realiza el análisis de la solicitud para saber que tanto impacta la modificación e identificar puntualmente las modificaciones solicitadas

4. Documenta el cambio, para tener un mejor control sobre los cambios solicitados realiza una documentación clara para evitar ambigüedades en las modificaciones que se van a realizar a los requerimientos.

1.Inicia con la creación de un RFC (Request For Change o Solicitud de Cambio) por parte de una persona o grupo quien planea el cambio y lo somete a revisión técnica.

2. Presenta ante el departamento de Gestión de Cambios el cual establece una valoración y evaluación inicial, para decidir si acepta, rechaza o solicita cambios al RFC.

3. Los cambios aceptados deben ser aprobados de acuerdo a su clasificación y nivel de impacto.

4. Las acciones necesarias para remediar efectos no esperados o no deseados se ejecutan de ser necesario

1. Cambio Estándar: Cambio pre-autorizado a aplicaciones o infraestructura para el cual el riesgo es bajo, sus efectos son conocidos y están documentados.

2. Tipo de Cambio Normal: Cambio que debe seguir completamente el proceso de Gestión de Cambios.

3.Tipo de Cambio Emergencia: Cambio que requiere acciones inmediatas para restaurar servicios o prevenir interrupción de los mismos.

4. Clasificación del Cambio como de Infraestructura: Cambio relacionado a algún componente de la infraestructura tecnológica de la organización.

5. Clasificación del Cambio como de Aplicaciones: Cambio relacionado a algún componente de aplicaciones tecnológicas de la organización

1. El conjunto de preguntas debe ser donde cada pregunta tiene unas posibles respuestas.

2. Cada respuesta tiene asociado un puntaje.

3.El puntaje total de las respuestas seleccionadas define el nivel de impacto de acuerdo a políticas establecidas.

4. Se pueden definir las preguntas, respuestas y puntajes de acuerdo a las políticas establecidas.

1. Por qué se necesita el cambio (el elemento no funciona tal y como debe hacerlo, le falta alguna característica, etc.)

2. Qué hay que cambiar esto en si en enfocarse en la parte central del problema

3. Quién lo solicita por ejemplo quien es el que lo pide ejemplo el jefe , cliente, etc.

4. La descripción del problema debe ser lo suficientemente detallada como para que se pueda recomendar una solución sin llegar a perder tiempo o recursos.

5. Al final están los tipos de cambios que se hicieron o como puede ayudar al proyecto en áreas relacionadas Otros cambios con los que está relacionado. Aprobación del cambio, Cómo se solucionó el problema-

1. El gerente hace la evaluación económica y valorará el impacto en el cronograma general.

2.El gerente evalúa la aplicación de un descuento parcial o total sobre la tarifa por el cambio a efectuarse, de acuerdo a la naturaleza de este.

3. Se deberá emitir una propuesta de cambio al cliente, indicando todos los pormenores al cliente y determinará en caso de existir un error.

4. No se cotizará económicamente el cambio, pero se comunicará al cliente la evaluación y el impacto del mismo, como sustento de los posibles cambios al cronograma y aplicativo.

1. El documento anterior deberá ser firmado y aceptado formalmente por el líder usuario.

2. Deberá tener : Fecha de Aprobación Funcional, Nombre del aprobador funcional, Firma del aprobador funcional

3. También contara con Fecha de aprobación técnica, Nombre del aprobador técnico, Firma del aprobador técnico

4. El jefe del proyecto procederá con el documento de propuesta de cambio, a modificar el cronograma detallado de la fase vigente y el cronograma general del proyecto, remitiendo una copia al gerente del proyecto y otra copia al Líder usuario.

Por formulario

1. En cualquier caso, debe ser simple y aceptado por las personas que lo tendrán que manejar.

2. Casi siempre se utilizan formularios diferentes para solicitar una mejora y para informar de un problema o deficiencia detectado durante una auditoría, una prueba o el uso del sistema (y que posiblemente requerirá un cambio).

3. Los que se usan para informar de problemas se les suele llamar Informes de Incidencias o Informes de Problemas.

4. Recogen información adicional sobre el incidente que ha desvelado la existencia de un problema.

Referencias Apa:

1. Kendall, K., & Kendall, J. (2011). Análisis y diseño de sistemas (8va ed.). Ciudad de México, México: Pearson educación.

2. Bennett, S., & McRobb, S., & Farmer, R. (2008). Análisis y diseño en sistemas orientados a objetos con UML (3ra ed.). Madrid, España: McGraw Hill.

3. Sánchez, S. & Sicilia, M. (2012). Ingeniería del software. Un enfoque desde la guía SWEBOK. Ciudad de México, México: Alfaomega.

4. Metodología Gestión de Requerimientos. (s. f.). Metodología Gestión de Requerimientos. Recuperado 16 de julio de 2021, de https://sites.google.com/site/metodologiareq/