(ctic) bpmn 2.0 - el estilo_v1.2

14
Parte III: Método y Estilo El Estilo Instructor: Gianfranco Campos Rubio

Upload: johnny-vp

Post on 25-Jan-2016

9 views

Category:

Documents


1 download

DESCRIPTION

holl

TRANSCRIPT

Page 1: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Parte III: Método y EstiloEl Estilo

Instructor: Gianfranco Campos Rubio

Page 2: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Comentario

Las personas que ascienden más rápido dentro de una organización son las que

mejor conocen los procesos internos de la misma.

Page 3: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Principios básicos del estilo con BPMN

El principios básico del estilo BPMN es que la lógica del proceso debe ser ambigua desde el diagrama en si mismo. Esto quiere decir a través de un “buen diagrama BPMN”. Recuerda que la “lógica del proceso” no es la lógica interna de una tarea del proceso. Las lógica de las tareas (o procedimientos) son importantes, pero BPMN no tiene mucho que decir o detallar al respecto.

El etiquetado apropiado es una pieza clave de las “buenas practicas”. Asimismo no solo se requiere etiquetar casi todo, sino también que las etiquetas coincidan con los elementos que continúan en el flujo.

Se puede tener un diagrama valido según la notación BPMN y a la vez sin significado. Por ejemplo BPMN no regula el etiquetado de los elementos. Es por ello que las reglas de estilo se hacen importantes.

Page 4: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Principios básicos del estilo con BPMN

Por otro lado, el diagrama debe obedecer las reglas oficiales de la especificación BPMN. Eso es obvio, e incluso más importante que seguir las convecciones del estilo. Como ya sabemos esto no es tan simple como parece. Por un lado, la especificación BPMN 2.0 no enumera sus reglas. Es decir no existe un apéndice en donde todas estén listadas y numeradas. En su lugar, las reglas están esparcidas a través de la narrativa del documento de 507 paginas, en donde la OMG redefine y sobre escribe varios otros requerimientos impuestos por el meta modelo BPMN (diagramas de clases UML) y sus esquemas XML asociados. Entonces tenemos tres hechos relacionados a la documentación oficial:

Las reglas y especificaciones pretenden estar alineadas.

Las reglas y especificaciones no siempre están del todo claras.

Cada herramienta muestra una interpretación distinta de las reglas

Un “buen modelo BPMN” siempre inicia con el cumplimiento de la especificación BPMN.

Page 5: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Reglas del estilo – parte 1

Existe un numero de reglas básicas para la composición, mientras que otras son especificación para soportar la validación del modelo realizado desde la herramienta. Para el nivel 1 consideraremos las siguientes:

1. Utilizar iconos y etiquetas que hagan que la lógica del proceso sea clara desde el diagrama impreso en papel.

2. Elaborar los modelos de forma jerárquica, haciendo encajar cada nivel en una página.

3. Utilizar los pools de caja negra para representar a clientes, proveedores de servicios, u otros solicitantes externos.

4. Iniciar los procesos de cara a clientes con un evento de mensaje de inicio, conectado el evento con un flujo de mensaje desde el pool del cliente.

5. En caso sea pertinente, podemos modelar unidades organizacionales internas como carriles dentro de un mismo pool de proceso, no en pools separados. Pools separados implica procesos independientes.

Page 6: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Modelamiento en Bizagi

Page 7: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Reglas del estilo – parte 1

Para el nivel 1 consideraremos las siguientes (continuación):

6. Etiquetar los pools de proceso con el nombre de un procesos; etiquetar los pools de caja negra con el nombre del actor participante o entidad negocio.

7. Indicar la culminación exitosa y excepcional de los estados finales de un proceso o subproceso con eventos separados, y etiquetarlos para indicar el estado final.

8. Etiquetar actividades con verbo (en su forma infinitiva) y sujeto.

9. Utilizar un evento con gatillador (mensaje, temporizador, simple, etc.) en el macro diagrama para indicar como el proceso inicia.

10. Si un subproceso es seguido por un Gateway etiquetarlo como pregunta, el subproceso debe tener múltiples eventos de finalización, y uno de ellos tiene que se igual a la etiqueta del Gateway.

Page 8: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Modelamiento en Bizagi

Page 9: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Reglas del estilo – parte 2

Para el nivel 1 consideraremos las siguientes (continuación):

11. Mostrar los flujos de mensaje con todos los mensajes de eventos.

12. Emparejar los flujos de mensaje en los niveles agregados y granulares (superiores y anidados).

13. Etiquetar los flujos de mensaje directamente con el nombre del mensaje.

14. Dos eventos de finalización en un mismo nivel del proceso no deben tener nombres iguales, ni referenciar a los mismos estados finales.

15. Dos actividades en un modelo de proceso no deben tener el mismo nombre.

Page 10: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Modelamiento en Bizagi

Page 11: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Reglas del estilo – parte 2

Para el nivel 1 consideraremos las siguientes (continuación):

16. Un subproceso debe tener un único evento de iniciación simple.

17. Un pool de proceso en un nivel anidado (si esta representado) debe ser etiquetado con el nombre del proceso padre y no con el nombre del subproceso.

18. En un diagrama jerárquico, un diagrama de nivel anidado no podrá contener ninguna de las actividades del nivel superior.

19. No utilizar un Gateway XOR para unir flujos alternativos. Solo es necesario conectar la secuencia de flujos directamente al elemento siguiente.

20. No utilizar un AND-join para unir flujos paralelos en un evento de finalización simple. Un AND-join siempre esta implícito en flujos que llegan a un mismo evento de finalización simple.

Page 12: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Modelamiento en Bizagi

Page 13: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Reglas oficiales BPMN 2.0

La regla principal es que el diagrama no debe violar la especificación BPMN. Luego de esta regla existen otras que enumeraremos a continuación:

1. Un flujo de secuencia no puede cruzar los limites de un pool (proceso).

2. Un flujo de secuencia no puede cruzar los limites de un subproceso.

3. Un flujo de secuencia solo puede conectarse a una actividad, Gateway, o evento, y ambos extremos debe estar correctamente conectados.

4. Un flujo de mensaje no puede conectar elementos dentro del mismo pool (proceso).

5. Un flujo de mensaje solo puede conectarse a una actividad, mensaje, evento (unitario o múltiple), o a un pool de caja negra, y ambos extremos deben estar correctamente conectados.

Page 14: (Ctic) Bpmn 2.0 - El Estilo_v1.2

Modelamiento en Bizagi