UNIVERSIDAD NACIONAL DE PIURA

FACULTAD DE INGENIERIA INDUSTRIAL

ESCUELA DE INGENIERIA INFORMATICA

TRABAJO DE INVESTIGACIN - INFORME FINAL

INTEGRACIN DE BPMN y UML PARA ALINEAR LOS PROCESOS DE

NEGOCIO A LOS PROCESOS DEL SISTEMA DE INFORMACIN,
CONSIDERANDO LAS NUEVAS NECESIDADES ORGANIZACIONALES.

DOCENTE:
ING. LIZANA PUELLES ESTHER YOLANDA Mag.

Mayo 2014

INDICE
CAPTULO I: EL PROBLEMA DE INVESTIGACIN

1.1. Planteamiento Del Problema

1.1.1. Formulacin del problema

1.2. Objetivos

1.2.1. Objetivo General

1.2.2.Objetivos Especficos
1.3. Justificacin De La Investigacin

1.4. Alcances Y Limitaciones

7
7

CAPTULO II: MARCO TEORICO-CONCEPTUAL

2.1 Antecedentes del Estudio

2.2 Marco Terico

2.2.1 Modelado de negocios

2.2.2 Visin general

2.2.3 Caractersticas Principales

2.2.4 El lenguaje unificado de Modelado

2.2.5 Artefactos de UML

2.2.6 Enfoques y beneficios en UML

2.2.7 Procesos de Negocio

2.2.8 Extensin de UML

2.2.9 Procesos de modelado de negocios basados en UML

2.2.10 El Lenguaje BPMN

21

2.2.10.1 Objetivos que persigue BPMN

21

2.2.10.2 Beneficios BPMN

21

2.2.10.3 Objetivos al crear BPMN

23

2.2.10.4 Artefactos

23

2.2.10.5 Tipos de Elementos BPMN

24

2.2.11 Ingeniera de Requisitos

29

2.2.12 Aproximacin basadas en modelado Organizacional

30

2.2.13 Aproximacin basados en UML

30

2.2.14 Diagramas de Proceso de Negocio (BPD)

31

2.2.14.1 Elementos de un BPD

31

2.2.14.2 Clasificacin de los procesos de Negocio

31

2.2.15 Modelado de Procesos

33

CAPTULO III: Integracin UML Y BPMN

34

3.1 UML y RUP en el modelado del negocio

35

3.2 BPMN vs UML y su integracin

36

3.3 Relacionado requerimientos BPMN y Casos de uso

37

3.4 Aplicacin de la integracin BPMN-UML/RUP

41

CONCLUSIONES

51

BIBLIOGRAFA

51

INTRODUCCION
Representar y mantener los mltiples componentes de una organizacin es
fundamental para entender cmo opera sta y cmo se adapta a un cambio en el entorno
del negocio. Esta representacin se encuentra generalmente asociada a alguna tcnica de
modelado de procesos de negocio, debido a que estos modelos son capaces de representar
cmo un conjunto de actividades se enfocan en la obtencin de un objetivo o poltica de
la organizacin, en este sentido la tecnologa de la informacin en general y los sistemas
de informacin en particular, juegan un rol importante en la gestin de procesos de
negocio dado que muchas de las actividades son soportadas por sistemas de informacin.
El xito en el alcance de los objetivos y su logro eficaz y eficiente depende del
trabajo coordinado de los recursos que intervienen (sean estos humanos o tecnolgicos).
Mientras que en el mbito organizacional los procesos de negocio sirven para entender
cmo opera la compaa, tambin juegan un rol importante en la construccin de sistemas
de informacin ms flexibles. Esta flexibilidad se mide en su capacidad de adaptarse
rpidamente a los cambios y para absorber velozmente el ritmo del mercado.
La gestin de procesos de negocio incluye conceptos, mtodos y tcnicas para
soportar el diseo, administracin, configuracin, representacin y anlisis de los
procesos de negocio. El anlisis de los modelos de procesos de negocios est enfocado
principalmente a la completitud de stos, es decir, qu elementos de la realidad a ser
modelada pueden ser representados. El mbito del modelamiento considera aspectos
inherentes a los procesos de negocios y aspectos de la relacin proceso de negociosistemas informticos, los procesos de negocios requieren funciones de informacin, y los
sistemas informticos entregan funcionalidades operativas, que estn apoyando a las
actividades de los procesos.
Su objetivo ltimo es representar el proceso de negocio con sus actividades y las
restricciones de ejecucin entre ellas utilizando para su representacin lenguajes
adecuados como el BPMN y el UML, considerando en la presente investigacin la
integracin de stos para una mejor representacin del modelo de procesos de negocio.

CAPITULO I: PLANTEAMIENTO DEL ESTUDIO

1.1 FORMULACIN DEL PROBLEMA.
El mundo de los procesos de negocio ha cambiado dramticamente en los ltimos aos,
en tanto que las organizaciones se encuentran en la incesante bsqueda de la eficiencia,
buscando obtener informacin til de los procesos que ejecutan y que le permitan tomar
decisiones certeras.
Sobre sta necesidad, las organizaciones confan la operatividad de los procesos del
negocio en la implementacin de sistemas de informacin, desvirtuando la importancia
que tiene el modelar el proceso del negocio, antes de convertirlo en un proceso del
sistema. Por su parte los analistas utilizando las herramientas de UML proceden a
modelar los procesos explicndolos detalladamente a travs del uso de diagramas de
actividades, pero an as, consideran que es un proceso complejo, ya que no slo
conlleva la resolucin de los problemas tecnolgicos asociados con su arquitectura y
componentes, sino que tambin se debe tener en cuenta los problemas organizacionales y
sociales relacionados con su dominio de aplicacin.
Los analistas de sistemas, como parte del equipo constructor de sistemas de informacin,
tienen la funcin de abstraer e instanciar los procesos del negocio que existen en las
organizaciones y ms de uno dir que es un proceso complejo, ya que en las primeras
entrevistas de requerimientos se encuentran con usuarios que no estn seguros de cmo
funcionan sus procesos de negocio y por lo tanto resulta imposible definirlos, pues, en
estas situaciones debemos enfatizar el anlisis hacia los procesos del negocio requiriendo
para ello, de alguna herramienta y tcnica adecuada, que permita modelar de forma
efectiva los procesos y obtener importantes reducciones de costos y claros incrementos en
la satisfaccin de los clientes internos y externos, es decir contar con una herramienta que
permita alinear los procesos de negocio a la estrategia del negocio, a las infraestructuras
organizacionales y a las metas organizacionales.
Integrando BPMN y UML ayudarn a modelar los procesos de negocio de la
organizacin para desarrollar el sistema de informacin adecuado que proporcione un
valor real y se ajuste a las nuevas necesidades organizacionales?
1.2 OBJETIVOS DE LA INVESTIGACIN.
La investigacin propone integrar las metodologas BPMN y UML para modelar los
procesos de negocio, alineados a las nuevas necesidades organizacionales y mejorar
eficientemente los procesos de negocio ejecutados por los sistemas de informacin.
1.2.1 OBJETIVOS ESPECFICOS
Conceptualizar los diferentes enfoques sobre gestin de procesos de negocio
Comprender el manejo de procesos de negocio a travs de concepto de BPMN
Evaluar y determinar las herramientas de modelado de procesos BPMN que permita
la gestin de procesos de negocio.
1.3 JUSTIFICACIN DEL ESTUDIO.
Un modelo organizacional es una representacin que captura la estructura y el
comportamiento de la organizacin inmerso sobre un sistema, haciendo notar que es
importante hoy en da que las organizaciones orienten principalmente sus acciones a
responder lo ms rpido que se pueda y como sea a los requerimientos del cliente y/o
5

usuarios, descuidando severamente el control de los costos involucrados para concretar

esta accin. Es as, considerando que paralelamente a la calidad de sus servicios, que toda
organizacin tambin debe controlar la eficiencia de sus procesos, vale decir, los
resultados referidos a las unidades de recursos empleados, siendo necesario contar con
herramientas que permitan controlar con rigurosidad los costos asociados a cada servicio
que brinda.
A consecuencia de lo que buscan las organizaciones, para realizar una buena gestin y
tener procesos de negocio soportados por sistemas de informacin eficientes, nace un
gran inters es desarrollar o usar tcnicas que puedan integrar los procesos del negocio
con el proceso de desarrollo, sus modelos de desarrollo y los productos de software que
se construyen, es por ello que la investigacin propone definir una tcnica que consiste en
la integracin de BPMN y UML que permitan mejorar la calidad del servicio al cliente
y/o usuarios, y tengan procesos del negocio alineados a sus nuevas necesidades.
Esta tcnica a investigar puede ser muy til, ya que los desarrolladores entendern, de un
modo apropiado, las necesidades de informacin y los requisitos que el sistema debe
satisfacer. Se utilizar el BPMN como una tcnica de modelado estndar desarrollado
para proveer a los usuarios de una notacin de uso libre, beneficindolos de la misma
forma que UML benefici el mundo de la ingeniera de software.
La investigacin propone integrar la metodologa BPMN con UML para modelar los
procesos de negocio y se alineen a sus nuevas necesidades organizacionales, como a la
estrategia del negocio, a las infraestructuras organizacionales y a las metas
organizacionales, instanciados en sus sistemas de informacin, garantizando la gestin,
optimizacin y mejoramiento de sus procesos de negocio.
1.4 ALCANCES Y LIMITACIONES
Se desarrollar un anlisis metodolgico de la tcnica BPMN y UML como investigacin
acadmica, integrando la tcnica BPMN en el modelado de los procesos de negocio y que
sern refinados con la definicin de los requisitos en el modelado de los procesos del
sistema.
Se limita la investigacin para la explicacin de la integracin en la etapa del modelado
del negocio y requerimientos del ciclo de vida de los sistemas de informacin y siguiendo
la metodologa RUP en sus dos primeras fases: fase1: Iniciacin y fase2: Elaboracin de
RUP, el resto de las 2 fases sern parte de una segunda investigacin.

CAPITULO II: MARCO TEORICO - CONCEPTUAL

2.1. Antecedentes del estudio
El reto de las organizaciones, actualmente, para enfrentar un mercado tan competitivo y
obtener ventajas en l, es hacer un rediseo organizacional. Esto es posible, con la
aplicacin de las mejores prcticas en el desarrollo de una reorganizacin por procesos,
que implica ganancia en agilidad a la atencin de oportunidades, flexibilidad para
adaptarse al cambio e integracin de los procesos y las tecnologas de informacin. El
enfoque de procesos redunda a su vez en mayor eficiencia en la toma de decisiones
estratgicas para ubicar a la organizacin en el escenario actual y prepararse para el
futuro.
Las empresas necesitan saber: qu hace el cliente con el servicio, qu grado de
satisfaccin obtiene, en qu medida la empresa cubre sus aspiraciones, en qu puede
mejorar el servicio y cmo la empresa puede alcanzar el perfil de la mejor en su clase.
Para mejorar los servicios brindados al cliente, traer nuevos servicios al mercado,
eliminar las ineficiencias y cumplir con las regulaciones legales, los proveedores han
apostado por la gestin de los procesos de negocios (BPM). Sin embargo, desde el
momento en que una organizacin expresa la necesidad del cambio al enfoque de
procesos, comienza un arduo trabajo que involucra: decidir si se lleva a cabo la
reingeniera de procesos o el mejoramiento continuo de procesos; analizar la
automatizacin de los procesos asegurando la integracin eficiente de aplicaciones y de
datos entre los sistemas involucrados en esos procesos; cmo resolver la interoperabilidad
entre los sistemas y el negocio; cmo lograr la alineacin entre las tecnologas de
informacin y los objetivos estratgicos de la organizacin; cmo relacionar los procesos
interorganizacionales, es decir, entre clientes, proveedores y socios del negocio.
En los ltimos tiempos, herramientas tales como BPM (Business Process Modeling),
SOA (Service Oriented Architecture) y workflow estn tomando mayor fuerza, tanto en
las organizaciones como en la industria del software. Esto ha llevado a que las
organizaciones piensen en el desarrollo y la adquisicin de aplicaciones de software
adoptando el concepto de arquitecturas empresariales.
Artculo: UN LENGUAJE DE TRANSFORMACIN ESPECFICO PARA MODELOS
DE PROCESO DEL NEGOCIO-Refactorizacin de modelos de proceso.
Los autores adaptan refactorizaciones convencionales en la IS a las necesidades de los
modelos de proceso y las completan con otras especficas para BPM. La aplicacin de
estas operaciones transforma un modelo de proceso P en un nuevo modelo de proceso P.
Varias de las tcnicas descriptas no slo se aplican a actividades (tareas o subprocesos),
sino tambin a artefactos (grupos) con una sola entrada y una sola salida.
BPMN crea un puente estandarizado para suplir la brecha entre los procesos de negocio
y la implementacin de procesos.

2.2. Marco Terico

2.2.1. Modelado de Negocio
Dividamos los trminos; segn la Real Academia de la Lengua Espaola (RAE, s/f),
modelar es:
Formar de cera, barro u otra materia blanda una figura o adorno.
Configurar o conformar algo no material.
Presentar con exactitud el relieve de las figuras. Por lo tanto el modelado es la accin
de conformar la representacin de algo.
Por su parte, la definicin de negocio es (RAE, s/f):
Ocupacin, quehacer o trabajo.
Dependencia, pretensin, tratado o agencia.
Aquello que es objeto o materia de una ocupacin lucrativa o de inters.
Accin y efecto de negociar.
Utilidad o inters que se logra en lo que se trata, comercia o pretende.
Local en que se negocia o comercia.
Sobre la base de estas definiciones entendemos entonces que: el modelado de negocios es
la conformacin de la representacin de los quehaceres de un comercio (empresa).
Esto nos orienta hacia el hecho de que el modelado de negocios debe crear una
representacin grfica de una empresa, donde se puedan apreciar todo los elementos que
lo componen, su interaccin, recursos, metas, procesos la comunicacin y relaciones que
existen.
2.2.2. Visin General
El modelado de negocios es de gran ayuda en la etapa de anlisis de desarrollo de
software, ya que tener un buen modelo permite lograr comprender el mbito de la
informacin adems de identificar las actividades y procesos que se realizan dentro de la
organizacin para lograr una correcta operacin y as lograr una buena comprensin del
negocio para automatizar procesos al crear sistemas computacionales que se ajusten a la
medida de una organizacin.
De esta manera, si los requerimientos son tomados con base en el modelado del negocio,
las probabilidades de que el sistema que se realice se adapte a las operaciones a realizarse
dentro de la organizacin, son muy altas.
Existen varias ventajas para basar los sistemas de informacin en un mismo modelo
bsico de negocio (Len y Asato, 2009):
Los sistemas de informacin se vuelven una parte integral del negocio global,
soportando las operaciones, fortaleciendo el trabajo y la obtencin de resultados.
Los sistemas se integran fcilmente unos con otros y pueden compartir o intercambiar
informacin.
Un modelo de proceso de negocio tpicamente define los siguientes elementos (Len y
Asato, 2009):
El Objetivo o motivo del proceso.
Las Entradas especficas.
Las Salidas especficas.
8

Los Recursos consumidos.

La secuencia de las Actividades.
Los Eventos que dirigen el proceso.

2.2.3. Caractersticas Principales

Dentro de las principales caractersticas del modelado de negocios se tienen las siguientes
(Len y Asato, 2009):
Permiten comprender mejor los mecanismos clave de un negocio existente: Se debe
proveer una imagen clara de sus roles y tareas en la organizacin global, los modelos
pueden ser usados para entrenar a las personas. Pueden ser usados tanto en una
organizacin jerrquica como en una organizacin orientada a procesos.
Actan como base para crear sistemas de informacin: Las descripciones de negocio
son usadas para identificar el apoyo de sistemas de informacin a los principales
procesos de la organizacin. Los modelos tambin son usados como una base para
especificar los requerimientos clave de esos sistemas.
Facilitan la identificacin de ideas para mejorar la estructura actual del negocio y su
operacin: Los modelos permiten identificar situaciones susceptibles de ser
mejoradas, la construccin de un modelo implica un proceso reflexivo del porqu se
hacen las cosas como se hacen, de manera que pueden visualizarse cambios en el
negocio actual que son necesarios para implementar el modelo mejorado.
Para experimentar con un nuevo concepto de negocio: Un modelo es una entidad
conceptual de bajo costo sobre la cual pueden hacerse ciertas pruebas para validar su
operacin, lo que los hace ser un medio para la adopcin de mejores prcticas
inspiradas por otros modelos de negocios exitosos. Tambin permite tomar ventaja
mediante la adopcin de nuevas tecnologas, tales como las relacionadas con Internet.
Para identificar oportunidades de Outsourcing: Los elementos del negocio no
considerados como parte central, son delegados a proveedores externos. Los modelos
son usados como especificacin para los proveedores.
Para mostrar la estructura de un negocio innovado: Los modelos sirven para presentar
ante la gerencia la nueva propuesta de trabajo, de manera tangible y concreta. A partir
de este punto es posible definir nuevas acciones, entonces los modelos se vuelven la
base para los planes de accin que apoyarn la transformacin del negocio.
2.2.4. El Lenguaje Unificado de Modelado
El Lenguaje Unificado de Modelado (UML) es, como su nombre lo indica, un lenguaje de
modelado. UML brinda a los arquitectos de sistemas, ingenieros de software y
desarrolladores de software, herramientas para las etapas de anlisis, diseo e
implementacin de desarrollo de software, as como para el modelado de negocios.
2.2.5. Artefactos de UML
El UML est compuesto por un rico conjunto de elementos grficos, los cuales al
combinarse crean diferentes tipos de diagramas. Al ser un lenguaje grafico tambin
cuenta con reglas semnticas. A continuacin se muestran los elementos grficos que se
utilizan para el modelado de negocios, es importante tomar en cuenta que estos no son
todos los elementos con los que cuenta UML, pues existen diferentes tipos de diagramas
9

que requieren de otros componentes, pero solamente mostraremos los que se requieren
para modelar negocios.

Tabla 1 Componentes de UML (para modelar actividades de los negocios)

2.2.6. Enfoques y beneficios en UML
Para alcanzar metas una empresa debe definir sus procesos, y cada uno de estos tiene un
conjunto de elementos (datos, entradas, salidas, acciones, etc.) que interactan de acuerdo
a un flujo de trabajo establecido, estos procesos se encuentran relacionados con base en
las reglas del negocio que estn determinadas por las polticas y manual organizacional.
UML ser de ayuda en la descripcin de estos elementos.
El UML provee beneficios significativos para los ingenieros de software y las
organizaciones, al ayudarles a construir modelos rigurosos, trazables y mantenibles, que
soporten el ciclo de vida de desarrollo de software completo (Len y Asato, 2009).
UML es un lenguaje de modelado de amplio uso, ha sido desarrollado por investigadores
de alto prestigio, adems, a lo largo de los aos (desde 1995), ha estado en constante
evolucin, adaptndose a las nacientes necesidades del rea de diseo. Otro punto
importante de UML es que la gran mayora de las herramientas CASE y de desarrollo la
han adaptado como lenguaje de modelado.
UML resuelve de forma bastante satisfactoria un viejo problema del desarrollo de
software: su modelado grfico. Adems, se ha llegado a una solucin unificada basada en
lo mejor que haba hasta el momento, lo cual lo hace todava ms excepcional (OMG,
2011).
2.2.7. Proceso de Negocio
Las definiciones de proceso de negocio son abundantes, y, aunque normalmente adaptada
de alguna definicin anterior, casi cada autor o experto tiene la suya. Entre otras, se
pueden destacar las siguientes:
Un proceso de negocio es un orden especfico de actividades de trabajo a lo largo
del tiempo y el espacio, con un comienzo, un fin, y unas entradas y salidas
claramente definidas: una estructura para una accin (Davenport, 1993)
Un proceso de negocio es un conjunto de actividades que toman uno o ms tipos de
entradas y crea una salida que tiene valor para el cliente (Hammer, Champy, 2001).
Un procesos de negocio es un conjunto de uno o ms procedimientos o actividades
enlazados que colectivamente ayudan a cumplir un objetivo o poltica de negocio,
normalmente dentro del contexto de una estructura organizacional en la que se
definen roles y relaciones (WfMC, 1999)
Un proceso de negocio es un conjunto completo y dinmicamente coordinado de
actividades colaborativas y transaccionales que dan valor a los clientes (Smith,
Fingar, 2002)
10

Un proceso de negocio consiste en un conjunto de actividades que se desarrollan

coordinadamente en un entorno organizacional y tcnico. Estas actividades satisfacen
conjuntamente alguna meta de negocio. Cada proceso de negocio se desarrolla en una
sola organizacin, pero puede interactuar con procesos de negocio de otras
organizaciones (Weske, 2005).

Aunque se podra decir que todas estas definiciones son similares, y que, por tanto, la
nocin de proceso de negocio es sencilla y comn, algunos trabajos han estudiado la
naturaleza y definicin de los procesos de negocio (Lindsay, Downs, Lunn, 2003; Melao,
Pidd, 2000).
Estos trabajos argumentan que es complicado desarrollar aproximaciones adecuadas para
su modelado sin una definicin adecuada de qu es un proceso de negocio ni comprender
su naturaleza.
Se han identificado cuatro perspectivas respecto a los procesos de negocio de una
organizacin (Melao, Pidd, 2000). Cada una de ellas pone nfasis e ilustra diferentes
caractersticas de los procesos de negocio, y presenta debilidades. Las perspectivas son
las siguientes:
a. Procesos de negocio como mquinas deterministas
Un proceso de negocio se define como una secuencia fija de actividades o tareas bien
definidas y desarrolladas por mquinas humanas que convierten entradas en salidas para
conseguir objetivos. El criterio principal sobre el buen diseo de un proceso es la
eficiencia en el uso de dinero, recursos y tiempo, sujeto a la restriccin de satisfacer las
necesidades de los clientes. Las TI juega un papel importante en esta perspectiva porque
son las encargadas de automatizar, coordinar y dar soporte a los procesos de negocio.
Las debilidades de esta perspectiva son que no tiene en cuenta los aspectos humanos y
organizacionales de los procesos y que asume que un proceso de negocio es esttico.

b. Procesos de negocio como sistemas dinmicos complejos

Esta perspectiva se centra en las caractersticas complejas, dinmicas e interactivas de los
procesos de negocio, considerndolos como sistemas abiertos que se adaptan a un entorno
cambiante, similares a un sistema orgnico. Un proceso de negocio tiene entradas,
transformaciones, salidas y lmites. As, un proceso de negocio se define como un
conjunto de subsistemas (personas, tareas, estructura, tecnologa) que interactan entre
ellos (relaciones internas) y con el entorno (relaciones externas) para cumplir algn
objetivo.
Las debilidades de esta perspectiva son que puede provocar que no se tenga en cuenta la
dimensin social de los procesos de negocio, que su puesta en prctica puede requerir
11

demasiado esfuerzo respecto a las ventajas que se obtienen, y que ignora la

retroalimentacin que tiene lugar en muchos procesos de negocio reales. No obstante,
esta perspectiva nos recuerda que diferentes subsistemas de un proceso de negocio
interactan para producir un comportamiento dinmico complejo.

c. Procesos de negocio como bucles de retroalimentacin que interactan

La tercera perspectiva extiende la vista orgnica resaltando la estructura de
retroalimentacin de informacin de los procesos de negocio. Los procesos de negocio se
definen como bucles cerrados con control intrnseco, con un comportamiento dinmico
debido a interacciones entre estructuras y polticas internas. As, un proceso de negocio
representara un flujo de recursos desde el exterior de su lmite a travs de una secuencia
de niveles que representan acumulaciones o transformaciones. Las polticas regulan los
flujos, y las acciones se toman a partir de una informacin que produce retroalimentacin.
Las debilidades de esta perspectiva son que, si se lleva al extremo, se corre el riesgo de
considerar el factor humano como un mero instrumento de control, y que su aplicacin es
compleja.

d. Procesos de negocio como constructores sociales

La cuarta perspectiva enfatiza la parte humana de los procesos de negocio, creados y
ejecutados por personas con diferentes valores, expectativas y responsabilidades.
As, un proceso de negocio se define como un conjunto de diferentes percepciones de
varias personas y grupos que son el resultado de diferentes interpretaciones de la realidad.
Las diferencias entre interpretaciones se deben a los distintos valores, creencias,
expectativas y experiencia, y actan como filtros que permiten a las personas percibir
unas cosas e ignorar otras.
Las debilidades de esta perspectiva son que, al considerarla aisladamente, podra impedir
que se consigan diseos ms eficientes o no ser capaz de proveer objetivos para evaluar
los cambios en los procesos de negocio.
Por tanto, es importante tener en cuenta las cuatro perspectivas a la hora de comprender y
definir qu es un proceso de negocio, de manera que cualquier tcnica para el modelado
de procesos de negocio debera intentar integrar el mayor nmero posible de perspectivas.
As, en esta tesis se propone la siguiente definicin de proceso de negocio para que gue
su modelado:

12

Un proceso de negocio es un conjunto de actividades ordenadas que se desarrollan en una

organizacin para alcanzar alguna de sus metas, recibe entradas del entorno y genera
salidas, y es ejecutado coordinada y dinmicamente por personas y/o componentes
tcnicos de la organizacin que intercambian informacin.

2.2.8. Extensin de UML

La versin extendida de UML por medio de estereotipos para abordar el modelado
organizacional incluye la visin del negocio, la estructura de negocio y los procesos de
negocio.
La visin del negocio incluye el modelado de metas. Su propsito es entender mejor el
funcionamiento de una organizacin, y que los modelos sirvan de punto de partida para
crear su SI, para mejorar su estructura y comportamiento y para identificar alternativas y
oportunidades de negocio.
Los conceptos en los que se basa esta aproximacin son:
Recursos, como objetos del negocio que se utilizan y se producen en la actividad de
una organizacin.
Proceso, como actividades de una organizacin en las que cambia el estado de los
Recursos.
Metas, como el propsito de una organizacin y el resultado que quiere lograr al
desarrollar su actividad.
Reglas, como afirmaciones que definen o restringen algn aspecto de una
organizacin
Para modelar una organizacin, la aproximacin define 4 vistas, cada una de las cuales se
representa en uno o varios diagramas. Las vistas no son modelos separados, sino que son
perspectivas diferentes de uno o ms aspectos de una organizacin. Las vistas son las
siguientes:
Vista de la visin de negocio: en esta vista se define la visin general de una
organizacin. Se describe su estrategia y su estructura de metas, se ilustran los
problemas que se deben resolver para alcanzar dichas metas, y se define la situacin
deseada por la organizacin.
Vista de los procesos de negocio: en esta vista se modelan los procesos de negocio
que representan las actividades de la organizacin y el valor que crean por medio de
una extensin de los diagramas de actividad. Se muestra la interaccin entre los
procesos y los recurso para lograr las metas de cada proceso, adems de la interaccin
entre diferentes procesos.
Vista de la estructura de negocio: en esta vista se representan la estructura de los
recursos, productos, servicios, informacin y unidades de una organizacin. Se
modela en paralelo a la vista de los procesos de negocio.
13

Vista del comportamiento de negocio: en esta vista se representa el comportamiento

individual detallado de cada recurso y proceso importante para una organizacin. El
comportamiento de los recursos se basa en la vista de los procesos de negocio. En
esta vista se utilizan diagramas de secuencia.

Para obtener los modelos de software a partir de los modelos organizacionales, se

identifica el SI que mejor soporte dar a la organizacin, se especifican los requisitos
funcionales (funciones o casos de uso) y no funcionales, se analizan los modelos
organizacionales durante el anlisis y diseo del sistema, y se identifican los componentes
necesarios.
2.2.9. Procesos de modelado de negocios basados en UML
El modelado de negocio, como cualquier otra actividad donde se trata de plasmar algo
abstracto en algo concreto, debe llevar una secuencia de pasos bien definidos. Se
enumeran estos pasos junto con las sub-tareas que llegarn a conformarlos para que as la
persona encargada de realizar la tarea de modelar procesos de negocio tenga una base
slida y no haya lugar a interpretaciones.
Esta enumeracin de pasos se conoce como ciclo de vida del modelado de procesos de
negocio y no es otra cosa que una secuencia lgica de pasos recomendados para
completar la tarea de plasmar el quehacer diario de una empresa u organizacin
cualquiera en objetos (grficos, descripciones, diagramas de flujo, entre otros) para
entender de manera fcil y de primera vista el funcionamiento general de la organizacin.
Generalmente (y no debe entenderse como letra escrita en piedra) la secuencia que
involucra el modelado de procesos de negocio puede entenderse como se presenta a
continuacin:

En trminos generales debe entenderse que la representacin piramidal tiene un sentido

formativo desde su base hacia lo alto de sta, de tal forma que si no se cumple con los
trminos bsicos (formacin de la base piramidal) el resultado de las capas superiores
ser igualmente deficiente. Bajo estos trminos, modelar los procesos de negocio lleva
dentro de s una serie de pasos ordenados y secuenciales (como ya se haba mencionado)
que, si no garantizan al 100% su correcta conformacin, si nos dejarn muy cerca de este
lmite.
A continuacin se listan los pasos que se deben seguir:
Paso1: Identificar los procesos de negocio
Hacer a manera de levantamiento de campo, un buen pero concreto levantamiento de
informacin utilizando alguna de sus tcnicas (entrevistas, cuestionarios, encuestas,
14

observacin, entre otras) y as identificar y listar los procesos que se desarrollan en la

organizacin. Se debe ser cuidadoso de slo documentar los procesos que en realidad
vayan a intervenir en nuestro modelado y no hacer trabajo de ms al documentar procesos
no contemplados o solicitados para su entendimiento. Si se trata de modelar la
organizacin completa, sern los procesos completos; en caso contrario identificar cules.
Para las personas expertas no tendr validez este comentario, pero a los observadores
nveles se les debe recalcar evitar confundir un subsistema con un proceso de negocio.
Por ejemplo en una pgina web de alguna tienda en lnea la seccin Catlogo en lnea
no es un proceso de negocio, sino una unidad funcional que funge como parte de su
modelo de negocio para servir de intermediario en las ventas a sus clientes a travs de una
plataforma diferente a la tradicional.
Un proceso del negocio sera ms del tipo atender solicitud de ventas que puede
pertenecer al modelo tradicional (el cliente se desplaza fsicamente al punto de venta) o
en el modelo de comercio electrnico (catlogo virtual, carrito de compras) y se sugiere
una descripcin como la siguiente:
Se atiende una peticin de compra del cliente y se verifica esta solicitud sujeta a las
siguientes restricciones: Mnimo de compra. Verificar su existencia en almacn. Se deber
verificar la NO existencia de duplicidad de pedidos y pasar por un proceso de aprobacin
que realizar una persona asignada a esta labor que deber atender los conflictos de
logstica que se deriven de las ventas (urgencia de un cliente sobre una mercanca
especfica contra tiempos de entrega de proveedores de sta). Deber decidir si cae en una
categora especial, cancelacin de pedido o cualquier decisin necesaria para atender al
cliente.
As se describe de manera clara el proceso que se sigue en la organizacin para atender
pedidos y su vertiente de pedidos especiales.
Identificar los usuarios, departamentos o elementos de la organizacin implicados en los
procesos de negocio.
Quines participan y con qu roles lo hacen, qu funciones especficas tiene ese rol. Por
ejemplo se puede decir que el proceso del negocio arranca cuando se recibe
automticamente una peticin del cliente o un empleado hace esta peticin explcita
mediante un formato o usando un canal de comunicacin adecuado; de esta forma la
peticin automtica y el empleado juegan el rol de solicitante de venta. Mientras que el
responsable de ventas es quien aprueba los pedidos y resuelve conflictos de logstica
cuando se tienen restricciones en el tiempo de produccin/entrega del producto pedido.
Por otro lado, el cliente es quien realiza el pedido y el operario es el encargado de
entregar los pedidos a los clientes.
Al revisar la lista anterior se puede deducir fcilmente que los involucrados son:
Solicitante de venta.
Responsable de ventas.
Cliente.
Operario.

15

Paso2: Acciones para realizar el Proceso de Negocio

Se describen las interacciones entre los roles identificados en el paso anterior para que el
proceso de negocio se lleva a cabo. Se sugiere una forma como la siguiente:

Es importante hacer notar la importancia de la realizacin de este paso, ya que como se

puede observar hay una redundancia en la identificacin de roles: el solicitante de venta
es el mismo que el cliente.
A continuacin se muestra una lista de las actividades que realiza cada rol.
Solicitante de venta (cliente):
Realiza una peticin
Enva peticin
Aprueba pedido
Responsable de ventas:
Decide
Discrimina
Encamina
Aprueba o rechaza
Procesa
Operario:
Entrega
Paso3: Diagrama de actividades
Ahora que se conocen los participantes y las actividades que realizan, se deber hacer un
diagrama donde se reflejen de manera clara estas actividades y la relacin que tienen con
los otros actores. El diagrama que se muestra a continuacin mezcla las actividades con el
personal encargado de cada una de ellas, este diagrama es denominado Diagrama de Flujo
de Funciones Cruzadas, donde cada columna es la representacin de cada uno de nuestros
actores (personas) involucrados, y se van colocando las actividades que cada uno realiza,
hasta completar el proceso en su totalidad. A continuacin se muestra el diagrama
correspondiente a nuestro ejemplo de negocio de venta:

16

La siguiente imagen ilustra el modelado de otro proceso para que se note la facilidad que
implica realizar este diagrama sin importar la naturaleza de la organizacin o del proceso
modelado.

17

Listar las actividades

La secuencia formativa del proceso de negocio es simplemente plasmar lo que se observ
en distintos tipos de objetos como listas, diagramas de flujo de funciones cruzadas o
diagramas de actividades. La lista de actividades del ejemplo original (procesamiento de
una venta) quedar como la siguiente lista:
Realiza peticin.
Enva peticin.
Decide aprobacin.
Discrimina encaminamiento.
Realiza encaminamiento.
Procesa pedido.
Entrega pedido.
Aprueba o rechaza pedido.

Con base en esta lista de actividades crearemos el diagrama de actividades

correspondiente, que sera como el que se muestra a continuacin:

18

Del ejemplo anterior (Diagrama de Flujo de Funciones Cruzadas del Proceso de

seguimiento) podemos observar que la lista de actividades que refleja la imagen
ilustrativa ser la siguiente:
Preparar lista de fichas.
Preparar lista de responsables.
Enviar lista de fichas y lista de responsables a administrador.
Dar de Alta, Baja o Cambio a fichas.
Dar de Alta, Baja o Cambio a responsables.
Asignar ficha a responsable.
Notificar a responsables.

Con base en lo anterior, el diagrama de actividades quedara como se muestra a

continuacin:
Listar las actividades brinda muchos beneficios al modelado de procesos de negocio, ya
que permite al modelador (persona que hace el modelado de los procesos) asociar cada
actividad con uno o varios casos de uso que posteriormente facilitarn su rastreabilidad y
en segundo trmino (pero no menos importante) ayuda a comprender el sistema y sus
procesos evitando ambigedades en los requerimientos y evitar inyectar errores en una
fase temprana del anlisis.
19

Listar la informacin
Se deber identificar la informacin que fluye a travs de los distintos actores y sus
distintas actividades. En el primer caso slo fluye un pedido, mientras que para el caso de
la imagen ilustrativa, las fichas y los responsables son la parte que fluye de una actividad
a otra. De esta manera, listar la informacin nos ayudar para empezar a construir un
mapa conceptual de todas las actividades y del sistema en general. Se podr identificar
que habr ms informacin en el sistema, pero slo se lista la que fluye y se intercambia.
Como producto de trabajo adicional a lo ya mencionado, se pueden empezar a
documentar las acciones y el flujo de informacin como posibles objetos (clases) y as ir
robusteciendo toda la informacin posible que se necesite a la hora de transformar el
modelo de procesos de negocio en requerimientos de un sistema de informacin.
Reglas del negocio
Pueden entenderse como la serie de restricciones o reglas del juego que impone la
organizacin a la hora de realizar alguna actividad. En cada proceso puede aparecer un
nmero diferente de reglas del negocio y su aplicacin estar en funcin del proceso que
representan.
En nuestro ejemplo las reglas de negocio que se pueden visualizar son: Cuando se
realice un pedido, dependiendo del producto seleccionado, se deber verificar un mnimo
de compra. Evitar la duplicidad de pedidos ya que los costos que generara esto para la
empresa seran intratables. Un pedido no puede procesarse si no tiene una aprobacin
explcita del encargado. Cuando se detecte un conflicto en la logstica, el encargado del
rea ser el nico que lo podr atender y resolver.
Diagrama del ciclo de vida del modelado de procesos del negocio
Una vez revisados los puntos anteriores, se debe hacer notar que el ciclo de vida es una
secuencia lineal y puede representarse como a continuacin se muestra:

2.2.10. El lenguaje BPMN

Se puede definir al BPMN como la captura de una serie ordenada de actividades e
informacin de apoyo que refuerzan a stas. Modelar un Proceso de Negocio incluye la
representacin de cmo una empresa realiza los pasos necesarios para lograr sus objetivos
centrales y, aunque los objetivos son la parte primordial de todo el modelado, no se
capturan dentro del modelo, se sobreentiende que se modelan los pasos para poder llegar
a ellos. Con BPMN slo los procesos son modelados.

20

2.2.10.1. Los objetivos principales que persigue BPMN son:

El objetivo primario del lenguaje estndar BPMN fue proveer una notacin que sea
legible y entendible para todos los usuarios de negocios, desde los analistas que realizan
el diseo inicial de los procesos y los responsables de desarrollar la tecnologa que
ejecutar estos procesos, hasta los gerentes de negocios encargados de administrar y
realizar el monitoreo de los procesos. BPMN define un modelo de procesos de negocio
basndose en diagramas de flujo. Un modelo de procesos de negocio, es una red de
objetos grficos que representan las actividades (por ejemplo tareas) y los controles de
flujo que definen su orden de ejecucin. Hasta la aparicin de BPMN no exista un
estndar especfico sobre tcnicas de modelado desarrollado para estos fines. BPMN ha
sido desarrollado para proveer una notacin estndar a los usuarios, de forma anloga a
como UML estandariz el mundo del modelado en la IS (Ingeniera de Software).
1. Tener una representacin grfica del Lenguaje de Modelado de Procesos de Negocio
(BPML), pues era primordial tener una notacin orientada hacia las necesidades del
usuario, es decir, una traduccin de la notacin orientada al negocio al lenguaje tcnico en
ejecucin (White, 2009).
2. Unificar la amplia gama de notaciones de modelado, pues en el mercado se maneja una
enorme variedad de stas y son utilizadas en forma arbitraria segn el gusto y necesidad
de quin las usa.
3. Consolidar los principios subyacentes del modelado de procesos, se pretende una
notacin comn, en cuanto a la representacin.
4. Llevar el ejercicio acadmico a la practicidad de las empresas, tanto para los
proveedores de herramientas de modelado como para los consumidores de stas. 5. Hacer
el aprendizaje transferible al estandarizar la manera de representar los modelos de
negocio y las herramientas necesarias para hacerlo.
6. Proporcionar un modelo ejecutable entre la representacin grfica (BMPN) y el
lenguaje de representacin formal (BPML, llamado luego BPEL). Por lo tanto
proporciona un mapeo vlido entre los diagramas y el lenguaje formal, de manera que se
pueda automatizar la ejecucin del modelo resultante.
2.2.10.2. Beneficios de BPMN
Cuando se pretende dar a entender una idea, hay muchas formas de hacerlo. Por ejemplo
para describir lo que es la letra A se puede hacer mediante descripciones muy
detalladas de manera verbal, pidindole que: imagine un tringulo pero con la parte de
abajo a la mitad, o como a interseccin de dos lneas en un ngulo de 45 y ambas
cortadas al centro por otra lnea paralela al ngulo mencionado en una distancia igual al
50% de su longitud entre muchas otras explicaciones producto de la prodigiosa
imaginacin del descriptor; pero en realidad el receptor no tendr el concepto completo
(definicin adems de representacin) si no se le da a conocer de manera grfica como
debera verse una A. De esta manera es posible apoyarse en el BPMN para hacer la
representacin grfica de los procesos que conforman el modelo de negocio de una
empresa.
Para hacer uso del BPMN, hay muchos aspectos o detalles que se deben tomar en cuenta;
por ejemplo si se quiere modelar el proceso de leer un libro, bastara con hacer mencin
que se toma el libro y se lee y para muchas personas eso sera ms que suficiente para

21

comprender de lo que se trata el modelo. Sin embargo no siempre se tratar o deber

modelar procesos tan familiares como el leer un libro.
Hoy en da las empresas se estn diversificando de tal manera que, su ritmo de trabajo lo
impulsan las ms variadas y diversas unidades de negocio; cada una de ellas con una
complejidad inherente a su propio objetivo tal, que se podra hacer un zoom y descubrir
un propio ecosistema dentro de ella.
Ahora, al querer modelar el conjunto de unidades funcionales: sus entradas, sus procesos,
salidas, en conjunto la complejidad de stas, sera exponencial revisar las relaciones que
hay entre ellas y, es aqu, donde el BPMN da una enorme ventaja y muchos beneficios; se
enlistan algunos a continuacin:
Hay una comunidad internacional respaldada por organizaciones reconocidas, de esta
manera no se dejar espacio a la interpretacin o al libre albedrio del modelador del
proceso de negocio, es decir, no se podr representar de manera diferente una relacin
entre departamentos, o de manera ms clara y concisa, no se podr malentender un
smbolo que represente flujo de datos de salida; si eso es lo que se representa, eso es
lo que se lee y eso es lo que se deber entender que quiere decir. De tal suerte que, al
ser una convencin internacionalmente aceptada, nadie que se diga apegado al
estndar del BPMN puede inventar sus propias representaciones, no puede aadir o
quitar elementos a su antojo, no tiene derecho a ser creativo en cunto al significado
ni la representacin de los elementos que conforman la representacin del BPMN,
pero s lo puede ser en el uso y la combinacin de ellos.
Cada vez se est ms inmenso en la aldea global. La ocurrencia de un suceso o
evento importante puede ser transmitida al otro lado del mundo en instantes. Esta
aseveracin lleva irremediablemente a la conclusin que se colabora cada da ms
entre personas de distintas regiones, culturas, idiomas, razas, entre otras variantes, lo
que significa que la complejidad de la comunicacin se vuelve alta. Al tener un
estndar de representacin de los procesos de negocio con el uso de BPMN de cierta
manera, si no se puede librar toda esta complejidad, se da la facilidad de hablar el
mismo lenguaje tanto al emitir como al recibir. Siguiendo al pie de la letra (como
debiera ser) lo que indica el estndar de BPMN no se tendr dificultad alguna al leer
(interpretar) modelado de negocio de una empresa, por ejemplo, de China o de Italia.
La misma rigidez que se sobreentiende del estndar BPMN tambin permite
formalizar; tanto que incluso (en algunas ocasiones y bajo ciertas circunstancias)
pueda
prescindirse
del
elemento
humano
para
su
elaboracin/interpretacin/implementacin/ejecucin y dejar este trabajo a elementos
automatizados (algoritmos programados en computadora) para hacer de los resultados
tan ricos en informacin como se desee.
De lo descrito en el punto anterior, se puede ahondar tanto, que se podr decir que: el
elemento grfico resultante del modelado de procesos de negocio no debe tomarse como
una receta infalible que al seguir descritos en algn lugar siempre funcionar. Con el
modelado de procesos de negocio, deber hacerse tomando en cuenta quin ser el
pblico al que se presentar, qu nivel de conocimiento tiene sobre los elementos tcnicos
que se quieren representar (por ejemplo: presentar a un mdico el funcionamiento de un
hospital ser diferente que a un ciclista profesional), qu nivel de detalle se desea saber.
No ser lo mismo dar una revisin laxa del todo, que una profunda descripcin de los
detalles.
22

2.2.10.3. Objetivos al crear BPMN

Para que una idea pueda ser comprendida por otro igual se necesita de un arduo trabajo de
convencimiento y explicacin, a fin de vender la idea. Cuando se est explicando en
trminos abstractos la secuencia del flujo del trabajo de un proceso que se maneja en una
empresa u organizacin, debe hacerse de tal forma que alguien que no est versado en sus
detalles pueda comprenderlo. El fin ltimo es que se d a entender lo que se hace. Al
tratar de listar los objetivos al crear BPMN se podr encontrar a los siguientes:
Contar con elementos grficos estndar.
Todos los elementos sern fciles de usar para describir los procesos de una empresa u
organizacin pues se basan en diagramas de flujo (de informacin en este caso).
Tener elementos que no se confundan entre ellos y as poder describir todos los
procesos de manera nica e irrepetible.
Tener un mtodo simple de crear modelos de procesos de negocio pero que al mismo
tiempo puedan manejar toda la complejidad que significan stos.
La descripcin de manera clara y explcita de todo lo que sucede en el interior de la
organizacin o empresa debe ser el punto principal que deben perseguir la persona o el
grupo que est modelando los procesos. Se debe recordar que los procesos se hacen para
ser vistos, ledos y comprendidos por terceras personas de cualquier extraccin cognitiva
y cultural, no se hacen para el equipo elaborador (para uno mismo).
2.2.10.4. Artefactos
A continuacin se muestran los diferentes
artefactos (elementos) de los que se compone un
diagrama BPMN.

23

2.2.10.5. Tipos de elementos de BPMN

A continuacin se listan los diferentes tipos de elementos de los que se compone BPMN,
as como su descripcin. Al final de la descripcin de los componentes se encuentra un
ejemplo de su uso, retomando el ejemplo del negocio electrnico visto en la unidad
anterior.
ACTIVIDADES
Tarea: Es el nivel ms bajo de actividades, las cuales no pueden ser descompuestas.
Sub-proceso: Es un conjunto de tareas unidas con un solo fin, el signo ms indica que
el subproceso puede descomponerse en pequeas actividades, que son las tareas.
Tarea bucle: Identifica que la tarea deber repetirse un determinado nmero de veces.
Multi-instancia: Esta actividad identifica que la tarea deber realizarse varias veces,
pero cada vez con diferentes datos.

24

EVENTOS
Un evento es algo que sucede durante el curso de un proceso. Los eventos afectan el
flujo del proceso y usualmente tienen un disparador (seal de que se debe realizar algo) o
un resultado (White, 2009). A continuacin se describen los diferentes tipos de eventos
con los que cuenta el BPMN.
Inicio: Este evento indica el inicio de un diagrama BPMN, al comenzar a realizar un
modelo es lo primero que se debe colocar.
Temporizador: Indica un disparador de fecha y hora.
Mensaje: Un disparador se genera al llegar un mensaje desde otro punto.
Seal: Un disparador se genera al llegar una seal enviada desde otro punto.
Condicional: Se indica que se debe cumplir con una condicin para
Mltiple: Indica que existe una combinacin de disparadores.
Error: Especifica que se interrumpir un proceso que necesitara ser corregido. Se
utiliza este mismo artefacto pero relleno de negro para indicar que el fin de un proceso
resulta en un error.
Cancelar: Indica la cancelacin de una actividad. Se utiliza este mismo artefacto pero
relleno de negro para indicar que el fin de un proceso resulta en una cancelacin.
Compensacin: Indica que una actividad se deshar. Y este mismo artefacto se utiliza
relleno de negro para indicar que el fin de un proceso resulta en una compensacin.
Vinculo: Establece un conector para ir hacia, otro punto del modelo. Se utiliza este
mismo artefacto relleno de negro para indicar el punto de conexin hacia donde se redirecciona.
Final: Este evento indica el final de un diagrama BPMN, al finalizar un modelo es lo
ltimo que se debe colocar.
Complejo: Se enva el flujo de actividades hacia varios caminos (hacia todos al
mismo tiempo), si es que se cumple una sola condicin del flujo secuencial de
actividades.
AGRUPAMIENTO
Estos elementos se utilizan para dividir y organizar los diagramas del BPMN, los cuales
se describen a continuacin.
Pools: Bsicamente son contenedores para indicar que el diagrama pertenece a un
participante en especfico.
Carriles: Son contenedores que representan roles en las actividades que se estn
modelando.
ARTEFACTOS
Objeto de datos: Son los documentos y datos que requieren los procesos.
Grupo: Ayuda a definir secciones en el diagrama.
Anotacin de texto: Son notas que aade quien modela a manera de informacin extra
sobre los modelos grficos.

25

PUERTAS DE ENLACE
Estos elementos controlan la divergencia del flujo de los procesos cuando se tienen
diferentes secuencias de flujo posibles, a continuacin se describen las diferentes puestas
de enlace que utiliza el BPMN.
Exclusivo: Evala las condiciones del flujo secuencial de actividades para definir un
solo camino hacia donde deber seguir el flujo.
Evento: Evala la ocurrencia de un evento para definir un solo camino hacia donde
deber seguir el flujo de actividades.
Paralelo: Se enva el flujo de actividades hacia varios caminos (hacia todos al mismo
tiempo) sin evaluar nada.
Inclusivo: Se enva el flujo de actividades hacia varios caminos (hacia todos al mismo
tiempo), si es que se cumplen las condiciones del flujo secuencial de actividades.
Asociaciones de los elementos BPMN
A continuacin se enumeran las asociaciones de los elementos BPMN:
Flujo de secuencia: Indica la secuencia de las actividades que se realizan, siendo el
origen la lnea sin punta, y el destino la punta de la flecha.
Flujo de secuencia condicional: Indica la secuencia de las actividades que se realizan
al cumplir o no una condicin. El pequeo rombo indica el origen del flujo de la
decisin y la punta indica el destino.
Flujo de mensaje: Indica la comunicacin entre participantes mediante mensajes, este
tipo de flujo se utiliza para comunicar a diferentes pools, el origen est indicado por el
crculo y el destino por la punta de la flecha.
Asociacin: Este elemento indica la unin entre elementos de un diagrama (sin flujo
de actividades).
Una vez descritos todos los elementos para generar diagramas BPMN se muestra el
diagrama del ejemplo de una venta mediante comercio electrnico.
Con la lista de actividades que se tiene y lo que hace cada rol (este ejemplo se vio en la
unidad anterior); en la siguiente lista que se desglosan las actividades a las tareas ms
bsicas:
Solicitante de venta (cliente):
Realiza una peticin.
o Revisa el catlogo de productos existentes.
o Analiza los productos de su inters.
o Si el producto le convence realiza la solicitud del producto mediante la compra.

Enva peticin
o Enva los datos de su compra.
o Enva sus datos personales para la entrega y pago.
Aprueba pedido
o Analiza la lista de cargos por la compra.
26

Si la lista de cargos es correcta aprueba los cargos y el pedido, de lo contrario

cancela la compra.

Responsable de ventas:
Decide
o Revisa la solicitud de compra.
o Analiza la fecha de entrega solicitada
Discrimina
o Identifica si es pedido especial o normal en base a la fecha de entrega requerida.
Encamina
o Se enva el pedido a que se surta.
Procesa
o Se revisa la existencia de los productos solicitados.
o Si no hay existencia de productos se cancela la compra.
o Si se cuenta con existencia se renen los productos solicitados (se surte).
Operario:
Entrega
o Revisa que el pedido corresponda con los productos solicitados.
o Si el surtido del producto es correcto se entrega al cliente.
o Si el surtido es incorrecto se regresa al paso de encaminamiento del pedido.
Una vez desglosadas las tareas de los procesos identificados se muestran los diagramas
correspondientes, en la imagen 1 se muestra el diagrama del proceso de compra a nivel de
subprocesos, de manera tal que se ven solo las actividades a nivel macro.

La siguiente imagen (2) muestra el mismo diagrama del proceso de compra pero a nivel
detallado (micro) donde cmo se puede observar se tienen todas las tareas requeridas.
Obsrvese que en este diagrama adems de tareas se utilizan puertas de enlace, pues se
requieren decisiones, tambin podemos observar que se utilizan eventos de cancelacin,
para los casos en que no existan productos que se quieran comprar, o los cargos del
pedido no sean los correctos.

27

La siguiente imagen (3) muestra el procesamiento del pedido a nivel de tareas; en l que
se puede revisar la utilizacin de una puerta de enlace paralela, ya que al discriminar solo
se identifica si el pedido es especial o normal -lo que se agreg con una nota de texto- y
despus se revisan las existencias, y como dice la descripcin no se evala nada, solo se
identifica el tipo de pedido. Otro elemento utilizado es un evento temporizador el cual es
utilizado por que la discriminacin se realiza con base en la fecha solicitada de entrega.

La siguiente imagen muestra el proceso de entrega del pedido, el elemento nuevo que se
utiliza en este diagrama es el evento vnculo, el cual indica volver a revisar existencias en
caso del que pedido no sea correcto.

Por ltimo, en la imagen 5, se muestra el

diagrama completo, que incluye el manejo de
roles -por lo tanto se usan carriles- y la
comunicacin de datos que se genera entre cada
proceso.

28

Imagen 5 Diagrama BPMN de un negocio de comercio electrnico a nivel tareas y con roles

2.2.11. Ingeniera de Requisitos (IR)

A pesar de las numerosas tcnicas existentes en la ingeniera del software, los fracasos en
los proyectos de desarrollo de sistemas software se pueden considerar comunes (The
Standish Group, 1995; Kotonya, Sommeville, 1998). Con demasiada frecuencia los
sistemas se entregan ms tarde de lo esperado, con mayor coste del previsto, y no
cumplen con las necesidades reales de los usuarios del sistema o de la organizacin en la
que se han de implantar. En la mayora de los casos, los fracasos no se deben a que las
personas que participan en el desarrollo del sistema no sean competentes o a una mala
prctica de ingeniera de software, sino que son consecuencia de problemas relacionados
con los requisitos del sistema.
Antes de desarrollar cualquier sistema software es necesario comprender qu deber
hacer y cmo dar soporte a las metas de los stakeholders (Sommerville, 2005). Esta
necesidad implica la comprensin del dominio de aplicacin, de las restricciones
operacionales del sistema, de la funcionalidad requerida por los stakeholders, y de las
caractersticas no funcionales del sistema.
La principal medida del xito (Nuseibeh, Eastbrook, 2000) y de la calidad (Finkelstein,
1994) de un sistema software es el grado en el que cumple con el propsito para el que
fue ideado, es decir, sus requisitos.
Por una parte, para poder definir los requisitos de un sistema, es necesario entender el
problema que deben resolver (Antn, 2003). Por otra parte, no se puede saber si un
sistema est finalizado y listo para su uso sin tener los requisitos claros, por lo que la
mayor amenaza para el xito de un proyecto es no desarrollar el proceso de IR
(Lawrence, Wiegers, Ebert, 2001).
La IR se puede definir como la rama de la ingeniera del software relativa a las metas del
mundo real, funciones, y restricciones de un sistema software. Adems, se preocupa de la
relacin de estos factores para obtener especificaciones precisas del comportamiento del
software y de su evolucin en el tiempo y a travs de familias software (Zave, 1997).
El proceso que se sigue durante la IR puede variar dependiendo del tipo de sistema a
desarrollar, el tamao y cultura de las organizaciones implicadas en el desarrollo, y el tipo
de software que se vaya a adquirir (Sommerville, 2005). No obstante, existe un conjunto
de actividades que son fundamentales para cualquier proceso de IR:
Captura: el propsito de esta actividad es identificar las fuentes de informacin sobre el
sistema y descubrir los requisitos a partir de ellas
Anlisis: el propsito de esta actividad es comprender los requisitos, sus coincidencias y
sus conflictos
Validacin: el propsito de esta actividad es que los stakeholders comprueben que los
requisitos se corresponden con sus necesidades
Negociacin: el propsito de esta actividad es intentar reconciliar las diferentes (y
posiblemente conflictivas) vistas de los stakeholders para generar un conjunto de
requisitos consistente
Especificacin: el propsito de esta actividad es documentar los requisitos a travs de su
redaccin en un estilo que tanto los stakeholders como los desarrolladores puedan
entender
29

 Gestin: el propsito de esta actividad es controlar los cambios en los requisitos, los
cuales aparecern inevitablemente
Los roles que debe jugar un analista de sistema son numerosos (Young, 2004), realizando
tareas que van desde el trabajo y la comunicacin con los clientes a la mediacin en
conflictos.
Las habilidades que debe poseer se pueden clasificar en tcnicas y personales (Ebert,
Wieringa, 2005). Las habilidades tcnicas son aquellas que se pueden aprender y aplicar
por distintas personas, y se dividen en habilidades de IR, de ingeniera de sistemas, y de
gestin. Las habilidades personales son nicas a cada persona, y se dividen en habilidades
comunicativas, cognitivas y sociales. Ambas habilidades se pueden desarrollar, pero el
desarrollo de las habilidades personales es ms complejo, ya que dependen de cada
persona.
2.2.12. Aproximaciones basadas en modelado organizacional
El modelado organizacional se puede definir como el arte de desarrollar modelos que
representen con precisin la estructura, organizacin y comportamiento de una entidad
de negocio, es decir, de una parte de una empresa o de un grupo de empresas (Vernadat,
1996). Su propsito es evaluar resultados o llevar a cabo un proceso de reingeniera en su
material, informacin o control de flujo para conseguir que una organizacin sea ms
eficiente. Los modelos organizacionales suelen estar compuestos por un conjunto de submodelos que representan distintas caractersticas de la organizacin, como procesos,
datos o distribucin de elementos en una fbrica. El propsito de estos modelos es que las
operaciones de una organizacin y su estructura se comprendan y se faciliten el anlisis,
la toma de decisiones o el control de las operaciones de la organizacin. La necesidad de
realizar modelado organizacional en el proceso de IR de SI para organizaciones ha sido
ampliamente reconocida durante las dos ltimas dcadas. Las aproximaciones de IR
basadas en modelado organizacional tienen como propsito entender adecuadamente la
organizacin en la que un SI operar y cmo deber encajar el sistema en la organizacin.
Abordan la estructura de la organizacin, las reglas de negocio que afectan a sus
operaciones, las metas, tareas y responsabilidades de sus miembros, y los datos que se
necesitan, generan y manipulan en la organizacin.
2.2.13. Aproximaciones basadas en UML
Existen varias aproximaciones de IR basadas en modelado organizacional que utilizan
UML como notacin. La razn es que se trata del estndar de facto para el modelado de
sistemas software, con gran aceptacin en la industria, de manera que los analistas de
sistemas estn acostumbrados a su uso. De todas las aproximaciones, se revisan RUP
(Rational Unified Process) (Kruchten, 2003) y la aproximacin para la extensin de UML
de (Eriksson, Penker, 2000).

2.2.13.1.
RUP
RUP es un proceso de ingeniera de software que fue desarrollado y comercializado por
Rational Software y que actualmente pertenece a IBM. Es una aproximacin en la que se
definen, asignan y controlan tareas y responsabilidades para una empresa de desarrollo de
software. Su objetivo es producir sistemas software de alta calidad que se correspondan
30

con las necesidades de sus usuarios finales, dentro de un plazo de entrega y un

presupuesto establecidos.
RUP propone un proceso de desarrollo iterativo. En l existen dos actividades para la
especificacin de requisitos a partir de modelos organizacionales. Estas actividades son el
modelado de negocio y la realizacin del proceso de IR.
El propsito del modelado de negocio es entender la estructura y la dinmica de la
organizacin en la que se ha de implantar un sistema, entender los problemas actuales de
la organizacin e identificar mejoras potenciales, asegurar que los clientes, usuarios y
desarrolladores tienen una visin comn de la organizacin, y derivar los requisitos del
sistema que darn soporte a la organizacin.
2.2.14. Diagramas de Procesos de Negocio (BPD)
En las empresas u organizaciones existentes hoy, la cantidad de personas que participan
es inmensa; junto con ello viene la diversidad cultural, cognitiva, de gnero, entre otros.
Las relaciones que se entrelazan no slo en las unidades funcionales, si no entre las
mismas personas, llevarn a formar una red de interaccin con una alta complejidad. El
departamento de contabilidad interacta con el departamento de desarrollo de software al
asignarles presupuesto o depreciar el equipo de cmputo que usan a diario. En el caso
contrario el departamento de desarrollo de software interacta con el departamento de
mantenimiento para proveerlos de sistemas de informacin que les ayude a llevar control
de su trabajo y el departamento de mantenimiento interacta con el departamento de
contabilidad al programar revisiones de sus equipos de aire acondicionado. Este breve
relato te da a entender entre lneas que los expertos de los distintos departamentos,
aunque lleven relaciones a diario; nada tienen que ver con el trabajo del otro.
Luego, ellos no deben entender el proceso interno de tal o cual departamento y ntese
que, an perteneciendo a una misma organizacin, slo se avizora lo general dejando lo
particular de lado; y no quiere decir que est mal hecho. Es por esto que un Diagrama de
Procesos del Negocio (BPD por sus siglas en ingls) se utiliza para modelar grficamente
las operaciones de los procesos del negocio, de forma que los usuarios que no tenga
instruccin formal en lo que versa el proceso (como ya se explic en prrafos anteriores)
puedan leer y comprender hasta los procesos ms complejos.
2.2.14.1. Elementos de un BPD
Un BPD se estructura a partir de un grupo de elementos grficos base, que son: Objetos
de flujo Objetos de conexin Carriles Artefactos
El resultado de modelar procesos debe ser un producto fcil de manejar/entender pero al
mismo tiempo que abstraiga la complejidad inherente de la consecucin de cualquier
proceso, grande o pequeo.
2.2.14.2. Clasificacin de los procesos de negocios
Los procesos de negocio pueden clasificarse utilizando diversos enfoques.
Segn el nivel de granularidad
Desde este punto de vista, los procesos de negocios pueden calificarse como
organizacionales, cuando describen en el mbito global los procesos de la organizacin y
marcan o delinean grandes objetivos, en contraposicin con los procesos operacionales
31

que presentan un mayor nivel de detalle y suelen concluir en un modelo completo del
proceso de negocio. Claramente los procesos organizacionales representan el primer nivel
de abstraccin posible en el anlisis y los procesos operacionales son la explotacin del
nivel anterior. La aplicacin de metodologas iterativas y evolutivas sobre estos dos tipos
de procesos constituira un modelo de procesos de negocio altamente detallado.
Segn el alcance corporativo
Este aspecto permite clasificar a los procesos de negocios segn se circunscriban a la
organizacin en s misma, o la trasciendan hacia otras organizaciones. Esta clasificacin
identifica procesos intraorganizacionales e interorganizacionales, marcando la diferencia
existente entre orquestacin y coreografa de procesos. Los procesos
interorganizacionales son soportados generalmente por sistemas de gestin de workflow
en su versin tradicional o, en versiones ms modernas, implementados o desplegados
como un conjunto de servicios ejecutados bajo un motor de orquestacin. Los procesos
interorganizacionales requieren una coreografa de procesos donde se requiere establecer
contratos entre las partes que interactan. En el caso en que se deba interactuar con otras
organizaciones, estamos en presencia de coreografa de procesos donde se requiere
establecer contratos con las partes con las que se interacta.
Segn el grado de automatizacin
El grado de automatizacin de un proceso de negocio permitira clasificarlos en
totalmente automatizados, parcialmente automatizados o manuales. Este aspecto tambin
marca el grado de interaccin humana que requiere la promulgacin del proceso. Los
Trabajadores del Conocimiento (actores involucrados en la etapa de administracin)
permiten marcar claramente el prximo paso a seguir para llevar a cabo un proceso, por
lo tanto, a la hora de construir un software es el indicado para determinar el flujo de la
interaccin con el usuario.
Segn el grado de repeticin
Este aspecto permite tener una medida temprana del ROI ( Return Of Investment ) de la
aplicacin de metodologas con enfoque en los procesos de negocio. Cuando el grado de
repeticin es alto, la inversin hecha en su modelizacin y promulgacin esta justificada
ya que habr muchas instancias que cumplen el mismo modelo. En el caso en que no
exista un alto grado de repeticin, como puede suceder con procesos como el diseo de
un avin, se duda acerca de la justificacin de la inversin. En estos casos se puede poner
el foco en modelizar la interaccin entre personas mediante procesos de negocio
colaborativos, donde el objetivo de modelar y promulgar no est en la eficiencia sino en
obtener una traza de su ejecucin para analizar los datos arrojados por la misma.
Segn el grado de estructuracin
Un proceso de negocio estructurado es el que prescribe las actividades a realizar y las
restricciones de ejecucin de una nica manera. Las decisiones que se toman durante la
promulgacin del proceso fueron tomadas en tiempo de diseo. Los workflow de
produccin son un ejemplo de tales procesos. Los procesos estructurados no permiten
saltear actividades no requeridas o ejecutar concurrentemente actividades definidas como
secuenciales. Para dar soporte a estas ideas surge el concepto de actividades ad-hoc,
donde el Trabajador del Conocimiento decide el orden y el momento de su ejecucin
dentro de un proceso. Es en estos casos que adquiere mayor relevancia el uso de BPMS,

32

sobre todo aquellos que incluyen herramientas para realizar monitoreo de procesos (BAM
Business Activity Monitoring ).

2.2.15. modelado de procesos

A partir del mapa de procesos ya construido en etapas anteriores, las necesidades y
requisitos identificadas y especificadas y los casos de uso del negocio descriptos en la
etapa de modelado del negocio, se puede comenzar la etapa de modelado de procesos de
negocio.
Si bien el modelado de los procesos de negocio constituye una de las piezas
fundamentales para desarrollar soluciones con enfoque en los procesos de negocios,
resulta insuficiente abordar solamente el aspecto funcional de tales procesos, debiendo
completarse la perspectiva de los datos que circulan en los flujos. Ms an, desde la
ptica de un enfoque basado tambin en servicios, es indudable que tales servicios
conformarn componentes de software donde los datos deben no solamente ser
modelados sino tambin persistidos e intercambiados entre servicios.
En este marco, se propone desarrollar esta etapa mediante un diagrama de procesos de
negocio (BPD) que se obtiene utilizando BPMN, pero enriquecido con la documentacin
que aportan dos formularios: el de los casos de uso del sistema y el de descripcin de los
objetos de informacin. A los efectos de formalizar y en cierta medida contar con alguna
herramienta de software que ayude a documentar la etapa, definiremos los dos
formularios anteriormente mencionados como diagramas de casos de uso del UML y
diagramas de clase de UML respectivamente. En cuanto a los BPD pueden documentarse
con cualquier herramienta de modelado que soporte BPMN. Existe una gran variedad de
estas herramientas en cuanto al modelado concretamente, muchas de cdigo abierto (la
ms popular es JBPM de JBoss, https://www.jboss.com/products/jbpm/).
Los diagramas de casos de uso documentarn lo que denominaremos casos de uso del
sistema que constituyen un prximo nivel de refinamiento de los casos de uso del
negocio construidos en la etapa anterior. El objetivo de la construccin de estos casos de
uso es lograr una descomposicin del proceso en un conjunto de tareas e identificar los
objetos de informacin y/o documentos que circulan entre las tareas. La definicin de
roles y flujos que del caso de uso aportan documentacin textual al BPD. Por su parte, los
diagramas de clase de UML describen y estructuran los objetos de informacin que
fluyen entre las actividades de un proceso de negocio y representan datos del dominio.
Estos datos del domino constituyen una buena base para crear el modelo de datos
conceptual inicial. Este modelo incluir las entidades y sus relaciones y se describir
mediante un diagrama de clases UML, en el que las entidades se representan mediante
clases (clases del dominio).
As, cada objeto de informacin del diagrama de proceso se convertir en una clase del
sistema informtico. A partir de la especificacin de un objeto de informacin
obtendremos la definicin de la entidad asociada, es decir, sus atributos, relaciones con
otras clases y restricciones. Para apoyar la construccin de estos diagramas de clase, se
extiende el formulario para describir casos de uso y se incluye el diccionario de datos
involucrado en el caso de uso. Este diccionario ser el insumo principal en la
construccin del diagrama de clases y permitir conocer, en una etapa temprana, los
atributos ms importante de cada dato, adems de garantizar su unicidad.
33

La figura 5.6 muestra un ejemplo de formulario para documentar dicho diccionario de

datos.

Por ltimo los diagramas de procesos de negocio representan grficamente las

actividades de un determinado proceso, los actores que las desempean y el flujo de
mensajes que intercambian las actividades. Una vez obtenido el modelo de procesos se
encuentra el terreno propicio para identificar los elementos (servicios) que realizarn los
procesos de negocios, transformndose estos ltimos en consumidores de dichos
servicios.

34

CAPITULO III: INTEGRACION BPMN-UML

La utilizacin de modelos entendibles y estandarizados. La notacin de modelo de
procesos empresariales, nombrado BPMN por sus siglas en ingles y el lenguaje de
modelado unificado, por sus siglas en ingles UML, son dos lenguajes de modelado que
complementan el levantamiento de requerimientos
3.1. El Lenguaje de Modelado Unificado (UML) y la metodologa del Proceso
Racional Unificado (RUP) en el modelado de procesos del negocio
En el Lenguaje de Modelado Unificado (UML, por sus siglas en ingls) y la metodologa
del Proceso Racional Unificado (RUP, por sus siglas en ingls), se presenta una nocin
para el modelado de negocio que sintetiza el proceso estndar ms utilizado para el
anlisis, diseo y documentacin de sistemas, apoyado en el ciclo de vida del Anlisis y
Diseo Orientado a Objetos, el cual permite modelar a una organizacin desde diferentes
puntos de vista con el fin de identificar qu actividades son clave en el nivel de
desempeo de su operacin (Garca, 2000). En este sentido el objetivo de la investigacin
se encamina en alinear los procesos identificados como claves en el negocio con los
procesos del sistema que se pretenda implementar.
Muchas organizaciones para documentar un negocio utilizan el mtodo tradicional, que
consiste en dibujar un mapa de la organizacin, que divide la empresa en un nmero de
departamentos o secciones como por ejemplo, produccin, mercadotecnia, ventas,
investigacin y desarrollo entre otros. Esta tcnica, pese a ser simple, no ofrece en su
propia naturaleza una visin global de la organizacin, de manera que la documentacin
desarrollada con frecuencia cae en los extremos de ser redundante, contradictoria o
inexistente.
La Notacin para el Modelado de Procesos de Negocios (Business Process Modeling
Notation) es una iniciativa mantenida actualmente por la Object Management Group, Inc.
(OMG), la cual ha sido usada para el modelado en el proceso de negocio, el cual describe
las actividades clave de la organizacin y cmo se relacionan e interactan con los
recursos del negocio para lograr la meta establecida para el proceso. Sin embargo, este
ideal de abstraer la realidad mediante un modelo no est exento de ciertas
consideraciones.
Un modelo de negocio nunca puede ser totalmente exacto o completo, simplemente
porque ninguno de los posibles observadores de un negocio tendr una percepcin
idntica o estar de acuerdo con un modelo exacto. El modelo debe concentrarse en las
tareas y mecanismos clave principales del negocio. Determinar con precisin las tareas
principales e identificar qu debe plasmarse en el modelo es responsabilidad del
modelador, lo que implica una cierta proporcin de subjetividad. Igualmente, el modelo
de una vista futura de un negocio no necesariamente va a realizarse tal como se plane.
Los cambios en el mundo real pueden afectar la base sobre la que el modelo fue creado
quedando ste como algo incompleto (Hernndez, 2005). Pese a estas limitaciones, los
siguientes argumentos para producir modelos de negocio apoyan su existencia:
Permiten comprender mejor los mecanismos clave de un negocio existente: Se debe
proveer una imagen clara de sus roles y tareas en la organizacin global, los modelos

35

pueden ser usados para entrenar a las personas. Pueden ser usados tanto en una
organizacin jerrquica como en una organizacin orientada a procesos.
Actan como base para crear sistemas de informacin: Las descripciones de negocio
son usadas para identificar el apoyo de sistemas de informacin a los principales
procesos de la organizacin. Los modelos tambin son usados como una base para
especificar los requerimientos clave de esos sistemas.
Facilitan la identificacin de ideas para mejorar la estructura actual del negocio y su
operacin: Los modelos permiten identificar situaciones susceptibles de ser
mejoradas, la construccin de un modelo implica un proceso reflexivo del porqu se
hacen las cosas como se hacen, de manera que pueden visualizarse cambios en el
negocio actual que son necesarios para implementar el modelo mejorado.
Para experimentar con un nuevo concepto de negocio: Un modelo es una entidad
conceptual de bajo costo sobre la cual pueden hacerse ciertas pruebas para validar su
operacin, lo que los hace ser un medio para la adopcin de mejores prcticas
inspiradas por otros modelos de negocios exitosos. Tambin permite tomar ventaja
mediante la adopcin de nuevas tecnologas, tales como las relacionadas con Internet.
Para identificar oportunidades de Outsourcing: Los elementos del negocio no
considerados como parte central, son delegados a proveedores externos. Los modelos
son usados como especificacin para los proveedores.
Para mostrar la estructura de un negocio innovado: Los modelos sirven para presentar
ante la gerencia la nueva propuesta de trabajo, de manera tangible y concreta. A partir
de este punto es posible definir nuevas acciones, entonces los modelos se vuelven la
base para los planes de accin que apoyarn la transformacin del negocio.
Es por ello que esta situacin se convierte en una oportunidad para aplicar herramientas
de modelado de negocios BPMN y obtener una visin global, que bajo esquemas
tradicionales pueden llegar a pasar desapercibidos.
Un buen modelo de negocio contiene informacin sobre objetivos, entradas, salidas,
recursos, actividades y eventos. Mediante la identificacin, captura y documentacin de
esta informacin se puede conformar la base para especificar los requerimientos de un
sistema de informacin que apoye al proceso para la toma de las mejores decisiones en un
negocio o como en este caso se plantea, de una organizacin de carcter educativo
(Sparks, 2000).

3.2. BPMN Vs. UML y su Integracin

El advenimiento de BPMN, BPMS y sus lenguajes de ejecucin no deja obsoleta la
necesidad de desarrollos de sistemas, como los que se logran utilizando UML (Unified
Modeling Languaje ). Los desarrollos de sistemas siguen teniendo un rol importante en la
arquitectura de procesos en el mbito empresarial, como se ha indicado que UML es un
lenguaje que facilita a los desarrolladores la especificacin, visualizacin y
documentacin de modelos de sistemas de software y fue desarrollado como un medio
para mejorar el proceso de desarrollo de software, desde el diseo de la arquitectura hasta
la implementacin de la aplicacin, y sobre todo para ser utilizado por personas con
conocimientos tcnicos (analistas de sistemas y programadores), sin embargo BPMN est
dirigido a los analistas de negocio, arquitectos de sistemas e ingenieros de software y ha
36

sido desarrollado para mejorar todo el ciclo de vida del desarrollo de procesos desde el
diseo de los mismos.
UML define un nmero de diagramas que se pueden clasificar en las siguientes
categoras: estructura esttica de la aplicacin,
comportamiento dinmico y
administracin y organizacin de soluciones de software. De estas tres categoras, el
comportamiento dinmico es el utilizado para modelar los procesos de negocio; los
diagramas asociados son el de actividad UML y los de casos de uso. BPMN est
emparentado con UML por el hecho que ambos definen una notacin grfica para los
procesos de negocio similar a los diagramas de comportamiento de UML. Sin embargo,
BPMN y UML usan enfoques muy diferentes para modelar procesos de negocio. Si bien
los diagramas de actividad constituyen la herramienta UML para modelar actividades de
procesos, UML, en general, ofrece un enfoque orientado a objetos para modelar
aplicaciones. Mientras que BPMN toma un enfoque centrado en los procesos. Este
enfoque es mucho ms natural e intuitivo para los analistas de negocios. Con BPMN, el
control y los mensajes de flujo entre procesos son primeramente modelados. Luego, se
definen implcitamente los modelos de objetos para los procesos en vez de hacerse
explcitamente como en UML. BPMN tambin ofrece la opcin de explicitar el modelado
de objetos de negocio que pueden ser expuestos a travs de servicios de negocio en el
flujo del proceso.
El uso del BPMN para el anlisis de requerimientos es definido como un diagrama de
actividades con caractersticas nuevas. Trabajar en conjunto los casos de uso y la notacin
BPMN es un trabajo que ya se ha realizado, pero no se le ha tomado en cuenta la gran
importancia que representa para la organizacin, ya que esta integracin muestra como
vincular un caso de uso por cada proceso o actividad en un BPMN y su enfoque es
establecer pre-condiciones, pos- condiciones y triggers, para generar automticamente un
BPMN, sobre sta base se puede pensar en otro tipo de estructuracin que relacione los
modelos de BPMN, los casos de uso y los requerimientos, realizando una trazabilidad
desde el punto de vista del negocio. As se tiene que Alistair Cockburn menciona otras
posibilidades de adaptacin de los casos de uso de acuerdo a la comodidad que sientan
los involucrados, dentro de estas adaptaciones se puede considerar que el BPMN es
considerado una evolucin del diagrama de actividades. Los casos de uso de negocio son
documentados usando diagramas de actividades, basndose siempre en los procesos de
negocio.

3.3. RELACIONANDO REQUERIMIENTOS, BPMN Y CASOS DE USO

En un proceso de anlisis de requerimientos de software, que est enmarcado en el
cumplimiento de los lineamientos dados por una arquitectura empresarial, los modelos de
BPMN pueden considerarse como una herramienta importante aunque no la nica a la
hora de entender y plasmar el proceso de negocio [9], esto cobra importancia cuando es
necesario entender y ubicar los requerimientos de software en un modelo de BPMN
asociado a el negocio mismo de la organizacin.
Los requerimientos de software muestran las caractersticas que deber tener un sistema de
informacin, los requerimientos deben reflejar las necesidades de los usuarios que sern
solucionadas por l, pero es difcil presentar una relacin con los procesos de negocio, es
decir que no se tiene una forma de alinear los requerimientos de software a los procesos de
37

negocio y los involucrados en los procesos de negocio no ven como sus propios
requerimientos pueden afectar los procesos o el sistema de informacin en s. Si se realiza
un levantamiento de requerimientos describiendo un proceso de negocio, a travs del caso
de uso se debe tener en cuenta que los casos de uso se pueden describir como una posible
secuencia de pasos en las que el usuario y el sistema interactan, para llegar a un objetivo
especfico, con esta definicin se puede considerar modelar los procesos de negocio
mediante casos de uso, pero no es fcil establecer un orden a las actividades, o como la
informacin se trasmite entre los actores.
Los casos de uso se enfocan en uno o varios escenarios en los que el usuario interacta
con el sistema, estos escenarios representan un solo instante, mientras que la temporalidad
de las acciones puede ser ubicada por medio de BPMN.
Los tres aspectos: BPMN, casos de uso y requerimientos, pueden ser combinados para
realizar una especificacin de requerimientos exitosa, la cual refleje una alineacin a las
necesidades de la empresa de acuerdo a su estrategia. Pero su combinacin implica
realizar un anlisis que este documento pretende simplificar, esta combinacin se puede
encontrar de manera formal en un Escenario de Negocio. Los escenarios de negocio,
describen un conjunto de procesos, aplicaciones y personas que actan en ellos, uno de sus
principales beneficios es el entendimiento completo de los problemas del negocio y la
participacin activa de los involucrados, esta tcnica es considerada clave para entender
los objetivos del negocio en un proceso de levantamiento de requerimientos. La definicin
del escenario de negocios puede involucrar BPMN para definir proceso. Las aplicaciones
y personas pueden representarse con casos de uso, los requerimientos pueden ser ubicados
en el diagrama BPMN para entender su importancia e interaccin entre participantes, as
como para asegurar la trazabilidad de los requerimientos desde el negocio hacia el
producto de software.
LEVANTANDO REQUERIMIENTOS
Un proceso de levantamiento de requerimientos puede iniciarse plasmando el estado
actual del negocio, identificando la duracin actual de las actividades, el alcance del
proceso, indicadores de gestin KPI (Key Performance Indicators, Indicadores Clave de
Desempeo) y los lmites del proceso, en esta etapa se comienzan a plantear las
necesidades generales que son transversales a todo el proceso, en algunos casos estas
necesidades pueden generar requerimientos que signifiquen la automatizacin de las
actividades que requieran la integracin con otros aplicativos ya existentes para generar
un intercambio de informacin, los requerimientos deben ir asociados a los involucrados
en el proceso para saber cuanto puede abarcar un requerimiento en trminos de quienes
intervienen y que otras actividades pueden estar relacionadas.
Es necesario detallar las actividades del proceso indicando en resumen la descripcin de la
actividad y teniendo en cuenta caractersticas como: si la actividad se apoya en un sistema
de informacin, identificar las tareas humanas del proceso, los datos e informacin que
conforman las entradas y salidas de cada actividad, el procesamiento y transformacin de
las mismas. De lo anterior se obtiene un modelo de BPMN y los requerimientos asociados
al proceso de negocio modelado, que pueden ser transversales a este o estar inmersos en
diferentes etapas del proceso, estos requerimientos son importantes para los involucrados
en el proceso de negocio.

38

Tambin se definen reglas de negocio para las actividades que conforman el proceso de
negocio. Este nivel de granularidad es bastante alto y ayuda a los interesados a entender a
alto nivel las necesidades del negocio y los requerimientos tecnolgicos asociados al
proceso, esta vista puede verse en un Framework de Arquitectura Empresarial como
ZACHMAN en el que se intercepta el punto de vista del negocio y el saber cmo se hace.
Tomando el modelo BPMN, con los requerimientos y las reglas de negocio, se puede
hacer una categorizacin de los requerimientos de acuerdo a los participantes a quienes les
interesa cada requerimiento, para esta categorizacin se toman los participantes en el
proceso, los cuales pueden tener inters en varios requerimientos, estos pueden
contextualizarse en diferentes actividades del negocio, sin embargo, muchos de estos
pueden ser compartidos o se complementan entre s, por ejemplo a los cargos directivos de
las empresas les interesa dar su aprobacin en etapas claves del proceso mientras que a los
ejecutivos les interesa notificar que su trabajo termino de acuerdo al proceso. Las reglas de
negocio deben ser documentadas y asociadas a las actividades o son plasmadas usando el
lenguaje BPMN como por ejemplo: gateways, mensajes, etc.
Estas reglas constituyen restricciones y comportamientos en las actividades que deben ser
tomados en cuenta, para ms adelante plantear los escenarios de cada actividad. En la
Figura 1 se toma un proceso de negocio modelado con BPMN, por otra parte se tiene una
clasificacin de requerimientos R1, R2, R3, R4 y R5, los requerimientos son categorizados
en diferentes lanes, que corresponden a diferentes participantes en el proceso, se puede
observar que los participantes pueden compartir diferentes requerimientos, de esta manera
se asocian requerimientos, procesos y participantes, en este caso se pueden considerar con
reglas de negocio el envi de mensajes entre los lanes.

39

Para avanzar en el proceso de especificacin, se pasa a un nivel de granularidad ms

detallado, en el cual se muestran los escenarios derivados de las actividades del BPMN,
los servicios y la interaccin de los participantes en el proceso, para esto el modelo BPMN
debe tener una descripcin clara y detallada de las actividades, as como los pormenores
de los eventos, los gateways, los subprocesos, etc. En este punto se pueden identificar las
actividades o eventos que pueden generar uno o varios casos de uso. Esta identificacin
puede empezarse con las tareas humanas como se muestra en la Figura 2.
La relacin de tareas humanas con casos de uso se ha hecho en diagramas que representan
procesos de negocio workflows, en los trabajos de [13] y [18] se puede ver que los casos
de uso relacionados con BPMN. Se deben tener en cuenta las relaciones de Include
(inclusin) y Extend (extensin) que puede tener los casos de uso. Estas relaciones se dan
a partir de actividades subsiguientes, eventos, gateways, pre-condiciones y poscondiciones que se descubren al formalizar el caso de uso, apoyados tambin en las reglas
de negocio documentadas, para saber cul es la relacin que se debe aplicar, o si es
necesario crear nuevos casos de uso, se debe tener en cuenta la definicin de la notacin
BPMN junto con un anlisis que permita determinar la relacin o creacin de un nuevo
caso de uso. El analista de requerimientos finalmente ser quien determine los casos de
uso y las relaciones que se generan. Por ejemplo: los eventos pueden ser parte del flujo
normal del caso de uso cuando se trata de enviar un mensaje, pero puede ser una
excepcin cuando el evento es una compensacin (reglas y actividades para deshacer una
tarea en caso de que esta falle o se genere una excepcin). Para continuar el anlisis
multidimensional los requerimientos y las actividades del BPMN, se generan los casos de
uso, estos crean escenarios detallados para que los involucrados pueden valorar y observar
la solucin a sus necesidades. A travs de un diagrama de procesos, ven reflejado su da a
da y los escenarios describen como un sistema de informacin puede mejorar su proceso
actual, esto le da sentido al modelado de negocio logrando un entendimiento comn entre
usuarios, desarrolladores, e interesados de la organizacin. De esta manera se obtiene una
jerarqua de requerimientos que van desde los caso de uso de negocio que puede ser
descritos en detalle usando el BPMN, los requerimientos de usuario como se mostr en la
40

primera parte asociados a los participantes del modelo a requerimientos particulares

(representados en casos de uso), y por ltimo los requerimientos de sistema, generados a
partir de los casos de uso en las actividades del BPMN. Todo esto genera una trazabilidad
vertical de los requerimientos, los casos de uso y el modelo de negocio, desde el punto de
vista de la arquitectura empresarial en un Framework como Zachman cobra importancia
relacionar estas vistas, dando valor agregado a los involucrados.

3.4. APLICACIN DE LA INTEGRACION BPMN-UML/RUP

Ambos conceptos, BPM y UML, se ven relacionados a travs de la notacin grfica
BPMN y de los Diagramas de Actividades y Casos de Usos, que cmo se ver son dos
maneras de controlar el comportamiento de los procesos, realizando una aproximacin a
travs de la correspondencia entre los smbolos de la notacin.
Cmo caso de aplicacin se incluye un ejemplo sobre catalogacin y consulta de artculos
donde se puede ver esta relacin, llamado Portal de Revistas (caso tomado de la
investigacin PROYECTO FIN DE MASTER EN PROGRAMACIN Y
TECNOLOGA SOFTWARE de Laura Henche Grande).
CASO: Portal de revistas cientficas
a) Definicin del sistema
Los diferentes departamentos de la universidad editan publicaciones en papel con
trabajos, investigaciones, etc. que realizan sobre la materia que en cada caso les compete.
El Servicio de Publicaciones en colaboracin con la Biblioteca ha decidido comenzar con
la digitalizacin de dicho material con dos ideas fundamentales: la preservacin y
difusin de dicho material a la comunidad universitaria.
En la actualidad se cuenta con ms de 60 revistas digitalizadas, realizndose archivos
independientes a nivel de artculo. Se han digitalizado todos los nmeros disponibles de
cada una de las revistas y el proceso de digitalizacin de los nuevos nmeros seguir de
forma continuada en el tiempo. El formato elegido para publicar esta informacin es el
formato .pdf
As pues, el objetivo principal del proyecto consiste en desarrollar una aplicacin que
permita:
1. La catalogacin (preservacin) de los ficheros pdf obtenidos de la digitalizacin de
artculos de revista,
2. La consulta (difusin) de los contenidos generados a travs de la catalogacin
anterior.
b) Establecimiento de requisitos
Requisitos funcionales que afectan al modelo de base de datos
Un artculo pertenecer exclusivamente a una de las clases definidos. Un artculo puede
estar escrito por uno o ms autores. Un autor puede publicar uno o ms artculos. El
nombre del fichero identifica de forma unvoca un artculo (ver ejemplo de codificacin
ms adelante). Un artculo slo pertenece a un fascculo. Un fascculo slo pertenece a
una revista. El anejo es un tipo de fascculo. Se utilizar como identificador de fascculo
al que pertenece el artculo los 16 primeros caracteres del nombre del fichero. Los cuatro
primeros caracteres del nombre del fichero se utilizarn como identificadores de la revista
41

a la que pertenece el artculo. Las revistas proceden de un centro. Una revista pertenece
a una materia principal. Las materias principales estn agrupadas en 4 reas:
humanidades, ciencias, ciencias de la salud y ciencias sociales. Un artculo se describe
por una o ms materias secundarias.

Formato del nombre del fichero para los artculos

A continuacin se muestra un ejemplo de cmo codificar el nombre del fichero PDF de
un artculo:

Requisitos de seguridad
El acceso es abierto, sin embargo algunas revistas tendrn un periodo de embargo en los
ltimos nmeros. El fascculo no se ver hasta que dicha fecha se haya cumplido.

42

 Funcionalidades
La aplicacin contar con tres mdulos:
1. Mdulo de catalogacin
Se encarga de recolectar y almacenar los metadatos referentes a las revistas y a los
artculos disponibles. Desde la catalogacin se podrn realizar las operaciones de:
- Aadir una nueva revista
- Modificacin de los datos de las revistas
- Modificacin de los datos de los artculos
- Modificacin de los datos de los fascculos
- Dar de alta nuevos artculos en una revista
- Envo de alertas donde se avisa al usuario de las nuevas publicaciones

El orden en el que se realizan las operaciones de catalogacin es importante ya que para

aadir nuevos artculos a una revista, sta debe estar dada de alta con anterioridad y
preferiblemente con toda su informacin completa, pues de lo contrario no se podr tener
acceso a ella a travs del portal. Durante el proceso de carga de los artculos tambin se
realiza la incorporacin del fascculo al que pertenece, en caso de que an no est dado de
alta. Es por eso que los pasos siguientes son los de catalogar a los artculos cargados y al
fascculo generado si ste fue creado durante la carga. Solo despus de todo este proceso
se puede considerar al fascculo por finalizado, permitiendo el envo de las alertas con las
novedades a los usuarios suscritos.

43

2.

Mdulo
de
consulta
Permite consultar las revistas y artculos catalogados. Se pueden diferenciar dos
submdulos:
2.1 Portal de revistas
Permite el acceso a todas las revistas. Se podrn realizar bsquedas por revistas sobre los
metadatos. Tambin se podrn listar las revistas alfabticamente, por rea o por materia.
2.2 Acceso a la revista
Al entrar en la revista se podr acceder a todos sus fascculos, as como realizar
bsquedas en los artculos de dicha revista. Dispondr de un ndice alfabtico por autor y
otro por ttulo de todos sus artculos. Los usuarios adems podrn suscribirse a la revista
para mantenerse informado de las novedades en sus publicaciones.

44

El modo habitual para acceder a un artculo comienza por entrar en el portal de revistas y
buscar la revista que se desea consultar a travs de los listados o bien buscando por
palabra clave. Una vez dentro de la revista se busca el artculo por palabra clave o a
travs de los ndices de ttulo y autor o accediendo a los fascculos que forman la revista.

3.

d
u
l
o

del sistema
El sistema ejecuta diariamente una tarea programada para actualizar el embargo de todos
los fascculos. Se calcula sumando los meses de embargo que tiene asignada la revista a
la fecha de publicacin del fascculo y comprobando si se ha superado la fecha actual.

Adems semanalmente genera los ndices con los ttulos de los artculos y los autores
para cada una de las revistas.

c) Diseo del sistema: diagramas de actividades en UML y BPMN

A continuacin se muestran los diagramas en UML y BPMN de tres procesos que se
usaron como gua durante la implementacin del proyecto.

1. Dar de alta una nueva revista

45

Para dar de alta una revista primero se han de introducir algunos datos representativos,
como el cdigo que la identifica, el ISSN asignado, su nombre y el centro que la pblica.
Todos los valores han de ser comprobados porque en el caso de que alguno no sea
correcto se rechaza el proceso de alta, pero la comprobacin ms importante que debe
hacerse es la de corroborar que el cdigo asignado sea nico, es decir, no est concedido a
otra revista. Solo si cumple con todos los requisitos se procede a guardar los datos en la
base de datos. Este procedimiento se representa grficamente a travs de los siguientes
diagramas:

2. Catalogar Fascculo
Un proceso algo ms complicado es la catalogacin de un fascculo que ya existe. Lo
primero que se hace es buscarlo de entre los aadidos a la revista a la que pertenece. Una
vez seleccionado se permite modificar cualquier dato que ya tuviera guardado, pero para
la consistencia de la base de datos hay que tener en cuenta que si se produce algn
cambio en el ao, volumen o nmero, el nombre del fichero que identifica al fascculo y a
sus correspondientes artculos cambia, pues estn formados por la concatenacin de stos
(ver formato del nombre de los artculos), por lo que debern ser todos actualizados.
46

Adems se debe recalcular el embargo si la fecha de publicacin es modificada. Cuando

la catalogacin del fascculo se d por finalizada, lo que tambin incluye el que sus
artculos hayan sido catalogados, hay que enviar el correo con toda la informacin a los
suscriptores. Los diagramas que lo representan en formato grfico:

47

48

3. Cargar artculos en una revista

Otro procedimiento interesante es el de aadir nuevos artculos. Lo primero que hay que
hacer para realizar la carga en una revista ya seleccionada es indicar el fascculo al cual
pertenecen los artculos. Si ya existiera, los ficheros con los artculos seleccionados irn
asociados a ese fascculo; sino, un nuevo fascculo ser dado de alta. En este ltimo caso
es obligatorio introducir la fecha de publicacin para calcular el embargo, antes de que
los artculos se guarden en la base de datos, evitando que se hagan pblicos antes de
tiempo. Inicialmente es suficiente con indicar las pginas de inicio y fin en cada uno de
los artculos, ya que el resto de datos se rellenarn durante el proceso de catalogacin. Si
los valores son correctos entonces se guardan los datos de los artculos y del fascculo si
no exista previamente.
A continuacin se muestra grficamente el proceso con diagramas. Merece la pena indicar
que en el caso de BPMN se incluye el subproceso compuesto Guardar Artculos, que
podra ejecutarse con mltiples instancias en paralelo, cada una con un artculo, y que
solo alcanzara la siguiente actividad si todos los artculos se guardan correctamente.

49

50

CONCLUSIONES

Un diagrama de procesos de negocio (BPD) describe el funcionamiento del proceso,

mientras que el mapa del proceso de negocio es una representacin grfica en
trminos del funcionamiento de la organizacin y describe cmo se articula el
funcionamiento de la empresa para dar lugar al objetivo del negocio.
Los procesos de negocios trascienden la estructura organizativa y la atraviesan e
implica un fuerte nfasis en cmo el trabajo es realizado dentro de una organizacin o
entre organizaciones en contraste al acento en el qu, en el enfoque orientado a
producto.
Las actividades de los procesos son responsabilidad de personas o reas de empresas,
incluso si son automatizadas. Las polticas empresariales y las reglas de negocio se
establecen para determinar cmo debe actuar la empresa para cumplir sus objetivos,
respondiendo a estrategias preestablecidas. Estas reglas son de aplicacin en los
distintos pasos de un proceso.
La integracin investigada incluye la actualizacin, revisin y complecin de
documentacin tcnica y funcional (Procesos de negocio, Casos de Uso detallados,
diagramas UML, Artefactos de Modelado, Documentos de arquitectura, Artefactos
testing, etc.) de acuerdo a las mejores prcticas recomendadas por RUP bajo los
estndares BPMN y UML.
La gran mayora de las organizaciones no representa esquemticamente cmo son sus
procesos y aquellos que s lo hacen, slo lo consideran implcitamente o bien de una
manera incompleta.

3) REFERENCIAS
a) Bibliografa
1. Beatriz Mora, Francisco Ruiz, Flix Garca, Mario Piattini. Experiencia en
transformacin de modelos de procesos de negocios.
2. C. Pons, R. Giandini, G. Prez. Desarrollo de Software Dirigido por
Modelos. Conceptos tericos y su aplicacin prctica. 1er. Edicin. EDULP
& McGraw-Hill Educacin. (2010). ISBN: 978-950-34-0630-4
3. Howard, S. F., Peter 2003, Business Process Management: The Third Wave.
4. Laura
Henche
Grande.
Introduccin a la notacin bpmn y su relacin con las estrategias del lenguaje
maude.
5. Moreno Juan J. BPMN Gua de Referencia y Modelado Comprendiendo y
Utilizando BPMN.
6. UML-OMG, Unified Modeling Language: superstructure v. 2.0. (2005).
7. Hernndez, E. (2011). El Lenguaje Unificado de Modelado (UML).
Universidad Politcnica de Valencia, Departamento de Informtica y
Sistemas Computacionales. Recuperado el 06 de octubre de 2011 de:
http://www.disca.upv.es/enheror/pdf/ActaUML.PDF
51

8. Len, O. y Asato, J. (2009). La Importancia del Modelado de Procesos de

Negocio como Herramienta para la Mejora e Innovacin. Revista Panorama
Administrativo. 7(4). 61 7. Podeswa, H. (2010). UML for the it business
analyst. USA: Course Technology.
9. Sparks, G. (2011). Introduccin al modelado de sistemas de software usando
el Lenguaje Unificado de Modelado (UML): El Modelo de Proceso de
Negocio. Craftware.net. Recuperado el 06 de octubre de 2011 de:
http://www.craftware.net/es/descargas/modelo_de_proceso_de_negocio.pdf
10. Havey, M. (2005), Essential Business Process Modeling, O'Reilly Media, Inc.
Prescription for a Good BPM Architecture, captulo 2.
Webgrafa
1.

Leymann, F. R., D.; Schmidth, M.-T. 2002, 'Web services and business
process management', IBM Systems Journal, vol. 41, no. 2, p. 8.
[http://www.research.ibm.com/journal/sj/412/leymann.html](7 Enero 2008)

2.

Grotevant S. M. 1998, Business Engineering and Process Redesign in

Higher
Education:
Art
or
Science?,
[http://www.educause.edu/ir/library/html/cnc9857/cnc9857.html](17
de
Enero 2008)

3.

Wikipedia 2008, Information Technology Infrastructure Library,

[http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Librar
y] (2 de fbrero 2008).

4.

Keber, B. t. 2006, Business Process Management in Telekom Slovenije,

[http://www.telekom.si]
[http://www.tmforum.org/browse.aspx?
catid=2212&linkID=33035&docID=6386 (8 de Enero 2008).

5.

J. Gallardo, O. Marbn, C. Meneses, A. Quelopana: El Modelo de

Negocio Decisional como origen de Especificacin de Requisitos en
Proyectos de Data Mining: Una Aproximacin Metodolgica Mediante
Framework i*.

52