Buscar en Gazafatonario IT

martes, mayo 17, 2005

Problemancia y Solucionancia

De todas las preguntas, observaciones y similares que me llegan a diario y que desafortunadamente por razones de tiempo no puedo atender en su completitud, quiero referirme esta vez a algunos comentarios y cuestiones que un colega me hace, a raíz de mi artículo anterior sobre Iteraciones. Ya le respondí a él, pero luego pensé que era interesante ampliar mis respuestas y darlas a un público más amplio, porque además son una muestra representativa de los temas que siempre discuto en los grupos de trabajo.

Como siempre, los nombres y algunos datos fueron cambiados para proteger la identidad de los culpables.

Sobre RUP

Nuestro amigo empieza diciendo que “RUP no es una metodología, sino un Proceso y como tal tiene metodología y responsables de las actividades y artefactos.

Ciertamente. RUP es un proceso de ingeniería de software, ya había hecho una presentación al respecto en El Imperio de las Metodologías, así es que estoy de acuerdo con esa apreciación, sin embargo, en el contexto en el que lo uso, Proceso y Metodología son sinónimos. Ahora van a salir los puristas del idioma a decirme que eso no es cierto, que hay una diferencia bien marcada. Pero no se trata de eso, hablo de las situaciones en las que uso las palabras: metodología es un término más arraigado en nuestro medio informático que proceso, que nos suena más a algo químico. Hay que ser flexibles en ese sentido y eso me da pie para hablarles de algo más adelante sobre adaptación.

Formalmente, un proceso es un conjunto de pasos ordenados con los que se busca un objetivo; en ingeniería de software, el propósito es construir un producto de software; en el caso de RUP, esos pasos están organizados en Disciplinas que a su vez definen Flujos de Trabajo y otros elementos del proceso.

Nuestro colega sigue diciendo que “en este momento él y su equipo se encuentran desarrollando un proyecto bastante grande siguiendo los lineamentos de RUP, y por ser la primera experiencia ha sido difícil la aplicación (el proyecto es contratado con una empresa desarrolladora de Software). Están precisamente terminando la 4a iteración de la fase de Elaboración.

Ya he tenido experiencias con RUP (coincidencialmente, la primera de ellas hace algunos años, fue con un proyecto también muy grande, como el mencionado), y también ha sido complejo aplicarlo. Ha sido un proceso de adaptación y adopción, yo lo he llamado en mis conferencias “de tropicalización”. Este tipo de proyectos son escasos en nuestro medio (quiero decir, proyectos de software de varias docenas de personas y de varios años de duración), pero se dan algunas veces. La experiencia, en todo caso, ha sido enriquecedora (a veces ha sido dura, pero los resultados se han visto). En particular, celebro que estén involucrados en este tipo de procesos, creo que es la única forma de mejorar la calidad de lo que hacemos, productos de software.

Voy a hacer énfasis en esto de la adaptación y adopción. El Proceso Unificado tiene muchos “roles” responsables de esa gran cantidad de actividades y de ese enorme conjunto de artefactos que se pueden generar siguiendo el proceso al pie de la letra. Pero una de las grandes ventajas de RUP es que, aunque rígido, permite cierta flexibilización por parte de quienes lo siguen. Y aquí “seguir” es la palabra clave, como lo anotaba nuestro lector en su comentario anterior. Esto quiere decir que no debemos meternos de cabeza en el proceso, sino acomodar y aceptar muchos de sus delineamientos, teniendo en cuenta siempre las habilidades del equipo del proyecto, el tiempo de entrega y los recursos (no es lo mismo “RUPizar” con las herramientas que proporciona IBM Rational –RequisitePro, Rose, Robot, XDE, entre muchas otras, que hacerlo prácticamente con lápiz y papel, como ocurre en muchos lados a nuestro alrededor.)

Por ejemplo, es posible tener en un mismo documento (o Artefacto), La Visión del Sistema, la Especificación de Requisitos y la Especificación Suplementaria, y no en tres documentos separados como propone el proceso. Esto ahorra tiempo, esfuerzo y proporciona un mayor entendimiento del sistema en construcción: la idea es hacer encajar las partes comunes y no comunes de cada uno de esos elementos en uno solo de ellos. Es una propuesta, funciona bien, en proyectos pequeños y medianos, los que hacemos con la llegada de las lluvias.

Sobre Mecanismos de Análisis, Diseño e Implementación

Luego pasamos al tema de las preguntas, inquietudes razonables, a las que traté de dar respuesta desde mi punto de vista y soportado en mi experiencia. Aquí la primera:

Los Mecanismos de Análisis, Diseño e Implementación deben quedar en un artefacto o documento en la fase de Elaboración, necesariamente? O se pueden entregar en la fase de Construcción? Y cual sería la importancia de tenerlos en la fase de Elaboración?

Trataré de definir en palabras simples qué es esto de los Mecanismos de Análisis, Diseño e Implementación. Un mecanismo de análisis representa un patrón que constituye una solución común a un problema común. Afortunadamente para nosotros, en ingeniería de software ya existen muchos problemas documentados, y con la aparición de cada nueva plataforma o tecnología, se documenta la forma de solucionar esos problemas habituales. Puedo citar algunos ejemplos prácticos: Manejo de Errores o Fallas del Sistema, Sincronización de Procesos y Acceso a Datos. En general, los mecanismos de análisis nos permiten concentrarnos en el análisis de los requisitos funcionales, el problema propiamente dicho, y no sumergirnos en ciertas complejidades que nos pueden conducir a la llamada “parálisis del análisis”, muy temida por todos.

Entre tanto, un Mecanismo de Diseño es un refinamiento de un mecanismo de análisis correspondiente. Un mecanismo de diseño agrega detalles concretos al mecanismo de análisis conceptual, pero llega hasta justo antes de proponer una técnica particular de implementación. Tanto los mecanismos de diseño, como los de análisis pueden instanciar uno o más patrones, en este caso, patrones arquitectónicos o de diseño.

De manera similar, un Mecanismo de Implementación es un refinamiento de un mecanismo de diseño correspondiente, usando ya una plataforma o lenguaje de programación específicos. Por ejemplo, para cada uno de los problemas que mencioné arriba ya existen soluciones en una plataforma como Microsoft.Net (y supongo que en J2EE también existirán). De los siguientes enlaces pueden bajar la solución a esos problemas, cuando se trata de usar tecnología Microsoft:

Manejo de Errores o Fallas del Sistema
Sincronización de Procesos
Acceso a Datos
Y aquí pueden bajar otras soluciones comunes.

Y para responder la duda citada, los mecanismos de Análisis, Diseño e Implementación hacen parte de lo que yo llamo “documentación interna”. Efectivamente, pueden hacer parte, por ejemplo, del documento de arquitectura, en cuyo caso lo extenderían y lo harían más complejo, innecesariamente. Lo que sí debe quedar en este documento son las relaciones o el mapeo de los mecanismos de análisis con los mecanismos de diseño con los mecanismos de implementación. Estos, a su vez, sí pueden quedar en el documento de Guías de Diseño, que también es responsabilidad del Arquitecto y que hace parte del Modelo de Diseño. En cualquier caso, estos mecanismos siguen siendo un asunto “peliagudo” (no sé si entiendan el término –“complicado”), son temas algo abstractos y muchas veces prefiero evitarlos, al menos, presentarlos al cliente (aun al representante del área de tecnología), pues siempre sigo la premisa de que “modelamos para entender el sistema que luego vamos a construir”.

Ahora bien, estos mecanismos, muy tarde, deben estar para el refinamiento de la arquitectura, hacia el final de fase de Elaboración. La idea es que haya suficiente claridad al momento de enfrentar el gran grueso de Construcción y que las soluciones comunes estén quizás ya implementadas. Reusabilidad ante todo. Además de esto, son importantes en Elaboración porque son un indicador de que conocemos muy bien el sistema, su arquitectura, la forma como se va a construir e implantar y porque, precisamente, tenemos desde el inicio de la construcción un conjunto de soluciones preestablecidas.

Sobre el Modelo de Dominio

El Modelo de Dominio es indispensable como insumo del documento de arquitectura? Es decir, lo necesito como insumo para validar la vista Lógica?

De acuerdo al Proceso Unificado, un modelo de dominio es un modelo de objetos del negocio que se enfoca en “el producto, entregables o eventos que son importantes para el dominio del negocio.” Un modelo de dominio es un modelo del negocio “incompleto”, en tanto omite las responsabilidades de los individuos. El modelo de dominio típicamente muestra las entidades mayores del negocio, sus responsabilidades funcionales y las relaciones entre esas entidades.

Sin duda, el modelo de dominio es útil para validar la vista lógica de la arquitectura, pero no solo para eso, de hecho, es la base de dicha vista, creo que sin el modelo de dominio no podremos obtener la vista lógica completa y realmente tampoco estaríamos en capacidad de avanzar mucho, porque no tener el modelo de dominio indica que todavía no conocemos lo suficiente el sistema. Sin embargo, en la práctica, el modelo de dominio evoluciona hasta la fase de Construcción, cuando todavía desarrollamos casos de uso que no se trataron en Elaboración.

Sobre Casos de Uso Significativos

Cuántos casos de uso sería aconsejable desarrollar en la fase de Elaboración para definir la línea base de arquitectura?

Cuántos casos de uso? Muchos. Depende del número total de ellos. La última palabra sobre este tema no está dicha ni aceptada, pero podríamos estar hablando de más del 60% de los casos de uso, al terminar la fase de Elaboración. Los que sí deben estar terminados son los casos de uso significativos para la arquitectura, aquellos que tienen mayor impacto sobre la misma.

Con una docena de casos de uso seleccionados como arquitectónicamente significativos de más de mil casos de uso identificados hasta el momento (final de la fase de Elaboración), puedo decir que mi arquitectura es estable? Estos casos de uso arquitectónicamente significativos se escogieron teniendo en cuenta el riesgo tecnológico que representaban para su implementación desde el punto de vista técnico.

Una docena de casos de uso me parece un número muy pequeño comparado con más de mil de ellos. Desde el exterior, y desde mi perspectiva, no creo que podamos hablar de una arquitectura estable. Si seguimos los delineamientos de elaboración de casos de uso, por lo menos, deberíamos tener un centenar o más de ellos arquitectónicamente significativos. Ahora bien, mil casos de uso es un número muy grande para un sistema, yo diría que exageradamente grande, dado que los casos de uso son el medio a través del cual los usuarios (aunque no siempre es así) se comunican con el sistema. Estamos hablando entonces de que el sistema en construcción tiene más de mil maneras de acceder a el. Lo veo complejo desde aquí. Recordemos además que un caso de uso puede tener más de un escenario o secuencia alternativa, con lo que estaríamos hablando tal vez de miles de escenarios. Mucho, pienso yo.

Se debieron escoger Casos de Uso Arquitectónicamente significativos desde el punto de vista de los usuarios o stakeholders y que representen la funcionalidad de negocio? De no tenerse en cuenta estos casos de uso, qué riesgo presenta la definición de la línea base de arquitectura?

Sí, se debieron (se deben) escoger. Pero con mucho cuidado. Algunas veces los usuarios piensan que un caso de uso (una funcionalidad es compleja o significativa) porque simplemente hacen uso de miles o millones de registros en muy poco tiempo y resulta que quizás para nosotros el asunto se resuelve con un algoritmo implementado en un procedimiento almacenado, para lo que se supone somos expertos.

Si el usuario nos dice, por el contrario, que sin importar el sitio de origen, la transacción debe llegar al servidor central y responder al usuario en menos de cinco segundos, así la transacción sea traer unos datos básicos de un cliente dada su cédula, usando los canales existentes en la compañía, entonces sí que debemos preocuparnos. Y como este hay muchos casos que se deben tener en cuenta a la hora de seleccionar los “significativamente arquitectónicos”.

Sobre La Vista Lógica

La vista Lógica me debe mostrar el Core de mi negocio? O que esperaría ver en ella?

El “core” del negocio debe reflejarse de alguna forma en la vista lógica si el sistema Es para el “core” del negocio, de lo contrario no. En cualquier caso, la vista lógica muestra paquetes de alto nivel, subsistemas, clases y las realizaciones de casos de uso. Observemos que si el sistema es “core”, las clases del dominio reflejan precisamente el negocio.

Conclusiones

Y bueno, como recomendación adicional, les sugiero que traten de “platanizar” RUP, como dicen algunos de mis colegas, adoptarlo, sí, pero adaptarlo a nuestros recursos, a nuestras habilidades, a nuestro entorno, donde no tenemos el tiempo ni el presupuesto de los grandes proyectos de otros lados. Quizás combinarlo con prácticas ágiles y obtener una “metodología” acorde al medio.

Como siempre, los invito a que compartan conmigo y con todos sus comentarios acerca de este artículo. Me pueden escribir a luissalazar@usa.net o en http://gazafatonarioit.blogspot.com/.

Luis Antonio Salazar Caraballo

Medellín, Noviembre 4 de 2003