Para la defensa final del trabajo, tendrán que confeccionar una documentación con el fin de describir lo siguiente:
a) El diseño y la implementación del código
b) Cómo se usa la aplicación
c) Las incidencias en el transcurso de la actividad (diario del trabajo)
d) Las conclusiones del grupo de prácticas respecto a su trabajo
Esta documentación será entregada al profesor tutor de la práctica. Por tanto, han de tener en mente que ese documento será importantísimo para evaluar el trabajo realizado, y contribuirá en la nota final que obtengan. Ante todo, es crucial redactar con claridad, concisión y sin perder el tiempo en divagaciones.
A continuación se presenta una guía de cómo estructurar la memoria de la práctica. Esta guía ha de considerarse más una recomendación que una exigencia. Ahora bien, procuren tener muy presente cuál es la misión de la documentación.
La memoria deberá estar redactada en un estilo legible, sin faltas de ortografía. La tipografía será clara. No es necesario que esté mecanografiada, pero en caso de ser manuscrita, la escritura habrá de ser bastante clara.
La memoria del trabajo no debería superar las 15 páginas en total. Habrá que procurar ser conciso y breve en la medida de lo posible. Elaboren un documento que se pueda leer por completo (y entender) en media hora a lo sumo.
El documento tiene que estar bien presentado y compuesto. Piensen que están vendiendo su trabajo, y que el envoltorio es tan importante como el contenido de lo que presentan. En resumen, los cuatro mandamientos que han de cumplir con la documentación son:
* Estilo claro y limpio
* No contar más que lo necesario
* No más de quince páginas
* Deberá poderse leer en media hora a lo sumo
Una memoria típica estaría organizada en los siguientes apartados:
1. Índice de contenidos
2. Descripción general
3. Diseño del programa
a) Estructuras de datos
b) Subprogramas
4. Organización de los archivos
5. Cómo utilizar la aplicación
6. Diario de incidencias
7. Conclusiones
Una breve presentación del trabajo. Contendrá las especificaciones de la aplicación, sobre todo las particularidades o diferencias respecto al planteamiento inicial de la práctica.
No debería abarcar más de una página.
Esta sección intentará presentar cómo han organizado el código. Por ejemplo, pueden describir estos elementos:
* Estructuras de datos (en memoria y en disco)
* Subprogramas (procedimientos y funciones)
* Módulos funcionales
Es muy recomendable utilizar diagramas y gráficos para representar las estructuras, o las relaciones entre los distintos módulos.
Diagramas o tablas donde aparezcan todos los archivos que componen su
aplicación, incluyendo programas en C, makefiles, ficheros
léeme, etc. En el caso de los ficheros en C, deben expresar
las relaciones entre ellos (ej. quién incluye a quién).
No debería ocupar más de dos páginas.
Reseñen en la memoria lo que les ha ocurrido durante la realización del trabajo. Algunas de las incidencias que pueden referir son:
a) Cómo se han descompuesto el trabajo
b) Con qué dificultades se han encontrado
c) Qué bibliografía u otras fuentes tuvieron que emplear
d) Si hicieron cambios respecto al diseño original
Este diario no debe superar una página.
En la parte final del documento, el grupo de prácticas debe recapitular sobre su trabajo y exponer lo que a su juicio es el resumen de la labor realizada. Podrían responder a cuestiones como: ¿se han cumplido los objetivos previstos? ¿las herramientas empleadas son las adecuadas? ¿se han aprendido conceptos nuevos? ¿cuáles?
El apartado de conclusiones típicamente ocuparía media página.
El listado de los programas fuentes no forma parte de la memoria. Si se desea entregar, debería hacerse en un anexo. Mejor incluso si va separado del documento.
* La memoria NO son los listados de los archivos fuentes.
* NO copien servilmente fragmentos de la documentación de las prácticas, o de los libros de texto de la asignatura. La memoria sirve como documentación a su trabajo. No es una descripción de las herramientas.
* NO mientan, sean sinceros. Programar una aplicación casi nunca es una tarea exenta de tropiezos y errores. Es preferible que reconozcan que tuvieron un error en el diseño, o que hay un elemento del programa que no han conseguido que funcione: todo ello demuestra que realmente han trabajado la práctica.
* La memoria NO es un resumen sobre un tema de la teoría. No se dediquen a explicar lo que es la gestión de la memoria, ni lo que es un sistema operativo. El profesor ya lo sabe. Céntrense en el software que han creado.