¡Hola!
Vaya que se han puesto a revivir un hilo viejo. Ya estaba acumulando polvo
Les comento que con el tiempo me di cuenta de que es inútil intentar buscar el modo de formar un nuevo lenguaje genérico... lo único que veía es que estaba reinventando la rueda.
En estos últimos años he cambiado la forma de ver esto, al comienzo iba con la idea de que se empleaban paradigmas puros como USDP pero luego empecé a darme cuenta que resulta mucho más valioso el conseguir un proceso que vaya madurando y que sea constante. Este proceso se establece y se desarrolla en base a la propia experiencia del equipo por tanto es un modelo único y propio.
Es mucho más probable un enfoque mixto de diversos paradigmas, y agregarle condimentos propios... a esa conclusión he llegado. Después de todo en realidad los paradigmas de desarrollo no establecen paso a paso como han de hacerse las cosas sino más bien que PROPONEN un esquema o marco de trabajo en general y en como han de ordenarse las macro-actividades. Las actividades reales se definen teniendo en cuenta cada proyecto en forma particular.
Las herramientas con que cuenten es de menos, mientras con ellas puedan llegar al producto final.
Disculpa que te lleve la contraria Casimiro, pero al igual que Mario considero que UML llegó para quedarse. No va a desaparecer... más bien evolucionará, de no ser ser así no existiría UML 2.0 y tengo entendido que ya están en proceso de borrador de 2.5.
UML está hecho para quienes deseen hacerlo. No a todos les gusta, ni les resulta. En lo particular considero que es una buena herramienta de trabajo.
No es fácil adoptar UML, sobre todo si uno lleva años sobreviviendo sin él. Debe haber una total puesta de conciencia: si vas a utilizarlo, utilízalo bien sino déjalo. Esta misma idea va para cualquier otra cosa: si vas a encarar un proceso de control de versión hazlo bien, no a medias... sino mejor ahórrate el trabajo.
El cambio no debe hacerse obligadamente brusco, puede ser gradual. Pero la idea tras esto es que si uno quiere adoptar una herramienta que la use, pero no porque quiera
probar si con ello tendrá más suerte y logrará aumentar la productividad y la calidad... sino porque tiene la
confianza suficiente de que con su uso su trabajo le resulta ventajoso.
Con el tiempo, consciente o inconscientemente, uno va desarrollando un proceso gradual y toma nota de las armas que les agrada y le resulta útil.
A mi me gusta UML, defiendo su uso. He estado llevando (y llevo) un proceso de aprendizaje y de maduración. Del mismo modo estoy en una fase en donde estoy aprendiendo y asimilando ideas de como ordenar la casa: en lo que hace a organización de actividades, de documentación, de testeo, etc.
No interesa si haces código o UML primero, eso
dependerá de las necesidades y la forma en como uno encara el proyecto. El asunto está en que si utilizas UML, le saques el provecho.
Y no es para volverse loco haciendo mil diagramas, no... así no es... ¡haz lo que consideres que te ayudan a aclarar ideas! Ni más ni menos.
Al comienzo tenía la idea de que todo debía hacerse bien formal, estructurado, rígido, con pasos bien definidos... "que debía hacerse si o si de esa forma". Pero luego empecé a relajarme de esta idea... y entiendo que no necesariamente hay que hacer todo y de todo. Actividades más sueltas, ligeras, flexibles, dinámicas pueden ofrecer mejores resultados sin estar presionando demasiado. Lo importante es lograr un proceso que nos lleve a los resultados, empleando las herramientas que nos aporten utilidad.
Saludos,