Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y...

132
REPORTE TECNICO Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML Eduardo Jara Goldenberg Ingeniero Civil Informático. Universidad de Concepción. Chile. Magister en Matemáticas Aplicadas. Universidad Estatal de Moscú. Federación Rusa. [email protected] Diciembre 2016 Resumen Los Sistemas de Información deben estar alineados con los Procesos de Negocio, que definen cómo realizar los productos y servicios en concordancia con los Objetivos Estratégicos de la Empresa. Así los Sistemas de Información efectivamente apoyan el logro de dichos Objetivos. Puesto que ambos son trabajados por distintos grupos, con distintos objetivos, metodologías y herramientas, se dificulta la alineación requerida. El presente documento presenta una Metodología de Alineamiento cuya aplicación asegura que todas aquellas partes de los Procesos de Negocio que requieren soporte informático tengan su contraparte como requerimientos sistémicos expresados como Casos de Uso. Y que, además, todos los Casos de Uso sean consecuencia de necesidades reales de los Procesos de Negocio. La Metodología utiliza BPMN (Business Process Model and Notation) para describir los Procesos de Negocio, y UML (Unified Modeling Language) para la especificación de requerimientos de software con Casos de Uso. La Metodología es compatible con cualquier Proceso de Desarrollo de Software, desde Procesos Ágiles, hasta Procesos altamente formalizados y documentados.

Transcript of Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y...

Page 1: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

REPORTE TECNICO

Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información

usando BPMN y UML

Eduardo Jara Goldenberg Ingeniero Civil Informático. Universidad de Concepción. Chile.

Magister en Matemáticas Aplicadas. Universidad Estatal de Moscú. Federación Rusa. [email protected]

Diciembre 2016

Resumen

Los Sistemas de Información deben estar alineados con los Procesos de Negocio, que definen cómo

realizar los productos y servicios en concordancia con los Objetivos Estratégicos de la Empresa. Así

los Sistemas de Información efectivamente apoyan el logro de dichos Objetivos. Puesto que ambos son

trabajados por distintos grupos, con distintos objetivos, metodologías y herramientas, se dificulta la

alineación requerida.

El presente documento presenta una Metodología de Alineamiento cuya aplicación asegura que todas

aquellas partes de los Procesos de Negocio que requieren soporte informático tengan su contraparte

como requerimientos sistémicos expresados como Casos de Uso. Y que, además, todos los Casos de

Uso sean consecuencia de necesidades reales de los Procesos de Negocio.

La Metodología utiliza BPMN (Business Process Model and Notation) para describir los Procesos de

Negocio, y UML (Unified Modeling Language) para la especificación de requerimientos de software

con Casos de Uso.

La Metodología es compatible con cualquier Proceso de Desarrollo de Software, desde Procesos

Ágiles, hasta Procesos altamente formalizados y documentados.

Page 2: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

ii

Prefacio

Este Reporte Técnico es el resultado de varios lustros de trabajo del autor en las áreas de Procesos de

Negocio y Desarrollo de Software, con los estándares UML desde 1998 y BPMN desde 2008.

Este Reporte Técnico está dirigido a profesionales que trabajan en el levantamiento, documentación y

automatización de Procesos de Negocio; y profesionales TI que trabajan en el levantamiento y

especificación de Requerimientos de Software.

Los estándares UML y BPMN son especificaciones de OMG (Object Management Group, 2016).

Los diagramas técnicos UML y BPMN mostrados en la figuras de este Reporte fueron desarrollados

con Enterprise Architect (Sparx Systems).

El autor agradece de antemano a los lectores cualquier información sobre ambigüedades,

inconsistencias o inexactitudes, así como opiniones y sugerencias para versiones futuras de este

documento. Por favor enviar correo a [email protected] o [email protected].

Page 3: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

iii

Contenido

1 Introducción ...................................................................................................................................... 1

2 Arquitectura Empresarial .................................................................................................................. 3

2.1 Matriz de Arquitectura Empresarial ........................................................................................... 4

2.2 Alineamiento y Trazabilidad ...................................................................................................... 6

3 Modelos y Notación de Procesos de Negocio (BPMN) .................................................................. 10

3.1 Ejemplo de BPMN ................................................................................................................... 11

3.2 Elementos de BPMN ................................................................................................................ 15

3.2.1 Elementos de Flujos .......................................................................................................... 15

3.2.2 Calles de Responsabilidad (Swimlanes) ............................................................................ 19

3.2.3 Elementos de Conexión .................................................................................................... 21

3.2.4 Otros Elementos de BPMN ............................................................................................... 24

4 Lenguaje Unificado de Modelado (UML) ...................................................................................... 25

4.1 Estructura de UML ................................................................................................................... 25

4.1.1 Tipos de Modelos en UML ............................................................................................... 26

4.2 Modelo de Clases ..................................................................................................................... 27

4.3 Modelo de Casos de Uso .......................................................................................................... 31

4.3.1 Descripción de un Caso de Uso ........................................................................................ 34

4.3.2 Requerimientos sólo con Casos de Uso ............................................................................ 35

4.4 Modelo de Actividades ............................................................................................................. 37

4.5 Modelado de Procesos de Negocio, ¿UML o BPMN? ............................................................. 39

5 Metodología de Alineamiento ......................................................................................................... 41

5.1 Principios y Políticas ................................................................................................................ 41

5.2 Ambientes ................................................................................................................................. 44

5.2.1 Ambiente Interno .............................................................................................................. 45

5.2.2 Ambiente Externo ............................................................................................................. 47

5.2.3 Tareas en Piscinas y Carriles ............................................................................................ 48

Page 4: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

iv

5.3 Patrones .................................................................................................................................... 52

5.3.1 Patrones de Interacción ..................................................................................................... 53

5.3.2 Patrones de Mensajes ........................................................................................................ 62

5.3.3 Patrones de Servicios ........................................................................................................ 88

6 Ejemplo ........................................................................................................................................... 98

6.1 Niveles ...................................................................................................................................... 98

6.1.1 Alto Nivel sin Tecnología ................................................................................................. 98

6.1.2 Colaboración detallada sin Tecnología ............................................................................. 99

6.1.3 Colaboración detallada con Tecnología en Piscinas separadas ...................................... 102

6.2 Aplicación de Patrones ........................................................................................................... 105

6.2.1 Mensaje de Rol Interno hacia Sistema Externo (Msj RI > SE) ...................................... 105

6.2.2 Mensaje de Sistema Externo hacia Sistema Interno (Msj SE>SI) .................................. 107

6.2.3 Mensaje a Rol Interno desde Sistema Interno (Msj RI<SI) ............................................ 109

6.2.4 Interacción Rol Interno-Sistema Interno (Int RI < > SI) ................................................. 111

6.2.5 Mensaje de Sistema Interno hacia Sistema Externo (Msj SI>SE) .................................. 115

6.2.6 Mensaje a Rol Interno desde Sistema Externo (Msj RI < SE) ........................................ 117

6.3 Refinamiento del Modelo de Casos de Uso ........................................................................... 119

6.3.1 Modelo de Casos de Uso inicial ...................................................................................... 119

6.3.2 Inclusiones ...................................................................................................................... 120

6.3.3 Nuevos Casos de Uso ...................................................................................................... 122

6.3.4 Generalización de Actores .............................................................................................. 124

6.3.5 Generalización de Casos de Uso ..................................................................................... 125

6.4 Mapeo ..................................................................................................................................... 126

7 Bibliografía ................................................................................................................................... 128

Page 5: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

1

1 Introducción

En última instancia los Sistemas de Información deben apoyar los Objetivos Estratégicos de la

Empresa. Sin embargo, existe un largo camino (temporal, metodológico y organizacional) entre la

definición de los Objetivos y la construcción de los Sistemas de Información.

Por un lado, los Objetivos Estratégicos, que materializan la Misión y Visión de la Empresa, junto con el

Modelo de Negocio desembocan en los Procesos de Negocio que definen, en términos operativos, qué

hace la Empresa, cómo lo hace y quién lo hace.

Por otro lado, los Sistemas de Información, que dan soporte al quehacer de la Empresa, es decir, sus

Procesos de Negocio, nacen de necesidades expresadas como Requerimientos de Software.

La clave para que esta larga cadena, que comienza en los Objetivos Estratégicos y termina en los

Sistemas de Información, se mantenga unida, es que estos dos eslabones: Procesos de Negocio y

Requerimientos de Software, estén alineados. En otras palabras, que cada necesidad de tecnología

informática en los Procesos esté expresada como un Requerimiento, y cada Requerimiento apoye algún

Proceso.

El presente documento presenta una Metodología de Alineamiento de Procesos y Requerimientos

cuya aplicación asegura que de manera sistemática, predecible, repetible y ordenada se deriven los

Requerimientos a partir de los Procesos. La Metodología utiliza BPMN (Business Process Model and

Notation) para describir los Procesos de Negocio, y UML1 (Unified Modeling Language) para la

especificación de requerimientos de software con Casos de Uso.

El objetivo de la Metodología es la identificación de los Requerimientos como Casos de Uso, pero no

se pronuncia sobre cómo documentarlos ni cómo se utilizarán para llegar finalmente al software. Esto

queda a criterio del Proceso de Desarrollo de Software utilizado. Por este motivo, la Metodología de

Alineamiento es compatible con cualquier Proceso de Desarrollo, desde Procesos Ágiles como

SCRUM, pasando por Procesos altamente formalizados y documentados, hasta MDA2.

Los estándares BPMN y UML son metodológicamente agnósticos3, es decir, definen la sintaxis y

semántica de los lenguajes gráficos, pero no se pronuncias sobre cómo utilizarlos. En esta línea, la

Metodología de Alineamiento define qué elementos de BPMN usar y cómo utilizarlos. Esto se traduce

en (1) la definición de Ambientes que establecen reglas sobre cómo utilizar BPMN para modelar los

Participantes de Colaboraciones de Procesos de Negocio. (2) La identificación de 15 Patrones que

representan las distintas situaciones de uso de Sistemas de Información en los Procesos de Negocio. (3)

1 BPMN y UML son estándares especificados por (Object Management Group, 2016).

2 Model Driven Architecture.

3 BPMN y UML no son métodos, ni técnicas, ni metodologías. Son lenguajes utilizados por métodos, técnicas y

metodologías.

Page 6: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

2

La definición de reglas para inferir los Requerimientos como Casos de Uso para cada Patrón. Y (4) la

definición de un mapeo entre elementos de los Procesos de Negocio y los de los Casos de Uso.

En el Capítulo 0 se presenta la necesidad del Alineamiento en el contexto de la Arquitectura

Empresarial. Se define y explica el uso de la Matriz de la Arquitectura Empresarial para visualizar las

distintas vistas desde las que puede ser analizada una Empresa. Dos de estas vistas son precisamente las

trabajadas en la Metodología de Alineamiento: Procesos de Negocio y Requerimientos de Software.

En los Capítulos 3 y 4 se presentan los estándares BPMN y UML, los que serán usados para describir

los Procesos de Negocio y los Requerimientos en la Metodología de Alineamiento. Para cada uno de

ellos se entrega una introducción a sus elementos más importantes.

La Metodología de Alineamiento es descrita en detalle en el Capítulo 5. Primero se define un conjunto

de principios y políticas que le dan sustento teórico y que delinean sus principales características.

Luego se describen detalladamente sus dos partes estructurales: Ambientes y Patrones.

Por último, en el Capítulo 6 se muestra un ejemplo detallado de la aplicación de los Ambientes y el uso

de Patrones para derivar los Requerimientos de Software como Casos de Uso.

Page 7: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

3

2 Arquitectura Empresarial4

Para efectos del presente trabajo entenderemos por Empresa una organización, con o sin fines de lucro,

dedicada a actividades industriales, mercantiles o de prestación de servicios, que se relaciona con su

entorno entregando productos o servicios e interactuando con clientes, proveedores y otros agentes

sociales.

Más allá de sus propósitos específicos, toda Empresa:

Tienen una Misión o razón de ser.

Lleva a cabo una Estrategia.

Involucra a un grupo de Personas.

Ejecuta Actividades y toma Decisiones.

Utiliza Recursos.

Se Relaciona con el mundo.

Todos los aspectos mencionados se relacionan entre sí. Si a esto agregamos el tamaño de las Empresas,

la cantidad de personas que en ellas trabajan, sus diferentes y – a veces – encontrados intereses, y el

cambiante ambiente (legal, comercial, medioambiental) en que deben competir; llegamos a un

escenario altamente complejo para el que las herramientas comunes de administración no están

preparadas.

La forma moderna de administrar esta complejidad es conceptualizar y gestionar las partes de una

Empresa y sus relaciones usando un enfoque arquitectónico, es decir, recurrir a criterios y técnicas

análogos a los usados en la planeación, diseño y construcción de edificios y otras estructuras. Es decir,

trabajando con la Arquitectura Empresarial.

La Arquitectura Empresarial es una técnica que ayuda a dirigir la forma como se construye (organiza y

trabaja) una Empresa, usando un enfoque holístico que conjuga sus diversas partes, para el desarrollo

y ejecución exitosos de la estrategia.

En la práctica la Arquitectura Empresarial consiste en disponer de una representación simplificada de la

realidad de la Empresa para ayudar a tomar decisiones, prever riesgos potenciales, evaluar posibles

cambios, identificar impactos, etc. Esto es análogo a la Arquitectura tradicional, donde los planos y la

maqueta de un edificio son representaciones simplificadas de éste. Lo mismo ocurre con una Empresa,

hay varias formas de verla y representarla, por ejemplo:

Organigrama – Representa los cargos y quien los ocupa.

Descripciones de Cargos – Muestran qué hace cada cargo.

Mapas de Procesos – Representan actividades y decisiones.

Cuadro de Mando (balance scorecard) – Muestra el estado de salud de la Empresa.

Diagrama de Redes – Muestra la infraestructura tecnológica y su enlaces.

4 Para mayor información sobre Arquitectura Empresarial consultar (Craftware Consultores, 2016).

Page 8: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

4

Modelo de negocio – Muestra cómo agregar valor a lo que se vende y cuál es la propuesta de

valor.

otros…

2.1 Matriz de Arquitectura Empresarial

Los diversos puntos de vista desde los que se puede ver la Empresa están identificados en la Matriz de

Arquitectura Empresarial (Craftware Consultores, 2016). Ésta muestra por un lado una jerarquía que va

desde el nivel Estratégico a los niveles Operacional y Tecnológico. Por el otro lado indica distintas

perspectivas de la Empresa: Motivación, Estructura y Funcionamiento.

Figura 2-1. Matriz de Arquitectura Empresarial

En cada celda van modelos específicos para representar esa perspectiva con un nivel dado, por ejemplo:

En el cruce de Estrategia con Estructura de Datos va el cuadro de mando integral o Balance

Scorecard que dice qué tal está la Empresa.

En el cruce de Procesos y Funciones y Comportamiento va el Mapa de Procesos de Negocio

En el cruce de Tecnología con Motivación y Objetivos van los modelos con los requisitos que

deben cumplir las aplicaciones de software.

Page 9: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

5

Aquí entendemos por modelo cualquier tipo de representación textual y/ o gráfica, con distintos grados

de formalidad. Es deseable que esta representación, de una parte de la realidad de la Empresa, esté

plasmada en algún documento físico o electrónico, y no sólo en la cabeza de las personas.

Los Modelos en cada celda pueden tener distinto nivel de detalle y usar distintas metodologías y

herramientas.

Figura 2-2. Niveles de detalle de modelos en celda Estrategia - Motivación y Objetivos

Por ejemplo, en la celda Estrategia - Motivación y Objetivos habrá una jerarquía de objetivos que

guían la Empresa desde la Visión y Misión hasta los Objetivos Operacionales. Por otro lado, en la celda

Procesos - Funciones y Comportamiento habrá una jerarquía de Procesos desde los Macro Procesos

hasta las Instrucciones de Trabajo.

Todas las Empresas tendrán esta desagregación en cada celda. En algunos casos los modelos estarán

implícitos, en otros casos estarán formalizados y documentos.

Page 10: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

6

Figura 2-3. Niveles de detalle de modelos en celda Procesos – Funciones y Comportamiento

2.2 Alineamiento y Trazabilidad

Los elementos de los modelos dentro de cada celda y entre ellas deben estar alineados, de modo que

ajusten como los elementos de un mecanismo para éste funcione correctamente.

Por ejemplo, en Estrategia - Motivación y Objetivos la Misión de la Empresa debe estar reflejada en

uno o más de los Objetivos Estratégicos. Además, cada uno de éstos debe materializar uno o más

aspectos de la Misión.

Entre Proceso- Funciones y Comportamiento y Tecnología-Motivación y Objetivos debe haber un

alineamiento entre las tareas de los Procesos de Negocio que requieren apoyo TIC5 y los

requerimientos de software expresados, por ejemplo, como Casos de Uso: todos los Casos de Uso

deben tener su origen en tareas de uno o más Procesos, y todas las tareas que requieren TIC deben estar

soportadas por – a lo menos – un Caso de Uso. Esta consistencia entre Procesos y Requerimientos es

esencial pues es el punto de unión el Negocio y los Sistemas de Información, como muestra la Figura

2-4.

5 Tecnología de Información y Comunicación.

Page 11: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

7

Figura 2-4. Procesos y Requerimientos - punto de unión entre

Negocio y Sistemas de Información

El alineamiento entre elementos relacionados es esencial para que la Arquitectura Empresarial sea de

calidad. Para asegurar este alineamiento se requiere administrar la trazabilidad entre estos elementos.

Es decir, definir y documentar las relaciones entre ellos y tener la capacidad de consultarlas y

actualizarlas, si es necesario.

Por ejemplo, la Figura 2-5 muestra, en su lado izquierdo, una parte de un Proceso de Negocio en el que

algunas Actividades (enmarcadas en rojo) usan TIC, y en el lado derecho los Casos de Uso que

representan los Requerimientos de Software correspondientes6.

6 Esto es parte del ejemplo del Capítulo 6. En particular la aplicación del Patrón Interacción Rol Interno-Sistema Interno

(Int RI < > SI).

Page 12: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

8

Figura 2-5. Actividades en Proceso de Negocio (izq.)

y Requerimientos que las soportan (der.)

El hecho de saber que ciertos Requerimientos están relacionados con Actividades de los Procesos es

positivo, pero si estas relaciones no están documentadas esta información se puede perder. Por el

contrario, si las relaciones están documentadas y gestionadas con alguna herramienta, se tendrá un

control del alineamiento y serán posibles, por ejemplo, análisis de impacto.

En la Figura 2-6 se muestra, a la izquierda, la documentación explícita de la relación entre Casos de

Uso y Actividades a través de trazas (relación trace). A la derecha se visualizan todas las relaciones del

Caso de Uso Editar Ticket Nivel 1, tanto dentro del Modelo de Requerimientos (con otros Casos de

Uso y con Actores), como hacia los Procesos de Negocio (con las Actividades de los Procesos)7.

7 Los modelos están hechos con la herramienta Enterprise Architect ( http://www.sparxsystems.com.au ).

Page 13: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

9

Figura 2-6. Actividades y Casos de Uso relacionados (izq.)

y visualización de relaciones en Enterprise Architect (der.)

El tema del presente documento versa sobre el alineamiento de las celdas Proceso - Funciones y

Comportamiento y Tecnología-Motivación y Objetivos. La Metodología descrita consiste en

modelar los Procesos de Negocio con BPMN y alinearlos con los Requerimientos de Software

modelados con Casos de Uso de UML. En los siguientes capítulos se realiza una introducción a estos

dos estándares.

Page 14: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

10

3 Modelos y Notación de Procesos de Negocio (BPMN)

Los Procesos de Negocio son trabajados con distintos niveles de detalle y formalización, y con

diversos propósitos. Por un lado, los analistas de negocio utilizan algún tipo de flujograma para

representarlos de manera informal o para describir gráficamente los procedimientos administrativos

bajo la norma ISO 90008.

Figura 3-1.Flujograma (izq.), Diagrama de Actividades UML (der.)

Por otro lado, arquitectos de sistemas e ingenieros de software usan lenguajes formales, como BPEL9,

para diseñar y ejecutar Procesos en Motores de Procesos BPMS10

.

BPMN (Business Process Model and Notation) es un lenguaje gráfico altamente formalizado cuyo

propósito es cubrir tanto las necesidades de diagramación de los Procesos de Negocio como su diseño

formal para alimentar Motores de Procesos. BPMN provee un mapeo hacia BPEL, y algunos Motores

de Procesos aceptan directamente Procesos diseñados con BPMN.

8 En ISO 9000 un Procedimiento Administrativo es la documentación de un Proceso.

9 Business Process Execution Language.

10 Business Process Management System or Suite. Estos sistemas también se conocen con otros nombres: WfM (Workflow

Management), Motor de Workflow o Process Engine.

Page 15: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

11

3.1 Ejemplo de BPMN

En esta sección se muestra un ejemplo simple de BPMN11

, pero que muestra con claridad su uso y sus

elementos más importantes. El ejemplo describe, a un alto nivel, el funcionamiento del Sistema de

Soporte que una Empresa de Software ofrece a sus Clientes para la solución de problemas que éste

tenga con el uso de las aplicaciones provistas.

Informalmente podemos describir el funcionamiento del Sistema de Soporte en los siguientes términos:

El Cliente realiza una consulta a un Administrador de Cuenta, quien le entrega la

respuesta. Si el Administrador de Cuenta puede resolver la consulta la responde de

inmediato, si no deriva el problema a la Mesa de Ayuda Nivel 1. Esta resuelve el

problema y entrega la respuesta al Administrador de Cuenta para que la comunique

al Cliente. La Mesa de Ayuda Nivel 1 puede derivar el problema al Nivel 2 quien

debe obligatoriamente entregar una respuesta al Administrador de Cuenta, si es

necesario consulta al Desarrollador.

A continuación se realiza una descripción del mismo Sistema de Soporte, pero usando la terminología

de BPMN.

El diagrama de la Figura 3-2 muestra una Colaboración en la que interactúan los Procesos de dos

Participantes:

Cliente

Empresa de Software

Cada Participante está representado en el Diagrama por una Piscina, dentro de la que se muestra un

Proceso.

Para el Participante Cliente su Proceso no se muestra en el diagrama (porque no es

relevante para el modelador, o porque – incluso siendo parte del modelo - no es relevante

para el destinatario del diagrama).

Para el Participante Empresa de Software se muestra el detalle del Proceso.

La Piscina de Empresa de Software está compartimentada en Carriles que, en este caso, representan

unidades de la organización (Soporte, Mesa de Ayuda Nivel 1 y Nivel 2) y roles o cargos cumplidos

por personas (Administrador de Cuenta y Desarrollador).

11 Este ejemplo es una variación del mostrado en (Object Management Group, 2010)

Page 16: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

12

Figura 3-2. Sistema de Soporte como Colaboración BPMN

Los Procesos se comunican a través de Flujos de Mensaje que van desde una Piscina a otra. Un Flujo

de Mensaje se inicia en el borde de una Piscina o en un objeto dentro de ella y termina en el borde de

otra Piscina o en un objeto dentro de ella. En el diagrama hay dos Flujos de Mensaje (ver detalle en

Figura 3-3):

Desde la Piscina de Cliente al Evento Consulta Recibida en la Piscina de Empresa de

Software.

Desde la Tarea Explicar Solución en la Piscina de Empresa de Software a la Piscina de

Cliente.

Page 17: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

13

Figura 3-3. Flujos de Mensaje entre Piscinas

Un Proceso está constituido por un conjunto de Objetos de Flujo (Eventos, Actividades y Compuertas)

conectados por Flujos de Secuencia, los que determinan cómo se va pasando de un objeto a otro

durante la ejecución del Proceso.

La ejecución de un Proceso comienza cuando ocurre un Evento. En el ejemplo, cuando ocurre el

Evento Consulta Recibida, gatillado por el Mensaje desde el Cliente.

Una vez ocurrido el Evento el flujo continúa con la Tarea Manejar la Consulta, la que es realizada por

el Administrador de Cuenta. Durante la ejecución de esta Tarea el Administrador de Cuenta

determina si puede o no solucionar la consulta del Cliente. Una vez terminada la Tarea, el Proceso se

bifurca al llegar a una Compuerta que tiene dos caminos alternativos. Si el Administrador de Cuenta

puede solucionar la consulta el mismo realiza la Tarea Explicar Solución (que, mediante un Flujo de

Mensaje, comunica la solución al Cliente) y el Proceso termina. En caso contrario, la ejecución

continúa en la Tarea Manejar Incidencia de Nivel 1 realizada por la Mesa de Ayuda Nivel 1.

Así el Proceso continúa con la realización de diferentes Tareas y siguiendo el flujo determinado por la

Compuertas.

Page 18: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

14

Figura 3-4. Incicio del Proceso al gatillarse el Evento Consulta Recibida

Las Actividades en BPMN son de dos tipos: Tareas y Subprocesos. Las primeras se consideran

atómicas, en el sentido que, a nivel del modelo BPMN, no tienen mayor nivel de detalle. Por otro lado,

los Subprocesos sí tienen mayores detalles (normalmente representados en otro diagrama). En el

ejemplo, todas las Actividades son Tareas, excepto Proveer retroalimentación que es realizada por el

Desarrollador (ver Figura 3-5).

Figura 3-5. Actividades: Tareas o Subprocesos

En la sección siguiente se realiza una descripción de los principales elementos de BPMN, éstos cubren

todo lo necesario para entender los ejemplos de BPMN mostrados en este documento.

Page 19: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

15

3.2 Elementos de BPMN

Los elementos de BPMN para describir Procesos y Colaboraciones son:

Elementos de Flujo.

Elementos de Conexión

Calles de Responsabilidad (Swimlanes)

Artefactos

3.2.1 Elementos de Flujos

Los Elementos de Flujo (Actividades, Eventos y Compuertas) son los principales elementos de BPMN

pues permiten describir lo que pasa en el Proceso.

3.2.1.1 Actividades

El trabajo realizado en un Proceso se representa con Actividades, las que pueden ser Subprocesos o

Tareas.

Un Subproceso es una actividad no atómica, es decir, compuesta por otras actividades. Puede estar

colapsado (no se muestran sus actividades internas) o expandido.

Figura 3-6. Subproceso colapsado

Una Tarea es una actividad atómica, es decir, no se descompone en un mayor nivel de detalle. Son

realizadas por una persona y/o aplicación. La tipificación de las Tareas se muestra en la Tabla 1.

Page 20: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

16

Tabla 1. Tipificación de Tareas BPMN

Tarea sin especificación mayor.

Tarea realizada por una persona sin el apoyo de

un Motor de Procesos o cualquier aplicación de

software.

Típica Tarea “workflow” donde una persona

realiza la Tarea con la asistencia de una aplicación

de software.

Usa algún tipo de servicio, el que puede ser un

servicio web o una aplicación automatizada.

Tarea automatizada ejecutada recurrentemente,

puede correr en un Motor de Procesos.

Provee un mecanismo para entregar un input a un

Motor de Reglas de Negocio y obtener el output

desde éste.

3.2.1.2 Eventos

Un Evento modela algo que sucede durante el proceso. Por ejemplo:

Cambio de estado de un documento.

Un mensaje que llega o que se envía.

Un proceso que se inicia o finaliza.

Se cumple un plazo.

Page 21: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

17

Hay tres tipos de Evento:

Inicial: indica dónde comienza un Proceso. Circulo con línea simple.

Intermedio: ocurren entre un Evento Inicial y un Evento Final. Círculo con línea doble.

Final: indica dónde termina el Proceso. Círculo con línea gruesa.

Figura 3-7. Tipos de Eventos

Para cada tipo de Evento existen variantes que indican el motivo por el que éste se gatilla. Las

principales variantes para cada tipo se muestran en las siguientes Tablas.

Tabla 2. Eventos Iniciales más utilizados

El Proceso comienza de inmediato.

El Proceso comienza cuando llega un

Mensaje desde otro Participante.

El Proceso comienza cuando se cumple

una fecha, hora o ciclo (“3 pm”, “1er

viernes del mes”).

Page 22: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

18

Tabla 3. Eventos Intermedios más utilizados

Para indicar un cambio de estado en el

Proceso.

Para recibir o enviar un Mensaje desde o

hacia otro Participante.

Cuando se cumple una fecha, hora o ciclo.

Tabla 4. Eventos Finales más utilizados

Indica el fin de un flujo dentro de un

Proceso.

El Flujo termina con el envío

de un Mensaje a otro Participante.

Todas las Actividades del Proceso

terminan.

Page 23: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

19

3.2.1.3 Compuertas

Las Compuertas (Gateways) representan bifurcaciones, uniones y acoplamientos de flujos. Se usan

cuando se necesita controlar el camino que seguirá el Proceso de acuerdo a condiciones basadas en

datos o en Eventos. Las compuertas más utilizadas son tres: Exclusiva, Inclusiva y Paralela.

Tabla 5. Compuertas más utilizadas

Se sigue un solo camino dependiendo

del cumplimiento de condiciones.

Se sigue uno o más caminos

dependiendo del cumplimiento de

condiciones.

Se siguen varios caminos paralelos.

3.2.2 Calles de Responsabilidad (Swimlanes)

Las Calles de Responsabilidad permiten organizar los diagramas para resaltar las capacidades

funcionales o responsabilidades de quienes (personas y organizaciones) participan en las

Colaboraciones.

Hay dos tipos de Calles de Responsabilidad: Piscinas (Pools) y Carriles (Lanes).

Los nombres de Piscinas y Carriles recuerdan a roles, cargos y partes de un organigrama. BPMN no

tiene como propósito modelar la estructura de la organización. Sin embargo, en un modelo correcto de

Procesos BPMN todas las Piscinas y Carriles deben estar de una otra manera reflejados en las

estructura de la organización y los roles y cargos que las personas tienen en dichas estructura.

Page 24: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

20

3.2.2.1 Piscina

Una Piscina es la representación gráfica de un Participante en una Colaboración. Todo Proceso ocurre

dentro de los límites de una Piscina.

Figura 3-8. Formas de diagramar una Piscina

3.2.2.2 Carril

Un Carril es una sub-partición dentro de una Piscina, normalmente son usados para representar:

Roles internos

Sistemas de Información

Unidades organizacionales como departamentos, gerencias, etc.

Figura 3-9. Carriles dentro de una Piscina

Page 25: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

21

3.2.3 Elementos de Conexión

Los Elementos de Conexión unen los Elementos de Flujo, Calles de Responsabilidad y Artefactos entre

sí. Hay tres Elementos de Conexión: Flujo de Secuencia, Flujo de Mensaje y Asociación.

3.2.3.1 Flujo de Secuencia

El Flujo de Secuencia es usado para mostrar el orden en que las actividades son realizadas en un

Proceso. Puesto que un Proceso ocurre dentro de los límites de una Piscina se colige que un Flujo de

Secuencia no puede atravesar los límites de ésta.

Un Flujo de Secuencia uno dos Elementos de Flujo, es decir, Actividades, Eventos y Compuertas.

Figura 3-10. Flujo de Secuencia

Cada Elemento de Flujo puede tener cero o varios Flujos de entrada o de salida. En la Tabla 6 se

muestran las Reglas de Conexión de Flujo de Secuencia.

Tabla 6. Reglas de Conexión de Flujo de Secuencia

Page 26: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

22

3.2.3.2 Flujo de Mensaje

El Flujo de Mensaje es usado para mostrar la comunicación entre Participantes en una Colaboración.

Por lo tanto no puede ocurrir dentro de una Piscina, siempre va de una a otra.

Figura 3-11. Flujo de Mensaje

Un Flujo de Mensaje conecta dos Piscinas o Elementos de Flujo dentro de ellas. En la Tabla 7 Tabla

6se muestran las Reglas de Conexión de Flujo de Mensaje.

Tabla 7. Reglas de Conexión de Flujo de Mensaje

Page 27: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

23

El Flujo de Mensaje sólo se refiere a una comunicación entre dos Piscinas, no a la tecnología usada

para dicha comunicación. Por ejemplo, dos personas se pueden comunicar cara a cara, o dos Sistemas

de Información lo pueden hacer vía servicios web. A nivel de BPMN lo relevante es dejar establecido

que ambos Participantes se comunican.

El Flujo de Mensaje es asincrónico. Esto significa que después que un Participante envía un Mensaje a

otro Participante (otra Piscina), sigue con la ejecución de su Proceso, es decir, desde la Tarea o Evento

que generó el Mensaje se sigue un Flujo de Secuencia hacia otra Tarea o Evento dentro de la misma

Piscina.

Si una Colaboración requiere que dos Participantes se coordinen, lo normal es que uno de ellos le envíe

un Mensaje a otro y continúe con su Proceso. Más adelante, el que envío el Mensaje se queda

esperando la respuesta del otro, por medio de una Tarea o Evento de Recepción de Mensaje.

Figura 3-12. Coodinación de Participantes a través de Mensajes

Page 28: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

24

3.2.4 Otros Elementos de BPMN

Lo elementos descritos de BMPN son los más importantes ya que con ellos es posible realizar la mayor

parte de los modelos de Procesos y Colaboraciones. Sin embargo, existen más variantes de los

elementos descritos y otros tipos de diagramas. A continuación una lista sumaria del contenido de

BPMN:

Tipos de Tarea: Abstracta, Manual, Usuario, Servicio, Envío, Recepción, Regla de Negocio y

Script.

Marcas de Actividad: las Tareas y Subprocesos puede ser repetitivas (secuencial o paralelo) y

ad-hoc.

Transacción: un Subproceso puede ser una transacción, es decir, soportado por un protocolo

especial que asegura que todas las partes involucradas acuerdan que la actividad puede ser o

completada o cancelada.

Actividad de Llamada: punto en el Proceso donde se (re)utiliza un Proceso Global o una Tarea

Global.

Subproceso-Evento: no es parte del flujo normal, puede ejecutarse varias veces mientras el

Proceso que lo contiene está activo.

Tipos de Evento: Nada, Mensaje, Timer, Condicional, Señal, Múltiple, Múltiple Paralelo, Error,

Escalada, Cancelar, Compensación, Enlace, Terminar.

Eventos adosados a Actividades: los Eventos pueden estar adosados a una Actividad, la que

pueden interrumpir o no.

Tipos de Compuertas: Exclusivo, Basado en Eventos, Basado en Eventos Paralelo, Inclusivo,

Complejo y Paralelo.

Conversaciones: Diagramas que muestran una versión simplificada de una Colaboración.

Coreografías: Diagramas que muestra secuencias ordenadas de intercambio de mensajes entre

dos o más Participantes.

Artefactos: proveen información adicional al Proceso, pero no influyen en el flujo del Proceso.

Asociación : usado para conectar información y Artefactos a elementos gráficos de BPMN

Para fuentes más detalladas de BPMN consultar la bibliografía al final del documento.

Page 29: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

25

4 Lenguaje Unificado de Modelado (UML)

UML (Unified Modeling Language) es un lenguaje gráfico para describir modelos de software, con

enfoque orientado a objetos. Se usa UML para:

Visualizar y comunicar modelos e ideas.

Especificar modelos.

En ingeniería directa e inversa.

Documentar.

UML se puede usar en aplicaciones de cualquier dominio: finanzas, ciencia, ingeniería, grandes y

pequeñas empresas, etc.

4.1 Estructura de UML

UML está definido por los Diagramas que permiten visualizar distintas vistas o aspectos de una

determinada realidad; y los Elementos y Relaciones que se muestran en los Diagramas.

Figura 4-1. Contenido de UML

En Modelo de un sistema es una descripción de éste y su entorno con un determinado propósito.

Usualmente un Modelo es una combinación de texto y diagramas.

Page 30: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

26

El objetivo es construir Modelos, no sólo Diagramas con UML u otros leguajes similares. Para ello hay

que crear Modelos “enriquecidos”, es decir, complementar lo puramente gráfico con documentación de

los elementos, restricciones formales (invariantes, pre y pos condiciones), estereotipos, valores

etiquetados, etc.

4.1.1 Tipos de Modelos en UML

UML permite construir dos tipos de Modelos: Estáticos o Estructurales, y de Comportamiento o

Dinámicos.

Los Modelos Estructurales destacan la estructura y la organización del sistema:

Clases

Objetos

Componentes

Paquetes

Despliegue

Artefactos

Estructura Compuesta

Los Modelos Comportamiento destacan los aspectos dinámicos del sistema:

Casos de Uso

Secuencia

Comunicación

Estados

Actividades

Tiempos

Visión Global de Interacciones

Como se ve, UML contiene una gran variedad de Diagramas que permiten modelar distintas vistas de

los sistemas de software. Sin embargo, algunos son más importantes y, por ende son más utilizados. De

acuerdo a (Grossman, Aronson, & McCarthy, 2005), los más utilizados son, es este orden: Casos de

Uso, Clases, Secuencia, Estados, Actividades, Comunicación, Componentes y Despliegue.

Para la compresión de los ejemplos y discusiones en el resto del documento, en las siguientes secciones

se describen las principales características de los Modelos de Clase, Casos de Uso y Actividades.

Page 31: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

27

4.2 Modelo de Clases

Los Modelos de Clase son usados para mostrar la Estructura Estática de un Sistema de Software

Computacional o del Dominio en el que existe dicho Sistema.

En un Dominio donde existen personas que son dueñas de vehículos, podemos – informalmente –

describir este hecho en los siguientes términos:

Una persona tiene vehículos, los que tienen color y marca.

Con mayor formalidad, lo anterior, se puede expresar como:

Una Persona posee cero o más Vehículos. Un Vehículo es de una Persona que cumple, en esta

relación, el rol de propietario.

Un Vehículo tiene color, el que puede ser rojo, verde o azul. Un Vehículo tiene una marca, la

que puede ser Ford, Datsun o Volvo.

En UML lo anterior se representa gráficamente con íconos y relaciones mostradas como líneas entre

éstos. Las agrupaciones de entidades (cosas, personas, etc.) se denominan clases y se representan

mediante rectángulos. En el ejemplo hay dos Clases: Persona y Vehículo.

Figura 4-2. Diagrama de Clases UML

Un tipo especial de Clase, denominado, Enumerador se utiliza para representar conjuntos acotados de

elementos simples. En ejemplo hay dos Enumeradores; Color y Marca.

Las relaciones entre Clases en UML se denominan Asociaciones. En el ejemplo, desde la perspectiva

de una Persona, la asociación hacia Vehículo describe el hecho que una Persona posee cero o más

(0..*) vehículos.

Persona

«enumeration»

Color

ROJO

VERDE

AZUL

«enumeration»

Marca

FORD

DATSUN

VOLVO

Vehículovehículos

0..*

poseepropietario

1

marca

10..*

color

1

0..*

Page 32: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

28

Figura 4-3. Asociación entre Persona y Vehículo vista desde Persona

Desde la perspectiva de un Vehículo, la asociación hacia Persona describe el hecho que un Vehículo

es posesión de una (1) Persona, cumpliendo el rol de propietario.

Figura 4-4. Asociación entre Persona y Vehículo vista desde Vehículo

Los Modelos de Clases permiten modelar relaciones entre conceptos y sus variedades. Por ejemplo,

Vehículo es la base de un conjunto de clases relacionadas por Generalizaciones: Camión, Camioneta

y Automóvil son tipos de Vehículo. Además, Sedán, SUV y Hatchback son tipos de Automóvil.

Figura 4-5. Jerarquía de Clases: Vehíclos y sus variedades

Persona Vehículovehículos

0..*

poseepropietario

1

Persona Vehículovehículos

0..*

poseepropietario

1

Vehículo

Camión Camioneta Automóvil

Sedán SUV Hatchback

Page 33: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

29

Las Clases pueden ser modeladas con mayor detalle agregándoles:

Atributos: representan características de cada Persona. En ejemplo rut, nombre y direcciones.

Operaciones: describen lo que pueden hacer una Persona. En el ejemplo comprar y vender.

Una Asociación también puede tener datos, en UML se utiliza una Clase para representarlos y ésta es

unida a la Asociación. En el ejemplo la instancia de la Asociación corresponde a una Compra/Venta

realizada en una determinada fecha y que involucra un cierto monto.

Figura 4-6. Clases con atributos y operaciones. Asociacción con datos

Los Modelos de Clases pueden ser usados para representar el Dominio del problema con un alto grado

de abstracción para que pueda ser entendido tanto por técnicos como por los usuarios del Dominio. En

el otro extremo, con un alto grado de detalle y formalización las Clases se pueden usar para representar

clases en lenguajes de programación orientados a objetos como Java o C#.

Persona

rut: Rut

nombre: Nombre

direcccion comercial: Direccion

direcccion privada: Direccion

comprar(Vehículo)

vender(Vehículo)

«enumeration»

Color

ROJO

VERDE

AZUL

«enumeration»

Marca

FORD

DATSUN

VOLVO

Compra/Venta

fecha: Date

monto: int

Vehículo

patente: string

color

1

0..*

vehículos

0..*

poseepropietario

1

marca

10..*

Page 34: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

30

Figura 4-7. Clase detallada (izq.), código Java (der.)

En resumen, los Modelos de Clases pueden ser usados en distintas etapas del desarrollo de Software:

desde la comprensión del problema en el lenguaje del Negocio, hasta la programación, pasando por el

análisis y el diseño.

Los Modelos de Clases contienen más elementos y relaciones que los aquí mostrados: Interfaces,

Agregaciones, Composiciones, Asociaciones Cualificadas, entre otros. Para mayor detalle consultar la

bibliografía.

Comparable

EMail

- localPart: String

- domain: String

- EMail(String, String)

+ getLocalPart(): String

+ getDomain(): String

+ valueOf(String): EMail

+ toString(): String

+ compareTo(EMail): int

public class EMail extends Tipo implements Comparable<EMail> {

private String localPart;

private String domain;

private EMail(String localPart, String domain) { . . . }

public String getLocalPart() {return localPart;}

public String getDomain() {return domain;}

public static EMail valueOf(String stringEmail)throws TipoErroneoException{

if (stringEmail == null || stringEmail.length()== 0){

throw new TipoVacioException("Email vacío");

}

EMail resultado = null;

String regex = "\\w+@(\\w+\\.)+[a-zA-Z]{2,3}";

Pattern pattern = Pattern.compile(regex);

Matcher m = pattern.matcher(stringEmail);

if (m.matches()){// email bien escrito

String[] partes = stringEmail.split("@");

resultado = new EMail(partes[0], partes[1]);

} else { throw new TipoErroneoException("Email mal escrito");

return resultado;

}

@Override

public String toString() {return localPart + "@" + domain;}

@Override

public int compareTo(EMail r) {

return this.toString().compareTo(r.toString());

}

}

Page 35: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

31

4.3 Modelo de Casos de Uso

Los Modelos de Casos de Uso son usados para representar los Requerimientos de un Sistema de

Información en términos de la forma en que los usuarios (personas u otros sistemas) lo usan.

En un Sistema de Información que maneja Cuentas Bancarias podemos – informalmente – describir los

requerimientos12

en los siguientes términos:

El titular de una o más Cuentas puede, en un Cajero Automático, hacer retiros o

transferir entre cualquiera de sus Cuentas. Cuando retira o transfiere, el usuario

puede imprimir un comprobante de la transacción, si lo desea. La transferencia

entre cuentas de distinta moneda, que es una variación de la transferencia normal,

es una característica opcional que, dependiendo de los recursos disponibles, será o

no incluida en la siguiente versión del sistema.

Con mayor formalidad, lo anterior, se puede expresar como:

El Sistema es utilizado por el Actor Cliente Cuentacorrentista.

El Cuentacorrentista utiliza instancias de los Casos de Uso (CU) Retirar de Cuenta y

Transferir entre Cuentas.

El CU Imprimir Comprobante es incluido por Retirar de Cuenta y Transferir entre

Cuentas. Es decir, dentro de la ejecución de éstos se incluye (llama o utiliza) a Imprimir

Comprobante. En este sentido, este último CU es obligatorio para que los otros dos puedan

funcionar.

El CU Transferir entre Cuentas de distinta Moneda es una extensión de Transferir entre

Cuentas, en el sentido que es una variación de este último, y se considera opcional porque

puede o no ser incluido en la siguiente entrega13

.

Un Modelo de Casos de Uso UML consta de Casos de Uso, Actores y relaciones entre ellos: los

Actores utilizan Casos de Uso, los Casos de Uso incluyen, extienden y/o generalizan otros Casos de

Uso.

Como muestra la Figura 4-8, Transferir entre Cuentas de distinta Moneda depende de la existencia

de Transferir entre Cuentas, es una variación de éste (la flecha apunta hacia Transferir entre

Cuentas). Por otro lado, Transferir entre Cuentas depende de la presencia de Imprimir

Comprobante (la flecha apunta hacia Imprimir Comprobante).

El nombre del Caso de Uso refleja lo que el Usuario hace con el Sistema. Por ejemplo, si una tienda

vende sus productos a sus clientes, ¿cuál será el Caso de Uso que representa este hecho?, ¿Vender

Producto o Comprar Producto?

12 Obviamente, un sistema como éste tendrá muchos más requerimientos.

13 Si no es incluido de todos modos el sistema podrá ser utilizado, no estará incompleto.

Page 36: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

32

Figura 4-8. Modelo de Casos de Uso

Si el cliente compra por Internet habrá un Caso de Uso Comprar Producto asociado al Actor Cliente,

pues es éste quien interactúa con el Sistema de Información. Por otro lado, si el cliente va a una Tienda

y es un vendedor quien registra lo que el cliente compró, habrá un Caso de Uso Vender Producto

asociado al Actor Vendedor. Lo normal es que existan ambos Casos de Uso y ambos Actores (como

muestra la Figura 4-9). A nivel sistémico los componentes que implementan ambos Casos de Uso serán

los mismos, diferirán sólo en los que implementan la interfaz de usuario mediante la cual los Actores

acceden al mismo Sistema de Información.

Figura 4-9. El Caso de Uso refleja lo que el Actor hace con él

Retirar de Cuenta

Imprimir

Comprobante

Cliente Cuenta-

correntista

Transferiri entre

Cuentas

Transferir entre

Cuentas de distinta

Moneda

«include»

«extend»

«include»

Comprar Producto

Cliente

Vender Producto

Vendedor

Page 37: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

33

Los Diagramas de Casos de Uso son sencillos en el sentido que contienen pocos íconos y relaciones.

Esta sencillez se extiende también a su utilización: deben ser simples y fáciles de entender tanto por

técnicos como por usuarios del Dominio.

Los Casos de Uso se utilizan para:

Comunicarse con el usuario final, el cliente y otros involucrados.

o Proporciona credibilidad en una etapa inicial del desarrollo del Sistema de Información.

o Asegura una comprensión mutua de los requerimientos.

Identificar

o Quién interactuará con el Sistema de Información.

o Qué interfaz deberá tener el Sistema de Información.

Validar que los requerimientos estén alineados con las reales necesidades de la organización.

Verificar

o Que se hayan capturado todos los requerimientos.

o Que los desarrolladores hayan entendido los requerimientos.

Servir de entrada al desarrollo de la solución de software que cumplirá con los requerimientos

definidos por los Casos de Uso.

Gestionar el Proyecto

o Planificar y controlar un proyecto de software.

o Estimar la complejidad y tamaño de un Sistema de Información (Puntos de Casos de

Uso).

Como muestra la Figura 4-10, los Casos de Uso no sólo sirven para describir los Requerimientos sino

que también son la base para planificar el Proyecto14

y los demás Modelos15

están relacionados con él.

14 Las Iteraciones se planifican de acuerdo a los Casos de Uso que serán trabajados en ella. Los recursos de distribuyen de

acuerdo a ellos: tal Diseñador diseñará tales Casos de Uso, tal Desarrollador programará y probará tales Casos de Uso en tal

fecha, etc. El avance se mide en términos de ellos: se ha diseñado el 80% de los Casos de Uso, ha pasado a producción el

45% de los Casos de Uso, etc.

15 Los Modelos pueden estar documentados o no, dependiendo del Proceso de Desarrollo utilizado (Ágil, MDA, etc.).

Page 38: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

34

Figura 4-10. Desarrollo dirigido por Casos de Uso

4.3.1 Descripción de un Caso de Uso

Los Casos de Uso son un buen ejemplo para ver la diferencia entre Modelos y Diagramas. Los Modelos

de Casos de Uso son para describir los requerimientos, pero no toda la descripción de éstos está en los

Diagramas de Casos de Uso. Por ejemplo, el hecho que el Usuario pueda decidir imprimir o no el

comprobante no está en el Diagrama (el dibujo) sino en la descripción del Caso de Uso.

A diferencia de los Modelos de Clases que contienen variados íconos y relaciones que permiten en el

Diagrama presentan mucha información, los Modelos de Caso de Uso contienen la mayor parte de la

información en la documentación de cada Caso de Uso, la que contiene:

Nombre del Caso de Uso.

Descripción breve.

Precondiciones.

Postcondiciones.

Flujos de Eventos.

o Flujo Básico.

o Flujo(s) Alternativo(s).

Interfaces con Usuarios o con otros Sistemas de Información.

Diferentes técnicas manejan distintos niveles de documentación con distintos grados de formalización.

En un extremo puede bastar el nombre y una descripción como entrada para el desarrollo. En el otro

extremo el Caso de Uso puede ser descrito detallada y formalmente como entrada para un diseño

detallado. Por ejemplo, las pre y postcondiciones pueden ser formalizadas con OCL16

en términos de

16 Object Constraint Language.

Page 39: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

35

lógica de predicados, y los Flujos de Eventos pueden ser descritos con, por ejemplo, diagramas UML

de Actividad o de Secuencia.

Los Casos de Uso no deben estar descritos en términos de botones, selecciones y otros elementos

típicos de una pantalla. De este modo un mismo Caso de Uso puede estar asociado a más de una

Interfaz de Usuario en distintas tecnologías17

. Sin embargo, como parte de los requerimientos es

necesario tener definidas las pantallas, mapas de navegación e interfaces con otros Sistemas de

Información, todo esto no sólo hace que los requerimientos estén más completos sino que también

ayudan a definir mejor los Casos de Uso.

Los Diagramas de Casos de Uso contienen más elementos y relaciones que los aquí mostrados: Temas,

Generalizaciones, entre otros. Para mayor detalle consultar la bibliografía.

4.3.2 Requerimientos sólo con Casos de Uso

Distintas metodologías de Desarrollo de SW usan uno o más artefactos para el levantamiento de

Requerimientos: Lista de Características, Modelo de Requerimientos, Modelo de Casos de Uso.

Figura 4-11. Artefactos para captura Requerimientos y su secuencia temporal

Por lo expuesto en las secciones anteriores, tener un Modelo de Requerimientos junto con un Modelo

de Casos de Uso es, por definición, redundante.

Algunas metodologías utilizan los Casos de Uso como una técnica de diseño de las interfaces de

usuario y el paso de una a otro, por lo que el diagrama termina siendo una representación del mapa de

navegación de la aplicación.

17 Un mismo Caso de Uso representa requerimientos funcionales que pueden ser accedidos desde un Smartphone, desde una

típica aplicación web a través de un browser y desde una aplicación cliente servidor. En los tres escenarios las pantallas y la

interacción serán diferentes, pero el Caso de Uso será el mismo.

Page 40: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

36

El enfoque presentado en este documento utiliza a los Casos de Uso en su propósito original: captura y

descripción de los requerimientos funcionales y no funcionales. Por lo tanto, no se usará un Modelo de

Requerimientos tradicional. Además, no se usará una Lista de Características puesto que los Casos de

Uso vendrán determinados por los Procesos de Negocio.

Figura 4-12. Requermientos exclusivamente con Casos de Uso

Page 41: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

37

4.4 Modelo de Actividades

Los Modelos de Actividad son usados para representar el comportamiento del Sistema de Información

o del Negocio. Muestran actividades y acciones (atómicas), destacando:

Condiciones y flujos alternativos.

Tareas y procesos concurrentes.

Responsabilidades sobre ciertas actividades.

Normalmente son utilizados para:

Describir Procesos de Negocio.

Describir Flujos de Eventos en Casos de Uso.

Describir algoritmos.

En un Dominio donde existen personas que son dueñas de vehículos, podemos – informalmente –

describir este hecho en los siguientes términos:

Si el contrato está en regla, lo firmo. En caso contrario lo analizo y agrego anexos,

y luego lo firmo.

En UML lo anterior se muestra gráficamente con íconos que representan actividades, bifurcaciones y

barras de sincronización, unidos por líneas que indican la secuencia de ejecución.

Figura 4-13. Diagrama de Actividad

Page 42: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

38

Los Diagramas de Actividad también pueden contener Carriles (Lanes) que indican los responsables de

las actividades descritas. Si el diagrama representa un Proceso de Negocio, los responsables serán roles

o unidades organizacionales. Si representa el comportamiento del software, los responsables serán

módulos, componentes o sistemas.

Figura 4-14. Diagrama de Actividad con Carriles

Existen semejanzas entre los Diagramas de Actividad UML y los Diagramas de Procesos de BPMN,

pero también muchas diferencias. Según lo indicado en (Object Management Group, 2013) BPMN fue

diseñado considerando la práctica y experiencia con lenguajes y notaciones ya existentes, entre los que

se cuentan los Diagramas de Actividad UML.

Los Diagramas de Actividades contienen más elementos que los aquí mostrados: objetos creados y

recibidos, envío y recepción de señales, entre otros. Para mayor detalle consultar la bibliografía.

Page 43: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

39

4.5 Modelado de Procesos de Negocio, ¿UML o BPMN?

Como se explicó en la sección anterior, UML también puede ser usado para el Modelado de Procesos

de Negocio. La manera más directa es por medio de Diagramas de Actividad como se muestra en la

Figura 4-14, donde se representan las actividades para crear el Modelo de Casos de Uso y los Roles que

participan. Los Diagramas de Actividad no difieren mucho de los flujogramas comúnmente utilizados

para describir procedimientos administrativos18

.

Extensiones de UML incluyen Casos de Uso de Negocio y Actores de Negocio, que, usando una

notación análoga a los Casos de Uso, representan los Participantes y los Procesos de Negocio.

Gráficamente los Casos de Uso de Negocio se distinguen porque tiene una línea diagonal en la parte

inferior derecha. Los Actores de Negocio tienen una línea diagonal en la parte inferior derecha de su

cabeza.

Los Casos de Uso de Negocio se pueden detallar con texto estructurado y/o diagramas dinámicos de

UML (Actividades o Secuencia).

Figura 4-15. Casos Uso de Negocio y Actores de Negocio

18 Ver Nota 8 (pág. 11).

Solicitar Ayuda

«business actor»

Administrador de

Cuenta

«business actor»

Desarrollador

Proveer Soporte en

Mesa de Ayuda

Proveer

Retroalimentación

de desarrollo

«business actor»

Cliente

«business actor»

Agente de Mesa de

Ayuda Nivel 1

«business actor»

Agente de Mesa de

Ayuda Nivel 2

«invokes»

«extend»

Page 44: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

40

Las extensiones de UML para Procesos de Negocio surgieron por la necesidad del personal de TI de

conocer el negocio para la captura de requerimientos y lo más natural fue reutilizar las notaciones

propias del modelado de Sistemas de Información. Sin embargo, estas notaciones no son utilizadas por

los encargados de la documentación de los Procesos de Negocio.

Se podría argumentar que al trabajar dentro de UML, el alineamiento de los elementos de Procesos de

Negocio y los Requerimientos de Software sería más natural y sencillo. Sin embargo, esto no es así

pues UML es un conjunto de notaciones donde está bien definida la relación entre los elementos de

cada tipo de diagrama, pero no entre ellos. Es responsabilidad de las metodologías y técnicas que usan

UML definir la trazabilidad entre los elementos de los distintos diagramas.

Por lo tanto ya sea que se use UML o BPMN para los Procesos de Negocio, de todas maneras habrá

que definir el mapeo entre elementos de los Procesos de Negocio (en UML o BPMN) a los

requerimientos en Casos de Uso UML.

Además, los diagramas UML se pueden usar en distintas etapas del modelado e implementación de

Sistemas de Información. Por este motivo el estándar UML establece las reglas sintácticas del lenguaje,

pero da espacio a las metodologías y técnicas que lo utilizan para que interpreten la semántica exacta

de los diagramas. Por su parte, BPMN está pensado exclusivamente para Procesos de Negocio y para

ser utilizado por herramientas que automaticen la ejecución de dichos Procesos, por lo tanto tiene una

semántica muy clara y deja menos espacio para interpretaciones.

En resumen, es mejor utilizar BPMN para modelar los Procesos de Negocio en lugar de UML por las

siguientes razones:

Fue diseñado específicamente para modelar Procesos de Negocio.

Representa los Procesos de Negocio como flujogramas enriquecidos que pueden ser entendidos

por especialistas de procesos.

Se está convirtiendo en un estándar de facto en las herramientas BPMS.

Por su naturaleza procedural son fáciles de entender por el personal técnico TI.

Page 45: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

41

5 Metodología de Alineamiento

UML y BPMN son estándares, es decir, establecen las normas sintácticas del lenguaje – cómo realizar

los diagramas - y su semántica – el significado de los elementos de los diagramas.

Tanto BPMN como UML tiene una gran cantidad de elementos y tipos de diagramas. En la mayoría de

los casos no se requiere usarlos todos. Además, ambos estándares presentan diferentes interpretaciones

para algunos de sus elementos, dejando al usuario del lenguaje la decisión de cuál usar.

BPMN y UML no son Metodologías ni Técnicas, sino estándares neutros con respecto a cualquier

Metodología. Cuando una Metodología usa BPMN y/o UML debe indicar qué usará (tipos de

diagramas y elementos) y cómo los usará. Todo uso e interpretación debe ser consistente con la

especificación de los estándares.

En las siguientes secciones se describen los principios y políticas sobre los que se sustenta la

Metodología de Alineamiento. Luego se describen detalladamente sus dos partes estructurales:

Ambientes y Patrones. Donde los Ambientes establecen reglas sobre cómo definir los Participantes de

las Colaboraciones, es decir, cómo aplicar Piscinas y Carriles. Y los Patrones definen las distintas

variantes en que la Tecnología de Información y Comunicación (TIC) puede aparecer en los Procesos

de Negocio, y establecen cómo cada una de éstas se representa como Casos de Uso y Actores.

5.1 Principios y Políticas

La Metodología de Alineamiento se sustenta sobre algunos principios y políticas que se derivan de

ciertos hechos y supuestos.

El Modelado del Negocio y el Modelado de Sistemas de Información son actividades diferentes, con

propósitos diferentes.

I. Los Procesos de Negocio y el Modelo de los Sistemas de Información no

estarán mezclados.

Las Empresas tienen distintos niveles de madurez en cuanto a la documentación de los Procesos de

Negocio y su grado de automatización

II. La Metodología de Alineamiento requiere que los Procesos de Negocio estén

documentados con BPMN.

III. La Metodología de Alineamiento no asume que los Procesos se ejecuten en un

BPMS.

IV. La Metodología de Alineamiento no asume derivación automática de los

Requerimientos.

El Modelado del Negocio tiene precedencia lógica y, normalmente, precedencia temporal respecto al

Modelado del Sistema de Información.

Page 46: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

42

V. En los Procesos de Negocio se definirán los elementos donde el uso de TIC se

mapeará al Modelo de los Sistemas de Información.

Todo elemento del Modelo de Sistemas de Información debe satisfacer una necesidad de TIC en los

Procesos de Negocio. Las funcionalidades de los Sistemas de Información se originan como

Requerimientos de Software.

VI. Para asegurar el Alineamiento, ciertos elementos de los Procesos de Negocio

estarán mapeados a Requerimientos de Software en el Modelo de los Sistemas

de Información.

Actualmente, los Negocios no son tecnológicamente neutros. Los detalles tecnológicos no son tema del

Modelo de Negocio.

VII. En los Procesos de Negocio se identificarán explícitamente los puntos en que

se requiere soporte TIC.

VIII. El tipo de TIC a utilizar y la forma en que ésta trabajará son asunto del

Modelo de los Sistemas de Información.

Una vez definidos los Requerimientos de Software es posible, a partir de ellos, construirlo con

diferentes Metodologías.

IX. La Metodología de Alineamiento no asume un Proceso específico de

Desarrollo de Software.

Una aclaración es necesaria respecto a que la Metodología de Alineamiento requiere que los Procesos

de Negocio están documentados con BPMN, y que no está atada a ninguna Metodología de Desarrollo

de Software en particular.

La primera exigencia puede ser fuerte para aquellas organizaciones donde los Procesos de Negocio no

están formalizados, pero no es posible pensar en ningún esfuerzo tendente al alineamiento entre los

Procesos de Negocio y los Sistemas de Información sin que los primeros estén documentados

detalladamente. Para llegar a la formalización de los Procesos de Negocio, la Empresa debe tener

implementado algún tipo de Sistema de Gestión de Calidad (SGC)19

. La exigencia de usar BPMN20

es

necesaria para poder realizar el alineamiento de manera concreta con alguna notación estándar y no

sólo enunciar ideas.

Los únicos elementos del Modelo de los Sistemas de Información que la Metodología considera para el

Alineamiento son los Requerimientos, expresados como Casos de Uso. Por lo tanto las demás partes

19 No necesariamente se debe estar certificado o acreditado bajo alguna norma (ISO 9000, CMMi, acreditaciones

académicas u otros), pero sí los Proceso de Negocio deben ser consistentes con la Misión, Visón y Modelo de Negocio de la

Empresa, y debe haber algún tipo de gestión formal de los Procesos de Negocio

20 Si los Procesos de Negocio están descritos con otra notación es posible adaptar la Metodología de Alineaminto para ellas,

aunque no es parte de este documento.

Page 47: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

43

del Modelo del Sistema de Información 21

, formalizados o no: componentes, casos de prueba, código

fuente, etc., no son relevantes para el Alineamiento.

Figura 5-1. Desde Misión a Procesos y desde Casos de Uso a Código

La Figura 5-1 muestra el hecho que los Procesos de Negocio deben estar dentro de un Sistema de

Gestión de Calidad formal o informal, de ahí el apelativo de SGC like. Por otro lado, los Casos de Uso

pueden ser el inicio de un Proceso de Desarrollo altamente documentado como Rational Unified

Process, o la descripción liviana de los requerimientos a desarrollar en un Proceso Ágil, o un modelo

formal de entrada a un desarrollo guiado por modelos que cumpla los criterios de MDA (Model Driven

Architecture).

21 Si el Modelo de Sistemas cuenta con modelos formales, y si las herramientas de desarrollo lo permiten, se pueden

mantener alineados los elementos del desarrollo con los Requerimientos de Software, y así - por transitividad – determinar,

por ejemplo, qué componentes soportan qué Requerimientos, y éstos qué Procesos de Negocio apoyan, etc.

Page 48: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

44

5.2 Ambientes

Como está explicado en

Page 49: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

45

Modelos y Notación de Procesos de Negocio (BPMN), una Colaboración entre Participantes se

representa con varias Piscinas (una por cada Participante con su propio Proceso de Negocio) con

Flujos de Mensaje entre ellas. Dentro de cada Piscina es posible representar, de manera libre, unidades

organizacionales, roles y cargos como Carriles para identificar quién hace qué dentro de cada Proceso

de Negocio.

En un Proceso de Negocio descrito a muy alto nivel es posible usar una sola Piscina y usar Carriles

dentro de ésta para representar, por ejemplo, Área de Ventas, Sistema de Contabilidad, Contraloría, etc.

Una descripción más detallada de la Colaboración puede requerir el uso de Piscinas separadas para

cada Área, Rol relevante o Sistema de Información. BPMN en cuanto estándar no se pronuncia por una

u otra estrategia sino que lo deja a criterio del modelador.

Como se indicó en Principios y Políticas, la Metodología de Alineamiento establece que en los

Procesos de Negocio se identificarán explícitamente los puntos en que se requiere soporte TIC, y

también saber si ésta es provista por Sistemas de Información de la Empresa o por Participantes

externos. Esto es relevante porque puede o no conducir a Requerimientos de Software que son

responsabilidad de la Empresa.

Lo anterior conduce a que los Sistemas de Información deben ser modelados en sus propias Piscinas, y,

además, se debe distinguir entre Participantes Sistémicos Internos y Externos. Cuando se haga

referencia a un Sistema de Información se usará el término Participante Sistémico, en caso contrario se

usará el término Participante Normal. Para distinguir a los Participantes Externos o Internos,

Sistémicos o Normales, se usarán colores.

5.2.1 Ambiente Interno

Un Participante Normal Interno se muestra mediante una Piscina de color blanco22

. Típicamente

representa la Empresa en su totalidad o un área o rol relevante, por ejemplo: Marketing, Ejecutivo de

Cuentas, Contraloría Interna, entre otros. La Piscina se puede mostrar sin detalles internos (“caja

negra”) o con la descripción del Procesos y Carriles.

22 Código RGB 255, 255, 255.

Page 50: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

46

Figura 5-2. Participante Interno "caja negra"

Puesto los Participantes Normales son el centro del modelo, normalmente estarán detallados, aunque

para efectos de simplicidad de los diagramas, en algunos casos aparecerán como “cajas negras”.

Figura 5-3. Participante Normal Interno detallado

Un Participante Sistémico Interno se representa mediante una Piscina de color gris claro23

. Típicamente

representa a la totalidad de los Sistemas de Información de la Empresa o a uno en particular, por

ejemplo: Sistema de Remuneraciones, CRM, entre otros. La Piscina se puede mostrar sin detalles

internos (“caja negra”) o con la descripción del Proceso y Carriles. Normalmente serán “cajas negras” a

no ser que se quiera representar aspectos del Proceso que son orquestados por algún sistema de

workflow especializado o ad-hoc24

.

23 Código RGB 220, 220, 220.

24 Puede ser un sistema especializado para BPM (Business Process Management) como Intalio, Bonita, Oracle BPM Suite; o

software ad-hoc que permite controlar el flujo de documentos y actividades de los usuarios.

Page 51: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

47

Figura 5-4. Participante Sistémico Interno “caja negra”

5.2.2 Ambiente Externo

Un Participante Normal Externo se muestra mediante una Piscina de color celeste claro25

. Típicamente

representa una organización o rol con el que interactúa la Empresa, por ejemplo: Cliente, Proveedor,

Ministerio de Salud, entre otros. La Piscina se puede mostrar sin detalles internos (“caja negra”) o con

la descripción del Procesos y Carriles.

Puesto que los Participantes normales Externos no son parte de la Empresa sino que representan el

entorno con el que ésta interactúa, normalmente no estarán detallados. En algunos casos el modelador

podrá mostrar algunos detalles del Participante Normal Externo que sean relevantes para la

comprensión de los Procesos de Negocio de la Empresa.

Figura 5-5. Participante Normal Externo "caja negra"

Un Participante Sistémico Externo se representa mediante una Piscina de color celeste oscuro26

.

Típicamente representa a la totalidad de los Sistemas de Información de una organización externa o a

uno en particular, por ejemplo: Sistema de Servicio de Impuestos, Sistemas de Proveedores y Clientes,

entre otros. La Piscina se puede mostrar sin detalles internos (“caja negra”) o con detalles.

Normalmente serán “cajas negras” a no ser que se quiera representar aspectos del Proceso que son

relevantes para la compresión de los Procesos de Negocio.

25 Código RGB 220, 255, 255.

26 Código RGB 100, 255, 255.

Page 52: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

48

Figura 5-6. Participante Sistémico Externo "caja negra"

En el caso de los Participantes Sistémicos Internos es obligatoria una Piscina exclusiva, para los

Participantes Sistémicos Externos esto es opcional, pudiendo estar como un Carril Sistémico dentro de

un Participante Normal Externo (ver Figura 5-7).

Figura 5-7. Participante Normal Externo con Carril Sistémico

5.2.3 Tareas en Piscinas y Carriles

Los elementos centrales en la descripción de los Procesos de Negocio con BPMN son las actividades.

Las cuales pueden ser Subprocesos o Tareas. Los primeros se usan para indicar que la actividad será

detallada aún más a nivel del Negocio. Las Tareas, por su parte, indican que la actividad es terminal a

nivel del Negocio, es decir, se les podrá detallar textualmente, pero no con otro diagrama BPMN.

Por lo tanto, una Tarea pueden interpretarse como el límite del Proceso de Negocio, en cuanto a que el

detalle de ésta no entra dentro de su ámbito. En este sentido, en la Metodología de Alineamiento las

Tareas son usadas para identificar los puntos donde un Proceso de Negocio requiere TIC, y el detalle de

la Tarea será parte del Modelo de los Sistemas de Información.

La definición de Ámbitos, es decir, la diferenciación de Participantes Internos y Externos, y su carácter

Sistémico o Normal, lleva a que sea necesario definir qué tipo de Tareas pueden o no ir en qué tipo de

Piscinas y Carriles. (Para una descripción de los tipos de Tareas ver 3.2.1.1).

Page 53: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

49

La especificación de BPMN establece que como todo objeto de flujo, en una Colaboración, las Tareas

deben localizarse dentro de Piscinas. Sin embargo, la Metodología de Alineamiento establece ciertas

restricciones respecto a qué tipo de Tareas deben ir en qué tipo de Piscinas.

5.2.3.1 Tareas relacionadas con TIC

Hay tres tipos de Tareas que hacen referencia a actividades realizadas por software: Servicio, Regla de

Negocio y Script.

Figura 5-8. Tareas Tecnológicas en Piscinas Sistémicas

Estas Tareas sólo pueden aparecer en Piscinas Sistémicas Internas o Externas. También pueden

aparecer en Carriles Sistémicos.

Todo Flujo de Mensaje entrante o saliente de estas Tareas debe llegar de o dirigirse a

otra Piscina Sistémica, o

un Carril Sistémico en otra Piscina de un Participante Normal Externo, o

un Carril de Rol en otra Piscina normal.

Estas restricciones permitirán diferenciar claramente en el Proceso de Negocio las Tareas

automatizadas y asociarlas a los Participantes Sistémicos.

Page 54: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

50

5.2.3.2 Tareas con participación humana

Las Tareas Manuales son realizadas por personas sin ningún tipo de apoyo tecnológico informático.

Las Tareas Usuario representa la interacción de una persona con un Sistema de Información, por

ejemplo un usuario de un banco que accede al sitio web de éste para consultar y hacer transacciones.

Figura 5-9. Tareas humanas en Piscinas normales

Estas Tareas sólo pueden aparecer en Piscinas normales Internas o Externas. Además, las Tareas

Usuario sólo pueden aparecer en Carriles asociados a Roles.

Todo Flujo de Mensaje entrante o saliente de una Tarea Usuario debe llegar de o dirigirse a:

una Piscina Sistémica, o

un Carril Sistémico en otra Piscina de un Participante Normal Externo.

Estas restricciones permitirán identificar claramente en el Proceso de Negocio dónde las personas,

jugando determinados roles, interactúan con los Sistemas de Información.

Page 55: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

51

5.2.3.3 Otras Tareas

Los demás tipos de Tarea: Abstracta, Envío de Mensaje y Recepción de Mensaje pueden o no

representar uso de TIC.

Figura 5-10. Tareas en cualquier tipo de Piscina

Las Tareas Abstractas se pueden usar para cualquier propósito del modelador. Este tipo de Tarea no

participa en ninguno de los Patrones de la Metodología de Alineamiento, por lo tanto el modelador

puede usarla en cualquier parte donde no se requiera uso de TIC.

Las Tareas de Envío o Recepción de Mensajes no están asociadas necesariamente a comunicación

tecnológica. Por ejemplo, si un Ejecutivo de comunica cara a cara con un Cliente se representa con un

Flujo de Mensaje con las respectivas Tareas de Envío y Recepción. Por otro lado, si un Sistema de

Información envía automáticamente un archivo a otro Sistema de Información también se usará la

misma notación de interacción mensajes.

Por lo tanto, estos tres tipos de Tareas se pueden usar en cualquier tipo de Piscina y Carril. En el caso

del envío y recepción de mensajes, dependiendo de dónde estén localizadas las Tareas representarán o

no el uso de TIC.

Si una Tarea de Envío (o Recepción) de Mensaje está en una Piscina o Carril Sistémico, entonces la

Tarea de Recepción (o Envío) asociada debe estar en:

otra Piscina Sistémica, o

un Carril Sistémico en otra Piscina de un Participante Normal Externo, o

un Carril de Rol en una Piscina normal.

Estas restricciones permitirán identificar claramente en el Proceso de Negocio dónde las personas y

Sistemas de Información se envían mensajes unos a otros.

Page 56: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

52

5.3 Patrones

En la sección anterior se definieron los Ambientes, es decir, las reglas sobre cómo definir los

Participantes de las Colaboraciones: Piscinas y Carriles, cuando en el Proceso de Negocio hay uso de

TIC. También se definieron restricciones respecto a qué tipo de Tareas usar para identificar el uso de

TIC y en qué lugares (Piscinas y Carriles) usarlas.

Al aplicar las reglas y restricciones anteriores se pueden presentar 15 configuraciones de uso de TIC en

Colaboraciones de Procesos de Negocio. A estas situaciones las llamamos Patrones, pues son

soluciones reutilizables para situaciones comunes en el uso de TIC.

Los 15 Patrones están divididos en 3 categorías:

3 Patrones de Interacción: Roles Internos o Externos interactúan con Sistemas Internos o

Externos. Por ejemplo un Cliente de Banco sacando dinero de un Cajero Automático.

9 Patrones de Mensajes: Roles o Sistemas Internos o Externos reciben o envían Mensajes

desde o hacia Sistemas Internos o Externos. Por ejemplo un Cliente recibe un correo automático

de un Banco, o un Sistema de Información envía un archivo a otro Sistema de Información.

3 Patrones de Servicios: Sistemas Internos o Externos acceden a los Servicios de Sistemas

Internos o Externos. Por ejemplo un Sistema de Información accede a un Servicio Web provisto

por otro para obtener el pronóstico meteorológico para unas coordenadas geográficas.

Las colaboraciones entre Roles (Internos o Externos) no son parte de los Patrones pues no involucran el

uso de TIC. Queda a criterio del modelador hacer uso libre de las posibilidades que da BPMN, o usar

algún conjunto de Patrones orientados a ese tipo de interacciones.

Las Colaboraciones entre Participantes Externos (Normales y Sistémicos) no están consideradas en los

Patrones pues son situaciones que ocurren fuera del ámbito interno de la Empresa y de su entorno

directo.

Las Colaboraciones entre Sistemas de Información están incluidas en los Patrones (de Servicio y

algunos de los de Mensajes). Sin embargo, el modelador debe considerar sólo aquellas interacciones

relevantes para el Proceso de Negocio y no involucrarse en detalles tecnológicos del Modelo de los

Sistemas de Información.

La descripción de cada Patrón consta de tres partes:

1. Proceso de Negocio: describe la configuración que desbribe la aplicación de TIC usando las

reglas definidas por la Metodología de Alineamiento.

2. Requerimientos de Software: describe los Casos de Uso y Actores que se derivan de lo descrito

en el Proceso de Negocio.

3. Mapeo: muestra la trazabilidad entre los Casos de Uso y Actores, y las Tareas, Piscinas y

Carriles.

La aplicación de los Patrones genera una primera versión del Modelo de Casos de Uso. Luego éste

puede ser refinado: agregando nuevos Casos de Uso, adecuando sus nombres, uniendolos o

sepandolos, creando extensiones entre ellos, etc.. Todo esto para optimizar el modelo o para reflejar

Page 57: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

53

aspectos técnicos no considerados en los Procesos de Negocio. Es importante mantener la trazabilidad

entre el modelo refinado y el original, para no perder el Alineamiento con los Procesos de Negocio.

5.3.1 Patrones de Interacción

Los Patrones de Interacción son tres.

1. Interacción Rol Interno-Sistema Interno (Int RI<>SI).

Un Empleado de Banco usando una intranet.

2. Interacción Rol Interno-Sistema Externo (Int RI<>SE).

Un Empleado municipal usando sistema del Ministerio de Desarrollo Social.

3. Interacción Rol Externo-Sistema Interno (Int RE<>SI).

El Cliente de un banco usando una aplicación web para consultar y realizar

transacciones bancarias.

5.3.1.1 Interacción Rol Interno-Sistema Interno (Int RI < > SI)

Este Patrón representa la típica interacción entre una persona cumpliendo un rol en una Empresa y una

aplicación provista por la misma Empresa. La aplicación puede ser un sitio web, una aplicación

desktop, una aplicación móvil, etc.

5.3.1.1.1 Proceso de Negocio

En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea Usuario la

que tiene comunicación vía Flujo de Mensajes con un Sistema Interno representado por una Piscina

separada.

Figura 5-11. Sistema Interno “caja negra” – Int RI <> SI

Page 58: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

54

El Sistema Interno puede estar como una Piscina “caja negra”, o detallado indicando aspectos

sistémicos relevantes para la comprensión del Negocio y/o porque está implementado con un software

de orquestación de procesos (BPMS). La contraparte de la Tarea Usuario en el Sistema Interno puede

ser una Subproceso o una Tarea Abstracta, dependiendo de lo que se desee modelar.

Figura 5-12. Sistema Interno detallado – Int RI <> SI

La contraparte de la Tarea Usuario en el Sistema Interno puede ser una Subproceso o una Tarea

Abstracta, dependiendo de lo que se desee modelar.

5.3.1.1.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a un Caso de Uso utilizado por el Actor

representado por el Carril en el que está la Tarea Usuario.

Figura 5-13. Requerimientos - Int RI <> SI

Page 59: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

55

Por ejemplo, si el Proceso de Negocio describe que el Analista ingresa todos los días las horas

dedicadas a las actividades asignadas, y esto lo hace ingresando al Sistema de Imputaciones. Entonces,

habrá un Caso de Uso – Ingresar Imputación de Horas – que es utilizado por el Actor – Analista.

5.3.1.1.3 Mapeo

El Actor Rol 1 tiene una traza hacia el Carril Rol 1 donde está localizada la Tarea Usuario Interactuar

con Sistema Interno.

El Caso de Uso Interactuar con Sistema Interno tiene trazas hacia la Tarea Usuario Interactuar con

Sistema Interno y, si el Sistema Interno está detallado, hacia el Subproceso Soportar Interacción.

Figura 5-14. Mapeo Negocio-Requerimientos - Int RI <> SI

Page 60: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

56

5.3.1.2 Interacción Rol Interno-Sistema Externo (Int RI < > SE)

Este Patrón representa una interacción entre una persona cumpliendo un rol en una Empresa y una

aplicación provista por un Sistema de Información de otra Empresa. La aplicación puede ser un sitio

web, una aplicación desktop, una aplicación móvil, etc.

5.3.1.2.1 Proceso de Negocio

En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea Usuario la

que tiene comunicación vía Flujo de Mensaje con un Sistema Externo representado por una Piscina

separada.

Figura 5-15. Sistema Externo "caja negra" – Int RI <> SE

El Sistema Externo puede estar como una Piscina “caja negra” o detallada indicando aspectos

sistémicos relevantes para la comprensión del Negocio. La contraparte de la Tarea Usuario en el

Sistema Externo puede ser una Subproceso o una Tarea Abstracta, dependiendo de lo que se desee

modelar. El Sistema Externo también puede estar detallado en un Carril dentro de una Piscina que

representa a la Empresa Externa.

Page 61: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

57

Figura 5-16. Sistema Externo en Carril – Int RI <> SE

5.3.1.2.2 Requerimiento de Software

Puesto que la funcionalidad es provista por un Sistema Externo no hay Requerimientos de Software

que deban ser trabajados por el Área de Desarrollo de Software.

Puede ocurrir que la aplicación de la otra Empresa sea accedida a través de una funcionalidad provista

por un Sistema Interno. El modelador del Proceso de Negocio podría obviar este aspecto técnico y

mostrar una interacción directa entre el Rol y el Sistema Externo. Sin embargo, la Metodología de

Alineamiento indica que en este caso corresponde aplicar los Patrones Interacción Rol Interno-Sistema

Interno (Int RI < > SI) y

Page 62: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

58

Petición de Servicio desde Sistema Interno a Sistema Externo (Serv SI > SE).

5.3.1.2.3 Mapeo

Puesto que no hay Requerimientos no aplica el Mapeo.

Page 63: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

59

5.3.1.3 Interacción Rol Externo-Sistema Interno (Int RE < > SI)

Este Patrón representa una interacción entre una persona cumpliendo un rol en otra Empresa y una

aplicación provista por la Empresa modelada. La aplicación puede ser un sitio web, una aplicación

desktop, una aplicación móvil, etc.

5.3.1.3.1 Proceso de Negocio

En el Proceso de Negocio un Rol (un Carril en un Participante Normal Externo) realiza una Tarea

Usuario la que tiene comunicación vía Flujo de Mensaje con un Sistema Interno representado por una

Piscina separada.

Figura 5-17. Sistema Interno "caja negra" – Int RE <> SI

El Sistema Interno puede estar como una Piscina “caja negra”, o detallado indicando aspectos

sistémicos relevantes para la comprensión del Negocio y/o porque está implementado con un software

de orquestación de procesos (BPMS). La contraparte de la Tarea Usuario en el Sistema Interno puede

ser una Subproceso o una Tarea Abstracta, dependiendo de lo que se desee modelar.

Page 64: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

60

Figura 5-18. Sistema Interno detallado – Int RE <> SI

5.3.1.3.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a un Caso de Uso utilizado por el Actor

representado por la Piscina (o Carril) del Participante Externo en la que está la Tarea Usuario.

Figura 5-19. Requerimientos - Int RE <> SI

Por ejemplo, si en un Proceso de Negocio del Servicio de Impuestos Internos describe que un

Contribuyente puede consultar las Facturas que ha recibido. Entonces, habrá un Caso de Uso –

Consultar Facturas Recibidas – que es utilizado por el Actor – Contribuyente.

Page 65: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

61

5.3.1.3.3 Mapeo

El Actor Rol Externo tiene una traza hacia el Carril Rol Externo donde está localizada la Tarea

Usuario Interactuar con Sistema Interno.

El Caso de Uso Interactuar con Sistema Interno tiene trazas hacia la Tarea Usuario Interactuar con

Sistema Interno y, si el Sistema Interno está detallado, hacia el Subproceso Soportar Interacción.

Figura 5-20. Mapeo Negocio-Requerimientos – Int RE <> SI

Page 66: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

62

5.3.2 Patrones de Mensajes

Los Patrones de Interacción son nueve.

1. Mensaje a Rol Interno desde Sistema Interno (Msj RI < SI)

Asignación automática de Incidencia a Desarrollador.

2. Mensaje a Rol Interno desde Sistema Externo (Msj RI < SE)

Correo electrónico automático desde Dirección de Aduanas a Encargado de

Importaciones.

3. Mensaje a Rol Externo desde Sistema Interno (Msj RE < SI)

Aviso a Cliente de Banco que tiene crédito pre-aprobado.

4. Mensaje de Rol Interno hacia Sistema Interno (Msj RI > SI)

Analista de Riesgo da el visto bueno a Solicitud de Crédito.

5. Mensaje de Rol Interno hacia Sistema Externo (Msj RI > SE)

Administrativo OTEC27

cierra Curso SENCE28

.

6. Mensaje de Rol Externo hacia Sistema Interno (Msj RE > SI)

Contribuyente envía su Declaración de Impuestos al SII29

.

7. Mensaje de Sistema Interno hacia Sistema Interno (Msj SI>SI)

Sistema de Registro Horario envía datos de horas trabajadas a Sistema de

Remuneraciones.

8. Mensaje de Sistema Externo hacia Sistema Interno (Msj SE > SI)

Sistema de Registro Académico de una Universidad recibe datos de alumnos

seleccionados mediante Proceso de Selección Nacional gestionado por el Ministerio de

Educación.

9. Mensaje de Sistema Interno hacia Sistema Externo (Msj SI > SE)

Sistema de Registro Académico de una Universidad envía al Ministerio de Educación

datos de titulados.

El envío y recepción de Mensajes se representa en los Procesos de Negocio con Tareas de Envío y

Recepción de Mensajes. Alternativamente se pueden usar Eventos de Envío y Recepción de Mensajes.

27 OTEC: Organismo Técnico de Capacitación.

28 SENCE: Servicio Nacional de Capacitación y Empleo.

29 SII: Servicio de Impuestos Internos.

Page 67: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

63

5.3.2.1 Mensaje a Rol Interno desde Sistema Interno (Msj RI < SI)

Este Patrón representa una comunicación asíncrona que recibe una persona cumpliendo un rol en una

Empresa desde un Sistema de Información de la misma Empresa. La comunicación puede ser por

correo electrónico u otro tipo de mensajería, también puede ser un aviso que le aparece al usuario

cuando ingresa a una aplicación, etc.

5.3.2.1.1 Proceso de Negocio

En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea de Recepción

de Mensaje que recibe un Flujo de Mensaje desde un Sistema Interno representado por una Piscina

separada.

Figura 5-21. Sistema Interno "caja negra" – Msj RI < SI

El Sistema Interno puede estar como una Piscina “caja negra”, o detallado indicando aspectos

sistémicos relevantes para la comprensión del Negocio y/o porque está implementado con un software

de orquestación de procesos (BPMS).

Page 68: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

64

Figura 5-22. Sistema Interno detallado – Msj RI < SI

5.3.2.1.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a un Caso de Uso. Sin embargo no hay Actor, pues

el receptor del Mensaje en el Carril en el que está la Tarea Recepción de Mensaje no está interactuando

con el Sistema de Información cuando éste le envía en Mensaje, con posterioridad podría ocurrir una

interacción.

El Caso de Uso refleja lo que hace el Sistema de Información, es decir, preparar y enviar el Mensaje,

por ejemplo: construir y enviar un correo electrónico, o grabar algún registro en la base de datos para

que cuando el usuario ingrese a una aplicación le aparezca un aviso.

Este Caso de Uso representa una funcionalidad que será utilizada (“incluida por”) otros Casos de Uso.

Figura 5-23. Requerimientos - Msj RI < SI

Por ejemplo, si el Proceso de Negocio describe que el Desarrollador al comienzo de su jornada verifica

las incidencias que le han sido asignadas para que las resuelva y esto lo hace ingresando a una

aplicación donde le aparece un aviso con las nuevas incidencias. Entonces, habrá un Caso de Uso –

Registrar y Comunicar Incidencias a Desarrollador.

Page 69: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

65

5.3.2.1.3 Mapeo

El Caso de Uso Enviar Mensaje tiene trazas hacia la Tarea de Recepción de Mensaje Recibir

Mensaje y, si el Sistema Interno está detallado, hacia la Tarea de Envío de Mensaje Preparar y

Enviar Mensaje.

Figura 5-24. Mapeo Negocio-Requerimientos – Msj RI < SI

Page 70: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

66

5.3.2.2 Mensaje a Rol Interno desde Sistema Externo (Msj RI < SE)

Este Patrón representa una comunicación asíncrona que recibe una persona cumpliendo un rol en una

Empresa desde un Sistema de Información de otra Empresa. La comunicación puede ser por correo

electrónico u otro tipo de mensajería, también puede ser un aviso que le aparece al usuario cuando

ingresa a una aplicación, etc.

5.3.2.2.1 Proceso de Negocio

En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea de Recepción

de Mensaje que recibe un Flujo de Mensaje desde un Sistema Externo representado por una Piscina

separada.

Figura 5-25. Sistema Externo "caja negra" - Msj RI < SE

El Sistema Externo puede estar como una Piscina “caja negra”, o detallado indicando aspectos

sistémicos relevantes para la comprensión del Negocio.

Page 71: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

67

Figura 5-26. Sistema Externo en Carril - Msj RI < SE

5.3.2.2.2 Requerimiento de Software

Puesto que la funcionalidad es provista por un Sistema Externo no hay Requerimientos de Software

que deban ser trabajados por el Área de Desarrollo de Software.

5.3.2.2.3 Mapeo

Puesto que no hay Requerimientos no aplica el Mapeo.

Page 72: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

68

5.3.2.3 Mensaje a Rol Externo desde Sistema Interno (Msj RE < SI)

Este Patrón representa una comunicación asíncrona que recibe una persona cumpliendo un rol en otra

Empresa desde un Sistema de Información de la Empresa modelada. La comunicación puede ser por

correo electrónico u otro tipo de mensajería, también puede ser un aviso que le aparece al usuario

cuando ingresa a una aplicación, etc.

5.3.2.3.1 Proceso de Negocio

En el Proceso de Negocio un Rol (un Carril en un Participante Externo) realiza una Tarea de Recepción

de Mensaje que recibe un Flujo de Mensaje desde un Sistema Interno representado por una Piscina

separada.

Figura 5-27. Sistema Interno "caja negra" - Msj RE < SI

El Sistema Interno puede estar como una Piscina “caja negra”, o detallado indicando aspectos

sistémicos relevantes para la comprensión del Negocio y/o porque está implementado con un software

de orquestación de procesos (BPMS).

Page 73: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

69

Figura 5-28. Sistema Interno detallado - Msj RE < SI

5.3.2.3.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a un Caso de Uso. Sin embargo no hay Actor, pues

el receptor del Mensaje en el Carril en el que está la Tarea Recepción de Mensaje no está interactuando

con el Sistema de Información cuando éste le envía en Mensaje, con posterioridad podría ocurrir una

interacción.

El Caso de Uso refleja lo que hace el Sistema de Información, es decir, preparar y enviar el Mensaje,

por ejemplo: construir y enviar un correo electrónico, o grabar algún registro en la base de datos para

que cuando el usuario ingrese a una aplicación le aparezca un aviso.

Este Caso de Uso representa una funcionalidad que será utilizada (“incluida por”) otros Casos de Uso.

Figura 5-29. Requerimientos - Msj RE < SI

Por ejemplo, si el Proceso de Negocio describe que el Cliente de un Banco recibe un aviso de crédito

pre-aprobado cuando ingresa al sitio web, y, además, recibe un correo electrónico automático.

Entonces, habrá un Caso de Uso – Comunicar Crédito Pre-Aprobado a Cliente.

Page 74: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

70

5.3.2.3.3 Mapeo

El Caso de Uso Enviar Mensaje tiene trazas hacia la Tarea de Recepción de Mensaje Recibir

Mensaje y, si el Sistema Interno está detallado, hacia la Tarea de Envío de Mensaje Preparar y

Enviar Mensaje.

Figura 5-30. Mapeo Negocio-Requerimientos - Msj RE < SI

Page 75: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

71

5.3.2.4 Mensaje de Rol Interno hacia Sistema Interno (Msj RI > SI)

Este Patrón representa una información, normalmente una decisión, que una persona cumpliendo un rol

en una Empresa comunica a un Sistema de Información de la misma Empresa y que provoca que el

flujo del Proceso de Negocio tome un determinado camino. La comunicación puede ser a través de la

selección de una opción, por ejemplo un botón, en una interfaz de usuario interactiva, o por un correo

electrónico que es recibido y procesado automáticamente, etc.

5.3.2.4.1 Proceso de Negocio

En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea de Envío de

Mensaje que lanza un Flujo de Mensaje hacia un Sistema Interno representado por una Piscina

separada.

Figura 5-31. Sistema Interno "caja negra" - Msj RI > SI

El Sistema Interno puede estar como una Piscina “caja negra”, o detallado indicando aspectos

sistémicos relevantes para la comprensión del Negocio y/o porque está implementado con un software

de orquestación de procesos (BPMS).

Page 76: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

72

Figura 5-32. Sistema Interno detallado - Msj RI > SI

5.3.2.4.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a un Caso de Uso utilizado por el Actor

representado por el Carril del Participante Normal en el que está la Tarea Envío de Mensaje.

Figura 5-33. Requerimientos - Msj RI > SI

Por ejemplo, si el Proceso de Negocio describe que el Analista de Riesgo luego de revisar los

antecedentes da el visto bueno a Solicitud de Crédito, y esto lo hace seleccionando una opción en una

aplicación. Entonces, habrá un Caso de Uso – Dar Visto Bueno a Solicitud de Crédito.

Page 77: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

73

5.3.2.4.3 Mapeo

El Actor Rol 1 tiene una traza hacia el Carril Rol 1 donde está localizada la Tarea de Envío de Mensaje

Preparar y Enviar Mensaje.

El Caso de Uso Preparar y Enviar Mensaje tiene trazas hacia la Tarea de Envío de Mensaje

Preparar y Enviar Mensaje y, si el Sistema Interno está detallado, hacia la Tarea de Recepción de

Mensaje Recibir Mensaje.

Figura 5-34. Mapeo Negocio-Requerimientos - Msj RI > SI

Page 78: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

74

5.3.2.5 Mensaje de Rol Interno hacia Sistema Externo (Msj RI > SE)

Este Patrón representa una información, normalmente una decisión, que una persona cumpliendo un rol

en una Empresa comunica a un Sistema de Información de otra Empresa y que provoca que el flujo del

Proceso de Negocio tome un determinado camino. La comunicación puede ser a través de la selección

de una opción, por ejemplo un botón, en una interfaz de usuario interactiva, o por un correo electrónico

que es recibido y procesado automáticamente, etc.

5.3.2.5.1 Proceso de Negocio

En el Proceso de Negocio un Rol (un Carril en un Participante Normal) realiza una Tarea de Envío de

Mensaje que lanza un Flujo de Mensaje hacia un Sistema Externo representado por una Piscina

separada.

Figura 5-35. Sistema Externo "caja negra" - Msj RI > SE

El Sistema Externo puede estar como una Piscina “caja negra”, o detallado indicando aspectos

sistémicos relevantes para la comprensión del Negocio.

Page 79: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

75

Figura 5-36. Sistema Externo en Carril - Msj RI > SE

5.3.2.5.2 Requerimiento de Software

Puesto que la funcionalidad es provista por un Sistema Externo no hay Requerimientos de Software

que deban ser trabajados por el Área de Desarrollo de Software.

5.3.2.5.3 Mapeo

Puesto que no hay Requerimientos no aplica el Mapeo.

Page 80: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

76

5.3.2.6 Mensaje de Rol Externo hacia Sistema Interno (Msj RE > SI)

Este Patrón representa una información, normalmente una decisión, que una persona cumpliendo un rol

en otra Empresa comunica a un Sistema de Información de la Empresa modelada y que provoca que el

flujo del Proceso de Negocio tome un determinado camino. La comunicación puede ser a través de la

selección de una opción, por ejemplo un botón, en una interfaz de usuario interactiva, o por un correo

electrónico que es recibido y procesado automáticamente, etc.

5.3.2.6.1 Proceso de Negocio

En el Proceso de Negocio un Rol (un Carril en un Participante Externo) realiza una Tarea de Envío de

Mensaje que lanza un Flujo de Mensaje hacia un Sistema Interno representado por una Piscina

separada.

Figura 5-37. Sistema Interno "caja negra" - Msj RE > SI

El Sistema Interno puede estar como una Piscina “caja negra”, o detallado indicando aspectos

sistémicos relevantes para la comprensión del Negocio y/o porque está implementado con un software

de orquestación de procesos (BPMS).

Page 81: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

77

Figura 5-38. Sistema Interno detallado - Msj RE > SI

5.3.2.6.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a un Caso de Uso utilizado por el Actor

representado por el Carril del Participante Externo en el que está la Tarea Envío de Mensaje.

Figura 5-39. Requerimientos - Msj RE > SI

Por ejemplo, si el Proceso de Negocio del SII describe que el Contribuyente luego de preparar su

declaración de impuestos la envía para su revisión, y esto lo hace seleccionando una opción en una

aplicación. Entonces, habrá un Caso de Uso – Enviar Declaración de Impuestos para Revisión.

Page 82: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

78

5.3.2.6.3 Mapeo

El Actor Rol Externo tiene una traza hacia el Carril Rol Externo donde está localizada la Tarea

Usuario Preparar y Enviar Mensaje.

El Caso de Uso Preparar y Enviar Mensaje tiene trazas hacia la Tarea de Envío de Mensaje

Preparar y Enviar Mensaje y, si el Sistema Interno está detallado, hacia la Tarea de Recepción de

Mensaje Recibir Mensaje.

Figura 5-40. Mapeo Negocio-Requerimientos - Msj RE > SI

Page 83: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

79

5.3.2.7 Mensaje de Sistema Interno hacia Sistema Interno (Msj SI>SI)

Este Patrón representa una comunicación asíncrona que envía un Sistema de Información de una

Empresa a otro Sistema de Información de la misma Empresa. La comunicación puede ser mediante el

envío de archivos vía ftp, usando casillas electrónicas, accediendo a una base de datos, etc.

5.3.2.7.1 Proceso de Negocio

En el Proceso de Negocio un Sistema Interno lanza un Flujo de Mensaje hacia otro Sistema Interno,

ambos representado por Piscinas separadas.

Figura 5-41. Sistemas Internos "cajas negras" - Msj SI > SI

Los Sistemas Internos puede estar como Piscinas “caja negra”, o detallados indicando aspectos

sistémicos relevantes para la comprensión del Negocio y/o porque están implementados con un

software de orquestación de procesos (BPMS). En caso de estar detallados habrá en uno la Tarea de

Envío de Mensaje y en el otro la Tarea de Recepción de Mensaje.

Page 84: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

80

Figura 5-42. Sistemas Internos detallados - Msj SI > SI

5.3.2.7.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a dos Casos de Uso, uno por cada Sistema Interno

representados por las Piscinas en las que están la Tarea de Envío y Recepción de Mensaje.

Figura 5-43. Requerimientos Sistema 1- Msj SI > SI

Desde el punto de vista del Sistema 1 hay un Actor – el Sistema 2 que requiere recibir un Mensaje. Por

lo tanto habrá un Caso de Uso en el Sistema 1 – Recibir Mensaje que se encargará de satisfacer esa

necesidad del Sistema 2, es decir, enviarle un Mensaje.

Figura 5-44. Requerimientos Sistema 2 - Msj SI > SI

Page 85: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

81

Desde el punto de vista del Sistema 2 hay un Actor – el Sistema 1 que requiere enviar un Mensaje. Por

lo tanto habrá un Caso de Uso en el Sistema 2 – Preparar y Enviar Mensaje que se encargará de

satisfacer esa necesidad del Sistema 1, es decir, recibir un Mensaje.

Por ejemplo, si el Proceso de Negocio describe que el Sistema de Registro Horario envía datos de horas

trabajadas a Sistema de Remuneraciones. Entonces, en el Sistema de Registro Horario habrá un Caso

de Uso – Recibir Horas Trabajadas asociado al Actor – Sistema de Remuneraciones. En el Sistema de

Remuneraciones habrá un Caso de Uso – Enviar Horas Trabajadas asociado al Actor – Sistema de

Registro Horario.

5.3.2.7.3 Mapeo

El Actor Sistema 1 tiene una traza hacia la Piscina Sistema 1 donde está localizada la Tarea de Envío

de Mensaje Preparar y Enviar Mensaje. El Actor Sistema 2 tiene una traza hacia la Piscina Sistema

2 donde está localizada la Tarea de Recepción de Mensaje Recibir Mensaje.

Los Casos de Uso Preparar y Enviar Mensaje y Recibir Mensaje tienen trazas hacia las Tareas

Preparar y Enviar Mensaje y Recibir Mensaje, si los Sistemas Internos están detallados.

Figura 5-45. Mapeo Negocio-Requerimientos - Msj SI > SI

Page 86: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

82

5.3.2.8 Mensaje de Sistema Externo hacia Sistema Interno (Msj SE > SI)

Este Patrón representa una comunicación asíncrona que envía un Sistema de Información de otra

Empresa a un Sistema de Información de la Empresa modelada. La comunicación puede ser mediante

el envío de archivos vía ftp, mediante el uso de casillas electrónicas, accediendo a una base de datos,

etc.

5.3.2.8.1 Proceso de Negocio

En el Proceso de Negocio un Sistema Externo lanza un Flujo de Mensaje hacia un Sistema Interno,

ambos representado por Piscinas separadas.

Figura 5-46. Sistema Externo e Interno "cajas negras" - Msj SE > SI

Los Sistemas Interno y Externo puede estar como Piscinas “caja negra”, o detallados indicando

aspectos sistémicos relevantes para la comprensión del Negocio. En el caso del Sistema Interno, el

detalle puede deberse a que está implementado con un software de orquestación de procesos (BPMS).

En caso de estar detallados habrá en cada uno las respectivas Tareas de Envío o Recepción de

Mensajes.

Page 87: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

83

Figura 5-47. Sistema Externo en Carril y Sistema Interno detallado - Msj SE > SI

5.3.2.8.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a un Caso de Uso asociado con el Sistema Externo

representado por la Piscina (o Carril) del Participante Externo en la que está la Tarea de Envío de

Mensaje.

Figura 5-48. Requerimientos - Msj SE > SI

El Caso de Uso se expresa en términos de una necesidad del Actor involucrado, pero su desarrollo

consiste en dar soporte a esa necesidad en términos del Sistema de Información que lo implementa. En

este caso el Sistema Externo prepara y envía el mensaje, y el Caso de Uso describe la interacción que

ocurre entre el Sistema Externo (el Actor) y el Sistema Interno (la Aplicación) para que éste último

reciba y procese correctamente el mensaje recibido.

Por ejemplo, si el Proceso de Negocio describe que el Sistema de Registro Académico de una

Universidad recibe datos de alumnos seleccionados mediante Proceso de Selección Nacional. Entonces,

habrá un Caso de Uso – Enviar Seleccionados asociado al Actor – Ministerio de Educación.

Page 88: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

84

5.3.2.8.3 Mapeo

El Actor Sistema Externo tiene una traza hacia la Piscina Sistema Externo donde está localizada la

Tarea de Envío de Mensaje Preparar y Enviar Mensaje.

El Caso de Uso Preparar y Enviar Mensaje tiene trazas hacia la Tarea Preparar y Enviar Mensaje

y, si el Sistema Interno está detallado, hacia la Tarea Recibir Mensaje.

Figura 5-49. Mapeo Negocio-Requerimientos - Msj SE > SI

Page 89: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

85

5.3.2.9 Mensaje de Sistema Interno hacia Sistema Externo (Msj SI > SE)

Este Patrón representa una comunicación asíncrona que envía un Sistema de Información de una

Empresa a un Sistema de Información de otra Empresa. La comunicación puede ser mediante el envío

de archivos vía ftp, mediante el uso de casillas electrónicas, accediendo a una base de datos, etc.

5.3.2.9.1 Proceso de Negocio

En el Proceso de Negocio un Sistema Interno lanza un Flujo de Mensaje hacia un Sistema Externo,

ambos representado por Piscinas separadas.

Figura 5-50. Sistemas Externo e Interno "cajas negras" - Msj SI > SE

Los Sistemas Interno y Externo puede estar como Piscinas “caja negra”, o detallados indicando

aspectos sistémicos relevantes para la comprensión del Negocio. En el caso del Sistema Interno, el

detalle puede deberse a que está implementado con un software de orquestación de procesos (BPMS).

En caso de estar detallados habrá en cada uno las respectivas Tareas de Envío o Recepción de

Mensajes.

Page 90: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

86

Figura 5-51. Sistema Externo en Carril y Sistema Interno detallado - Msj SI > SE

5.3.2.9.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a un Caso de Uso asociado con el Sistema Externo

representado por la Piscina (o Carril) del Participante Externo en la que está la Tarea de Recepción de

Mensaje.

Figura 5-52. Requerimientos - Msj SI > SE

Desde el punto de vista del Sistema Interno hay un Actor – el Sistema Externo que requiere recibir un

Mensaje. Por lo tanto habrá un Caso de Uso en el Sistema Interno – Recibir Mensaje que se encargará

de satisfacer esa necesidad del Sistema Externo, es decir, enviarle un Mensaje.

Por ejemplo, si el Proceso de Negocio describe que el Sistema de Registro Académico de una

Universidad envía al Ministerio de Educación datos de titulados. Entonces, habrá un Caso de Uso –

Recibir Datos de Titulados asociado al Actor – Ministerio de Educación.

Page 91: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

87

5.3.2.9.3 Mapeo

El Actor Sistema Externo tiene una traza hacia la Piscina Sistema Externo donde está localizada la

Tarea de Recepción de Mensaje Recibir Mensaje.

El Caso de Uso Recibir Mensaje tiene trazas hacia la Tarea Recibir Mensaje y, si el Sistema

Interno está detallado, hacia la Tarea Preparar y Enviar Mensaje.

Figura 5-53. Mapeo Negocio-Requerimientos - Msj SI > SE

Page 92: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

88

5.3.3 Patrones de Servicios

Los Patrones de Servicio son tres.

4. Petición de Servicio desde Sistema Interno a Sistema Interno (Serv SI > SI).

En un banco el Sistema de Créditos solicita a Sistema de Riesgos el nivel de riesgo de

un Cliente.

5. Petición de Servicio desde Sistema Interno a Sistema Externo (Serv SI > SE).

En una agencia de viajes el Sistema de Reservaciones solicita el pronóstico

meteorológico para una ciudad y fecha a una Empresa de Servicio de Información

Meteorológica.

6. Petición de Servicio desde Sistema Externo a Sistema Interno (Serv SE > SI).

Sistema de Banco Central responde a solicitudes de información de tipo de cambio de

distintas monedas respecto a la moneda nacional desde bancos comerciales.

5.3.3.1 Petición de Servicio desde Sistema Interno a Sistema Interno (Serv SI > SI)

Este Patrón representa una comunicación síncrona que establece una colaboración entre dos Sistemas

de Información de la Empresa en que uno solicita del otro un cierto servicio, que consiste en que quien

pide el servicio entrega ciertos parámetros y el que lo presta toma esos parámetros, realiza algún

cómputo y entrega un resultado al peticionario. La comunicación puede ser mediante un bus de

servicios, o por medio de servicios web, etc.

5.3.3.1.1 Proceso de Negocio

En el Proceso de Negocio un Sistema Interno solicita un servicio a otro Sistema Interno, ambos

representado por Piscinas separadas.

Figura 5-54. Sistemas Internos "cajas negras" - Serv SI > SI

Page 93: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

89

Los Sistemas Internos puede estar como Piscinas “caja negra”, o detallados indicando aspectos

sistémicos relevantes para la comprensión del Negocio y/o porque están implementados con un

software de orquestación de procesos (BPMS). En caso de estar detallados habrá en cada uno las

respectivas Tareas de Servicio.

La petición del servicio se indica con Tareas Servicio a ambos lados de la colaboración. El sentido de

la petición (del peticionario al prestador) se muestra con un Flujo de Mensaje desde el que pide el

servicio hacia el que lo presta.

Figura 5-55. Sistemas Internos detallados - Serv SI > SI

5.3.3.1.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a dos Casos de Uso, uno por cada Sistema Interno

representados por las Piscinas en las que están las Tareas Servicio.

Figura 5-56. Requerimientos Sistema 1 - Serv SI > SI

Page 94: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

90

Desde el punto de vista del Sistema 1 hay un Actor – el Sistema 2 que requiere presar un Servicio. Por

lo tanto habrá un Caso de Uso en el Sistema 1 – Prestar Servicio que se encargará de satisfacer esa

necesidad del Sistema 2, es decir, solicitarle un Servicio.

Figura 5-57. Requerimientos Sistema 2 - Serv SI > SI

Desde el punto de vista del Sistema 2 hay un Actor – el Sistema 1 que requiere solicitar un Servicio.

Por lo tanto habrá un Caso de Uso en el Sistema 2 – Solicitar Servicio que se encargará de satisfacer

esa necesidad del Sistema 1, es decir, prestarle un Servicio.

Por ejemplo, si el Proceso de Negocio describe que en un banco el Sistema de Créditos solicita a

Sistema de Riesgos el nivel de riesgo de un Cliente. Entonces, en el Sistema de Créditos habrá un Caso

de Uso – Entregar Grado de Riesgo asociado al Actor – Sistema de Riesgos. En el Sistema de Riesgos

habrá un Caso de Uso – Solicitar Grado de Riesgo asociado al Actor – Sistema de Crédito.

Page 95: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

91

5.3.3.1.3 Mapeo

El Actor Sistema 1 tiene una traza hacia la Piscina Sistema 1 donde está localizada la Tarea de

Servicio Solicitar Servicio donde se origina el Flujo de Mensaje. El Actor Sistema 2 tiene una traza

hacia la Piscina Sistema 2 donde está localizada la Tarea de Servicio Prestar Servicio donde se llega

el Flujo de Mensaje.

Los Casos de Uso Prestar Servicio y Solicitar Servicio tienen trazas hacia las Tareas Solicitar

Servicio y Prestar Servicio, si los Sistemas Internos están detallados.

Figura 5-58. Mapeo Negocio-Requerimientos - Serv Si > Si

Page 96: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

92

5.3.3.2 Petición de Servicio desde Sistema Interno a Sistema Externo (Serv SI > SE)

Este Patrón representa una comunicación síncrona que establece una colaboración entre un Sistema de

Información de la Empresa modelada y un Sistema de Información de otra Empresa, en que el primero

solicita al segundo un cierto servicio, que consiste en que quien pide el servicio entrega ciertos

parámetros y el que lo presta toma esos parámetros, realiza algún cómputo y entre un resultado al

peticionario. La comunicación puede ser por medio de servicios web, tecnologías CORBA, RMI30

,

etc.

5.3.3.2.1 Proceso de Negocio

En el Proceso de Negocio un Sistema Interno solicita un servicio a un Sistema Externo, ambos

representado por Piscinas separadas.

Figura 5-59. Sistemas Externo e Interno "cajas negras" - Serv SI > SE

Los Sistemas Interno y Externo pueden estar como Piscinas “caja negra”, o detallados indicando

aspectos sistémicos relevantes para la comprensión del Negocio. En el caso del Sistema Interno, el

detalle puede deberse a que está implementado con un software de orquestación de procesos (BPMS).

La petición del servicio se indica con Tareas Servicio a ambos lados de la colaboración. El sentido de

la petición (del peticionario al prestador) se muestra con un Flujo de Mensaje desde el que pide el

servicio hacia el que lo presta.

30 CORBA: Common Object Request Broker Architecture. RMI: Java Remote Method Invocation.

Page 97: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

93

Figura 5-60. Sistema Externo en Carril y Sistema Interno detallado - Serv SI > SE

5.3.3.2.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a un Caso de Uso asociado con el Sistema Externo

representado por la Piscina (o Carril) del Participante Externo en la que está la Tarea de Servicio que

recibe el Flujo de Mensaje.

Figura 5-61. Requerimientos - Serv SI > SE

Desde el punto de vista del Sistema Interno hay un Actor – el Sistema Externo que requiere prestar un

Servicio. Por lo tanto habrá un Caso de Uso en el Sistema Interno – Prestar Servicio que se encargará

de satisfacer esa necesidad del Sistema Externo, es decir, pedirle un Servicio.

Por ejemplo, si el Proceso de Negocio describe que en una agencia de viajes el Sistema de

Reservaciones solicita el pronóstico meteorológico para una ciudad y fecha a una Empresa de Servicio

de Información Meteorológica. Entonces, habrá un Caso de Uso – Proveer Pronóstico Meteorológico

asociado al Actor – Empresa de Servicio de Información Meteorológica.

Page 98: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

94

5.3.3.2.3 Mapeo

El Actor Sistema Externo tiene una traza hacia la Piscina Sistema Externo donde está localizada la

Tarea de Servicio Prestar Servicio donde llega el Flujo de Mensaje.

El Caso de Uso Prestar Servicio tiene trazas hacia la Tarea Prestar Servicio y, si el Sistema Interno

está detallado, hacia la Tarea Solicitar Servicio.

Figura 5-62. Mapeo Negocio-Requerimientos - Serv SI > SE

Page 99: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

95

5.3.3.3 Petición de Servicio desde Sistema Externo a Sistema Interno (Serv SE > SI)

Este Patrón representa una comunicación síncrona que establece una colaboración entre un Sistema de

Información de la Empresa modelada y un Sistema de Información de otra Empresa, en que este último

solicita al primero un cierto servicio, que consiste en que quien pide el servicio entrega ciertos

parámetros y el que lo presta toma esos parámetros, realiza algún cómputo y entre un resultado al

peticionario. La comunicación puede ser por medio de servicios web, tecnologías CORBA, RMI, etc.

5.3.3.3.1 Proceso de Negocio

En el Proceso de Negocio un Sistema Externo solicita un servicio a un Sistema Interno, ambos

representado por Piscinas separadas.

Figura 5-63. Sistemas Externo e Interno "cajas negras" - Serv SE > SI

Los Sistemas Interno y Externo pueden estar como Piscinas “caja negra”, o detallados indicando

aspectos sistémicos relevantes para la comprensión del Negocio. En el caso del Sistema Interno, el

detalle puede deberse a que está implementado con un software de orquestación de procesos (BPMS).

La petición del servicio se indica con Tareas Servicio a ambos lados de la colaboración. El sentido de

la petición (del peticionario al prestador) se muestra con un Flujo de Mensaje desde el que pide el

servicio hacia el que lo presta.

Page 100: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

96

Figura 5-64. Sistema Externo en Carril y Sistema Interno detallado - Serv SE > SI

5.3.3.3.2 Requerimiento de Software

La configuración del Proceso de Negocio conduce a un Caso de Uso asociado con el Sistema Externo

representado por la Piscina (o Carril) del Participante Externo en la que está la Tarea Servicio que

envía el Flujo de Mensaje

Figura 5-65. Requerimientos - Serv SE > SI

Desde el punto de vista del Sistema Interno hay un Actor – el Sistema Externo que solicita un Servicio.

Por lo tanto habrá un Caso de Uso en el Sistema Interno – Solicitar Servicio que se encargará de

satisfacer esa necesidad del Sistema Externo, es decir, prestarle un Servicio.

Por ejemplo, si el Proceso de Negocio describe que el Sistema de Banco Central responde a solicitudes

de información de tipo de cambio de distintas monedas respecto a la moneda nacional. Entonces, habrá

un Caso de Uso – Solicitar Tipo de Cambio asociado al Actor – Banco Comercial.

Page 101: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

97

5.3.3.3.3 Mapeo

El Actor Sistema Externo tiene una traza hacia la Piscina Sistema Externo donde está localizada la

Tarea Solicitar Servicio de Servicio donde se origina el Flujo de Mensaje.

El Caso de Uso Solicitar Servicio tiene trazas hacia la Tarea Solicitar Servicio y, si el Sistema

Interno está detallado, hacia la Tarea Prestar Servicio.

Figura 5-66. Mapeo Negocio-Requerimientos - SE > SI

Page 102: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

98

6 Ejemplo

En esta sección mostraremos un ejemplo de utilización de la Metodología de Alineamiento, es decir,

aplicar los Ambientes y luego los Patrones de Alineamiento para derivar el Modelo de Casos de Uso.

El ejemplo a desarrollar es el mismo mostrado al explicar BPMN (ver 3.1), que muestra el

funcionamiento del Proceso de Soporte de una Empresa de Software:

El Cliente realiza una consulta a un Administrador de Cuenta, quien le entrega la

respuesta. Si el Administrador de Cuenta puede resolver la consulta la responde de

inmediato, si no deriva el problema a la Mesa de Ayuda Nivel 1. Esta resuelve el

problema y entrega la respuesta al Administrador de Cuenta para que la comunique

al Cliente. La Mesa de Ayuda Nivel 1 puede derivar el problema al Nivel 2 quien

debe obligatoriamente entregar una respuesta al Administrador de Cuenta, si es

necesario consulta al Desarrollador.

6.1 Niveles

Primero veremos tres enfoques de modelado del Proceso de Negocio, todos ellos correctos, pero los

dos primeros no cumplen con las reglas establecidas por la Metodología de Alineamiento. El tercer

enfoque sí sigue las reglas y será usado para continuar con el desarrollo del ejemplo.

6.1.1 Alto Nivel sin Tecnología

El primer enfoque modela el Proceso de Negocio sin hacer una indicación explícita de uso de TIC. Es

decir, no se usan Tareas especializadas para las TIC (Servicio, Mensaje, Reglas de Negocio, Script) ni

se usan Piscinas y Carriles especiales para los Sistemas de Información.

Todo lo que ocurre dentro de la Empresa es colocado dentro de una Piscina y se usan Carriles para

identificar quién hace qué. Se muestran unidades organizacionales y no roles: Mesa de Ayuda Nivel 1

en lugar de Agente de Mesa de Ayuda Nivel 1.

Este enfoque es útil para mostrar el Proceso de Negocio a un alto nivel, pero no para los propósitos de

lograr un Alineamiento Procesos de Negocio-Sistemas de Información de manera controlable, es decir:

ordenada, sistemática y repetible.

Page 103: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

99

Figura 6-1. Modelo de Alto Nivel sin Tecnología

6.1.2 Colaboración detallada sin Tecnología

El segundo enfoque separa la Colaboración en varios Participantes:

1 Participante Externo

o Cliente

3 Participantes Internes

o Administrador de Cuenta

o Soporte

o Desarrollador

Page 104: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

100

Figura 6-2. Colaboración con varios Participantes "cajas negras"

No hay Piscinas separadas para Participantes Sistémicos, por lo tanto no hay una separación explícita

para las TIC.

En cada una de las Piscinas se detalla el respectivo Proceso de Negocio. Sin embargo, al igual que en

caso anterior, no se usan Tareas especializadas para las TIC (Servicio, Usuario, Reglas de Negocio,

Script).

Este enfoque es más detallado que el anterior y es más flexible al usar más Piscinas. Sin embargo, no

cumple con la configuración de Ambientes requerida por la Metodología de Alineamiento.

Page 105: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

101

Figura 6-3. Colaboración detallada con Tareas Manuales, sin TIC

Page 106: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

102

6.1.3 Colaboración detallada con Tecnología en Piscinas separadas

El tercer enfoque sigue las reglas de Ambientes definidas por la Metodología de Alineamiento. Es

decir, hay una separación de los Participantes Sistémicos.

Figura 6-4. Colaboración con Participante Sistémico

El Sistema de Seguimiento de Incidencias se encarga de tomar las consultas del Administrador de

Cuentas y entregarle la respuesta. El Administrador de Cuentas no interactúa directamente con Soporte.

Por el contrario, Soporte interactúa con Desarrollo directamente (comunicación personal, telefónica,

correo electrónico, etc.).

En cada Piscina Interna se utilizan Tareas especializas en TIC. Además, los Carriles de la Piscina

Soporte representan roles: Agente de Mesa de Ayuda Nivel 1 y Agente de Mesa de Ayuda Nivel 2.

Esta versión de los Procesos de Negocio ya está en condiciones de ser usada para aplicar los Patrones

de Alineamiento. Sin embargo, todavía hay algunos refinamientos que se describen a continuación.

Page 107: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

103

Figura 6-5. Colaboración con Participantes Sistémicos Interno y Externo

Un análisis más detallado muestra que la relación entre Administrador de Cuenta y el Sistema de

Seguimiento de Incidencias no es directo sino a través de un Sistema de Mensajería.

El Sistema de Mensajería no es desarrollado ni gestionado por la Empresa de Software, es parte de otra

Empresa la que cobra un monto por cada comunicación. Por lo tanto habrá dos Participantes

Sistémicos: uno Interno (Sistema de Seguimiento de Incidencias) y otro Externo (Sistema de

Mensajería).

Page 108: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

104

Figura 6-6. Colaboración detallada con uso explícito de TIC

El Proceso de Negocio en la Piscina de Sistema de Seguimiento de Incidencias muestra el detalle de la

orquestación de Procesos de Negocio.

Ahora sí estamos en condiciones de aplicar los Patrones de Alineamiento y luego derivar los Casos de

Uso.

Page 109: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

105

6.2 Aplicación de Patrones

El análisis de la Colaboración del Proceso de Soporte de una Empresa de Software conduce a la

aplicación de 6 Patrones de Alineamiento:

1. Mensaje de Rol Interno hacia Sistema Externo (Msj RI > SE)

2. Mensaje de Sistema Externo hacia Sistema Interno (Msj SE>SI)

3. Mensaje a Rol Interno desde Sistema Interno (Msj RI<SI)

4. Interacción Rol Interno-Sistema Interno (Int RI < > SI)

5. Mensaje de Sistema Interno hacia Sistema Externo (Msj SI>SE)

6. Mensaje a Rol Interno desde Sistema Externo (Msj RI < SE)

6.2.1 Mensaje de Rol Interno hacia Sistema Externo (Msj RI > SE)

El Administrador de Cuenta envía un Mensaje al Sistema de Mensajería. Es decir un Rol Interno envía

un Mensaje a un Sistema Externo.

Figura 6-7. Mensaje de Rol Interno hacia Sistema Externo

El Patrón a aplicar es entonces Msj RI > SE. En la descripción de Patrón se indica que el Rol realiza

una Tarea de Envío de Mensaje con un Flujo de Mensaje hacia la Piscina del Sistema Externo.

Page 110: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

106

Figura 6-8. Proceso de Negocio de Patrón Msj RI > SE

Puesto que la funcionalidad es provista por un Sistema Externo, no habrá Requerimientos de Software.

Es decir, este es un uso de TIC relevante para el entendimiento del Negocio, pero que no implica

requerimientos que deba trabajar el área de Desarrollo de Software de la Empresa.

Page 111: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

107

6.2.2 Mensaje de Sistema Externo hacia Sistema Interno (Msj SE>SI)

El Sistema de Mensajería envía un Mensaje al Sistema de Seguimiento de Incidencias. Es decir, un

Sistema Externo envía un Mensaje a un Sistema Interno.

Figura 6-9. Mensaje de Sistema Externo a Sistema Interno

El Patrón a aplicar es entonces Msj SE > SI. En la descripción de Patrón se indica que el Sistema

Externo utiliza una Tarea de Envío de Mensaje y el Sistema Interno una Tarea de Recepción de

Mensaje. Sin embargo, en lugar de Tareas es posible usar Eventos de Envío y Recepción de Mensajes

como en nuestro ejemplo.

Page 112: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

108

Figura 6-10. Proceso de Negocio de Patrón Msj SE > SI

El Patrón indica que hay un Caso de Uso asociado al Sistema Externo, y que su nombre refleja lo que

hace el Sistema Externo con respecto al Sistema Interno.

Figura 6-11. Caso de Uso de Patrón Msj SE > SI

Por lo tanto tenemos un Caso de Uso llamado Enviar Incidencia asociado al Actor Sistema de

Mensajería.

Figura 6-12. Caso de Uso drivado de

Mensaje de Sistema Externo a Sistema Interno

Enviar Incidencia

Sistema de Mensajería

Page 113: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

109

6.2.3 Mensaje a Rol Interno desde Sistema Interno (Msj RI<SI)

El Sistema de Seguimiento de Incidencias envía un Mensaje al Agente de Mesa de Ayuda Nivel 1, y

otro Mensaje al Agente de Mesa de Ayuda Nivel 2. Es decir, un Sistema Interno envía Mensajes a un

Rol Interno.

Figura 6-13. Mensajes a Roles Internos desde Sistema Interno

El Patrón a aplicar es entonces Msj RI < SI. En la descripción de Patrón se indica que el Sistema

Interno utiliza una Tarea de Envío de Mensaje y el Rol Interno una Tarea de Recepción de Mensaje.

Sin embargo, en lugar de Tareas es posible usar Eventos de Envío y Recepción de Mensajes como en

nuestro ejemplo.

Page 114: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

110

Figura 6-14. Proceso de Negocio de Patrón Msj RI < SI

El Patrón indica que hay un Caso de Uso sin Actor asociado, y que su nombre refleja lo que hace el

Sistema Interno con respecto al Rol Interno.

Figura 6-15. Caso de Uso de Patrón Msj RI < SI

Por lo tanto tenemos un Caso de Uso llamado Enviar Ticket a Agente.

Figura 6-16. Caso de Uso drivado de

Mensajes a Roles Internos desde Sistema Interno

Enviar Ticket a Agente

Page 115: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

111

6.2.4 Interacción Rol Interno-Sistema Interno (Int RI < > SI)

El Agente de Mesa de Ayuda Nivel 1 interactúa con el Sistema de Seguimiento de Incidencias al editar

el ticket y luego al documentar el resultado. Lo mismo hace el Agente de Mesa de Ayuda Nivel 2. Es

decir, un Rol Interno interactúa con un Sistema Interno.

Figura 6-17. Interacciones entre Rol Interno y Sistema Interno (i)

Page 116: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

112

Figura 6-18. Interacciones entre Rol Interno y Sistema Interno (ii)

El Patrón a aplicar es entonces Int RI <> SI. En la descripción de Patrón se indica que el Rol Interno

utiliza una Tarea Usuario y que el Sistema Interno utiliza un Subproceso o una Tarea Abstracta.

Page 117: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

113

Figura 6-19. Proceso de Negocio de Patrón Int RI <> SI

El Patrón indica que hay un Caso de Uso asociado al Rol Interno, y que su nombre refleja lo que hace

el Rol Externo con respecto al Sistema Interno.

Figura 6-20. Caso de Uso de Patrón Int RI <> SI

Page 118: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

114

Por lo tanto tenemos cuatro Casos de Uso. Dos asociados al Actor Agente de Mesa de Ayuda Nivel 1:

Editar Ticket Nivel 1 y Documentar Resultado Nivel 1. Y dos asociados al Actor Agente de Mesa

de Ayuda Nivel 2: Editar Ticket Nivel 2 y Documentar Resultado Nivel 2.

Figura 6-21. Casos de Uso drivados de

Interacciones entre Rol Interno y Sistema Interno

Agente de Mesa de Ayuda

Nivel 1

Agente de Mesa de Ayuda

Nivel 2

Editar Ticket Nivel 1

Editar Ticket Nivel 2

Documentar Resultado

Nivel 1

Documentar Resultado

Nivel 2

Page 119: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

115

6.2.5 Mensaje de Sistema Interno hacia Sistema Externo (Msj SI>SE)

El Sistema de Seguimiento de Incidencias envía un Mensaje al Sistema de Mensajería. Es decir, un

Sistema Interno envía un Mensaje a un Sistema Externo.

Figura 6-22. Mensaje de Sistema Interno a Sistema Externo

El Patrón a aplicar es entonces Msj SI > SE. En la descripción de Patrón se indica que el Sistema

Interno utiliza una Tarea de Envío de Mensaje y el Sistema Externo una Tarea de Recepción de

Mensaje. Sin embargo, en lugar de Tareas es posible usar Eventos de Envío y Recepción de Mensajes

como en nuestro ejemplo.

Page 120: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

116

Figura 6-23. Proceso de Negocio de Patrón Msj SI > SE

El Patrón indica que hay un Caso de Uso asociado al Sistema Externo, y que su nombre refleja lo que

hace el Sistema Externo con respecto al Sistema Interno.

Figura 6-24. Caso de Uso de Patrón Msj SI > SE

Por lo tanto tenemos un Caso de Uso llamado Recibir Respuesta asociado al Actor Sistema de

Mensajería.

Figura 6-25. Caso de Uso drivado de

Mensaje de Sistema Interno a Sistema Externo

Sistema de Mensajería

Recibir Respuesta

Page 121: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

117

6.2.6 Mensaje a Rol Interno desde Sistema Externo (Msj RI < SE)

El Administrador de Cuenta recibe un Mensaje del Sistema de Mensajería. Es decir un Rol Interno

recibe un Mensaje desde un Sistema Externo.

Figura 6-26. Mensaje de Sistema Externo a Rol Interno

El Patrón a aplicar es entonces Msj RI < SE. En la descripción de Patrón se indica que el Rol realiza

una Tarea de Recepción de Mensaje con un Flujo de Mensaje desde la Piscina del Sistema Externo.

Page 122: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

118

Figura 6-27. Proceso de Negocio de Patrón Msj RI < SE

Puesto que la funcionalidad es provista por un Sistema Externo, no hay Requerimientos de Software.

Es decir, este es un uso de TIC relevante para el entendimiento del Negocio, pero que no implica

requerimientos que deba trabajar el área de Desarrollo de Software de la Empresa.

Page 123: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

119

6.3 Refinamiento del Modelo de Casos de Uso

Una vez derivado el Modelo de Casos de Uso por medio de los Patrones de Alineamiento es necesario

refinarlo considerando, entre otros, nuevos Casos de Uso, fusión de algunos de ellos, relaciones de

inclusión y extensión, etc.

6.3.1 Modelo de Casos de Uso inicial

Hasta ahora tenemos 3 Actores y 7 Casos de Uso, donde uno de ellos – Enviar Ticket a Agente – está

aislado.

Figura 6-28. Modelo de Casos de Uso inicial

Agente de Mesa de Ayuda

Nivel 1

Agente de Mesa de Ayuda

Nivel 2

Editar Ticket Nivel 1

Editar Ticket Nivel 2

Documentar Resultado

Nivel 1

Documentar Resultado

Nivel 2

Enviar Incidencia

Recibir Respuesta

Sistema de Mensajería

Enviar Ticket a Agente

Page 124: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

120

6.3.2 Inclusiones

El Caso de Uso Enviar Ticket a Agente ocurre inmediatamente después que el Sistema de

Seguimiento de Incidencias recibe el Mensaje del Sistema de Mensajería. Y también inmediatamente

después de que el Agente de Mesa de Ayuda Nivel 1 Documenta el Resultado Nivel 1.

Figura 6-29. Activación de Caso de Uso Enviar Ticket a Agente

Por lo tanto el Caso de Uso Enviar Ticket a Agente se puede ejecutar hacia el término de los Casos de

Uso Enviar Incidencia y Documentar Resultado Nivel 1. Esto se representa en el modelo con un

relación de inclusión hacia Enviar Ticket a Agente. El significado de la relación de inclusión es que

en algún momento los Casos de Uso utilizarán la funcionalidad de Enviar Ticket a Agente, y, además,

que para que los Casos de Uso Enviar Incidencia y Documentar Resultado Nivel 1 puedan pasar a

producción es obligatorio que Enviar Ticket a Agente esté operativo.

Page 125: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

121

Figura 6-30. Modelo de Casos de Uso

con relación de inclusión hacia Enviar Ticket a Agente

Agente de Mesa de Ayuda

Nivel 1

Agente de Mesa de Ayuda

Nivel 2

Editar Ticket Nivel 1

Editar Ticket Nivel 2

Documentar Resultado

Nivel 1

Documentar Resultado

Nivel 2

Enviar Incidencia

Recibir Respuesta

Sistema de Mensajería

Enviar Ticket a Agente

«include»

«include»

Page 126: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

122

6.3.3 Nuevos Casos de Uso

Al analizar el Proceso de Negocio que ocurre dentro de la Piscina del Sistema de Seguimiento de

Incidencias vemos que hay tres Actividades que no están aún consideradas dentro de los Casos de Uso:

Abrir Ticket, Insertar en la Lista de Tareas del Producto y Cerrar Ticket.

Figura 6-31. Actividades aún no consideradas en el Modelo de Casos de Uso

Estas Actividades pueden considerarse Casos de Uso pues representan acciones atómicas

potencialmente reutilizables. Ninguno tiene un Actor que lo requiera, por lo tanto serán utilizados por

otros Casos de Uso a través de la relación de inclusión.

Usando el criterio de temporalidad, es decir, que serán utilizados por el Caso de Uso que le antecede,

tenemos las siguientes inclusiones:

1. Abrir Ticket es incluido por Enviar Incidencia.

2. Insertar en la Lista de Tareas del Producto es incluido por Documentar Resultado Nivel 2.

3. Cerrar Ticket es incluido por Recibir Respuesta.

Page 127: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

123

Figura 6-32. Nuevos Casos de Uso

Agente de Mesa de Ayuda

Nivel 1

Agente de Mesa de Ayuda

Nivel 2

Editar Ticket Nivel 1

Editar Ticket Nivel 2

Documentar Resultado

Nivel 1

Documentar Resultado

Nivel 2

Enviar Incidencia

Recibir Respuesta

Sistema de Mensajería

Enviar Ticket a Agente

Insertar en la Lista de

Tareas del Producto

Abrir Ticket

Cerrar Ticket

«include»

«include»

«include»

«include»

«include»

Page 128: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

124

6.3.4 Generalización de Actores

Los Actores del Modelo de Casos de Uso representan a las personas y otros sistemas que interacturán

con el Sistema de Información. Las personas lo usan mientras cumplen algún Rol desde el punto de

vista del Negocio. Desde el punto de vista del Sistema de Información son los Usuarios y como tal

tendrán perfiles que les darán distintos niveles de acceso a las funcionalidades.

Un refinamiento común será el ordenamiento de los Actores en una jerarquía que facilitará la

definición de Perfiles de Usuario. A nivel de Modelo de Casos de Uso esto se logra aplicando

generalizaciones entre Actores. En nuestro ejemplo los Actores Agente de Mesa de Ayuda Nivel 1 y

Agente de Mesa de Ayuda Nivel 2 son especializaciones de Agente de Mesa de Ayuda. Ambos

heredarán el Perfil del “súper” Agente de Mesa de Ayuda y podrán especializar sus Perfiles agregando

o quitando privilegios.

Figura 6-33. Generalización de Actores

Page 129: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

125

6.3.5 Generalización de Casos de Uso

A partir de los nombres de los Casos de Uso hasta ahora identificados y de lo que conocemos de los

Procesos de Negocio es problable que los Casos de Uso Editar Ticket Nivel 1 y Editar Ticket Nivel 2

sean parecidos. Lo mismo ocurre con Documentar Resultado Nivel 1 y Documentar Resultado

Nivel 2.

Figura 6-34. Generalización de Casos de Uso

Esto puede ser modelado agregando un nuevo Caso de Uso que generaliza los Casos de Uso que

comparten parte sustancial de su contenido. El modelador puede, incluso, considerar que son sólo un

Caso de Uso (Editar Ticket y Documentar Resultado) y las variaciones, si las hubiera, se puede

manejar internamente.

Page 130: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

126

6.4 Mapeo

La derivación del Modelo de Casos de Uso es importante, pero no basta para el Alineamiento entre

Procesos de Negocio y Requerimientos – Casos de Uso. También es necesario definir y mantener el

mapeo entre ambos Modelos.

En otras palabras, el Alineamiento no sólo significa que los Casos de Uso se derivan de los Procesos de

Negocio, sino que también es necesario conocer y administrar las relaciones entre ellos para poder

tener control sobre el Alineamiento.

Figura 6-35. Mapeo de Actores a Piscinas y Carriles

Si las herramientas usadas para modelar lo permiten, es recomendable incorporar explícitamente las

trazas en los modelos. Por ejemplo con Enterprise Architect es posible definir y administrar las

relaciones entre los elementos de cualquier modelo. La Figura 6-37 muestra, en la parte izquierda, las

trazas entre el Caso de Uso Editar Ticket Nivel 1 y las Actividades Editar Ticket Nivel 1 y Soportar

Interacción Nivel 1. En la parte derecha, muestra la trazabilidad del Caso de Uso Editar Ticket Nivel

1, es decir, sus relaciones con cualquier otro elemento, en este caso con otros Casos de uso, con

Actores y con Actividades.

Page 131: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

127

Figura 6-36. Mapeo de Casos de Uso a Actividades y Eventos

Figura 6-37. Actividades y Casos de Uso relacionados (izq.)

y visualización de relaciones en Enterprise Architect (der.)

Page 132: Metodología para el Alineamiento de Procesos de Negocio y Sistemas de Información usando BPMN y UML

128

7 Bibliografía

Booch, G., Rumbaugh, J., & Jacobson, I. (2005). Unified Modeling Language User Guide, The.

Addison-Wesley Professional.

Craftware Consultores. (octubre de 2016). Arquitectura Empresarial. Obtenido de

http://craftware.net/introduccion-basica-arquitectura-empresarial/

Grossman, M., Aronson, J., & McCarthy, R. (2005). Does UML make the grade? Insights from the

software development community. Information and Software Technology, 383-397.

Object Management Group. (2010). BPMN 2.0 by Example.

Object Management Group. (2013). Business Process Model and Notation (BPMN).

Object Management Group. (2015). Unified Modeling Language.

Object Management Group. (2016). OMG. Obtenido de http://www.omg.org

Sparx Systems. (s.f.). Enterprise Architect. Obtenido de http://www.sparxsystems.com.au/