Thursday, September 29, 2011

El Proceso Unificado

Curioso mundo éste de la informática, recuerdo cuando Compaq compró la Digital, desapareciendo los sistemas Alfa, para luego ser comprada por HP, la empresa con las siglas peor escogidas de la historia.

La absorción de pequeñas empresas con éxito por otras de enorme tamaño es algo del día a día y lo mismo ocurrió con Rational, padres del Proceso Unificado de Rational (RUP) , que una vez absorvidos por IBM  pasó a llamarse Proceso Unificado (UP).

En 1995 Grady Booch, Jim Rumbaugh y Ivar Jacobson, ambos en plantilla de Rational Software, decidieron unificar tres técnicas dedicadas a modelizar objetos, la Técnica de Modelado de Objetos (OMT), la metodología de diagramas utilizados por Booch, y la Ingeniería Orientada a Objetos (OOSE). Ese fue el origen de UML.


La relación entre UML y el RUP era tan fuerte que durante años estuvo sujeta a la confusión de muchos; hablar de UML, una técnica de diagramatización, parecía forzosamente unida al RUP, una metodología.

Básicamente el UP descompone un proyecto en múltiples fases que se tratan individualmente como un proyecto separado llevado a cabo por iteración contínua y que al terminar genera salidas intermedias, denominadas artefactos y normalmente documentales que se utilizan como entradas de la fase siguiente. UML se utiliza a mansalva tanto internamente como en las interfases a modo de artefactos.

Las fases de UP pueden inicialmente recordarnos al ciclo de vida tradicional de la cascada del salmón, donde cada subfase se realiza como un proceso iterativo, que nos puede recordar también al ciclo de vida de la espiral de Boehm, el solapamiento sabernos a Shasimi... A menudo las ideas nuevas no son más que las antiguas, unidas, cambiadas de sitio y renombradas. La siguiente imágen se hizo muy conocida en el mundillo de la ingeniería del software y muchas interpretada erróneamente al pie de la letra.



Cualquier otra metodología existente puede adoptar los diagramas UML en sus distintas fases aportando, entre otras muchas, la ventaja de unificar la represantación de los sistemas arquitectónicamente orientados a objetos. Esto viene a aportar a la ingeniería del software algo común en todas las ingenierías conocidas, los planos de sus sistemas.


Wednesday, September 28, 2011

Metodologías Formales vs Ligeras

La rigidez de las metodologías formales, típicas del período previo a los años 90, definían rígidamente todo aquello relacionado con un proyecto, encontrándose una y otra vez con un efecto bien conocido: que la rigidez se adapta mal al cambio. Descartarlas no tiene sentido dado que en muchos casos tuvieron, y tienen, mucho éxito. En esencia la mayoría de las metodologías formales intenta aislar la zona de mayor cambio, la captura de requisitos, y congelarla entre entregas. Pero es de buen conocer español que "no se pueden poner puertas al campo", la cantidad de energía necesaria para mantener los requisitos congelados es enorme y supone, en gran medida, pararle los pies al cliente, cosa que no siempre es posible ni conveniente.

Por otro lado, las estrategias de las metodologías ágiles intentan mitigar la mala definición de requisitos mediante técnicas de adaptación al cambio, entre ellas el desarrollo en ciclos muy cortos, de manera que los requerimientos se mantengan congelados durante períodos breves, permitiendo la aceptación de cambios, nuevas peticiones y visibilidad de avance del proyecto aparentemente contínuos. No obstante estas ventajas también pueden verse como inconvenientes.

“En este mundo traidor, nada es verdad ni mentira, todo es según el color del cristal con que se mira.”
Ramón de Campoamor (1817-1901)


Las metologías ágiles están teniendo mucha aceptación hoy en día, pero no deben confundirse con la anarquía, por motivante que sea, conlleva mucha disciplina y ponerlas en práctica no es tarea fácil.