• No se han encontrado resultados

Modelo para estimar el esfuerzo que demanda la automatización de procesos de negocio

N/A
N/A
Protected

Academic year: 2020

Share "Modelo para estimar el esfuerzo que demanda la automatización de procesos de negocio"

Copied!
87
0
0

Texto completo

(1)Universidad Central “Marta Abreu” de las Villas Facultad de Matemática, Física y Computación. “Modelo para estimar el esfuerzo que demanda la automatización de procesos de negocio” Tesis para optar por el título de Máster en Ciencia de la Computación. Autora: Ing. Yaimara Granados Hondares Tutora: Dra. Gheisa Lucía Ferreira Lorenzo. Santa Clara 2015.

(2) Declaración Jurada El que suscribe, Yaimara Granados Hondares, hago constar que el trabajo titulado “Modelo para la estimación del esfuerzo que demanda la automatización de procesos de negocio” fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los estudios de la maestría en Ciencia de la Computación, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. ________________ Firma del autor. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. _____________________________. ____________________________. Firma del Tutor(es). Firma del Jefe del Laboratorio. 2015. i.

(3) DEDICATORIA. “A mis hijas Meli y Vane (todavía en la barriguita).. Por ser mi obra mejor, mi orgullo. A quienes dedico cada día lo mejor de mí y brindo mi amor más sincero y profundo. Por quienes hago todo sin importar el cansancio, porque aún cuando pienso que el día no ha acabado y siento desfallecer, una sonrisa hace que mis fuerzas se renueven.”. ii.

(4) AGRADECIMIENTOS A mi esposo Jorge A mis padres Marilyn y Wilfredo A mis suegros Teresa y Armando A mi cuñada Yenia y familia A mi familia toda. A mi tutora y amiga Gheisa A la profesora Gladita A mi tesiante y amiga Claudia A mis compañeros del departamento de computación y específicamente del laboratorio Programación e Ingeniería de Software.. iii.

(5) RESUMEN El desarrollo de productos software ha impactado de forma significativa en el mundo empresarial. De forma paralela las organizaciones han dejado atrás su enfoque funcional y han empeñado recursos en la modelación con calidad de sus procesos de negocio. Numerosos son los estudios dedicados a medir indicadores significativos a partir estos, dígase calidad, complejidad, entendibilidad y facilidad de modificación, atendiendo a los constantes cambios organizacionales. Investigaciones relacionadas han dado como resultado la definición de un sin número de métricas. Estas métricas se han seleccionado en su gran mayoría haciendo analogías con métricas de software. De ahí que comiencen a ser utilizadas para estimar elementos de software, como el esfuerzo, utilizando como base los modelos de procesos de negocio anteriormente mencionados. El presente trabajo tiene como objetivo fundamental, definir un modelo estadístico que permita la predicción del esfuerzo requerido en la automatización de procesos de negocio, tomando como punto de partida su representación gráfica. Para ello se propuso un conjunto de métricas relativas a los modelos de procesos de negocio con el fin de estudiar su comportamiento e influencia en la estimación del esfuerzo. Se construyó una base de casos con un total de ochenta modelos con sus respectivos valores del esfuerzo, realizándose el procesamiento a partir técnicas estadísticas y obteniéndose un modelo de predicción con un nivel de exactitud elevado. Asimismo, se desarrolló una aplicación para la interpretación de diferentes formatos de salida de herramientas que permiten modelar procesos de negocio y la implementación del modelo predictivo obtenido.. iv.

(6) ABSTRACT Software products development has impacted meaningfully in the business world. The organizations have left behind their functional focus and they have dedicated many resources in the modeling of business processes with quality. There are many studies dedicated to measure significant indicators related to the business process, quality, complexity and understandability, attending to the constant organizational changes. Related works have given the definition of metrics that have been selected in his great majority making out of analogies with software metrics. They are used to estimate elements of software, like the automation effort, using business process models. The present work defines an effort automation prediction model of business processes diagrams. This thesis presents a metrics set defined with elements to the business process models, to measure its behavior and its influence in the automation effort. A base of cases was conformed to a total of eighty models with his respective values of the effort; these models were processed using statistical classifiers getting a prediction model with a high accuracy. Have been developed an information-technology tool for the interpretation of formats of exit of modeling tools for business process and the implementation of the prediction model obtained was included.. v.

(7) TABLA DE CONTENIDO. RESUMEN ....................................................................................................................................................... iv ABSTRACT ....................................................................................................................................................... v INTRODUCCIÓN ............................................................................................................................................. 1 CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES. ...................................................................................................................................................... 8 Modelado de procesos de negocio. .......................................................................................................... 8 Notaciones para el modelado de procesos de negocio......................................................................... 9 Business Process Modeling Notation (BPMN). ..................................................................................... 12 Objetivo y alcance de BPMN ............................................................................................................... 13 Diagrama de Procesos de Negocio (BPD). ....................................................................................... 14 Herramientas para el modelado BPMN.............................................................................................. 16 Diferencias de BPMN con otros estándares...................................................................................... 18 Evaluación de los procesos de negocio ................................................................................................. 18 El esfuerzo en el contexto de los procesos de negocio. .................................................................... 24 Conclusiones del capítulo......................................................................................................................... 27 CAPÍTULO II MÉTRICAS PROPUESTAS ASOCIADAS A MODELOS DE PROCESOS DE NEGOCIO ....................................................................................................................................................... 29 Métricas asociadas a procesos de negocio........................................................................................... 29 Contexto actual .......................................................................................................................................... 30 Definición de las métricas. ....................................................................................................................... 31 Métricas Grupo I. ................................................................................................................................... 33 Ejemplo de aplicación. .......................................................................................................................... 36 Métricas Grupo II. .................................................................................................................................. 38 Algoritmo para el cálculo de CAPN. (Bandomo Toledo 2014) ....................................................... 40 Ejemplo de aplicación de las métricas Grupo II. ............................................................................... 40 Sentencia computacional para el cálculo de las métricas propuestas. ............................................. 41 Herramienta para la interpretación de archivos IEEMPN.................................................................... 41 Formatos interpretables. ....................................................................................................................... 42 Herramienta IEEMPN ............................................................................................................................ 43 Conclusiones del capítulo. ....................................................................................................................... 48 CAPÍTULO III MODELO PARA LA PREDICCIÓN DEL ESFUERZO A PARTIR DE MODELOS DE PROCESOS DE NEGOCIO. ........................................................................................................................ 50 vi.

(8) Creación de la Base de casos. ................................................................................................................ 50 Análisis de los datos.................................................................................................................................. 52 Regresión lineal múltiple........................................................................................................................... 53 NCA y CCOM en los resultados obtenidos. .......................................................................................... 55 Complejidad de Automatización de procesos de negocio. ................................................................. 56 Métricas que influyen directamente en la automatización de procesos de negocio. ...................... 57 Implementación del modelo predictivo en la herramienta IEEMPN. ................................................. 58 Conclusiones del capítulo. ....................................................................................................................... 59 CONCLUSIONES .......................................................................................................................................... 60 RECOMENDACIONES ................................................................................................................................. 61 REFERENCIAS BIBLIOGRÁFICAS ........................................................................................................... 62 ANEXOS ......................................................................................................................................................... 67 A. Elementos centrales de la notación BPMN ...................................................................................... 67 B. Métricas propuestas por diferentes autores en la literatura. Cronología. .................................... 68 C. Conjunto de métricas propuestas por Elvira Rolón. ........................................................................ 70 D. Analogía entre le métricas de software LOC (Lines of Code) y los procesos de negocio. ....... 74 E. Tabla de correlación utilizando el coeficiente de correlación de Pearson ................................... 75 D. Análisis de la regresión eliminando la métrica NTA del conjunto de variables independientes. ...................................................................................................................................................................... 77. vii.

(9) ÍNDICE DE FIGURAS Figura 1: Elementos de un proceso de negocio. ........................................................................................ 8 Figura 2: Diagrama de Proceso de Negocio modelado utilizando la notación BPMN. ....................... 15 Figura 3: Medidas base para eventos propuestas en (Rolón Aguilar 2009). ....................................... 23 Figura 4: Evento de inicio. ............................................................................................................................ 33 Figura 5: Evento Intermedio. ........................................................................................................................ 33 Figura 6: Evento fin. ...................................................................................................................................... 33 Figura 7: Tarea............................................................................................................................................... 34 Figura 8: Subproceso. ................................................................................................................................... 34 Figura 9: Nodo decisión/unión. .................................................................................................................... 34 Figura 10: Flujo de control de una tarea a otra. ........................................................................................ 34 Figura 11: Flujos de secuencia procedentes de un nodo. ...................................................................... 35 Figura 12: Flujo de secuencia...................................................................................................................... 35 Figura 13: Carriles. ........................................................................................................................................ 35 Figura 14: Participantes. ............................................................................................................................... 36 Figura 15: Objetos de dato. .......................................................................................................................... 36 Figura 16: Modelos de proceso de negocio Atender Paciente modelado con notación BPMN. ....... 37 Figura 17: Etiquetas del formato .bpmn ..................................................................................................... 42 Figura 18: Etiquetas formato .xpdl .............................................................................................................. 43 Figura 19: Diagrama de Casos de Uso del sistema IEEMPN ................................................................ 44 Figura 20: Diagrama de clases de diseño del sistema IEEMPN. .......................................................... 45 Figura 21: Interfaces inicial y principal del sistema IEEMPN.................................................................. 47 Figura 22: Fragmento de la base de casos creada a partir de los modelos. ....................................... 52 Figura 23: Gráfico asociado a la Tabla 16. ................................................................................................ 57. viii.

(10) ÍNDICE DE TABLAS Tabla 1: Lista de elementos centrales del BPD ........................................................................................ 15 Tabla 2: Características de BonitaSoft y BizAgi ....................................................................................... 18 Tabla 3: Resumen de métricas asociadas a procesos de negocio. ...................................................... 25 Tabla 4: Grupo I de métricas correspondiente a la propuesta. .............................................................. 32 Tabla 5: Grupo II de métricas correspondientes a la propuesta. ........................................................... 32 Tabla 6: Resultados de la aplicación de las métricas del Grupo I. ........................................................ 37 Tabla 7: Analogía entre elementos de software y procesos de negocio. ............................................. 39 Tabla 8: Analogía entre la métrica de Complejidad de Automatización y la métricas Grupo I propuestas. ..................................................................................................................................................... 39 Tabla 9: Resultados de la aplicación de las métricas GRUPO II ........................................................... 40 Tabla 10: Sentencia computacional para el cálculo de las métricas. .................................................... 43 Tabla 11: Relación de modelos de procesos de negocio........................................................................ 51 Tabla 12: Variables introducidas en el modelo. ........................................................................................ 53 Tabla 13: Resumen del modelo. ................................................................................................................. 53 Tabla 14: Ajuste del modelo. ....................................................................................................................... 54 Tabla 15: Ecuación de regresión. ............................................................................................................... 55 Tabla 16: Modelo clasificados según su complejidad. ............................................................................. 56 Tabla 17: Significación de las métricas Grupo I en la predicción del esfuerzo. ................................... 57 Tabla 18: Significación de las métricas Grupo II en la predicción del esfuerzo................................... 58 Tabla 19: Lista de elementos centrales del BPD ...................................................................................... 67 Tabla 20: Medidas Base. Eventos. ............................................................................................................. 70 Tabla 21: Medidas Base. Actividades. ....................................................................................................... 71 Tabla 22: Medidas Base. Nodos decisión/unión....................................................................................... 71 Tabla 23: Medidas Base. Flujo de secuencia. .......................................................................................... 71 Tabla 24: Medidas Base. Carriles. .............................................................................................................. 72 Tabla 25: Medidas Base. Artefactos. .......................................................................................................... 72 Tabla 26: Medidas Derivadas. ..................................................................................................................... 73. ix.

(11) INTRODUCCIÓN MODELO PARA ESTIMAR EL ESFUERZO QUE DEMANDA LA AUTOMATIZACIÓN DE PROCESOS DE NEGOCIO _________________________________________________________________________________________________. INTRODUCCIÓN El desarrollo de productos software ha impactado de forma significativa en la sociedad y en los últimos años ha marcado pautas en el perfeccionamiento de las organizaciones empresariales. El proyecto de software es un caso particular de proyecto, donde existe una gran incertidumbre sobre: el resultado final, su costo, sus riesgos, así como el esfuerzo y tiempo que implica su desarrollo. El producto final es intangible desde el punto de vista físico, su valor depende no sólo de su corrección, sino del momento en que se pone en servicio, la calidad apreciada por el usuario, su facilidad de uso, mantenimiento y extensión (O'Farrill Fernández 2012). Dentro de la disciplina Gestión de Proyectos, la planificación es una de las etapas más importantes en el desarrollo de cualquier proyecto de software. Comprende actividades tales como ámbito de software, recursos y estimación. La estimación es un punto clave para lograr una adecuada planificación. Su objetivo es predecir las variables involucradas en el proyecto, esfuerzo de desarrollo, tiempo de duración, recursos necesarios, costos, etc., con determinado grado de certeza, tratando así de aportar una predicción de algún indicador importante para la gestión de proyectos de software. El desarrollo de software requiere de la estimación como una herramienta para controlar. y administrar los recursos que se necesitan y utilizan antes y durante el. desarrollo de un proyecto. No se puede considerar la estimación como una ciencia exacta ya que existen numerosas variables humanas, técnicas, del entorno, entre otras, que intervienen en ésta y que pueden afectar los resultados finales. Sin embargo, cuando es llevada a cabo en. forma. sistemática,. se pueden. lograr resultados con un grado. aceptable de riesgo y convertirla en un instrumento útil para la toma de decisiones. Aunque se trabaja en la mejora del proceso de producción de software, aún existen retos para los especialistas encargados del desarrollo de ese tipo de sistemas. Uno de los retos es el proceso de estimación de variables como el tiempo, el esfuerzo y los costos. Uno de los problemas de algunos modelos de estimación es que son dependientes del juicio 1.

(12) INTRODUCCIÓN MODELO PARA ESTIMAR EL ESFUERZO QUE DEMANDA LA AUTOMATIZACIÓN DE PROCESOS DE NEGOCIO _________________________________________________________________________________________________. experto y requieren gerentes con experiencia para aplicarlos. La tendencia actual es desplazarse hacia metodologías ágiles con equipos altamente reducidos, motivados y comprometidos con la realización del proyecto (O'Farrill Fernández 2012). Independizar la estimación del juicio experto aumenta la credibilidad de la industria, facilita la relación entre clientes y desarrolladores aumentando su transparencia. Puede ser el comienzo de contratos que no se basen en un precio cerrado en el momento en que menos se sabe del proyecto, sino en un cálculo de acuerdo a las condiciones de ejecución del mismo y la complejidad del sistema a construir. De acuerdo con (Salvetto 2006), esto contribuye a poner en evidencia, sobre bases objetivas, los riesgos que introducen las fechas fijadas con criterios no técnicos, y apoya la gestión conjunta de los cambios, plazos, alcance de los proyectos y los riesgos derivados de ellos. Un aspecto que incide directamente en la estimación de tiempo, esfuerzo y costos de un producto software es sin dudas la complejidad de este. Mientras más complejo es el producto a desarrollar, mayor será el tiempo que se invertirá en su construcción, el esfuerzo que demandará su realización y los costos asociados. Resultados interesantes encontrados en (Moløkken & Jørgensen 2004) demuestran que entre el 60 y el 80% de los proyectos analizados sobrepasaron el tiempo y esfuerzo planificados y que el método de estimación empleado de manera más frecuente es el basado en el juicio del experto, a pesar de que existen múltiples técnicas algorítmicas y no algorítmicas para resolver este problema (Stutzke 1996), (Sandhu et al. 2008) y (Attarzadeh & Hock Ow 2010). Con un método de estimación basado en criterio de expertos o de especialistas los expertos se lanzan a estimar el nivel de complejidad del proceso haciendo uso esencialmente de los conocimientos o experiencia adquiridos en el desarrollo de proyectos similares. Esto representa un riesgo, ya que cada proyecto es único independientemente de por quién sea desarrollado y pudiera suceder que la experticia de los especialistas no sea suficiente para estimar dicha complejidad. Por otra parte con un método de estimación basado en métricas se pueden definir métricas de complejidad teniendo en cuenta que todas las métricas de software definen, de una u otra forma la medición de la complejidad; tales como el volumen, el tamaño, las anidaciones, el costo (estimado), la agregación, la configuración, y el flujo. Dentro de las 2.

(13) INTRODUCCIÓN MODELO PARA ESTIMAR EL ESFUERZO QUE DEMANDA LA AUTOMATIZACIÓN DE PROCESOS DE NEGOCIO _________________________________________________________________________________________________. métricas antes mencionadas, las más utilizadas para medir el nivel de complejidad son las métricas de tamaño (Nieto 2008). Las métricas de tamaño se pueden clasificar en dos grupos, las métricas que determinan el tamaño a partir del código fuente del sistema y las métricas de tamaño funcional. Desde ambas métricas se plantea una relación directamente proporcional con la complejidad, estableciendo que el desarrollo de cierto producto será tan complejo según sea su tamaño. A pesar de ser estas métricas comúnmente empleadas en la actualidad, tienen la dificultad de que para calcularlas se necesitan elementos que están disponibles sólo en etapas avanzadas del desarrollo del producto, lo cual no permite contar con una estimación del tamaño del software a desarrollar en etapas bien tempranas de su ciclo de vida. Esto trae como consecuencia que si el proyecto no es viable por alguna razón, haya pérdidas de recursos, esfuerzos y costos para las organizaciones involucradas en el proceso. A partir de lo planteado con anterioridad surge la primera interrogante y punto de partida de la presente investigación: ¿Cuál es la etapa más temprana para predecir la complejidad del producto software a desarrollar? Según se plantea en (O'Farrill Fernández 2012), la etapa más temprana en la concepción de un producto de software es la identificación y el estudio de los procesos de negocio de la organización a la que servirá de apoyo el sistema informático. Los procesos de negocio no forman parte del espacio de solución en la confección de un producto software, sin embargo, es a partir de estos que se identifica la necesidad de construir un producto informático y concebir las funcionalidades imprescindibles que se deben implementar en el sistema. En los últimos años diversos factores como la globalización o el incremento de la competencia, han forzado a las organizaciones a mejorar y a centrarse en sus procesos de negocio (Rolón Aguilar 2009). Esto ha constituido un medio para subsistir y progresar y las organizaciones han tenido que adaptarse a las nuevas condiciones comerciales, así como responder a las presiones competitivas en las que deben asegurar la calidad de sus productos y la eficiencia de sus servicios, teniendo en cuenta no solo el entorno que les rodea (proveedores, competidores, clientes, etc.), sino también la evaluación de sus sistemas de información. 3.

(14) INTRODUCCIÓN MODELO PARA ESTIMAR EL ESFUERZO QUE DEMANDA LA AUTOMATIZACIÓN DE PROCESOS DE NEGOCIO _________________________________________________________________________________________________. Teniendo en cuenta el auge que ha cobrado el seguimiento, control y mejora continua de los procesos de negocio en el contexto empresarial, se presenta la segunda interrogante de la investigación: ¿Cómo evaluar la complejidad de los modelos de procesos de negocio? Elvira Rolón en su tesis doctoral (Rolón Aguilar 2009), da a conocer un conjunto de métricas para evaluar los procesos de negocio desde el punto de vista de su complejidad estructural, en la búsqueda de mejorar la calidad de los modelos de procesos de negocio, así como su mantenibilidad y usabilidad. Años más tarde (O'Farrill Fernández 2012) propone un procedimiento para la industria cubana del software, basado en métricas, que evalúa la complejidad de informatizar los procesos de negocio, cuyas métricas en algunos casos son comunes con las planteadas en (Rolón Aguilar 2009). En dicho procedimiento se realiza la evaluación de la complejidad de un modelo de proceso de negocio de acuerdo a tres criterios, Complejidad Alta, Complejidad Media y Complejidad Baja. En (Bandomo Toledo 2014), a partir de la investigación de (O'Farrill Fernández 2012) y su definición de métricas que inciden directamente en informatización de los procesos de negocio, se realizó una predicción de la complejidad de estos, utilizando técnicas de inteligencia artificial. Esta predicción aportaba información similar al procedimiento anterior, clasificando la complejidad de informatización atendiendo a los mismos criterios anteriormente especificados. El modelo predictivo obtenido en (Bandomo Toledo 2014) fue implementado en (Esquivel Ariz et al. 2014) . Para ello se diseñó y desarrolló una herramienta con el objetivo extraer los valores correspondientes a las métricas involucradas en dicho modelo y calcular a partir de estas la complejidad de informatización de procesos de negocio, utilizando como base su diagrama o representación gráfica. Teniendo en cuenta la actualidad del tema y las constantes búsquedas para obtener una estimación del esfuerzo empleado en el desarrollo de productos software lo más acertada y cercana a la realidad posible, estos criterios, aunque útiles, carecen de exactitud y pueden ser interpretados de disímiles maneras ya que, en el caso de que un proceso posea una complejidad Alta, no da la medida de cuánto va a tardar la automatización del mismo. De ahí que el presente trabajo se centre en al análisis de modelos de procesos de negocio a fin de extraer información valiosa que influya directamente en la automatización 4.

(15) INTRODUCCIÓN MODELO PARA ESTIMAR EL ESFUERZO QUE DEMANDA LA AUTOMATIZACIÓN DE PROCESOS DE NEGOCIO _________________________________________________________________________________________________. de los mismos y permita estimar el esfuerzo en horas/hombre necesario para ello. De acuerdo a lo planteado se identifica como problema de investigación el siguiente: ¿Cómo calcular el esfuerzo que demanda la automatización de un proceso de negocio a partir de su representación gráfica? Para dar solución a esta interrogante se propone como objetivo general del presente trabajo: Definir un modelo estadístico que permita estimar el esfuerzo que demanda la automatización de procesos de negocio a partir de su representación gráfica. Del objetivo general se desglosan los siguientes objetivos específicos: 1. Estudiar las propuestas existentes en la literatura, relacionadas con la evaluación y medición de procesos de negocio. 2. Proponer un conjunto de métricas para la predicción del esfuerzo que demanda la automatización de los modelos de proceso de negocio. 3. Definir un modelo estadístico para la predicción del esfuerzo. 4. Desarrollar una herramienta informática que permita la obtención de los valores asociados a las métricas seleccionadas e incluya la estimación del esfuerzo a partir del modelo de predicción obtenido. Como preguntas de investigación se plantean las siguientes. 1. ¿Cuáles son métricas que influyen directamente en el esfuerzo de automatización de procesos de negocio? 2. ¿Cómo conformar la base de casos necesaria para el conteo de las métricas propuestas de forma automática, a partir de los modelos recolectados? Valor de la investigación Científicos 1. Propuesta de un conjunto de métricas, a partir de la representación de los procesos de negocio, que inciden en la predicción del esfuerzo que demanda el proceso de desarrollo de software. 2. Propuesta de un modelo para la estimación del esfuerzo que requiere la automatización de un proceso de negocio a partir de su diagrama.. Prácticos 5.

(16) INTRODUCCIÓN MODELO PARA ESTIMAR EL ESFUERZO QUE DEMANDA LA AUTOMATIZACIÓN DE PROCESOS DE NEGOCIO _________________________________________________________________________________________________. 1. Herramienta automatizada que permite extraer de los modelos de procesos de negocio, el valor de cada métrica propuesta y determinar, a partir del modelo de estimación, el esfuerzo. Estructura del documento por capítulos Capítulo I: Se presenta un estudio del modelado de procesos de negocio, detallando notaciones y herramientas con este fin. Se hace énfasis especial en la notación BPMN por sus siglas en inglés Business Process Modeling Notation, así como la forma y objetivos de medir los modelos de proceso de negocio en el contexto de investigación actual. Capítulo II: Se define el conjunto de métricas asociadas a modelos de proceso de negocio que servirá de base a la predicción del esfuerzo de automatización de los mismos. Se da a conocer la herramienta implementada IEEMPN para la captura de los valores correspondientes a las métricas asociadas a modelos de procesos de negocio Capítulo III: Se presenta el conjunto de datos recolectados, modelos de procesos de negocio, punto de partida para lograr los resultados de la investigación. Se realiza el procesamiento de los datos a partir de técnicas estadísticas obteniendo el modelo de predicción del esfuerzo. Se incluye en la herramienta el cálculo del esfuerzo a partir del modelo predictor encontrado, comprobando la calidad del modelo para cada uno de los casos recolectados.. 6.

(17) Capítulo I. MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. 7.

(18) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES. En este capítulo se presenta un estudio del modelado de procesos de negocio, detallando notaciones y herramientas de modelado. Se hace énfasis especial en la notación BPMN por sus siglas en inglés Business Process Modeling Notation, así como la forma y objetivos de medir los modelos de procesos de negocio en el contexto de la investigación actual. Modelado de procesos de negocio. Desde el punto de vista empresarial los procesos de negocio son definidos como el “conjunto de dos o más procedimientos o actividades enlazadas que realizan de forma colectiva un objetivo del negocio o meta política, normalmente dentro del contexto de una estructura organizacional en donde se definen roles funcionales y relaciones” (WfMC 1999). Por su parte, en (Jiménez et al. 2003) se definen como un “conjunto estructurado de actividades, diseñado para producir una salida específica o lograr un objetivo, que describen cómo es realizado el trabajo de la empresa y caracterizándose por ser observables, medibles, mejorables y repetitivos”. La Figura 1 representa los elementos esenciales de un proceso de negocio.. Figura 1: Elementos de un proceso de negocio. 8.

(19) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. Los procesos de negocio son representados de forma gráfica mediante un diagrama o modelo, el cual refleja las acciones indispensables para producir los resultados esenciales de la organización, siendo activado en función del cliente, independientemente de cómo, cuándo, por quién o el medio por el cual se produzcan dichos resultados, mostrando lo que un sistema hace o debe hacer de manera independiente a la implementación (Wedemeijer et al. 2004). De esta forma es importante destacar que el modelado de los procesos de negocio y su definición innovadora y flexible es fundamental para el funcionamiento exitoso de cualquier institución empresarial. Estos modelos pueden ser utilizados como base para programas de planeación, ejecución y mejora continua de la organización; para la retención del conocimiento y aprendizaje, la visualización de los procesos, la capacitación de nuevo personal; sirviendo además como marco para la definición de métricas y para ayudar a la organización a cumplir con los requisitos de auditoría y evaluación (Browning 2002). Entre los principales objetivos del modelado de procesos de negocio en (Multamäki 2002) se destaca: la mejora del entendimiento de una situación, así como su comunicación y que puedan ser vistos como una herramienta para alcanzar las metas de un proyecto de desarrollo. Notaciones para el modelado de procesos de negocio. Un lenguaje para el modelado de procesos de negocio requiere un conjunto de requisitos indispensables que le permitan describir de forma correcta la complejidad que estos presentan. Varios autores destacan las características que deben estar presentes en un lenguaje de modelado para que cumpla su propósito. En (Haberl 2003) y (Lonjon 2004) se proponen las siguientes características:  Ser capaces de modelar todas las complejidades que presentan los procesos de negocio,. incluyendo:. secuencia,. bifurcación,. enlazamiento,. construcción. de. concurrencia, intervalos, vencimientos, fallos y agregación.  Tener un medio de distinción de roles y de asignación de las diversas tareas.  Ser una representación gráfica inequívoca del lenguaje.  Especificar cómo las instancias de procesos serán disparadas e identificadas a lo largo de toda su ejecución. 9.

(20) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________.  El lenguaje no debe mezclarse con detalles de protocolos de comunicación.  Tener una notación intuitiva que sea fácilmente adoptada por el usuario.  Tener un metamodelo y un vocabulario, es decir un grupo de conceptos y relaciones que esté estricta y consistentemente definido para proporcionar un fundamento sólido a las diversas propuestas de procesos de negocio.  Permitir una clasificación del metamodelo y de la notación para cada nivel de análisis del proceso de negocio, como la organización e integración de las tecnologías de la información. La clasificación debe estar acompañada por un mecanismo para navegar entre los diferentes niveles de análisis. Según estas características, un leguaje de modelado de procesos de negocio incluye un conjunto de reglas sintácticas y semánticas que permitan elaborar diagramas que relacionen elementos válidos para el negocio. Dentro de los lenguajes o técnicas comúnmente utilizados para el modelado de procesos de negocio se encuentran: los Diagramas de Flujos de Datos (DFDs, Data Flow Diagrams), los Diagramas de Flujo de Control (CFD, Control Flow Diagrams), los Diagramas de Gantt, Diagramas de PERT y los diagramas de la familia IDEF, especialmente IDEF0 e IDEF3, Redes de Petri, Cadena de Procesos Dirigida a Eventos (EPC, Event Driven Process Chain), entre otros. En la actualidad organizaciones como Object Management Group (OMG), Business Process Management Initiative (BPMI) y Workflow Management Coalition (WfMC) ofrecen una serie de estándares para el modelado de procesos de negocios, así como lenguajes de definición. Esto se debe a la gran diversidad de propuestas para modelar procesos de negocio, considerando fundamental la estandarización en los lenguajes de modelado. Algunos de los estándares usados para tecnologías y prácticas referentes a la Gestión de Procesos de Negocio (BPM, Business Process Management) fueron desarrollados para otros propósitos relacionados a procesos, tales como UML (Unified Modeling Language) desarrollado con un objetivo totalmente diferente, o la familia de lenguajes IDEF que incluso surgió mucho antes de la concepción de los primeros Sistemas de Gestión de Procesos de Negocio (BPMS, Business Process Management System). A continuación se presentan algunos de los estándares y notaciones más relevantes relacionadas con BPM. 10.

(21) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. • Business Process Execution Language for Web Services (BPEL4WS) (IBM et al. 2002) ofrece un lenguaje de ejecución para procesos de negocios distribuidos y transaccionales basado en el modelo matemático Pi-Calculo. Da soporte a la orquestación de múltiples procesos independientes que se comunican y utiliza servicios Web en base a estándares para la comunicación proceso a proceso y la integración con sistemas de terceras personas. • Business Process Modeling Language (BPML) (BPMI. 2002) es un metalenguaje para el modelado de procesos de negocio. Proporciona un modelo de ejecución abstracto para procesos de negocio colaborativos y transaccionales basados en el concepto de una máquina transaccional de estado finito. BPML ofrece soporte explícito para transacciones distribuidas sincrónicas y asincrónicas, y por lo tanto puede ser usado como un modelo de ejecución lo cual le permite gran flexibilidad para adaptarse a situaciones cambiante de los negocios. • Business Process Modeling Notation (BPMN) (OMG 2011) es la primera notación gráfica específica para procesos de negocio basada en estándares, que permite a los analistas de negocios, diseñadores de procesos e ingenieros software diseñar gráficamente procesos de negocio de principio a fin, con la característica de que pueden ser automáticamente traducidos en procesos totalmente ejecutables usando el lenguaje BPEL. • XML Process Description Language (XPDL). (WfMC 2005), es un lenguaje de. descripción basado en XML para procesos de flujo de trabajo basado en el modelo matemático de las Redes de Petri. XPDL proporciona un modelo de transición del flujo de control, basado en un documento abstracto conocido como caso, dando soporte al concepto de recursos, organizaciones, así como a procesos anidados o encadenados. Sin embargo, no da soporte a procesos colaborativos, transacciones o excepción semántica. Desarrollado principalmente para el intercambio de definición de procesos, es un subconjunto funcional riguroso de lenguajes de procesos más generales estructurados en bloques tales como BPEL y BPML. • Integration Definition Method (IDEF0, IDEF3) (FIPS. 1993),(Mayer et al. 2005).IDEF0 es un estándar de modelado de procesos consistente de un mapa de alto nivel de los principales usos de los procesos de negocio de una compañía, y proporciona una 11.

(22) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. descomposición funcional de esos procesos dentro de secuencias siempre más finas de actividades describiendo decisiones, acciones y actividades. IDEF3, proporciona una metodología para el descubrimiento, colección y documentación de procesos de negocio de alto nivel no ejecutables. • Diagramas de Actividad UML 2.0 (OMG. 2003). El origen de los diagramas de actividad radica en el desarrollo del software, sin embargo en la versión 2.0 de UML se diseñaron para modelar procesos de negocios y flujos en sistemas software. Sus principales conceptos son las actividades y los carriles mediante los cuales representan los roles. • Event Driven Process Chain (EPC) (Sheer 1999). Desarrollado para el modelado de procesos de negocio con el objetivo de ser fácilmente entendido y usado por gente de negocios. Los elementos básicos de EPC son las funciones para modelar las actividades de un proceso de negocio y los eventos creados para procesar funciones o para actores externos al proceso. La presente investigación se basará en la notación BPMN para el estudio y selección de elementos significativos sobre modelos de procesos de negocio, por ser la notación estándar diseñada específicamente para el modelado de procesos de negocio y la más ampliamente aceptada y difundida en el mundo empresarial. A continuación se detallan características que argumentan esta afirmación. Business Process Modeling Notation (BPMN). La Notación para el Modelado de Procesos de Negocio (BPMN) (OMG 2011), es un estándar para el modelado de procesos de negocios y servicios Web, propuesto inicialmente por la BPMI, organización que actualmente trabaja de manera conjunta con la OMG en la promoción y desarrollo de estándares abiertos, completos y totalmente libres basados en XML, con el objetivo de proporcionar el soporte necesario al ciclo de vida de la gestión de procesos de negocio, desde su diseño, a través del desarrollo, ejecución, mantenimiento y optimización, creando un puente estandarizado para el vacío existente entre las fases de diseño del proceso de negocio y su implementación (White 2004). BPMN es una notación gráfica que muestra los pasos de un proceso de negocio. La notación ha sido diseñada específicamente para coordinar la secuencia de los procesos y 12.

(23) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. los mensajes que fluyen entre los participantes del mismo, con un conjunto de actividades relacionadas. Objetivo y alcance de BPMN Según se describen en (OMG 2006) Los principales objetivos de BPMN son: • Proporcionar una notación fácilmente entendible por todos los usuarios de negocios, desde los analistas que crean el bosquejo inicial del proceso, hasta los desarrolladores responsables de implementar la tecnología que ejecutará el proceso y las personas que van a dirigir y controlar dicho proceso, proporcionando soporte a la gestión de procesos de negocio y a la habilidad de modelar procesos de negocio complejos. • Asegurar que los lenguajes XML diseñados para la ejecución de procesos de negocio como BPEL4WS y BPML puedan ser visualizados con una notación común orientada a negocios. Por tanto, el interés de este estándar radica en proporcionar a los negocios la capacidad de definir y entender sus procedimientos tanto internos como externos, a través de un diagrama de procesos dando la habilidad para comunicar estos procesos en una manera estándar. Sin embargo, el alcance de BPMN está restringido a dar soporte sólo a los conceptos de modelado que son aplicables a procesos de negocio, lo cual significa que otros tipos de modelado hechos por las organizaciones para propósitos de negocios tales como la estructura y recurso organizacional, fallas funcionales, modelos de datos e información, estrategia y reglas de negocio, quedan fuera del alcance de este estándar. Entre las principales características de BPMN se incluyen: . Facilita el diseño de procesos de alto nivel, así como procesos complejos con múltiples niveles de detalle.. . Proporciona la noción de conceptos de datos para modelar documentos, datos y otros objetos que son usados y actualizados durante un flujo de procesos.. . Proporciona una notación de modelado que enlaza la definición del negocio al mapa de la ejecución del proceso.. . Es extensible y permite usar asociaciones y anotaciones para interrelacionar con otros artefactos dentro o fuera del sistema.. . Modela servicios Web haciendo el trabajo de los mismos en un proceso de cuatro etapas: diseño, simulación, publicación y orquestación 13.

(24) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. . Define un Diagrama de Procesos de Negocio (BPD, Business Process Diagram) que está basado en una técnica de diagrama de flujo adaptada para la creación de modelos gráficos de operaciones de procesos de negocio.. Diagrama de Procesos de Negocio (BPD). Dentro de un BPD existe un conjunto de elementos gráficos que permiten representar un proceso de negocio y hacen fácil el entendimiento del proceso, tanto para usuarios del negocio como para desarrolladores. Desde la aparición de BPMN, y mucho más desde la absorción de BPMI por parte de la OMG, la notación BPMN ha tenido un éxito notable y como consecuencia de este éxito han ido apareciendo herramientas que dan soporte a esta notación. Los elementos de BPMN que componen un BPD se pueden clasificar en cuatro categorías básicas según (OMG 2011):  Objetos de Flujo: Eventos, Actividades, Nodos o Compuertas (acrónimo del inglés Gateway)  Objetos de Conexión: Flujo de Secuencia, Flujo de Mensajes, Asociación  Canales: Piscina, carriles (acrónimo del inglés Pool, Lane)  Artefactos: Objetos de Datos, Grupos, Anotaciones. 14.

(25) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. Figura 2: Diagrama de Proceso de Negocio modelado utilizando la notación BPMN. En la Tabla 1 se muestran los elementos pertenecientes a las cuatro categorías centrales de BPMN: Objetos de Flujo, Objetos de Conexión, Canales y Artefactos, que forman los elementos básicos para la representación de un modelo de negocios simple, entendible por cualquier audiencia. Cada categoría de elementos básicos mostrada en la Tabla 1, se compone a su vez de una lista completa de elementos con los cuales se da el soporte a los requisitos de complejidad sin cambiar drásticamente la apariencia y sentido del diagrama. La descripción completa de todos los elementos que componen la notación estándar BPMN se presentan en el Anexo A. Tabla 1: Lista de elementos centrales del BPD. Objetos de flujo. Elemento. 1. Evento. Actividad. Descripción Es algo que sucede durante el curso de un proceso de negocio y afectan el flujo de los procesos y usualmente tienen una causa (disparador) o un impacto (resultado). Hay tres tipos de eventos en base a cuando afectan el flujo: de Inicio, Intermedio y Final Es un término genérico el trabajo que realiza la empresa. Puede ser atómica o no-atómica. Los tipos de actividades que son una parte de un modelo de procesos son: Procesos, Sub-procesos y Tareas.. Tomados de la Herramienta para el modelado de procesos de negocio BizAgi.. 15. Notación Gráfica1.

(26) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. Entrada (Decisión). Es usada para controlar la divergencia y convergencia de flujos de secuencia, por lo tanto determinará la ramificación, bifurcación o unión de las trayectorias.. Flujo de Secuencia. Es usado para mostrar el orden en que las actividades serán realizadas en un proceso.. Flujo de mensaje. Es usado para mostrar el flujo de los mensajes entre dos participantes que están preparados para enviarlos y recibirlos.. Asociación. Es usada para asociar información (como texto y gráficos) con Objetos de Flujo.. Pool. Swimlanes. Objetos de conexión. ________________________________________________________________________________________. Carriles. Artefactos. Objetos de datos. Grupos. Anotación de texto. Representa a un participante en un proceso y actúa como un carril y contenedor gráfico para dividir un conjunto de actividades de otros Pools. Es una sub-división dentro de un pool y extiende la distancia entera del Pool, tanto horizontal como vertical. Son usados para organizar y categorizar actividades. Son considerados artefactos debido a que no tienen ningún efecto directo en el Flujo de secuencia o Flujo de mensaje del proceso, pero proporcionan información acerca de cuáles actividades requieren ser realizadas y/o que es lo que producen.. La agrupación puede ser usada para propósitos de documentación o análisis. También pueden ser usados para identificar las actividades de una transacción distribuida que es mostrada a través de Pools. Son un mecanismo para que el modelador proporcione información adicional para el lector de un diagrama BPMN.. Herramientas para el modelado BPMN Según (OMG 2011) algunas de las herramientas que soportan esta notación son las siguientes:  Appian Enterprise 5 Business Process Management Suite  aXway: Process Manager  BizAgi  BOC Information Systems: ADONIS  Borland Together Products: Together Architect 2006 and Together Designer 16.

(27) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________.  Casewise: Corporate Modeler  BonitaSoft Open Solution En el momento que se desarrolla la investigación no se tuvo acceso a varias de las herramientas mencionadas o se hacía necesaria la licencia para su instalación, la cual tampoco era accesible. En el caso de BizAgi (Suite 2014) y BonitaSoft Open Solution (BonitaSoft 2011), se hizo posible su manipulación y luego de realizar un estudio se demostró que son herramientas líderes en el modelado de procesos de negocio, capaces de representar más de 40 patrones workflow de procesos de negocio con una gran variedad de símbolos para la representación del lenguaje natural. Ambas herramientas permiten exportar sus modelos a formatos XML interpretables, .xpdl y .bpmn respectivamente. Es válido destacar que los modelos de procesos de negocio recopilados para el desarrollo de la presente investigación fueron modelados por ambas herramientas. En la Tabla 2 se muestra un resumen de las características de ambas herramientas atendiendo a diversos aspectos.. 17.

(28) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. Tabla 2: Características de BonitaSoft y BizAgi Aspectos Servidores. BonitaSoft. BizAgi. Contenedor de Servlets Versión (JBoss, Tomcat, etc.). .NET. -. IIS. (Microsoft. Internet Information Services) Versión. J2EE. -. Weblogic. /. Websphere / JBoss Entorno de desarrollo Bases de datos. Propio basado en Eclipse Propio (Multiplataforma, Java) .NET) Hsql, MySQL,. (Multiplataforma,. Java,. PostGreeSql, SQL Server, Oracle Oracle,. SQL. Server Formatos. XPDL, BPMN 2.0, JBPM XPDL, Visio, (BPM BizAgi) 3.2, (BPM Bonita). Validaciones. Si. Si. BPMN 2.0. Si. Si. Diferencias de BPMN con otros estándares XPDL, BPML, y BPEL son lenguajes de modelado de procesos con enfoque a la ejecución del proceso, y generalmente no son usados en las fases de análisis y diseño, ya que por definición no están diseñados para abarcar los niveles de la cadena de suministro y del análisis organizacional. Están expresados en sintaxis XML por lo que tienen un formato de intercambio estándar, sin embargo ninguno ofrece una notación gráfica estandarizada. Otra diferencia a distinguir entre los principales lenguajes de modelado, es la existente entre UML y BPMN. UML está orientado a objetos para el modelado de aplicaciones con enfoque en diseño de software. BPMN está orientado a procesos para el modelado de sistemas. Evaluación de los procesos de negocio En los últimos años el ámbito empresarial empeña esfuerzos significativos en el mejoramiento, entendibilidad y mantenibilidad de los procesos de negocio. Esta popularidad se ha visto propiciada por el surgimiento de nuevas y diferentes propuestas 18.

(29) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. para la gestión de los mismos, lo que ha traído como consecuencia que se haya incrementado considerablemente la cantidad y la variedad de usuarios y diseñadores de modelos y de los propósitos para los cuales son usados dichos modelos (Becker et al. 2000). De ahí que investigaciones recientes (Mendling & Neumann 2007), (Vanderfeesten, Cardoso, et al. 2007), (Ghani et al. 2008),(Rolón Aguilar 2009),(O'Farrill Fernández 2012) se enfocan en la medición, según diversos indicadores, de la calidad y/o complejidad de los modelos de procesos de negocio, siendo este un tema que ha cobrado auge en la actualidad. La evaluación de la complejidad de procesos de negocio como el punto de partida para obtener modelos de mayor calidad, más fáciles de entender y de mantener en un futuro, es una de la ideas más comunes presentes en las propuestas encontradas en la literatura. Jorge Cardoso en (Cardoso 2005a) define la complejidad de un proceso de negocio como el grado con el cual éste es difícil de analizar, entender o explicar. Esto explica el creciente interés en evaluar la complejidad de los procesos de negocio, ya que con la medición y control de los procesos, se pueden obtener modelos más fáciles de entender y de modificar. Trabajos incipientes en este tema son los presentados por Daneva y Tjaden en 1996. Donde se introduce un conjunto de indicadores de complejidad para modelos con notación EPC (Event Driven Process Chain) basado en los siguientes atributos visuales del modelo: cohesión de la función, cohesión del evento y cohesión de un conector lógico (Daneva et al. 1996). Diversas propuestas iniciales de medidas de complejidad para modelos de proceso de negocio han sido recopiladas y analizadas por algunos autores. Uno de estos estudios es el presentado en el reporte técnico que aparece en (Latva-Koivisto 2001),. donde se. presenta una recopilación de medidas para la complejidad de los procesos de negocio encontradas en la literatura, con la finalidad de encontrar una medida de complejidad estructural que cumpla los siguientes criterios: validez, confiabilidad, facilidad de implementación, independencia de otras métricas relacionadas, habilidad para medir la complejidad de procesos reiterativos, modularidad, aditividad e independencia del nivel de detalle en el modelado.. 19.

(30) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. Otro aspecto importante que se destaca en las propuestas de medición de procesos de negocio, es que la gran mayoría parten de la adecuación o adaptación de métricas originalmente definidas para la medición de procesos de desarrollo de software. Estas propuestas generalmente están enfocadas a la definición de métricas de calidad, que como resultado de su aplicación se espera que proporcionen las bases para obtener modelos de calidad. Un ejemplo de ello, es el trabajo presentado en (Reijers & Vanderfeesten 2004). Los autores inspirados en las semejanzas entre los programas software y los procesos workflow hacen un estudio de las métricas existentes para la calidad del software y su aplicabilidad al diseño de procesos workflow. Como resultado definen las medidas de cohesión y acoplamiento, las cuales se centran en el contenido de las actividades y tienen el propósito de ayudar a los diseñadores en la creación de modelos con una mejor calidad de ejecución y que sean más fáciles de entender por los usuarios. Estas medidas, posteriormente habrían de ser extendidas en diversas direcciones de acuerdo a los primeros hallazgos de carencias en la definición inicial (Vanderfeesten, Reijers, et al. 2007). El análisis comparativo de métricas de software y su aplicación en procesos de negocio pronto habría de generar nuevas propuestas. Algunas de estas propuestas en su momento fueron analizadas y discutidas en (Gruhn & Laue 2006). Aquí se explica cómo las ideas conocidas en la investigación acerca de las métricas de complejidad del software, podían ser usadas y extendidas para analizar la complejidad de modelos de procesos de negocio. Como resultado, surgió la propuesta basada en la idea de que al medir el peso cognitivo del modelo de proceso de negocio, se puede obtener información acerca de la facilidad o dificultad de entenderlo, por lo que asignan un peso cognitivo a los elementos del modelo de proceso de negocio, para posteriormente definir el peso cognitivo del modelo en su totalidad. Por otra parte, en (Ghani et al. 2008) se presenta de igual manera un reporte comprensivo de cómo las métricas de complejidad del software han sido adaptadas para analizar la complejidad de los actuales modelos de procesos de negocio. Otra de las principales propuestas que figuran en trabajos relacionados con la temática se hacen notar los estudios presentados en (Cardoso 2005b), (Cardoso 2005a), (Cardoso et 20.

(31) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. al. 2006). Los cuales tienen como objetivo evaluar la complejidad estructural de los modelos de procesos de negocio, para lo que se propone un conjunto de medidas para evaluar este indicador desde la perspectiva de sus flujos de control. Estas medidas, denominadas medidas CFC (Control-Flow Complexity) tienen como principal objetivo conseguir una gestión eficaz de los procesos, considerando para ello el análisis de la complejidad del proceso como aspecto básico. La definición de las medidas CFC se basa en la hipótesis de que el comportamiento de los flujos de control de un proceso es afectado por constructores tales como las divisiones y uniones (splits y joins). Matemáticamente, la medida CFC es aditiva. Esto es posible simplemente agregando el CFC a todos los constructores split y es calculado como sigue: CFC = ∑CFC XOR-split (a) + ∑CFC OR-split (a) + ∑CFC AND-split (a) Cuanto mayor sea el valor de CFC, mayor será la complejidad estructural total del proceso. Con el análisis de los flujos de control se busca evaluar la complejidad sin la ejecución directa del proceso. En (Cardoso et al. 2006) se presenta otra medida que involucra la complejidad. La métrica de complejidad de la interfaz incluye el número de entradas y salidas de un proceso. El acoplamiento se refiere al número de actividades relacionadas que contienen elementos de datos comunes y la cohesión expresa la coherencia entre las actividades de los modelos de procesos de negocio (Mendling 2009a). Otra propuesta interesante es la de Mendling y Neuman, quienes motivados por el supuesto de que los modelos de procesos de negocio son construidos por modeladores humanos y que su diseño está sujeto a una racionalidad limitada, consideran la comprensibilidad del modelo de proceso de negocio como el principal determinante para la probabilidad de error (Mendling & Neumann 2007). Mendling considera que la comprensibilidad de cualquier modelo por una persona es influenciado por una variedad de factores incluyendo factores relacionados al modelo (tamaño), factores personales (aptitud de modelado), conocimiento del dominio, lenguaje de modelado o diseño gráfico del modelo. En (Mendling 2009a) se analizan los aspectos relacionados al modelo, y concretamente se describe un conjunto de métricas que capturan diversos aspectos relacionados a la estructura y/o al estado de espacio del modelo de proceso discutiendo su impacto en la probabilidad de error. El conjunto de métricas definidas por Mendling se 21.

(32) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. subdividen en seis categorías que son: tamaño, densidad, particionalidad, interacción de conectores, ciclicidad y concurrencia. Otras propuestas de medidas para modelos de procesos de negocio, se pueden ver en (Huang & Kumar 2008) quienes presentan una propuesta sistemática para desarrollar métricas de calidad para modelos de procesos estructurados por bloques, que ofrecen menos poder expresivo que las redes de Petri, pero que tienen una semántica más fácil. Esta propuesta se basa en la noción de un mal puntaje que es usado para calcular la calidad y que debe ser el mismo para modelos equivalentes. Por su parte, en (Jung 2008) se introduce el concepto de entropía para la medición de los modelos de procesos de negocio. Jung considera que la medida de entropía para modelos de procesos puede ser usada para cuantificar su incertidumbre o variabilidad en base a la probabilidad de los flujos de control y al porcentaje de ejecución del proceso. Elvira Rolón en su tesis doctoral “Medidas para asegurar la calidad de los procesos de negocio” (Rolón Aguilar 2009) realiza una propuesta clara y abarcadora de métricas debidamente fundamentadas, obtenidas a partir de modelos de procesos de negocio con notación BPMN, la cual incluye un conjunto de experimentos que validan la influencia de estas métricas en la entendibilidad y mantenibilidad de los procesos de negocio. En la Figura 3 se muestra el conjunto de medidas base, correspondientes a los eventos, presentes en (Rolón Aguilar 2009). Otra propuesta interesante es el procedimiento para evaluar la complejidad de automatización de modelos de procesos de negocio dado a conocer en (O'Farrill Fernández 2012) y (Bandomo Toledo 2014) donde, entre otras, se definen las siguientes métricas: número de tareas, número de mecanismos de control y número de fronteras. Algunas de ellas semánticamente coinciden con las presentadas en (Rolón Aguilar 2009) aunque difieren en su denominación. Esto es algo común en las investigaciones revisadas, en las cuales las mismas métricas poseen nombres diferentes. La presente tesis, en su propuesta, identificará la procedencia de cada métrica en el caso que corresponda.. 22.

(33) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. Figura 3: Medidas base para eventos propuestas en (Rolón Aguilar 2009). Resumiendo, existe un gran volumen de literatura dedicado a la definición y discusión de numerosas métricas relacionadas con los procesos de negocio, derivadas usualmente de métricas de software (Güceğlioğlu & Demirörs 2005), (Cardoso et al. 2006), , (Vanderfeesten, Cardoso, et al. 2007), (Muketha et al. 2010). El tamaño del proceso es en ocasiones determinado usando la métrica de tamaño de software líneas de código asociado al número de actividades presentes en un proceso. Algunas métricas de tamaño usadas son número de actividades, decisión/unión (Cardoso et al. 2006), (Mendling 2009b), diámetro, densidad (Mendling 2009b).. 23.

(34) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. El esfuerzo en el contexto de los procesos de negocio. Hasta este momento los estudios realizados sobre modelos de procesos de negocio estuvieron dedicados a medir la complejidad y calidad desde el punto de vista estructural y funcional de los procesos de negocio. Sin embargo, resulta de interés investigar la relación que pudiera existir entre los procesos de negocio y la determinación del esfuerzo que requiere la automatización de los mismos. Uno de los acercamientos encontrados en la literatura al esfuerzo de desarrollo es la utilización del modelo COSMIC, método ampliamente aceptado para mediciones de tamaño funcional de software y establecido como un estándar internacional. Autores como (Lavazza & Bianco 2009) utilizan el modelo COSMIC para estimar a partir de diagramas UML el tamaño funcional del sistema. Su acercamiento es una estimación indirecta del esfuerzo a partir de modelos de procesos de negocio de negocio. Un propuesta más cercana al esfuerzo de desarrollo de procesos de negocio se presenta en (Aysolmaz et al. 2011). Aquí aparece un estudio en el cual se maneja el concepto de esfuerzo de automatización de procesos de negocio, seleccionando un conjunto de métricas para predecir dicho esfuerzo a partir de un total de diez modelos de procesos de negocio recopilados a lo largo de tres años. Teniendo en cuenta varias perspectivas: funcional, organizacional y de comportamiento; y realizando analogías con las métricas para evaluar software. Las métricas seleccionadas fueron:  Número de actividades (NOA).  Número de roles participantes (NOR)  Número de salidas de los procesos (NOO)  Complejidad del flujo de control (CFC) De esta forma en (Aysolmaz et al. 2011) se examinó el efecto de cada una de estas métricas en el esfuerzo de automatización y se concluye con un modelo de predicción del esfuerzo. Se debe destacar el pequeño número tanto de modelos en el procesamiento como de métricas seleccionadas. Estudios más recientes han incluido el cálculo del esfuerzo a partir de modelos de procesos de negocio, (Silveira et al. 2014) utilizando técnica de clusters. Tomando como. 24.

(35) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________. datos de entrada proyectos BPM recopilados, adquiriendo e infiriendo datos referentes al esfuerzo de los mismos. Se puede observar que la mayoría de las métricas comentadas en este capítulo pueden ser catalogadas como métricas de tamaño, pero estas han sido coleccionadas para otros fines, como el análisis de la entendibilidad de los modelos. Existen poco estudios realizados en años recientes centrados en el tamaño de los procesos de negocio con el fin de evaluar sus efectos en el esfuerzo de desarrollo de software. Tabla 3: Resumen de métricas asociadas a procesos de negocio. Año. Autor. 1996. Daneva, M.. Function Cohesion (FC). (Daneva et al. 1996). Event Cohesion (EC). Tjaden G. S.. Effectiveness Metrics. Complejidad, dinamismo e integración. Latva-Koivisto, A.. Coefficient of Network Complexity (CNC). (Latva-Koivisto 2001). Ciclomatic Number (S). Complejidad: Validez, confiabilidad, facilidad de implementación, intuitividad, independencia de otras métricas, medición de proceso iterativos, modularidad, aditividad,Indepedencia de tamaño.. 1996. Medidas. Complejidad-Cohesión. Cohesion of a Logical Connector (CLC). (Tjaden et al. 1996) 2001. Concepto Medible. Complexity Index (CI) Restrictiveness Estimator (RE) Number of a tress in a graph (T). 2004. 2006. and Coupling Reijers y Cohesion Vanderfeesten, Metrics I. (Reijers & Vanderfeesten 2004) Cognitive Complexity Gruhn & Laue (Gruhn & Laue 2006) 25. Complejidad: acoplamiento. Cohesión. y. Complejidad cognitivo. cognitiva-Peso.

(36) CAPÍTULO I MEDICIÓN DE LOS MODELOS DE PROCESOS DE NEGOCIO. TENDENCIAS ACTUALES.. ________________________________________________________________________________________ 2006. Control-Flow Cardoso, J. (Cardoso et al. (CFC) 2006). 2007. Mendling, J. (Mendling Neumann 2007). 2007. 2008. 2008 2009. 2011. 2012. Error Metrics. Comprensibilidad: Tamaño, particionalidad, interacción de ciclicidad y concurrencia. &. Vanderfeesten, I. (Vanderfeesten, Reijers, et al. 2007) Huang, Z. & Kumar, A. (Huang & Kumar 2008) Jung, J-Y (Jung 2008) Rolón, E. (Rolón Aguilar 2009) Aysolmaz, B. (Aysolmaz et al. 2011). O’Farril Fernández L. (O'Farrill Fernández 2012). Complexity Complejidad-Flujos de control. densidad, conectores,. Cross-Connectivity (CC). Calidad: Conectividad. Métricas de Calidad. Calidad: Puntuación de la mala calidad para procesos estructurados en bloques Variabilidad: Incertidumbre de la ejecución del proceso Calidad: Complejidad. Entropy metric Medidas Base Medidas Derivadas. Número de actividades Esfuerzo (NOA). Número de roles participantes (NOR) Número de salidas de los procesos (NOO) Complejidad del flujo de control (CFC) Número de mecanismos de Complejidad de automatización control (NMC) Número de sujetos (NS) Número de dependencias (NMD) Número de fronteras (NF) Número de entidades (NE). 26.

Figure

Figura 1: Elementos de un proceso de negocio.
Tabla 1: Lista de elementos centrales del BPD
Figura 3: Medidas base para eventos propuestas en (Rolón Aguilar 2009) .
Tabla 3: Resumen de métricas asociadas a procesos de negocio.
+7

Referencias

Documento similar

Where possible, the EU IG and more specifically the data fields and associated business rules present in Chapter 2 –Data elements for the electronic submission of information

The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the

In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)

Package Item (Container) Type : Vial (100000073563) Quantity Operator: equal to (100000000049) Package Item (Container) Quantity : 1 Material : Glass type I (200000003204)

b) El Tribunal Constitucional se encuadra dentro de una organiza- ción jurídico constitucional que asume la supremacía de los dere- chos fundamentales y que reconoce la separación