Algunas preguntas sobre la redacción de la memoria del TFG/TFM/PFC

¿La memoria? ¿Eso qué es? ¿El TFG/TFM/PFC?

La memoria es el documento que describe y explica el proyecto realizado por el alumno. La memoria no es necesariamente el TFG/TFM/PFC. El trabajo puede ser un proyecto clásico de ingeniería, de hardware, software o una combinación de ambos. La memoria documenta ese proyecto o trabajo. En ciertos casos la memoria puede coincidir más o menos con el trabajo en cuestión, por ejemplo en un estudio comparado de productos, o en un estudio de mercado.

¿Y qué pongo en la memoria? ¿Cuento lo que he hecho?

Claro. Pero bien. Un error frecuente es plantear la memoria como una crónica, donde se va anotando el curso de la realización del proyecto. Así, quien lee se ve obligado a pasar por las mismas vicisitudes y en el mismo orden que el alumno: "y entonces me paso esto, y entonces me di cuenta de esto otro, y entonces descubrí tal otra cosa, y entonces..." No se trata de eso. El objetivo no es que el lector haga el mismo recorrido, sino conseguir que se familiarice con el proyecto de una forma más rápida y efectiva. Por tanto, hay que proporcionar la información de la forma más ordenada y estructurada posible. Además, llegado este punto ya sabemos que la cosa funciona, no tiene sentido añadir suspense. A grandes rasgos, la redacción debe contemplar los siguientes puntos:
  • En primer lugar los objetivos, entendiendo por estos los que finalmente se han conseguido, independientemente de que fueran los primeros que se consideraron al iniciar el proyecto.
  • En segundo lugar, el plan, es decir, la metodología y el diseño. Aunque sea "sólo código", uno no se lanza a teclear sin ton ni son (bueno, sí que lo hace, pero no debiera...) Es necesario tener un diseño previo. Evidentemente ese diseño se refinará y realimentará según avance la codificación, y puede ser que haya que cambiarlo...no pasa nada, en la memoria sólo se pone el definitivo. Cuando haya alternativas de realización hay que discutirlas y justificar la elección tomada. Así el lector podrá formarse un esquema mental de lo que se ha hecho y del porqué.
  • Y por último, los problemas detectados.

¿Y no hay un índice que pueda seguir?

El contenido de la memoria es libre, y el índice concreto dependerá del tipo de proyecto. De todas formas es frecuente que tenga:
  1. Una introducción, donde se presenta el trabajo y el ámbito en que se desarrolla.
  2. Una motivación y antecedentes, donde se justifica la necesidad que se busca resolver y se presenta el entorno, indicando por qué otras soluciones (si las hubiera) no resultan satisfactorias.
  3. Una planificación temporal y una declaración de los medios materiales necesarios para llevar a cabo el trabajo
  4. Un diseño (de clases, de bloques, de procesos, de módulos, etc). Si se desea puede usarse UML. Si hubiera varias posibilidades, se justificarán las escogidas.
  5. Un plan de pruebas. Hay que probar todo el software que se desarrolla, y lo normal es que el esfuerzo de probarlo sea tan grande como el de codificar. Las pruebas deberían ser automáticas, para que, si se modifica algo, puedan pasarse de nuevo sin intervención manual.
  6. Un apartado de conclusiones y líneas de continuación.
  7. Referencias y bibliografía.
Algunos de los ítems anteriores podrán agruparse en el mismo capítulo, mientras que otros se repartirán entre varios o podrán relegarse a un anexo. O, para algún tipo de proyecto concreto, podrán no existir en absoluto. Los manuales de instalación y uso suelen también dejarse para un anexo.

¿Y qué hay del estilo?

La memoria es el documento técnico y formal. Debe estar orientado a que lo lea otro ingeniero, quien, poseedor de la formación necesaria, pueda hacerse una idea de la motivación, objetivos, organización y solución adoptada. En general no es un documento docente, un "tutorial" para presentar una tecnología: se supone que el lector ya la conoce, y, si no, basta con proporcionarle las referencias necesarias.

El mío es un programa ¿Pongo el código?

En el documento impreso, no. Pero sí en el CD, por lo que el código debe ser decente. Repasa las normas de programación. Nada de constantes mágicas, efectos laterales, variables sin iniciar, errores no tratados y demás. Los comentarios debieron ponerse mientras se codificaba. Si se siguió la convención adecuada, la documentación del código podrá generarse automáticamente con javadoc o doxygen

Es que entonces creo que tiene pocas páginas ¿cuántas debería tener?

Las necesarias. No se mide al peso. Pero es raro que sean menos de 60 o más de 300.

¿Y hay algún formato?

La ESI tiene una plantilla bastante agradable, que está accesible en la Web. Conviene escribir directamente en el formato definitivo. Word es particularmente estúpido e incompetente para pasar de un formato a otro y luego costará más trabajo (en mi opinión también es particularmente estúpido e incompetente para casi todo lo demás).

¿Se leerá el tutor los capítulos de la memoria según los voy escribiendo?

No por Dios, que ya somos mayores. Además, hacerlo incentiva una mala redacción. El tutor necesitará una memoria completa para hacerse una idea de conjunto. La memoria completa no tiene que ser "definitiva"...pero casi. En concreto:
  1. Nunca capítulos sueltos, sino memorias completas, en PDF.
  2. El formato debe ser, desde la primera redacción, el definitivo. Un buen formato facilita la lectura, así que seguramente no quieras mortificar innecesariamente al tutor con un formato incompleto, con las páginas sin numerar, sin índice, con una tipografía inconsistente y con las secciones mal ordenadas.
  3. La redacción será impecable, la propia de un universitario. Nada de enviar borradores a medias justificando que "ya luego lo pongo bien": el momento de hacerlo bien es desde el principio. En particular, no habrá faltas de ortografía y la puntuación se usará correctamente. Las comas no se usarán para separar sujeto y predicado, como sabe cualquier alumno de secundaria. Las oraciones de más de tres líneas son, casi sin excepción, una mala idea. Las palabras en otro idioma (p.ej. layout) aparecerán en cursiva. Las siglas y acrónimos no se traducen. El imperativo y el infinitivo no se usarán como si fueran la misma cosa.

Ayer por la tarde envié un borrador. Quería enviar otro hoy pero todavía no me ha corregido el de ayer

Quizá el anterior no estaba lo bastante maduro. Por supuesto, el tutor esperará que te hayas leído lo que has escrito...varias veces...antes de enviárselo. Ni se te ocurra decir algo como (sic) "Gracias por el feedback, es realmente útil cuando uno no se ha leído lo que ha escrito", los siguientes borradores irían directos a la papelera... Concede un tiempo prudencial al tutor antes de insistir. Si en 4-5 días no tienes noticia, reenvía el mensaje, pero no lo atosigues: los exámenes tienen preferencia, y, además, hay más alumnos enviando memorias peor redactadas que la tuya.

No encuentro un error en el código ¿Me lo buscará el tutor?

Noooo. El tutor ya encontró los errores de su propio código. Te ayudará con los problemas, te dará consejos, te planteará alternativas para encontrar los errores, e incluso te sugerirá soluciones, pero no modificará ni buscará errores en tu código.

Vale, ya lo tengo todo escrito, ¿y ahora, qué?

Ahora el tutor te dirá. En el Departamento de Telemática pedimos, salvo indicación del tutor, lo siguiente:
  1. Dos copias de la memoria, ambas a doble cara.
  2. Una de las copias quedará depositada en el Departamento antes de que el tutor autorice la defensa del proyecto. Eso acelerará el proceso de evaluación, ya que los miembros de la comisión evaluadora podrán ir examinándola. Por motivos prácticos dicha copia estará encuadernada en pasta dura y deberá ser identificable por el lomo (o sea, no con espiral de alambre). Esta copia debe incluir en CD los códigos fuente de todos los programas realizados, sus manuales de uso y documentación en formato electrónico, así como la memoria misma.
  3. La otra copia se depositará en la Secretaría de Alumnos para iniciar los trámites de defensa.
  4. Un resumen del PFC/TFG/TFM de no más de 20 líneas.

Y ¿en qué consiste la defensa?

En la exposición oral y pública del trabajo, seguida de un turno de preguntas por parte del tribunal o comisión evaluadora del mismo. Conviene planear una duración de unos 20 minutos (luego serán más...), con no más de 25-30 transparencias y, si se desea y el tipo de trabajo lo permite, una demostración de su uso.

¿Cuánto tiempo tarda en defender el trabajo desde que se deposita la memoria en Secretaría?

Los plazos máximos y mínimos están en la normativa académica. Entre 7 y 10 días suele ser un plazo razonable. Hay que dar tiempo a que se realicen los trámites administrativos, a que los miembros de la comisión evaluadora (tribunal) examinen la memoria y a que encuentren una fecha adecuada.

La fecha de defensa no me viene bien, no puede venir mi novia/novio

Reflexionemos un poco. La defensa del PFC/TFG/TFM es un acto académico, no un acto meramente protocolario y familiar, para amigos, novias y abuelos. En particular, no es el acto de despedida de la carrera del alumno. El acto académico-familiar es el de entrega de diplomas a la promoción. El carácter público de la defensa garantiza su limpieza, pero conviene no olvidarse de que se trata de un examen más. En el que, por cierto, se puede suspender. No hay, ni puede haber, inconveniente en que asista quien sea, faltaría más. Pero lo que no nos parace bien es que se deje que esta distorsión condicione el procedimiento.