Cuando uno conoce el dominio del problema, la lógica de negocio, los casos de uso, etc. da mucha pereza modelar todo y dejarlo documentado. A mí el UML me parece en mucha ocasiones verboso, redundante e inútil. Para colmo, jamás en 15 años de profesión he recibido por parte de un cliente con el que he tenido que integrarme ninguna documentación en UML. No por ello creo que sea inútil hacerlo: HAY QUE DOCUMENTAR. Pero la relación beneficio-coste en este caso es bastante dudosa. El UML al final sirve para hacerte una idea del sistema en cuestión, pero para eso tienes que empaparte unos diagramas en muchos casos crípticos. Y para más inri, crípticos para exponer quizás un algoritmo o secuencia muy sencilla.
Ahora bien, atarse al UML por el hecho de ser un estándar, a veces me parece innecesario. Hay mil formas de representar procesos, algoritmos y arquitecturas sin necesidad del UML de forma más elegante y ante todo sencilla.
Por otro lado, el problema de la documentación detallada es que se queda obsoleta en poco tiempo. Ahora mismo ya no se estila el desarrollo en cascada sino los procesos iterativos donde hay multitud de cambios tanto en el código fuente como el la funcionalidad de un sistema. Todos esos cambios habría que reflejarlos en la documentación, y eso yo creo que no lo hace ni el tato (incluso por mucha empresa grande con un ejército de analistas).
De todas formas, para no tener que abrir paraguas por mi opinión, insisto, documentar está bien y lo veo un mal necesario.
?
