Este artículo pretende servir de guía para la realización de un Trabajo de Fin Grado (TFG) para el Grado en Ingeniería Informática (GII). Es responsabilidad del alumno asegurarse de que la información proporcionada aquí se corresponda con la actualmente vigente (y si lo deja de estar, agradecería un aviso), así como valorar con su tutor la adecuación de los planteamientos que aquí se recogen. Esto es especialmente importante en el curso 2024/25, en que ha cambiado el modelo de referencia para la memoria. Si sigues el presente documento para elaborar la tuya y se te ocurre alguna recomendación que creas importante compartir, te agradecería que me la hicieras llegar.
Lo primero que hay que tener presente es la normativa específica del título. Es mucha información, pero hay que leerla al menos una vez. Después de eso se puede trabajar mirando hacia ejemplos de trabajos buenos, y revisando de vez en cuando la normativa para ver qué están reflejando o qué carencias pueden tener. La información oficial de los TFG a nivel de Facultad actualizada está aquí. Más en particular, en Informática tenemos información más específica en la página de Diaweb sobre ello. Dentro de lo que se enlaza allí, lo más importante es la normativa del Consejo de Colegios de Ingeniería Informática, que constituye la referencia a considerar a partir del curso 2024/25. La guía del Departamento también es una referencia útil, pero debe tenerse en cuenta que la estructura allí planteada para el trabajo y sus anexos corresponde a un modelo anterior que ya no está vigente. Por último, se pueden ver algunos ejemplos del Grado con buena nota en el repositorio Gredos; teniendo también en cuenta que la estructura empleada por ellos puede no corresponderse con la que se debe seguir a partir del curso 2024/25.
Habitualmente los TFG del GII se centran en un desarrollo software que sirva para demostrar los conocimientos adquiridos durante la carrera, que, complementados con otros adquiridos en el desarrollo del mismo, dan lugar a un producto software que debe cumplir con los requisitos de la propuesta, y ser acorde a la dimensión del TFG en cuanto a asignatura (12 ECTS).
Estructura de los anexos
El objetivo general de la memoria es recoger los aspectos más importantes del desarrollo software, pero los artefactos completos del proceso de ingeniería se entregan en anexos, que conviene tener presentes desde el comienzo del desarrollo para recopilarlos debidamente.
Una forma de adaptar las recomendaciones de la Normativa del Colegio de Ingenieros (cf. apartado 1 en la misma) es la siguiente:
- Anexo 1: Especificaciones del sistema, donde tiene cabida todo lo relativo al proceso de ingeniería de requisitos, como los casos de uso y tablas de requisitos funcionales, no funcionales y de información; o los productos de otras metodologías como pueden ser las historias de usuario.
- Anexo 2: Análisis y diseño del sistema, para los productos de estas dos partes del proceso de ingeniería, como los modelos de dominio propios del análisis o todos aquellos del diseño, entre los que se encuentran: diagramas de clases (con posible atención a esquemas como MVC), diagramas de diseño procedimental (algoritmos, descripción de procedimientos propios...), diseño de interfaz, diseño de datos (diagrama relacional, entidad/relación...)
- Anexo 3: Estimación del tamaño y esfuerzo, incluyendo el análisis realizado al inicio del proyecto en que se estima el esfuerzo de su elaboración. Es importante referenciar adecuadamente la metodología empleada para la obtención de las métricas. También se ubicaría aquí la planificación temporal completa (habitualmente con digramas de Gantt), siendo interesante recoger tanto la planificación inicial para la misma como el resultado real.
- Anexo 4: Plan de seguridad, incluyendo todo lo relativo a las consideraciones tomadas para la construcción de un software seguro. Se puede hablar de las metodologías empleadas para detectar o prevenir posibles vulnerabilidades y para la protección de los datos, así como identificar las componentes del software en que esto es más crítico. También es conveniente exponer aquí los aspectos legales relevantes, citando las leyes o normativas que se deben guardar.
Es posible añadir más anexos sobre estos. Algunos habituales, al menos en el modelo anterior, son los siguientes:
- Anexo (5): Documentación técnica de programación. Lo ideal es integrarla en el propio desarrollo, en el formato propio de los lenguajes, y generarla al final con alguna herramienta [javadoc (Java), sphinx (python), doxygen (multilenguaje)...]. Esto es, este anexo debería, en buena medida, generarse, no escribirse.
- Anexo (6): Manual de usuario (incluyendo capturas, explicando el flujo de trabajo de la aplicación...).
En función de las metodologías empleadas, puede haber otros relevantes que merezca la pena incluir.
Una buena estrategia para empezar a trabajar puede ser ir volcando todo lo producido durante el desarrollo software sobre los anexos e ir tomando nota de las cosas más importantes, que tendrán su propia sección también en la memoria.
Estructura de la memoria
Una propuesta para la estructura de la memoria, atendiendo a las recomendaciones del Colegio de Ingenieros, es la siguiente:
- Introducción: Contar en un par de páginas de qué va el proyecto de forma global, quizá motivando que existe un problema que se quiere solucionar, qué posibles soluciones hay ya, y que carencias tienen que motivan la presente, haciendo ver así la importancia del proyecto. Conviene terminar presentando la estructura del resto de la memoria (y sus anexos).
- Objeto: Describir los objetivos de forma concreta y esquematizada. Deben ser coherentes con lo que aparece en la propuesta de TFG (pudiendo extenderlos). Debería poder evidenciarse el cumplimiento de los objetivos en el proyecto en las secciones posteriores de la memoria. También se puede hablar aquí de objetivos personales (aprender tecnologías o lenguajes, iniciarse en algún campo, construir un software completo/explotable...).
- Antecedentes: Contextualizar el marco en que se desarrolla el proyecto. Se puede presentar en primer lugar el ámbito del proyecto, incluyendo la explicación de aspectos teóricos o nociones del dominio del problema. Adicionalmente, si el proyecto se ubica en alguna empresa o en el marco de otro proyecto que lo engloba, también procede su presentación.
- Descripción de la situación actual: Describir las soluciones que ya existan para el problema tratado (análisis de la competencia) o el estado de la cuestión, teniendo presente que esto tiene que hacer ver el valor que proporciona en este contexto la solución elaborada.
- Normas y referencias: Enumerar y presentar brevemente las normas y referencias seguidas. No interesa desarrollar un contenido teórico generalista, sino especificar cuáles se han seguido, para lo que es muy conveniente recurrir a citas bibliográficas. Según la estructura recomendada se dividiría en "Métodos y herramientas" y en "Modelos, métricas y prototipos", para lo que se pueden considerar las siguientes propuestas:
- Métodos: Métodología seguida (Proceso unificado, Scrum, eXtreme Programming...) y otros métodos relevantes (como puede ser kanban, algún patrón de diseño especialmente relevante...).
- Herramientas: Software utilizado para el desarrollo. Se pueden intentar agrupar en categorías para hacer la estructura más comprensible.
- Modelos: Si se emplea algún modelo técnico se puede describir, incluyendo posibilidades como modelos de inteligencia artificial, modelos industriales, modelos electrónicos...
- Prototipos: Descripción de prototipos elaborados, desde mock-ups hasta prototipos funcionales.
- Métricas: Descripción de métricas de evaluación si procede, como pueden ser métricas de rendimiento, de desempeño de modelos de predicción, de éxito en pruebas de usuario...
- Definiciones y abreviaturas: Opcional, pero recomendable especialmente si algunas se repiten copiosamente. Puede ubicarse también al principio o al final de la memoria.
- Requisitos iniciales: Resumen de lo recogido más exhaustivamente en el anexo 1, centrado en lo más importante y referenciado dicho anexo para mayor detalle.
- Hipótesis y restricciones / Alcance: Algunas posibilidades para construir este apartado (escogiendo de los dos nombres el que se adecúe más) son:
- Presentar las restricciones del proyecto: hasta dónde se puede aplicar la solución construida, motivadas por los requisitos y justificadas adecuadamente.
- Presentar el impacto estimado del resultado: en qué medida podría esperarse que se adopte su uso.
- Analizar cómo podría cambiar el ámbito del problema como resultado del producto construido.
- Estudio de alternativas y viabilidad:
- Para el estudio de alternativas, se puede motivar el porqué de las decisiones tomadas durante del proceso (lenguajes de programación, frameworks, tecnologías para el despliegue...), comparando con otras opciones y justificando la escogida. Puede ser útil apoyarse en estudios comparativos existentes o en estadísticas de uso.
- Para el estudio de viabilidad se puede enfocar un análisis de la viabilidad económica del producto (costes, posible monetización...).
- Descripción de la solución propuesta: Presentar el producto sofware construido, para lo que se puede recurrir a diagramas relevantes, capturas de la aplicación, tablas de funcionalidad... El objetivo es que quede evidenciado el alcance de la aplicación. Es conveniente también incluir algún enlace a la aplicación (bien al despliegue web, a un sitio desde el que se puede descargar el instalador) o incluso a un vídeo de demostración si las otras opciones son complejas.
- Análisis de riesgos: En el desarrollo más común, orientado a usuarios, los riesgos a analizar pueden ser el riesgo de aceptación y el nivel de satisfacción con la implementación. En otros casos se puede analizar también el riesgo tecnológico (e.g., mi producto puede quedar obsoleto), y el de integración (con otras tecnologías o en el marco de un proyecto superior del que forme parte). Algunas metodologías que se pueden usar para este estudio son:
- Matriz de riesgos.
- Análisis DAFO/FODA.
- Descripción tabulada de riesgos: se les puede asignar un código identificador y dar su descripción, prioridad (3 niveles), complejidad (3 niveles) y posibles medidas correctoras o mitigadoras.
- Organización y gestión del proyecto: Dividida en esas dos subsecciones:
- Organización: aspectos como la arquitectura, el diseño de la base de datos o una descripción del proceso de desarrollo tienen cabida aquí. Debe observarse que guarda una buena relación con los anexos, de los que debe extraerse y sintetizarse la información más importante, referenciándolos para mayor detalle.
- Gestión del proyecto: se podría, igual que antes, resumir los aspectos de estimación del esfuerzo y de planificación temporal, intentando contraponer la estimación inicial con el caso real. (En la guía del Colegio de Ingenieros la planificación temporal aparece como independiente, pero puede ser más cabal para TFG ubicarlo aquí).
- Conclusiones y trabajo futuro: Presentar un resumen de lo que se ha logrado, que debería ser coherente con lo que aparece en la introducción y en la propuesta del proyecto. Se pueden incluir también propuestas de trabajo futuro.
- Bibliografía: Se debe ir recopilando desde el principio, a ser posible utilizando la funcionalidad del procesador de textos que se emplee (para Word, aquí).
Agradecimientos
Mucho de la correspondencia entre el "modelo clásico del Departamento" y el del Colegio de Ingenieros se basa en una síntesis que hizo mi compañera Alicia García Holgado. Si esta entrada te ha ayudado, ella también lo habrá hecho.