GitLab

Resumen

Duración Estimada: 106 horas

Horas Completadas: 90 horas

PBIs Completados

• #2 (closed) - PBI-02 - Creación y asignación de solicitudes a expedientes
• #8 (closed) - PBI-08 - Generador de informes

Reunión con el cliente

La reunión fue satisfactoria para ambas partes sin introducir grandes cambios en la parte de Activaciones mas allá de la modificación en la denominación de los estados intermedios del proceso. También se llego a la conclusión de que lo mejor era que la aplicación gestione las transiciones entre estados de forma automática al realizar las acciones correspondientes del proceso.

En cuanto a plazas se le enseñó un adelanto al cliente del módulo de gestión de titulaciones que fué pedido por el mismo. Obteniendo un feedback positivo del mismo con leves correcciones a nivel de interfaz.

Conclusiones

PBIs pendientes en el módulo de activaciones

Durante la reunión con el cliente, se plantea la necesidad de que la SECRES pueda cargar todas las activaciones que tienen ya registradas en la hoja de cálculo que utilizan para poder empezar a utilizar la aplicación Deméter en cualquier momento del año sin necesidad de tener empezar al comienzo de un año natural. Esto provoca que aún no se pueda cerrar el PBI-03.

Además, se comenta que el dato de la Subdelegación de Defensa de los reservistas obtenido desde SIPERDEF no es fidedigno en todos los casos, por lo que se establece que el dato sea cargado por la UCO solicitante a la hora de realizar la solicitud. Esto impide cerrar el PBI-01.

Durante la reunión se decide no implementar los siguientes PBIs debido a las siguientes causas:

• #5 - PBI-05 - Adjuntar documentación

Cumplimentar este PBI queda fuera del alcance del proyecto ya que se necesitaría disponer de un gestor documental con suficiente almacenamiento para administrar toda la documentación. Esto supondría un gran esfuerzo nada proporcional a lo que acerca el desarrollo hacia el objetivo del negocio, ya que tal y como se especifica en el Impact Map, el principal problema que se encuentra la SECRES debido al cual no pueden gestionar las solicitudes de activación en menos tiempo es porque los datos de las solicitudes no introducen correctamente por parte de las UCOs solicitantes.

• #6 (closed) - PBI-06 - Enviar emails al POC según se modifique el estado de una solicitud

Este PBI se implementó durante el sprint 2 utilizando un servicio de correo SMTP mediante una cuenta externa de Gmail. Tras la finalización del sprint 2 y la consecuente implementación del arquetipo MEDUSA, no se podía utilizar el servicio anteriormente mencionado. El arquetipo Medusa ya cuenta con un servicio el cual envía emails mediante un correo corporativo. Para su utilización se realiza una solicitud de credenciales para que la aplicación pueda enviar emails, aunque no se garantiza que la solicitud se resuelva antes de la finalización del desarrollo.

• #10 - PBI-10 - Solicitudes de modificación y anulación

La aplicación permite realizar las modificaciones y anulaciones únicamente al rol ADMINISTRADOR. Se ha considerado que esta capacidad no debería recaer bajo ninguna circunstancia bajo un usuario con rol USUARIO para evitar inconsistencias en la aplicación. La implementación de las solicitudes de modificación o anulación a través de la aplicación podría proporcionar utilidad al producto, aunque no sería proporcional a la dificultad de su implementación, por lo que queda fuera del alcance de este proyecto.

Adaptación del Mind Map

Durante la reunión el cliente ha aclarado una serie de cuestiones relativas al módulo de plazas produciendo una adaptación del Mind Map. El concepto de Reservista ya no tiene sentido dentro de la rama de Propuesta ya que el perfil de ingreso buscado queda únicamente definido por la titulación, formación y experiencia. Además, cada propuesta cuenta con un cometido y una prioridad. El cometido es un valor plenamente informativo sobre el trabajo que va a realizar el reservista en la UCO que solicita la plaza y la prioridad es la asignada por la UCO al realizar una solicitud.