Tanto en los tribunales de trabajos fin de grado o máster (TFG/TFM, a partir de ahora sólo TF) en los que he participado me encuentro repitiendo, una y otra vez, las mismas reglas sobre lo que son o no son tanto los trabajos en sí, como la tutorización, como las presentaciones. El trasfondo es que, realmente, parece que nadie tiene claro lo que es o lo que debe de ser. En la mayor parte de los casos es irrelevante: los tribunales son soberanos, y la nota que va a obtener tiene poca relación no sólo con el trabajo realizado o su calidad, sino también con TFs de similar nivel corregidos en otros tribunales.
En todo caso, la nota obtenida es, en la mayor parte de los casos, irrelevante. Un TF es una asignatura, y cómo tal debería servir para que el estudiante aprenda; si, como debería ser, el trabajo es liberado (Merelo 2018), es un muestrario de las técnicas y habilidades que el estudiante ha sido capaz de desarrollar a lo largo del grado.
Dejemos de lado si ha sido capaz de desarrollarlas en él o a pesar de o aparte de él. Si es muestrario de habilidades, de dónde procedan esas habilidades es totalmente secundario.
Por eso voy a tratar de dar una serie de reglas para poder aprovechar, efectivamente, este grado para crecer en la ingeniería que se ha elegido y convertirse en mejor profesional. Dirigido principalmente al estudiante, pero también a quién le toque ser tutor o tutora de este tipo de trabajos.
En todo esto, soy totalmente consciente de que, en la mayor parte de los casos, un TF es un trámite molesto que necesitas para poder acceder a un grado que necesitas, sobre todo, por el título que conlleva, no por los conocimientos que te impartan. Muchos estudiantes están ya trabajando a tiempo parcial o completo y sin el grado simplemente no pueden acceder a los convenios laborales o puestos mejor remunerados. El TF lo tienen que compatibilizar con este trabajo y lo que se desea es quitárselo de enmedio lo antes posible, sin que represente una gran cantidad de trabajo.
Por eso, lo que voy a contar trata de no aportar carga de trabajo adicional; en muchos casos incluso puede ayudar a tener el trabajo más enfocado y dirigido desde el principio, y a permitir organizarse el trabajo mejor para trabajar con regularidad y llegar al final más rápidamente y, sobre todo, con más eficiencia en las horas invertidas y también en el retorno de la inversión de esas horas. En todo caso, no es absolutista y no representa un camino zen de perfección: toma las reglas que te convengan o te parezcan más razonables, y deja el resto.
Este trabajo, además, es libre y está en un repositorio. Cópialo y adáptalo para entregarlo a tus tutorizados, o si crees que hay algún error o quieres aportar algo a esta copia, hazlo también. Encantado revisaré el PR y lo añadiré a la versión publicada, que actualizaré a continuación.
Como cualquier TF, debemos empezar por el
No he encontrado demasiadas guías prácticas sobre cómo afrontar el TF. Hay trabajos, como (Rodrı́guez 2012), que hacen una panorámica de qué tipo de trabajos recogen los reglamentos de TFG de diferentes universidades. El libro de García Sanz y Martínez Clares (Sanz and Clares 2012) promete ser una guía práctica, pero es quizás demasiado genérico (y extenso) para poder usarse de forma práctica; no está mal, sin embargo, consultarlo antes de ponerse a trabajar. Alier et al. (Alier et al. 2012) proponen una estructuración del trabajo en tres hitos (lo que es un poco escaso para trabajos informáticos) y una serie de preguntas para cada uno de ellos, del estilo de “¿Existe una planificación del trabajo a realizar?”. Puede ayudar sobre todo al tutor, pero desde luego no ayuda al estudiante a hacer dicha planificación o cómo enfocarla. Por último, la guía práctica de Monferrer y otros (Monferrer, Soria, and Nuri 2012) puede ayudar a centrar el desarrollo inicial de un trabajo, pero es un poco demasiado genérica para ser de ayuda a estudiantes de informática. En (Merelo and Tricas 2016), por otro lado, se hace una revisión, no del todo formal, de lo que significa la elaboración de un trabajo fin de grado en ingeniería y el acto de presentación del mismo.
El problema, muchas veces, es que el estudiante realmente no tiene conocimientos (porque su grado no se ha molestado en impartírselo) para tener un proyecto y llevarlo a cabo. Así que vamos al principio, qué es un proyecto y cómo plantearlo.
Porque, en general, la ingeniería de software busca solucionar problemas usando medios informáticos. Así que ninguna sorpresa.
Es decir, en un TF, sea de “investigación” o de cualquier otro tipo (dejemos de lado los llamados “de revisión”, que en general son para salir del paso y reflejan muy poco las habilidades adquiridas por el estudiante en una ingeniería), tienes que resolver un problema. El problema debe ser tan real como sea posible, y debe expresarse en términos cuantitativos si lo admite. Por ejemplo
El problema muchas veces coincide con la motivación de todo el trabajo; en algunos casos la motivación es resolver el problema. En este caso concreto, ese problema puede plantearse en varios contextos; por ejemplo, en un local de ocio, saber si vuelven y cuantas veces lo hacen o contar cuantas personas hay, por temas de aforo (relacionado con el COVID19 o cualquier otra razón). En ese sentido, volvemos a hacer énfasis en que deben ser problemas reales, al menos lo más reales posibles. Sería bastante fatuo decir que se va a resolver el problema del COVID, sin embargo un subproblema sí se puede resolver, y por medios informáticos.
En muchos casos la motivación será el verdadero motor del problema, y no sabrás realmente qué problema quieres resolver hasta que no avances un poco en la modelización del mismo. Por ejemplo, un local cualquiera quiere conocer un poco mejor a la clientela para adaptar los recursos que tiene (de espacio, de asignación de citas) o un centro de ocio municipal necesita controlar el aforo por temas de COVID. La motivación te puede dar directamente el problema a resolver, pero en muchos casos habrá que entender mejor el problema para ver cómo resolverlo. En el caso del centro de ocio municipal, por ejemplo, puede que no podamos contar con que todo el mundo use un dispositivo móvil (y por tanto poco podremos hacer desde la informática).
En este sentido, no sería un problema lo siguiente
Y no lo es principalmente porque no dice qué problema va a resolver, ni tiene ninguna relación con la motivación. “Captar MACs” no es un problema, es una tarea. No tiene motivación más allá de hacer una tarea.
Saber qué problema se va a resolver es esencial. Del problema surge la motivación (o a veces al revés), pero también los casos de uso, es decir, las diferentes situaciones en las que diferentes tipos de usuarios interaccionarán con la solución propuesta para resolver, en ese caso, su problema. En el primer caso, las posibles aplicaciones o el problema que uno tenga en mente serán casos de uso, y de esa forma se tendrán que crear, adicionalmente, lógica de negocio para presentar esa información, o para almacenarla y procesarla. En el segundo caso no hay casos de uso. Se construye el dispositivo. Capta las MACs. Ya está. ¿Dónde se guardan esas MAC? ¿Se tienen que guardar o no?
En esto de puede ayudar la técnica del Design Thinking (Steinbeck 2011,@revisiondesignthinking). Recuerda que siempre es mejor, y va a ser para ti más interesante, que resuelvas tu problema (o el de alguien cercano) que el que te lleguen con una solución ya hecha que ni siquiera se te haya ocurrido a ti. A partir de aquí, ya puedes pasar a la siguiente fase.
Un TFG tiene que culminar en una memoria, que rara vez se lee alguien, pero que tiene que estar ahí; sobre todo si lo has liberado (recuerda, debes liberarlo) va a quedar como una parte aprovechable que permitirá, a quien continúe o use ese proyecto, entender por qué ha llegado a ese estado y qué se puede hacer para que evolucione o se adapte a un contexto determinado.
La memoria suele empezar con los objetivos (tras un breve paso por la motivación/problema); no siempre es así, pero así debería ser. El primer capítulo debe empezar por la motivación (“Por razones legales, en una serie de locales se necesita saber en tiempo real cuantas personas se encuentran en el mismo, así como tener un histórico”) y el planteamiento del problema (“Se necesita un sistema de medición automática del aforo y de la duración de la estancia de una persona en un recinto cerrado”), pero a continuación, se deben experesar cuales son los objetivos del trabajo, es decir, qué parte de ese problema vamos a dejar resuelta y cuál se va a dejar como trabajo futuro.
Construir un sistema tal como el que a priori se va a necesitar (que iremos concretando durante el trabajo) implica ver qué componentes, partes o productos mínimamente viables van a ser necesarios durante su desarrollo; también ver cuales son los casos de uso reales. Por ejemplo, puede que sea un sólo local en cuyo caso la solución será relativamente fácil: algo que se ejecute en un dispositivo en el mismo local. Pero puede ser un local con muchas estancias; o pueden ser muchos locales separados físicamente. Los objetivos deben estar claros, porque de los objetivos saldrán los casos de uso (una vez más, los casos de uso son muy importantes) y de los casos de uso los hitos y tareas para resolverlos. Por ejemplo, puede ser el siguiente objetivo.
Los objetivos deben ser alcanzables, y en lo posible cuantitativos. En este caso, nos hemos comprometido a que valga menos de 30€ (lo que puede excluir, por ejemplo, equipos del tipo Raspi). Pero en subobjetivos se puede ir más allá.
En el primer caso, va a ser totalmente diferente la solución dependiendo de la dimensión del recinto; el segundo nos va a dar un límite en la capacidad de procesamiento del sistema. Que en este caso es amplia, pero puede ser de 1 segundo, en cuyo caso habrá que componérselas.
No será un objetivo, por ejemplo
Por varias razones. Un objetivo siempre tiene que estar en el dominio del problema, o en un contexto de negocio. Si el problema, por ejemplo, es automatizar los procesos de desarrollo de una empresa que provee soluciones de gestión de contenidos, un objetivo podrá ser “Crear configuraciones repetibles que funcionen con una sola orden” o “reducir el tiempo de despliegue de desarrollo a 5 minutos” o “Poder adaptar soluciones existentes a una nueva solución con una semana-persona”. El objetivo no será nunca
ansible que instale todas las aplicaciones que usamos ahora.Un objetivo nunca debe formularse como una solución específica a un problema; es algo que se debe de alcanzar, y justificar, durante el desarrollo de un proyecto. Y nunca debe ser una tarea cerrada. Un TF siempre debe resolver un problema (o parte del mismo), no hacer una tarea.
Los objetivos del proyecto son uno de los apartados más importantes del mismo;
Entre otras cosas porque, estando al principio, es el contenido que con casi toda probabilidad se leerán en el tribunal.
en otro artículo (Merelo 2019) describo cómo formularlos correctamente y qué hace que sean buenos o malos.
Un TF es un trabajo, claro, pero se evalúa mediante una memoria (sobre todo la presentación, pero tiene que haber memoria), que debemos asumir que van a leer, porque aunque es muy probable que no se lea completa, sí pueden leer (o tratar de leer) precisamente la parte que está mal escrita o la que falta; el tutor sí debe leerse al menos una parte considerable, o la estructura de la misma.
Ojo: no se debe pretender, en general, que el tutor se la lea y corrija los puntos y comas, y menos si se presenta completa unos días antes de la presentación. En general, el tutor establecerá líneas generales u objectivos que la memoria debe cumplir (no tener faltas de ortografía, por ejemplo); quien la escriba debe asegurarse de que se cumplen.
Trabajo y memoria deben de ir unidos, en general. No suele suceder así, y esto es un error, pero lo mejor es que se considere la memoria como documentación del trabajo hecho para el TF y parte integral del mismo, no algo que hay que escribir al final para entregarlo y quitarse el tema de encima. Por eso es muy conveniente (d)escribir el trabajo según se vaya haciendo. Porque además, esas fases del trabajo corresponderán también a las diferentes secciones de una memoria.
Usa un sistema de proceso de textos profesional en vez de un procesador de textos comercial. Hay plantillas para memorias o memorias liberadas, como la de de Nacho Cordón enlazada, o esta plantilla que yo mismo he creado. GitHub (y GitLab) te permite hacer tests a todo lo que se mueva, úsalo también para comprobar la ortografía. Finalmente, la gestión de la bibliografía es mucho más fácil en LaTeX, así que todo son ventajas.
Recuerda, finalmente, que en un repositorio no puede ir ningún fichero generado. Si quieres publicar el PDF, crea un release; es decir, añade un tag al repositorio y usa GitHub para subir el PDF.
En este capítulo debe ponerse la motivación, los objetivos generales, los subobjetivos, y describirse claramente el problema que se trata de resolver y todo lo que contribuya a entender el contexto. Si es parte del trabajo en la empresa, esto es lo que se debe describir, si está ya funcionando, también, si es un trabajo de investigación, por qué se ha elegido hacer ese trabajo específico de investigación. También se explicará el resto de la memoria, su estructura, e info adicional: en qué repositorio está, por ejemplo, o si los datos del trabajo se han publicado en algún lugar.
En un capítulo tendrán que ir todos los casos de uso. En general, todas las restricciones que hay (por el negocio al que se aplique, por ejemplo) y por supuesto los casos de uso, qué es lo que queremos que el sistema resuelva. Por supuesto, estos casos de uso tendrán que estar relacionados con los objetivos; por eso es conveniente escribir a la vez que se trabaja: podemos encontrarnos que los casos de uso van más allá (en cuyo caso habrá que modificarlos) y o más acá (en cuyo caso, también, claro). Lo más importante es que cada capítulo forma parte de una misma narrativa, y los RFs no pueden estar “en el aire”, sin tener ningún tipo de relación con los objetivos. Estos casos de uso deben referirse explícitamente a los objetivos, y de hecho tienen que ser anteriores a los mismos, por lo que dentro de ellos tendrá que explicarse claramente por qué. Y la motivación puede ser implícita o explícita: un caso de uso puede haber generado un objetivo.
Una vez que sepas, aunque sea inicialmente, qué vas a hacer, necesitas ponerte, efectivamente, a hacerlo. Puede que no tengas todos los requisitos al principio, pero al menos tendrás los primeros o sabrás por dónde tienes que empezar. Hoy en día la mayoría de los proyectos usan metodologías ágiles basadas en SCRUM. Te pillas una historia de usuario, y la conviertes en una serie de hitos (o milestones) que hay que ir alcanzando antes de tener la historia de usuario completa. Por ejemplo, vamos al proyecto anterior. Una historia de usuario puede ser algo como “El usuario debe de recibir información sobre las personas que hay en el recinto de su interés”.
La historia de usuario es expresamente vaga. Si dices “voy a crear una página web que muestre el número de personas en el recinto” excluyes muchas formas posibles de interacción, desde un bot de Telegram (al que se le pregunte) hasta enviarlo a una cuenta de Twitter. Otra razón por la que los objetivos no deben ser nunca el producto que vas a desarrollar; es algo que tiene que decidirse en función de los requisitos funcionales (y de otro tipo).
De ahí saldrán un montón de productos intermedios. Pero en la parte más bajas de los mismos tendrá que estar el hito de “Captar los paquetes BT y almacenarlos transitoriamente en una estructura de datos”. Ese puede ser el hito inicial. Un hito tiene que describir un producto concreto, un producto mínimamente viable sobre el que se pueda construir. En este caso, una clase o módulo que se conecte con el hardware (que se habrá decidido o elegido en otro hito) y tenga un API del que se pueda obtener ese resultado.
Sobre esto, un proyecto va a ser siempre construir una serie de capas de abstracción. El diseño de una aplicación es algo a lo que no se presta suficiente atención, ni yo voy a hacerlo aquí. Pero no es algo directo, y merece la pena que se pare uno un poco a la hora de hacerlo.
En cualquier caso, hay que hacer un sprint para llevar a cabo el hito, y durante el mismo, tomar una serie de decisiones sobre el diseño, bibliotecas externas que se van a usar, etcétera. Todo debe ir bien anotado (los mensajes de commit pueden servir para eso), porque nos va a servir en el siguiente capítulo.
Por otro lado, es imprescindible que uses git para desarrollar el proyecto; por un lado, porque es lo que se usa en la empresa, por otro lado, porque te permitirá documentar en línea el código, y referirte a issues y demás. Y porque GitHub o GitLab son verdaderos sitios de trabajo en grupo, donde puedes (si el tutor/a quiere) interaccionar con el resto de las personas implicadas; puedes solicitar reviews de lo|as tutore|as o ellos te pueden poner issues para que corrijas algún aspecto del mismo. Estos issues pueden estar fuera de un hito, pero tú puedes añadirlos al mismo (o crear uno que sea producto final o algo así). El hecho de que esté en un issue te permitirá controlar más fácilmente la interacción y consecución del mismo.
En la metodología tendrás que incluir (porque se evalúa, o al menos debería evaluarse) como se ha hecho el control de calidad del producto. En general, debes usar tests desde abajo (funcionales) hasta arriba (integración, y todos los issues se deben cerrar con un test que permita asegurarse de que ese issue no va a volver a aparecer; una vez terminado código + tests se cierra el issue desde un commit.
Lo que no quiere decir que se use un sólo commit para todo un issue. Puede haber uno o muchos; en el mensaje de commit se puede aclarar cómo se avanza para cerrar ese issue.
Todo el proyecto debe estar bien engarzado: los requisitos deben aparecer en milestones, los issues deben estar bien enmarcados y avanzar un hito concreto, y cada vez que se cierre un hito se puede hacer un release. Pero con todo esto podrás avanzar fácilmente tanto en el proyecto como en la memoria, que al fin y al cabo es la descripción de lo que has hecho en el mismo.
Habría que dedicar otro artículo completo a issues y commits. Pero basten un par de reglas: los issues deben ser descriptivos del problema que se quiere resolver específicamente con los mismos, o cómo se va a avanzar hacia el hito. Los commits son los que deben decir qué se ha hecho. Todo commit debe referirse a un issue (puede haber (pocas) excepciones), y un issue siempre se tiene que cerrar con un commit.
En los trabajos científicos, el estado del arte es una parte esencial e independiente. Se trata de saber cómo está el panorama en el problema que se trate de resolver. Por ejemplo, en el caso que nos ocupa, tendremos un montón de placas, conocidas o no, con HATs o lo que sea que pueden ser capaces de captar tramas de Bluetooth o WiFi. Cada una de ellas tendrá sus méritos y sus deméritos.
Pero esta sección de la memoria no es para que se muestre que has sido capaz de buscar por internet y copiar con más o menos fortuna una hoja de especificaciones, muchas de las cuales pueden venir, o no, a cuento. Se trata de que conoces las opciones que tienes a la hora de resolver un problema y que has escogido la mejor dados tus requisitos.
Por ejemplo, no debes hacer esto
No. Se trata de que ya sabes cuales son tus requisitos, de los cuales hemos resaltado el coste (pero podía ser también velocidad de procesamiento). Teniendo en cuenta tus requisitos, puedes hacer una tabla (o contarlo) de todo lo que hay en el estado del arte que lo cumpla. Y finalmente, en el diseño, optas por el que te dé mejores prestaciones en algún aspecto que tienes también que haber decidido de antemano.
Y el estado del arte (y diseño) se debe extender a todo, tanto lo que esté en el proyecto como lo que hayas usado; en algunas cosas te lo puedes saltar (por ejemplo, el editor), pero en general, que muestres conocimiento de herramientas de desarrollo, de implementación y de despliegue es lo que se busca en un TF.
Cuando he hablado de los issues, he dicho implícitamente que todos los issues se debían cerrar con un test; pero es que issues de nivel mayor también tienen que cerrarse con el mismo tipo de test, aunque en este caso serán tests end to end o de integración. Afortunadamente, los tests se pueden ejecutar automáticamente, así que no hay que preocuparse por hacerlo a mano cada vez; sí habrá que preocuparse (y ponerlo claramente en el repo) de que los tests pasen.
Y una vez que los tests pasen, el proyecto se puede desplegar es decir, pasar a producción en una máquina destinada para ello. Y hoy en día, esa máquina estará en la nube, o si no lo está, de todas formas el proceso de desplegar es uno en el cual se crea el contexto necesario para que se ejecute el producto y se comienza a ejecutar, sabiendo claramente qué versión de todos los ficheros se ha desplegado (ya que se ha hecho desde el repositorio), y pudiendo reproducirlo fácilmente simplemente volviéndolo a lanzar. En este proceso de despliegue se levantarán todos los servicios, se compilarán, se instalará lo que haga falta. Y necesita programación específica: la infraestructura es código, y se pueden usar múltiples formas de desplegar, desde un simple contenedor Docker hasta una orquestación con Kubernetes, pasando por Terraform, Vagrant, plantillas de instancias en la nube o lo que a uno se le ocurra.
Los tiempos en los que se copiaban ficheros en un zip a un hosting terminaron en los 90; los tiempos en que se descargaba de un repositorio de código y se empezaban a ejecutar cosas escritas en un post-it (o en un documento de instalación) en 2010 más o menos. Conoce y aprende el concepto de despliegue (para lo que te puede venir bien la asignatura infraestructura virtual) y ponlo en práctica en tu TF.
En algunos casos, del TF se deduce una biblioteca o módulo. El despliegue en este caso es la publicación en el repositorio de códigos correspondiente, siguiendo las reglas que haya en el mismo. El mejor producto de un TF es que cualquiera pueda descargárselo usando la orden correspondiente en el lenguaje que sea.
Como un proyecto de ingeniería que es, se deben estimar los costes del mismo, en dos vertientes: costes de desarrollo, y costes de producción. ¿Cuanto tiempo has dedicado? ¿Qué material has usado? ¿Sabes que tienes que estimar los costes de amortización del equipo informático que hayas usado? Y en producción, ¿cuanto costaría el hosting o los recursos cloud que has usado?
Por otro lado, en general vas a resolver un problema de negocio, que puede tener un retorno monetario o simplemente de ahorro de recursos. Esto también se tiene que estimar. Se trata de un proyecto de ingeniería, los costes son muy importantes, y que el estudiante muestre que es consciente de los mismos, mucho más.
Hay dos tipos de memorias de TF que son muy habituales.
Hay que tener en cuenta la “naturaleza dual” de la memoria. Por un lado, es una descripción de un proyecto; por otro lado, es el documento que se entrega para evaluar el mismo. Como este último, debe contener todo lo que se haya hecho que sea evaluable, esencialmente todas las decisiones técnicas que se han tomado; como el primero, debe describir el trabajo hecho, pero dirigido hacia personas que quieran continuar con el trabajo o, una vez más, evaluarlo. Pantallazos, decisiones sin explicación, no deben tener cabida en el mismo.
Es muy raro que en un TF aparezca como un requisito funcional un nivel de prestaciones determinado, o requisitos como que el downtime sea menos de una cantidad determinada, o que se tenga que levantar el sistema el un tiempo determinado. Por la misma razón, es muy raro que realmente se analice el nivel de prestaciones que se requiere.
El análisis de prestaciones es todo un arte arcano. Pero las decisiones sobre la arquitectura van a afectar el nivel de prestaciones, y por tanto es esencial establecerlo aunque sea mínimamente, para luego comprobar que efectivamente se cumple. Cosas como el nivel de peticiones simultáneas que es capaz de soportar es esencial conocerlas. Aunque no se prevea una carga masiva, primero, nunca se sabe, segundo, se debe conocer para, en caso de que se alcance, tomar decisiones relativas a la arquitectura (y que estas estén claramente explicadas en la memoria).
Las conclusiones no se deben de limitar a decir lo que se ha hecho, sino a evaluar si las decisiones que se han tomado son las correctas. Un proyecto está afectado por las decisiones que ha tomado, y en el tiempo que se da es imposible volver atrás para rehacer lo hecho. Las conclusiones, por tanto, deben ser una serie de contrafactuales: si hubiera elegido PostgreSQL en vez de MySQL, ¿qué habría podido hacer y qué no? ¿Si hubiera pillado un Arduino en vez de una ESP8266? ¿Si hubiera usado Go en vez de Java?
Lo principal es que esta sección cierre el ciclo de la memoria. Se ha planteado un problema, nos hemos propuesto alcanzar estos objetivos, los hemos alcanzado, hemos resuelto el problema. Fin de la historia. Se puede añadir (o no) una sección de trabajo futuro, pero la verdad es que la relevancia de esta es más bien minúscula.
Aunque me había propuesto hacer una pequeño artículo sobre este tema, finalmente ha quedado algo más extenso; al menos, me sirve para recoger diversos artículos y recursos para TFs que tenía dispersos por ahí. Si tuviera que resumir en una serie de mantras lo que hace que un TF tenga éxito, sería:
El último punto, por supuesto, es lo más importante. Buena suerte.
Este trabajo tiene licencia cc-by-sa, así que puedes modificarlo o compartirlo siempre que menciones el autor original y compartas de la misma forma.
Alier, Marc, Jose Cabré, Jordi Garcı́a, David López, and Fermı́n Sánchez. 2012. “Preguntas Para Guiar El Trabajo de Fin de Grado.” XVIII Jornadas de Enseñanza Universitaria Sobre Informática, 201–8.
Merelo, JJ. 2019. “Cómo Formular Buenos Objetivos En Un Trabajo Fin de Grado O Máster.” Medium, https://medium.com/@jjmerelo/c%C3%B3mo-formular-buenos-objetivos-en-un-trabajo-7e68abf10028.
———. 2018. “Por Qué, Cómo, Cuando Y Dónde Debes Liberar Tu Trabajo Fin de Grado/Máster.” Medium https://medium.com/@jjmerelo/por-qu%C3%A9-c%C3%B3mo-cuando-y-d%C3%B3nde-debes-liberar-tu-trabajo-fin-de-grado-m%C3%A1ster-tesis-bb0393a235b1.
Merelo, JJ, and Fernando Tricas. 2016. “En Defensa de Los Trabajos de Fin de Grado.” ReVisión 9 (2): 2. http://www.aenui.net/ojs/index.php?journal=revision&page=article&op=view&path%5B%5D=238&path%5B%5D=381.
———. 2017. “Diseñando Un Proyecto: Design Thinking Para Los Estudios de Informática.” ReVisión 10 (1): 2. http://www.aenui.net/ojs/index.php?journal=revision&page=article&op=download&path%5B%5D=325&path%5B%5D=486.
Monferrer, Mosiés Carmona, Vanessa Soria, and Anna Nuri. 2012. “El Trabajo Final de Grado (Tfg): Una Guı́a Orientativa Para Los Estudiantes.” Revista Del Congrés Internacional de Docència Universitària I Innovació (CIDUI) 1 (1).
Rodrı́guez, I Rekalde. 2012. “¿Cómo Afrontar El Trabajo Fin de Grado? Un Problema O Una Oportunidad Para Culminar Con El Desarrollo de Las Competencias.” Revista Complutense de Educación 22 (2): 179–93.
Sanz, Marı́a Paz Garcı́a, and Pilar Martı́nez Clares. 2012. Guı́a Práctica Para La Realización de Trabajos Fin de Grado Y Trabajos Fin de Máster. Editum.
Steinbeck, Reinhold. 2011. “El Design Thinking Como Estrategia de Creatividad En La Distancia.” Comunicar 19 (37): 27–35.