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
+
.
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

BPD ¿Diagrama de Actividades con Esteroides?
Por Sergio Orozco y Carlos Macías

El diagrama que se explicará en esta ocasión no se encuentra definido en la especificación de UML. Sin embargo puede considerarse como una ramificación de UML hacia una disciplina en particular de mucho provecho para la ingeniería de software: el modelado de negocio. Es por eso que decidimos tratar el tema en esta sección.

Los Requerimientos y el Modelo del Negocio

Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar algún o algunos procesos del negocio, y solemos prometerle al cliente la construcción de un producto de software “a la medida” de las necesidades del proceso de negocio que automatizará.

Pero, la mayoría de los equipos de desarrollo ¿cómo determinan las características del producto de software (que se supone cubrirán las necesidades del negocio)? La manera típica suele ser cuestionando directamente a los trabajadores del negocio acerca de la funcionalidad requerida, sin considerar el procesos o proceso del negocio a automatizar. Cuando deberíamos de recordar que el cliente no suele ser el experto en definir sistemas, sino el experto (o por lo menos eso quisiéramos) en los procesos en los que se involucra.

Utilizar puramente los requerimimentos 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 de éxito consiste en entender la estructura y dinámica del negocio o la parte del negocio que el producto automatizará para 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 a 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 seguramente nos afectará a nosotros como sus proveedores.

UML vs BPMN

UML, a lo largo de los años, se ha destacado por su utilidad para representar fenómenos del mundo real, razón por la cual, 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.

UML y BPMN

La comunidad de ingeniería de negocios ha venido trabajando por varios años en la definición de un estándar propio que satisfaga las necesidades de dicha actividad. Al igual que con otros estándares, en este se han recopilado buenas prácticas ya existentes, como es el caso del diagrama de actividad. Al cual, con las correspondientes adecuaciones le han llamado Diagrama de Procesos de Negocios. Al estándar completo se le conoce como 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 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 como BPEL4WS puedan visualizarse a través de esta notación.

Business Process Diagram (BPD): El Diagrama de Actividades con Esteroides

Para quien ya conoce el diagrama de actividad, la transición hacia el BPD es relativamente simple. Aunque aquí se presentan toda una serie de elementos especiales, muy apropiados para la necesidad de los ingenieros de negocios. Los elementos que se pueden modelar en un BPD se clasifican en cuatro categorías, que a continuación mencionamos:

  • 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.

A continuación se presenta un BPD que modela un proceso simple de reclamación. En este se identifican los principales elementos de la notación BPMN:


Clic en la imagen para ampliar

¿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. Por lo menos nosotros, y otros capacitadores de UML e ingeniería de negocio en otras partes del mundo, ofrecemos alternativas al respecto, prefiriendo la combinación de ambos estándares que una sola alternativa.

Y es que en nuestra experiencia modelando negocios, hemos constatado que UML definitivamente 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 que 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 de BPMN 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 es superior al usar los BPD.

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).

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





Cómo estimar correctamente un proyecto y llevarlo a cabo en tiempo y forma (Nahun Enrique Montoya-Iribe)
+
.
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. PMBOK, PMP, Project Management Professional, Project Management Professional (PMP), PgMP, Program Management Professional (PgMP), PMI-RMP, PMI Risk Management Professional (PMI-RMP), CAPM, Certified Associate in Project Management (CAPM), PMI-SP, PMI Scheduling Professional (PMI-SP), THE PMI TALENT TRIANGLE and the PMI REP Logo are registered marks of the Project Management Institute. 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. 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.