| ... | @@ -2,4 +2,20 @@ |
... | @@ -2,4 +2,20 @@ |
|
|
|
|
|
|
|
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 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. |
|
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.
|
|
\ No newline at end of file |
|
|
|
|
|
### 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. |
|
|
|
\ No newline at end of file |
