Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GIO - Gestor de Información Otorrinológica GIO - Gestor de Información Otorrinológica
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1
    • Issues 1
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • 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
  • DSanchez
  • GIO - Gestor de Información OtorrinológicaGIO - Gestor de Información Otorrinológica
  • Wiki
    • 4.sprint_2
  • Sprint 2 Sprint Planning

Sprint 2 Sprint Planning · Changes

Page history
Update Sprint 2 Sprint Planning authored Jun 16, 2025 by ddcDIM47's avatar ddcDIM47
Hide whitespace changes
Inline Side-by-side
Showing with 7 additions and 0 deletions
+7 -0
  • 4.Sprint_2/Sprint-2-Sprint-Planning.md 4.Sprint_2/Sprint-2-Sprint-Planning.md +7 -0
  • No files found.
4.Sprint_2/Sprint-2-Sprint-Planning.md
View page @ 2c50a637
......@@ -18,7 +18,14 @@ Para cumplir con el objetivo se seleccionan los siguientes PBI:
| Operación de Login | Para poder dar acceso a los usuarios registrados, es necesario permitir el login, de forma que se identifique al usuario y se compruebe si está autorizado o no a realizar las operaciones solicitadas. | Permite el correcto control del acceso al API. | Si un usuario está registrado permite la ejecución de las operaciones. Si un usuario no está registrado no permite la ejecución de las operaciones. | #32 #33 | 5h |
| Introducir la autenticación en las llamadas al API | Para que la aplicación funcione de forma correcta es necesario introducir los elementos necesario en las llamadas para permitir el login de un usuario registrado y la obtención de los datos | Permite el correcto control del acceso al API. | Si un usuario está registrado permite autenticarse. Si un usuario no está registrado no permite autenticarse. Un usuario autenticado puede hacer uso de las funciones de la aplicación | #34 | 2h |
| Creación de menú de autenticación | Se crea un componente de autenticación que permita al usuario entrar en la aplicación para hacer uso de sus funciones | Contribuye al uso y obtención de datos autorizado. | Si un usuario está registrado permite autenticarse en la aplicación. Si un usuario no está registrado no permite autenticarse en la aplicación. | #34 #36 | 7h |
| CRUD de informes en el API | El sistema debe permitir almacenar los informes asignados a cada paciente, de forma que sea posible recuperar e incluso modificar dicho informe por el medico que esté haciendo uso de la aplicación. | Persistencia del texto generado en una consulta | Se permite la creación del informe Se permite modificar un informe Se permite recuperar un informe Se permite eliminar un informe | Debe existir un paciente para asignar el informe | 1h |
| Generación de PDF de un Informe | | | | #38 | 6h |
| Visualización de los informes de cada paciente | Una vez que ya se persisten los informes para los pacientes es necesario poder consultar estos informes. Para ello es necesario que cada vez que se seleccione un paciente se visualicen todos los informes asociados al mismo. | Permitir mostrar informes pasados de forma que permita al medico consultar patologias pasadas. | Al seleccionar un paciente se muestran todos los informes asociados al mismo. | #38 #45 | 8h |
| Creación de plantilla para el fichero pdf | Para que los informes sigan una misma estructura se crea una plantilla conforme a un formato facilitado por el cliente. | El informe generado se adapta al formato utilizado por el cliente. Si el cliente decide cambiar dicho formato solo es necesario cambiar la plantilla. | El informe generado se adapta al formato facilitado por el cliente. | #39 | 8h |
| Creación de un informe para un paciente | La aplicación debe permitir seleccionar un paciente y asociar el informe con el mismo si, desde la pantalla de texto, se quiere guardar este texto. | Almacenar el informe generado para un paciente, de forma que permita en el futuro recuperarlo y/o modificarlo. | Se permite seleccionar un paciente para crear el informe Se crea el texto a guardar para el paciente. Con el texto genereado se pulsa guardar y se guarda el texto El texto se guarda de forma correcta y se recupera por PostMan | #38 | 5h |
| Modificación de un informe de un paciente | El sistema debe permitir al usuario modificar el contenido de un informe de forma que el usuario pueda modificar informes recuperados con el fin de poder corregir errores y modificar conclusiones. | Permite al usuario modificar informes lo que permite realizar correcciones y/o modificaciones de evaluaciones y diagnósticos. | El usuario recupera un informe Se permite modificar el texto en el informe recuperado. Se persisten las modificaciones realizadas. Si se esta modificando el informe no se permite imprimirlo para evitar inconsistencias. Una vez confirmados los cambios, si el usuario realiza la acción, se imprime el nuevo informe. | #38 #45 | 8h |
# Cumplimiento del Objetivo
* El usuario debe poder crear, consultar, y modificar informes
......
Clone repository

GIO

  1. Especificación y formulación del problema
    1.1 Introducción
    1.2 Definición del problema
    1.3 Descripción del proceso actual
    1.4 Actores

  2. Estudio de viabilidad del sistema
    2.1 Mind Map
    2.2 Impact Map
    2.3 Estudio de Alternativas
    2.4 Decisión

  3. Propuesta de desarrollo
    3.1 Interfaz de usuario
    3.2 Product Backlog
    3.3 Producto Mínimo Viable

  4. Sprint 1
    4.1 Sprint Planning
    4.2 Sprint Review
    4.3 Sprint Retrospective
    4.2 Burndown

  5. Sprint 2
    4.1 Sprint Planning
    4.2 Sprint Review
    4.3 Sprint Retrospective
    4.2 Burndown