Es una realidad evidente para cualquier persona observadora que la Industria de Software, por su naturaleza misma y por su intima relación con la tecnología es una de las mas cambiantes. La Ingeniera de Software, por tanto, no se encuentra ajena a esta realidad y en menos de una década ha sido victima de dos grandes revoluciones que han modificado definitivamente el escenario:
1996: Aparición de UML y su posterior adopción como estándar de Análisis y Diseño Orientado a Objetos
2001: La Confección de Manifiesto Ágil y la aparición de nuevos modelos y metodologías que aplicaban a éste.
Es verdad aceptada hoy en día que UML es el estándar de gestión de cualquier Proyecto de Software de envergadura. Pero la irrupción de otras metodologías hace clara la necesidad de satisfacer otros aspectosque no han sido tenidos en cuenta. Esto, por otro lado, no significa que los métodos ágiles sean “balas de plata” (en términos de F. Brooks), si bien es cierto que si se encuentran en uso, debe existir algún argumento que justifique esa implementación; se me hace igualmente inevitable traer a colación las palabras de Dijkstra quien alguna vez expresó que "los errores industriales no son sacrosantos sólo porque se cometan a gran escala" , y esto aplica para ambas posturas.
El hecho objetivo es que existen disconformidades, por llamarlas inicialmente de una manera con UML, y es ahí donde radica el objetivo de este análisis.
Las razones de UML
27 Años después que Dijkstra observara que la calidad de un código fuente era inversamente proporcional a la cantidad de sentencias GO TO del mismo, esta preocupación parecía salvada con la aplicación de los conceptos de O.O., pero no evitaba que el debate siguiera abierto en cuanto al desarrollo de Software.
Existían por aquel entonces (como atestigua el conocido artículo de Richard Paige y Jonathan Ostroff “A Comparison of the Business Object Notation and The Unified Modeling Language”) numerosas notaciones que aplicaban al modelado orientado a objetos. Es en este escenario donde Jacobson, Rumbaugh y Booch desarrollan su Unified Modeling Language desde su empresa Rational, la que luego sería comprada por IBM.
Queda claro que nace por necesidad de unificar varias notaciones y nos deja como principal enseñanza la aplicación de un Modelo Iterativo e Incremental. Lección aprendida de los viejos modelos, como el de Cascada, era que el partir de un objetivo de un sistema y crear según él todo un diseño y un posterior desarrollo, podría traer consecuencias insalvables si se descubrían errores en etapas tardías del proceso.
Pero por otro lado, trajo como consecuencia la dificultad de separar las etapas. Si bien son cosas diferentes, el análisis y diseño no se encuentran diferenciados claramente en UML, y en ciertos casos puede dar la impresión que se hacen en simultaneo; esto, si bien no en todods los casos, puede representar una limitacion importante.
UML unifico un gran numero de corrientes y se convirtió en estándar, pero no era la única opción, sino la mas aceptada. Me permito solicitarle al lector que retome la cita de Dijkstra realizada al final de la introducción y que la contraste con este ultimo párrafo.
Los contrincantes caídos en batalla
El Modelo BON (Business Object Notation) era por aquellas épocas otra de las grandes opciones, y si bien su popularidad es notoriamente inferior a la de UML y (Que viva el cielo!) tiene sus fallas, perseguía entre sus objetivos una premisa que en mi modesta opinión UML no cumple: el desarrollo continuo.
Entre los objetivos de BON encontramos:
Reversibilidad, que es la capacidad de reducir el impacto de un cambio sustancial que deba implementarse en una etapa avanzada del proyecto, incluso en las etapas de implementación y mantenimiento.
La Continuidad en el desarrollo (“seamless”) es decir, reducir las actividades superpuestas, y la disociación entre otras, durante el desarrollo del soft.
En 1997 Bertrand Meyer, quien fuera el desarrollador del lenguaje de programación Eiffel, y uno de los principales adeptos a el modelo formalizado por Kim Waldén y Jean-Marc Nerson (el mencionado Modelo BON) hace notar esta falencia de UML en su polémico articulo titulado UML: The positive spin (UML: EL giro positivo). En el mismo hace, con una toque de sarcasmos que le seria de envidia del mismísimo Mikhail Bakunin, una zagas critica, aunque a veces desmedida, hacia RUP y UML y una defensa al modelo BON. Si bien no estoy de acuerdo con la totalidad del artículo, vale destacar el hecho de que Meyer se planta en la vereda de enfrente y lanza un critica sin miramientos, lo cual me parece válido utilizar hoy en dìa, a fin de re pensar lo que se entiende como políticamente correcto y que implícitamente el mercado y la industria del Software dicen entre lineas: UML es la mejor forma de gestionar un proyecto.
Se que tal vez alguno pueda sentirse ofendido por esta cuestión, pero no son las ideas las que dañan, y cuente esto tanto para BON como para UML y cualquier cosa que se le parezca, la fanatización Y radicalizacion de las ideas son lo realmente peligroso y no las ideas en si, si su generación fue en pos de un objetivo positivo.
Para los interesados, dejo un link al articulo, el cual es altamente recomendable a fin de replantearnos algunas cuestiones:
http://www.archivosbackup.com/download.php?file=593UML,%20El%20giro%20positivo%20Por%20Bertrand%20Meyer.pdf
Mas allá de las formas de Meyer, es cierto que los Arquitectos de Software a la hora de gestionar un proyecto con UML se encuentran con la complicación de encontrar el nivel de detalle adecuado y a menudo es difícil diferenciar si se esta efectuando una Ingeniería de Software o Ingenieria de Documentación. Por otro lado, no caben dudas que la aplicación efectiva de UML deja una exhaustiva documentación y no queda aspecto del desarrollo sin cubrir.
La Moraleja.
De todo este repaso sobre debates de la Ingenieria de Software podemos sacar algo en claro: no hay nada nuevo bajo el sol. La batalla no esta cerrada aun y todos los enfoques son igualmente válidos. Es decir, mientras BON aplica el concepto de Reversibilidad, UML habla de un proceso Iterativo e Incremental y las Metodologías Ágiles hablan de Iteracion, Sprint o lo que fuere, todas lo que buscan es hacer un proceso incremental en el cual los cambios tengan el menor impacto posible y puedan contemplarse todas las posibilidades y definir periodos cortos de desarrollo a fin de reducir la incertidumbre en la estimación de tiempos y. Esto puede ser bueno, dado que tenemos diferentes versiones de una misma realidad o malo si consideramos que seguimos en los mismos debates y no hemos encontrado una resolución definitiva.
Por otro lado esta claro que la naturaleza de cada proyecto determinara que metodología es apta: mientras parece ser mas apropiado aplicar una metodología ágil a proyectos que posean una cantidad de integrantes y elementos acotada, difícilmente pueda aplicarse y controlar todos los aspectos de un desarrollo grande.
Pero no hay balas de plata, no hay formulas mágicas, por lo cual siempre es saludable una revisión a lo pre establecido y una posterior adaptación al caso en análisis.
1996: Aparición de UML y su posterior adopción como estándar de Análisis y Diseño Orientado a Objetos
2001: La Confección de Manifiesto Ágil y la aparición de nuevos modelos y metodologías que aplicaban a éste.
Es verdad aceptada hoy en día que UML es el estándar de gestión de cualquier Proyecto de Software de envergadura. Pero la irrupción de otras metodologías hace clara la necesidad de satisfacer otros aspectosque no han sido tenidos en cuenta. Esto, por otro lado, no significa que los métodos ágiles sean “balas de plata” (en términos de F. Brooks), si bien es cierto que si se encuentran en uso, debe existir algún argumento que justifique esa implementación; se me hace igualmente inevitable traer a colación las palabras de Dijkstra quien alguna vez expresó que "los errores industriales no son sacrosantos sólo porque se cometan a gran escala" , y esto aplica para ambas posturas.
El hecho objetivo es que existen disconformidades, por llamarlas inicialmente de una manera con UML, y es ahí donde radica el objetivo de este análisis.
Las razones de UML
27 Años después que Dijkstra observara que la calidad de un código fuente era inversamente proporcional a la cantidad de sentencias GO TO del mismo, esta preocupación parecía salvada con la aplicación de los conceptos de O.O., pero no evitaba que el debate siguiera abierto en cuanto al desarrollo de Software.
Existían por aquel entonces (como atestigua el conocido artículo de Richard Paige y Jonathan Ostroff “A Comparison of the Business Object Notation and The Unified Modeling Language”) numerosas notaciones que aplicaban al modelado orientado a objetos. Es en este escenario donde Jacobson, Rumbaugh y Booch desarrollan su Unified Modeling Language desde su empresa Rational, la que luego sería comprada por IBM.
Queda claro que nace por necesidad de unificar varias notaciones y nos deja como principal enseñanza la aplicación de un Modelo Iterativo e Incremental. Lección aprendida de los viejos modelos, como el de Cascada, era que el partir de un objetivo de un sistema y crear según él todo un diseño y un posterior desarrollo, podría traer consecuencias insalvables si se descubrían errores en etapas tardías del proceso.
Pero por otro lado, trajo como consecuencia la dificultad de separar las etapas. Si bien son cosas diferentes, el análisis y diseño no se encuentran diferenciados claramente en UML, y en ciertos casos puede dar la impresión que se hacen en simultaneo; esto, si bien no en todods los casos, puede representar una limitacion importante.
UML unifico un gran numero de corrientes y se convirtió en estándar, pero no era la única opción, sino la mas aceptada. Me permito solicitarle al lector que retome la cita de Dijkstra realizada al final de la introducción y que la contraste con este ultimo párrafo.
Los contrincantes caídos en batalla
El Modelo BON (Business Object Notation) era por aquellas épocas otra de las grandes opciones, y si bien su popularidad es notoriamente inferior a la de UML y (Que viva el cielo!) tiene sus fallas, perseguía entre sus objetivos una premisa que en mi modesta opinión UML no cumple: el desarrollo continuo.
Entre los objetivos de BON encontramos:
Reversibilidad, que es la capacidad de reducir el impacto de un cambio sustancial que deba implementarse en una etapa avanzada del proyecto, incluso en las etapas de implementación y mantenimiento.
La Continuidad en el desarrollo (“seamless”) es decir, reducir las actividades superpuestas, y la disociación entre otras, durante el desarrollo del soft.
En 1997 Bertrand Meyer, quien fuera el desarrollador del lenguaje de programación Eiffel, y uno de los principales adeptos a el modelo formalizado por Kim Waldén y Jean-Marc Nerson (el mencionado Modelo BON) hace notar esta falencia de UML en su polémico articulo titulado UML: The positive spin (UML: EL giro positivo). En el mismo hace, con una toque de sarcasmos que le seria de envidia del mismísimo Mikhail Bakunin, una zagas critica, aunque a veces desmedida, hacia RUP y UML y una defensa al modelo BON. Si bien no estoy de acuerdo con la totalidad del artículo, vale destacar el hecho de que Meyer se planta en la vereda de enfrente y lanza un critica sin miramientos, lo cual me parece válido utilizar hoy en dìa, a fin de re pensar lo que se entiende como políticamente correcto y que implícitamente el mercado y la industria del Software dicen entre lineas: UML es la mejor forma de gestionar un proyecto.
Se que tal vez alguno pueda sentirse ofendido por esta cuestión, pero no son las ideas las que dañan, y cuente esto tanto para BON como para UML y cualquier cosa que se le parezca, la fanatización Y radicalizacion de las ideas son lo realmente peligroso y no las ideas en si, si su generación fue en pos de un objetivo positivo.
Para los interesados, dejo un link al articulo, el cual es altamente recomendable a fin de replantearnos algunas cuestiones:
http://www.archivosbackup.com/download.php?file=593UML,%20El%20giro%20positivo%20Por%20Bertrand%20Meyer.pdf
Mas allá de las formas de Meyer, es cierto que los Arquitectos de Software a la hora de gestionar un proyecto con UML se encuentran con la complicación de encontrar el nivel de detalle adecuado y a menudo es difícil diferenciar si se esta efectuando una Ingeniería de Software o Ingenieria de Documentación. Por otro lado, no caben dudas que la aplicación efectiva de UML deja una exhaustiva documentación y no queda aspecto del desarrollo sin cubrir.
La Moraleja.
De todo este repaso sobre debates de la Ingenieria de Software podemos sacar algo en claro: no hay nada nuevo bajo el sol. La batalla no esta cerrada aun y todos los enfoques son igualmente válidos. Es decir, mientras BON aplica el concepto de Reversibilidad, UML habla de un proceso Iterativo e Incremental y las Metodologías Ágiles hablan de Iteracion, Sprint o lo que fuere, todas lo que buscan es hacer un proceso incremental en el cual los cambios tengan el menor impacto posible y puedan contemplarse todas las posibilidades y definir periodos cortos de desarrollo a fin de reducir la incertidumbre en la estimación de tiempos y. Esto puede ser bueno, dado que tenemos diferentes versiones de una misma realidad o malo si consideramos que seguimos en los mismos debates y no hemos encontrado una resolución definitiva.
Por otro lado esta claro que la naturaleza de cada proyecto determinara que metodología es apta: mientras parece ser mas apropiado aplicar una metodología ágil a proyectos que posean una cantidad de integrantes y elementos acotada, difícilmente pueda aplicarse y controlar todos los aspectos de un desarrollo grande.
Pero no hay balas de plata, no hay formulas mágicas, por lo cual siempre es saludable una revisión a lo pre establecido y una posterior adaptación al caso en análisis.