13. Ventajas de contar con un Protocolo

• Prevenir cambios no autorizados.

• Guardar revisiones de los documentos de requerimientos.

• Recuperar versiones previas de los documentos.

• Prevenir la modificación simultánea a los requerimientos.

• Mayor precisión en determinación de esfuerzos, plazos y costos.

• Mejor capacidad de planificación de los proyectos.

• Mayor visibilidad de riesgos asociados al desarrollo.

• Preservar los intereses de ambas partes (Cliente y DocIRS).

• Buenas prácticas de la actividad de gestión de requerimientos.

• Definir un proceso de control de cambios.

• Establecer un grupo (o comité) de control de cambios.

• Realizar análisis del impacto sobre los cambios.

• Crear líneas base y controlar las versiones de los requerimientos.

• Mantener la historia de los cambios.

• Seguir el estado de los requerimientos.

• Medir la volatilidad de los requerimientos.

• Usar herramientas de gestión de requerimientos.

• Crear matrices de trazabilidad de los requerimientos.

• El proyecto puede responder frente a petición de nuevos requerimientos o petición de cambios en los requerimientos de diferentes maneras.

• Diferir los requerimientos de baja prioridad.

• Obtener recursos adicionales.

• Ordenar y realizar más horas de trabajo (preferiblemente durante un periodo corto de tiempo y pagado).

• Ajustar el calendario para acomodarse a la nueva funcionalidad.

• Ninguna aproximación es universalmente correcta porque cada uno de los proyectos es diferente (características, presupuesto, calendario, recursos y calidad).

• Independientemente a cómo se responda a los cambios de los requerimientos, lo que realmente importa es ajustar las expectativas y los compromisos cuando sea necesario.

• Las gestión de requerimientos tiene como salidas los cambios aprobados y no aprobados, informes acerca del estado del proceso, de actividades o requerimientos, resultados de análisis de matrices y otros.

14. Desventajas de no contar con un Protocolo

Cuando la gestión de los requerimientos no se hace con un protocolo definido, de inmediato aparecen síntomas, tales como:

• Altos niveles de trabajo adicional a lo largo del proyecto.

• Obligar al personal de programación a aceptar requerimientos bajo el paradigma “si los solicitado no se realiza el sistema no sirve”. • Se incrementa en forma desmesurada y desordenada las peticiones de requerimientos.

• No se cuenta con herramientas para verificar que el producto cumple los requerimientos aprobados.

• Hay altas probabilidades de entregar un producto incompleto o incorrecto.

• Volver a revisar cambios en los requerimientos, una y otra vez, generando derroche de recursos muy visibles para el cliente. • Retrasar el calendario para acomodarse a la nueva funcionalidad.

• Permitir reducir el nivel de calidad bajo la presión de mantener la fecha original (frecuentemente esta es la reacción por defecto).