Del Negocio al Sistema: El Diagrama de Actividad

Por Sergio Orozco

Manufactura o Consultoría

¿Cuál es la diferencia entre la manufactura de software y la consultoría de software? En mi opinión la

consultoría le ofrece un valor extra al cliente más allá de la construcción del software. Para hacer
consultoría 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 definición de la solución podría ser de menor proactividad

que la de un consultor. En este caso el cliente nos especifica cuál es el software que necesita y nosotros lo
fabricamos según sus instrucciones, con poco o nulo cuestionamiento de nuestra parte respecto a la
relevancia de cada función 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 habría que tener clara la responsabilidad de cada
quien dentro de un proyecto.

IQ, Experiencia o Simplemente Técnicas

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 capacitación, con sólo haber realizado uno o dos diagramas de UML durante el curso.

Pero, sería 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 más sencilla.
Habilidad que afortunadamente hemos podido transmitir en la capacitación 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 más
claro que la explicación original. Incluso el usuario ve las cosas con más 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 más apropiados para ser
utilizados en la comunicación directa con el cliente. Es decir, cuáles le pueden entregar con la seguridad de
que el cliente los va a entender.

Entre los artefactos básicos que yo sugiero para esto están:

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 Cómo Funciona Este Negocio?

Y es que suele ser la regla, más que la excepción, 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 después pegarlas y así comprender los procesos del negocio que
serán automatizados.
Responsable del Negocio

Hace poco un alumno me preguntaba si el trabajo de modelar los procesos de negocio le correspondían a
la gente de sistemas. La respuesta no es tan simple, pues en el mundo ideal habría un rol que se
encargara de eso y el equipo de desarrollo sólo tendría 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 más 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 ¿quién no ha visto o elaborado un diagrama de este tipo? La mayoría de
los usuarios no tienen problema en entender este diagrama sin tanta explicación.

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 más básicos sería 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 más elementos para modelar flujos cada vez más complejos. Por ejemplo, un
elemento básico a representar nos indicaría explícitamente cuál es inicio y fin del flujo.

Condiciones, Carriles y Flujos Paralelos

Qué felices seríamos 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 súper mercado y
nos pregunta el cajero si queremos pagar en efectivo o con tarjeta. Cada opción requiere pasos alternativos
a modelar a partir del símbolo de decisión.
En muchas situaciones querrás saber a quién le corresponde cada tarea del proceso modelado, ¿al
vendedor? ¿al cliente? ¿al encargado del almacén? Podemos representar en este diagrama de una forma
simple, mediante carriles, quién es el responsable de cada actividad dentro del proceso.

Los procesos se pueden complicar aún más al requerir actividades que se lleven a cabo en paralelo.
Tampoco hay mayor problema, pues las barras de sincronización nos muestran claramente esta
característica del flujo que estamos modelando.

Uso y Generación 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 mercancía 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. Después de
haber asesorado a todos esos proyectos durante estos años 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 impresión de una esquela en un periódico

La Transición al Software

Otra gran ventaja de este tipo de diagramas consiste en la transición del análisis del negocio a los
requerimientos del sistema de una manera más transparente. Nos ofrece la formidable ventaja de
facilitarnos la identificación 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 más 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 pequeño resumen que aquí te
presenté. Mucha suerte y hasta la próxima.

Por Sergio Orozco