COMPLEJIDAD EN MODELOS CONCEPTUALES DE PROCESOS DE NEGOCIOS. PROPUESTA DE MéTRICAS DE CALIDAD DE MODELOS CONCEPTUALES DE PROCESOS
BUSINESS PROCESS MODEL COMPLExITY. A PROPOSAL OF qUALITY METRICS OF CONCEPTUAL BUSINESS PROCESS MODEL
AUTOR
RICARDO MÉNDEZ L.
Magíster© en Ciencias de la Computación
Universidad Católica del Maule
ricardo.mendez@econtinuum.cl
CHILE
AUTOR
ANGÉLICA URRUTIA
Doctora en Ingeniería Informática
Universidad Católica del Maule
*Departamento de Computación e Informática,
aurrutia@ucm.cl
CHILE
*INSTITUCION
Universidad Católica del Maule
Talca, Chile
Institución Universitaria
Avenida San Miguel 3605, Talca Chile.
INFORMACIÓN DE LA INVESTIGACIÓN O DEL PROYECTO: Este trabajo forma parte de los resultados obtenidos de la investigación realizada para la tesis de magíster en ciencias de la computación, Universidad Católica del Maule, Chile.
RECEPCIÓN: Septiembre 27 de 2016
ACEPTACIÓN: Noviembre 28 de 2016
TEMÁTICA: Business Process Management (BPM)
Forma de citar: Mendez. R. (2016). Complejidad en modelos conceptuales de procesos de negocios. En R, Llamosa Villalba (Ed.). Revista Gerencia Tecnológica Informática, 15(43), 47-62. ISSN 1657-8236.
RESUMEN
Los procesos de negocios constituyen un factor clave para el éxito las organizaciones, actualmente el interés en los procesos de negocios por parte de las organizaciones ha crecido de la mano del surgimiento de un sin número de herramientas para el modelado. Analistas, ingenieros de procesos y de software consideran el modelo conceptual de procesos como un insumo que ayuda a la visibilidad, comprensión del negocio e implementación tecnológica, sin embargo, no hay un consenso respecto de que constituye un modelo de procesos de calidad. En este trabajo tiene como propósito contribuir en el estudio de calidad de los modelos conceptuales de procesos desde la perspectiva de la complejidad, se pretende establecer que la complejidad de los modelos afecta el entendimiento de los procesos, dificulta su adaptación y posterior implementación. Actualmente, existen trabajos relacionados con el estudio de la complejidad de los modelos de procesos, En este trabajo se pretende contribuir en el desarrollo de esta dimensión de la calidad de los modelos procesos, centrado en el estudio de casos reales de modelos de procesos en notación BPMN. Se proponen algunas métricas para medir la complejidad de los modelos procesos, y como estas nuevas mediciones inciden en el entendimiento y comprensión de los mismos.
Palabras clave: BPMN, modelado de procesos, complejidad, métrica, procesos de negocios
ANALYTICAL SUMMARY
Processes are a key factor for the success of the organizations, currently the interest in the business processes by organizations has grown out of the hand of the emergence of several tools for modeling. Analysts, process engineers and software consider the conceptual model of processes such as an input that helps the visibility, understanding of the business and technological implementation, however, there is no consensus that constitutes a model of quality processes. In this Paper, has as purpose to contribute in the study of quality of the conceptual models of processes from the perspective of the complexity, we intend to establish that the complexity of the models affects the understanding of processes, hinders their adaptation and subsequent implementation. There are currently work related to the study of the complexity of the process models, this paper aims to contribute in the development of this dimension of the quality of the models processes, focused on the study of actual cases of process models in BPMN notation. It is proposed some metrics to measure the complexity of the models processes, and as these new measurements affect the understanding of the same.
Keywords: BPMN, business process modeling, complexity, metric, business process.
INTRODUCCIÓN
El modelado de procesos de negocios se ha
transformado en una actividad esencial en las
organizaciones, el creciente interés del modelado de
procesos ha contribuido a la aparición de una variedad
de herramientas y notaciones que han permitido a las
organizaciones de distinta índole diseñar sus procesos.
Entre las notaciones de modelado de procesos, BPMN se
ha ido convirtiendo en el estándar de facto de la industria;
la popularidad de BPMN se debe a las innumerables
herramientas disponibles que implementan la notación,
adicionalmente la facilidad de uso de la notación para el
modelado. La expresividad de BPMN permite construir
modelos con alto grado de representación de la realidad,
sin embargo, esta expresividad en algunas oportunidades
produce modelos con un alto nivel de complejidad. Este
aumento de la complejidad de los modelos de procesos
implica dificultad para su entendimiento y mantención
[1].
La complejidad en los modelos de procesos ha sido
estudiada en [2, 3, 4, 5], en estos trabajos se presenta
una visión respecto de la complejidad y como esta
puede afectar de manera significativa la comprensión
de los modelos de procesos, dificultando la mantención.
Es deseable establecer las propiedades en los modelos
de procesos que ayuden a los analistas, ingenieros
de procesos a diseñar modelos con bajos niveles de
complejidad; este trabajo pretende contribuir en el
desarrollo, aplicación y profundización de los criterios
de calidad desde la perspectiva de la complejidad en los
modelos de procesos.
Este trabajo está organizado de la siguiente manera:
en la sección 1 se presentan los conceptos básicos.
En la sección 2 se presenta discusión bibliográfica con
los diferentes trabajos relacionados con la complejidad
de los modelos procesos. En la sección 3 se presenta
la formulación de la investigación, las preguntas de
investigación y las limitaciones de trabajo. En la sección
4 se presenta el diseño del experimento. En la sección 5
se presentan los resultados experimentales. En la sección
6 se presenta el análisis y discusión del experimento.
En la sección 7 se presenta las conclusiones y trabajos
futuros. En la sección 8 se presenta los agradecimientos
y finalmente en la sección 9 se presentan las referencias
bibliográficas utilizadas en este trabajo.
1. CONCEPTOS BÁSICOS
1.1 MODELADO DE PROCESOS DE NEGOCIOS
El modelado de procesos de negocios se está
transformando en un área de gran importancia y su
historia nace el año 1992. Es considerada una práctica
central dentro de la Gestión de Procesos de Negocios
(BPM) [6].
El modelado puede ser entendido como una
representación gráfica y simbólica de un asunto de
interés por medio de diagramas y otros artefactos.
Los Modelos son simplificaciones en orden a mantener
claridad y entendimiento sobre algún aspecto de un
problema donde hay complejidad, incertidumbre,
cambios o suposiciones [8].
El modelado de Procesos de Negocios debe ser entendido
como un proceso que tiene como finalidad la obtención
de un artefacto que permita entender, visibilizar y
comunicar a los distintos agentes interesados del
funcionamiento del negocio. Este modelado constituye
un insumo de gran utilidad para las distintas partes
interesadas del negocio, Gestores de Negocios, Analistas
de Procesos, Ingenieros de Procesos, Ingenieros de
Software. El modelado de PN es considerado como el
primer artefacto de software [6].
1.2 MODELOS DE CALIDAD DE PROCESOS DE NEGOCIOS
La definición clásica de Calidad en los Modelos fue propuesta en [7]. “Define un conjunto de características y relaciones entre ellas, que proveen un marco de trabajo para especificar los requerimientos de calidad y su evaluación”.
En el contexto del Modelo Conceptual de los Procesos de
Negocios (MCPN) no se puede precisar con exactitud si
un MCPN tiene un alto nivel de calidad o no, en muchas
ocasiones la calidad depende del observador del modelo,
para algunos analistas un MCPN puede presentar un
nivel alto de calidad, sin embargo, para otros puede que
ese no sea el caso. Es por esta razón que es complejo
precisar el nivel de calidad de MCPN. De todas maneras
los investigadores coinciden que es necesario desarrollar
modelos de calidad que permitan medir y establecer los
niveles de calidad MCPN. La importancia de desarrollar
modelos de calidad de Procesos de Negocios son las
siguientes:
- Niveles Altos de Calidad en los modelos de procesos
ayudan en el entendimiento y mantención de los
procesos de negocios [4].
- La Calidad de los modelos de procesos tiene una
positiva influencia en la mantención del software [4].
- Mejorando la Calidad de los Modelos de Procesos
puede ayudar a reducir los costos [5].
- Procesos altamente complejos son propensos a
errores, dificultando su entendimiento y mantención
[2].
1.3 COMPLEJIDAD EN LOS MODELOS DE PROCESOS
No existe consenso en la definición de la complejidad
en el ámbito de los modelos de procesos de negocios,
está claro que representa un gran desafío establecer
claramente que constituye un modelo complejo,
sin embargo, todos los trabajos relacionados con el
tema coinciden que los modelos con altos niveles de
complejidad dificultan el entendimiento, mantención,
elevan los costos de implementación tecnológica y son
propensos a errores.
Actualmente se han realizado trabajos en el área de
complejidad en los modelos de procesos, todos estos
estudios establecen que modelos de procesos con
bajos niveles de complejidad permiten ser modificados
rápidamente para adaptarse a las necesidades de los
clientes, accionistas y proveedores.
Por otro lado, los analistas no están considerando
la complejidad como un factor relevante al momento
de modelar, incluso en algunos casos para procesos
relativamente sencillos los diseños resultan intricados y
se tornan extremadamente difíciles de entender.
1.4 MÉTRICAS EN EL CONTE XTO DE LOS MODELOS CONCEPTUALES DE PROCESOS
“Si algo no puede ser medido, no puede ser mejorado”. Las métricas ayudan a establecer de manera cuantitativa, el estado de ciertas propiedades que son de interés de estudio, la definición de métricas en el modelado de procesos es una práctica relativamente nueva. El surgimiento de las métricas se ha nutrido principalmente de la ingeniería de software [8]. En la TABLA 1 se presentan las similitudes entre el paradigma de Programación Orientada a Objetos(OO) y Notación de Modelado de Procesos de Negocios (BPMN)
- Ambos (Procesos y Software) están centrados en
el procesamiento de información, entre cada paso,
una o más salidas son producidas a partir de una o
más entradas.
- Tiene similitud en la composición estructural. Un
software está compuesto de módulos y clases.
Cada módulo cuenta un número de líneas de código
y cada línea de código está formada por variables,
por otro lado, los procesos están compuestos de
actividades, cada actividad está compuesta de
operaciones elementales (Tareas) y cada una de
estas operaciones usa elementos de información
para producir nueva información.
- Su ejecución dinámica se deriva de su estructura
estática. Cuando se instancia un proceso o se
ejecuta un software, sus elementos toman valores
de acuerdo a su representación estática.
Ha quedado establecido que los procesos y el software
tienen mucho en común, es por esta razón que es
natural que las medidas para determinar la calidad en
el software perfectamente puedan ser adaptadas para
medir la calidad de los modelos de procesos.
2. DISCUSIÓN BIBLIOGRÁFICA
El concepto de complejidad en el modelado de procesos
ha sido introducido en [4,9]. En estos trabajos se plantea
la oportunidad de emplear las métricas de ingeniería de
software para medir la complejidad de los modelos de
procesos. Las métricas propuestas no han sido aplicadas
y validadas con casos reales. En estos trabajos se
consideran los principios básicos de diseño de software
orientado a objeto y como pueden ser considerados
como propiedades deseables a medir en los modelos de
procesos. A continuación, se presenta una revisión de
estos principios y su adaptación al área de complejidad
de modelos de procesos.
Acoplamiento: Las medidas de acoplamiento permiten
establecer el número de interconexiones a través de
los módulos de un modelo. Se han identificado dos
trabajos que usan esta propiedad para medir la calidad
de un modelo de procesos En [10] se denomina a las
métricas que miden esta característica, métricas de
complejidad, el propósito de esta métrica es medir
la cantidad de conexiones entre las tareas en un
modelo de procesos basado en la teoría de análisis
de redes sociales. En [11] se presenta otra métrica de
acoplamiento que tiene como propósito contar todos
los elementos de datos por cada par de tareas. En
ambos trabajos, no se considera la dificultad de las
conexiones, sin embargo, en [12] se presenta una
métrica de acoplamiento que considera la complejidad
de las conexiones y el tipo de nodo que se conecta,
denominada métrica de densidad. Esta métrica se basa
en la complejidad cognitiva de la decodificación de
símbolos y el espacio de estados que se produce al
activar las transiciones entre las actividades.
Cohesión: La cohesión tiene relación con la coherencia
entre las partes de un modelo [11] se presenta una
métrica de cohesión que establece la coherencia entre
las actividades de un modelo de proceso.
Complejidad: Las medidas de complejidad tienen como
propósito medir la entendibilidad y sencillez de un
modelo. Esta propiedad es la más investigada, existen
un amplio rango de métricas definidas. En [4,13]
se realiza una adaptación de McCabes’ cyclometric
number como métrica de complejidad.
Modularidad: La modularidad establece el grado de
como un diseño se puede dividir en varios módulos.
Esta propiedad no registra trabajos que desarrollen
este concepto.
Tamaño: esta medida establece el tamaño de un
modelo de proceso, contando la cantidad de nodos de
un modelo. En [4, 13,16] se propone como medida
la cantidad de actividades como una medida de
complejidad, esta medida surge a partir de la métrica
de LoC (line of Code) de la ingeniería de software, Los
módulos con una gran cantidad de líneas de código
son más difíciles de entender, costosos para mantener
y propensos a errores.
2.1 MOTIVACIÓN
De acuerdo a lo presentado en las secciones anteriores existen numerosos trabajos que abordan el problema de complejidad en los modelos de procesos, sin embargo, en estos trabajos existen muy pocas referencias a modelos reales de procesos, y las referencias más realistas son las presentadas cuando se analizan modelos de procesos de SAP Model Reference que emplean una notación distinta (EPC) que difiere a BPMN, dominante al menos en la realidad nacional. Los modelos propuestos en el catálogo antes mencionado se consideran que están presentados a un alto nivel de abstracción y algunos casos simplifican la realidad objetiva de esos procesos. Los diseños reales consideran regiones de cancelación, manejo de excepciones, estos constructos son empleados habitualmente en el diseño de procesos. Adicionalmente estos estudios están centrados en el acoplamiento como propiedad para establecer niveles de complejidad, nosotros estimamos pertinente que se deben estudiar otras propiedades de los modelos desde la perspectiva de complejidad que son relevantes al momento de realizar una implementación tecnología de los diseños. Es por lo anterior, que la motivación de este trabajo es realizar una propuesta de estudio de la complejidad desde una perspectiva que tenga en cuenta la Modularidad y Cohesión de los modelos procesos, teniendo presente que no existe investigación relevante en esta área, creemos pertinente proponer nuevas medidas que permitan establecer la complejidad de los modelos considerando estas dos propiedades.
2.2 PREGUNTAS DE INVESTIGACIÓN
De acuerdo a lo anterior se plantean las preguntas de
investigación que este trabajo pretende dar respuesta
1. ¿Cómo se puede establecer y medir la cohesión y
modularidad en los modelos de procesos?
2. ¿Qué aspectos claves deben ser considerados de
manera que puedan ser evaluados en modelos
reales?
3. Establecido los aspectos claves y medidas ¿Cómo
pueden ser traducidas en guías y plantillas para el
apoyo en el diseño?
2.3 CONTRIBUCIÓN
La contribución principal de este trabajo, es proponer guías
prácticas que permitan a los analistas e ingenieros de
procesos diseñar procesos que consideren la modularidad
y cohesión como elementos esenciales en los modelos,
adicionalmente establecer que estas propiedades ayudan
a la comprensión por parte de las distintas partes
interesadas, permiten facilitar la mantención de los
modelos y su posterior implementación tecnológica.
Los resultados esperados, se pretende validar
empíricamente la propuesta a través del empleo de un
catálogo de procesos reales. Adicionalmente se pretende
construir un prototipo que incorpore las características
y ayude a los analistas de procesos validar y establecer
la calidad de modelos considerando estos dos atributos.
3. FORMULACIÓN DE LA INVESTIGACIÓN
3.1 Métrica de Cohesión
En esta sección se presenta y describe la métrica de
Cohesión.
Definición N°1: Sea p un Proceso que está compuesto
por un conjunto de nodos (n1, n2, n3,.., nm). Un nodo puede
ser (i) Actividades, por ejemplo a1, a2 ∈A. (ii) Gateway,
por ejemplo g1,g2,..gg ∈G. Eventos e1, e2,..,en ∈ E.
Donde dom(l) es el elemento dominante del Proceso p Para el cálculo de dom(l) se presenta el algoritmo propuesto en [17]. Presentado en la Figura 1
Luego la Métrica de Cohesión de Procesos se define
De la MCP presentada anteriormente podemos decir que
un modelo de proceso es perfectamente cohesionado
si MC(p)=1 y para MC(p)=0 perfectamente no
cohesionado.
En la Figura 2 se presenta el modelo de Proceso Preparar
Clase. En este proceso el docente antes de realizar la
clase, debe definir la clase, el contenido y los objetivos,
una vez ejecutada esta actividad, este diseño debe ser
revisado y aprobado por la Unidad Técnica Pedagógica
(UTP), en paralelo este diseño puede recibir feedback
por parte de un asesor cognitivo. Si la UTP aprueba
el diseño el proceso se termina y la clase queda lista
para ser posteriormente ejecutada. A continuación,
mostraremos como aplicar la métrica de cohesión de
proceso presentada anteriormente.
En la Figura 3 se presenta el resultado de la ejecución
del algoritmo de extracción de elemento dominante
propuesto en Figura 2, el elemento dominante es
Diseño Clase está presente en 7 de 10 actividades luego
MC(p)=7/10=0.7 es un nivel de cohesión bastante alto.
Si consideramos otras técnicas de detección de
similitudes textuales, el proceso presentado en la Figura
3 su nivel de cohesión sería más alto por ejemplo la
Actividad Diseñar Clase es bastante similar al elemento
dominante Diseño Clase.
Luego se podría sensibilizar la función cod(ai)
considerando un umbral de similitud.
Entonces sim(ad/etd) viene dado por el grado de similitud
del elemento dominante etd sobre la etiqueta de la
actividad ai
En la Figura 2 la Actividad Diseño Clase al aplicar scod(aj)=1 donde aj es Diseño Clase incrementando el nivel de cohesión del modelo luego MC(p)=0.8.
3.1.1 Validación de la métrica Propuesta
Para efectos de establecer la validez de la métrica, es
necesario que cumpla un conjunto de propiedades tales
como: facilidad de cálculo, Consistencia y sea objetiva.
Adicionalmente en [3] se presentan las propiedades
deseables de la una métrica:
- Simplicidad: La métrica debe ser fácil de entender
por parte de los usuarios finales (Analistas,
Ingenieros de Procesos).
- Consistencia: La métrica debe obtener el mismo
valor cuando dos usuarios de manera independiente
la aplican al mismo modelo.
- Automatización: Esta debe ser posible de
implementar en un software para realizar la
medición de los procesos.
- Las medidas deben ser aditivas si dos estructuras
independientes: dos modelos son puestos en
secuencia entonces el total de la complejidad de
las estructuras combinadas debe ser al menos
la suma de las complejidades de las estructuras
independientes.
- Las medidas deben ser interoperables: deben
ser capaces de ser implementadas en distintas
notaciones de modelado de procesos, por ejemplo,
EPC, BPMN, etc.
En el caso MC a simple vista cumple 4 de 5 propiedades
presentadas anteriormente, la propiedad de complejidad
aditiva debe ser demostrada de manera formal para
afirmar que es satisfecha por MC.
Para determinar si MC constituye una buena medida de
complejidad se propone utilizar Weyuker Properties. WP
ha sido aplicado al estudio de métricas de complejidad
en el área de ingeniería de software, respecto de
investigaciones para métricas de modelos de procesos
en [3] es empleada para validad la métrica CFC (Control-
Flow Complexity).
Es necesario realizar las pruebas para validar la calidad
de una métrica, no obstante, se puede adelantar que
la métrica propuesta no cumpla la propiedad 8 de la
TABLA 2, debido a que la métrica propuesta realiza
análisis de palabras y nombres de actividades y a partir
del grado de similitud determina la medida, es decir que
si una actividad varia en su nombre probablemente el
resultado de la medición sea diferente. En definitiva se
puede establecer a priori que la métrica propuesta no
cumple con la propiedad 8
La métrica propuesta determina el nivel de cohesión de un proceso a partir de los nombres de actividades. Esto reviste una limitación importante, no obstante, en [18] un influyente trabajo en esta área propone 7 guías de diseño de procesos que han tenido una gran aceptación y han sido adoptadas por los analistas, ingenieros de procesos en sus modelos. En la TABLA 3 se presentan las 7 guías de diseño
El ejemplo propuesto, las etiquetas cumplen con gran
parte de las guías presentadas en la TABLA 3.
Adicionalmente en [17] se presenta los diferentes tipos
de estructuras gramaticales que son usualmente empleados
por los analistas en los modelos de procesos.
Estas estructuras han sido habituales en los modelos
de procesos en el Catalogo del SAP Model Reference,
donde se agrupan cerca de 2000 modelos de procesos.
Dentro de los estilos de nombres utilizados existen están
Verbo-Objeto, por ejemplo, Diseñar Clase, Estructuras
de texto que no contienen acción y agregan conectores
gramaticales y pronombres, por ejemplo: Diseño de
Clase y Revisión, Acciones descriptivas incluyen al rol,
por ejemplo, Docente realiza el diseño de la clase.
En [19] se presentan los diferentes estilos de etiquetas
para nombrar las actividades en un proceso, esta clasificación
surge del estudio del catálogo de SAP Model Reference.
En la Figura 4 se presenta los estilos de etiquetas
para nombres de actividades en modelos de procesos.
3.2 Métrica de Modularidad
proveniente de la ingeniería de software plantea que
un componente es modular si es capaz de ser divido
en partes. A partir de las similitudes de la Ingeniería
de Software con los modelos procesos establecida
previamente, se puede suponer lo siguiente:
Un Proceso puede ser entendido como una interfaz y
cada actividad de ese proceso puede ser entendida
como la declaración de los métodos de esa interfaz.
Una interfaz debe ser implementada por una Clase.
En la Figura 5 se presenta un proceso declarado como
una interfaz, La interfaz PrepararClase compuesta por
los métodos realizarDisenioClase, revisarDisenioClase,
corregirDisenioClase que representan las actividades del
proceso Preparar Clase.
A partir de los principios de diseño de orientación a objetos, en la TABLA 4 se presentan los principios SOLID (Single Responsability,Open-Close, Sustitution Liskov, Interface segregation, Dependency inversion).
En el caso de los procesos, se puede decir que un
modelo de proceso requiere ser divido si el MC(p)
es bajo, si MC(p) es alto es proceso auto contenido.
Aplicando SOLID para S la alta cohesión implica que
existe un elemento dominante y que el proceso tiene
directa relación con ese elemento dominante, vale decir
el proceso solo tendría pocas razones por las cuales
cambiar, es decir MC (p) cumple S. En este punto se
puede establecer que MC(p) es una métrica que permita
medir el nivel de responsabilidades de una actividad.
En el caso de O un proceso debe ser cerrado para
modificación y abierto para su extensión, esta propiedad
tiene directa relación con el objetivo que buscan las
métricas de complejidad, es ayudar a producir modelos
que puedan tener un menor costo en modificación y
mantención ante los cambios del entorno, se puede
establecer que Un proceso con alto nivel de cohesión
permite facilitar la modificación y adaptación a nuevos
requerimientos cumpliendo O.
En (5) se define la fórmula para el cálculo de la Métrica
de Modularidad (MRP)
Donde NRP es la cantidad de palabras promedio que las
etiquetas emplean al definir el nombre de las actividades.
Se puede decir que para NRP(p) cercano a 2 se encuentra
bien definidas las responsabilidades de las tareas. Este
valor no es arbitrario. en [19] se establece que modelos
con bajos niveles de complejidad emplean 2 palabras
en las etiquetas del proceso principalmente estilo Verb
Phrase. Al estar bien definidas las responsabilidades se
entiende que un proceso no cuenta con más actividades
que las necesarias cumpliendo con esto I. Adicionalmente
para D para NRP(p) alto supone que las actividades
contenidas en el proceso emplean demasiadas palabras,
aumentando su nivel de especialización en consecuencia
para NRP(p) cercanos a 2 las actividades no muestran
detalles de implementación concreta. Luego NRP(p)
bajos o cercanos a 2 cumple con D. En el caso de L, es
forzado establecer que un Proceso p cumpla con esta
propiedad, principalmente por el análisis semántico
involucra dependencia de como se llame la actividad al
resultado y su implementación en definitiva no podemos
asegurar que las métricas propuestas cumplan L.
Intuitivamente se ha presentado como las métricas
propuestas cumplen en mayor medida los principios
esenciales de la orientación a objetos, adaptados para
el caso de modelado de procesos.
3.3 LIMITACIONES DEL TRABAJO
En este trabajo no tiene dentro de sus alcances la definición de umbrales para clasificar en niveles la cohesión, este trabajo constituye un primer avance en materia de la definición de la medición de complejidad en virtud de dos propiedades cohesión y modularidad. Abordar de manera sencilla la cohesión y modularidad que permita a los analistas noveles mejorar sus diseños considerando estas propiedades. En trabajos futuros se pretende establecer umbrales, para este nuevo objetivo.
4. DISEÑO DEL EXPERIMENTO
Se prepara un catálogo de procesos y se define una
población de individuos, se considera profesionales de
las Carreras Ingeniería Civil Informática, Ingeniería Civil
Industrial, Ingeniería Mecánica, Estudiante de Postgrado
de Magíster en Ciencias de la Computación, Expertos
del Dominio e Ingenieros de Procesos con al menos dos
años de experiencia usando notación BPMN.
Cada uno de estos grupos de evaluadores se solicita
que respondan una encuesta la cual serán contrastados
con los obtenidos a partir de la métrica. Posteriormente
se emplea las métricas propuestas y se evaluará las
propiedades esenciales de las mismas presentadas
anteriormente. Finalmente se diseña una modificación
del o los procesos y se verifica si efectivamente las
métricas contribuyen a mejorar la comprensión de los
modelos y disminuir la complejidad.
En la Figura 5 se presenta el proceso Preparar y Ejecutar
Experimento que se utiliza para validar empíricamente
las métricas propuestas. En el Subproceso Diseñar
Experimento se ejecutan dos actividades: Diseñar
Cuestionario y Cargar Modelo. En Diseñar Cuestionario
se crea una encuesta donde los participantes se les
solicita que respondan preguntas de apreciación de
dificultad de entendibilidad y comprensión de un
modelo en particular, adicionalmente se solicita que
incorporen nuevos requerimientos al modelo. En Cargar
Modelo se sube el modelo que será sujeto de estudio.
Posteriormente una vez concluido este subproceso,
se realiza invitación a un grupo de expertos para que
validen el modelo desde la perspectiva de sintaxis y
semántica, además que validen la encuesta. Luego
se ejecuta el Subproceso Validar Diseño, donde cada
experto invitado valida el diseño del experimento. Una
vez concluido se incorporan las recomendaciones de
los expertos en la encuesta y el modelo de proceso
en estudio en Consolidar Resultados. En esta Fase del
Proceso se realiza la invitación a los participantes que
serán parte del experimento. En el Subproceso Ejecutar
Experimento, en esta etapa los participantes ejecutan
las actividades: Descargar, Analizar y Responder
Encuesta. Una vez terminadas todas las instancias
por participantes, Se ejecutan las actividades Procesar
Resultados, Cancelar Instancias Activas y finalmente se
ejecuta la actividad Evaluar y Analizar Resultados.
5. RESULTADOS DEL EXPERIMENTO
5.1 Caso 1: ENCUESTA
Se crea una instancia del Proceso Preparar y Ejecutar Experimento para Modelo de Proceso Preparar y Aplicar Evaluación. En el subproceso Diseñar Experimento se diseña el cuestionario y se carga el modelo. La validación del cuestionario se envía a un Experto en Diseño de Evaluaciones. La Validación de la Semántica y Sintaxis del Modelo la realiza un profesional con conocimiento en modelado de procesos y el dominio de educación. Una vez validado el modelo y el cuestionario, se realiza la invitación a 10 participantes que responderán el cuestionario a partir del modelo propuesto.
En la Figura 6 se presenta el modelo de procesos Preparar y Aplicar Evaluación que será presentado a los invitados al experimento. Este modelo describe el proceso de evaluaciones y pruebas en una institución de educación primaria, este proceso se inicia con el diseño de una evaluación que incluye las preguntas y sus respectivas alternativas de respuestas, posteriormente el docente/evaluador envía el diseño a revisión por parte de un grupo de expertos que validan el instrumento, luego una vez recibido las sugerencias por parte de los asesores/expertos, el docente/evaluador puede incluir las recomendaciones en el instrumento evaluativo, una vez realizada esta actividad, el evaluador debe realizar la invitación a los estudiantes/ participantes del proceso a quienes se aplicará la evaluación, entregada la invitación, los estudiantes deben realizar la evaluación. Cuando terminen de rendir las evaluaciones, se procesan analizan los resultados y se generan los reportes de resultados terminando el proceso en la actividad de cierre de evaluación. En la Figura 7 se presenta la encuesta a aplicar, la finalidad de la encuesta es determinar la complejidad, entendibilidad y facilidad de incorporar nuevos requerimientos, si el modelo resulta entendible, la magnitud de la métrica de cohesión debería tener una magnitud considerable, además se pretende a través de las preguntas de apreciación identificar la valoración en escala Likert de las distintas dimensiones entendibilidad, facilidad de uso y adaptación a nuevos requerimientos, además se incluye una pregunta de inferencia que tiene directa relación con el nombre del proceso, en el experimento no se incluye el nombre del proceso, se solicita a los participantes que elijan un nombre a partir de 5 nombres propuestos: Diseñar Evaluación, Preparar y Aplicar Evaluación, Diseñar y Realizar Evaluación, Elaborar Evaluación, Elaborar y Aplicar Evaluación. El propósito de esta pregunta es determinar si los encuestados consideran patrones de asignación de nombres de actividades que tengan relación con lo propuesto en [17]. Además, se solicita a los participantes que incorporen un nuevo requerimiento al modelo propuesto y se solicita que valoren la dificultad para incluir el nuevo requerimiento.
Adicionalmente, se propone un método de refactorización de modelos de procesos que incorpora guías de diseño para etiquetas de modelos de procesos, en la Figura 8 se presenta el esquema general del método de refactorización, se inicia aplicando la métrica de cohesión propuesta al modelo, luego se realiza el análisis del modelo, a través de distintos mecanismos, tales como: estilos de etiquetas, conjugación de verbos. Una vez realizado lo anterior, se elige la refactorización a aplicar al modelo a partir de catálogo de refactorizaciones, se aplica la refactorización y se calcula nuevamente la métrica, este proceso se realiza hasta que la métrica alcance un umbral o en su defecto no queden más refactorizaciones por aplicar.
5.1.1 Resultados Caso 1
En la Figura 9 se presentan los resultados promedios
de la encuesta, en las preguntas de apreciación de la
encuesta, Pregunta 2 El modelo le resulta entendible
(Entendibilidad/Comprensibilidad) arrojaron en
promedio 4.85 sobre 5, donde 5 es la opción muy de
acuerdo con la afirmación propuesta en la pregunta.
En el caso de la pregunta 4 Le resultó fácil incorporar
el Requerimiento (Modificabilidad/Adaptabilidad) en
promedio entrega un valor 4.67 sobre 5. En la pregunta
5 se plantea una descripción de una situación y se
pregunta Si esa descripción tiene coherencia con el BPMN
presentado(Comprensibilidad) en resultado en promedio
es 4.78 sobre 5. A partir de los resultados obtenidos
en la encuesta, los participantes calificaron el modelo
como de baja complejidad debido a que los valores de
las escalas de apreciación son cercanos o muy cercanos
a 5 en las 3 preguntas de apreciación, el estilo de las
etiquetas de las actividades del proceso pueden tener
una incidencia en la entendibilidad y comprensión del
modelo. En la Figura 11 se presenta análisis del estilo de
etiquetas de las actividades del proceso [17][19] para
el modelo propuesto en el experimento. En este caso,
el total de las etiquetas presentes en el proceso tiene el
estilo Verb Phrase.
En el caso de la Pregunta 1 ¿Qué nombre le pondría al
modelo? 5 de los encuestados eligieron la alternativa 3
Diseñar y Realizar Evaluación, 2 escogieron la alternativa
1 Diseñar Evaluación, 1 escogieron alternativa
Preparar y aplicar Evaluación y Elaborar Evaluación
respectivamente. La elección mayoritaria tiene directa
relación con lo propuesto en [17] donde el nombre de la
actividad deriva del elemento dominante (Evaluación) y
conjunción distintas actividades (Diseñar, Realizar).
5.1.1.1 Cálculo Métrica Cohesión
A partir de los resultados obtenidos en la encuesta, se debe contrastar con la métrica de cohesión propuesta. En la Figura 12 se presenta el análisis de etiquetas de las actividades, entrega como resultado que existen 15 etiquetas en el modelo, las etiquetas con mayor frecuencia (elemento dominante) son Resultados y Evaluación. Luego al calcular la métrica propuesta esta arroja un valor de 40%.
5.1.1.2 Análisis de los resultados
En la Figura 13 se presenta el resultado obtenido al aplicar la métrica de cohesión, la magnitud de la métrica arroja un valor medio/alto, sin embargo, hay dos elementos dominantes Evaluación y Resultados. A partir de lo propuesto en [17] se realiza el análisis de conjugación de verbos que acompañan a los objetos de negocios. En la Figura 14 se presenta los resultados de la conjugación de verbos, en el caso de Evaluación los verbos que acompañan a este objeto de negocio Diseñar, Revisar, Validar, Realizar y Cerrar y para Resultados se identifican los verbos Consolidar, Procesar, Analizar. Esto puede señalar la existencia de subprocesos. Uno relacionado con el Objeto de Negocio Evaluación y otro subproceso que tenga relación con Resultados.
5.2 Caso 2: Refactorización del modelo Preparar y Aplicar Evaluación
El resultado de la métrica de cohesión y el análisis de conjugación de verbos presentados previamente, entregan una señal de la existencia de subprocesos, A partir de lo anterior, se plantea la necesidad de refactorizar el modelo de proceso y aplicar nuevamente la métrica, para ver la evolución de la magnitud de la misma, para llevar a cabo este proceso, se emplea el catálogo clásico de refactorizaciones propuesto en [20]. En la TABLA 6 se presenta la propuesta de refactorizaciones para modelos de procesos a partir del catálogo clásico de refactorizaciones.
5.2.1 Caso 2 Aplicar Refactorización Renombrar Actividad
En el proceso de Preparar y Aplicar Evaluación se identifica la actividad Consolidar Resultados que es candidata a aplicar la refactorización renombrar actividad, el nombre de actividad no tiene relación con su propósito, que es recibir recomendaciones de los expertos y realizar los ajustes a la evaluación, Se renombra por Ajustar Evaluación. En la Figura 15 se presenta la refactorización para la actividad Consolidar Resultados. En la Figura 16 se presenta el resultado al calcular la métrica de cohesión al aplicar la refactorización Renombrar Actividad la magnitud 50%.
5.2.2 Analisis de los Resultados
El modelo resultante no difiere respecto del anterior, sin embargo, aumenta su nivel de cohesión al cambiar la etiqueta por una que representa de mejor manera el proceso. La magnitud indica que hay un elemento dominante que está presente al menos en la mitad de las actividades del proceso, esto puede entregar una señal de la existencia de un subproceso que encapsule el elemento dominante.
5.3 CASO 3 APLICAR REFACTORIZACIÓN EXTRACCIÓN DE SUBPROCESO
Una vez aplicada la refactorización, se obtiene conjugación de verbos del objeto de negocio dominante Evaluación, En la Figura 17 se presenta los verbos que conjugan a este objeto de negocio son Diseñar, Revisar, Validar, Ajustar, Realizar, Cerrar y para el objeto de negocio Resultados los verbos son Procesar, Analizar, resulta evidente que existen dos subprocesos. En la Figura 18 se presentan los resultados al aplicar la refactorización Extracción de subprocesos donde se obtienen dos subprocesos Diseñar y Realizar Evaluación y Procesar y Analizar Resultados.
5.3.1 Análisis de Resultados Caso 3
Los modelos resultantes Diseñar y Realizar Evaluación,
Procesar y Analizar Resultados tienen definidas
claramente sus responsabilidades, el primero tiene
relación con el objeto de negocio Evaluación y el
segundo con Resultados.
En la Figura 19 se presenta el resultado al aplicar la
métrica de cohesión a los modelos resultantes, la
magnitud de la métrica es cercana al 67%. Esto supone
un nivel de cohesión alto para cada proceso.
5.4 CASO 4: INCORPORACIÓN DE NUEVO REQUERIMIENTO AL MODELO
El dueño del proceso desea incorporar un nuevo requerimiento, que el proceso permita aplicar evaluaciones sin requerir del concurso de un experto que valide el instrumento evaluativo, esto permitirá ejecutar instancias del proceso para el desarrollo de pruebas cortas o trivias. Este requerimiento involucra modificar el modelo de proceso e incorporar una compuerta basadas en datos, esta compuerta evalúa dependiendo del tipo de evaluación (Evaluación Convencional, Quiz, Evaluación de Nivel) si requiere ejecutar las actividades de Invitar Experto, Revisar y Validar Evaluación. En la Figura 20 se presenta el resultado del proceso al incorporar la compuerta basada de datos.
5.5 CASO 5 APLICAR REFACTORIZACIÓN REEMPLAZAR CONDICIONAL CON UNA NUEVA VERSIÓN DEL PROCESO
La incorporación del nuevo requerimiento en el modelo de proceso no modifica la magnitud de la métrica de cohesión, sin embargo, la implementación a través de una compuerta basadas en datos, aumenta la complejidad del modelo, dificultando la adaptabilidad a nuevos requerimientos en el futuro. Para disminuir la complejidad del modelo y no degradar el proceso se aplica la refactorización Reemplazar condicional con una nueva versión del proceso. Se emplea las Jerarquías de procesos propuesto en [21] para reemplazar la compuerta basada en datos y se crean tres versiones del proceso de Diseñar y Realizar Evaluación a partir del tipo de evaluación Convencional, Quiz, Nivel. En la Figura 21 se presenta el esquema de versiones de procesos que resultan al aplicar la refactorización. Esto esquema permite cumplir con el principio de Open-Close cerrado para modificación y Abierto para extensión para otras versiones del proceso Diseñar y Realizar evaluación.
5.5.1 Análisis de Resultados Caso 5
Las tres versiones de procesos que surgen al aplicar la refactorización, tiene una magnitud de la métrica de cohesión alta, en el caso de la Diseñar y Realizar Evaluación(Quiz) el modelo se encuentra perfectamente cohesionado, es decir, todas las actividades del proceso tienen relación con el elemento dominante Evaluación. Para evaluación Convencional y de Nivel, la métrica de cohesión es superior al 60%. En esta fase se detiene el proceso de refactorización. En la Figura 22 se presenta la magnitud de la métrica de cohesión resultante para las tres versiones del proceso Diseñar y Realizar Evaluación.
6. DISCUSIÓN DE LOS EXPERIMENTOS
Las métricas presentadas en este estudio conjuntamente con el análisis de conjugación de verbos, permiten mejorar los niveles de cohesión del modelo, además dirige el proceso de refactorización de modelos de procesos. En el experimento se muestra que el método propuesto puede ser incorporado como una práctica en el proceso de levantamiento y diseño de modelos de procesos. El experimento entrega señal respecto que la incorporación de guías de diseño de procesos y el análisis de etiquetas ayuda a la comprensibilidad, entendibilidad y aumenta el valor de uso de los modelos de procesos, Los usuarios encuestados dejan en evidencia en las preguntas de apreciación, la alta valoración que realizan en dimensiones de entendibilidad, comprensibilidad y facilidad de adaptación a nuevos requerimientos. El experimento permite tener una aproximación al desarrollo de modelos con mayores niveles de cohesión, además el proceso de refactorización propuesto en este trabajo ayuda a al diseño de modelos de procesos modulares.
6.1 AMENAZAS PARA LA VALIDACIÓN
Este estudio no puede asegurar resultados en un modelo
de procesos que no cuente con mecanismos mínimos
de validación desde la perspectiva sintaxis. La muestra
de individuos encuestados puede no ser representativo
del fenómeno que se desea evaluar, adicionalmente el
método propuesto en este estudio debe ser validado
de manera más exhaustiva con más casos y distintos
escenarios. Sin embargo, este estudio constituye una
primera aproximación de un método sistemático de
evaluación y mejora de modelo conceptuales de procesos
de negocios. El método propuesto y experimento
desarrollado en este trabajo fue empleado en caso real
de procesos y sirvió de base para la implementación del
proceso y las distintas versiones surgidas a partir de los
nuevos requerimientos solicitados por los usuarios de
negocio.
En relación a los resultados obtenidos en este trabajo, a
partir del experimento se encuentra cierta evidencia que
las métricas propuestas en estudio en combinación con
el análisis de etiquetas y la refactorización de etiquetas
de procesos, permiten diseñar modelos conceptuales
de procesos de negocios con menores niveles de
complejidad y constituyen un buen mecanismo para
mejorar los modelos, mejorar la comprensión y facilitar
la incorporación de nuevos requerimientos.
7. CONCLUSIÓN Y TRABAJOS FUTUROS
En este estudio se presenta una propuesta de
métricas de complejidad basados en el análisis de
etiquetas, se propone un proceso de refactorización
de modelos de procesos a partir del catálogo clásico
de refactorizaciones. Adicionalmente se incluye un
experimento donde se aplica en un caso real lo propuesto
en este estudio. Los resultados obtenidos indican que
las métricas propuestas en combinación con el proceso
de refactorización ayudan al proceso de levantamiento
y diseño de procesos de negocios, entregan algunas
directrices que permiten a los analistas mejorar los
diseños de los procesos y disminuir el esfuerzo en la
incorporación de nuevos requerimientos. La simplicidad
de la propuesta presentada en este estudio, ayude
en el futuro a ingenieros, analistas de procesos en la
adopción y uso.
En relación a la pregunta de Investigación ¿Cómo se
puede establecer y medir la cohesión y modularidad
en los modelos de procesos? En este estudio se
establece que el análisis de etiquetas constituye un
buen mecanismo para medir los niveles de cohesión,
conjuntamente el catálogo de refactorizaciones para
modelos de procesos entrega una visión para el diseño
de modelos de procesos modulares atendiendo a la
existencia de elementos dominantes, las técnicas
de refactorización permiten de manera controlada y
sistémica levantar y diseñar modelos más modulares.
Con respecto a la Pregunta de Investigación ¿Qué
aspectos claves deben ser considerados de manera que
puedan ser evaluados en modelos reales? Los aspectos
identificados en este estudio que deben ser tener en
cuenta al ser evaluados en modelos reales tiene relación
con la entendibilidad del modelo, el esfuerzo en la
incorporación de nuevos requerimientos, la facilidad
de adopción y el valor de uso de los modelos por las
distintas partes interesadas de la organización.
En relación a la Pregunta de Investigación, Establecido los
aspectos claves y medidas ¿Cómo pueden ser traducidas
en guías y plantillas para el apoyo en el diseño? El
catálogo de refactorizaciones, la conjugación de verbos
y extracción de elementos dominante, se pueden
considerar como un marco que apoye el levantamiento
y diseño de procesos de negocios con bajos niveles de
complejidad. Las guías presentadas en este estudio se
espera que ayude a analistas e ingenieros de procesos
más noveles en la construcción de modelos con altos
niveles de cohesión que sean útiles a las organizaciones.
En relación a los trabajos futuros, actualmente se está
desarrollando una plataforma web que implementa lo
propuesto en este estudio, esta plataforma permite
además del despliegue de procesos de negocios, se
incorpora los elementos de calidad de modelado que
facilite y apoye la evaluación de los modelos de procesos
antes de que estos sean implementados. Adicionalmente
se está trabajando en el estudio de la variabilidad de
modelos de procesos, a partir de este concepto se
pretende facilitar la implementación y despliegue de
distintas versiones de modelos de procesos. Permitiendo
a las organizaciones disminuir el tiempo de ciclo de
implementación de los procesos.
8. AGRADECIMIENTOS
Este trabajo forma parte de los requisitos de tesis de Magíster en Ciencias de la Computación, Universidad Católica del Maule, Chile
9. REFERENCIAS
[1] Muketha, G.M., Ghani, A.A.A., Selamat, M.H., and
Atan, R. (2010). “A Survey of Business Process Complexity
Metrics. In Information Technology” Journal
9.7, 1336-344.
[2] Indulska Marta, Zur, Muehlen, Recker J “Measuring
Method Complexity: The Case of the Business Process
Modeling Notation.”,2009
[3] Cardoso J. “Control-flow Complexity Measurement of
Processes and Weyuker’s Properties”, 2007
[4] Cardoso J, Mendling, Neumann, and Reijers H.A. “A
Discourse on Complexity of Process Models” 2006.
[5] Figl Kathrin, Laue R. “Cognitive Complexity in Business
Process Modeling” 2011.
[6] Reijers, H.A., Mendling, J., and Recker, J. (2010).
Business Process Quality Management, In Handbook
on Business Process Management, 167-185.
[7] ISO/IEC 25000:2005, Software Engineering Software
Product Quality Requirements and Evaluation
(SQuaRE) Guide to SQuaRE,2005
[8] Lindsay, A., and Lunn, K. “Business processes attempts
to find a definition. In Information and Software
Technology, 45 (15), 1015-1019. (2003).
[9] Guceglioglu, A.S., and Demiros, O. “Using Software
Quality Characteristics to Measure Business Process
Quality”. Proceedings of the 3rd International Conference
on Business Process Management (BPM 2005),
Lecture Notes in Computer Science 3649, pages 374-
379, 2005.
[10] Mendling, J. Testing Density as a Complexity Metric
for EPcs. German EPC workshop on density of process
models, 2006. http://wi.wuwien.ac.at/home/
mendling/publications/TR06-density.pdf
[11] Reijers, H.A., and Vanderfeesten, I. Cohesion and
Coupling Metrics for Workflow Process Design. In:
Desel, J., Pernici, B., and Weske, M., editors, Business
Process Management (BPM 2004), Lecture Notes in
Computer Science, volume 3080, pages 290-305,
Springer-Verlag Berlin, 2004.
[12] Cardoso J, Vanderfeesten I, Reijers R. “Computing
coupling for business process models”.
[13] Gruhn, V., and Laue, R. “Complexity metrics for business
process models”. In: Witold Abramowicz and
Heinrich C. Mayr, editors, 9th international conference
on business information systems (BIS 2006), volume
85 of Lecture Notes in Informatics, pages 1-12, 2006.
[14] Krzysztof Kluza, Grzegorz J. Nalepa “Proposal of
Square Metrics for Measuring Business Process Model
Complexity” IEEE, 2011
[15] W. Khlif, N. Zaaboub, and H. Ben-Abdallah, “Coupling
metrics for business process modeling,” International
Journal of Computers, vol. 4, no. 4, 2010.
[16] Latva-Koivosto, A.M. “Finding a complexity measure
for business process models”. Helsinki University of
Technology, Systens Analysis Laboratory, 2001.
[17] Henrik Leopold, Mendling Jan, Reijers Hajo A, La Rosa
Marcelo “Simplifying Process Model Abstraction: Techniques
for Generating Model Names”,2014
[18] Mendling J, Reijers H. A., and van der Aalst, “Seven
process modeling guidelines (7pmg),” Information &
Software Technology, vol. 52, no. 2, pp. 127–136, Feb
2010.
[19] Henrik Leopold, Sergey Smirnov, Jan Mendling. “Recognising
Activity Labeling Styles in Business Process
Models” Enterprise Modelling and Information Systems
Architectures Vol. 6, No. 1, February 2011.
[20] Fowler Martin, Beck Kent, Brant John, Opdyke William,
Roberts Don, “Refactoring: Improving the Design
of Existing Code” 1999.
[21] Bravo C. Juan, “Gestión de Procesos con responsabilidad
social”, pag. 33-37. 2009