Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • demeter demeter
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 9
    • Issues 9
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Manuel de Blas
  • demeterdemeter
  • Wiki
    • 8.sprint4
  • 8.3 Sprint Review

Last edited by Manuel de Blas Pino Nov 21, 2025
Page history
This is an old version of this page. You can view the most recent version or browse the history.

8.3 Sprint Review

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

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.

Mind Map Sprint Review 4

Clone repository
  1. Especificación y formulación del problema
    1. Introducción
    2. Definición del problema
    3. Descripción del proceso actual
    4. Actores
    5. Alcance y limitaciones
    6. Analistas
  2. Estudio de Viabilidad del Sistema (EVS)
    1. Mind Map
    2. Impact Map
    3. Alternativas
      1. Sage HR
      2. OrangeHRM
      3. Deméter
      4. Matriz de decisión
  3. Especificación de Requisitos del Sistema (ERS)
    1. Planificación
    2. Historias de Usuario
    3. Product Backlog
    4. Diseño de la Interfaz de Usuario
    5. Diagramas
  4. Definición del MVP
  5. Sprint 1
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  6. Sprint 2
    1. Sprint Planning
    2. Plan de pruebas
    3. Sprint Review
    4. Sprint Retrospective
  7. Sprint 3
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  8. Sprint 4
    1. Sprint Planning
    2. Plan de pruebas
    3. Sprint Review
    4. Sprint Restrospective
  9. Sprint 5
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  10. Manual de desarrollador
    1. Guía de instalación
    2. Estructura del backend
    3. Estructura del frontend
  11. Siglas
  12. Referencias