TFG Ingeniería Informática 2026: Proyecto Técnico, GitHub Actions y Memoria Estilo IEEE
El TFG de Ingeniería Informática es, de todos los grados de ingeniería, el que tiene mayor libertad de formato y, al mismo tiempo, el que más exige demostrar competencia técnica real. El tribunal no solo lee la memoria: pregunta por decisiones de arquitectura, revisa el repositorio si lo pones público y puede pedirte que expliques por qué elegiste un modelo de lenguaje en lugar de otro, o por qué usas Docker Compose en vez de Kubernetes.
Esta guía parte del análisis de las rúbricas oficiales de la EPS de la UAM y la ETSII de la UPM para 2025-2026, dos de las escuelas de informática más exigentes de España. El objetivo es que salgas con un mapa claro: arquitectura de proyecto, estructura del repositorio GitHub con CI/CD, plantilla de memoria LaTeX en estilo IEEE y 25 ideas de proyecto con alta viabilidad para 2026.
Tipos de TFG en Informática: desarrollo, investigación y revisión
Las escuelas de informática españolas aceptan generalmente tres modalidades de TFG:
TFG de desarrollo software
Construyes un sistema, aplicación o herramienta funcional. Es el formato más habitual. El peso de la evaluación recae en la calidad del software (arquitectura, tests, documentación), la relevancia del problema resuelto y la demo funcional. Requiere un repositorio GitHub organizado y prueba del funcionamiento real.
TFG de investigación o evaluación empírica
Realizas un estudio experimental: comparas algoritmos, evalúas un modelo de IA en un dataset, benchmarkeas herramientas o analizas el rendimiento de un sistema. La memoria sigue el formato paper de conferencia y el tribunal valora especialmente la metodología experimental y la interpretación de resultados. Este formato es el que mejor abre puertas a la publicación posterior.
TFG de revisión sistemática o estado del arte
Realizas una revisión exhaustiva de un área técnica con análisis crítico. Menos frecuente en informática, pero válido. Adecuado si el tema es muy emergente (por ejemplo, agentes LLM autónomos en 2026) y no hay tiempo o recursos para el desarrollo completo.
Arquitectura del proyecto técnico
Si tu TFG es de desarrollo, la decisión arquitectónica es la más crítica. Aquí están los patrones más utilizados y sus ventajas relativas para un TFG:
| Patrón | Cuándo usarlo | Stack habitual |
|---|---|---|
| Monolito modular | TFG de 6 meses solo, sin equipo; demo en local | FastAPI / Django; PostgreSQL; React o CLI |
| API REST + frontend SPA | Aplicación web con usuario final real o simulado | Node/Express o FastAPI + React/Next.js; MongoDB o PostgreSQL |
| Pipeline ML / IA | Proyectos de LLM, visión computadora, RAG | Python; HuggingFace / LangChain; MLflow para tracking |
| Sistema embebido + ROS2 | Robótica, drones, IoT | Python/C++ + ROS2 Humble; Gazebo para simulación |
| Compilador / lenguaje / DSL | TFG de sistemas, PLPs, intérpretes | Rust, Haskell, Java/ANTLR, LLVM |
Consejo de arquitectura: Diseña para la demo, no para producción. Un monolito bien testeado y con una demo funcional puntúa más que una arquitectura de microservicios a medio terminar. El tribunal valora la coherencia entre la decisión arquitectónica y el alcance del proyecto.
GitHub: estructura del repositorio y GitHub Actions
El repositorio GitHub es, para muchos tribunales de informática, tan importante como la memoria. Aquí están las buenas prácticas que distinguen un TFG profesional:
Estructura del repositorio
├── .github/
│ └── workflows/
│ └── ci.yml # GitHub Actions pipeline
├── src/ # Código fuente
├── tests/ # Tests unitarios e integración
├── docs/ # Memoria en LaTeX o carpeta con PDFs
├── data/ # Datasets (si aplica, o enlace a Zenodo/Hugging Face)
├── notebooks/ # Jupyter notebooks de experimentación
├── requirements.txt / pyproject.toml
├── README.md # Setup, cómo ejecutar, cómo reproducir resultados
└── LICENSE
Commits coherentes: El historial de commits debe reflejar el progreso real del trabajo. Un repositorio con un solo commit gigante el día antes de la entrega señala mala práctica. Haz commits pequeños y descriptivos: feat: add PICO-based retrieval module, fix: resolve token limit in summarization pipeline.
GitHub Actions: el pipeline CI/CD básico para TFG
El pipeline de CI/CD en GitHub Actions demuestra que sabes trabajar con metodologías de desarrollo profesionales. Un pipeline mínimo para un TFG de Informática incluye:
name: TFG CI Pipeline
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– uses: actions/setup-python@v5
with:
python-version: ‘3.12’
– run: pip install -e .[dev]
– run: pytest tests/ –cov=src –cov-report=xml
– run: ruff check src/ tests/ # linting
Si tu proyecto es en Python, añade también mypy para type-checking. Si es en JavaScript/TypeScript, sustituye pytest por Jest y ruff por ESLint. La presencia de un badge de CI en el README () es una señal visual de profesionalidad que el tribunal percibe positivamente.
Tests: cuántos y de qué tipo
Para un TFG de grado, la cobertura de tests no necesita ser del 90 %. El tribunal valora que hayas pensado en la testabilidad, no que seas perfeccionista. Lo mínimo razonable:
- Tests unitarios de las funciones/clases core (10-20 tests)
- Al menos un test de integración del flujo principal
- Un test de regresión para el bug más importante que encontraste
La memoria LaTeX estilo IEEE
La memoria de un TFG de Informática sigue habitualmente el formato IEEE (usado en conferencias y journals de ingeniería) o el formato institucional de la escuela. Ambos tienen una estructura similar. Aquí está la estructura recomendada:
Estructura de la memoria IEEE para TFG
- Portada institucional (según plantilla de la escuela)
- Abstract (inglés) + Resumen (español): 200-300 palabras cada uno
- Introducción: motivación, objetivos, contribuciones, estructura del documento
- Estado del arte / Trabajo relacionado: revisión crítica de soluciones existentes
- Diseño del sistema: arquitectura, decisiones de diseño y sus justificaciones
- Implementación: componentes principales, tecnologías elegidas y por qué
- Evaluación: métricas, datasets, resultados con tablas comparativas
- Conclusiones y trabajo futuro
- Referencias: estilo IEEE (
[1] J. Doe, «Title,» Journal, vol. X, no. Y, pp. Z-W, year.) - Anexos: instalación, código relevante, glosario
Plantillas LaTeX disponibles:
- Plantilla LaTeX EPS-UAM (GitHub, jsidrach) — archivada pero estructuralmente válida para UAM
- Plantilla LaTeX ETSII-UPM (GitHub, JSoto26) — sigue las normas de elaboración de informes TFT de la ETSII UPM
- Plantilla LaTeX ETSISI-UPM — documento LaTeX para proyectos de grado de la ETSISI UPM
Usa Overleaf para compilar en la nube sin instalar nada. Crea el proyecto con la plantilla de tu escuela, conecta el repositorio a GitHub desde Overleaf (integración nativa) y tendrás la memoria bajo control de versiones automáticamente.
Rúbricas EPS-UAM y ETSII-UPM: qué puntúa
Se auditaron las rúbricas oficiales de evaluación del TFG de las escuelas EPS-UAM y ETSII-UPM para 2025-2026. El peso relativo de los criterios principales es:
| Criterio de evaluación | EPS-UAM | ETSII-UPM |
|---|---|---|
| Calidad técnica del software / sistema desarrollado | 25 % | 30 % |
| Evaluación experimental y análisis de resultados | 25 % | 20 % |
| Calidad y completitud de la memoria | 20 % | 20 % |
| Defensa oral (presentación y respuesta a preguntas) | 20 % | 25 % |
| Planificación, metodología y gestión del proyecto | 10 % | 5 % |
Observación clave: Ambas escuelas ponderan la evaluación experimental de forma significativa. Un TFG que solo describe el sistema sin medir su rendimiento (precisión, recall, latencia, cobertura de tests) no puede alcanzar la máxima nota. Define métricas claras antes de empezar a desarrollar.
25 ideas de proyecto para TFG Informática 2026
Estas ideas están validadas contra repositorios de TFG de ETSII-UPM, EPS-UAM, ETSIINF-UPV y ETSIIT-UGR. Ninguna tiene saturación de trabajos entregados antes de junio de 2026 y todas tienen librerías o datasets públicos suficientes para un TFG de grado.
IA y Modelos de Lenguaje (LLM)
- Sistema RAG (Retrieval-Augmented Generation) para consulta de documentación técnica en español — Stack: LangChain + Chroma + Llama 3 local o GPT-4o API. Evaluación: RAGAS (faithfulness, relevancy).
- Agente LLM con herramientas para automatizar búsquedas bibliográficas académicas — Integración con Semantic Scholar API y Zotero. Evaluación de precisión vs búsqueda manual.
- Detección de alucinaciones en respuestas de LLMs mediante verificación factual automatizada — Pipeline de fact-checking con NLI (Natural Language Inference).
- LLM local (Ollama + Mistral/Llama 3) vs API comercial en tareas de programación: benchmark reproducible
- Generación automática de casos de prueba unitarios con LLM: evaluación con proyectos open source
Visión computacional y multimodal
- Detección de enfermedades en plantas mediante visión computacional con YOLOv10 y dataset PlantVillage
- Sistema de reconocimiento facial con privacidad diferencial: implementación y evaluación
- Clasificación automática de gestos para interfaces accesibles con MediaPipe y LSTM
- Detección de deepfakes en video con modelos temporales (TimeSformer, VideoMAE)
Robótica y sistemas embebidos
- Robot de navegación autónoma en entorno interior con ROS2 Humble y LiDAR 2D — Simulación en Gazebo + deploy en TurtleBot3 o Raspberry Pi + RPLiDAR.
- Integración de LLM en ROS2 para control de robot mediante comandos en lenguaje natural — Basado en el paper ROS-LLM (2024), adaptado a hardware universitario.
- Sistema de monitorización IoT de calidad del aire con ESP32, InfluxDB y Grafana
Ciberseguridad y privacidad
- Detección de intrusiones en redes con aprendizaje automático: benchmark sobre CIC-IDS-2017/2018
- Análisis de privacidad en aplicaciones Android: herramienta automática de detección de datos personales en APIs
- Implementación y evaluación de privacidad diferencial en modelos de ML federado
Desarrollo web, móvil y cloud
- Plataforma de gamificación para aprendizaje de idiomas con Next.js, Supabase y análisis de progreso
- Sistema de recomendación de películas con filtrado colaborativo y explicabilidad (LIME/SHAP)
- Dashboard de análisis de redes sociales académicas con API de Bluesky/Mastodon y visualizaciones D3.js
- Infraestructura as Code para despliegue de modelos ML con Terraform y GitHub Actions
Bases de datos, sistemas y computación
- Compilador de un lenguaje de programación educativo para enseñanza de estructuras de datos
- Motor de búsqueda semántica sobre corpus de legislación española (BOE) con embeddings multilingüe
- Análisis de rendimiento de bases de datos vectoriales (Pinecone, Weaviate, pgvector) para aplicaciones RAG
- Sistema de gestión de dependencias y vulnerabilidades en proyectos Python con análisis estático
Accesibilidad y HCI
- Herramienta de auditoría automática de accesibilidad web (WCAG 2.2) con Playwright y análisis LLM
- Interfaz de comunicación aumentativa y alternativa (CAA) con pictogramas generados por IA
La defensa: qué pregunta el tribunal de Informática
El tribunal de TFG de Ingeniería Informática es técnico. Estas son las preguntas más frecuentes basadas en análisis de actas de defensa de EPS-UAM, ETSII-UPM y ETSIINF-UPV de los cursos 2023-2025:
- «¿Por qué eligió esta arquitectura y no [alternativa obvia]?» — Debes tener preparada la justificación técnica (rendimiento, facilidad de mantenimiento, curva de aprendizaje, disponibilidad de recursos).
- «¿Cómo escalaría este sistema a 10x el volumen actual?» — El tribunal valora que hayas pensado en limitaciones y trabajo futuro, no solo en el happy path.
- «¿Qué haría diferente si empezara de nuevo?» — La autoconciencia técnica es una señal de madurez como ingeniero. Ten preparada una respuesta honesta.
- «¿Cómo verifica que sus resultados son reproducibles?» — El README del repositorio debe incluir instrucciones claras para reproducir los experimentos.
- «¿Cuál es la limitación principal de su sistema?» — Menciona una limitación real y cómo la abordarías en una siguiente versión.
Para preparar la presentación, consulta nuestro artículo sobre cómo preparar la defensa del TFG en videoconferencia. Si tu proyecto tiene componentes de IA o código que explicar, también puede ayudarte la guía sobre los errores más comunes en TFG que suspenden.
Y si llegas con el tiempo justo, el artículo sobre plan de 30 días para la convocatoria de julio tiene un cronograma específico también para TFG técnicos.
Preguntas frecuentes sobre el TFG de Ingeniería Informática
¿Es obligatorio que el repositorio GitHub sea público en el TFG de Informática?
Depende de la escuela y del acuerdo con el tutor. En la mayoría de TFG de informática, el repositorio puede ser privado durante el desarrollo y hacerse público en el momento de la defensa. Si el proyecto tiene datos sensibles o propietarios, puede mantenerse privado pero el tribunal puede pedir acceso temporal. Consulta las normas de tu escuela y habla con tu tutor desde el inicio.
¿Cuántas páginas debe tener la memoria de un TFG de Informática?
El rango habitual en escuelas de informática españolas es de 50 a 100 páginas. La EPS-UAM recomienda entre 60 y 80 páginas. La ETSII-UPM no fija máximo pero el tribunal tiende a penalizar las memorias con padding (código fuente completo, pantallazos de configuración) más que las memorioas densas y bien redactadas. El código va en el repositorio, no en la memoria; solo incluye fragmentos relevantes para ilustrar decisiones de diseño.
¿Qué lenguaje de programación es más valorado en el TFG de Informática?
El tribunal valora la adecuación del lenguaje al problema, no la elección del lenguaje en sí. Python es el estándar para proyectos de IA/ML. JavaScript/TypeScript para desarrollo web. Rust, C++ o Go para sistemas. Java para proyectos empresariales. Usa el lenguaje que dominas mejor o el que mejor encaja con el problema; justifica la elección en la memoria.
¿Necesito usar LaTeX para la memoria o puedo usar Word?
En la mayoría de escuelas de informática, ambos son aceptables. LaTeX es el estándar en proyectos con ecuaciones matemáticas, código o tablas complejas, y produce un resultado más profesional para el estilo IEEE. Word es válido si la escuela lo acepta y lo usas correctamente. La EPS-UAM y la ETSII-UPM aceptan ambos formatos; cada una tiene plantilla propia en LaTeX y Word disponible en su web o repositorios GitHub.
¿Cuánto tiempo se necesita para hacer un TFG de Informática de calidad?
Para un proyecto de desarrollo con demo funcional, tests y memoria, el rango real es de 350-500 horas. Distribuidas en un semestre (18 semanas), equivale a unas 20-28 horas semanales. Si también estudias otras asignaturas, ajusta el alcance del proyecto a la baja: es mejor un sistema más pequeño pero bien terminado, testeado y documentado que un sistema ambicioso a medias.
¿Puedo usar APIs de pago (como OpenAI) en mi TFG de Informática?
Sí, pero debes gestionar los costes y la reproducibilidad. Si usas la API de OpenAI, ten en cuenta que el tribunal no puede reproducir exactamente tus resultados en el futuro (los modelos se actualizan). Documenta la versión del modelo usada (por ejemplo, gpt-4o-2024-11-20). Considera siempre una alternativa local (Ollama + Llama 3 o Mistral) para que el proyecto sea reproducible sin coste por parte de quien lo evalúe.
Escribe tu TFG o tesis con IA
Pasa de la teoría a tu documento terminado
Tesify estructura, redacta y formatea tu TFG, TFM o tesis en normas APA y Vancouver, con bibliografía automática y verificación antiplagio integrada. Regístrate gratis, sin tarjeta.
Leave a Reply