|
|
|
Analizadas una solución comercial y una solución de open source, como tercera alternativa se propone una solución propia.
|
|
|
|
|
|
|
|
[Centauri](https://git.institutomilitar.com/imunnic/centauri) es una aplicación diseñada para facilitar la planificación del entrenamiento deportivo y la ejecución del mismo, de forma que los usuarios puedan mejorar físicamente gracias a una organización mucho más eficiente del entrenamiento, que permita la supercompensación para alcanzar los objetivos previstos por los encargados de los grupos y por los deportistas.
|
|
|
|
|
|
|
|
### Arquitectura
|
|
|
|
|
|
|
|
La arquitectura de la web app se basa en una estructura moderna y eficiente que utiliza Spring Boot para el desarrollo del backend, MongoDB como base de datos NoSQL, y Vue.js como marco para el frontend. En esta arquitectura, Spring Boot actúa como el núcleo del servidor, proporcionando una API RESTful<sup>10</sup> robusta y escalable para manejar las solicitudes y respuestas entre el cliente y el servidor. La elección de MongoDB permite una gestión flexible y eficiente de los datos de los entrenamientos, evitando una sobrecarga en el almacenamiento y en las consultas necesarias que con una base de datos relacional no sería posible. El frontend, desarrollado con Vue.js, ofrece una interfaz de usuario dinámica y reactiva, asegurando una experiencia fluida y responsiva para el usuario final. Esta combinación de tecnologías permite una integración eficaz entre los componentes del sistema, facilitando el desarrollo y mantenimiento de la aplicación web, al mismo tiempo que proporciona un rendimiento sólido y una alta disponibilidad.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Estimación
|
|
|
|
|
|
|
|
#### Tiempo
|
|
|
|
|
|
|
|
De la misma forma que con la solución [MixPost](../2.EVS/2.4.1.2-MixPost.md), se ha considerado oportuno realizar las estimaciones correspondientes en base a los *puntos historia* [previamente](../2.EVS/2.3-Historias-de-usuario.md) descritos. Por ello, el total de *puntos historia* que son necesarios para el desarrollo completo de **Centauri** son un total de 74, o lo que es lo mismo, 74 días laborables.
|
|
|
|
|
|
|
|
Es necesario recordar que estas estimaciones *[...]son predicciones de coste y esfuerzo, proyecciones del pasado al futuro*<sup>11</sup>, por lo que el acierto de las mismas queda sujeto a la experiencia en el pasado y como se ajuste el modelo que se usa de proyección hacia el futuro.
|
|
|
|
|
|
|
|
#### Costes
|
|
|
|
- **Desarrollo**:
|
|
|
|
Bajo las misas suposiciones que en la solución [anterior](../2.EVS/2.4.1.2-MixPost.md),se deducía que el coste por hora sería de **15,66 €** y por lo tanto, por *punto historia* o jornada laboral sería de **125,33 €**.
|
|
|
|
|
|
|
|
Por tanto, el coste total del desarrollo sería de **9274,66 €** por miembro del equipo. En este caso se considera oportuno que el desarrollo se ejecute siguiendo una metodología ágil, dentro de un marco Scrum, en el que participarán dos personas, por lo que el coste será de **18549,33 €**.
|
|
|
|
|
|
|
|
- **Alojamiento**:
|
|
|
|
Dadas las mismas condiciones y necesidades que en la solución [anterior](../2.EVS/2.4.1.2-MixPost.md), se estima que el coste de dicho apartado es de:
|
|
|
|
|
|
|
|
| | Alojamiento | Direccionamiento | Total |
|
|
|
|
|--------------|-------------|------------------|-------|
|
|
|
|
| **Primer año** | 144 € | 1 € | 145 € |
|
|
|
|
| **Segundo año** | 168 € | 1 € | 169 € |
|
|
|
|
|
|
|
|
- **Mantenimiento**:
|
|
|
|
En diferencia con los otros apartados, dado que esta solución no dispondría del soporte comunitario que la [anterior](../2.EVS/2.4.1.2-MixPost.md) posee, se estima que el mantenimiento necesario sean 4 horas mensuales por lo que en las mismas condiciones se proyecta que el precio anual del mantenimiento ascenderá a **752 €**.
|
|
|
|
|
|
|
|
| Concepto | Primer Año (€) | Años Posteriores (€) |
|
|
|
|
|----------------|----------------|----------------------|
|
|
|
|
| **Desarrollo** | 18.549,33 | 0 |
|
|
|
|
| **Alojamiento**| 145,00 | 169,00 |
|
|
|
|
| **Mantenimiento** | 752,00 | 752,00 |
|
|
|
|
| **Total** | 19.446,33 | 921,00 |
|
|
|
|
|
|
|
|
|
|
|
|
### Funcionalidades
|
|
|
|
De la misma forma que la [anterior](../2.EVS/2.4.1.2-MixPost.md) solución, se considera que **Centauri** cumpliría con todos los criterios de aceptación de las distintas [historias de usuario](../2.EVS/2.3-Historias-de-usuario.md) previstas, por lo que se alcanzarían todos los impactos requeridos para alcanzar el objetivo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Riesgos
|
|
|
|
|
|
|
|
**R1: Ciberataques**: al ser una plataforma del Ministerio de Defensa y estar expuesta en internet es susceptible de ser objetivo de ciberataques. Si bien es cierto que la información que recoje la solución no es crítica para la institución de forma global, si podría serlo para los usuarios de forma particular. Los posibles impactos incluyen:
|
|
|
|
|
|
|
|
- **Pérdida de Datos y Compromiso de la Información**: Los ataques pueden resultar en la pérdida o filtración de datos personales, comprometiendo la privacidad y la integridad de la información gestionada por la plataforma.
|
|
|
|
|
|
|
|
- **Interrupción de Servicios**: Un ataque exitoso puede causar interrupciones en los servicios que la plataforma proporciona, afectando a las actividades previstas durante la interrupción.
|
|
|
|
|
|
|
|
Para mitigar este riesgo es fundamental proteger o anonimizar la información de los usuarios de la aplicación, de forma que la información que se pueda obtener de la misma no tenga una mayor repercusión.
|
|
|
|
|
|
|
|
Si bien es cierto que el hecho de que una herramienta del Ministerio de Defensa que se encuentra desplegada en internet es **probable**, el impacto que podría llegar a tener, dada la limitación de la información que la solución trata y los servicios que ofrece es **menor**.
|
|
|
|
|
|
|
|
**R2: Capacidad de escalado**
|
|
|
|
La solución puede verse limitada por la infraestructura del servidor en el que se aloje. En un entorno con alta demanda o crecimiento de usuarios, los problemas que podrían surgir incluyen:
|
|
|
|
|
|
|
|
- **Rendimiento Reducido**: Si el servidor no está adecuadamente dimensionado, el rendimiento de la aplicación puede degradarse, resultando en tiempos de respuesta lentos o caídas del sistema.
|
|
|
|
|
|
|
|
- **Cuellos de Botella**: La infraestructura puede enfrentar cuellos de botella, como limitaciones de memoria o ancho de banda, que afectan la capacidad de manejar múltiples usuarios o transacciones simultáneamente.
|
|
|
|
|
|
|
|
Para mitigar este riesgo, es esencial planificar y realizar ajustes proactivos en la infraestructura, incluyendo la posibilidad de escalar recursos del servidor según las necesidades crecientes, por ejemplo en las horas de mayor actividad que posiblemente ocurran entre las 07.30-09.00 que es la hora en la que la mayor parte de la Fuerza realiza sus actividades físicas.
|
|
|
|
|
|
|
|
Conociendo los tiempos previstos en los que la solución puede tener una mayor afluencia de usuarios, si bien se considera **posible** que exista alguna necesidad de escalado, el impacto se considera **menor** puesto que la paralización del servicio sería muy limitada y resoluble.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Licenciamiento
|
|
|
|
|
|
|
|
Para esta solución el desarrollado será específico, siendo la titularidad del mismo del cliente. Sin embargo, se contempla el uso de código genérico de terceras partes, como el uso de distintas librerías para la construcción final del código. Los frameworks que se estima se usarán en este proyecto y las librerías asociadas serán:
|
|
|
|
|
|
|
|
- Spring Data REST
|
|
|
|
- Spring MongoDB
|
|
|
|
- Spring Security
|
|
|
|
- Vue.js
|
|
|
|
- Vuetify |
|
|
\ No newline at end of file |
