Documentación de Software

 

“se deberá valorar más  al software operativo sobre la documentación exhaustiva“.  - manifiesto ágil - 

Existe la controversia sobre si es necesario documentar todos los procesos de un sistema o si es realmente útil elaborar manuales tan extensos. Esta controversia existe sobre todo entre los métodos tradicionales y los métodos ágiles de desarrollo de software.

Por un lado las metodologías tradicionales hacen énfasis en que el producto arrojado por cada etapa del ciclo de vida del software deberá ser un documento con todos los detalles que estén involucrados. Esto incluye manuales extensos de usuario que deberán ser entregados al cliente.  Otra de las características de este enfoque, es que se basa en el uso de contratos entre la empresa desarrolladora de software y el cliente que solicita el producto. De esta forma es posible controlar los requerimientos y las peticiones de cambio.  

Se debe aclarar que la documentación así como los tipos de documentación que son resultados de estas metodologías  son de muchas variedades, puesto que cada tipo de documento va enfocado a mostrar los detalles de diferentes puntos del sistema.

En contraste, las metodologías ágiles hacen énfasis en el hecho de que al producir software el enfoque deberá ser orientado a los clientes, el usuario y  los desarrolladores mismos. En general los principios de estas se basan en el “Manifiesto ágil” (“Agile manifesto for software development,” 2015)  el cual argumenta que la documentación no es tan importante, puesto que esta tiende a degradarse  y quedar obsoleta muy rápido con cada petición de cambio del cliente.

De este modo los desarrolladores deberán estar más cerca del cliente, mostrando el progreso y recibiendo retroalimentación constante por parte de estos.  Los requerimientos cambiantes no son un problema, puesto que existen diversos principios y estrategias que se siguen para realizar los ajustes del cliente. Una de las debilidades de este enfoque es que los desarrolladores tienden a no generar documentación ni de usuario, ni de desarrolladores y muchas veces no suelen comentar el código fuente,  Sommerville( 2011, p.57-77).

El manifiesto ágil tiende a malinterpretarse en el principio que reza:

“se deberá valorar más  al software operativo sobre la documentación exhaustiva“.

Muchos desarrolladores piensan  que no debe existir documentación puesto que es tiempo perdido y que resta esfuerzo al proyecto. Sin embargo esto es erróneo ya que si bien la “documentación exhaustiva” tiende a degradarse, es necesario realizar de algún modo el registro para comunicar los detalles no tan obvios del sistema. El principio antes citado, no habla sobre documentación nula, habla en realidad sobre el hecho de realizar documentación puntual sobre lo que en realidad importa.   

Lo anterior se demuestra cuando en un equipo ágil mientras los miembros esten activos en los proyectos sabrán los detalles del sistema. Si en un momento dado entrara un nuevo miembro, este sería fácilmente capacitado puesto que los miembros poseen la información y perspectivas necesarias. Pero, si en un instante los miembros originales de un proyecto se van, es evidente que se irá perdiendo información realmente útil, poniendo en riesgo el mismo proyecto puesto que no hay referencia alguna sobre lo que contiene, lo que hace o lo que debería hacer el sistema (documento de requerimientos).