El objetivo de las aplicaciones de software, típicamente es el de automatizar uno o más procesos del negocio. Para esto, solemos prometerle al cliente (ya sea interno o externo) la construcción de un sistema de software “a la medida” de las necesidades del proceso de negocio que automatizará.
Para determinar las características de dicho producto de software (que supuestamente cubrirá las necesidades del negocio), la técnica más común es la de cuestionar directamente a los usuarios cuál es la funcionalidad requerida. El problema es que si solamente hacemos esto, estamos dejando de lado los procesos de negocio que se desea automatizar. Basarnos exclusivamente en los requerimientos del sistema como la entrada para el proceso de desarrollo de software suele traducirse en una reducción sustantiva en la probabilidad de entregar un software que cubra las necesidades para las que se supone fue creado.
Luego entonces, un factor crítico para el éxito de un proyecto de software, consiste en entender la estructura y dinámica del negocio o la parte del negocio que el producto automatizará, para entonces poder construir el producto que satisfaga su operación. En otras palabras, es indispensable partir de un modelo del negocio, ya sea que haya sido previamente definido por la gente de negocios (lo cual sería ideal, aunque por desgracia poco probable), o que nosotros como desarrolladores lo elaboremos previo al desarrollo del software.
No importa quien asuma la responsabilidad de elaborar el modelo de negocio; como bien sabemos, si no partimos de la entrada correcta para nuestro proceso de desarrollo, la satisfacción del cliente al recibir el software desarrollado no será la óptima. Lo cual, de una forma u otra nos terminará afectando.
UML vs BPMN
A lo largo de los años, UML se ha destacado por su utilidad para representar fenómenos del mundo real. Es por ello que desde hace varios años se desarrollaron y popularizaron una serie de extensiones para el modelado de los negocios. Entre los diagramas más útiles para este fin se encuentran: el de actividades, el de casos de uso de negocio, el de clases y el de secuencia.
Por otro lado, la comunidad de ingeniería de negocios ha venido trabajando también por varios años en la definición de un estándar propio que satisfaga las necesidades de modelado de procesos de negocio, el estándar más conocido resultado de estos esfuerzos, es el denominado BPMN. BPMN es acrónimo de Business Process Modeling Notation, y fue adoptado como estándar regulado por el OMG en febrero del 2006. BPMN define un único diagrama: el llamado BPD (Business Process Diagram) o diagrama de procesos del negocio. En la especificación del mismo se plantean dos objetivos, el primero: ofrecer una notación sencilla de entender por todos los involucrados en el modelado del negocio y el segundo, no menos importante: asegurar que los lenguajes orientados a la automatización de procesos, como BPEL4WS, puedan visualizarse a través de esta notación.
Business Process Diagram (BPD): El Diagrama de Actividades con Esteroides
El BPD toma las bases del diagrama de actividad de UML, así que para quienes ya conozcan este diagrama, la transición hacia el BPD será sencilla. Simplemente es cuestión de conocer y entender los elementos adicionales específicos para el modelado de negocios.
Los elementos que se pueden modelar en un BPD se clasifican en las siguientes cuatro categorías:
•Objetos de flujo: Eventos, Actividades y Gateways.
•Objetos de conexión: Flujo de Secuencia, Flujo de Mensaje y Asociación.
•Swimlanes: Pools y Lanes.
•Artefactos: Objetos de Datos, Grupos y Anotaciones de Texto.
La figura 1 muestra un BPD modelando un proceso simple de reclamación. En ella podemos identificar los principales elementos de BPMN.
Figura 1. BPD modelando un proceso de reclamación
¿No Más UML para el Negocio?
Lo natural es preguntarse si con esta nueva notación para negocio, BPMN, ya no es necesario utilizar los artefactos de UML para hacer modelado de negocio. En ese sentido hay opiniones variadas que debemos de considerar al tomar nuestra propia decisión al respecto.
A menudo se menciona que una de las principales ventajas que posee BPMN frente a UML es que de origen fue concebida como una notación enfocada en procesos y no en objetos. Sin embargo, sugerimos no hacer a un lado a UML para estos fines. Lo que nosotros recomendamos, al igual que otros consultores de UML e ingeniería de negocio en el mundo, es combinar ambos estándares para así obtener los máximos beneficios.
En nuestra experiencia modelando negocios, hemos constatado que UML aporta elementos muy valiosos, como la identificación inmediata de las responsabilidades de los trabajadores del negocio, y el comportamiento dependiente del estado de las entidades del negocio. Modelar este tipo de elementos en BPMN, si bien es posible, resulta impráctico.
Por otro lado, a pesar de que tanto los diagramas de actividad de UML como los BPD soportan el modelado de los escenarios más comunes de negocio –por ejemplo, los 21 patrones que describen el comportamiento de los procesos de negocio –, hemos comprobado que la riqueza semántica y simplicidad de uso provista por BPD es superior.
Finalmente, tampoco hay que dejar de lado la relación de BPMN con lenguajes como BPEL4WS como elemento importante en la implantación de soluciones que se adhieren a una Arquitectura Orientada a Servicios (SOA).
Acerca del autor
Carlos Macías es instructor y arquitecto en jefe. Sergio Orozco es director general e instructor senior, ambos especializados en temas relacionados con UML en Milestone Consulting. Milestone Consulting (UML Value Added Training Center), es una empresa especializada en capacitación práctica-intensiva y consultoría en UML, BPMN y PM. Milestone Consulting es la primer empresa mexicana miembro de la OMG, además de ser REP del PMI.
info@milestone.com.mx, www.milestone.com.mx
- Log in to post comments