GitLab

Analizadas una solución comercial y una solución de open source, como tercera alternativa se propone una solución propia.

Centauri

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¹⁰ 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, se ha considerado oportuno realizar las estimaciones correspondientes en base a los puntos historia previamente 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¹¹, 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,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, se estima que el coste de dicho apartado es de:

• Mantenimiento: En diferencia con los otros apartados, dado que esta solución no dispondría del soporte comunitario que la anterior 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 €.

Funcionalidades

De la misma forma que la anterior solución, se considera que Centauri cumpliría con todos los criterios de aceptación de las distintas historias de usuario 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.

R3: Integración con DICODEF Aunque la aplicación puede tener su propio servicio de autenticación, lo más apropiado para no exponer datos de los usuarios en internet y facilitar así la anonimización, sería el uso de la autenticación del Ministerio de Defensa, tal como se hace para otros servicios como el CVCDEF, sin embargo, pueden que esta integración no pueda suceder por distintos motivos:

• La arquitectura de la aplicación impide al autenticación con DICODEF: Tal como está previsto el diseño de la aplicación puede que no sea capaz de integrarse con DICODEF y que sea necesario reestructurar el diseño de autenticación en la solución.

• CESTIC no permite usar la autenticación para Centauri: Puede que por motivos que se desconocen, CESTIC no permita la autenticación con DICODEF a la aplicación, por lo que la anonimización de los datos y el registro recaería en los usuarios.

El riesgo puede mitigarse adaptando la autenticación de la forma más adecuada para que sea compatible con DICODEF.

Dado que para anonimizar los datos siempre existiría posibilidad, de forma que no se conozcan las identidades del personal que utilice la aplicación, el impacto se considera insignificante, aunque la probabilidad de ocurrencia se considera posible.

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