¿Qué lleva el anteproyecto de un TFG de Ingeniería Informática? Estructura y ejemplo completo (2026)

El anteproyecto de un TFG de Ingeniería Informática se diferencia del de otras disciplinas en un punto clave: tiene que demostrar viabilidad técnica, no solo viabilidad académica. Un tribunal de Informática no solo evalúa si tu tema tiene bibliografía suficiente, sino si el sistema, la aplicación o el algoritmo que propones se puede construir realmente en el tiempo disponible con las tecnologías que planteas. Esta guía repasa qué lleva el anteproyecto, con un ejemplo completo resuelto al final, cómo justificar tu stack tecnológico y los errores que un tutor técnico detecta primero al revisarlo.

Qué apartados lleva el anteproyecto

Un anteproyecto de Ingeniería Informática, aunque el formato exacto varía por facultad, suele cubrir seis bloques:

1. Título provisional y contexto del problema. Qué problema técnico o de gestión resuelve el sistema que propones, y por qué es relevante.
2. Objetivos. Un objetivo general (qué vas a construir o demostrar) y objetivos específicos medibles (funcionalidades concretas, métricas de rendimiento a alcanzar).
3. Estado del arte preliminar. Qué soluciones existentes ya abordan un problema similar, y en qué se diferencia tu propuesta de ellas.
4. Alcance técnico y arquitectura prevista. Qué tecnologías, lenguajes y arquitectura vas a usar, con una justificación breve de por qué esas y no otras.
5. Metodología de desarrollo. Si vas a seguir una metodología ágil, en cascada, o un proceso propio, y cómo vas a validar el resultado (tests, evaluación de usabilidad, benchmarks de rendimiento).
6. Cronograma provisional. Hitos de desarrollo con fechas aproximadas, alineados con los sprints o fases que hayas previsto.

La diferencia clave: viabilidad técnica frente a viabilidad académica

En la mayoría de las disciplinas, la viabilidad de un anteproyecto se valora sobre todo por el acceso a datos o a participantes. En Ingeniería Informática, el riesgo principal es distinto: sobreestimar lo que se puede construir en el tiempo disponible. Es habitual que un anteproyecto proponga un sistema con demasiadas funcionalidades, sin priorizar cuáles son el núcleo mínimo viable y cuáles son extensiones opcionales si sobra tiempo. Un buen anteproyecto de Informática distingue explícitamente entre el alcance mínimo garantizado y las funcionalidades adicionales deseables, de forma que el proyecto siga siendo defendible aunque no dé tiempo a implementarlas todas. Esta distinción también protege al estudiante de un problema muy concreto: llegar a la fecha de entrega con un sistema a medio terminar porque el anteproyecto nunca fijó qué era realmente imprescindible frente a lo que era deseable.

Ejemplo completo de anteproyecto resuelto

Título provisional: Sistema de recomendación de rutas de estudio personalizadas mediante aprendizaje automático para una plataforma educativa.

Contexto del problema: Las plataformas educativas online generan grandes volúmenes de datos de interacción del alumnado que rara vez se aprovechan para personalizar la secuencia de contenidos recomendada, lo que deja sobre la mesa una oportunidad de mejora en la retención y el rendimiento del alumnado.

Objetivo general: Diseñar e implementar un sistema de recomendación de rutas de estudio personalizadas basado en el historial de interacción del alumnado.

Objetivos específicos: (1) Analizar y preparar un conjunto de datos de interacción de una plataforma educativa disponible; (2) implementar y comparar al menos dos algoritmos de recomendación; (3) evaluar el rendimiento de cada algoritmo con métricas estándar de sistemas de recomendación.

Estado del arte preliminar: Existen sistemas de recomendación aplicados a comercio electrónico y streaming ampliamente documentados; su aplicación a rutas de aprendizaje personalizadas en educación superior es un área activa pero con menos soluciones consolidadas, lo que justifica el interés del proyecto.

Alcance técnico: Python con librerías estándar de aprendizaje automático para el motor de recomendación; una interfaz web mínima para visualizar las recomendaciones, sin llegar a un despliegue en producción real.

Metodología: Desarrollo iterativo en sprints de dos semanas, con una fase inicial de preparación de datos, una fase de implementación de algoritmos y una fase final de evaluación comparativa.

Alcance mínimo garantizado: Un algoritmo de recomendación funcional evaluado con métricas estándar. Extensión deseable si hay tiempo: un segundo algoritmo de comparación y una interfaz web más pulida.

Ejemplo ilustrativo: un alcance mal delimitado y cómo corregirlo

El siguiente contraste es ilustrativo y ficticio, construido solo para mostrar el tipo de corrección que un tutor técnico suele pedir en la primera revisión del anteproyecto. Un estudiante plantea, para el mismo sistema de recomendación del ejemplo anterior, este alcance técnico inicial: «la plataforma permitirá a los alumnos ver sus rutas recomendadas, comparar su progreso con el de otros usuarios, recibir notificaciones automáticas, chatear con un tutor virtual y exportar informes en PDF». Cinco funcionalidades distintas, ninguna priorizada, sin distinguir cuál depende de cuál.

La versión corregida no elimina la ambición del proyecto, la ordena: el alcance mínimo garantizado queda en «el alumno ve su ruta recomendada y puede marcar contenidos como completados», porque es la única funcionalidad imprescindible para responder a la pregunta de investigación del anteproyecto (qué algoritmo recomienda mejor). Las notificaciones, el chat con tutor virtual y la exportación de informes pasan a la lista de extensiones opcionales, explícitamente etiquetadas como tal, y la comparación de progreso entre usuarios se descarta directamente por plantear cuestiones de privacidad que excederían el tiempo disponible para resolverlas con el rigor necesario. Este mismo ejercicio de separar «lo que responde a la pregunta de investigación» de «lo que sería bonito tener» es el que conviene aplicar a cualquier anteproyecto antes de presentarlo al tutor.

Cómo justificar la arquitectura y las tecnologías elegidas

Un error frecuente en los anteproyectos de Informática es listar tecnologías sin justificar por qué se han elegido frente a alternativas razonables. No basta con decir «usaré Python y una base de datos SQL» — conviene explicar brevemente por qué esa elección encaja con el problema (por ejemplo, la disponibilidad de librerías de aprendizaje automático maduras en Python, o la necesidad de relaciones estructuradas que justifica una base de datos SQL frente a una NoSQL). Esta justificación no necesita ser extensa en el anteproyecto, pero su ausencia total es algo que un tutor técnico suele señalar al revisarlo. Si tu TFG se plantea como un proyecto software que se evalúa como tal, la guía sobre TFG de tipo proyecto software: cuándo se acepta y qué exige la memoria desarrolla qué espera el tribunal más allá de que el sistema funcione.

Cómo distinguir tu anteproyecto de un simple proyecto de programación

Un anteproyecto de TFG no es lo mismo que un briefing de proyecto profesional, aunque se parezcan en estructura. La diferencia que un tribunal académico busca es la aportación: no basta con construir un sistema que funciona, hace falta identificar qué pregunta técnica o de investigación responde el proyecto, y cómo vas a demostrarlo con evidencia (comparativas de rendimiento, evaluación de usuarios, análisis de complejidad). Un anteproyecto que solo describe funcionalidades («la aplicación permitirá hacer X, Y y Z») sin plantear ninguna pregunta que el desarrollo vaya a responder corre el riesgo de leerse como un encargo de desarrollo de software, no como un trabajo académico. Añadir una pregunta de investigación explícita — por ejemplo, «¿qué algoritmo de recomendación ofrece mejor precisión con un conjunto de datos educativo de tamaño reducido?» — convierte el proyecto en algo evaluable académicamente, no solo funcionalmente.

Qué hacer con el estado del arte del anteproyecto una vez avanza el TFG

El estado del arte preliminar del anteproyecto no tiene que ser exhaustivo, pero sí debe evolucionar durante el desarrollo del TFG hacia una revisión más completa que sitúe tu contribución frente a las soluciones existentes con precisión. Cuando llegues a la fase de redacción del resumen final, la guía sobre cómo se escribe el resumen y las palabras clave de un TFG de Ingeniería Informática explica la convención problema-método-resultados-contribución y el sistema de clasificación ACM CCS que conviene tener presente desde el anteproyecto, porque ayuda a delimitar con precisión en qué área técnica se sitúa tu trabajo. Si además usas Tesify para documentar tu código y estructurar la memoria técnica, la guía sobre cómo usar Tesify para el TFG de Ingeniería Informática muestra el flujo de trabajo paso a paso desde el repositorio hasta el documento final.

Errores frecuentes en el anteproyecto de Informática

• Proponer un sistema demasiado ambicioso sin distinguir alcance mínimo de extensiones opcionales. Es una causa habitual de que un TFG de Informática llegue incompleto a la entrega.
• No justificar la elección de tecnologías. Listar un stack sin explicar por qué encaja con el problema deja al tribunal sin poder valorar el criterio técnico del planteamiento.
• Confundir estado del arte con una lista de herramientas existentes. El estado del arte debe situar tu contribución frente a soluciones similares, no limitarse a enumerar productos comerciales.
• No prever cómo se va a evaluar el resultado. Un sistema sin métricas de evaluación previstas desde el anteproyecto (rendimiento, usabilidad, precisión) es difícil de defender como una aportación académica, no solo técnica.
• No incluir una pregunta de investigación. Sin ella, el anteproyecto se lee como un encargo de desarrollo, no como un trabajo académico evaluable.

Checklist antes de presentar el anteproyecto al tutor

• Los seis apartados (contexto, objetivos, estado del arte, alcance técnico, metodología, cronograma) están todos presentes.
• El alcance mínimo garantizado y las extensiones opcionales están claramente diferenciados.
• Cada tecnología elegida tiene una línea de justificación, no solo el nombre.
• Hay al menos una pregunta de investigación explícita, no solo una lista de funcionalidades.
• El cronograma refleja sprints o fases realistas, con margen para imprevistos técnicos.

Cómo te ayuda Tesify

Tesify no diseña tu arquitectura ni escribe tu código — eso depende de tus decisiones técnicas. Lo que sí hace es ayudarte a estructurar el anteproyecto con los seis apartados que espera un tribunal de Informática, a redactar la justificación de tu stack tecnológico con claridad, y a mantener la coherencia entre lo que planteas en el anteproyecto y lo que finalmente documentas en la memoria.

Estructura el anteproyecto de tu TFG de Ingeniería Informática con Tesify

Preguntas frecuentes

¿El anteproyecto de Informática necesita código ya escrito?

No, el anteproyecto es una propuesta de lo que vas a construir, no el desarrollo en sí; algunas facultades valoran positivamente un prototipo mínimo o una prueba de concepto, pero no suele ser obligatorio.

¿Puedo cambiar de tecnología a mitad del desarrollo si la elegida no funciona bien?

Sí, y es preferible documentarlo honestamente en la memoria final como una decisión de diseño justificada, en lugar de ocultar el cambio; un tribunal valora más la capacidad de adaptar el proyecto ante un problema técnico real que un plan inicial seguido a ciegas.

¿Qué pasa si mi TFG usa datos de una fuente que luego deja de estar disponible?

Conviene tener siempre un plan alternativo de fuente de datos desde el anteproyecto, especialmente si dependes de una API externa o un dataset de terceros que puede cambiar sus condiciones de acceso durante el desarrollo del TFG.

¿Necesito incluir diagramas de arquitectura en el anteproyecto?

No es obligatorio en todas las facultades, pero un diagrama de alto nivel (componentes principales y cómo se comunican) ayuda al tutor a valorar rápidamente la coherencia técnica de la propuesta, incluso en una versión preliminar y simplificada.

¿Cómo delimito el alcance mínimo garantizado si no sé cuánto tiempo me llevará cada parte?

Estima de forma conservadora, dando más tiempo del que crees necesario a la parte más incierta técnicamente (normalmente la que usa una tecnología con la que tienes menos experiencia previa), y deja las funcionalidades que dependen de que todo lo anterior salga bien como extensiones opcionales, no como parte del alcance mínimo.

¿Qué diferencia hay entre un TFG de investigación y un TFG de proyecto software en Informática?

Un TFG de investigación aporta conocimiento nuevo sobre un problema (por ejemplo, comparar algoritmos), mientras que un TFG de proyecto software aporta un sistema funcional con valor de aplicación; ambos necesitan una pregunta o un criterio de evaluación claro, pero el peso relativo entre desarrollo y análisis cambia según cuál elijas.

¿Debo incluir un análisis de riesgos técnicos en el anteproyecto?

No siempre es obligatorio, pero identificar por adelantado uno o dos riesgos técnicos previsibles (por ejemplo, la disponibilidad de un dataset o la curva de aprendizaje de una tecnología nueva) y cómo los mitigarías fortalece mucho la credibilidad del anteproyecto ante el tutor.