TFG de Ingeniería Informática: ejemplos, temas y método

Un TFG de Ingeniería Informática no consiste en desarrollar la mayor cantidad de funcionalidades posible. Consiste en demostrar un proceso de ingeniería: entender una necesidad, convertirla en requisitos, comparar decisiones, construir una solución y verificar qué cumple bajo condiciones explícitas.

La modalidad puede ser desarrollo, investigación, análisis de datos, infraestructura, seguridad, interacción, simulación o evaluación. La guía y la rúbrica de la escuela deciden entregables y peso de memoria, producto, gestión y defensa. No adopte una estructura genérica antes de leerlas.

Dónde ver ejemplos de TFG de Informática

Consulte repositorios institucionales como UPCommons de la UPC, RiuNet de la UPV, Archivo Digital de la UPM, e-Archivo de la UC3M u O2 de la UOC. La Facultad de Informática de Barcelona también publica el proceso de su TFG.

Filtre por titulación, modalidad y fecha. En cada ejemplo, registre problema, alcance, requisitos, arquitectura, artefactos, pruebas, reproducibilidad y límites. Una memoria antigua ayuda a estudiar razonamiento, pero no confirma que la tecnología, las amenazas o las reglas académicas sigan vigentes.

Elegir tema mediante alcance y evidencia

Aplicaciones web o móviles, aprendizaje automático, ciberseguridad, videojuegos, visualización, sistemas distribuidos, IoT o DevOps son áreas, no proyectos. Formule quién tiene el problema, qué tarea o propiedad se pretende mejorar, bajo qué restricciones y cómo se comprobará.

Defina un núcleo evaluable y separe mejoras opcionales. Puede usar una matriz con requisito, prioridad, criterio de aceptación, método de prueba y estado. Cuando el calendario se reduce, se recorta primero lo opcional sin perder la pregunta central. Un backlog grande no equivale a alcance académico.

Confirme pronto datos, hardware, APIs, licencias, cuentas y permisos. No base el TFG en un servicio cuya cuota o acceso no controla ni en datos personales que aún no está autorizado a tratar. Diseñe una alternativa reproducible con datos sintéticos o abiertos cuando sea posible.

Requisitos que puedan comprobarse

Distinga requisitos funcionales —qué comportamiento ofrece el sistema— y propiedades como rendimiento, seguridad, accesibilidad, mantenibilidad o privacidad. Evite «la aplicación será intuitiva y rápida» sin usuario, tarea, métrica ni umbral justificados.

La orientación de Software Engineering de ACM incluye requisitos, diseño, gestión, verificación, validación y pruebas entre las capacidades de ingeniería. No significa que cada TFG deba usar UML o un proceso concreto: seleccione artefactos que permitan explicar y evaluar su solución.

Registre cambios de alcance y razón. Si un requisito se descarta por tiempo, dependencia o riesgo, documentarlo muestra control del proyecto; ocultarlo hace que la memoria y el producto parezcan inconsistentes.

Arquitectura y decisiones técnicas

Explique componentes, responsabilidades, flujos de datos, límites de confianza y dependencias externas. Los diagramas deben responder preguntas, no decorar. Para cada decisión importante, describa alternativas consideradas, criterios, elección y consecuencias. «Se eligió React porque es moderno» no es suficiente; relacione experiencia, ecosistema, requisitos, despliegue y coste de cambio.

La implementación debe centrarse en fragmentos o mecanismos que acreditan una decisión. No vuelque archivos completos en la memoria. Enlace o adjunte el código según las reglas, indicando versión exacta o etiqueta asociada a la entrega.

Documente entorno, lenguaje, dependencias y configuración sin incluir secretos. Fije versiones y explique cómo instalar, ejecutar pruebas, cargar datos mínimos y reproducir la demo. Si existen elementos no redistribuibles, indique cómo se obtienen y qué parte puede evaluar el tribunal.

Datos e inteligencia artificial

Un proyecto de aprendizaje automático debe empezar por pregunta, unidad de análisis, origen de datos y criterio de evaluación, no por el modelo. Separe entrenamiento, validación y prueba evitando fugas. Describa limpieza, etiquetado, desbalance, métricas, línea base y variabilidad. Una métrica alta no demuestra utilidad fuera de la muestra ni ausencia de daño diferencial.

Revise licencias y términos de datasets y modelos. Si hay personas, trate privacidad, base o consentimiento aplicable, minimización y sesgos. Las herramientas generativas pueden ayudar solo según la política institucional; conserve trazabilidad, verifique cada salida y no entregue código que no pueda explicar.

Seguridad desde los requisitos

Modele activos, actores, superficies y amenazas pertinentes al alcance. El Application Security Verification Standard de OWASP ofrece requisitos verificables para aplicaciones web. Seleccione la versión y los controles relevantes; no declare que el sistema es «seguro» por ejecutar un escáner.

Proteja secretos, aplique mínimo privilegio y utilice datos de prueba. Las pruebas ofensivas deben realizarse únicamente en sistemas y entornos autorizados. Documente hallazgo, impacto, corrección y nueva verificación sin publicar detalles que expongan a terceros.

Diseñar un plan de pruebas útil

Cada prueba debe conectar con un requisito o riesgo. Combine niveles según el proyecto: unidades para lógica, integración para fronteras, sistema para flujos, aceptación para necesidades, rendimiento bajo carga definida, usabilidad con tareas y seguridad con controles seleccionados.

Registre entorno, precondiciones, datos, pasos o automatización, resultado esperado, resultado obtenido y evidencia. Informe también fallos y pruebas pendientes. Una cobertura elevada puede no comprobar casos límite; una demo exitosa no sustituye la repetibilidad.

Si compara tecnologías o algoritmos, mantenga condiciones equivalentes y repita cuando exista variabilidad. Publique configuración y semillas cuando proceda. Evite escoger después la métrica o escenario en el que su propuesta sale mejor.

La memoria como argumento de ingeniería

La estructura exacta puede variar, pero debe hacer visible la cadena entre problema, antecedentes, requisitos, diseño, implementación, evaluación y conclusión. Planificación y costes se incluyen si la guía los exige o si ayudan a evaluar viabilidad; no son apartados universales que deban rellenarse con cifras ficticias.

Los anexos pueden alojar manuales, especificaciones extensas, inventario de pruebas y detalles de despliegue. La memoria principal conserva decisiones y evidencia. Consulte nuestra guía de anexos para no separar material esencial de la argumentación.

Podemos ayudarle a revisar alcance, trazabilidad, pruebas y claridad de la memoria conservando su autoría técnica. No se debe externalizar un desarrollo que tendrá que ejecutar, explicar y defender como propio.

Fuentes consultadas

• Orientación curricular de Software Engineering de ACM
• OWASP Application Security Verification Standard
• Proceso de TFG de la Facultad de Informática de Barcelona
• UPCommons y RiuNet, repositorios universitarios de acceso abierto.