Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • P PANACEA
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • 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
  • dgutlop
  • PANACEA
  • Wiki
  • 3.1. Planificacion

Last edited by amararr Jul 05, 2026
Page history
This is an old version of this page. You can view the most recent version or browse the history.

3.1. Planificacion

Metodología

El desarrollo de PANACEA seguirá el framework Scrum, seleccionado por su capacidad para gestionar proyectos de desarrollo software mediante un enfoque iterativo e incremental. Esta aproximación permite priorizar los requisitos funcionales, desarrollar el sistema en incrementos sucesivos y validar cada entrega antes de iniciar la siguiente.

El trabajo se organizará mediante un Product Backlog, del que se seleccionarán las funcionalidades a desarrollar en cada Sprint. Al finalizar cada iteración se revisarán los resultados obtenidos y se incorporarán las mejoras identificadas, favoreciendo la adaptación continua del producto a los requisitos del proyecto.

Arquitectura

La arquitectura de PANACEA se plantea como una aplicación web interna basada en un modelo cliente-servidor, con separación entre la capa de presentación, la capa de lógica de negocio y la capa de persistencia.

El frontend será desarrollado como una aplicación web, accesible desde navegador, encargada de proporcionar la interfaz de usuario a los distintos perfiles del sistema: UCO, SMR, NAS, BRILOG, DISAN y Administrador. Desde esta interfaz los usuarios podrán registrar actividades, consultar solicitudes, visualizar calendarios, asignar recursos y realizar el seguimiento del estado de los apoyos sanitarios conforme a sus permisos.

El backend se implementará mediante Spring Boot, exponiendo una API REST que permitirá la comunicación con el frontend. Esta API no se limitará a operaciones básicas de alta, baja, modificación y consulta, sino que reflejará las acciones propias del proceso de negocio: creación de actividades, formalización de solicitudes, asignación de recursos, elevación de solicitudes, cambio de estados y consulta de trazabilidad.

La lógica de negocio se ubicará en una capa de servicios independiente, responsable de aplicar las reglas del proceso de planificación y gestión de apoyos sanitarios. Esta capa comprobará, entre otros aspectos, los permisos del usuario, el estado de cada solicitud, la disponibilidad de recursos y la coherencia de las transiciones entre estados.

Para la persistencia de la información se empleará una base de datos relacional, al tratarse de un dominio con entidades estructuradas y fuertemente relacionadas entre sí: actividades, solicitudes, UCO, usuarios, roles, recursos sanitarios, asignaciones, estados e histórico de actuaciones. Este enfoque facilita la integridad referencial, la trazabilidad y la explotación posterior de la información.

La seguridad del sistema se apoyará en mecanismos de autenticación corporativa y control de acceso basado en roles. Cada usuario podrá acceder únicamente a las funcionalidades e información correspondientes a su perfil y ámbito de responsabilidad. Además, al tratarse del sistema oficial de planificación y formalización de apoyos sanitarios, PANACEA deberá registrar las acciones relevantes realizadas sobre cada expediente, permitiendo reconstruir su evolución desde la creación de la actividad hasta la resolución final del apoyo.

La arquitectura propuesta permite desarrollar inicialmente un Producto Mínimo Viable centrado en las funcionalidades prioritarias, manteniendo una estructura preparada para incorporar progresivamente nuevos módulos, como cuadros de mando, informes, gestión avanzada de recursos, integración con SharePoint o mecanismos adicionales de auditoría.

Calendario

El desarrollo de PANACEA se planifica siguiendo un enfoque iterativo e incremental basado en el framework Scrum. Previamente al desarrollo se han realizado las fases de estudio de viabilidad y especificación de requisitos, sobre las que se apoyará la implementación del Producto Mínimo Viable (MVP). A partir de septiembre, el desarrollo se organizará en cuatro Sprint consecutivos, al término de los cuales se dispondrá de una versión funcional del sistema para su presentación.

Queda por tanto el siguiente calendario:

Plazos Etapa
10 mayo – 09 junio Estudio de Viabilidad del Sistema (EVS)
10 junio – 05 julio Especificación de Requisitos del Software (ERS)
01 septiembre – 20 septiembre Sprint 1
21 septiembre – 10 octubre Sprint 2
11 octubre – 31 octubre Sprint 3
01 noviembre – 20 noviembre Sprint 4
03 diciembre Exposición del proyecto

Tecnologías y entornos de desarrollo/despliegue

Para el desarrollo de PANACEA se empleará un conjunto de tecnologías ampliamente utilizadas en el desarrollo de aplicaciones empresariales, seleccionadas por su madurez, estabilidad y adecuación a los requisitos funcionales del proyecto.

  • Frontend: la interfaz de usuario se desarrollará mediante Angular, utilizando HTML5, CSS3 y TypeScript para implementar una aplicación web moderna, dinámica y adaptable a los distintos perfiles de usuario del sistema.

  • Backend: la lógica de negocio se implementará en Java utilizando el framework Spring Boot, exponiendo una API REST para la comunicación con el frontend y gestionando la aplicación de las reglas de negocio.

  • Persistencia: la gestión de datos se realizará mediante una base de datos relacional, garantizando la integridad de la información y la correcta gestión de las relaciones existentes entre actividades, solicitudes, recursos, usuarios y organizaciones.

  • Seguridad: el sistema incorporará mecanismos de autenticación y autorización mediante Spring Security, permitiendo el acceso a las funcionalidades en función del perfil de cada usuario.

  • IDE de desarrollo: el desarrollo se realizará principalmente mediante IntelliJ IDEA, utilizándose también Visual Studio Code para tareas relacionadas con el desarrollo del frontend y la edición de documentación.

  • Control de versiones: se utilizará Git como sistema de control de versiones, alojando el código fuente en un repositorio GitLab, facilitando el trabajo colaborativo y el seguimiento de la evolución del proyecto.

  • Pruebas de la API: las pruebas funcionales de los servicios REST se realizarán mediante Postman, verificando el correcto funcionamiento de los distintos endpoints desarrollados.

  • Gestión del proyecto: la planificación de los Sprint, la gestión del Product Backlog y el seguimiento del desarrollo se realizará mediante las herramientas colaborativas integradas en GitLab.

  • Entorno de despliegue: durante la fase de desarrollo la aplicación se ejecutará en un entorno local. El Producto Mínimo Viable (MVP) se desplegará en un servidor de pruebas para realizar la validación funcional antes de futuras fases de evolución.

Clone repository

PANACEA

  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. Historias de usuario
    4. Estudio de Alternativas
      1. HESTIA
      2. SUMMA112
      3. PANACEA
    5. Cumplimiento de impactos
    6. Decisión
    7. Exposición EVS
  3. Especificación de Requisitos Software (ERS)
    1. Planificación
    2. Requisitos
    3. Diagramas
    4. Modelos
    5. Exposición ERS
  4. Producto Mínimo Viable
    1. Product backlog
    2. Producto Mínimo Viable
    3. Exposición MVP