TFG de tipo proyecto software en Ingeniería Informática: cuándo se acepta y qué exige la memoria

Has decidido que tu TFG de Ingeniería Informática sea construir una aplicación o un sistema en vez de una investigación tradicional con hipótesis y datos, pero te preocupa que «solo el código» no sea suficiente para el tribunal, o no sepas qué debe llevar la memoria cuando el trabajo principal ya está en el repositorio. El proyecto software es una modalidad de TFG plenamente aceptada en la mayoría de facultades de Informática, pero el tribunal no evalúa solo si el sistema funciona: evalúa si la memoria demuestra un proceso de ingeniería con decisiones justificadas, no solo un resultado que compila. Esta guía explica cuándo se acepta esta modalidad y qué debe incluir la memoria para que el código no se quede sin el respaldo académico que necesita.

¿Qué es un TFG de tipo proyecto software?

Es una modalidad de TFG en la que el estudiante diseña, implementa y evalúa un sistema informático completo o un componente significativo de software, en vez de plantear una pregunta de investigación que se responde con datos recolectados. Se diferencia de un TFG de investigación en que el «resultado» no es un hallazgo generalizable sino un artefacto funcional, y se diferencia de un simple ejercicio de programación en que exige un proceso documentado: análisis del problema, diseño justificado, implementación y evaluación de que el sistema cumple lo que se propuso resolver.

¿Cuándo se acepta este formato en Ingeniería Informática?

La práctica totalidad de facultades de Informática aceptan el proyecto software como modalidad de TFG, y en muchos programas es de hecho la modalidad más habitual, junto a la investigación aplicada. Lo que sí varía entre universidades es el nivel de complejidad mínimo exigido: la mayoría de reglamentos de TFG rechazan explícitamente un proyecto que se limite a seguir un tutorial o a integrar librerías existentes sin ningún componente de diseño propio, y esperan que el sistema resuelva un problema con cierta dificultad técnica —ya sea de arquitectura, de algoritmia, de escalabilidad o de integración entre componentes— que justifique el nivel de un trabajo de fin de grado. Confirma con tu tutor si tu propuesta tiene la complejidad suficiente antes de empezar a implementar, porque es más fácil ajustar el alcance en la fase de propuesta que después de haber invertido meses de desarrollo.

¿Qué debe incluir la memoria más allá del código?

• Análisis del problema y de requisitos: qué problema resuelve el sistema, para quién, y los requisitos funcionales y no funcionales que debe cumplir, con la misma trazabilidad que un requisito de calidad exige en cualquier proyecto de ingeniería del software.
• Estado del arte o alternativas existentes: qué soluciones ya existen para ese problema (herramientas, librerías, sistemas comerciales) y por qué tu propuesta aporta algo distinto, aunque sea a menor escala; sin este apartado, el tribunal no puede evaluar si el proyecto es una aportación o una reimplementación de algo ya resuelto.
• Diseño de la arquitectura: los componentes del sistema, cómo se comunican, y las decisiones de diseño explicadas —no solo un diagrama, sino la justificación de por qué se eligió esa arquitectura y no una alternativa razonable.
• Decisiones tecnológicas justificadas: por qué se eligió cada tecnología, framework o base de datos concreta, con criterios explícitos (rendimiento, madurez del ecosistema, curva de aprendizaje del equipo, restricciones del entorno de despliegue), no solo «porque la conocía».
• Implementación: los aspectos técnicos más relevantes del desarrollo, con extractos de código solo cuando ilustran una decisión de diseño importante, no como relleno de páginas.
• Evaluación y pruebas: cómo se verificó que el sistema cumple los requisitos planteados, con evidencia concreta, no solo la afirmación de que «funciona correctamente».
• Conclusiones y trabajo futuro: qué se logró, qué limitaciones tiene el sistema y qué líneas de mejora quedan abiertas.

Si tu proyecto se apoya en integración continua, control de versiones y una memoria técnica con formato de publicación científica, la guía sobre TFG de Ingeniería Informática con GitHub Actions y memoria en estilo IEEE profundiza en cómo estructurar el repositorio y la memoria siguiendo ese formato concreto.

¿Qué metodología de desarrollo se declara en la memoria?

Igual que un TFG de investigación declara su metodología de recolección de datos, un TFG de proyecto software debe declarar su metodología de desarrollo: si siguió un enfoque ágil (Scrum, Kanban) con iteraciones documentadas, o un enfoque más tradicional en cascada con fases secuenciales de análisis, diseño, implementación y pruebas. Declarar la metodología no es un trámite formal: el tribunal la usa para entender cómo evolucionó el proyecto y para contextualizar decisiones que cambiaron a mitad de camino, algo especialmente relevante si usaste un enfoque ágil donde los requisitos se refinan iterativamente en vez de fijarse por completo al inicio.

¿Cómo se demuestra aportación académica en un proyecto software?

La aportación no está en que el sistema «funcione» —eso es una condición necesaria pero no suficiente— sino en las decisiones de ingeniería que tomaste y en cómo las justificas frente a alternativas razonables. Un TFG que documenta por qué se descartó una arquitectura de microservicios en favor de un monolito modular, con los criterios concretos que llevaron a esa decisión (tamaño del equipo, complejidad operativa, alcance del proyecto), demuestra más criterio de ingeniería que uno que simplemente construye el sistema sin explicar las alternativas consideradas. Si tu proyecto resuelve un problema con cierta originalidad técnica —un algoritmo propio, una optimización de rendimiento medida y comparada, una arquitectura adaptada a una restricción específica del contexto—, ese es precisamente el punto donde el tribunal reconoce la aportación del trabajo, más allá del resultado funcional.

¿Qué se exige en la fase de evaluación y pruebas?

Como mínimo, el tribunal espera evidencia de pruebas unitarias sobre los componentes críticos del sistema y de pruebas de integración que verifiquen que los componentes trabajan correctamente en conjunto, documentadas con su cobertura o sus resultados, no solo mencionadas de pasada. Si el sistema tiene interfaz de usuario, muchos programas también valoran positivamente una evaluación de usabilidad, aunque sea con un grupo pequeño de usuarios de prueba, porque demuestra que el proyecto se validó más allá del propio criterio del desarrollador. Si el proyecto plantea una mejora de rendimiento o de eficiencia como parte de su aportación, esa mejora debe medirse y compararse con una alternativa de referencia (el sistema anterior, una implementación ingenua, un benchmark estándar), no solo describirse cualitativamente.

Ejemplo resuelto: un sistema de recomendación para una plataforma de contenidos educativos

Problema: una plataforma educativa pequeña necesita recomendar contenidos relevantes a sus usuarios sin los recursos de cómputo de una gran plataforma comercial. Estado del arte: se revisan los enfoques de filtrado colaborativo y filtrado basado en contenido, y se documenta por qué el filtrado colaborativo puro no es viable dado el volumen bajo de interacciones de usuarios nuevos (el problema conocido como «arranque en frío»). Decisión de diseño: se opta por un sistema híbrido que combina filtrado basado en contenido para usuarios nuevos con filtrado colaborativo una vez que el usuario acumula suficientes interacciones, justificado explícitamente por ese problema de arranque en frío. Evaluación: se mide la precisión de las recomendaciones con un conjunto de datos de prueba separado del de entrenamiento, y se compara el enfoque híbrido contra cada enfoque puro por separado, mostrando en qué escenario cada uno rinde mejor. Las conclusiones reconocen que el sistema no se evaluó con usuarios reales en producción, solo con datos históricos, y proponen esa validación como trabajo futuro.

¿Cómo se defiende un TFG de proyecto software ante el tribunal?

Además de la presentación habitual de objetivos, metodología y conclusiones, la defensa de un TFG de proyecto software suele incluir una demostración en vivo del sistema funcionando. Prepara esa demo con un plan B: ten capturas de pantalla o un vídeo grabado de las funcionalidades clave por si falla la conexión a internet o el entorno de despliegue el día de la defensa, porque una demo que no puede ejecutarse en directo no debe dejar al tribunal sin ninguna evidencia visual del resultado. Espera preguntas técnicas específicas sobre las decisiones de arquitectura y sobre por qué no se adoptó un enfoque alternativo que el tribunal pueda considerar razonable; responder con los mismos criterios explícitos que documentaste en la memoria —no con una justificación improvisada— es lo que distingue una defensa sólida de una simple repetición de la presentación. Para los aspectos generales de la defensa —tiempos, estructura de la presentación y cómo manejar el turno de preguntas— la guía de 20 consejos para aprobar la defensa del TFG con nota complementa estas recomendaciones específicas de la demo técnica.

¿Qué error penaliza más el tribunal en un TFG de proyecto software?

Presentar el sistema como un producto terminado sin ninguna discusión crítica de sus propias limitaciones o de las alternativas de diseño descartadas. Un TFG que solo describe lo que se construyó, sin explicar por qué se construyó así y no de otra forma, funciona más como documentación de usuario que como memoria académica. El tribunal espera ver el razonamiento de ingeniería detrás de cada decisión importante, incluidas las que no salieron como se esperaba: reconocer una limitación técnica y explicar por qué no se resolvió dentro del alcance del TFG demuestra más madurez que ocultarla. Si todavía estás eligiendo el tema de tu proyecto, la lista de 25 temas de TFG de Ingeniería Informática con proyectos software te da ideas de alcance y stack tecnológico según el área que te interese.

Checklist antes de entregar un TFG de tipo proyecto software

• La memoria incluye un apartado de estado del arte o alternativas existentes, no solo la descripción del sistema construido.
• Cada decisión de arquitectura y de tecnología está justificada con criterios explícitos, no solo mencionada.
• Existe evidencia documentada de pruebas unitarias y de integración, con resultados concretos.
• Si el proyecto plantea una mejora de rendimiento, esa mejora está medida y comparada con una alternativa de referencia.
• Las conclusiones reconocen las limitaciones del sistema con la misma claridad con la que se presentan sus logros.
• La metodología de desarrollo (ágil o en cascada) está declarada explícitamente en la memoria.
• Tienes un plan B (capturas o vídeo grabado) para la demo en vivo del día de la defensa.

Preguntas frecuentes

¿Puedo usar un framework o librería de terceros como base de mi proyecto software?

Sí, es habitual y esperado en la mayoría de proyectos; lo que el tribunal valora no es que hayas escrito cada línea de código desde cero, sino que la elección de esas herramientas esté justificada y que exista un componente de diseño o desarrollo propio significativo más allá de la simple integración de piezas ya construidas.

¿Necesito publicar el código en un repositorio público?

No es un requisito general, aunque muchas facultades sí piden acceso al repositorio (público o privado con permisos para el tribunal) como parte de la entrega, para poder revisar el historial de commits y verificar el proceso de desarrollo documentado en la memoria. Si finalmente publicas el repositorio, revisa también cómo citar software o código fuente en APA 7 para referenciar correctamente cualquier librería, dataset o herramienta externa que hayas usado en la memoria.

¿Un proyecto software necesita aprobación de un comité de ética?

Generalmente no, salvo que el sistema recolecte datos personales de usuarios reales durante su evaluación (por ejemplo, en una prueba de usabilidad con participantes), en cuyo caso aplican las mismas exigencias de consentimiento informado que en cualquier estudio con personas.

¿Qué pasa si mi sistema no llega a funcionar completamente como se planeó?

Un sistema parcialmente funcional puede ser un TFG perfectamente válido si la memoria documenta con honestidad qué se logró, qué no, y por qué —analizando las causas técnicas del problema—, porque el tribunal evalúa el proceso de ingeniería y el aprendizaje demostrado, no solo el resultado final terminado al cien por cien.

¿Puedo combinar un proyecto software con una pequeña investigación empírica dentro del mismo TFG?

Sí, y es habitual cuando el proyecto incluye una evaluación con usuarios o una comparación de rendimiento entre enfoques: esa parte puede tener un diseño metodológico más cercano al de una investigación, siempre que se mantenga proporcional al conjunto del trabajo y no desplace al desarrollo del sistema como eje central.

¿Qué pasa si la demo falla el día de la defensa?

Ten siempre un plan B preparado (vídeo grabado o capturas de pantalla de las funcionalidades clave), porque un fallo técnico en la demo en vivo no debería dejar al tribunal sin ninguna evidencia visual del sistema; la mayoría de tribunales entienden que un fallo puntual de conexión o de entorno no refleja necesariamente la calidad del trabajo, siempre que exista una alternativa preparada.

Con Tesify, tu memoria de proyecto software respalda cada decisión de diseño

Tesify te ayuda a estructurar la memoria de tu TFG de tipo proyecto software, a documentar el estado del arte y las decisiones de arquitectura, y a organizar la evaluación del sistema con la evidencia que el tribunal espera ver, más allá del código.