1.4.1. Clupik

Es una plataforma centrada fundamentalmente en la gestión de competiciones. Permite a los usuarios inscribirse en eventos deportivos, hacer un seguimiento de los mismos y, a nivel de administración, crear y organizar dichos torneos. Sin embargo, no está diseñada para cubrir la gestión burocrática interna del día a día de un club modesto. Carece de herramientas para la gestión de un club de atletismo (independientemente de sus dimensiones)

1.4.2. Playoff Informática

Es uno de los sistemas más potentes y consolidados. Permite la gestión de recibos y remesas bancarias con gran eficacia. El problema radica en que es una herramienta sobredimensionada ("overkill"); ofrece cientos de funcionalidades que un club modesto jamás usará, generando una curva de aprendizaje muy pronunciada para los entrenadores y padres y aumentando inecesariamente el precio del servicio al estar pagando funciones no utiles para el caso de un club pequeño de atletismo.

1.4.3. Necesidades reales no cubiertas (El hueco de Ianuarius)

Tras este análisis, se concluye que el sector adolece de una herramienta que satisfaga las siguientes demandas clave del Club Ianuarius:

• Generación automatizada de burocracia: Ninguna de las alternativas genera de forma automática el PDF oficial de inscripción requerido por la Federación combinando los datos del usuario.

• Seguimiento de sensaciones: Falta de un módulo sencillo donde el atleta pueda registrar su "feedback" post-entrenamiento en la pista.

• Accesibilidad económica: Inexistencia de un sistema de bajo mantenimiento adaptado a la realidad financiera de los clubes pequeños.

1.5.1. Viabilidad Técnica

El proyecto es viable técnicamente dado que se desarrollará utilizando tecnologías sólidas y ampliamente documentadas (React, PHP 8.2 y MySQL 8.0). Sin embargo, al tratarse de un sistema que gestionará datos personales y fichas médicas de atletas (en su gran mayoría menores de edad), la viabilidad no solo reside en la capacidad de programación, sino en garantizar el estricto cumplimiento del RGPD y la LOPDGDD.

Para garantizar esta seguridad técnica, la aplicación se alojará en servidores ubicados dentro del Espacio Económico Europeo (EEE). Las contraseñas de los usuarios se almacenarán cifradas mediante funciones de hash. Respecto a los documentos altamente sensibles (como los PDF de las inscripciones generados y los escaneos de los DNI), se implementará un sistema de control de acceso en el backend (PHP). Los archivos se guardarán en directorios privados del servidor sin acceso público directo por URL, de forma que el sistema verificará primero el rol y la sesión del usuario antes de servir la descarga del documento.

1.5.2. Viabilidad Económica (Estimación de Costes)

Aunque el proyecto se desarrolla en un ámbito académico, a continuación se presenta una estimación del presupuesto como si se tratase de un encargo profesional para el Club Atletismo Ianuarius. Adicionalmente, se han calculado los costes periodicos necesarios para mantener el sistema en producción una vez finalizado el proyecto.

2.1.1. Objetivo General

2.1.2. Objetivos Funcionales

2.3.1. Diagrama de Casos de Uso

2.3.2. Especificación de Casos de Uso

2.4.1. Requisitos Funcionales (RF)

2.4.2. Requisitos No Funcionales (RNF)

2.4.3. Requisitos de Información (IRQ)

Modelo de Comunicación y API REST

La interacción entre la interfaz de usuario y el servidor se realiza mediante una API REST (Application Programming Interface), desarrollada íntegramente en PHP. El ciclo de vida de una petición típica en la aplicación sigue estos cuatro pasos fundamentales:

• 1º. Interacción (Frontend): La aplicación interactiva construida en React captura las acciones del usuario (por ejemplo, enviar el formulario de una nueva inscripción o solicitar el listado de atletas).

• 2º. Petición Asíncrona: React utiliza la API nativa "fetch" (o la librería Axios) para enviar una petición HTTP (GET, POST, PUT o DELETE) al servidor. Al ser una SPA (Single Page Application), esto ocurre en segundo plano sin necesidad de recargar la página del navegador.

• 3º. Procesamiento (Backend): El servidor PHP recibe la petición HTTP, valida los permisos de seguridad y el rol del usuario, ejecuta la lógica de negocio correspondiente y realiza las consultas necesarias a la base de datos MySQL.

• 4º. Respuesta (JSON): PHP devuelve al cliente la información solicitada empaquetada en un objeto de formato JSON. React intercepta esta respuesta y actualiza el DOM (la pantalla) de forma reactiva para mostrar los resultados al usuario.

Seguridad en la Arquitectura

Para garantizar el cumplimiento de la normativa de protección de datos (RGPD), la arquitectura se blinda en el lado del servidor. Las rutas de la API en PHP comprueban activamente las credenciales mediante el uso de sesiones o tokens de autenticación antes de servir cualquier archivo o dato sensible (como los PDF oficiales generados o las marcas deportivas), impidiendo el acceso no autorizado mediante la manipulación de las URL en el Frontend.

3.3.1. Tabla: categorias

Catálogo maestro que define los rangos de edad (ej. Sub-16, Sub-18).

3.3.2. Tabla: pruebas

Catálogo maestro de las disciplinas generales de atletismo.

3.3.3. Tabla: pruebas_variantes

Tabla de detalle que resuelve la relación N:M entre Pruebas y Categorías, añadiendo especificaciones técnicas.

3.3.4. Tabla: usuarios

Almacena las credenciales de acceso y datos personales, perfilando al atleta.

3.3.5. Tabla: fichas_inscripcion

Almacena los documentos. Relación 1:1 con la tabla usuarios.

3.3.6. Tabla: feedback_entrenamientos

Registra las sensaciones diarias. Relación 1:N con la tabla usuarios y pruebas_variantes.

3.4.1. Paleta de Colores

Se definirá una paleta cromática basada en la identidad corporativa del Club de Atletismo Ianuarius, priorizando el contraste y la legibilidad para entornos con mucha luz (exteriores):

• - Color Principal (Identidad Club): Rojo Ianuarius (#E63946) - Se reserva para los botones de acción principal (como enviar inscripciones), enlaces destacados y elementos de marca.

• - Colores Neutros: Escala de grises (desde #F8F9FA para fondos hasta #212529 para textos principales) para estructurar el contenido sin fatigar la vista.

• - Colores de Estado: Verde (#2A9D8F) para alertas de éxito (feedback guardado, PDF generado) y Naranja (#F4A261) para advertencias o campos incompletos.

3.4.2. Tipografía

Se emplea la familia tipográfica Inter, nativa en entornos web modernos e incluida a través de Tailwind CSS. Destaca por su legibilidad en pantallas pequeñas y su aspecto limpio y profesional, ideal para la lectura densa de tablas de marcas deportivas y listados de atletas.

3.4.3. Prototipado y Experiencia de Usuario (UX)

El diseño de las vistas principales (Wireframes) se plantea utilizando la herramienta Figma, con el objetivo de estructurar visualmente la interfaz y definir los flujos de navegación de cara a la codificación final de los componentes. Esta conceptualización se centra especialmente en procesos críticos como la inscripción o la subida documental, buscando reducir la fricción cognitiva mediante formularios guiados paso a paso y asegurando que la plataforma resulte intuitiva tanto para jóvenes atletas como para sus tutores legales.

4.1.1. Desarrollo iterativo e incremental:

Permite tener versiones funcionales desde las primeras semanas, añadiendo módulos de forma progresiva.

4.1.2. Herramientas de gestión:

Se utilizará un tablero tipo Kanban (GitHub Projects) dividido en las columnas básicas: Backlog, In Progress, Testing y Done.

Fase 1: Análisis y Diseño (Semanas 1 - 4)

• Semana 1-2: Toma de requisitos, análisis de competencia y elaboración de diagramas de Casos de Uso.

• Semana 3: Diseño del modelo Entidad-Relación y creación de los esquemas relacionales (MySQL).

• Semana 4: Elaboración de wireframes y maquetado visual de la interfaz de usuario en Figma.

Fase 2: Backend y Base de Datos (Semanas 5 - 8)

• Semana 5: Configuración del entorno (XAMPP), despliegue de la BBDD e implementación de la librería FPDF/TCPDF para la futura generación de documentos.

• Semana 6: Desarrollo de la API REST (PHP 8.2) y creación de los endpoints básicos (Registro, Login) con cifrado de contraseñas.

• Semana 7: Programación de la lógica de filtros de marcas deportivas y categorías por edades en el servidor.

• Semana 8: Desarrollo del módulo de control de acceso y protección de directorios para los archivos PDF de los atletas (cumplimiento RGPD).

Fase 3: Frontend e Integración (Semanas 9 - 12)

• Semana 9: Inicialización del proyecto en React 18, configuración del enrutamiento y aplicación de Tailwind CSS.

• Semana 10: Maquetación de los paneles de control (dashboard del Entrenador y vista del Atleta).

• Semana 11: Conexión asíncrona (Fetch/Axios) entre el Frontend y la API REST para el intercambio de datos JSON.

• Semana 12: Integración del formulario dinámico de inscripciones con el generador de PDF del backend.

Fase 4: Pruebas y Despliegue (Semanas 13 - 15)

• Semana 13: Ejecución de pruebas unitarias en formularios y validación de seguridad en la subida de archivos (DNI/Fotos).

• Semana 14: Resolución de errores (testing continuo).

• Semana 15: Despliegue en el servidor de producción (hosting), redacción final de los manuales y preparación de la defensa.