Skip to content

Documento de Proyecto

Jump to bottom
Urbano14 edited this page Dec 16, 2025 · 63 revisions

Documento del Proyecto —

Portada

Proyecto: <FIFAHUB>
Curso académico: <2025-2026>
Grupo: <2> <tarde>
Repositorio: <https://github.com/EGCproyecto/fifahub>
Wiki: https://github.com/EGCproyecto/fifahub/wiki/
Fecha de última edición: <15-12-2025>

Equipo

1. Indicadores del proyecto

Issues: https://github.com/EGCproyecto/fifahub/issues Actions: https://github.com/EGCproyecto/fifahub/actions Código: https://github.com/EGCproyecto/fifahub

1.1 Tabla de indicadores (equipo y total)

Miembro del equipo Horas Commits LoC Test Issues Work Item Dificultad
Blanes Bonachera, Urbano Muchas 46+5 14572 27 12 WI-92/ WI-Datasets M/H
Reyes Zájara, Daniel Muchas 32 2867 41 16 WI-89/WI-fakenodo H/M
García Eslava, Sergio Muchas 78 15465 54 17 WI-newdataset, WI-Trending M
Frutos Raigon, Iván Muchas 20 742 17 12 WI-98/Recommendation Service WI 69 — Perfil de usuario H/L
Lozano Gómez, Javier Muchas 48 712 6 14 WI-100/WI-105 M/L
<Moraga Fontán, Germán> Muchas 52 724 20 WI-98/WI-fakenodo H/H
TOTAL 35082 — H()/M()/L()

1.2 Evidencias de los indicadores

3. Resumen ejecutivo

3.1 Objetivo

El proyecto FIFAHUB tiene como objetivo aplicar de forma práctica los conceptos fundamentales de Evolución y Gestión de la Configuración (EGC) sobre un sistema software real, tomando como base el repositorio original UVLHub y adaptándolo al contexto de datos del videojuego FIFA.

El propósito principal es aprender y demostrar, a través de evidencia real de trabajo (issues, commits, métricas y despliegues), la correcta gestión del desarrollo incremental: planificación de tareas, resolución de errores, mejoras funcionales e integración de cambios continuos.

El proyecto está dirigido a:

  • Los miembros del equipo, como parte de su formación en Ingeniería del Software.
  • El profesorado evaluador, para mostrar una aplicación rigurosa de procesos de control de versiones, trabajo colaborativo y documentación organizada en GitHub.

FIFAHUB resuelve el problema de gestionar la evolución de un sistema basado en datos de FIFA, garantizando que los cambios se realizan de forma controlada y trazable, con atención a la calidad del código y la coherencia del histórico de desarrollo.

3.2 Alcance y entregables

El alcance del proyecto abarca desde la configuración inicial del entorno de desarrollo hasta la entrega de un sistema funcional corregido y mejorado en relación con aspectos clave detectados durante el trabajo colaborativo. Se ha trabajado sobre el repositorio EGCproyecto/fifahub, que actúa como un fork del proyecto original, con un historial de trabajo genuino del equipo aportado mediante issues y resoluciones.

Los entregables principales del proyecto son:

  • Repositorio Git con historial propio de trabajo
    Todos los cambios se han realizado mediante commits gestionados por el equipo, reflejando la evolución del proyecto conforme a las tareas definidas.

  • Gestión formal de issues cerradas
    Organización de bugs, tareas y mejoras con tipificación de dificultad y prioridad para apoyar decisiones de planificación.

  • Correcciones funcionales y mejoras técnicas aplicadas
    Resolución de errores críticos como fallos en el display de datasets, problemas en renderización y ajustes de workflows.

  • Configuración de entorno reproducible
    Adición de variables de configuración para correo electrónico en ejemplos de entorno y renombrado de workflows para mantener consistencia en CI.

  • Documentación de procesos
    Este documento y evidencias enlazadas en la wiki o en carpetas de documentación dentro del repositorio.

  • Validación de despliegue y entornos
    Verificación de Docker y Vagrant para asegurar que el sistema se puede levantar de forma reproducible, identificando y corrigiendo incompatibilidades durante el proceso.

El proyecto no solo cubre cambios de código, sino también la gestión de configuraciones, planificación y cierre de issues conforme a las buenas prácticas del desarrollo colaborativo moderno.

3.3 Resultados y métricas clave

El trabajo realizado se apoya en un conjunto de indicadores que permiten evaluar la contribución y la eficiencia del equipo, reflejados en la tabla de indicadores del apartado correspondiente. Estos indicadores se interpretan cualitativamente como evidencias del dominio de procesos de EGC:

  • Commits y contribuciones trazables
    Todos los cambios vienen acompañados de issues que justifican el trabajo realizado, facilitando el análisis histórico de cada aporte.

  • Resolución de bugs y mejoras
    Cierre de múltiples issues de tipo bug relacionados con la visualización y carga de datos, lo que demuestra atención a la calidad funcional del proyecto.

  • Tareas organizadas por prioridad y dificultad
    La tipificación (low, medium, high) de issues y tareas completadas muestra un entendimiento claro del esfuerzo requerido y una planificación adecuada.

  • Configuración y consistencia de workflows
    Acciones como el renombrado de archivos de workflows o la verificación de entornos reflejan un enfoque en la estabilidad del pipeline de construcción y despliegue.

Estos resultados no solo reflejan trabajo realizado, sino también la aplicación de metodologías que permiten evaluar objetivamente el progreso del proyecto, tal como se exige en la asignatura.

3.4 Riesgos y decisiones clave

Durante el desarrollo de FIFAHUB se identificaron y mitigaron una serie de riesgos tanto técnicos como organizativos:

  • Riesgo 1: Complejidad en configuración de entornos
    La combinación de Docker, Vagrant y dependencias varias presentaba riesgo de inconsistencias de despliegue.
    Decisión: crear y verificar workflows reproducibles para Docker/Vagrant, estableciendo un entorno fiable para todo el equipo.

  • Riesgo 2: Errores funcionales en módulos esenciales
    Bugs como la falta de visualización de datasets o errores de renderizado suponían un riesgo para la funcionalidad básica de FIFAHUB.
    Decisión: priorizar la resolución de estas issues para garantizar una base funcional estable antes de abordar mejoras de menor impacto.

  • Riesgo 3: Gestión de configuración inconsistente
    La ausencia de una política clara podía provocar pérdida de trazabilidad.
    Decisión: organizar issues con etiquetas de prioridad y dificultad y vincular cada cambio a un work item específico.

Además, se tomaron decisiones organizativas clave como:

  • La estructuración de tareas planificadas (planned tasks).
  • La identificación explícita de tareas no planificadas (unplanned tasks) surgidas durante la ejecución.

Esta práctica facilitó la adaptación a cambios imprevistos sin comprometer la coherencia del repositorio ni la planificación general.

En conjunto, estas decisiones permitieron no solo cumplir con los objetivos técnicos, sino también demostrar de forma clara y verificable que el proceso de desarrollo siguió prácticas aceptadas de ingeniería del software.

4. Descripción del sistema

4.1 Visión funcional

Usuarios y roles

FIFAHUB es una plataforma web colaborativa orientada a la gestión, publicación y exploración de datasets, desarrollada como una evolución funcional del proyecto base UVLHub y adaptada al dominio de datos del videojuego FIFA. El sistema está diseñado para soportar distintos tipos de usuarios, cada uno con responsabilidades y permisos claramente diferenciados:

  • Usuario no autenticado: puede acceder a información pública limitada, pero no puede interactuar con funcionalidades que impliquen modificación de datos ni acceder a secciones avanzadas.
  • Usuario autenticado: constituye el perfil principal del sistema. Puede explorar el catálogo completo de datasets, realizar búsquedas, acceder al detalle de datasets publicados por otros usuarios y navegar por páginas de autor y comunidad.
  • Propietario de datasets: usuario autenticado que, además, puede crear, editar y eliminar sus propios datasets, así como asociarlos a autores y comunidades.
  • Usuario con seguridad reforzada: el sistema soporta mecanismos avanzados de autenticación, incluyendo Two Factor Authentication (2FA), proporcionando un nivel adicional de protección de la cuenta.

La correcta definición de estos roles ha sido clave para garantizar un equilibrio entre colaboración, seguridad y control de acceso, uno de los objetivos centrales del proyecto.

Casos de uso principales

A partir del análisis del repositorio y del conjunto completo de Work Items e issues cerradas, se identifican los siguientes casos de uso fundamentales:

  1. Creación y gestión de datasets
    Los usuarios propietarios pueden crear datasets, definir sus metadatos, asociarlos a autores y comunidades y gestionar su ciclo de vida completo. Este flujo se ha ampliado para soportar distintos tipos de datasets, incluyendo datasets tabulares (CSV), como parte de la evolución hacia un DatatypeHub.

  2. Exploración y búsqueda avanzada
    La sección Explore permite a los usuarios descubrir datasets mediante listados y búsquedas. Se han corregido y ampliado estas funcionalidades para garantizar que todos los datasets relevantes aparezcan correctamente, independientemente de su tipo, y que puedan ser localizados de forma eficiente.

  3. Visualización de datasets y navegación contextual
    Los usuarios autenticados pueden acceder al detalle de datasets publicados por otros usuarios, navegar hacia perfiles de autor o comunidad y descubrir contenido relacionado.

  4. Descubrimiento basado en popularidad y tendencias
    El sistema incluye funcionalidades avanzadas como Trending Datasets, basadas en métricas de uso, que permiten destacar datasets relevantes y mejorar la experiencia de descubrimiento.

  5. Recomendaciones automáticas de contenido
    FIFAHUB incorpora un sistema de recomendación automática de datasets, que sugiere contenido relacionado al usuario en función de criterios definidos por el sistema.

  6. Interacción social
    Los usuarios pueden seguir a otros usuarios y comunidades, recibiendo actualizaciones y notificaciones cuando se producen cambios relevantes.

  7. Gestión del perfil de usuario
    Cada usuario dispone de un perfil propio desde el que puede consultar información personal y los datasets asociados a su cuenta.

  8. Seguridad y control de acceso
    El sistema refuerza la seguridad mediante autenticación de dos factores, pruebas de seguridad y endurecimiento de flujos sensibles.

Flujos relevantes

Un flujo representativo del sistema es el siguiente:

  1. Un usuario se registra y accede al sistema (con o sin 2FA).
  2. El usuario crea un nuevo dataset, selecciona su tipo (por ejemplo, tabular), añade metadatos y lo publica.
  3. El dataset pasa a estar disponible en:
    • Explore
    • Resultados de búsqueda
    • Secciones agregadas (Latest, Trending)
  4. Otros usuarios pueden:
    • Visualizar el dataset
    • Recibirlo como recomendación
    • Seguir al autor o comunidad asociada
  5. El sistema registra métricas de uso como descargas, que influyen en estadísticas y tendencias.

Este flujo refleja una experiencia completa que integra creación, exploración, recomendación y análisis del uso del sistema.

4.2 Arquitectura (visión técnica)

Componentes principales

FIFAHUB se basa en una arquitectura web monolítica, organizada en componentes claramente definidos:

  • Backend
    Implementado en Python, contiene la lógica de negocio, la gestión de usuarios y permisos, los controladores, servicios y endpoints API. Incluye módulos específicos para recomendaciones, métricas, seguidores y seguridad.

  • Frontend
    Basado en plantillas HTML y recursos estáticos (CSS y JavaScript), integrados con el backend. Incluye vistas para exploración, detalle de dataset, perfiles de usuario, trending, recomendaciones y estadísticas.

  • Base de datos
    Utiliza MariaDB como sistema de persistencia, almacenando usuarios, datasets, relaciones sociales, métricas de descargas y datos auxiliares.

  • Sistema de migraciones
    Gestionado mediante Alembic, permite evolucionar el esquema de base de datos de forma controlada, garantizando consistencia entre entornos.

  • Infraestructura de despliegue

    • Docker y Docker Compose para ejecución reproducible del sistema.
    • Vagrant como alternativa de entorno de desarrollo.
    • Variables de entorno centralizadas para la configuración.

  • Herramientas auxiliares
    Incluyen módulos como fakenodo, scripts de seed y utilidades para pruebas y simulación de servicios externos.

Integraciones externas

El sistema mantiene compatibilidad conceptual con el ecosistema UVLHub, incluyendo mecanismos para integrarse con servicios de publicación externos. En el contexto del proyecto, se desarrolló fakenodo, un servicio ficticio que simula Zenodo, permitiendo pruebas y validaciones sin depender de servicios reales.

Comunicación entre componentes

  • El frontend se comunica con el backend mediante peticiones HTTP.
  • El backend accede a la base de datos mediante conexiones SQL.
  • Las migraciones se ejecutan como parte del ciclo de despliegue.
  • Los servicios comparten configuración a través de variables de entorno.

Este modelo garantiza una comunicación clara y una separación efectiva de responsabilidades.

4.3 Modelo de datos

Entidades principales

  • User: usuario del sistema, con perfil, credenciales y configuración de seguridad (incluyendo 2FA).
  • Dataset: entidad central que representa un conjunto de datos (incluidos datasets tabulares).
  • Author: entidad de autoría asociada a datasets.
  • Community: agrupación temática o social de datasets.
  • Follow: relación que permite seguir usuarios y comunidades.
  • DownloadCounter: entidad que registra el número de descargas por dataset.
  • Recommendation: entidades auxiliares que soportan el sistema de recomendación automática.

Relaciones

  • Un usuario puede ser propietario de múltiples datasets.
  • Un dataset puede estar asociado a uno o varios autores.
  • Un dataset puede pertenecer a una o varias comunidades.
  • Los usuarios pueden seguir a otros usuarios y comunidades.
  • Cada dataset puede tener múltiples registros de métricas (descargas, recomendaciones).

La evolución de este modelo se ha gestionado mediante migraciones controladas.

4.4 Cambios desarrollados explícitamente para el proyecto

Los cambios realizados durante el proyecto se estructuran en los siguientes Work Items principales, cada uno con resultados observables en el sistema:

WI 105 — Download Counter

Implementación de contadores de descargas por dataset, utilizados como base para métricas y funcionalidades posteriores como trending.
Resultado observable: visualización y registro de descargas por dataset.

WI 100 — Trending Datasets

Desarrollo completo del sistema de datasets en tendencia, incluyendo lógica, API, optimización de base de datos, integración en UI y tests.
Resultado observable: sección de Trending Datasets visible para los usuarios.

WI 89 — Seguridad y 2FA

Endurecimiento de la seguridad del sistema mediante autenticación en dos factores, pruebas de seguridad y documentación asociada.
Resultado observable: cuentas con 2FA y flujos de autenticación reforzados.

WI 69 — Perfil de usuario

Implementación de perfiles de usuario y endpoints asociados para listar datasets por usuario.
Resultado observable: páginas de perfil con información y datasets del usuario.

WI 98 — Recomendaciones automáticas de datasets

Sistema completo de recomendación: servicio dedicado, algoritmo de scoring, integración en controladores, UI, tests y documentación.
Resultado observable: bloques de “datasets relacionados” y recomendaciones automáticas.

WI 92 — Following users and communities

Funcionalidad social para seguir usuarios y comunidades, incluyendo modelos, backend, frontend y notificaciones por email.
Resultado observable: botones de follow/unfollow y actualización de contenido seguido.

WI-fakenodo — Simulación de Zenodo

Creación de un servicio ficticio para simular un repositorio externo, con documentación y pruebas de carga.
Resultado observable: integración funcional sin dependencia de servicios reales.

WI-newdataset — DatatypeHub (Tabular / CSV)

Evolución del sistema hacia un DatatypeHub con soporte para datasets tabulares, orientado al dominio FIFA.
Resultado observable: soporte completo para datasets CSV y su correcta visualización y exploración.

5. Visión global del proceso de desarrollo (≈ 1.500 palabras)

5.1 Proceso seguido

Metodología

El desarrollo del proyecto FIFAHUB se ha realizado siguiendo una metodología híbrida, combinando ideas de Scrum y Kanban, adaptadas a las condiciones y restricciones establecidas en la asignatura. En particular, el proceso no ha utilizado Pull Requests, ya que estaban explícitamente prohibidas, y todos los cambios se integraron mediante merge directo sobre la rama principal.

El trabajo se organizó en torno a Work Items (WIs) como unidades de planificación de alto nivel. Cada WI representa una funcionalidad completa o un bloque relevante de evolución del sistema (por ejemplo, recomendaciones automáticas, trending datasets, seguridad, interacción social o soporte para nuevos tipos de datasets). Estos WIs se descompusieron en múltiples issues, que se abordaron de forma incremental y continua.

Este enfoque permitió mantener una planificación clara a nivel estratégico, mientras que la ejecución diaria del trabajo se realizaba de forma flexible, absorbiendo tanto tareas planificadas como incidencias y mejoras no previstas inicialmente.

Planificación

La planificación del proyecto se estructuró alrededor de los siguientes elementos:

  • Definición de Work Items principales, que marcaron los grandes objetivos funcionales del proyecto:

    • WI 105 — Download Counter
    • WI 100 — Trending Datasets
    • WI 89 — Seguridad y Two Factor Authentication (2FA)
    • WI 69 — Perfil de usuario
    • WI 98 — Recomendaciones automáticas de datasets
    • WI 92 — Following users and communities
    • WI-fakenodo — Simulación de Zenodo
    • WI-newdataset — DatatypeHub (datasets tabulares)

  • Descomposición de cada WI en issues más pequeñas, lo que permitió:

    • Dividir funcionalidades complejas en tareas manejables.
    • Clasificar el trabajo por dificultad.
    • Repartir responsabilidades.
    • Mantener trazabilidad clara entre planificación e implementación.

  • Iteraciones continuas, sin sprints formales, en las que las issues se resolvían y cerraban progresivamente conforme se completaban, siguiendo una filosofía cercana a Kanban.

Este modelo de planificación permitió avanzar de forma constante sin bloquear el desarrollo por dependencias rígidas o fases cerradas.

Gestión del trabajo

La gestión del trabajo se realizó íntegramente a través de GitHub, utilizando sus mecanismos básicos:

  • Issues como eje central del desarrollo
    Cada mejora, corrección de error o tarea técnica se registró como una issue. Las issues documentan el problema identificado, el contexto técnico y la solución aplicada.

  • Integración mediante merge directo
    Siguiendo las normas del proyecto, no se utilizaron Pull Requests. Los cambios se integraron directamente en la rama principal mediante merge, lo que implicó una mayor responsabilidad individual sobre:

    • La verificación previa del cambio.
    • La estabilidad del sistema tras cada integración.
    • La calidad de los commits realizados.

  • Commits trazables y justificados
    Los commits se realizaron con mensajes descriptivos y, en la mayoría de los casos, vinculados explícitamente a una issue concreta, garantizando la trazabilidad entre trabajo planificado y código integrado.

  • Gestión de tareas no planificadas
    Durante el desarrollo surgieron tareas no previstas inicialmente (bugs, ajustes de despliegue, mejoras de configuración). Estas tareas se registraron igualmente como issues, manteniendo un historial completo y evaluable del trabajo real realizado.

Control de calidad

Dado que no se emplearon Pull Requests como mecanismo de revisión formal, el control de calidad se reforzó en otras fases del proceso:

  • Verificación local previa a la integración

    • Ejecución del sistema en entorno local (Docker o Vagrant).
    • Pruebas manuales de los flujos afectados.
    • Validación de que los cambios no rompían funcionalidades existentes.

  • Tests automatizados

    • Tests unitarios para componentes críticos (por ejemplo, lógica de recomendaciones).
    • Tests de integración.
    • Tests de interfaz (Selenium) en funcionalidades relevantes.
    • Tests asociados a Work Items complejos como trending datasets o recomendaciones automáticas.

  • Integración continua (CI)

    • Uso de GitHub Actions para ejecutar pipelines automáticos tras la integración.
    • Normalización y mantenimiento de workflows.
    • Detección temprana de errores tras los merges.

  • Validación de despliegue

    • Verificación del correcto despliegue del sistema mediante Docker.
    • Corrección de errores relacionados con migraciones, dependencias y configuración.
    • Garantía de que el sistema puede levantarse de forma reproducible.

Este enfoque asegura que la calidad del sistema se mantiene incluso sin revisiones formales basadas en Pull Requests.

5.2 Herramientas utilizadas

Control de versiones

  • Git como sistema de control de versiones distribuido.
  • GitHub como plataforma central del repositorio.

CI/CD

  • GitHub Actions para la ejecución de procesos de integración continua.
  • Workflows personalizados y normalizados para verificación del sistema.

Gestión de issues

  • GitHub Issues como herramienta principal de:
    • Planificación.
    • Seguimiento del trabajo.
    • Documentación de problemas y decisiones técnicas.

Documentación

  • GitHub Wiki y ficheros Markdown para:
    • Documento del proyecto.
    • Documentación técnica y funcional.
    • Evidencias de métricas y trabajo realizado.

Otras herramientas

  • Docker y Docker Compose para entornos reproducibles.
  • Vagrant como alternativa de entorno de desarrollo.
  • MariaDB como sistema de base de datos.
  • Alembic para la gestión de migraciones.
  • Selenium para pruebas de interfaz.
  • Fakenodo como simulador de servicios externos (Zenodo).

5.3 Ejemplo de cambio propuesto y ciclo end-to-end (alto nivel)

A continuación se describe un ejemplo representativo del ciclo completo de desarrollo de un cambio, siguiendo exactamente el proceso aplicado en FIFAHUB.

Identificación de la necesidad (issue)

Se detecta una necesidad funcional, por ejemplo: “Incluir datasets en tendencia basados en métricas de uso”.
Se crea una issue describiendo el problema, el contexto y el objetivo del cambio.

Refinamiento y criterios de aceptación

La issue se refina definiendo criterios claros:

  • El sistema debe identificar datasets en tendencia.
  • Debe existir lógica de cálculo y persistencia.
  • La información debe mostrarse en la interfaz.
  • El sistema debe seguir siendo estable tras el cambio.

Diseño técnico (breve)

Se define un diseño de alto nivel:

  • Uso de métricas existentes (contadores de descargas).
  • Algoritmo de cálculo de trending.
  • Integración directa en backend y frontend.
  • Impacto controlado en base de datos mediante migraciones.

6. Entorno de desarrollo (≈ 800 palabras)

6.1 Requisitos

El proyecto FIFAHUB se ha desarrollado utilizando un entorno de trabajo homogéneo y reproducible, con el objetivo de minimizar problemas de configuración entre los miembros del equipo y garantizar la consistencia entre los distintos entornos de desarrollo.

Los requisitos mínimos para trabajar con el proyecto son los siguientes:

  • Sistema Operativo:

    • Linux (recomendado: Ubuntu 22.04 LTS)
    • El proyecto puede ejecutarse también en otros sistemas operativos siempre que se disponga de Docker y Docker Compose.

  • Lenguaje y runtime:

    • Python 3.12

  • Base de datos:

    • MariaDB, utilizada como sistema de persistencia principal.

  • Herramientas de virtualización y contenedores:

    • Docker
    • Docker Compose

  • Control de versiones:

    • Git, con repositorio alojado en GitHub.

  • Entorno de desarrollo:

    • Visual Studio Code (VSCode), recomendado como IDE común para todo el equipo.

  • Otras herramientas relevantes:

    • pytest y pytest-cov para pruebas automáticas
    • rosemary para ejecución de suites de test
    • flake8 y ESLint para análisis estático
    • pip-audit para análisis de dependencias
    • gitleaks para detección de secretos

Este conjunto de herramientas permite trabajar de forma consistente tanto en desarrollo local como en los entornos de integración continua y despliegue.

6.2 Instalación y puesta en marcha

A continuación se describen los pasos necesarios para levantar el sistema completo de forma local, garantizando una ejecución reproducible del proyecto.

  1. Clonar repo:
    • git clone https://github.com/EGCproyecto/fifahub
    • cd fifahub
  2. Configuración de entorno:
    • <variables de entorno, ficheros .env, etc.>
  3. Arranque de dependencias:
    • docker compose up -d
  4. Arranque del sistema:
    • source venv/bin/activate
    • flask run --host=0.0.0.0 --reload --debug
  5. Ejecución de tests:
    • rosemary test
  6. Verificación:
    • Acceso a la aplicación desde el navegador en http://localhost:5000. Se puede comprobar la página principal de Fifahub

6.3 Variantes por miembro

Todos los miembros usaron el mismo entorno de desarrollo.

7. Ejercicio de propuesta de cambio

7.1 Cambio propuesto

Título: Endurecimiento del esquema de subida de CSV: columna Description obligatoria

Objetivo:
A partir de este cambio, cualquier CSV subido al sistema deberá incluir obligatoriamente la columna Description en la cabecera.
Si el CSV no la contiene, el sistema debe rechazar la subida con un mensaje de error claro (demostrable en la defensa).

Criterios de aceptación:

  • El sistema rechaza la subida de cualquier CSV que no incluya Description en la cabecera.
  • El sistema acepta CSVs que sí incluyen Description.
  • El mensaje de error indica claramente que falta Description.
  • No se rompe ninguna funcionalidad existente relacionada con la subida o visualización de datasets.
  • Los tests del módulo tabular pasan tras el cambio.

7.2 Pasos detallados (incluyendo comandos y herramientas)

Flujo:
Proceso 100 % mediante comandos, sin Pull Requests, integrando el cambio en main mediante squash (un único commit).

Preparación (repositorio limpio y main actualizado)

git status
git checkout main
git pull --rebase origin main

(Optativo) Ver el último commit como referencia para la defensa:

git log -1 --oneline --decorate

Crear issue (trazabilidad)

Issue:
[TASK] Enforce Description column in CSV uploads

La issue incluye:

  • Objetivo
  • Alcance
  • Criterios de aceptación
  • Plan de verificación manual

Crear rama de trabajo

git checkout -b featuretask/TASK-CSV-enforce-description
git branch --show-current

Implementación

Backend

  • Archivo: app/modules/tabular/forms.py
  • Acción: añadir Description a FIFA_REQUIRED_COLUMNS.
grep -R "FIFA_REQUIRED_COLUMNS" -n app/modules/tabular/forms.py

Tests / CSV fixtures

  • Carpeta: app/modules/tabular/tests/data/
  • Acción: añadir Description a la cabecera y un valor por fila en todos los CSV.
ls -la app/modules/tabular/tests/data/
grep -R "Description" -n app/modules/tabular/tests/data/ || true

Tests locales y verificación manual

Tests automáticos

pytest app/modules/tabular/tests/

Lint (si aplica)

flake8

Verificación manual

  • Subir CSV sin Description → debe fallar con error.
  • Subir CSV con Description → debe funcionar correctamente.

Si el proyecto se levanta con Docker:

docker compose up --build
docker compose logs -f

Commit en la rama

git status
git diff
git add app/modules/tabular/forms.py app/modules/tabular/tests/data
git commit -m "feat(tabular): require Description column in CSV uploads"

Integración a main con squash real (sin Pull Request)

El squash se realiza en local, antes del merge, para que main reciba un único commit.

Rebase de la rama contra main 

git checkout main
git pull --rebase origin main
git checkout featuretask/TASK-CSV-enforce-description
git rebase main

Si hay conflictos:

git status
# resolver conflictos
git add <ficheros>
git rebase --continue

Squash local (un solo commit)

git reset --soft main
git commit -m "feat(tabular): require Description column in CSV uploads"

Verificación del historial:

git log --oneline --decorate -n 10
git cherry -v main

Merge a main usando comandos

git checkout main
git merge --ff-only featuretask/TASK-CSV-enforce-description

Tests finales en main 

pytest app/modules/tabular/tests/

(Lint opcional)

flake8

Push a main 

git push origin main

Limpieza de ramas (opcional)

git branch -d featuretask/TASK-CSV-enforce-description
git push origin --delete featuretask/TASK-CSV-enforce-description

Verificación post-merge

git log --oneline --decorate -n 15

Cierre de issue y documentación

Cerrar la issue indicando que:

  • Description es obligatoria en la validación.
  • Los CSV de tests han sido actualizados.
  • pytest app/modules/tabular/tests/ pasa correctamente.
  • Verificación manual realizada (upload KO / OK).
  • Referencia al commit final (hash).

Resultado esperado

La subida de CSV queda endurecida:

  • Sin Description → se rechaza.
  • Con Description → funciona correctamente.

El cambio se integra en main sin Pull Request, usando git merge y dejando un único commit squash, garantizando trazabilidad y un historial limpio.

8.2 Trabajo futuro (curso siguiente)

A continuación se enumeran algunas mejoras que no se han implementado en este curso, pero que serían interesantes para futuras versiones del sistema:

  • Sistema de permisos más detallado por dataset — Impacto: alto — Esfuerzo: medio
    Permitir distintos niveles de acceso a un mismo dataset (solo lectura, edición, colaboración), especialmente útil en entornos más colaborativos.

  • Panel de estadísticas más completo — Impacto: alto — — Esfuerzo: alto
    Añadir un panel con estadísticas más avanzadas sobre uso de datasets, descargas y tendencias a lo largo del tiempo.

  • Configuración personalizada de notificaciones — Impacto: medio — Esfuerzo: medio
    Permitir que cada usuario decida qué tipo de notificaciones quiere recibir y cuáles no.

Clone this wiki locally