[mamcx]

Empezado por Delphius

A la manera en que lo dices, parece que el trabajo del añalista está de moño.
No creo que sea tan así, me parece obvio que todo software sigue una línea (en línea generales): análisis, diseño, codificación, prueba, manteniminento. ¿Como es posible que se llegue entonces a la codificación si no hubo una etapa anterior de diseño aunque sea mínima?

No deberia ser asi, lo se. Pero es la realidad. Una vez alguien tiene una idea (ej: Haz un software de facturacion) la gran mayoria inmediatamente nos sentamos a codificar sin hacer ninguno tipo de analisis serio, confiando en que en el camino se resolveran las cosas. Y digo "nos sentamos" porque en lineas generales es mi propia experiencia y de lo que conozco de la mayoria de la gente en varias empresas de software. De hecho, es la tendencia mundial.

Empezado por Delphius

¿Entonces para que gastaron años estos 3 locos si nadie la usa desde un principio?

Precisamente, porque nadie lo hace y por eso Rational es una empresa que gana millones de dolares vendiendo un modelo, unas herramientas y consultorias.

Empezado por Delphius

Me parece fabuloso, pero no le veo sentido hacer UML del código cuando en realidad lo que debería hacerse es el paso inverso: de UML al código.

Es lo ideal, pero la mayoria del codigo ya esta hecho y se necesita comprenderlo. Sin una ayuda automatica, queda muy dicil documentar un desarrollo existente.

Por otro lado, si miras las ideas que propone la programacion extrema, el orden es codigo y si hay tiempo, UML. El UML no es absolutamente indispensable y se puede diseñar directamente en codigo... pero si es una excelente y mejor herramienta para hacerlo. Obvio que habra quienes piensen otra cosa y ese es el problema...

Empezado por Delphius

Se supone que este cambio no debería producirse. ¿Que acaso no se le enseña a usar UML en las universidades?¿Si realmente se les enseñaron estos conceptos, a que tanto le tienen miedo?
En todo caso lo que falta no es la integración, sino la enseñanza. ¿Si se enseñaran bien las cosas, no habría golpes no crees?

Desafortunadamente la enseñanza al respecto no es muy buena. Y el punto es, estamos hablando de quienes, programadores o analistas o ingenieros o??? Si como es el caso de muchos, que iniciamos como programadores, si tenemos de forma caotica los procesos mas elementales, como la manera de mantener las versiones de nuestro propio codigo, de poco o nada sirve el UML.

Haciendo una analogia, es como construir una casa. Obvio que tener los planos es indispensable, pero si los albañiles no saben organizar las herramientas y cada cual tiene su "estilo" de pegar ladrillos, el beneficio de tenerlos se diluira.

A lo que voy con todo esto y apuntando al objetivo que tienes, es reconocer que el desarrollo de software es en general, muy caotico. No se cumplen los tiempos pactados, la mayoria no sabe como estimarlos, no se satisfacen los requerimientos del cliente y muchas veces, ni siquiera los tecnicos. La calidad de los desarrollos es variable pero no es muy comun un programa de buena calidad de primera vez, y asi por el estilo.

El tener las herramientas es indispensable. Mantener:

- El codigo
- Lo que ese codigo debe hacer (requerimientos)
- El diseño del codigo, en otro lenguaje (UML)
- Lo que ese codigo no hace bien (bugs)
- Los archivos anexos, como manejo de los clientes
- etc...

de forma manual es muy tediosa...y ante el problema, la mayoria de los codificadores elegirian solo mantener el codigo. Agrava el hecho que muchas empresas se NIEGAN a "gastar" tiempo diseñando y se NIEGAN a tener requerimientos por ESCRITO y actualizar los mismos.

En mi experiencia en varias empresas de desarrollo, es lo que se ve. De hecho en una que estoy de consultor ahora, practicamente a la fuerza he puesto en marcha el manejo de codigo fuente, una base de datos de bugs y hacer releases en un click. Aun estando en el proceso de certificacion ISO 9000, la administracion NO quiere pagar para tener un proceso mejor... no hay herramienta gratuita que soporte todo lo que la ISO exige y que lo haga bien (y si la hay, diganmelo!).

Y sabes? mi persona ha estado en varios simposios de esto, de ISO, de CMM y de calidad. Mi equipo de desarrollo sabe muy bien UML y todo lo demas. Y sin embargo.. no es suficiente.

Por otro lado, ten en cuenta que la mayoria de las personas que usan UML se limitan a hacer diagramas de clases, y los que medianamente entendemos para que sirven los otros, no es que le veamos tanta aplicabilidad. Y estoy hablando de gente con capacitacion.

Pero Delphius, eso es una gran oportunidad. El UML es parte de un proceso, y hacer que tengo un rol importante seria muy bueno, pero es dificil. De hecho Borland, MS e IBM esperan obtener GRANDES dividendos con sus respectivas plataformas que integran todo eso.

En mi opinion, el UML tiene una aplicacion limitada a la hora de diseñar... o sea, haciendo la analogia con la arquitectura, de hecho un plano no lo cuenta todo y hay varios tipos de planos necesarios para hacer un panorama mas completo y aun asi, se requiere de experiencia practica para unirlo todo.

Para mi diseñar un software reune:

1- Una lista detallada y desmenuzada de requerimientos funcionales. Al menos deberian estar los conocidos, porque obviamente muchos no estan.
2- Un cronograma
3- Una lista de errores
4- Una suite de testing
5- Una representacion de a)Las clases b)Los procesos en tiempo de ejecucion y la interaccion y c)Como se comunican las clases

Hacer solo una de esta sin las otras hace el proceso muy debil. De hecho contra la arquitectura creo que es parecido

1- Que es lo que se va a construir y cuales son los recursos
2- El cronograma
3- Los planos