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:

	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 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 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: Continuación del Proyecto

La continuación del proyecto después de la finalización del período de prácticas enfrenta incertidumbres relacionadas con la continuidad y el mantenimiento de la solución. Las cuestiones que podrían surgir incluyen:

• Suspensión del Proyecto: Tras el final del proyecto de prácticas, no hay garantía de que el proyecto se mantenga activo o se implemente en producción. Esto puede llevar a una paralización indefinida del desarrollo y de la puesta en marcha del sistema.

• Mantenimiento y Alojamiento: La necesidad de procedimientos administrativos establecidos para la continuidad del proyecto puede afectar la capacidad para garantizar el alojamiento en el futuro y el mantenimiento de la solución. Esto incluye posibles dificultades en la actualización, soporte técnico y gestión de la infraestructura a largo plazo.

Para mitigar este riesgo, puede dejarse el proyecto en las mejores condiciones posibles para su funcionamiento desde el entorno del MVP, de forma que pueda hacerse uso del mismo con muy poco mantenimiento y aclarando los procedimientos necesarios para poder darle continuidad a la solución.Finalmente, se considera posible que se llegue a esta situación y el impacto se considera mayor.

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