Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
.

Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Aliados del PMI® México

LiderDeProyecto.com es aliado estratégico del PMI® Capítulo México.
+
.
Humor del Líder

Problemas de comunicación
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
UML

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.


Publicado en la revista Software Gurú.
Reproducido con permiso del autor.


Temas relacionados:
Curso de análisis y diseño orientado a objetos con UML


indice del manual



Sergio dijo el 30 Octubre de 2009:
Qué buena onda Diego. Gracias por tu comentario

Diego dijo el 29 Octubre de 2009:
buenisimo gracias!



Mejores prácticas para definir la estrategia de un proyecto (Raymundo Sánchez Ticó)
+
.
.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. PMI®, PMBOK® Guide, OPM3®, CAPM® y PMP® son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.