El TFG de Ingeniería Informática tiene una trampa que casi nadie ve venir: no te suspenden por programar mal, te suspenden por documentar mal. Puedes tener una aplicación que funciona de maravilla y llevarte un 6 raspado porque la memoria no explica por qué tomaste cada decisión, porque no hay diagramas UML, porque el repositorio es un único commit gigante llamado 'proyecto final' o porque en la defensa la demo se cae delante del tribunal. La parte de código es la que más horas te lleva, pero es la que menos peso tiene en la nota.
En esta guía te cuento el proceso completo de principio a fin: qué pide tu escuela, qué tipos de TFG puedes elegir, cómo se estructura la memoria por capítulos con norma IEEE, cómo hacer el análisis y diseño con UML, qué stack y qué herramientas usar, cómo montar el repositorio Git para que sume, cómo probar y desplegar, y cómo preparar una defensa con demo que no te deje tirado. Vale para grados de Informática presenciales y online (UOC, UNIR, UNED, UOC, universidades públicas), porque el esqueleto es el mismo en casi todas.
No evalúa si tu app es bonita. Evalúa tres cosas: (1) que hayas seguido un método de ingeniería —análisis, diseño, implementación, pruebas—; (2) que la memoria justifique cada decisión técnica; (3) que sepas defender lo que hiciste. El código es la prueba de que sabes, pero la nota vive en la memoria y en la defensa.
Qué pide un TFG de Ingeniería Informática
Un TFG de Informática es un proyecto de ingeniería, no un tutorial ampliado. Eso significa que tienes que demostrar que sabes aplicar un ciclo de desarrollo entero: partir de un problema real, analizar requisitos, diseñar una solución, implementarla, probarla y evaluarla. La escuela quiere ver criterio de ingeniero, no solo destreza de programador. Da igual que la app sea pequeña: si el análisis, el diseño y las pruebas están bien hechos, el trabajo es sólido.
El alcance típico es de 8 a 12 ECTS (unas 250-350 horas de trabajo real). La memoria suele moverse entre 50 y 90 páginas sin contar anexos. Casi todas las escuelas exigen que el proyecto sea individual, original y que aporte algo tuyo: no vale clonar un repositorio de GitHub y cambiarle el nombre. Y prácticamente todas piden entregar el código fuente junto con la memoria, normalmente como enlace a un repositorio Git o como fichero comprimido.
Tipos de TFG que puedes elegir
No todos los TFG de Informática son iguales. Elegir bien el tipo desde el principio te ahorra meses de sufrimiento, porque cada uno pide una estructura y una carga de trabajo distinta. Estos son los tres grandes bloques:
- Desarrollo de software: es el más común. Construyes una aplicación real (web, móvil, API, videojuego, sistema de gestión). El peso está en el análisis de requisitos, el diseño de la arquitectura y la calidad del código. Ideal si te gusta programar y quieres algo tangible que enseñar en la defensa.
- Investigación o experimentación: comparas algoritmos, entrenas modelos de machine learning, mides rendimiento de tecnologías, haces una revisión sistemática de un campo. El peso está en la metodología científica, los experimentos reproducibles y el análisis de resultados con datos. Aquí importa más el rigor que la interfaz.
- Sistemas e infraestructura: diseñas y despliegas una arquitectura (redes, cloud, contenedores, ciberseguridad, DevOps, IoT). El peso está en el diseño de la infraestructura, la configuración, las pruebas de carga y seguridad, y la justificación de las decisiones de arquitectura.
Elige un problema que puedas acotar en una frase y resolver de verdad en tu plazo. 'Una app para que los vecinos de una comunidad reserven la pista de pádel' es mejor TFG que 'una red social con IA'. Lo pequeño y bien terminado siempre gana a lo grande y a medias. Y si puedes, reutiliza un problema real de tus prácticas o de tu trabajo: ya conoces el dominio.
Estructura de la memoria por capítulos
La memoria de un TFG de Informática sigue el ciclo de vida del software. No es un ensayo, es un documento de ingeniería. Esta es la estructura estándar que funciona en casi cualquier escuela; ajusta los títulos a la plantilla oficial de la tuya, pero el orden lógico es este:
- 1Introducción: contexto, motivación, problema que resuelves, objetivos (uno general + varios específicos y medibles) y metodología de trabajo (Scrum, Kanban, cascada, iterativo).
- 2Estado del arte / análisis de alternativas: qué soluciones existen ya, qué tecnologías hay disponibles y por qué eliges tu stack. Aquí justificas Java vs Python, React vs Angular, SQL vs NoSQL. Sin esto, el tribunal piensa que elegiste al azar.
- 3Análisis de requisitos: requisitos funcionales y no funcionales, casos de uso, historias de usuario. Es el capítulo que más se salta la gente y el que más peso tiene.
- 4Diseño: arquitectura del sistema, diagramas UML (clases, secuencia, despliegue), modelo de datos (entidad-relación), diseño de la interfaz (wireframes o mockups).
- 5Implementación: decisiones técnicas relevantes, patrones de diseño usados, fragmentos de código clave (no vuelques todo el código, solo lo interesante), problemas que encontraste y cómo los resolviste.
- 6Pruebas: plan de pruebas, tipos (unitarias, integración, sistema, aceptación), herramientas y resultados. Un capítulo de pruebas serio sube la nota más que cien líneas de código extra.
- 7Despliegue y conclusiones: cómo se pone en producción, objetivos cumplidos vs planteados, limitaciones honestas y líneas de trabajo futuro.
- 8Bibliografía y anexos: referencias con norma IEEE, manual de usuario, manual de instalación y enlace al repositorio.
Sobre la norma de citación: en Informática lo habitual es IEEE (referencias numeradas entre corchetes, [1], [2], ordenadas por aparición), no APA. Comprueba tu normativa, pero si tu escuela no obliga a APA, usa IEEE: es el estándar del área y queda mucho más profesional en un trabajo técnico. Gestor recomendado: Zotero o Mendeley con el estilo IEEE cargado, así no formateas referencias a mano.
Análisis y diseño con UML
Los diagramas UML son la parte más 'de ingeniería' de la memoria y la que separa un TFG de un proyecto de clase. No hace falta que hagas los catorce tipos de diagrama que existen; con tres o cuatro bien hechos vas sobrado. Estos son los que de verdad importan:
- Diagrama de casos de uso: qué puede hacer cada actor (usuario, administrador, sistema externo) con el software. Es el mapa de funcionalidades.
- Diagrama de clases: la estructura estática del sistema, con entidades, atributos, métodos y relaciones. Imprescindible si usas orientación a objetos.
- Diagrama de secuencia: cómo colaboran los objetos en un flujo concreto (por ejemplo, 'realizar una reserva'). Demuestra que entiendes la dinámica del sistema.
- Diagrama de despliegue o de componentes: cómo se organizan las piezas en la infraestructura (servidor, base de datos, cliente, API). Muy útil si tu TFG es de sistemas.
Para dibujarlos, olvídate de hacerlo a mano. Herramientas reales que se usan: PlantUML (defines los diagramas como texto, versionable en Git, ideal para gente técnica), draw.io / diagrams.net (gratis, sencillo, exporta a PNG y SVG), StarUML o Visual Paradigm (más potentes, con versión de estudiante). El modelo entidad-relación de la base de datos lo puedes sacar con dbdiagram.io o directamente con el modelador de MySQL Workbench o pgAdmin.
Arquitectura, stack y repositorio Git
El stack tecnológico hay que justificarlo, no soltarlo. Da igual lo que elijas mientras expliques por qué. Combinaciones habituales y sólidas para un TFG: backend en Java con Spring Boot, Python con Django o FastAPI, o Node.js con Express; frontend en React, Angular o Vue; base de datos PostgreSQL o MySQL para relacional, MongoDB para documental; contenedores con Docker. Para móvil, Kotlin (Android), Swift (iOS) o Flutter/React Native si quieres multiplataforma. Elige lo que domines: la defensa la haces tú, y el tribunal preguntará por decisiones de tu arquitectura.
El repositorio Git no es un adorno: es una prueba de cómo trabajas. Un historial con un solo commit gigante grita 'lo hice todo la última semana'. Un historial con commits pequeños, frecuentes y con mensajes claros ('feat: login con JWT', 'fix: validación de fechas en reservas') demuestra método. Súbelo a GitHub o GitLab, ponlo público o comparte acceso con tu tutor, y cuida el README: descripción, instrucciones de instalación, tecnologías y capturas. Ese README es lo primero que abre el tribunal.
Haz commits desde el primer día, aunque sean pequeños. Usa ramas (una por funcionalidad) y mensajes con formato tipo 'feat/fix/docs'. Añade un .gitignore para no subir node_modules ni credenciales. Si además configuras un flujo de CI/CD sencillo con GitHub Actions que ejecute los tests en cada push, tienes un punto extra casi garantizado: demuestra madurez de ingeniería.
Pruebas y despliegue
El capítulo de pruebas es donde más gente pierde nota tonta, porque lo dejan en dos frases o directamente no lo ponen. Un plan de pruebas bien montado convence al tribunal de que tu software funciona de verdad. Herramientas por lenguaje: JUnit y Mockito (Java), pytest (Python), Jest o Vitest (JavaScript/TypeScript). Para pruebas de API, Postman o Insomnia. Para pruebas de interfaz de extremo a extremo, Cypress o Selenium. Para medir calidad y cobertura de código, SonarQube o el propio informe de cobertura de tu framework.
Cubre al menos estos niveles: pruebas unitarias (funciones aisladas), de integración (que los módulos hablen entre sí), de sistema (el flujo completo) y de aceptación (que cumpla los requisitos del capítulo de análisis). No necesitas el 100% de cobertura; con probar lo crítico y documentar los casos de prueba con su entrada, salida esperada y resultado obtenido, ya tienes un capítulo digno.
Sobre el despliegue: si puedes dejar el proyecto funcionando en línea, hazlo. Opciones gratuitas o baratas para un TFG: Vercel o Netlify (frontend), Render, Railway o Fly.io (backend y bases de datos), y las capas gratuitas de AWS, Azure o Google Cloud si quieres tocar cloud de verdad. Docker Compose para levantar todo el entorno con un comando queda muy bien y facilita que el tutor lo pruebe. Un enlace vivo en la defensa vale más que mil capturas.
La defensa con demo en directo
La defensa de un TFG de Informática tiene un ingrediente que otras áreas no tienen: la demo. El tribunal quiere ver el software funcionando. Prepara una presentación de 10-15 minutos (según tu escuela) que cuente el problema, los objetivos, la arquitectura, dos o tres decisiones técnicas interesantes y las conclusiones. Reserva el tramo central para la demo: enseña el flujo principal, no toda la aplicación. Cronométrala y ensáyala en voz alta al menos tres veces.
Las preguntas típicas del tribunal técnico son predecibles: por qué elegiste ese stack, cómo garantizas la seguridad (contraseñas hasheadas, inyección SQL, autenticación), cómo escalaría el sistema, qué pasa si falla la base de datos, qué mejorarías con más tiempo. Ten una respuesta honesta para cada una. Reconocer una limitación con criterio ('no implementé caché porque el volumen no lo justificaba, pero lo dejo como trabajo futuro') puntúa más que fingir que todo es perfecto.
El wifi de la facultad se cae, el servidor se duerme, la base de datos en la nube tarda en despertar. Graba un vídeo de la demo completa como plan B y tenlo abierto en una pestaña. Lleva también capturas en las diapositivas. Si la demo en vivo falla, cambias al vídeo sin perder el ritmo y el tribunal ni se inmuta. Improvisar delante del tribunal con la demo caída es el peor sitio para descubrir un bug.
Errores típicos que hunden la nota
- Todo el peso en el código y una memoria pobre: es el error número uno. La nota está en la documentación, no en las líneas de código.
- Saltarse el análisis de requisitos: sin casos de uso ni requisitos claros, el diseño no se sostiene y el tribunal lo nota.
- Un repositorio con un único commit 'final': delata que lo hiciste todo de golpe y resta credibilidad a todo el proceso.
- No justificar el stack: 'usé React porque me gusta' no es una razón de ingeniería. Compara alternativas.
- Capítulo de pruebas inexistente o de relleno: sin pruebas, no demuestras que el software funciona.
- Objetivos genéricos e inmedibles: 'hacer una buena app' no se puede evaluar. Formula objetivos concretos y verificables.
- Citar con estilo inconsistente o copiar fragmentos sin referenciar: el antiplagio (Turnitin) también revisa TFG técnicos, y el código copiado sin atribuir se detecta.
- Dejar el despliegue y la defensa para el final: la demo se prepara con margen, no la noche antes.
Checklist final antes de entregar
- Objetivos del capítulo 1 cumplidos y comentados uno a uno en las conclusiones.
- Diagramas UML incluidos, legibles y coherentes con el código real.
- Requisitos funcionales y no funcionales listados y trazados a los casos de uso.
- Repositorio Git ordenado, con README completo, .gitignore y sin credenciales subidas.
- Capítulo de pruebas con casos concretos, herramientas y resultados.
- Bibliografía con norma IEEE y todas las referencias citadas en el texto.
- Software desplegado o, como mínimo, un vídeo-demo grabado como plan B.
- Manual de instalación probado en una máquina limpia (que el tutor pueda ejecutarlo).
- Memoria pasada por el corrector, sin faltas y con formato de la plantilla oficial.
- Presentación ensayada y cronometrada, dentro del tiempo asignado.
Si sigues este proceso —problema acotado, análisis serio, diseño con UML, código versionado en Git, pruebas documentadas, despliegue y una defensa ensayada con plan B— tu TFG de Informática estará por encima de la media sin necesidad de reinventar la rueda. La clave no es programar más, es documentar y demostrar mejor lo que ya has hecho.
Si vas justo de tiempo o se te atraganta el análisis, la memoria técnica o la parte de UML, en Academia Tu Futuro te asignamos un experto del área de Informática que trabaja contigo desde el campus virtual, con antiplagio Turnitin antes de cada entrega. Pídenos un presupuesto sin compromiso y te contamos cómo lo enfocaríamos en tu caso.
¿Te ayudamos con tu trabajo?
Presupuesto en menos de 24h, sin compromiso. Pago por fases y campus virtual privado con tu experto.