Glosario del Proyecto

Un Glosario contiene las definiciones de los términos propios de un proyecto o actividad. Este artefacto es importante, ya que es la base para lograr un vocabulario común entre los grupos relacionados con el desarrollo del proyecto.

Hay que recordar que aunque nuestra lengua posee un diccionario que la resume, cada quien da connotaciones diferentes a las palabras, por lo que los términos en uso, sufren de un proceso de deriva que los aleja de su significado común. Por otro lado, en muchas profesiones se da el fenómeno de utilizar palabras extranjeras, a las que se le otorga un significado preciso muchas veces de gran importancia.

Difícilmente podremos encontrar un proyecto en que no se justifique mantener un Glosario completo y detallado. Las palabras tienen un gran poder de síntesis, por lo que nuestros clientes podrán darse a entender más fácilmente si saben que les oímos en sus propios términos. Pero también es cierto que las palabras poseen un gran poder de análisis por lo que ser capaces de modelar el vocabulario del proyecto es un paso importante para modelar el dominio del problema y hallar el diseño de una solución.

Las palabras correctas muchas veces son en si mismas, el diseño correcto. Durante miles de años los seres humanos nos hemos esforzado en darnos a entender con palabras, por lo que nuestras mentes ya vienen equipadas con poderosos instrumentos de abstracción los cuales podemos ahora reutilizar con miras al desarrollo de aplicaciones.

De hecho, una de las heurísticas más simples para encontrar clases en un desarrollo orientado a objeto es precisamente el análisis[1] sujeto/verbo/predicado hecho sobre las sentencias del enunciado del problema. Una técnica sencilla y efectiva en ocasiones, que no nos pide mucho para mantenerla en la mira.

¿Son necesarias más razones para justificar el esfuerzo invertido en un Glosario? Veamos un resumen de sus ventajas:

• Define un vocabulario común con el cliente
• Delimita una suerte de mapa mental que sirve para el análisis
• Da pistas sobre conceptos importantes que son candidatos a clases

Así llegamos a la conclusión: en todo proceso de desarrollo conviene mantener un Glosario. Muy bien, ¿como lo hacemos?

A partir de la plantilla Documento del Proceso elaboramos una nueva llamada Glosario, en la cual tendremos la familiar estructura de Entrada/Acepción a la que nos tiene acostumbrados todos los diccionarios.

En adición a la simple definición del término, debemos mantener una lista de sinónimos y homónimos para cada una de ellas, de manera de agilizar el uso del Glosario manteniendo referencias entre las entradas.

Los sinónimos, palabras diferentes que tienen igual significado, son causa de confusiones cuando uno entiende cosas ligeramente diferentes con cada uno de ellos, por lo que normalizamos el vocabulario poniendo sobre aviso a todos los involucrados sobre cuales sinónimos se encuentran en uso dentro del proyecto. Por ejemplo, una entrada del Glosario podría indicar que como sinónimo al término Departamento de Ventas se suele utilizar las siglas DV.

Pero mucho más peligrosos son los homónimos, palabras con significado diferente que suenan o se escriben igual. Las confusiones que los homónimos generan son mucho más graves y en realidad nos conviene mantenernos alejados de ellas.

Si para uno o más términos no se encuentran sinónimos u homónimos, coloquemos Ninguno o quizás No Aplica, como prueba de haber considerado estas entradas habiendo decidido con consciencia de lo que se hacía, que no hay algo que sea pertinente colocar. Por otro lado dejar en blanco estas secciones es ambiguo: quizás es que se nos olvidó, quizás es algo intencional.

Eso es todo. Como parte de su proceso de captura de requisitos es necesario ejercer la actividad de desarrollar un vocabulario común para lo cual es imprescindible un Glosario. Afortunadamente este es un documento fácil de crear y mantener, que en adición a lo anterior nos ayudará en el análisis e incluso en el diseño. Toda una ganga que no podemos dejar pasar.

Documento del Proceso (II)

Según las practicas comunes en cada lugar u organización, los elementos comunes de los documentos vienen dispuestos en distintos lugares del mismo. Un ejemplo de esto es el Indice de Contenido, el cual suele colocarse de primero o en las primeras páginas del documento en Venezuela y otros países de habla española, en tanto que en USA muchas veces es colocado de ultimo.

Diferencias como la anterior no nos deben llamar a la admiración ni constituire en un problema. De todos modos, cada artefacto del proceso, e incluso el proceso mismo de cada organización debe ser adaptado a sus propias necesidades y costumbres, por lo que tener el indice en un lugar distinto al sugerido en metodologías como RUP es algo muy natural.

Por otro lado, si bien la disposición de los elementos comunes puede variar, debería tenerlos en algún sitio bien definido de sus documentos, ya que recogen información útil sobre los pasos del proceso.

Finalmente, una lista parcial de elementos para que los tenga en consideración:

• Identificación del documento: Título, Proyecto y Versión.
• Identificación del autor: Nombre e información de contacto.
• Identificación de quien aprueba, en caso de requerirse una aprobación.
• Historial de versiones del documento.
• Glosario de términos utilizados.
• Glosario visual de los iconos utilizados.
• Alcance del documento, esto es, identificar que parte del proceso o del sistema que se cubre en el documento. Por ejemplo Arquitectura del Sistema: Módulo de Atención al Cliente.
• Artefactos tomados como entrada, indicando nombre y versión.
• Artefactos generados como derivados, indicando nombre.
• Anexos.
• Indice de Contenido.
• Indice de Figuras.
• Indice de Tablas.

De la lista anterior, tome lo que considere que se justifica para su organización. Es importante que mantenga el alcance del documento, así como la relación de artefactos en entrada y salida, ya que esta información le ayuda más adelante con las trazas de requisitos.

Coloque los nombres de las secciones y escriba pequeñas secciones de introducción a cada sección. Añada además las notas e indicaciones para los futuros usuarios de su plantilla. Recuerde que estas plantillas serán llenadas por seres humanos, por lo que las indicaciones en cuanto a estructura, forma y contenido que pueda ir planificando desde ahora le harán la vida más sencilla en un futuro. Todo esto será de utilidad cuando intente en realidad hacer su trabajo con ayuda de la documentación que produzca.

Documento del Proceso

A diferencia del Documento en Blanco, este nuevo artefacto posee una estructura visible. No solo se han utilizado aquí los margenes y estilos definidos en la plantilla de base -la de Documento en Blanco, tengamos presente- sino que se han añadido elementos que serán comunes a todos nuestros documentos a lo largo y ancho de nuestra organización.

Sugiero que las plantillas sean vistas como una jerarquía de clases de documentos. De esta forma, Documento en Blanco seria el objeto raíz dependiente de plataforma y la plantilla Documento del Proceso sería nuestra raíz independiente de la plataforma pero definida enteramente para las necesidades del proceso.

Me explico: la plantilla Documento en Blanco tendrá opciones propias del editor de textos que utilicemos, fijadas de forma tal que todos los documentos que se escribamos sobre está tengan un aspecto uniforme. Por tener en su diseño consideraciones del procesador de textos, le llamo a esta plantilla “dependiente de la plataforma”.

Por otra parte, la plantilla de Documento del Proceso es diseñada pensando exclusivamente en la organización común de los documentos a desarrollar en la organización. Ahora las opciones exactas de formato no son nuestro problema. En su lugar nuestro objetivo es enteramente la estructura del documento y la forma en que se utilizará. Esto es, la plantilla es “dependiente del proceso”.

Según cuales sean nuestras influencias metodológicas, la estructura de este documento puede cambiar. Sin embargo parece razonable que deberá incluir información de identificación suficiente, quizás un historial, y anexos tales como un glosario.

Fije usted toda esta estructura en la plantilla. De ser necesario coloque pequeños comentarios sobre el propósito de cada sección. A estas indicaciones las hemos de colorear o adornar de forma tal que nadie dude que son comentarios para el redactor de documentos, y que por tanto no deben estar presentes en ningún documento entregado.

Suerte en este nuevo artefacto, a partir de aquí los documentos comenzarán a tener un estructura que refleje nuestra manera de trabajar, así que nos tendremos que poner un poco más formales y sugerir organizaciones precisadas en mayor detalle.

Estaremos en contacto.

Documento en Blanco

El joven Johannes se levantó aquel día como todos los días. Con la obligación de ir al trabajo, pero con un peso del alma tan grande, que a duras penas pudo bajar a la cocina a tomar el desayuno.

Su madre le advirtió “come toda tu comida, o las brujas se la llevarán” broma con que siempre le animaba a comer antes de ir a lo que él imaginaba como un horrible trabajo: un centro de copiado de libros. Ahí la labor era pesada y solo la tradición familiar junto a la necesidad de comer, le lograban convencer de ir.

Las responsabilidades de Johannes incluían el tallado de los tipos, pequeñas fichas con la forma de las letras. También se encargaba, cuando su tío el jefe estaba de buen humor, de montar las páginas para su impresión. “Ojalá me permita imprimir hoy” era un pensamiento cotidiano pero que pocas veces se lograba convertir en realidad. Solo los talladores más experimentados podían recibir la confianza suficiente como para arriesgar todo ese precioso trabajo de crear los tipos en la impresión de una hoja de texto. Corria el siglo XV y los libros eran cosa muy delicada.

Así Johannes dedico la mayor parte de su vida a una labor pesada de la que no gustaba. Su sueño fue siempre lograr una forma simple de hacer su trabajo. No podía dedicarse a nada más, así que siguió su instinto e inventiva y termino dando al mundo un objeto de lo más transcendental: la imprenta.

Johannes Gutenberg diseño la imprenta de tipos móviles luego de años de esfuerzo y desarrollo. Todo lo que invirtió en ella le pareció poca cosa, al lado del esfuerzo extraordinario que demandaba el copiado de un libro en sus días.

Cada letra tallada por separado, cada página compuesta a mano, cada folio impreso con cuidado y esmero, y sin embargo todo ese esfuerzo se perdía en poco tiempo dada la fragilidad de los tipos utilizados. La gran novedad de la imprenta no era la técnica en si misma, sino la posibilidad de agilizar el trabajo al simplificar la creación de las letras y la composición de las páginas. Gutenberg utilizo metal para los tipos y pequeños moldes que le permitían crear todas las letras que quisiera con un poco menos de trabajo manual.

Es admirable lo mucho que ha avanzado la tecnología. Hoy en día generamos documentos en pocos minutos, dedicando poca atención a toda la infraestructura que es necesaria para lograr tener una hoja de papel con nuestro pensamiento plasmado en ella.

Quizás las opciones de formato de un procesador de texto moderno no sean tan difíciles de usar como una imprenta de los tiempos de Gutenberg, pero es una irresponsabilidad el pensar que solo por esa facilidad nadie debe ocuparse de los detalles detrás de cada documento.

Es mi tesis aquí, que incluso una humilde hoja en blanco -con sus opciones de margenes, estilos de edición predeterminados, cabezas y pies de página- debe ser objeto de cuidadoso diseño.

No solo para respetar la memoria del joven Johannes y de todas esas comidas que las brujas no se comieron, sino para lograr también, que nuestros documentos tengan un aspecto uniforme y que a lo largo del tiempo, sea más fácil el leerlos.

Recuerde: los procesadores de palabras modernos tienen muchas opciones de formato, no querrá que sus proyectos tengan aspectos diferentes para sus documentos ni mucho menos, que esto pase dentro de un mismo desarrollo.

Así que vaya ahora mismo, y comience a definir como es para su organización, un documento en blanco.

En Rumbo a un Proceso Definido (II)

Sin duda alguna, la creación de un sistema de información es la construcción de uno o más programas. Y como tal, la actividad de crear programas es conocida por todos los estudiantes de programación e informática del mundo. De hecho, el primer impulso del novato es intentar crear el sistema, armado únicamente con la secuencia simple de pasos que aprendió en sus cursos de programación básicos: Editar, Compilar y Probar.

Hay que reconocer dos virtudes de este enfoque: es fácil de entender y es iterativo. De momento, pese a que más tarde hablaremos de sus limitaciones, utilizaremos el Proceso Trivial de Desarrollo como caso de ejemplo de Proceso Definido.

Después de todo, de definir un proceso pues este puede ser uno cualquiera. Idealmente uno va a definir un buen proceso, pero vale el ejemplo de momento, con un proceso trivial.

Fig 1. Esquema de Trabajo Trivial

Lo anterior es un Flujo de Trabajo. Tiene un punto de inicio y otro de fin, representados por los puntos de arriba y abajo, respectivamente. En medio, las actividades se indican con cuadros conectados con líneas, siguiendo el orden de los sucesos. Los pequeños rombos representan decisiones que modifican el flujo: aquí, según si el programa está completo o no, se repite el ciclo entero. Por ultimo, los cuadros azules representan documentos o artefactos del mundo real, que son intercambiados como parte del flujo de actividad.

Este pequeño dibujo incluye otra característica que quiero resaltar ahora. Dado que la decisión del final -¿está completo el programa?- genera una repetición completa del ciclo de desarrollo, hablaremos de este y de la línea de flujo que sube al principio, como Lazo de Iteración. Una idea que mencionamos aquí como referencia futura.

Como sea que el propósito es contar con un Proceso Definido, lo siguiente que debemos hacer es identificar a nuestros trabajadores e indicar sus responsabilidades. Esto lo podemos hacer con ayuda del siguiente dibujo:

Fig 2. Definición de las tareas del Programador

En el Proceso Trivial de Desarrollo, el único Trabajador es el Programador. Por esto nos basta de momento con su definición. En la figura 2, se ve que él está encargado de las tareas de Editar, Compilar y Probar. Las mismas que han sido presentadas en el Flujo de Trabajo de la figura 1, ahora organizadas según quien las realiza – en nuestro caso, todo lo hace el programador.

Incluso podemos avanzar e indicar el detalle de cada una de las Actividades o Tareas del Programador. Esto lo hacemos indicando las entradas y salidas de la actividad, como se ha hecho en la siguiente figura.

Fig 3. Detalles de la Tarea Compilar

En la figura 3, la sección de la izquierda indica las entradas, la derecha las salidas, y la central señala con precisión que actividad va a ser realizada y quien es su responsable.

Claramente para realizar la actividad de compilar, el programador necesitará de algunas herramientas. Entre otras:

• Computador con sistema operativo instalado.
• Compilar del lenguaje utilizado en el proyecto.
• Paquetes de las bibliotecas utilizadas.
• Herramientas de construcción.

Para cada uno de estos puntos se hace referencia a productos concretos, que deben ser licenciados e instalados antes de poder ser utilizados. La idea es saber que herramienta en especifico se va a utilizar y tenerla a mano para cuando se necesite.

Lo anterior es solo un ejemplo, pero si incluimos convenientes plantillas y recursos de ayuda a las actividades, habremos definido para el así llamado Proceso Trivial de Desarrollo los cuatro componentes de un Proceso Definido: Trabajadores, Herramientas, Flujos de Trabajo y Plantillas.

¿Es esto todo lo que es un Proceso Definido? En esencia, así es. Tenemos un enfoque sobre como hacer el trabajo, lo hemos normalizado con un flujo explicito, lo alimentamos con herramientas y plantillas, y hemos asignado las actividades involucradas a un trabajador con un rol y misión bien definidos.

Cuando una organización ha definido sus procesos en una forma similar a la anterior, se encuentra en la capacidad de disfrutar de muchas virtudes, por ejemplo:

• Puede adquirir las herramientas más idóneas.
• Puede mejorar sus practicas de entrenamiento.
• Puede reproducir casos de éxito en otros proyectos.
• Puede identificar recursos útiles para proyectos siguientes.

Entre otras posibles ventajas.

Realmente nos conviene contar con procesos bien definidos en nuestras organizaciones de desarrollo de software. Sin embargo una advertencia: un proceso definido no es necesariamente un buen proceso. Uno puede definir e incluso automatizar un proceso ineficiente o limitado. Tal cosa nos conduciría a una especie de ineptitud organizada, no a una organización eficiente.

Entonces finalmente, ¿qué es lo malo con el Proceso Trivial? Pensemos en algunas de sus limitaciones y en el futuro próximo definiremos mejores procesos que nos ayuden a superarlas. He aquí, una lista breve de problemas con el Proceso Trivial:

• No es escalable. Contempla un solo Programador. No hay indicaciones sobre Equipos de Programadores.
• No hay gestión de requisitos. De alguna manera, en este proceso son los programadores quienes interpretan los requisitos del cliente y son ellos también quienes visualizan una forma de atenderlos.
• No hay un manejo de la Arquitectura. La aplicación es construida como una colección de pequeños aportes más o menos independientes. No hay actividades orientadas a definir y mantener un diseño a gran escala.
• No hay forma de medir la duración. No hay una forma clara de saber cuanto tiempo se va a llevar el proyecto. ¿Una semana? ¿Un mes? ¿Un año? No hay ningún soporte previsto para esto.

Entre otros mucho problemas. La lista podría seguir y seguir por docenas de puntos problemáticos. En alguna forma, espero poder atacar todos estos problemas con ayuda de procesos más robustos, que sin llegar a ser pesados en exceso nos puedan dar una plataforma cierta y estable para atacar proyectos complejos. Proyectos complejos como los de hoy en día.

Este artículo continua En Rumbo a un Proceso Definido (III), puede ver el comienzo de la serie En Rumbo a un Proceso Definido.

Por ultimo, menciono que los gráficos han sido elaborados utilizando la herramienta Dia y retocados en menor grado con Gimp. Todos los gráficos son esencialmente compatibles con UML si bien han sido sometidos a un proceso conocido como estereotipado, ya que aquí y allá he utilizado iconos alternativos. Ambas herramientas utilizadas son proyectos de software libre y están disponibles para todas las plataformas en uso corriente.

Definimos Iterativo Incremental como…

Qué fue primero: ¿el huevo o la gallina?

Anónimo

Se dice que Charles Darwin hizo una de las más grandes colaboraciones al pensamiento occidental cuando dio al conocimiento publico su ahora famosa Teoría del Huevo y la Gallina. En ella, nuestro amigo ingles nos explica que las estructuras complejas, tales como los seres vivos, pueden ir variando en el tiempo, sometidos como están a presiones de selección, con lo cual “unos ganan y sobreviven, y otros encuentran potenciales obstáculos en su camino. Unos viven y se reproducen y otros mueres y son olvidados”. De esta forma, no hubo un primer huevo ni una primera gallina, existieron seres anteriores que ni nacieron del huevo ni mucho menos fueron gallinas, que cambiaron poco a poco en el tiempo hasta que un día, despertar con que eran gallinas ponedoras de huevos.

También encontró el amigo Darwin, que bajo el nombre de Teoría del Huevo y la Gallina su propuesta no iba a encontrar el apoyo deseado, por lo cual cambió el nombre de esta por el de Teoría del Cambio por Dar Vueltas e Incrementar cada vez. Un nombre quizás muy largo, pero que expresaba que siempre que se daba una nueva generación (o iteración) el avance no esta asegurado, sino que en su lugar lo que se logra es una variación del concepto original, quizás mejor, quizás peor.

Finalmente se decidió por el nombre de Evolución, tomando prestadas las técnicas de formación de palabras de las lenguas clásicas como el Latín. Sin embargo hay que recordar que algo evoluciona cuando da vueltas sobre algo, y que este movimiento circular da lugar a la mejora solo como un efecto secundario.

Reconozco que lo dicho hasta aquí es solo un trabajo de ficción, pero es que me es muy fácil imaginar a la Evolución como una técnica de trabajo en la construcción de sistemas complejos. Se parte de una idea simple, fácil de implantar, y se va variando esta, dando vueltas y más vueltas sobre el concepto deseado, hasta ver que uno se ha acercado al objetivo tanto como para darse por satisfecho.

Con todo, lo anterior no tiene nada de específicamente biológico. De hecho, es una aproximación enteramente valida al problema de la construcción de sistemas software; donde el resultado es más complejo que lo que podemos construir con una sola pasada por nuestros procesos de análisis y diseño de aplicaciones.

Considerando todo lo anterior, estamos listos entonces para definir Proceso Iterativo Incremental.

Proceso Iterativo: se dice que un proceso es iterativo cuando sus pasos se repiten una y otra vez, como en un ciclo. Al dar por concluido el ultimo paso, se procede con el proceso entero desde el comienzo.

Y por tanto:

Proceso Iterativo Incremental: se dice que un proceso es iterativo incremental cuando en cada iteración de sus pasos se alcanza una mayor cercania con los objetivos finales. Esto es, se añade algo nuevo de valor en cada iteración.

Siempre que estamos ante la construcción de un sistema complejo, vale de mucho recordar al problema del Huevo y la Gallina. La naturaleza nos ofrece un sistema complejo, auto definido, como lo es la relación huevo – gallina, puesto a funcionar casi en forma mágica, y en el que prácticamente no quedan referencias a como fue construido.

¿Quieren una receta para el éxito? Copiemos a la naturaleza. Ha venido funcionando desde hace millones de años y tal parece que no necesita administración ni mantenimiento. Por esto, construyamos nuestros sistemas software complejos, siguiente la simple receta de ser Iterativo e Incremental, tal y como lo son el huevo y la gallina.

En dos frases: comenzar con algo sencillo, repetir los pasos de análisis y diseño, incrementar el código. Repita tantas veces como sea necesario hasta alcanzar los objetivos de su proyecto. Eso debe ser suficiente.

En Rumbo a un Proceso Definido

A la pregunta, ¿qué es un proceso definido?[1] siempre le sigue ¿como asumimos un proceso así?. Ambas son preguntas muy lógicas, que intentaremos responder a la medida en que avancemos con este blog.

Veamos de cerca la primera: ¿Qué es un Proceso Definido?. Anteriormente habíamos intentado una definición, ahora hagamos una aproximación gráfica, con ayuda de unos inocentes dibujos.

Fig 1. Paquete UML que representa un Proceso Definido

La Figura 1 representa una visión de conjunto, sin detalles por el momento, de un Proceso Definido. Veamos luego con detalle lo que esto representa, pero de momento hagamos la siguiente abstracción: un proceso definido es un conjunto de cosas -un paquete- que se manejan como un conjunto y que se asume como practica diaria.

Puede resultar interesar observar que existen infinitos posibles Procesos Definidos de desarrollo del software. De hecho, cada organización que asuma este método de desarrollo en cierta medida tendrá que crear su propio Proceso.

Hoy por hoy, el Proceso Unificado se erige como el método de desarrollo de software por Proceso Definido, más importante. De este método hablaremos en detalle a lo largo de la vida de este blog, ya que es la referencia número uno en esta forma de pensar sobre el trabajo de desarrollar aplicaciones y sistemas software.

Del Proceso Unificado (UP) existen numerosas variaciones, siendo la más conocida la variación comercial RUP. Un punto de partida para conocer de esto es la Wikipedia, como siempre, una fuerte de información general invaluable.

Veamos ahora un poco del contenido de nuestro paquete Proceso Definido.

Fig 2. Contenido del Proceso Definido

En una primera aproximación, un Proceso Definido ha de incluir una visión detallada de entre otras cosas, lo siguiente:

1. Trabajadores. Identificando sus responsabilidades y habilidades requeridas. Es tentador llamar Rol a esta idea, ya que un mismo ser humano puede desempeñarse como varios Trabajadores del Proceso, pero es que en UML la palabra rol ya fue reservada para algo bastante especifico.
2. Herramientas. Enumerando cuales están a disposición de los trabajadores y cual función cumple cada una. Como parte de las herramientas se debe contar con todo el equipo, licencias, manuales, y demás elementos físicos que son necesarios para llevar a cabo las actividades de los Trabajadores.
3. Flujos de Trabajo. Del inglés workflow, se detalla la forma y el momento en que el Proceso fluye de una actividad a la otra. Los pasos de estos flujos son ejecutados por los Trabajadores utilizando las Herramientas, aunque quizás con algo de apoyo de los Clientes.
4. Plantillas. De manera de no comenzar un trabajo desde cero. Después de todo, no es la primera vez que se hace un proyecto de esta naturaleza, por lo que es factible tener plantillas con todo lo que es común a cada producto del Proceso. Llámese documento, código, diagrama, o cualquier otra cosa.

Así la cosa, para que una organización asuma un Proceso de desarrollo bien definido, vale mucho comenzar por precisar cuales trabajadores, herramientas y plantillas integran el proceso, así como pensar claramente en la secuencia de pasos que se han de dar para cumplir con lo pautado en los proyectos. Esto es, conviene pensar en definir las cosas en lugar de dejarlas para el día a día.

Cuando una organización adquiere un Proceso Definido de un proveedor, lo que en realidad compra es un conjunto de directrices, plantillas, manuales, herramientas, asesoría y recomendaciones, que han sido pensadas como un todo orgánico, y que en su conjunto permiten a la organización destino, desarrollar software.

Y es que, guerra avisada no mata a soldado. Siempre y cuando este vaya con la suficiente preparación. Esa es la filosofía detrás de todo Proceso Definido. Dejar por fuera la improvisación y dar la bienvenida a todo lo que nos ayude a conocer los detalles del camino por seguir.

Este artículo continua en En rumbo a un Proceso Definido (II).

Por ultimo, los gráficos de este post son compatibles con UML 1.4, y fueron obtenidos utilizando la herramienta ArgoUML. Un proyecto de software libre que elabora un modelador de UML. Aunque es cierto que existen muchas otras herramientas de mayor poder, ArgoUML se destaca por ser sencillo, multiplataforma y libre. Vale la pena darle una mirada y considerar su uso. Al menos en proyectos sencillos.

Definimos Visión como…

“Caminante no hay camino, se hace camino al andar…”

Joan Manuel Serrat

Idea romántica sin duda, la del amigo Serrat. Sin embargo es también una idea muy inquietante si un día consideramos aplicarla a nuestros esfuerzos de desarrollo. Si no hay camino salvo el que se logra día con día, entonces hoy no sabemos que vamos a estar haciendo el miércoles, el jueves no tendremos idea de en que andaremos el mes proximo y cuando se nos pregunte por el proyecto y sus resultados no sabremos más que responder “con fe, que la vida no puede ser vivida así con tanto estrés”. Aunque esta frase no este en la canción de Serrat.

Seguramente nuestros clientes, asustados por nuestra despreocupada actitud, cancelará sus proyectos e irá a donde otro proveedor, quizás menos capaz, pero que al menos le sepa decir en que andan sus asuntos.

Esto es así y no de otra manera. Cuando uno se enfrenta a un proceso largo y complejo, la naturaleza diferenciara entre dos clases de lideres: aquellos con visión y aquellos que harán su camino al andar.

Visión: capacidad de ver los detalles del camino por delante aún antes de haber comenzado a andar.

Como he dicho en otras ocasiones, no gusto de la emoción en un proyecto de desarrollo. Nada mejor que un trabajo aburrido que cumpla con lo pautado, se ajuste a los costos y que cree valor de negocio para el cliente. Y para lograr este factor de previsibilidad en un proyecto, es imprescindible contar con una generosa dosis de visión.

La visión sobre el proyecto puede ser detallada a lo largo del proceso mismo. Esto significa que como parte de un proceso definido, se pueden establecer reglas y actividades que conduzcan al logro de esa visión detallada. Y como integrante del proceso, seguramente el encontrar la visión va a estar apoyado en una serie de plantillas de documentos, consejos de estilo y actividades más o menos definidas a ejecutar con el cliente o entre los miembros del equipo de desarrollo.

Visión del Sistema: descripción de las características del sistema, generalmente desarrollada como parte del proceso de captura de requisitos, y que suele estar contenida en un documento de texto.

Y también

Visión del Proyecto: también conocida como Caso de Desarrollo, es la visión de los modos, hitos y tareas que se ejecutarán durante el proyecto. Detalla cuales actividades se prevé realizar y cuales son las dependencias entre los distintos productos del proceso.

Poco a poco, que nadie espera que se cuente con un plan de rutas completo cuando el camino es nuevo. Sin embargo la pretensión de empezar un proyecto sin una visión clara es igual a improvisar, quizás el mayor pecado que se puede cometer en un proyecto de desarrollo.

Finalmente, a quien quiera escuchar la canción, una visita a Youtube les dejara oírla.

Definimos UML como…

Imaginemos de momento, una reunión entre el cliente y los ingenieros responsables de una obra en construcción. Digamos un puente o un edificio alto, da igual. En esta escena, seguramente se discuten temas importantes: ¿Cuando estará terminada la obra? ¿Estará ajustada al costo? ¿Estamos atrasados? Digan de nuevo ¿como es que se va a hacer esto?

Los ingenieros civiles así como los arquitectos presentes, se apresuran a explicar al cliente el estado de la obra, presentando en todo momento lo muy bien ajustado que esta la construcción a la planificación y al plano del edificio.

Esto es, a pesar de tener algo muy concreto que mostrar (¡y ese algo es hecho de concreto!) los arquitectos intentan mantener la calma y la confianza del cliente demostrándole que la obra física esta en sincronía con un papel muy grande lleno de líneas y letras, a las que de cariño llaman el plano de la obra.

Curiosamente el cliente se muestra satisfecho, solicita unos pequeños cambios y se retira de la reunión renovando sus votos de confianza en el equipo constructor.

Ahora imaginemos una reunión entre este mismo cliente, buen hombre que esta ocupado en mil y un proyectos diferentes, y un equipo de desarrollo de software. En esta escena, seguramente también se discuten temas importantes: ¿Cuando estará terminado el sistema? ¿Estará ajustada al costo? ¿Estamos atrasados? Digan de nuevo ¿como es que se va a hacer esto?

Hay que ver que son las mismas preguntas… ¿no es razonable esperar la misma reacción de los ingenieros presentes? Ok, son ingenieros de software en esta ocasión, pero la verdad es que desde un punto de vista psicológico, nuestro cliente esta esperando lo mismo que lo tranquilizo en su primera reunión. Él quiere ver un plano.

UML notación gráfica utilizada para describir sistemas de software. En su sentido más amplio, puede ser utilizado para representar desde los requisitos iniciales, pasando por el detalle del diseño y así hasta llegar a los detalles de la instalación y uso del sistema desarrollado.

Naturalmente que tratándose de la profesión experta en hacer modelos de sistemas es obvio que el UML tenga cualidades similares a estos; es así que los elementos del lenguaje visual UML se encuentran definidos en forma tal que constituyen ellas mismas un entramado de partes y relaciones, es decir, un sistema.

Dicho sistema de definiciones, organizadas y sistematizadas, presentadas en gloriosos y detallados documentos de definición es el resultado del Grupo de Gestión de Objetos u OMG por sus siglas en inglés. Dicho grupo es el responsable no solo de la especificación de UML, sino de otras tecnologías clave en la industria como Corba.

La construcción del UML es un trabajo que solo puede ser entendida aplicando al lenguaje en si, los mismos principios que se aplican en el desarrollo de software de calidad. De acuerdo con la OMG, la organización modular de la definición garantiza el cumplimiento del principio de abierto cerrado o en otras palabras, que nuevas características, elementos de modelado e incluso nuevos lenguajes visuales completos, pueden ser definidos a partir de los elementos del UML, sin dañar el entendimiento de los elementos reutilizados y permitiendo la interoperabilidad de las herramientas así como de los conceptos integrados en los modelos.

El elemento más conocido del UML desde el punto de vista de los usuarios del mismo, es el diagrama; o presentación visual de elementos y relaciones en sintaxis UML; este elemento es equivalente a un plano individual del sistema. Existen gran variedad de diagramas dentro de UML por lo que estos a su vez, son objeto de clasificación, conociendo en forma inicial los diagramas que presentan información estructural o estática, por oposición a aquellos que presentan información dinámica o del comportamiento del sistema. Es decir, que con UML tendremos todas las vistas deseables para documentar nuestras ideas sobre el software o sistema cuyo modelo estemos construyendo.

A efectos de tener un ejemplo, he de decir que la inmensa mayoría de las ilustraciones de este blog son en realidad diagramas UML, creados en concordancia con las reglas del lenguaje con ayuda de software especial de dibujo. Así que si se ven algunos artículos tales como ejemplo de análisis de caso de uso, se tendrán un buen conjunto de ejemplos de diagramas bien construidos.

Más adelante voy a documentar cada uno de los tipos de diagramas, así como los mecanismos por medio de los cuales funcionan las definiciones de los mismos, con miras a presentar, no solo el modo en que el UML es utilizado directamente la construcción de vistas del sistema, sino también en como lo podemos extender y personalizar a fin de contar con una herramienta de modelado que sea mucho más que solo cajas y rayas.

Definimos Proceso Definido como…

Dios no hizo al hombre ni a la mujer para estar solo. Eso se le dice a la gente que no se quiere casar, para resaltar la importancia de la vida en pareja así como en comunidad.

Cierto, el matrimonio es un asunto complejo. Pero sin entrar en comparaciones, el proceso de desarrollar un sistema de software es también muy complejo y propenso a los problemas… justo igual a un matrimonio.

Aquí el punto clave es el hecho, simple y contundente, que las exigencias que el cliente o usuario tiene sobre sus sistemas de software no pueden ser satisfechas por el trabajo en solitario de un solo individuo. Los tiempos en que bastaban unas pocas líneas de código para generar un programa ejecutable útil para alguien, se han ido ya hace mucho y no se espera que vuelvan en el futuro cercano.

Entonces, si los sistemas de software van a ser desarrollados por grupos de personas, mas nos vale empezar a pensar racionalmente sobre el matrimonio.

En un matrimonio, muchas cosas se discuten en forma más o menos explicita. El número de hijos, el lugar de residencia, la cantidad de ingreso que se va a ahorrar, el propósito de este ahorro… tantas y tantas cosas que pueden ser causa de problema si uno por error o descuido no las habla a tiempo.

Aproximadamente lo mismo ocurre en los equipos de desarrollo de software. Es necesario discutir el rol de cada integrante, las actividades que cada quien va a realizar, los objetivos del trabajo en común, los recursos de los que se van a disponer para las tareas, entre otras muchas cosas.

Si bien es cierto que aceptar que un matrimonio pueda estar definido por completo es algo difícil de considerar para los enamorados, los jefes de los equipos de desarrollo más bien están enamorados de la idea de definir sus propios esfuerzos. Esto es, nuestros amigos jefes quieren imponen en los proyectos de software la frase proceso definido.

Proceso Definido: un conjunto de roles, actividades, recursos y planificación previa, que se pueden utilizar como referencia durante un esfuerzo de desarrollo de software.

O dicho de otra manera, lo que mantiene viva la emoción en un matrimonio, la novedad y los sentimientos de “no término de conocer a la persona pero me gusta todo lo que veo” es agradable ahí, pero en los equipos de desarrollo la coherencia y la previsibilidad del todo es la virtud número uno, aún a costa de parecer aburrido a los buscadores de emociones.

Pese a haber comparado como similares al matrimonio y al desarrollo de software, creo más bien ahora que son todo lo contrario. Un proyecto aburrido es un proyecto exitoso, un matrimonio aburrido… bueno, les diré cuando me case.

Si es que me caso algún día.