Del Negocio al Sistema: El Diagrama de Actividad

Por Sergio Orozco

Manufactura o Consultora

Cul es la diferencia entre la manufactura de software y la consultora de software? En mi opinin la

consultora le ofrece un valor extra al cliente ms all de la construccin del software. Para hacer
consultora debemos de ponernos en los zapatos del cliente para comprender su problema y necesidades,
y de esta forma ser capaces de ayudarle a definir el sistema adecuado para su negocio.

En la manufactura la responsabilidad sobre la definicin de la solucin podra ser de menor proactividad

que la de un consultor. En este caso el cliente nos especifica cul es el software que necesita y nosotros lo
fabricamos segn sus instrucciones, con poco o nulo cuestionamiento de nuestra parte respecto a la
relevancia de cada funcin a implementar en dicho sistema.

El problema en este ltimo escenario consiste en que el cliente NO suele ser un experto en sistemas de
forma que pueda proponer el sistema ideal. El cliente es experto en su negocio y nosotros somos expertos
en el nuestro: en el desarrollo de sistemas. Por lo tanto habra que tener clara la responsabilidad de cada
quien dentro de un proyecto.

IQ, Experiencia o Simplemente Tcnicas

Lo fascinante del modelado de negocio se puede ver en situaciones como la siguiente: no es raro notar la
sorpresa en la cara de nuestros alumnos cuando descubren que su instructor de UML pareciera
comprender mejor que ellos sus reglas de negocio y los requerimientos del sistema que proponen para que
les brindemos la capacitacin, con slo haber realizado uno o dos diagramas de UML durante el curso.

Pero, sera muy presuntuoso de nuestra parte pensar que dominamos las reglas de su negocio por nuestra
capacidad o por nuestro coeficiente intelectual. En todo caso es el dominio de UML el que nos permite, a
nuestros instructores o a cualquier persona, lograr comprender las cosas de una forma ms sencilla.
Habilidad que afortunadamente hemos podido transmitir en la capacitacin que brindamos por medio de
simulacros de proyectos reales, en lugar de nicamente explicar los dibujos que conforman a UML.

La Magia de Armar Rompecabezas

La magia para ayudarle a los usuarios a entender su negocio por medio de UML consiste en saber pegar
las piezas aisladas que nos proporciona en un rompecabezas completo y coherente que sea mucho ms
claro que la explicacin original. Incluso el usuario ve las cosas con ms claridad cuando le mostramos eso
que l mismo explic, por medio de los modelos.
Al respecto, mis alumnos suelen preguntarme qu artefactos de UML son los ms apropiados para ser
utilizados en la comunicacin directa con el cliente. Es decir, cules le pueden entregar con la seguridad de
que el cliente los va a entender.

Entre los artefactos bsicos que yo sugiero para esto estn:

a) para definir la funcionalidad del sistema, los casos de uso

b) para comprender la jerga del cliente, el modelo conceptual, pero

c) para validar con el cliente si comprendemos el trabajo (procesos/procedimientos) que realiza su empresa
y que desea automatizar, posiblemente no haya nada como el diagrama de actividades.

Alguien Sabe Cmo Funciona Este Negocio?

Y es que suele ser la regla, ms que la excepcin, encontrarse con usuarios que no comprenden del todo
los procesos dentro de los cuales participan. Por lo que nosotros, como analistas, terminamos recogiendo
todas las piezas del rompecabezas para despus pegarlas y as comprender los procesos del negocio que
sern automatizados.
Responsable del Negocio

Hace poco un alumno me preguntaba si el trabajo de modelar los procesos de negocio le correspondan a
la gente de sistemas. La respuesta no es tan simple, pues en el mundo ideal habra un rol que se
encargara de eso y el equipo de desarrollo slo tendra que preocuparse por definir y construir el sistema
adecuado.

Pero, todos sabemos que el mundo no es color de rosa, as que no es raro que tengamos que ocupar dicho
rol ante la ausencia de alguien ms que asuma esta responsabilidad. Con esto no quiero decir que
recomiendo que la gente de sistemas se encargue de esta tarea. Pero, no podemos tapar el sol con un
dedo, pues esto ocurre con bastante frecuencia ante la ausencia de un rol asignado para realizar dichas
tareas entre los usuarios.

El Artefacto

El diagrama de actividades es un artefacto muy til y simple para comunicarse con el cliente porque en
esencia es un diagrama de flujo, y quin no ha visto o elaborado un diagrama de este tipo? La mayora de
los usuarios no tienen problema en entender este diagrama sin tanta explicacin.

La esencia del diagrama del diagrama de actividades consiste en mostrar una secuencia de acciones o
actividades. Ya sea un proceso, un procedimiento, un conjunto de eventos de un caso de uso o los de un
algoritmo.

Para mostrar los flujos ms bsicos sera suficiente utilizar dos elementos del diagrama: las actividades o
acciones y las transiciones. En otras palabras, los pasos del proceso y el orden en que estos ocurren.

De ah podemos agregar ms elementos para modelar flujos cada vez ms complejos. Por ejemplo, un
elemento bsico a representar nos indicara explcitamente cul es inicio y fin del flujo.

Condiciones, Carriles y Flujos Paralelos

Qu felices seramos si los procesos siguieran una ruta simple para cumplir con su objetivo.
Desafortunadamente existen situaciones alternativas que hay que considerar y que complican su
modelado. Estos flujos alternativos se pueden representar utilizando las condiciones que nos indican que
tenemos que irnos por uno u otro camino, como cuando vamos a pagar una compra en el sper mercado y
nos pregunta el cajero si queremos pagar en efectivo o con tarjeta. Cada opcin requiere pasos alternativos
a modelar a partir del smbolo de decisin.
En muchas situaciones querrs saber a quin le corresponde cada tarea del proceso modelado, al
vendedor? al cliente? al encargado del almacn? Podemos representar en este diagrama de una forma
simple, mediante carriles, quin es el responsable de cada actividad dentro del proceso.

Los procesos se pueden complicar an ms al requerir actividades que se lleven a cabo en paralelo.
Tampoco hay mayor problema, pues las barras de sincronizacin nos muestran claramente esta
caracterstica del flujo que estamos modelando.

Uso y Generacin de Productos

Y qu hay de los productos o documentos que se utilizan o generan durante una actividad del proceso?
Por ejemplo para fabricar un carro necesitas un motor y un chasis, estos son productos de entrada para
generar un producto de salida. Para entregar cierta mercanca necesitas una orden de entrega. Este tipo de
diagramas permiten representar los productos de entrada y de salida para cada actividad, por medio de
objetos y flujos de objetos.

Apto para Todo Mundo

Lo mejor de todo es que estos diagramas no requieren mayor ciencia para ser entendidos. Al menos as
ocurre con los procesos que no requieran demasiados tipos de elementos de este artefacto. Despus de
haber asesorado a todos esos proyectos durante estos aos en las tareas de modelado, puedo asegurar
que a los clientes les fascina este diagrama, pues de una forma simple definen su trabajo y muchas veces
lo ven por primera vez de una forma ordenada.
 Figura 1. Diagrama de Actividades para la impresin de una esquela en un peridico

La Transicin al Software

Otra gran ventaja de este tipo de diagramas consiste en la transicin del anlisis del negocio a los
requerimientos del sistema de una manera ms transparente. Nos ofrece la formidable ventaja de
facilitarnos la identificacin de los principales casos de uso del sistema. Pues, algunas de las actividades
mostradas en el diagrama se convierten directamente en casos de uso. De esta forma comienza a aparecer
mucha de la funcionalidad principal para el cliente. Claro que no es toda la funcionalidad, pero por lo menos
la que posiblemente sea ms relevante para el negocio.

Para terminar recuerda la regla del 20/80: el 20% de los elementos de un artefacto te pueden ayudar en el
80% de los casos. As que para comenzar puedes subsistir con este pequeo resumen que aqu te
present. Mucha suerte y hasta la prxima.

Por Sergio Orozco