La fiebre de UML
¿conoces a alguien con la fiebre de UML?
Los procesos de desarrollo de software están llenos de herramientas que podemos usar: tarjetas CRC, diagramas de todo tipo, generadores de código automáticos, documentación...
El problema surge cuando nos centramos más en las herramientas que en el software que debemos construir. Se ve en bastantes proyectos, dónde se manejan ingentes cantidades de documentación, agendas, diagramas; pero no se vislumbra cómo va el desarrollo del software, que es el objetivo final. De repente, nadie sabe exactamente en que estado está el producto. Unos días te hacen una demo de una parte, y días despues de otro módulo, pero entonces te dicen que el del otro día ya no funciona, que hay que revisarlo. Eso sí, los diagramas UML te los enseñan, para descibirte las características internas del sistema.
El artículo "Death by UML Fever" describe con un poco de sarcasmo, los casos clínicos del abuso del UML, sin duda la herramienta más extendida hoy por hoy para el diseño y ayuda del proceso de construcción del software. La falta de experiencia práctica parece ser una de las principales razones para que los ingenieros de software se dejen llevar por las "fiebres" que provocan el uso indiscriminado de UML. Parece más facil e igual de útil pintar diagramas que ponerse "manos a la obra".
Y tú, ¿conoces a alguien afectado por las fiebres del UML?
Mi Twitter
Por desgracia se ven con bastante frecuencia casos parecidos.
ResponderEliminarMucho coordinar, gestionar, planificar, analizar, evaluar, controlar, ... Pero de escribir código, nada de nada.
Guti.
Mucho escribir código pero de coordinar, gestionar, planificar, analizar, evaluar, controlar... nada de nada.
ResponderEliminarEsto me da más miedo que lo primero, prefiero el código que no existe al que no esta bien diseñado.
Aunque si es cierto que a veces un proyecto se entierra entre la marea de diagramas, diseños y tal y pascual y luego no hay un control sobre el proceso de desarrollo (buen control de versiones, gestión de la configuración, integración continua... ).
Ciertamente no debemos sobrecargar un proyecto con documentación excesiva. Pero tampoco debemos menospreciar ni confunfir su utilidad.
ResponderEliminarEl objetivo del UML es facilitar la comunicación, permitir hablar un idioma común entre todos los integrantes del proyecto. Es vital para que un diseño sea correctamente entendido y realizado y para documentar los conceptos en los que se fundamenta el desarrollo.
Esto obviamente tiene una implicación importante tenida muy a menos: "Pensar antes de programar".
Se imaginan las grandes contrucciones como el aeropuesto de Japon en el mar o la torre Eiffel sin un plano, sin una planeación, sin maquetas. Simple y sencillamente NO hubierán existido.
ResponderEliminarClaro, nadie dice que no haya que pensar y diseñar como primer paso. El problema es su exageración.
ResponderEliminarLa torre Eiffel o un aeropuerto se pueden diseñar completamente, e incluso simular antes de su construcción, pero con el software no. ¿cuando decides parar y ponerte manos a la obra? Hasta que no empiezas a ver las cosas, es muy dificil de cerrar los requerimientos y ver todos los problemas. En el diseño no salen todas las cuestiones.
Por eso hay que tener cuidado con la tendencia a sufrir la "fiebre de UML", ¡¡¡pero no quiere decir esto que no haya que diseñar nada!!!
De alli la importancia de la Ingeniería de Software, estoy de acuerdo en que no se debe exagerar por que en lugar de hacer análisis se cae en la parálisis. Todo debe ser un equilibrio como en todas las cosas. El problema es que a veces los programadores estan peleados con los Ingenieros de Software o con los testers o viceversa, el punto es todos son importantes para el desarrollo de un sistema. Una función no puede estar divorciada de la otra. Mas alla, un sistema es, hardware, Software, Procedimientos, Recursos humanos Etc.
ResponderEliminar