GADA Project Gestor Avanzado de Dietas y Alimentación

Estructura del informe del proyecto

La documentación: esa gran desconocida.

En los tiempos en que vivimos, que nadie se lee ni el manual del mando de la tele ni para entretenerse en el baño, se hace muy necesario tener conocimientos de documentación, sobre todo si es de proyectos software. En el caso de GADA en particular (y de los demás proyectos en general), además de ser parte de los ficheros a entregar para el CUSL, considero muy importante una buena documentación, y no me refiero al simple hecho de explicar como se instala o se usa el programa, eso es sólo una pequeña parte de la documentación. Me refiero a documentar todo el proyecto, desde que es un boceto en la cabeza, hasta que adquiere forma y funcionalidad.

Creo que es imprescindible relatar el cómo, pero también el porqué de cada decisión tomada durante las distintas fases del desarrollo. Si usted está diseñando un sitio web interactivo, educativo o algo donde la gente puede jugar poker español, que hay que construir con cuidado. Cada etapa debe ser cuidadosamente considerado. Debe ser lo más práctico, ya que está claro, atractivo y fácil de usar. La cuestión es: ¿Qué fases de desarrollo? En la ingeniería del software, podemos distinguir varias etapas o fases en el desarrollo. No todo se reduce a programar; es más, programar sólo es la consecuencia lógica de todas las demás fases. Las etapas (o fases) que creo que son fundamentales son:

1. Planificación: Una buena planificación del proyecto, sabiendo qué herramientas de apoyo usaremos (SVN, LaTeX...), como se organizará la gente participante en el proyecto (sobre todo si es colectivo) y una primera idea de qué va a ser el proyecto, es fundamental para un buen inicio. Aquí es donde marcaremos las pautas a seguir.
2. Pre-estudio: A pesar de no ser una fase fundamental, considero que es de bastante ayuda para tener una visión global de qué impacto puede tener aquello que vamos a desarrollar, en el entorno al que va destinado. Muchas veces es más importante una pequeña aplicación que cumpla con las necesidades de un grupo específico, que un gran sistema que intenta abarcarlo todo sin conseguirlo.
3. Especificación de requisitos: Una vez que tenemos claro que va a suponer nuestro programa, viene una de las partes más importantes. Definir los requisitos que ha de cumplir. Muchos proyectos fracasan o sufren graves retrasos en su desarrollo por una mala especificación de requisitos. Aquí es donde decidimos qué debe hacer la aplicación, porque debe hacerlo y que implica la realización de esa tarea concreta.
4. Diseño: La fase de diseño es otra de las más laboriosas. En este punto ya tenemos claro qué y porqué debe hacer el programa sus taras, por lo que nos debemos ocupar de solucionar el cómo va a realizar todo aquello que queremos y cómo va a comportarse tanto interna como externamente. Aquí definiremos el comportamiento de los elementos tal que bases de datos, diferentes módulos del programa, interfaz gráfica, interrelación con el usuario, etc.
5. Implementación: Fase importante por el resultado, pero no tanto por lo que supone. En esta fase se produce el desarrollo de la aplicación, no es una fase crítica, ya que si se han resuelto las anteriores de forma óptima, no debe haber más sobresaltos que los propios de la programación.
6. Fase de pruebas: Es importante que a la hora de entregar un producto software, se pasen una serie de pruebas básicas para comprobar que la fase de implementación se ha llevado a cabo correctamente. Aquí es donde se especificarán esas pruebas y se llevarán a cabo.
7. Documentación: Personalmente no la considero estrictamente una fase de la ingeniería del software, pero por su importancia creo que merece ser nombrada e incluida en un buen planteamiento. Aquí es donde debemos especificar lo nombrado en los primeros dos párrafos de esta entrada, y en los seis puntos anteriores. Claro está que esta fase no se desarrolla en último lugar, sino que se va trabajando en ella a medida que pasamos por las diferentes etapas.

Bueno, espero que os haya servido como introducción, otro día pondré un ejemplo de qué partes concretas puede tener la documentación y como estructurarla. Obviamente, todo esto es desde mi punto de vista y no es una verdad universal. Cada maestrillo tiene su librillo.