|
|
|
### 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 desarrollo de PANACEA se realiza siguiendo el framework **Scrum**, seleccionado por su adecuación a un desarrollo iterativo e incremental. Este enfoque permite priorizar las funcionalidades, desarrollar el sistema en incrementos sucesivos y validar progresivamente el producto durante su construcción.
|
|
|
|
|
|
|
|
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.
|
|
|
|
El trabajo se organiza mediante un **Product Backlog**, a partir del cual se seleccionan y descomponen los elementos que deben abordarse en cada Sprint. La integración entre frontend y backend se realiza de forma progresiva, permitiendo validar las funcionalidades desarrolladas antes de continuar con los siguientes bloques del sistema.
|
|
|
|
|
|
|
|
### 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.
|
|
|
|
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 lógica de negocio y la 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 desarrollo parte del framework corporativo **MEDUSA**, tomando como base la aplicación Démeter. Sobre este entorno se implementan las funcionalidades específicas de PANACEA.
|
|
|
|
|
|
|
|
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.
|
|
|
|
El **frontend** se desarrolla mediante **Angular** y proporciona la interfaz desde la que los usuarios interactúan con el sistema de acuerdo con su contexto funcional. Desde esta interfaz se podrán consultar y gestionar recursos, planificar actividades, realizar asignaciones, tramitar solicitudes de apoyo y efectuar el seguimiento de los apoyos sanitarios.
|
|
|
|
|
|
|
|
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.
|
|
|
|
El **backend** se implementa mediante **Spring Boot**, exponiendo servicios REST para la comunicación con el frontend. Junto con las operaciones de consulta y mantenimiento de información, se implementarán las acciones propias del proceso de negocio, entre ellas la planificación de actividades, asignación de recursos, formalización de solicitudes, elevación entre escalones y resolución de los apoyos.
|
|
|
|
|
|
|
|
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 lógica de negocio se concentra en el backend, que será responsable de aplicar las reglas relativas a autorización, ámbito funcional, disponibilidad y asignabilidad de recursos, estados de actividades y solicitudes y trazabilidad de las actuaciones realizadas.
|
|
|
|
|
|
|
|
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.
|
|
|
|
Para la persistencia se empleará una **base de datos relacional MySQL**, adecuada para representar las entidades y relaciones que conforman el dominio de PANACEA, entre ellas unidades, recursos sanitarios, actividades, solicitudes, trámites y asignaciones.
|
|
|
|
|
|
|
|
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.
|
|
|
|
La autenticación y parte de la infraestructura de seguridad se apoyarán en los mecanismos proporcionados por **MEDUSA**, incorporándose sobre ellos el contexto funcional propio de PANACEA para determinar el ámbito de actuación de cada usuario.
|
|
|
|
|
|
|
|
La arquitectura contempla asimismo la integración con sistemas corporativos externos. **SIPERDEF** proporcionará los datos orgánicos y de personal que correspondan, mientras que **SIGLE** proporcionará los datos relativos a los recursos materiales que se determinen.
|
|
|
|
|
|
|
|
Esta arquitectura permite desarrollar inicialmente un **Producto Mínimo Viable**, manteniendo una estructura susceptible de evolucionar mediante la incorporación progresiva de nuevas funcionalidades e integraciones.
|
|
|
|
|
|
|
|
### 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.
|
|
|
|
El desarrollo de **PANACEA** se organiza siguiendo un enfoque iterativo e incremental. Previamente a la implementación se han realizado las fases de **Estudio de Viabilidad del Sistema (EVS)** y **Especificación de Requisitos del Software (ERS)**.
|
|
|
|
|
|
|
|
Queda por tanto el siguiente calendario:
|
|
|
|
La fase de desarrollo del MVP se estructura en **tres Sprint**, con integración progresiva entre frontend y backend y con el objetivo de disponer de una versión funcional, integrada y demostrable antes de la exposición final.
|
|
|
|
|
|
|
|
| **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|
|
|
|
|
| 10 mayo – 09 junio | Estudio de Viabilidad del Sistema (EVS) |
|
|
|
|
| 10 junio – 05 julio | Especificación de Requisitos del Software (ERS) |
|
|
|
|
| 01 octubre – 20 octubre | Sprint 1 |
|
|
|
|
| 21 octubre – 09 noviembre | Sprint 2 |
|
|
|
|
| 10 noviembre – 20 noviembre | Sprint 3 |
|
|
|
|
| 21 noviembre – 02 diciembre | Cierre, documentación, correcciones y preparación de la demostración |
|
|
|
|
| 03 diciembre | Exposición del proyecto |
|
|
|
|
|
|
|
|
### Tecnologías y entornos de desarrollo
|
|
|
|
|
|
|
|
### Tecnologías y entornos de desarrollo/despliegue
|
|
|
|
Para el desarrollo de **PANACEA** se emplean las siguientes tecnologías y herramientas:
|
|
|
|
|
|
|
|
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.
|
|
|
|
- **Framework corporativo:** MEDUSA, utilizando Démeter como aplicación base.
|
|
|
|
|
|
|
|
- **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.
|
|
|
|
- **Frontend:** **Angular**, HTML5, CSS3 y TypeScript.
|
|
|
|
|
|
|
|
- **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.
|
|
|
|
- **Backend:** **Java** y **Spring Boot**, mediante servicios REST para la comunicación con el frontend.
|
|
|
|
|
|
|
|
- **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.
|
|
|
|
- **Persistencia:** **MySQL**, mediante un modelo de datos relacional.
|
|
|
|
|
|
|
|
- **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.
|
|
|
|
- **Seguridad:** mecanismos de autenticación y autorización proporcionados por MEDUSA, complementados con el modelo de contexto funcional propio de PANACEA.
|
|
|
|
|
|
|
|
- **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.
|
|
|
|
- **Entornos de desarrollo:** **Spring Tool Suite (STS/Eclipse)** para el backend y **Visual Studio Code** para el 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.
|
|
|
|
- **Gestión de dependencias y construcción:** **Maven** para el backend y las herramientas propias del ecosistema Node.js/Angular para el frontend.
|
|
|
|
|
|
|
|
- **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.
|
|
|
|
- **Control de versiones:** **Git**, con repositorios alojados en **GitLab**.
|
|
|
|
|
|
|
|
- **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**.
|
|
|
|
- **Pruebas e integración:** pruebas de los servicios REST y validación progresiva de la integración entre frontend y backend, sustituyendo los datos simulados por servicios reales conforme estos se encuentran disponibles.
|
|
|
|
|
|
|
|
- **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.
|
|
|
|
- **Gestión del proyecto:** GitLab y la documentación asociada al proyecto para el seguimiento del Product Backlog, los Sprint y las decisiones adoptadas durante el desarrollo.
|
|
|
|
|
|
|
|
Durante la fase de desarrollo, frontend y backend se ejecutan principalmente en entornos locales, realizando la integración de forma progresiva conforme se completan los distintos bloques funcionales.
|
|
|
|
|
|
|
|
### Equipo Scrum
|
|
|
|
|
|
|
|
El equipo Scrum responsable del desarrollo de **PANACEA** estará compuesto por los siguientes integrantes:
|
|
|
|
El equipo Scrum responsable del desarrollo de **PANACEA** está compuesto por:
|
|
|
|
|
|
|
|
- **Scrum Master:** Teniente Coronel D. José Manuel Marzo Oballe.
|
|
|
|
|
| ... | ... | @@ -69,4 +77,3 @@ El equipo Scrum responsable del desarrollo de **PANACEA** estará compuesto por |
|
|
|
- **Equipo de Desarrollo:**
|
|
|
|
- Capitán D. David Gutiérrez López.
|
|
|
|
- Capitán D. Agustín Martín Arranz. |
|
|
\ No newline at end of file |
|
|
|
|
|
|
\ No newline at end of file |