DESARROLLO Y DOCUMENTACION DEL SOFTWARE



DESARROLLO Y DOCUMENTACION DEL SOFTWARE


























DESARROLLO Y DOCUMENTACION DEL SOFTWARE

En la quinta fase del ciclo de vida de desarrollo de sistemas, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las técnicas estructuradas para diseñar y documentar software se encuentran losdiagramas de la estructura, los diagramas de Nassi-Shneiderman y el pseudocódigo.
Durante esta fase el analista también trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios web que incluyan respuestas a preguntas frecuentes (FAQ, Frequently Asked Questions) en archivos “léame” que se integran en e nuevo software.
Losprogramadores desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de los programadores de cómputo. Si el programa se ejecutara en un entorno de mainframe, se debe crear un lenguaje de control de trabajos.

 Cómo documentar un sistema de software?
Objetivo
Un sistema pobremente documentado carece de valor aunque haya funcionado bien en alguna ocasión. En elcaso de programas pequeños y poco importantes que sólo se utilizan durante un corto periodo de tiempo, unos cuantos comentarios en el código podrían ser suficientes. No obstante, la mayoría de los programas cuya única documentación es el código, se quedan obsoletos rápidamente y es imposible mantenerlos. El que la dedicación de un poco de esfuerzo a la documentación sea recompensado incluso dentrode los límites de un pequeño proyecto, constituye una sorpresa para la mayoría de los novatos.
A menos que usted sea infalible y viva en un mundo en el que nada cambia, tendrá que volver a consultar el código que ya está escrito, y pondrá en duda decisiones que tomó durante el desarrollo del mismo. Si no documenta sus decisiones, se verá siempre cometiendo los mismos errores y tratando decomprender lo que pudo haber descrito fácilmente en una ocasión. La falta de documentación no sólo genera trabajo adicional, sino que también tiende a dañar la calidad del código. Si no posee una nítida caracterización del problema, es imposible que desarrolle una solución clara.
Aprender a documentar software es una tarea complicada y exige un criterio de ingeniería maduro. Documentar de forma concisaes un error habitual, pero el otro extremo puede resultar igual de perjudicial: si escribe documentaciones extensas, éstas atosigarán al lector y constituirán una carga a la hora de conservarlas. Es esencial documentar sólo los asuntos correctos. La documentación no sirve de ayuda para nadie si su extensión desanima a la gente a la hora de leerla.
Los principiantes tienen la tentación de centrarsus esfuerzos en temas sencillos, ya que éstos les resultan más fáciles de documentar. Esto es una pérdida de tiempo; no se aprende nada del esfuerzo y se termina escribiendo una documentación que es cualquier cosa excepto útil. Los principiantes también tienden a mostrarse reacios con los problemas de documentación. Esto trae consigo poca visión de futuro: si usted sabe que algún aspecto de sudiseño no es del todo correcto, que alguna parte del problema no se ha aclarado o que es posible que parte del código tenga errores, ¡dígalo! Hará que el lector ahorre tiempo dándole vueltas a algo que aparentemente es erróneo, se acordará de dónde tiene que mirar si encuentra problemas y acabará teniendo una documentación más útil y honesta.
Otro asunto es cuándo documentar. Aunque algunas veces esconveniente posponer la tarea de la documentación mientras se realizan experimentos, los programadores con experiencia suelen documentar de forma metódica incluso el código provisional, los análisis de un problema inicial y los borradores de un diseño. Ellos creen que esto hace que la experimentación sea más productiva. Además, dado que han tomado la documentación como hábito, les resulta normal...