Bitácora del Proyecto equipo de trabajo "SyntaxTerror"

Documentación del proyecto actualizado

Resumen vivo de lo que llevamos preparado hasta hoy: alcance, viabilidad, roles, requisitos y riesgos. Esta sección se mantiene alineada con lo que estamos entregando en GitHub (bitácora + materiales).

0) Consultas utilizadas (Firestore)

Hemos documentado las consultas reales usadas en la app (Firebase/Firestore), incluyendo filtros, lecturas, escrituras y transacciones.
🔥 Ver consultas Firestore (en la web) 🎬 Ver vídeos demostrativos 🔥 Ver consultas Firestore (en la web) ⬇️ Descargar PDF (opcional)

1) Alcance (MVP) y visión

Desarrollar una solución tecnológica completa (app de escritorio + app Android) para la gestión y reserva de espacios/recursos (salas, equipos, parkings). Empezamos por un MVP centrado en un gimnasio para después escalar si hay tiempo.

2) Tecnologías y herramientas

• GitHub: repositorio, control de versiones, trabajo colaborativo y publicación web (GitHub Pages).
• IDE: IntelliJ IDEA / Android Studio (según módulo y necesidades).
• Backend: Java (API/servicios) + JSON.
• Frontend escritorio: JavaFX.
• App móvil: Android (Kotlin).
• BBDD: Firestore (Firebase NoSQL) (modelado y consultas con DBeaver).

3) Organización del equipo (roles)

4) Requisitos (resumen)

• Usuarios: registro, login seguro, roles (admin/monitor/cliente), recuperación de contraseña.
• Reservas: consultar disponibilidad, reservar/modificar/cancelar, control de aforo.
• Clases/actividades: crear clases, horarios, monitor, plazas disponibles.
• Atómico: evitar solapamientos/duplicidades (anti-overbooking).
• No funcionales: rendimiento, disponibilidad, seguridad (RGPD), mantenibilidad (Git).

5) Riesgos (los que vigilamos)

• Complejidad del backend (reserva atómica / overbooking en tiempo real).
• Tiempo de entrega y coordinación de tareas.
• Caída/limitaciones del servidor cloud (si lo usamos).
• Seguridad y cumplimiento RGPD (datos personales + autenticación).

6) DAFO (resumen)

Fuente interna: recopilación y viabilidad técnica del proyecto (documento del equipo).

Cronograma (Gantt interactivo) interactivo

UX / Diseño centrado en el usuario (HCD)

Checklist de cómo estamos enfocando el diseño para que la app sea usable (no solo “bonita”).

• Paso 01 — Definir la utilidad
  Qué problema resuelve la app y qué necesidad real cubre (en palabras simples).
• Paso 02 — Conocer al usuario
  Personas / perfiles: objetivos, motivaciones, experiencia tecnológica, contexto.
• Paso 03 — Ideación
  Brainstorming → debate → priorización (imprescindible / importante / opcional).
• Paso 04 — Prototipos
  Wireframes y prototipos (ej. Figma) para validar flujo antes de programar.
• Paso 05 — Tests
  Pruebas con usuarios: conclusiones y mejora iterativa (ciclo continuo).

Nota: este detalle no sustituye al Gantt, lo complementa. El Gantt responde a “fases grandes”, y este bloque responde a “qué hicimos realmente cada día”.

Diseño visual: paleta, tipografías y criterios

En esta fase hemos fijado una identidad visual coherente para que tanto la web (GitHub Pages) como la app PixelGym se sientan parte del mismo proyecto. Nos centramos en consistencia (mismos acentos, mismos contrastes) y en que sea legible. Última actualización: 21/02/2026

Paleta principal (Web / SyntaxTerror)

Para la web elegimos una base oscura (azules/grises) y un accent naranja para botones y enlaces, porque encaja con el carácter del proyecto y mantiene el “look” tecnológico. Importante: evitamos dejar colores “por defecto” (como los colores por defecto de plantilla) para que todo tenga identidad propia.

Paleta secundaria (App PixelGym)

Se mantiene el naranja PXG como marca (botones, switches, highlights). Para modo claro usamos un blanco suave para no “quemar” la vista.

Tipografía

Para la app se ha añadido una fuente personalizada en res/font (ej: bebasneue_regular.ttf) y se aplica con android:fontFamily="@font/bebasneue_regular". Importante: nombres de archivo en minúsculas y con _.

Wireframes (frames) y ajustes de layout

Hemos trabajado los frames (wireframes) para asegurar que la navegación sea lógica antes de “pintar” toda la UI final. Aquí documentamos la decisión y el arreglo de distribución (alineación, tamaños y coherencia entre pantallas).

Qué se ha arreglado

• Orden y jerarquía visual: logo → marca (PXG) → formulario → acciones.
• Botones con tamaños coherentes y separación suficiente (evitar “apretar” elementos).
• Uso correcto de Toolbar / flecha atrás según si es pantalla raíz o secundaria.
• Modo claro/oscuro: mismos componentes, cambian colores (no cambia la estructura).

Base de datos (BBDD): modelo, scripts y diagrama

Decisión de Base de Datos: inicialmente estuvimos bastante tiempo investigando y trabajando con PostgreSQL, diseñando tablas y analizando cómo estructurar correctamente las relaciones para el sistema de reservas. Sin embargo, tras evaluar la integración con Android y la complejidad del mantenimiento, decidimos cambiar el enfoque y optar por una base de datos NoSQL utilizando Firebase (Cloud Firestore). Esta decisión nos permitió simplificar la estructura de datos, adaptarla mejor al modelo de usuarios y reservas y aprovechar la integración directa con el ecosistema Android.

Diseño de la base de datos para el módulo gym (usuarios, suscripciones, planes, salas, profesores, sesiones y reservas). Se adjunta el diagrama ER y scripts NoSQL.

Diagrama Entidad-Relación (ER)

Evidencias y entregables (hasta hoy)

Recopilación rápida de lo que ya está hecho y documentado para poder defender el proyecto y preparar el PDF final.

Bitácora del proyecto

Añadimos una sesión al día o evento de trabajo.

• 2025-12-23 Diseño BD
  Diseño ER y UML de la base de datos (salas, clases, horarios y reservas)
  - Se ha elaborado el Diagrama Entidad-Relación (ER) para definir entidades, atributos y relaciones.
  - Se ha construido el modelo UML para representar las clases/tablas y sus asociaciones.
  - Objetivo: dejar clara la estructura antes de pasar a Firestore (Firebase NoSQL) y asegurar integridad (claves y relaciones).
  
  Wireframe Vista Usuario:
  
  
  Diagrama UML:
  
  
  Explicación breve:
  El modelo se basa en: TipoSala → Sala → Clase, donde una sala pertenece a un tipo y en esa sala se imparten clases. Cada clase usa un horario (inicio/fin) y los usuarios pueden generar reservas asociadas a una clase. Además, el aforo/plazas máximas limitan el número de reservas permitidas por sesión.
  
  

Bitácora – Últimas 3 semanas Sprint final

En estas últimas tres semanas hemos intensificado el desarrollo hasta llegar a la entrega final del proyecto. Trabajo completamente coordinado entre los tres miembros del equipo, aprendizaje continuo y resolución de problemas reales en producción.

🗓️ Semana 1 (2 febrero – 8 febrero 2026)

• Reestructuración y mejora de consultas en Firestore.
• Corrección de errores en autenticación (LoginFragment y RegisterFragment).
• Validaciones mejoradas de usuario y control de estados.
• Ajuste de navegación y flujo completo de registro → login.

🗓️ Semana 2 (9 febrero – 15 febrero 2026)

• Problemas graves con GitHub: superposición de versiones y conflictos de merge.
• Recuperación del proyecto restaurando versiones anteriores y reorganizando ramas.
• Establecimos una mejor coordinación para evitar conflictos futuros.
• Trabajo conjunto casi permanente entre los tres para estabilizar el proyecto.

🗓️ Semana 3 (16 febrero – 22 febrero 2026)

• Implementación del sistema de reservas por día y hora.
• Control de aforo dinámico según capacidad de cada sala.
• Desarrollo del sistema de tickets para reservas.
• Implementación del Fragment Perfil para visualizar tickets restantes.
• Operaciones completas: seleccionar día → seleccionar hora → validar aforo → reservar.
• Ajustes finales de interfaz y experiencia de usuario.

📌 Domingo 23 febrero 2026 – Entrega Final

Entrega del proyecto como Producto Mínimo Viable (MVP) completamente funcional. Realizamos una demo totalmente operativa mostrando:
• Registro y login funcional.
• Sistema de tickets activo.
• Reservas por día y hora con control real de aforo.
• Perfil de usuario con visualización de tickets restantes.
• Confirmación correcta de reservas.

Durante todo el proceso trabajamos los tres prácticamente siempre juntos, coordinándonos en tiempo real, resolviendo errores y aprendiendo de cada problema técnico. Este sprint final nos permitió consolidar conocimientos en Firebase, Git, arquitectura de fragmentos y trabajo en equipo.

Roadmap del proyecto

Notas rápidas

• [Idea] Mejorar el diseño de la interfaz
  Probar una paleta más clara y añadir iconos pequeños para las acciones principales.
• [Duda] Integración con base de datos
  Hemos configurado la base de datos en Firestore (Firebase NoSQL) y la gestionamos mediante DBeaver. Hoy hemos creado el esquema inicial, conectado el cliente NoSQL y comenzado a definir tablas y relaciones.
• [Recordatorio] Revisar rúbrica del profesor
  Comprobar que la entrega cumple todos los puntos de RA y criterios de evaluación.

Quiénes somos

Somos el equipo SyntaxTerror, responsables del desarrollo del proyecto intermodular de 2º DAM. Nuestro objetivo es aplicar las competencias del ciclo para crear una solución útil, organizada y bien documentada.

• Pedro Torres
  Desarrollador · Coordinación técnica · Gestión del proyecto · Control de versiones · Documentación
• Manuel Sánchez
  Desarrollador · Coordinación técnica · Gestión del proyecto · Control de versiones · Documentación
• Adrián Romera
  Desarrollador · Coordinación técnica · Gestión del proyecto · Control de versiones · Documentación