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.