TFG Ingeniería Informática: guía práctica, herramientas y ejemplos

Introducción: El Trabajo de Fin de Grado (TFG) en Ingeniería Informática exige una combinación de rigor técnico, gestión de proyecto y capacidad para comunicar resultados. Este artículo ofrece una hoja de ruta concreta: cómo escoger el tema, estructurar entregables, seleccionar herramientas y preparar la defensa. Se aporta también un ejemplo práctico con entregables por semanas que puede adaptarse a distintos ámbitos (aplicaciones web, sistemas embebidos, aprendizaje automático).

Elección del tema y viabilidad

La selección del tema marca la diferencia entre un TFG que permanece como documento y otro que genera valor comprobable. Conviene evaluar tres preguntas antes de comprometerse: ¿qué se pretende demostrar o construir?, ¿qué datos o recursos son necesarios?, ¿cuál es el criterio de éxito?

Consejo práctico: preferir proyectos con límites claros y entregables medibles. Un proyecto amplio como «inteligencia artificial aplicada» suele fallar por falta de foco; en su lugar, acotar a «clasificación de fallos en maquinaria ligera con sensores acelerométricos» ofrece objetivos y métricas concretas.

Antes de arrancar, confirmar la disponibilidad de datos, hardware o software. Si el proyecto depende de datos externos, obtener muestras y describir su formato y volumen en la memoria. Si necesita hardware, especificar proveedores y plazos de entrega para evitar retrasos en el cronograma.

Metodología y planificación

Un TFG con planificación realista reduce el riesgo de improvisación en las últimas semanas. Dividir el proyecto en fases permite medir el avance y justificar recursos.

Fases recomendadas: definición del problema; revisión bibliográfica; diseño de solución (arquitectura, modelos, interfaces); implementación; pruebas y validación; documentación y defensa.

Herramientas y elección del stack

La elección de herramientas debe responder a la reproducibilidad y al mantenimiento. A continuación, una comparación práctica de opciones habituales:

• Control de versiones: Git es la opción estándar. Emplear ramas por funcionalidad y etiquetas para versiones entregables.
• Entornos: Docker ofrece portabilidad entre máquinas; los entornos virtuales (venv, conda) son más ligeros para prototipos rápidos.
• Lenguajes y frameworks: Para back-end, Node.js, Django o Spring según competencia. Para componentes de IA, Python con scikit-learn o PyTorch. Seleccionar lo que garantice reproducibilidad en el plazo del TFG.
• Base de datos: PostgreSQL para datos relacionales; MongoDB cuando el esquema sea flexible. Evaluar la complejidad de consultas previstas.
• Documentación: LaTeX ofrece formato académico profesional; un buen procesador de texto puede ser suficiente si el formato exigido por la universidad es simple.

Desarrollo, documentación y pruebas

Implementación y documentación deben avanzar de forma paralela. La memoria no es un anexo posterior: documentar decisiones arquitectónicas y resultados de pruebas mientras se desarrollan evita rehacer trabajo.

Checklist básico de control de calidad:

• Repositorio con README que explique cómo ejecutar el proyecto.
• Automatización mínima: script de instalación o Dockerfile.
• Pruebas unitarias para componentes críticos.
• Scripts de evaluación para reproducir métricas presentadas en la memoria.
• Registro de experimentos (logs, versiones de datos y modelos).

Pruebas y métricas: definir métricas desde el inicio. Para sistemas de clasificación, precisión, recall y matriz de confusión. Para rendimiento, latencia y consumo de recursos. Las tablas con resultados por versión del sistema facilitan la comparación directa.

Ejemplo práctico: mini-proyecto de detección de anomalías en sensores

Descripción breve: desarrollar un prototipo que detecte anomalías en datos de sensores de vibración para predecir fallos. Objetivo: demostrar que un modelo simple permite detectar desviaciones relevantes en condiciones controladas.

Entregables propuestos y calendario (16 semanas):

• Semanas 1-2: Definición del alcance y obtención de datos (registro y formato). Entregable: documento de especificación de 2 páginas.
• Semanas 3-4: Revisión bibliográfica y elección de técnicas (umbralismo, aislamiento, autoencoders). Entregable: estado del arte resumido y justificación técnica.
• Semanas 5-8: Implementación del pipeline de ingestión y preprocesado. Entregable: repositorio con scripts de limpieza y ejemplos de datos.
• Semanas 9-11: Entrenamiento y validación de modelos. Entregable: notebook reproducible con métricas y gráficos.
• Semanas 12-13: Integración en contenedor y pruebas de despliegue local. Entregable: Dockerfile y guía de uso.
• Semanas 14-15: Redacción de la memoria y preparación de la presentación. Entregable: borrador de memoria y diapositivas.
• Semana 16: Ensayo de defensa y entrega final. Entregable: memoria final, código etiquetado, demo preparada.

Ejemplo de estructura de repositorio:

• /data/raw
• /src/preprocessing
• /src/models
• /notebooks
• /docker
• /docs

En este mini-caso, una recomendación práctica es desarrollar primero un detector sencillo (p. ej., umbral basado en desviación estándar) que sirva como línea base antes de aplicar modelos complejos. Si resultados complejos no mejoran la línea base, documentar por qué y qué variables fallan.

Preparación de la defensa y criterios de evaluación

La exposición debe narrar una progresión lógica: problema, metodología, implementación, resultados y lecciones aprendidas. Empezar con una diapositiva con el valor aportado por el proyecto y las limitaciones detectadas genera expectativas claras en el tribunal.

Tener preparado un demo breve y robusto. Si la demo depende de servicios externos, crear una versión local o grabar un vídeo de ejecución para evitar fallos por conectividad.

Preguntas habituales del tribunal y cómo abordarlas:

• Validación de datos: explicar el origen, limpieza y sesgos potenciales.
• Reproducibilidad: indicar cómo ejecutar los experimentos y qué recursos se necesitan.
• Contribución original: clarificar qué parte del trabajo aporta novedad (ajuste, integración, evaluación o implementación).
• Limitaciones: presentar escenarios en los que el sistema no funciona y líneas futuras para mitigarlo.

Conclusión: Un TFG de Ingeniería Informática con posibilidades de éxito combina alcance acotado, planificación por entregables, elecciones de herramientas que faciliten la reproducibilidad y una defensa orientada a demostrar valor tangible. Implementar prototipos tempranos, documentar decisiones técnicas y preparar una demo resiliente reduce sorpresas en la fase de evaluación. Aplicar la hoja de ruta propuesta y adaptar los plazos según recursos disponibles dará una base sólida para obtener una evaluación favorable sin depender de promesas no verificables.