Resultados Evaluación - Área de Proceso REQM

Resultados Evaluación - Área de Proceso REQM

SG1 Gestionar los requisitos

SP 1.1 Comprender los requisitos. Desarrollar una comprensión del significado de los requisitos con los proveedores de los requisitos

1. Identificación de proveedores de requerimientos

• Existe claridad sobre los proveedores de requerimientos aunque no para todos los grupos. No se encuentra documentado.

• Debería existir una lista de los responsables  que proveen requerimientos

1. Criterios para evaluación y aceptación de requerimientos

• Existen criterios personales de revisión de requerimientos (Juicio de expertos). Criterios de evaluación y aceptación de requerimientos no se encuentran estandarizados y documentados
• Existe una evaluación preliminar por parte del área de Procesos, se desconoce los criterios y si se encuentran documentados
• En algunos grupos el líder revisa los requerimientos con el usuario para determinar que apunten a las reglas del negocio. Se realiza durante el levantamiento del requerimiento. Cuando el requerimiento se oficializa ya tiene una revisión preliminar.
• Uno de los criterios de evaluación que tienen los líderes es el impacto en la operación.

1. Garantizar el análisis de  los criterios

• Como no existen criterios no se garantiza el análisis de los criterios

1. Requisitos aprobados

• () Los requisitos aprobados pueden ser los casos de uso
• En caso de generar dudas en la revisión del requerimiento, estos algunas de las veces no son actualizados con el fin de tener el requerimiento completo y aprobado.
• Como evidencias de resolución de dudas quedan los correos, algunos quedan en la herramienta OTRS.
• Algunos grupos (Sal) envían correo electrónico para formalizar los requerimientos finales. No se registra en el requerimiento inicial para que este quede completo.
• Algunos grupos (Afil) lo realizan en la fase de revisión del requerimiento. Cuando se presentan cambios en el requerimiento se actualiza si el cliente lo envía con los nuevos cambios.
• Algunos grupos (AyC) realizan reuniones informales y se modifica el requerimiento si es necesario. Se realiza antes de registrarlo en la Mesa de Servicios. Las dudas que surgen después de formalizarlo se registran en el Análisis de Impacto. Si se presentan dudas durante la realización de Casos de Uso, también se registran en el Análisis de Impacto. Se registran las dudas más no la resolución de estas

1. SP 1.2 Obtener el compromiso sobre los requisitos. Obtener el compromiso de los participantes del proyecto sobre los requisitos. Evaluación del impacto de los requerimientos

• Se evalúa impacto del requerimiento sobre el software existente
• Generalmente no se evalúa el impacto  teniendo en cuenta los otros requerimientos en curso o el impacto en los otros módulos.
• No se verifica el impacto teniendo en cuenta  el recurso y el tiempo
• Algunos grupos (Afi,Rec) realizan reuniones internas, sin embargo, no existe un registro. Quedan algunos registros de correos electrónicos.

1. Negociación y registro de los compromisos 

• Algunos grupos (AyC) realizan priorización de requerimientos y se comunica a través del correo con un formato en Excel donde aparecen las fechas de cumplimiento de cada etapa del desarrollo. Se realiza una reunión mensual de requerimientos con el usuario. Realizan el registro localmente y envían al Director de Desarrollo.
• No se realizan planes de mitigación del impacto de no cumplir con los compromisos de entrega
• Algunos grupos (CuentasM) programan el recurso a medida que avanzan las actividades
•  Los compromisos se socializan verbalmente al interior del grupo. No existe un registro formal de los compromisos. No se comunica al cliente oficialmente. Existe un archivo de Requerimientos donde se registran los compromisos (dueño Director de Desarrollo) pero no se garantiza la actualización de este.
• Algunos grupos (Pac) gestionan los nuevos compromisos a través del correo y los registran en sus programaciones locales. No se informa al cliente el incumplimiento de entregas
• En algunos grupos (Salud) se reciben muchos cambios a las prioridades y no se realiza ningún tipo de gestión, sólo se detiene lo que esté en curos y se inicia la nueva solicitud.
• Algunos grupos (Portal) informan los cambios en cronograma al Director de Desarrollo, quien se encarga de informar los cambios.
• ()Compromisos de los clientes. Ejemplo: Aceptar Casos de Uso a tiempo.

SP 1.3 Gestionar los cambios a los requisitos. Gestionar los cambios a los requisitos a medida que evolucionan durante el proyecto

1. Documentar los requerimientos y los cambios.

• Se documenta en el formato de Alcance de Requerimiento y se guarda en el repositorio, en este se encuentra registrado el requerimiento inicial.
• No siempre, para los cambios, se registran alcances a los requerimientos
• No es claro quién es el responsable de rechazar o aprobar el cambio. Calidad y Procesos aprueba o rechaza cambio pero en tecnología se puede rechazar de acuerdo a los criterios del Líder
• No se tienen criterios definidos de escalado para la decisión de aprobar o rechazar
• El registro de los cambios no es totalmente organizado, debido a que nos es posible determinar la cantidad de alcances recibidos de una forma ágil y confiable
• En algunos grupos (cuentasm) los cambios identificados son solicitados por el líder directamente, y no quedan asociados al requerimiento inicial
• En algunos grupos (pac) no se aceptan control cambios si se encuentran en la fase de pruebas.
• Algunos grupos (Portal) escalan la aprobación de un cambio a la Direcciòn de Tecnología cuando impactan los costos.

1. Historial de cambios y su motivación.

• La motivación del cambio es registrada dentro del formato de alcance (campo Justificación).
• El Historial se obtiene revisando uno a uno los alcances de los requerimientos los cuales se encuentran enumerados
• No se lleva historial de las reuniones donde se analizan los posibles cambios a los requerimientos.
• ()Capacitar al usuario  en el tema de justificación en los requerimientos y alcances

1. Evaluación del impacto de los cambios de los requerimientos

• Se evalúa el impacto pero no siempre es registrado en el Análisis de Impacto, Algunos grupos modifican los tiempos y otros  modifican  cronograma.
• No siempre se informa el impacto al usuario de Famisanar
• Se evalúa el impacto del cambio en el requerimiento, pero no se evalúa contra los requerimientos en curso
• No siempre se verifica el impacto del cambio teniendo en cuenta  el recurso y el tiempo
• Algunos grupos (pac) analizan junto al cliente el impacto en los cronogramas, para que tome la decisión de aceptar o rechazar el cambio
• ()El formato Análisis de Impacto requiere que se documente mas

1. Control  y consulta rápida del estado de los requisitos

• Se tiene un documento en Excel en el repositorio que no es actualizado al día. No se tiene una consulta en línea. Para ver el estado de un requerimiento se debe buscar en la Mesa de Servicios o en Mantis.
• Algunos líderes llevan un cuadro de requerimientos que actualizan localmente.
• ()Se requiere una manera más rápida para consultar

SP 1.4 Mantener la trazabilidad bidireccional de los requisitos. Mantener la trazabilidad bidireccional entre los requisitos y los productos de trabajo

1. Trazabilidad entre los requisitos

• No se tiene definida el alcance de la trazabilidad
• Se tiene alguna relación entre los requerimientos y sus alcances, aunque no es fácil llegar a ella. 

1. Trazabilidad entre los requisitos y los productos de trabajo

• De alguna manera se puede encontrar la trazabilidad, sin embargo  es dispendiosa.
• La trazabilidad se lleva en OTRS, lo que se llevaba en Mantis desapareció

1. Matriz de trazabilidad

• No se tiene una Matriz de trazabilidad documentada, mantenida y seguida por todos los integrantes del proyecto.

SP 1.5 Asegurar el alineamiento entre el trabajo del proyecto y los requisitos. Asegurar que los planes del proyecto y los productos de trabajo permanecen alineados con los requisitos.

...