Planificación y Modelado

Planificación y Modelado
2.4
“Planificación de la documentación”
La documentación es una de las etapas del modelo clásico de ciclo de vida de
un software, esta nos permite documentar información necesaria para los
usuarios del software y para desarrollos futuros.
Una y otra vez aparece el tema de la documentación, durante y después de los
proyectos. ¿Qué documentación deberíamos crear? ¿Por qué necesitamos
documentos de diseño? ¿Cómo podemos asegurarnos de estar construyendo
el software indicado si no tenemos un Documento de Diseño Funcional? Y si el
Documento de Diseño Funcional no está alineado con el software que se está
construyendo, ¿cómo podemos comprobar que obtenemos lo que pagamos?
De todas formas, ¿cuál es el problema?
La pregunta más importante que se hace es:
Si no documentamos todo, ¿cómo vamos a saber lo que queremos
de antemano, y cómo podemos verificar que obtuvimos lo que
necesitamos después de hacer el proyecto?
La pregunta anterior trae una respuesta implícita:
Si documentamos cada aspecto del proyecto, vamos a saber lo que
hay que construir antes de empezar el trabajo, y así podemos
verificar con facilidad si el producto entregado cumple con los
requerimientos originales.
Tipos de documentación
Existen dos tipos de documentos que viven en el mundo de los proyectos de
software.
1. Documentación que los miembros del equipo necesitan para trabajar en
el proyecto. (Es generada en la etapa de análisis)
2. Documentación para ser entregada con el producto final.
A continuación se muestra que debe contener cada uno de estos dos tipos de
documentos, viendo qué necesita crearse (Que información debe contener),
cuando de debe generar y en qué profundidad.
Documentación necesaria para que el equipo trabaje en el proyecto
En el mundo real por lo general la información de lo que se realiza en un
sistema se transmite de una persona a otra un tanto informal ya que se realiza
M.C. Luz Elena Butterfield Velázquez.
Planificación y Modelado
utilizando comunicación directa: hablando entre las personas, preferentemente
en la misma habitación o departamento. Sin embargo hay muchas situaciones
donde lo más conveniente o mejor es realizar documentos. Ya sea porque
tenemos que transportar este conocimiento en tiempo y espacio, porque
tendemos a olvidarnos de las cosas, o porque escribir nos ayuda a pensar en el
proceso.
Sin embargo, en algún punto la industria del software empezó a confundir estos
tipos de documentos de trabajo con documentos que deberían entregarse con
el producto. Por lo que es muy usual que se piense
que los documentos
funcionales y de diseño técnico deben estar alineados con el producto
desarrollado después de terminar el proyecto. Cuando se les pregunta a las
personas porqué querrían hacer esto, las respuestas más comunes incluyen
argumentos como:

Necesitamos saber lo que construimos.

Por motivos de mantenimiento.

Cuando algo parezca no funcionar, necesitamos ver qué debía hacer
originalmente.
Todas estas razones son malos motivos para intentar mantener documentos
enormes que fueron creados con el único propósito de comunicar lo que había
que construir. Después de terminar una característica y entregarla al entorno
productivo, cualquier documento que se creó durante el proceso de
construcción con la intención de soportar este proceso se vuelve obsoleto.
¿Cómo podemos hacer mantenimiento sin documentación?
Cualquier documento que se necesite para el mantenimiento debería crearse
como parte del producto entregable. Sin embargo esto no es lo mismo que un
documento de diseño. La mayoría del software no tiene una vida tan larga (el
software de 5 años ya es bastante viejo), y los lenguajes de programación
modernos permiten crear software legible por humanos, disminuyendo así la
necesidad de crear documentos separados (el código es gran parte de la
documentación). Lo importante aquí es determinar qué tipo de documentos se
necesitan realmente para hacer el mantenimiento. En general bastan unos
pocos diagramas de arquitectura y de tablas que se usan, pero la mayoría del
texto escrito descriptivo por lo general nunca se lee.
M.C. Luz Elena Butterfield Velázquez.
Planificación y Modelado
El documentar nuestro sistema con base al diseño del software evita la pérdida
de tiempo.
Documentación que se entrega con el producto
Dependiendo del producto, el cliente, etc, va a haber distintas necesidades
sobre la cantidad de documentación a entregar como parte integral del
producto. Ejemplos comunes incluyen:

Manuales de usuario

Manuales de despliegue (Pantalla)

Manuales de mantenimiento (orientados a la operación del software)

Documentación técnica (orientados al mantenimiento del código)
El tipo de documentación a entregar con el producto tiene que definirse mucho
antes de terminar el producto. Después de todo, el producto no está completo
antes de que todas sus partes se marquen como terminadas. Usualmente
necesitamos acordar qué documentos entregar con el producto antes de
empezar a construirlo (especialmente en una relación cliente-proveedor).
Cuando se desarrolla un software debe precisarse qué documentos vamos a
entregar con el producto. Podemos escribir manuales largos, o usar técnicas
más "2.0" (Multimedia) como captura de video para cumplir con la
documentación. Esto último suele ser más barato y además es más probable
que se use.
Comentarios
Añadir nuevo
Buscar
693
1
M.C. Luz Elena Butterfield Velázquez.