Este documento contiene guías e ideas generales (no reglas fijas) para estructurar el trabajo de fin de grado. Es fundamental tener en cuenta que la memoria va a ser la primera impresión (y, junto con la presentación, la más relevante), y que el tribunal se la mirará con detalle.
A pesar de que las diferentes partes (trabajo, presentación y defensa) tienen baremado su peso en la nota final, la memoria es realmente el resultado más relevante. Es lo que va a dejar claro si un TFG es bueno o no. La calidad de la memoria y la presentación es esencial para la evaluación del TFG.
Hacer la memoria cuesta bastante esfuerzo. Suele ser la primera vez que escribís un documento técnico de esta envergadura y rigor y hay que empezar pronto y darle muchas vueltas y revisiones.
Lo primero es leerse la normativa del TFG del año que nos toca y mirar el calendario. Siempre hay información relevante, y veréis:
- Los plazos de entrega. De estos, el llamado “Entrega de la memoria final y de la autorización de difusión” es la fecha final en la que ya no se pueden hacer más cambios (a finales de mayo).
- Hay una “Entrega del borrador del proyecto al director” pero esa no es importante y podéis ignorarla, debería haber un borrador alrededor de finales de abril.
- Que hay que hacer una parte en inglés.
- Hay que declarar la contribución de cada uno de los miembros, explicitando qué ha hecho cada uno. Se puede poner notas distintas a los miembros del grupo (aunque no es raro que se ponga la misma a todos).
Seguid los criterios estéticos de las memorias anteriores, con la portada correcta y demás. Tiene que quedar muy bien maquetado. LaTeX lo deja muy bien, podéis usar Overleaf para colaborar. Si no queréis usar LaTeX, la siguiente mejor alternativa es Office 365 (tenéis acceso con la cuenta UCM), y además os permite usar Word de escritorio sincronizado con la nube. En tercera posición, Google Docs.
La bibliografía es fundamental. Hay que procurar no citar páginas web, sino artículos científicos y libros (las páginas desaparecen, el material académica está conservado y, en general, revisado por expertos). Gestionar una bibliografía es un poco aburrido pero con un gestor como Zotero es más fácil. Google Docs y Office 365 tienen un plug-in para Zotero, aunque con Word de escritorio también podéis gestionar la bibliografía.
En LaTeX, con BibTeX, se hace de una manera más texto pero bastante potente.
Hay 5 partes importantes que todo trabajo académico (no solo la memoria del TFG) tiene que contemplar. Lo normal es estructurar el documento de forma que estas partes se correspondan con los capítulos:
Unos pocos párrafos que sirvan para que alguien no tenga ni idea de lo que se está leyendo sepa: cuál es el problema que se quiere resolver, cómo se ha resuelto y cuáles han sido los resultados más importantes. Algo siguiendo estas ideas, pero más largo y detallado:
- El estado actual de la tecnología es
$X$ . - Sin embargo, la tecnología aún no hace
$Y$ . - Usando
$Z$ , hemos hecho un sistema que hace$Y$ . - Lo hemos montado y evaluado, con resultados
$R$ .
Poned las keywords. Intentad ordenarlas por relevancia, y que sean palabras clave que la gente suela buscar.
Es útil empezar a escribir contando de forma general el estado de la ciencia o la técnica en un punto dado, e introduciendo el problema general por el que se trabaja. Es decir, antes de ir a las subsecciones, escribir unos párrafos describiendo un poco con detalle el estado actual del problema o la tecnología. Con seriedad, pero no con un detalle total de cada cosa, ya que eso va en el siguiente capítulo.
La motivación es la razón técnica por la que se lleva a cabo un desarrollo. La motivación describe por qué se hace el trabajo (por ejemplo, se quiere mejorar la identificación automática de personas por la imagen de su cara) y por qué se intenta, en particular, la solución que se propone.
Es decir, hacéis el trabajo por un motivo, porque vale para algo, y porque la tecnología lo permite. Por ejemplo: “el hecho de que los videojuegos sean tan computacionalmente costosos motiva hacer esta investigación, basada en reducir el coste energético de cada ciclo de juego”.
En ningún caso es vuestra motivación personal. Las razones por las que se hace un TFG, en cuanto a la memoria se refiere, son las del contexto social, económico, etc., nunca porque os interese aprender una tecnología u os apasione un campo. No hay nada de malo en ello (al contrario), pero no se pone aquí.
La hipótesis de partida son las ideas que aún no sabemos si son ciertas, pero vamos a trabajar para demostrarlas. Por ejemplo, que usando números primos la identificación de caras será más efectiva.
Una hipótesis bien escrita es una frase enunciativa clara:
Nuestro trabajo se inicia con la hipótesis de que si ponemos 10 de vida a todos los enemigos, los jugadores disfrutarán más.
Luego, con la implementación y las pruebas, probaréis (o no) que la hipótesis es cierta (o no).
Una lista concreta de cosas que se quieren conseguir. Muchas veces ayudará hacerlo como una lista con topos:
- Descubrir los números primos que acaben en 7
- Implementar un algoritmo que descubra las caras que se parecen a 7
- Hacer un experimento con caras reales
Un estilo que suele funcionar bien es poner 2 o 3 objetivos generales de alto nivel (conseguir
Scrum, GitHub, Discord… explicad sobre qué plataformas de desarrollo elaboráis el proyecto.
Explicad un poco el método de trabajo: ágil, reuniones semanales, revisiones de código en GitHub…
Una manera sencilla es coger los Objetivos y, uno por uno, ponerles una fecha aproximada (en slots como mucho de “1ª semana de noviembre”, aunque puede ser incluso “durante diciembre”). En una tabla, ideal.
Este plan de cómo se van a repartir los recursos y el tiempo queda también muy bien con un diagrama de Gantt, aunque no tiene que ser tan técnico.
Esto es más una costumbre, pero ayuda. Algo del estilo de: “En el capítulo 2 se estudiará el estado del arte. En el 3, 4 y 5 se describe la propuesta basada en números primos…”
Una parte lenta de hacer, pero muy importante. En esta parte se describe todo el trabajo sobre el que se construye nuestra propuesta. Tiene que tener muchas citas, y esas citas son idealmente artículos y libros técnicos y científicos. Solo en el caso de citar algo que no esté como publicación clásica (un videojuego) se permite no ser tan riguroso.
Aquí hay que hacer una revisión general de todo lo que se parezca a nuestro trabajo.
Aquí se describen los puntos importante de las tecnologías que usamos, si es que hay algo interesante: librerías, algoritmos, plataformas… No hay que poner imágenes con los logos ni contar cosas triviales (no hay que explicar qué navegador de Internet usamos, a no ser que el proyecto vaya de eso). No hay que describir git ni scrum, eso se resuelve en la parte de Metodología.
Esta parte puede ser un solo capítulo, aunque pueden (y suelen) ser más, dependiendo de lo que se cuente. Es donde se explica lo que se ha hecho, la arquitectura, pruebas, experimentos, resultados… Idealmente, primero lo general y finalmente los resultados.
Una cosa muy normal es tener varios capítulos aquí. Por ejemplo:
- Diseño computacional del sistema de identificación de fresas en un campo
- Arquitectura cliente servidor para comunicar identificación de fresas
- Implementación del sistema de identificación de fresas
Un capítulo en el que contéis cómo habéis evaluado el sistema. Empezad el capítulo esbozando la idea, y luego, por secciones, detalláis.
Qué hacéis para evaluar, cómo son los cuestionarios.
Qué experimentos se han hecho, cuántos usuarios, donde, etc.
Poner tablas, gráficas y números. Sin opinar de momento, solo decir lo que sale
Basándoos en la sección anterior, explicar qué significa que hayan salido esos datos (sobre todo en función de la hipótesis inicial), y si la validad o la rechazan. Es muy normal que ni una cosa ni la otra, pero los datos deberían dar indicios en uno u otro sentido, cosa que se dice claramente.
Es un capítulo que discute, desde el punto de vista técnico, las ventajas y limitaciones de nuestro trabajo. No hay inconveniente por admitir explícitamente las limitaciones, sobre todo si esas limitaciones no las ha superado nadie. No hay que dejarse nada, todo lo que no se discuta será discutido por el tribunal, y eso suele ser peor.
El capítulo final es bastante esquemático. Se empieza con algo parecido al abstract, pero centrándose más en los resultados. Puede parecer redundante, porque lo es, pero se espera que se cuente aquí. Después se habla de lo que se podría hacer a partir de aquí, basándose en los resultados o en el producto de la implementación.
- Nadie se lee la memoria como un cuento, de arriba a abajo. Se lee el abstract, las conclusiones, luego el índice, luego se busca una cosa concreta… Se lee más como un manual para enterarse de qué se ha hecho que como un libro. Por eso todo tiene que estar autocontenido y ser muy claro. El estilo literario es bonito, pero si sacrificáis claridad por esto el tribunal lo evaluará da forma negativa.
- Dejad claro siempre lo que estáis haciendo. Desde el principio, idealmente desde el título, quien se lea la memoria tiene que saber qué está leyendo. No tengáis miedo de insistir en “como hemos comentado, el objetivo general del trabajo es …”.
- Todas las imágenes y figuras tienen que ser útiles (nada de logos). Las imágenes tienen que ser el resultado de vuestro trabajo, o figuras de datos (gráficas), o figuras de trabajos relacionados. Nada de dibujos “para decorar”.
- Todas las imágenes, figuras, tablas y demás tienen que estar numeradas con esquema (Tabla 2.5), y tener un pie que describa perfectamente lo que se ve.
- Los títulos de capítulos, secciones y subsecciones tienen que ser descriptivos, no atractivos (aunque si se consiguen ambas cosas, mejor). Es normal que queden largos, pero ayuda mucho. Si en el índice aparece un título que es “Implementación” y hay 4 módulos en el sistema, no sabré de qué modulo se habla. Mucho mejor “Implementación del motor de diálogo y su conexión con el motor 3D”.
- No se escribe en “personal”. No se ponen nada como “hemos aprendido mucho”, es un documento técnico. Para referirse a uno mismo, las fórmulas clásicas son usar la primera persona del plural (“hemos llevado a cabo”), o el impersonal (“se ha llevado a cabo”).
- Dentro de lo razonable, repetir cosas en varios sitios no es necesariamente malo. Es muy raro que alguien se lea un documento técnico como se lee una novela, se va por secciones, se cambia de capítulo… Aunque no hay que exagerar esto, hay que asumir que mucha gente se leerá las conclusiones casi lo primero. Recordad siempre cuál es el objetivo general e id hilando el discurso de forma que quede claro y que alguien que llega “de golpe” a un capítulo pueda entender qué está leyendo.
- Poned títulos de capítulos y secciones largos y descriptivos. No pongáis “contribución” o “prototipo”. Poned “Desarrollo del sistema inteligente para hacer palomitas” o “Detalle de modelo computacional del primer prototipo”.
- No tengáis miedo de repetir contenido, siempre que esté justificado que lo hagáis. No es una novela, es un documento técnico que nadie se lee de arriba a abajo, por eso tantos índices y referencias son necesarios.
- No hagáis referencias a “este TFG”. Es un trabajo técnico, no un log.
- Imágenes y figuras
- Siempre con licencia si no son vuestras, y citando el origen.
- Siempre con un pie de figura largo y descriptivo.
- El texto del pie acaba en punto.
De forma aproximada, fechas realistas para la planificación son:
- 1 de noviembre: tener ya muy claro lo que se va a hacer: qué, cómo y cómo se va a evaluar.
- 1 de enero: primer prototipo con todo (aunque no esté terminado).
- 1 de marzo: código “terminado” y plantear la evaluación.
- 1 de abril: código terminado y empezar a evaluar (tened en cuenta que en mayo ya no hay gente en la Facultad).
- 1 de mayo: primer borrador de la memoria.
- 15 de mayo: borrador completo de la memoria.
- 20 de mayo: versión entregable de la memoria.
Se han escrito ya muchos TFGs, y es muy útil que leáis TFGs ya escritos para ver cómo se hacen. La UCM publica todos los TFG, y son de libre acceso. Principalmente de la Facultad de Informática (porque siguen la normativa, sobre todo los del año anterior), pero cualquier lectura es buena. Aunque no sea lo más divertido del mundo leer trabajos de otros, intentad echar un vistazo a ejemplos (por ejemplo, de compañeros vuestros que ya hayan terminado).
Es fundamental ver otros trabajos bien escritos para que todas estas explicaciones tengan más sentido y para que entendáis mejor lo que hay que hacer. Algunos ejemplos:
- Análisis de emociones básicas mediante electroencefalografías y datos fisiológicos
- Generación procedimental de asentamientos humanos en mundos 3D
- Generación procedimental de ecosistemas y biomas y evolución inteligente de seres vivos en entornos naturales
- MMOTFG: Massively Multiplayer Online Telegram Fantasy Game
- Recomendador inteligente de vestimenta
- Realidad aumentada para el Museo de América
- Sistema de matchmaking para un videojuego multijugador
- Automatic detection of flashing video content in videogames (en inglés)
- Automatic validation of accesibility guidelines in videogames (en inglés)
- Plugin de Blender para exportación de materiales a Unity
En última instancia, una memoria técnica es un ejercicio de comunicación. Se escribe para que alguien, en 1 hora, sepa todo lo relevante que ha ocurrido durante todo un año de trabajo. Filtrar, condensar, explicar bien las causas y las decisiones, y estructurar de forma que el lector tenga que emplear poco esfuerzo para entender, es fundamental.
Empezad a escribir cuanto antes. Cuesta mucho esfuerzo, y en general se tiene poca práctica. Lo ideal es mandar muchas versiones al principio para que, muy pronto, la estructura coja forma y se corrijan, cuanto antes, los defectos básicos.
Otra cosa importante es que cada cita, artículo, libro o idea que se encuentre se vaya añadiendo a un documento para que no se pierda información.
La presentación sigue un esquema muy parecido al de la memoria. Básicamente, lo que hay que hacer es contar todo en muy poco tiempo, y por supuesto hacerlo de manera resumida, omitiendo los detalles y haciendo énfasis en qué se ha hecho, por qué, cómo se ha hecho y cuáles han sido los resultados.
De forma orientativa (y asumiendo que hay transparencias), la presentación podría seguir un esquema así:
- Diapositiva con el título, autores, etc. Aquí se debería presentar (de palabra) lo que se ha hecho en 1 o 2 frases.
- Motivación: por qué se ha hecho esto. Se vuelve al principio (ya habíamos contado lo que hemos hecho), pero ayuda a entenderlo.
- Hipótesis: resumir la hipótesis, sobre todo para enlazar motivación y objetivos. La hipótesis es lo que asumís que será cierto para que vuestros objetivos sean realizables.
- Objetivos: los generales, lo que se quiere conseguir para mejorar el estado que da contexto a la motivación.
- Estado del arte muy breve, solo lo más relevante (1 diapositiva).
- Arquitectura general, descripción de alto nivel de toda la solución.
- Detalles de cada parte, en las diapositivas que se necesiten.
- Experimentos y pruebas, qué se ha hecho para probar.
- Resultados, qué ha salido de los experimentos.
- Conclusiones: vistos los resultados, qué objetivos se han cumplido, y hasta qué punto se ha validado/reforzado la hipótesis.
- Contribuciones personales.
Generalmente cerca de la fecha de entrega de los TFGs, se confeccionan las sesiones de presentación (ejemplo 2023/2024). A veces, por necesidades de los recursos, puede haber modificaciones.
Es importante revisar esa página por si hay cambios.