Ingeniería
TFG de Ingeniería e Informática: validación técnica y trucos para subir la nota
Junio 2026 · 8 min de lectura · Corrige tu TFG
En ingeniería e informática, el tribunal evalúa sobre todo una cosa: ¿la solución funciona y está bien justificada? Un TFG que desarrolla una aplicación perfecta pero no la valida, o que elige tecnologías sin justificar por qué, no puede superar el 6.5 aunque el código sea excelente.
Lo que el tribunal de ingeniería prioriza
A diferencia de otras disciplinas, en ingeniería el "contenido" principal es la solución técnica. El tribunal lo evalúa en tres niveles:
- Planteamiento: ¿el problema está bien definido? ¿Los requisitos son claros y completos?
- Desarrollo: ¿las decisiones de diseño y tecnología están justificadas? ¿Se documenta el proceso, no solo el resultado?
- Validación: ¿la solución funciona? ¿Hay pruebas que lo demuestren? ¿Se compara con alternativas?
El error más frecuente: documentar solo el "qué" (qué se hizo) y olvidar el "por qué" (por qué se eligió este enfoque y no otro). El tribunal quiere ver razonamiento de ingeniero, no solo descripción.
La justificación tecnológica: lo que más se olvida
¿Por qué React y no Vue? ¿Por qué PostgreSQL y no MongoDB? ¿Por qué una arquitectura MVC y no microservicios? Estas decisiones parecen obvias cuando las tomas, pero el tribunal espera que las justifiques.
Para cada decisión tecnológica importante, incluye en la memoria:
- Qué alternativas existían
- Con qué criterios las evaluaste (rendimiento, coste, curva de aprendizaje, ecosistema…)
- Por qué elegiste la opción final
Una tabla comparativa de tecnologías es más clara que tres párrafos de texto y el tribunal la valora.
La validación: sin esto no hay más de 6.5
La validación técnica demuestra que tu solución cumple los requisitos. Sin ella, el tribunal no puede evaluar si el trabajo tiene calidad real. Según el tipo de TFG:
Aplicación web/móvil: pruebas funcionales (casos de prueba documentados), pruebas de rendimiento (tiempos de carga, usuarios concurrentes) y al menos una prueba con usuarios reales si es posible.
Algoritmo o modelo ML: métricas concretas (accuracy, F1, RMSE…), comparativa con baseline o estado del arte, validación cruzada si procede.
Sistema embebido / hardware: pruebas en condiciones reales, mediciones de consumo, latencia o precisión según aplique.
Análisis/simulación: validación del modelo con datos reales o casos conocidos, análisis de sensibilidad.
Evita: "la aplicación funciona correctamente" sin capturas, sin casos de prueba ni métricas. El tribunal no puede verificarlo.
El estado del arte: más importante de lo que parece
Muchos estudiantes de ingeniería escriben el estado del arte como un trámite. Es un error. El tribunal usa el estado del arte para evaluar si entiendes el contexto de tu trabajo: qué soluciones existen, cuáles son sus limitaciones y cómo la tuya las mejora o las aborda de forma diferente.
Un buen estado del arte en ingeniería incluye:
- Soluciones existentes para el mismo problema (comerciales y académicas)
- Comparativa de sus características, ventajas y limitaciones
- Justificación de por qué ninguna resuelve exactamente tu problema (o lo hace peor)
Estructura recomendada para TFG de Ingeniería/Informática
- Introducción: contexto, motivación y objetivos concretos y medibles
- Estado del arte: soluciones existentes y su análisis comparativo
- Análisis de requisitos: funcionales y no funcionales, bien especificados
- Diseño: arquitectura, diagramas (UML, entidad-relación, casos de uso…) y justificación de decisiones
- Implementación: descripción del desarrollo, tecnologías usadas y justificación
- Validación y pruebas: casos de prueba, métricas y resultados
- Conclusiones: logros respecto a los objetivos, limitaciones y trabajo futuro
- Bibliografía
Evalúa tu TFG de Ingeniería con criterios técnicos reales
Nuestra IA analiza tu memoria con los criterios específicos de Ingeniería e Informática: planteamiento técnico, justificación de decisiones, validación y documentación.
Evaluar mi TFG de Ingeniería →
Los 4 errores que más bajan la nota en ingeniería
- Sin validación de la solución — el error más frecuente y el que más penaliza. Si no demuestras que funciona, el tribunal no puede puntuarlo.
- Decisiones técnicas sin justificar — "usé React porque lo conozco" no es justificación técnica.
- Estado del arte sin comparativa — enumerar herramientas sin analizarlas no aporta valor.
- Conclusiones desconectadas de los objetivos — si planteaste 4 objetivos al inicio, las conclusiones deben decir si se cumplieron y en qué medida.