Facultad de Ciencias Físico Matemáticas y Naturales
Universidad Nacional de San Luis ______________________________
Tesis de
Maestría en Ingeniería de Software
MEMPN: Método para la Evaluación de Modelos
Conceptuales de Procesos de Negocio
Autor Esp. Carlos H. Salgado
Directores:
Dr. Daniel Edgardo Riesco Dr. Mario Marcelo Berón
______________________________
Proyecto de Investigación:
Ingeniería de Software: Aspectos de Alta Sensibilidad en el Ejercicio de la Profesión de Ingeniero de Software – Facultad de Ciencias Físico-Matemáticas
y Naturales, Universidad Nacional de San Luis. Proyecto Nº 22/F222.
Área de Programación y Metodologías de Desarrollo de Software
______________________________
Tesis de Maestría en Ingeniería de Software
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Autor Esp. Carlos H. Salgado
Directores
Dr. Daniel Edgardo Riesco Dr. Mario Marcelo Berón
______________________________
- 2013 -
Prefacio Este trabajo de maestría fue desarrollado en el marco de la Carrera de
Maestría en Ingeniería de Software, dictada en la Universidad Nacional de San
Luis, bajo el soporte académico del Proyecto de investigación: Ingeniería de
Software: Aspectos de Alta Sensibilidad en el Ejercicio de la Profesión de
Ingeniero de Software (Código: 22/F222 – F.C.F.M.yN., U.N.S.L).
El modelado de procesos de negocio presenta una visión global de la
organización que permite entender mejor la dinámica de la empresa y las
relaciones que se dan dentro de ella y con su entorno (tanto en el ámbito que
refiere a los clientes como a sus proveedores y/o prestadores de servicios). Por
lo tanto, el modelado del negocio es la técnica por excelencia para alinear los
desarrollos con las metas y objetivos de las empresas e instituciones. En este
sentido, es de vital importancia que los modelos de los procesos de negocio
sean de alta calidad y se adecuen a las necesidades de la empresa. Modelos
de calidad ayudarán a mejorar el desempeño y evolución de la organización, y
no se convertirán en una traba o factor de riesgo. En el presente trabajo se
presenta un método para la evaluación de modelos conceptuales de procesos
de negocio. Este método permite calificar la adecuación de los modelos de
procesos de negocio a las necesidades de cada problemática particular.
Además, es aplicable en la comparación de distintas propuestas para un
problema bajo estudio particular. De esta manera se puede obtener un
indicador de cuál de las propuestas comparadas se adecúa más a la situación
particular. Cabe destacar que este proceso de evaluación es aplicable
independientemente de una estructura organizacional particular.
A mis padres Juan Carlos y Reina
A mi esposa Estela e hijos Nahir y Martín
Agradecimientos A Daniel Riesco y Mario Berón, mis directores, por acompañarme en este
trabajo con aportes enriquecedores y por el apoyo constante a mi tarea.
A Mario Peralta, mi colega y amigo por su incondicional predisposición, ayuda y
aportes.
A la Facultad de Ciencias Físico Matemáticas y Naturales, de la Universidad
Nacional de San Luis, por el soporte brindado que facilitó en buena parte este
estudio.
A mis hijos Nahir y Martín y a mi esposa Estela, por soportar mi ausencia y
acompañar mi esfuerzo con cariño y comprensión.
A mis colegas y compañeros de labor, por haber compartido momentos de
trabajo y compañerismo, y por alentarme constantemente. Especialmente, a
Lorena Baigorria por la importante contribución y apoyo con sus sugerencias e
ideas.
Carlos H. Salgado I
Índice de Contenidos
CAPÍTULO 1. Introducción ......................................................................................... 1
1.1. Planteamiento y Justificación del Trabajo .............................................................. 1
1.2. Objetivo de la Tesis ............................................................................................... 4
1.3. Marco de Trabajo ................................................................................................... 4
1.4. Estructura del Informe ............................................................................................ 4
CAPÍTULO 2. Los Procesos de Negocio y su Modelado .......................................... 6
2.1. Introducción a los Procesos de Negocio ................................................................ 6
2.2. El Ciclo de Vida del Proceso de Negocio ............................................................... 9
2.3. La Gestión de Procesos de Negocio .................................................................... 11
2.4. Modelado de Procesos de Negocio...................................................................... 13
2.4.1. Notaciones de Modelado de Proceso de Negocio ............................................. 15
2.4.1.1. IDEF .............................................................................................................. 15
2.4.1.2. IDEF0............................................................................................................. 16
2.4.1.3. IDEF3............................................................................................................. 16
2.4.1.4. UML ............................................................................................................... 18
2.4.1.5. BPMN ............................................................................................................ 18
2.4.2. Calidad de los Modelos de Procesos de Negocio ............................................. 20
CAPÍTULO 3. Modelos de Análisis .......................................................................... 23
3.1. Introducción. ........................................................................................................ 23
3.2. Decisión – Situaciones de Decisión ..................................................................... 23
3.3. El Proceso de Toma de Decisión ......................................................................... 25
3.4. Análisis de Decisión Multicriterio .......................................................................... 27
3.4.1. Métodos de Evaluación y Decisión Multicriterio Discretos ................................. 29
3.4.1.1. Ponderación Aditiva Simple (SAS - Simple Additive Scoring) ......................... 30
3.4.1.2. Teoría de Valor Multiatributo (MAVT: Multiattribute Value Theory) ................. 31
3.4.1.3. Teoría de Utilidad Multiatributo (MAUT: Multiattribute Utility Theory) ............. 32
3.4.1.4. Proceso Jerárquico Analítico (AHP: Analytic hierarchy process) .................... 33
3.4.1.5. Métodos de Superación (Outranking Methods) .............................................. 34
Carlos H. Salgado II
3.4.1.6. Marcas Lógicas de Preferencias (LSP: Logic Scoring of Preferences) ........... 37
CAPÍTULO 4. MEMPN: Método para la Evaluación de Modelos Conceptuales de
Procesos de Negocio ............................................................................................... 39
4.1. Introducción ......................................................................................................... 39
4.2. Fases del Método ................................................................................................ 41
4.2.1. Determinación y Especificación de los Requisitos de Calidad Deseados .......... 42
4.2.2. Definición de los Criterios Elementales de Evaluación ...................................... 46
4.2.2.1. Rango Nominal de las Variables de Preferencias .......................................... 48
4.2.2.2. Clasificación de los Tipos de Criterios Elementales ....................................... 50
4.2.2.2.1. Criterios Absolutos Continuos de Variable Única ........................................ 51
4.2.2.2.2. Criterios Absolutos Continuos de Variable Normalizada .............................. 52
4.2.2.2.3. Criterios Absolutos Continuos Multi-variables. ............................................ 54
4.2.2.2.4. Criterios Absolutos Continuos de Preferencia Directa ................................. 55
4.2.2.2.5. Criterios Absolutos Discretos Binarios ......................................................... 56
4.2.2.2.6. Criterios Absolutos Discretos Multi-nivel ..................................................... 58
4.2.2.2.7. Criterios Absolutos Discretos Multi-variable ................................................ 58
4.2.2.2.8. Criterios Absolutos Discretos de Punto Aditivo ............................................ 59
4.2.2.2.9. Criterios Elementales Relativos de Variable Única ...................................... 62
4.2.2.2.10. Criterios Elementales Relativos Normalizados .......................................... 63
4.2.2.2.11. Criterios Elementales Discretos Estadísticos ............................................ 64
4.2.3. Definición de la Estructura de Agregación de los Criterios Elementales para la
Evaluación Global ....................................................................................................... 67
4.2.4. Documentación, Análisis de Resultados y Conclusiones .................................. 69
CAPÍTULO 5. Casos de Estudio ............................................................................... 73
5.1. Introducción ......................................................................................................... 73
5.2. Caso de Estudio 1: Evaluación de los Modelos de Procesos de Negocio de una
Empresa del Medio ..................................................................................................... 74
5.2.1. Enfoques de Trabajo de las Empresas ............................................................. 75
5.2.2. El Caso de Estudio: Descripción del Problema ................................................. 77
5.2.3. La Aplicación del Método en la Evaluación de los Modelos Propuestos ............ 81
5.2.3.1. Fase 1: Definición de la Estructura de Categorización de Requerimientos para
la Evaluación de los Modelos de Procesos de Negocio de la Empresa en Estudio ..... 82
5.2.3.2. Fase 2: Definición de los Criterios Elementales de Evaluación ...................... 83
Carlos H. Salgado III
5.2.3.3. Fase 3: Definición de la Estructura de Agregación para la Evaluación Global 92
5.2.3.4. Fase 4: Documentación, Análisis de los Resultados y Conclusiones ............. 95
5.2.3.4.1. Beneficios para la Empresa ........................................................................ 98
5.3. Caso de estudio 2: Aplicando MEMPN en la comparación de Metodologías Ágiles
de Desarrollo de Software .......................................................................................... 98
5.3.1. Fase 1: Definición de la Estructura de Categorización de Requerimientos para el
Análisis de las Metodologías Ágiles Estudiadas .......................................................... 99
5.3.2. Fase 2: Definición de los Criterios Elementales de Evaluación ....................... 101
5.3.3. Fase 3: Definición de la Estructura de Agregación para la Evaluación Global . 105
5.3.4. Fase 4: Documentación, Análisis de los Resultados y Conclusiones .............. 107
5.3.4.1. Análisis de los resultados y Documentación................................................. 108
5.4. Conclusión ......................................................................................................... 109
CAPÍTULO 6. Conclusiones ................................................................................... 111
CAPÍTULO 7. Trabajos Futuros .............................................................................. 115
ANEXO 1. BPMN: Business Process Management Notation ............................... 116
A1.1. BPMN ........................................................................................................... 116
A1.2. Visión General .............................................................................................. 116
A1.3. Alcance de BPMN ......................................................................................... 118
A1.4. Usos de BPMN ............................................................................................. 119
A1.5. Tipos de Diagramas de Proceso de Negocio ................................................ 121
A1.6. Mapeos BPMN .............................................................................................. 122
A1.7. Extensibilidad de BPMN y Dominios Verticales ............................................. 122
A1.8. Diagramas de Proceso de Negocio ............................................................... 123
A1.9. Conjunto de Elementos Centrales de DPN ................................................... 124
A1.10. Conjunto Extendido de Elementos de DPN ................................................... 128
ANEXO 2. Métricas para el modelado de Procesos de Negocio .......................... 138
A2.1. Métricas Base ............................................................................................... 138
A2.2. Métricas Derivadas. ...................................................................................... 142
Referencias Bibliográficas ..................................................................................... 145
Carlos H. Salgado IV
Índice de Figuras
Figura 2.1. Proceso de Negocio .............................................................................................................. 7 Figura 2.2. Ciclo de Vida de un Proceso de Negocio ........................................................................ 11
Figura 4.1. Estructura básica de categorización de requerimientos del sistema para la evaluación de Modelos de Procesos de Negocio ..................................................................... 44
Figura 4.2. Criterio elemental para la variable de preferencia: Tiempo de Procesamiento de un programa de referencia ................................................................................................................. 52
Figura 4.3. Criterio elemental para la variable de preferencia: Tiempo de Procesamiento de un programa de referencia ................................................................................................................. 53
Figura 4.4. Criterio elemental para la variable de preferencia: Tiempo Total de Entrenamiento 55 Figura 4.5. Formulario de relevamiento de resultados ...................................................................... 71
Figura 5.1. Modelo del Proceso Compras y Pagos de la Empresa ................................................. 79 Figura 5.2. Modelo del Proceso Compras y Pagos Propuesto ......................................................... 80 Figura 5.3. Subproceso Realizar Control Físico ................................................................................. 81 Figura 5.4. Subproceso Elegir Proveedor ............................................................................................ 81 Figura 5.5. Subproceso Pagar Documento ......................................................................................... 81 Figura 5.6. Estructura de Categorización de Requerimientos utilizada en la evaluación de los
modelos estudiados. ...................................................................................................................... 83 Figura 5.7. Estructura de Agregación ................................................................................................... 93 Figura 5.8. Formulario de Documentación de la Evaluación ............................................................ 97 Figura 5.9. Estructura de categorización de requerimientos del sistema a ser aplicada a la
evaluación de Metodologías Ágiles ........................................................................................... 100 Figura 5.10. Estructura de agregación para la evaluación de Metodologías Ágiles ................... 106 Figura 5.11. Formulario de Documentación de la Evaluación ........................................................ 109
Figura A-1.1. Ejemplo de Proceso de Negocio Privado [11] ........................................................... 119 Figura A-1.2. Ejemplo de Proceso de Negocio Abstracto [11]. ...................................................... 120 Figura A-1.3. Ejemplo de un proceso de negocio de colaboración [11] ........................................ 121
Carlos H. Salgado V
Índice de Tablas
Tabla 4.1. Clasificación de Tipos de Criterios Elementales .............................................................. 50 Tabla 4.2. Ejemplo de un criterio absoluto discreto multivariable con variables binarias ............. 59 Tabla 4.3. Ejemplo de Reglas de Clasificación de Impresoras Seriales ......................................... 61 Tabla 4.4. Símbolos y parámetros de la función andor ..................................................................... 68 Tabla 4.5. Modelo de tabla para listar los resultados de la evaluación. .......................................... 70
Tabla 5.1. Aplicación de los Criterios Elementales a los modelos evaluados ................................ 91 Tabla 5.2. Resultados de la aplicación del método a los modelos (Ref-1). .................................... 96 Tabla 5.3. Resultados de la aplicación del método a los modelos de las Metodologías Ágiles
estudiadas (Ref-2) ........................................................................................................................ 107 Tabla 5.4. Resumen de los resultados de la aplicación del método a los modelos de las
Metodologías Ágiles estudiadas ................................................................................................ 108
Tabla A-1.1. Conjunto de Elementos Centrales de DPN: Objetos de Flujo .................................. 126 Tabla A-1.2. Conjunto de Elementos Centrales de DPN: Objetos de Conexión ......................... 127 Tabla A-1.3. Conjunto de Elementos Centrales de DPN: Carriles ................................................. 127 Tabla A-1.4. Conjunto de Elementos Centrales de DPN: Artefactos ............................................. 128 Tabla A-1.5.Conjunto de Elementos Extendidos de DPN ............................................................... 129
Tabla A-2.1. Métricas Base definidas para el elemento Evento de inicio. .................................... 138 Tabla A-2.2. Métricas Base definidas para el elemento Eventos intermedios. ............................ 139 Tabla A-2.3. Métricas Base definidas para el elemento Eventos finales. ..................................... 139 Tabla A-2.4. Métricas Base para el elemento Actividad atómica (tareas). ................................... 140 Tabla A-2.5. Métricas Base para el elemento Actividad compuesta (sub-proceso) .................... 140 Tabla A-2.6. Métricas Base para el elemento Nodos. ...................................................................... 141 Tabla A-2.7. Métricas Base para los Objetos de Conexión............................................................. 141 Tabla A-2.8. Métricas Base para los Carriles .................................................................................... 142 Tabla A-2.9. Métricas Base para los Artefactos. ............................................................................... 142
Carlos H. Salgado 1
CAPÍTULO 1. Introducción
1.1. Planteamiento y Justificación del Trabajo
La compleja naturaleza de los procesos de negocio ha llevado a la realización
de diversas propuestas y estudios referentes a distintos aspectos de este tipo
de procesos. Entre dichos aspectos se pueden mencionar la utilidad [1],
evaluación de la calidad [2], la medición [3], entre otros. En este contexto, son
frecuentes los estudios que se refieren a la utilización de diferentes
herramientas y lenguajes para modelar los procesos de negocio [4, 5, 6]. La
motivación principal de los investigadores interesados en esta área, es la gran
variedad de notaciones y lenguajes existentes para el modelado, definición y
ejecución de los procesos de negocio.
Desde el punto de vista del modelado, el desarrollo de modelos
conceptuales constituye sólo una parte del esfuerzo de la definición de un
proceso de negocio. Sin embargo, esta actividad es una de las tareas claves en
las primeras etapas del ciclo de vida de los procesos de negocio.
Los Modelos de Procesos de Negocio (MPN) tienen un amplio rango de
aplicación. Entre las más importantes se distinguen el soporte a la re-ingeniería
de procesos, la simulación, servir como base para el desarrollo de sistemas
que automatizan dichos procesos, entre otras. Los MPN pueden ser creados o
presentados usando diversos lenguajes que son muy dispares entre sí. Esto se
debe a que cada uno tiene una manera diferente de abordar el modelado de los
procesos dependiendo del propósito para el cuál fue creado [5]. Entre los
lenguajes para el modelado de procesos de negocio mencionados en la
literatura que merecen especial atención, se encuentran: IDEF0 [7], IDEF3 [8],
UML [9], UML 2.0 [10] y BPMN [11]. Estos lenguajes de modelado,
proporcionan una notación gráfica para expresar procesos de negocio
mediante Diagramas de Procesos de Negocio (DPN). Un DPN se basa en una
técnica de diagramas de flujo adaptada para la creación de modelos gráficos
de las operaciones de procesos de negocio. Está compuesto de dos categorías
básicas de elementos. En la primera se encuentran los elementos centrales
con los cuales es posible desarrollar modelos de procesos simples, mientras
que en la segunda se incluyen los elementos que permiten la creación de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 2
MPNs complejos o de alto nivel.
Desde otra perspectiva, e independientemente de la notación utilizada, los
modelos de procesos de negocio son utilizados como un medio para entender
fácilmente los procesos que dichos modelos representan. Además, son
empleados como punto de partida a la hora de realizar cambios y adaptaciones
de los procesos a las nuevas necesidades de las empresas. Por este motivo,
es de suma importancia que los modelos se adecuen a las necesidades y
objetivos de la organización. Es decir, es fundamental que representen
fehacientemente sus reglas de negocio y que sean fácilmente adaptables a los
cambios constantes a los que los negocios actuales están expuestos. Por ello,
es un factor primordial que estos modelos sean de alta calidad. Esto lleva a la
necesidad de tener algún medio que permita evaluar dicha calidad,
determinando si los modelos satisfacen ciertos criterios de calidad.
Al hablar de calidad de los modelos conceptuales, la misma puede ser
medida en función de distintos criterios. Por ejemplo, algunos de dichos
criterios pueden ser:
(i) Riqueza semántica o expresividad: un modelo es rico
semánticamente, si ofrece una amplia gama de conceptos para cubrir
la mayor cantidad de aspectos relevantes del dominio del problema.
(ii) Comprensibilidad: un modelo debe ser comprensible para facilitar la
comunicación entre los usuarios finales y los modeladores. Un modelo
comprensible permite resaltar los detalles importantes del sistema
para plantear la solución y, así, poder transferir ese conocimiento.
(iii) Formalidad o Rigor: un modelo es formal, si cada concepto tiene una
interpretación única, precisa y bien definida. Esta cualidad determina
la capacidad de traducción o transformación de un modelo a otro de
más bajo nivel de abstracción.
(iv) Simplicidad: un modelo simple es legible y comprensible.
Desafortunadamente, esta cualidad casi siempre está en conflicto con
la expresividad. Por eso, siempre se busca un punto de equilibrio
entre ambas cualidades.
(v) Suficiencia o Minimalidad: Un modelo es mínimo o suficiente, si cada
concepto modelado no puede ser deducido de otros conceptos ya
incluidos en él. Si se tiene un modelo suficiente; se incrementa la
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 3
probabilidad de tener un modelo de la solución correcto; ya que se
minimizará la posibilidad de especificar contradicciones. Esta cualidad
incide positivamente, también, en la simplicidad y comprensibilidad
del modelo.
Desde el punto de vista del modelado conceptual, se debe distinguir entre
la calidad del producto (relacionada con las características del modelo
conceptual) y la calidad del proceso de modelado (relacionada en cómo se
desarrollan los modelos) [12]. Al respecto, la complejidad de un modelo
conceptual puede estar altamente influenciada por los diferentes elementos
que lo componen, tales como tareas, subprocesos, participantes, eventos, etc.
Por lo tanto, no es aconsejable definir una medida general para su complejidad
[13]. En este sentido, se han propuesto varios marcos de trabajo interesantes
[14, 15, 16, 17], que han contribuido a una mejor comprensión del concepto de
calidad en el modelado conceptual [18]. El tener métodos que permitan medir la
calidad de dichos modelos es de gran ayuda para las organizaciones en cuanto
a la administración, difusión y mantenimiento de los procesos que ellos
representan.
Desde la perspectiva mencionada en el párrafo precedente, el proceso de
evaluación de requerimientos de calidad de los modelos conceptuales de PN
es de suma importancia. Por lo tanto, es de gran utilidad contar con un método
cuantitativo para la evaluación y comparación de las características deseables
de todo modelo que se apoye en los principios y prácticas de la ingeniería de
software, con el fin de obtener resultados objetivos y justificables. Por ello, en el
presente trabajo se propone un método de evaluación y comparación de
modelos conceptuales de PN. El objetivo de la propuesta es brindar un medio
que ayude en la toma de decisión a la hora de evaluar la calidad de los MPN en
las organizaciones.
Debido a la importancia de los estándares de calidad, como las normas de
calidad ISO 9000 [19], e ISO/IEC 9126 [20], en cuanto a la compatibilidad con
distintos medios y notaciones, el método propuesto adhiere a dichos
estándares de calidad y es independiente de la notación utilizada para la
definición de los modelos evaluados. El método propuesto se centra en la
calidad del producto.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 4
Cabe destacar que hasta el momento se ha trabajado en la aplicación de
métodos para la evaluación de la calidad de distintos tipos de sistemas. Por
ejemplo, en [21] se presentan los resultados de la aplicación de LSP para la
evaluación de Gestores de bases de datos. De la misma manera en [22], se
aplica dicho método en la evaluación de distintos lenguajes de programación
Web y en [23] para la evaluación de herramientas para el modelado en UML.
En tanto, en el marco de la presente tesis, entre las más destacadas, se
pueden mencionar [24, 25, 26, 27], donde se presenta la aplicación de un
método de evaluación de modelos conceptuales de procesos de negocio y la
aplicación de un modelo para la evaluación de lenguajes de modelado de
procesos de negocio. En [28, 29], se presenta una estrategia basada en LSP
para la evaluación de lenguajes específicos para el modelado de procesos de
negocio. Desde otra perspectiva, en [30] se describe una propuesta para la
optimización en la definición de métricas de procesos de negocio especificadas
en OCL basadas en BPDM (Business Process Documentation Metamodel).
1.2. Objetivo de la Tesis
El presente trabajo está orientado a la definición de un método para la
evaluación de la calidad de modelos conceptuales de procesos de negocio. El
objetivo es proveer a las organizaciones, instituciones, desarrolladores, etc., un
método que, al permitir evaluar la calidad de los modelos conceptuales de sus
procesos de negocio, les ayude en la toma de decisiones respecto a dichos
proceso. Además, brindará un grupo de reglas y procedimientos para el análisis
de la adecuación de esos modelos a las necesidades de la organización.
1.3. Marco de Trabajo
El presente trabajo se desarrolló en el Laboratorio de Calidad e Ingeniería de
Software (LaCIS), y se enmarca dentro del Proyecto de investigación:
Ingeniería de Software: Aspectos de Alta Sensibilidad en el Ejercicio de la
Profesión de Ingeniero de Software (Código: 22/F222 – F.C.F.M.yN., U.N.S.L).
1.4. Estructura del Informe
Acorde a lo expuesto en las secciones previas, el resto del presente trabajo se
estructura de la siguiente forma: El capítulo 2 presenta una introducción a los
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 5
conceptos básicos de Procesos de Negocio y el modelado de procesos de
negocio. Además, se presenta una introducción a los conceptos de calidad
respecto de los modelos de procesos de negocio. En el Capítulo 3, se propone
una clasificación de distintos métodos para la evaluación de sistemas de todo
tipo. En el Capítulo 4 se describe MEMPN, el método propuesto en el presente
trabajo. El capítulo 5 presenta los resultados de aplicar el método a casos de
estudio. Finalmente, en los Capítulos 6 y 7, se delinean las conclusiones del
trabajo y los trabajos futuros que pueden derivarse de esta propuesta. En los
Anexos 1 y 2 se presenta una descripción de BPMN y las métricas utilizadas en
la definición de los criterios elementales aplicados en los casos de estudio,
respectivamente.
Carlos H. Salgado 6
CAPÍTULO 2. Los Procesos de Negocio y su Modelado
2.1. Introducción a los Procesos de Negocio
Si se observa en la literatura, [31, 32, 33], por mencionar algunos, se pueden
encontrar diversas conceptualizaciones de los Procesos de Negocio. Por ello, y
en un intento de estandarizar este concepto, la Workflow Management
Coalition (WfMC) define un proceso de negocio como:
Un 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 la que se definen relaciones y
roles funcionales [34].
No obstante, teniendo presente las diversas definiciones de procesos de
negocio existentes, se puede decir que un proceso de negocio normalmente:
I. Está asociado con objetivos operacionales y relaciones de negocio,
II. puede estar contenido completamente dentro de una unidad
organizacional o puede abarcar diferentes organizaciones,
III. tiene condiciones definidas que disparan su inicio,
IV. produce salidas definidas en su finalización,
V. puede involucrar interacciones formales o relativamente informales
entre los participantes, y
VI. puede consistir de actividades manuales y/o automatizadas.
La Figura 2.1 muestra gráficamente un proceso de negocio y los
elementos que lo conforman.
Se puede decir, entonces, que un Proceso de Negocio es una colección
de actividades diseñadas para producir una salida específica para un cliente o
mercado particular. Implica un fuerte énfasis en cómo se hace el trabajo en una
organización, en contraposición al enfoque en qué producto. Un proceso es un
ordenamiento específico de actividades de trabajo a través del tiempo y del
espacio, con un comienzo, un fin, entradas y salidas claramente identificados.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 7
Figura 2.1. Proceso de Negocio
Otra forma de ver un proceso de negocio, es como un conjunto de tareas
lógicamente relacionadas que se llevan a cabo para lograr un resultado de
negocio definido. Cada proceso de negocio tiene sus entradas, funciones y
salidas. Las entradas son requisitos que deben reunirse antes de que una
función pueda ser aplicada para obtener las salidas resultantes esperadas.
Dichas salidas deben producir un valor para la organización, sus inversores o
sus clientes.
Por los motivos antes mencionados, se puede afirmar que un proceso de
negocio tiene objetivos bien definidos. Dichos objetivos, deben expresarse en
términos de los beneficios que proporcionan a la organización como un todo.
Desde otro punto de vista, se debe analizar el aporte de estos objetivos a la
satisfacción de las necesidades del negocio. Esto producirá más salidas de
valor para el negocio, tanto para uso interno como para satisfacer requisitos
externos. Donde, dichas salidas, pueden ser: (i) un objeto físico (tal como un
informe o una factura), (ii) una transformación de recursos crudos en un nuevo
ordenamiento (una agenda diaria o calendario), o (iii) un resultado global de
negocio (tal como completar una orden de cliente). Desde esta perspectiva,
una salida de un proceso de negocio puede alimentar otros procesos, ya sea
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 8
como un ítem que se solicita o como un disparador para iniciar nuevas
actividades.
Un proceso de negocio puede agrupar varios procesos de negocio que
deben incluirse para lograr el objetivo del proceso contenedor o, inversamente,
puede formar parte de un proceso más grande o complejo que lo necesite para
alcanzar su meta final. Esta perspectiva hace que se puedan ver los procesos
de negocio como los flujos de trabajo que efectúan las tareas de una
organización. Se puede decir que todo proceso de negocio posee las
siguientes características:
1. Pueden ser medidos y están orientados al rendimiento.
2. Tienen resultados específicos.
3. Entregan resultados a clientes o “stakeholders”.
4. Responden a alguna acción o evento específico.
5. Las actividades deben valorizar las entradas del proceso.
Los procesos de negocio generalmente son transversales a la
organización y por lo tanto pueden involucrar varias unidades estratégicas. De
acuerdo a ello, se pueden agrupar en tres tipos:
1. Procesos estratégicos – Son los que están orientados a la dirección de
la organización. Por ejemplo: Planificar estrategias, Establecer objetivos
y metas, etc.
2. Procesos centrales – Constituyen el núcleo de la actividad de la
organización y le dan valor al cliente, son la parte principal del negocio.
Por ejemplo, Repartir Mercancías, etc.
3. Procesos de soporte – Estos procesos son aquellos en los que se
apoyan los procesos centrales para su desarrollo. Por ejemplo,
Contabilidad, Servicio Técnico, etc.
Todo proceso de negocio puede estar compuesto por varios subprocesos,
los cuales tienen su propia identidad, es decir cada uno tiene sus propias
metas y objetivos, entradas y salidas, propietarios, decisiones y actividades,
pero en conjunto contribuyen al logro de las metas del proceso principal que lo
contiene. Más allá de la construcción del proceso de negocio, éste permite que
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 9
la organización pueda fácilmente obtener:
• La identificación temprana de las condiciones de viabilidad del negocio.
• La identificación de factores claves de éxito.
• La identificación de los Indicadores de Posicionamiento Competitivo.
• El diseño de la estrategia comercial del negocio.
Una consideración importante en todo proceso de negocio, es que debe
poder evolucionar y adaptarse a los cambios constantes del mundo en el que
está inmerso. Es decir, debe ser fácil de mantener, mejorar y adaptar a las
condiciones cambiantes del medioambiente. En este sentido, los procesos de
negocio pueden ser mejorados, siempre que se sigan los siguientes objetivos
[35]:
• Comprender el estado actual de la práctica de Ingeniería de Software y
gestión en una organización.
• Seleccionar áreas a mejorar donde los cambios pueden significar un
mayor beneficio a largo plazo.
• Focalizarse en agregar valor al negocio, no en alcanzar una utopía del
proceso.
• Prosperar mediante una combinación de procesos efectivos, con gente
preparada, emotiva y creativa.
2.2. El Ciclo de Vida del Proceso de Negocio
Para alcanzar con éxito los objetivos y ventajas pretendidos con la Gestión de
Procesos de Negocio (BPM, por la sigla en inglés de Business Process
Management) debe establecerse el “ciclo de vida” del proceso de negocio; el
cual está constituido por etapas y actividades. En dicho ciclo de vida, las
principales fases son [36]:
• Descubrimiento: el principal objetivo es descubrir y entender cada uno
de los procesos de negocio que forman la organización. En esta fase se
especifican todos los detalles de cada uno de los requisitos y se centra,
principalmente, en las funcionalidades claves del sistema.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 10
• Análisis: en esta fase se analizan cada uno de los procesos de negocio
del sistema, modelándolos con las nuevas características y reglas que
se deben seguir para obtener una mayor productividad.
• Desarrollo: se desarrollan los procesos de negocio analizados y
diseñados en la etapa anterior.
• Monitoreo: cada proceso de negocio debe ser medible para saber el
grado de éxito y calidad con el que ha sido llevado a cabo. De esta
forma, se pueden analizar los resultados de cada uno de los procesos
para que puedan ser redefinidos y optimizados.
• Optimización: aquellos procesos que no han cumplido las expectativas
deseadas, ya sea porque no poseen un conjunto coherente de tareas, o
bien porque las necesidades han cambiado, son optimizados para que
puedan mejorar su rendimiento, y por ende el de la empresa. Si se
necesita crear un nuevo software que soporte las optimizaciones, será
imprescindible que estos procesos pasen, de nuevo, a la fase de
análisis.
Considerando las etapas descritas previamente, se puede afirmar que el
Ciclo de Vida en los Procesos de Negocio, se inicia con el Descubrimiento. Es
decir, se debe hacer explícita la manera en que se hacen las cosas en
contraste a cómo se deberían hacer. Para ello, se realiza un Diseño (modelar,
simular y reestructurar el Proceso de Negocio) para, luego, avanzar en el
Despliegue. Esta última actividad se refiere a implantar un nuevo Proceso de
Negocio a todos los participantes – personas, sistemas, otros procesos, etc.
Una vez completadas las etapas mencionadas previamente, se efectiviza
la Ejecución (asegurar que el nuevo Proceso de Negocio es llevado a cabo por
todos los participantes) mediante la Interacción (permitir a las personas
gestionar la interfaz entre procesos automáticos y manuales).
Otra etapa importante en este ciclo es la Operación y Mantenimiento
(intervenir para resolver excepciones, reasignar participantes, etc.).
La Optimización (cambiar el Proceso de Negocio para mejorarlo – la
mejora de procesos debe ser un esfuerzo continuo en ciclos de diseño-
despliegue-ejecución-operación-optimización) debe estar ayudada por el
Análisis (medir el rendimiento del Proceso de Negocio e idear estrategias de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 11
mejora).
Finalmente, se debe tener en cuenta la Automatización (se realiza durante
las etapas de despliegue, ejecución, operación y optimización). La Figura 2.2
muestra una representación gráfica que describe el ciclo de vida de un Proceso
de Negocio [37].
Figura 2.2. Ciclo de Vida de un Proceso de Negocio
2.3. La Gestión de Procesos de Negocio
En el vertiginoso mundo de los negocios, las empresas necesitan herramientas
que les permitan alcanzar un buen desempeño y una alta competitividad. En
este sentido, la Gestión de Procesos de Negocio (BPM, por la sigla en inglés
de Business Process Management) es el más reciente trabajo en el campo del
software empresarial. Su objetivo principal es la automatización y optimización
de los procesos de negocio de las empresas y organizaciones actuales. BPM
Cambio de Etapa.
Gestión de Procesos de Negocio
Mejora de Procesos de Negocio.
Interacción de PN
Procesos Manuales
Automatización de PN
Procesos Automatizados
Workflow/ Colaboración
Integración de PN
Integración de Aplicación
Empresarial
Integración B2B
Descubrir el PN
Diseño de PN
Despliegue de PN
Ejecución de PN
Operación de PN
Optimizar el PN
Análisis de PN
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 12
se puede definir como:
El conjunto de servicios y herramientas que facilitan la administración de
procesos de negocio [38].
Donde, administración de procesos se entiende como:
El análisis, definición, ejecución, monitoreo, y control de los procesos,
contemplando el soporte para interacción humana, e integración de
aplicaciones [38].
BPM, es un enfoque estructurado que emplea métodos, políticas,
métricas, prácticas de administración, y herramientas de software para mejorar
la agilidad y el desempeño operacional [38]. Además, es vista como una
disciplina de administración, que requiere que las organizaciones:
I. Se centren en los procesos; y
II. reduzcan su dependencia de estructuras tradicionales de territorio y
funcionalidad (los llamados silos).
Todo proceso de negocio necesita de la aplicación de recursos de diversa
índole, humanos, materiales, financieros, energéticos, informativos, etc. El
concepto tradicional, basado en la optimización de las actividades en forma
independiente, puede llevar a mejorar la productividad de los recursos de una
parte de la gestión de la compañía. Sin embargo, esto puede ir en desmedro de
la productividad del conjunto.
La gestión de procesos de negocio permite realizar un mapa de
conectividad de procesos. Tratados en conjunto, estos procesos, determinan
necesidades integradas de recursos y permite darles respuesta con una visión
integral.
El tratamiento de los recursos se realiza por grupos de procesos conexos
y se consideran cinco aspectos fundamentales:
• Evaluación de necesidades.
• Posibilidad de sustitutos.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 13
• Adquisición.
• Utilización productiva.
• Desperdicios (identificación y eliminación).
Como dicen Rodríguez, et al, [39]: (…) “ Para mejorar los servicios
brindados al cliente, traer nuevos servicios al mercado, eliminar las
ineficiencias y cumplir con las regulaciones legales, los proveedores han
apostado por la Gestión de Procesos de Negocio. Sin embargo, desde el
momento en que una organización expresa la necesidad del cambio al enfoque
de procesos, comienza un arduo trabajo que involucra: decidir si se lleva a
cabo la reingeniería de procesos o el mejoramiento continuo de procesos;
analizar la automatización de los procesos asegurando la integración eficiente
de aplicaciones y de datos entre los sistemas involucrados en esos procesos;
cómo resolver la interoperabilidad entre los sistemas y el negocio; cómo lograr
la alineación entre las tecnologías de información y los objetivos estratégicos
de la organización; cómo relacionar los procesos (…) “Uno de los aspectos
para responder a estos problemas, ha sido un cambio en la forma en que las
compañías están usando la gestión de los procesos. Estas buscan una manera
diferente de mejorar los procesos de negocio, influenciando el uso de
aplicaciones dedicadas a la captura, diseño e implementación de procesos a
través de la organización (…). Se diseñan nuevos procesos y modelos de
negocio para adaptarse a los cambiantes requerimientos de los consumidores y
avances tecnológicos. Existe la necesidad de brindar más productos y servicios
con costos menores, lo que puede ser llevado a cabo, sólo mediante la
automatización, gestión y control de los procesos. (...) Los procesos deben ser
subdivididos en unidades bien definidas, que puedan ser reutilizadas en la
mayor cantidad de procesos posible.” (…)
2.4. Modelado de Procesos de Negocio.
Desde el punto de vista de la BPM, es de vital importancia tener herramientas
que ayuden a la gestión de las distintas etapas de la administración de
procesos. En este sentido, el modelado es una herramienta muy útil en el área
de análisis y definición de la BPM. En el campo del modelado de procesos de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 14
negocio se pueden encontrar numerosas propuestas de lenguajes de
modelado, como IDEF0 [7], IDEF3 [8], UML [9], UML 2.0 [10] y BPMN [11], por
mencionar algunos.
El modelado del Proceso de Negocio constituye una etapa fundamental
para lograr el objetivo de un proceso de negocio, es decir, como lo establece la
definición de PN [40], obtener resultados beneficiosos para los clientes u otros
interesados. Esto se debe a que un modelo de proceso de negocio describe
cómo funciona el negocio [5], es decir, describe las actividades involucradas en
el negocio y cómo se relacionan e interactúan con los recursos necesarios para
lograr los objetivos del proceso. Desde este punto de vista, el modelado de
procesos de negocios se utiliza para capturar, documentar o rediseñar
procesos de negocio [41].
Los modelos de los procesos de negocio dan a la organización una visión
global que ayuda a entender mejor la dinámica de la empresa. Además,
permiten visualizar mejor las distintas relaciones que se dan dentro de ella y
con su entorno. Esto se da, tanto en el ámbito que refiere a los clientes, como a
sus proveedores y/o prestadores de servicios.
Por lo tanto, el modelado de procesos de negocio es una de las técnicas
más adecuada para alinear los desarrollos con las metas y objetivos de las
empresas e instituciones. Si se realiza de tal forma que el modelo quede
consensuado entre los grupos interesados, las posibilidades de éxito del
proyecto aumentarán [42].
En vista de lo expuesto, se puede decir que un modelo de proceso de
negocio muestra las actividades que se deben realizar para alcanzar los
objetivos establecidos por la organización en su negocio. Además, en él se
describen las relaciones que vinculan dichas actividades y los recursos
necesarios para llevarlas a cabo. Para lograr su objetivo, un modelo consta,
entre otros elementos, de una representación gráfica fácilmente entendible e
interpretable por todos los niveles de usuarios y participantes del negocio, tanto
administradores como desarrolladores y cualquier otra persona que interactúe
en el proceso.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 15
2.4.1. Notaciones de Modelado de Proceso de Negocio
Para llevar a cabo el modelado de un proceso de negocio, existen numerosas
propuestas de lenguajes y notaciones gráficas y estándares, con diferentes
características y alcances. En esta sección se presentan algunas de estas
notaciones y estándares más difundidos y utilizados en el ámbito del modelado
de procesos de negocio a lo largo del tiempo.
2.4.1.1. IDEF
La familia de Lenguajes de Definición IDEF, inicialmente abreviatura de “ICAM
DEFinition” y luego redefinida por los estándares IEEE como “Integration
DEFinition”, fue creada por un programa para la Fabricación Integrada Asistida
por Computadora (ICAM, por su sigla en inglés de Integrated Computer Aided
Manufacturing) de las Fuerzas Aéreas de los Estados Unidos de América en la
década de 1970s. Este programa identificaba las necesidades de mejoras en
las técnicas y análisis de comunicación para personal involucrado en la
producción. El resultado del proyecto es una serie de técnicas conocidas como
IDEF (Integrated Definition Methods). En la propuesta inicial se incluían tres
notaciones: (i) IDEF0, para la representación de actividades o procesos; (ii)
IDEF1, para la representación y estructuración de la información. Esta notación
fue extendida y se creó IDEF1X, para el diseño de bases de datos relacionales;
(iii) IDEF2, para representar modelos dinámicos, es decir modelos que
representan las características comportamentales del sistema modelado.
Posteriormente, IDEF siguió su desarrollo y se definieron nuevas
versiones [43]: (i) IDEF3, provee un mecanismo para coleccionar y documentar
procesos; (ii) IDEF4, enfatiza el proceso de diseño orientado a objetos sobre la
sintaxis y diagramas gráficos como ayuda para focalizar y comunicar temas de
diseño importantes; (iii) IDEF5, provee un método empírica y teóricamente bien
fundamentado especialmente diseñado para asistir a la creación, modificación
y mantenimiento de ontologías.
Así, en sus versiones IDEF0 e IDEF3, esta familia de lenguajes provee
herramientas de modelado adecuadas para la representación de procesos de
negocio. Por esta razón, se describen brevemente cada una de ellas.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 16
2.4.1.2. IDEF0
Esta notación de modelado se basa en una combinación de gráficos y textos
presentados de forma sistemática y organizada. El objetivo principal es lograr
un mejor entendimiento del proceso, brindar análisis de soporte, proveer la
lógica para potenciales cambios, requerimientos específicos, o diseño a nivel
de sistemas de soporte y actividades de integración.
Un modelo IDEF0 está compuesto de una serie jerárquica de
representaciones que gradualmente despliegan niveles incrementales de
detalles. Estas representaciones describen las funciones y sus interfaces
dentro del contexto de un sistema. El método provee tres tipos de
representaciones: diagramas gráficos, descripciones textuales y glosarios. Los
diagramas gráficos definen funciones y relaciones funcionales a través de
sintaxis y semánticas de cajas y flechas. Los descripciones textuales y
glosarios proveen información adicional de soporte de los diagramas gráficos,
[7].
IDEF0 permite el análisis de necesidades y beneficios, la definición de
requerimientos, análisis funcional, diseño de sistemas, mantenimiento y líneas
base (baselines) para la mejora continua. Puede interpretarse un modelo
IDEF0 como un plano de las funciones y sus interfaces que se necesitan
capturar y entender para tomar decisiones lógicas, asequibles, integrables y
alcanzables en la ingeniería de sistemas. El modelo IDEF0 refleja cómo las
funciones del sistema se interrelacionan y operan, de la misma manera en que
el plano de un producto refleja cómo las diferentes piezas del mismo se ajustan
entre sí.
2.4.1.3. IDEF3
El Método de Captura de Descripción de Procesos IDEF3 se creó con la
finalidad de capturar descripciones de secuencias de actividades. Su meta
principal es proveer un método estructurado por el cual un experto del dominio
pueda expresar conocimiento acerca de la operación de un sistema u
organización particular [8]. La idea es posibilitar la adquisición de conocimiento
acerca de un proceso mediante la captura directa de declaraciones acerca del
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 17
proceso y de eventos del mundo real. Además, permite capturar declaraciones
sobre los objetos participantes y soportados por el proceso. Otro objetivo del
método, es la captura de las relaciones de precedencia y causalidad entre los
procesos y eventos que se producen en el ambiente de dicho proceso.
La metodología combina un soporte para la adquisición de conocimiento a
través de la captura de declaraciones sobre los procesos y eventos. Provee un
lenguaje altamente expresivo y fácil de utilizar para la captura y expresión de
información. Esto permite enfocar la atención del usuario en los aspectos
relevantes del proceso y le da la potencia expresiva necesaria para representar
explícitamente información acerca de la naturaleza y estructura de ese
proceso.
Para lograr sus objetivos, se basa en la captura de descripciones
relacionadas con la operación de un sistema particular. Por esta razón, es más
fácil de usar que los métodos de modelado tradicionales. Esto permite el
posterior reuso de la información recopilada. Además, libera a los usuarios de
la tarea de tener que pensar en características de idealizaciones de modelado.
De esta manera, los usuarios sólo deben concentrarse en la recopilación de
observaciones y opiniones acerca de cómo operan los sistemas de negocio.
La estructura organizacional básica para las Descripciones de Proceso
IDEF3 es la noción de un escenario o historia. Un escenario se ve como una
situación recurrente, un conjunto de situaciones que describen una clase típica
de problemas abordados por una organización o sistema, o el marco dentro del
cual un proceso ocurre. Estos escenarios establecen el centro de atención y las
condiciones de frontera de una descripción. Para lograr su objetivo, explotan la
tendencia de las personas a describir su conocimiento como una secuencia de
actividades ordenadas en el contexto de alguna situación particular.
Desde otro punto de vista, para la adquisición de conocimiento, IDEF3
utiliza dos propuestas de modelado [8]: (i) una estrategia centrada en el
proceso, que organiza el conocimiento tomando como centro de atención los
procesos y sus relaciones temporales, causales y lógicas dentro de un
escenario, y (ii) una estrategia centrada en los objetos, que organiza el
conocimiento tomando como centro de atención los objetos y su
comportamiento de cambio de estado, en un único escenario o a través de
escenarios múltiples.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 18
2.4.1.4. UML
Si bien UML ha sido aceptado como estándar para el modelado de sistemas
software, dada la similitud existente entre los procesos de negocio y los
procesos de desarrollo de software, puede ser utilizado para modelar procesos
de negocio. A pesar de las similitudes mencionadas, existen algunas
situaciones en los procesos de negocio para las cuales no son previstas o
adecuadas para ser abordadas por un sistema software (como por ejemplo las
personas que desempeñan los roles de interés para el proceso de negocio).
UML provee mecanismos para crear extensiones que permiten representar
elementos que con los constructores propios del lenguaje no es posible. Dado
que en los procesos de negocio se encuentran elementos no representables
por los constructores de UML, Eriksson et al en [44] propone un conjunto de
extensiones para el modelado de procesos de negocio.
Desde el punto de vista del modelado, un proceso de negocio puede ser
mostrado desde distintas vistas. En UML se pueden utilizar distintos diagramas
para mostrar dichas vistas del proceso de negocio [45].
Dentro de los distintos diagramas que provee UML, los Diagramas de
Actividad son los más importantes para el modelado de procesos de negocio ya
que ellos pueden mostrar las actividades, los objetos consumidos, usados o
producidos por una actividad, quién es responsable de dicha actividad, y las
relaciones y dependencias entre las actividades. Elementos que son
fundamentales a la hora de modelar procesos de negocio.
2.4.1.5. BPMN
BPMN (Business Process Modeling Notation) es un estándar definido por la
BPMI (Business Process Management Initiative). El objetivo primario de BPMN
es proporcionar una notación que sea fácilmente comprensible por todos los
usuarios empresariales, desde los analistas de negocio que crean los
borradores iniciales de los procesos, hasta los desarrolladores técnicos
responsables de implementar la tecnología que realizará dichos procesos y,
finalmente, la gente de negocio que gestionará y supervisará estos procesos.
BPMN crea un puente estandarizado para la brecha entre el diseño del proceso
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 19
de negocio y su implementación [11].
La intención de BPMN es estandarizar una notación de modelado de
proceso de negocio frente a la gran diversidad de notaciones y puntos de vista
del modelado. Para alcanzar este objetivo la notación toma las mejores
prácticas dentro de la comunidad de modelado. BPMN constituye un medio
simple de comunicar información del proceso de negocio a otros usuarios,
proveedores, clientes, etc.
Otro objetivo importante de BPMN es asegurar que lenguajes XML
diseñados para la ejecución de procesos de negocio (como por ejemplo
BPEL4WS), puedan ser vistos como una notación orientada al negocio.
Asimismo, la especificación define la notación y la semántica de un Diagrama
de Procesos de Negocio (DPN). De esta manera, la notación provee una
manera simple de comunicación de información de procesos a otros clientes,
proveedores e implementadores de procesos, y usuarios del negocio [11].
La visualización de los procesos de negocio como organigrama ha tenido
una gran aceptación por los hombres de negocio. Sin embargo, hay una brecha
técnica entre el formato del diseño inicial de los procesos de negocio (como por
ejemplo, definición de procesos de negocio con organigramas simples) y el
formato de los lenguajes de ejecución XML, basados en servicios Web para
sistemas de Gestión de Proceso de Negocio (GPN). Dichos lenguajes
constituyen un mecanismo formal para la definición de estos procesos. Un
ejemplo de estos lenguajes es BPEL4WS. Por lo tanto, se hace necesario un
mecanismo formal para la conversión de una visualización apropiada a un
formato de ejecución apropiado para estos procesos de negocio.
Por lo expuesto en el párrafo precedente, BPMN surge como una solución
a esta brecha mencionada, ya que establece una estandarización en la
Notación y provee un Diagrama de Proceso de Negocio (DPN), destinado a los
diseñadores y gerentes de procesos de negocio. Además, provee un mapeo al
Lenguaje de Ejecución BPEL4WS. De esta manera, BPMN proporciona un
mecanismo de visualización estándar para los Procesos de Negocio definidos
en un lenguaje de proceso de negocio optimizado.
Desde otro punto de vista, la notación gráfica de BPMN provee a las
empresas la capacidad de entender sus procedimientos de negocio internos,
dándoles a las organizaciones, a través de una notación estándar, la capacidad
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 20
de comunicar dichos procedimientos. Además, una notación gráfica facilitará la
inserción de los analistas, gerentes, etc. en nuevas organizaciones. Esto es
fundamental dado el dinamismo actual en el mundo de los negocios, donde las
empresas surgen, se unen y divergen constantemente. Como también el hecho
de que, en las distintas etapas del ciclo de vida de una compañía, surgirán
distintas representaciones de los mismos procesos, acorde a la etapa del ciclo
de vida en que se encuentre. De la misma forma, facilitará la comprensión de
las colaboraciones del funcionamiento y las transacciones de negocio dentro y
entre las organizaciones, asegurando que los negocios sean entendidos
internamente y por los participantes en su negocio. Esto ayudará a las
organizaciones a adaptarse rápidamente a nuevas circunstancias de negocio
internas y B2B.
Por todo lo anterior, BPMN sigue las notaciones de organigramas, lo que
le da una mayor legibilidad, y proporciona un mapeo a construcciones
ejecutables.
2.4.2. Calidad de los Modelos de Procesos de Negocio
El desarrollo de modelos conceptuales constituye una parte del esfuerzo de
implementación de un proceso de negocio. Sin embargo, es una de las tareas
claves en las primeras etapas del ciclo de vida de los procesos de negocio. Son
utilizados, principalmente, como herramientas o medios para que, los distintos
tipos de participantes, puedan entender fácilmente el proceso que dichos
modelos representan. Además, son empleados como punto de partida a la hora
de realizar cambios y adaptaciones de los procesos a las nuevas necesidades
de las empresas. Por ello, es un factor primordial que estos modelos sean de
alta calidad, en cuanto a su entendibilidad y adaptabilidad.
Como se mencionó en el Capítulo 1, cuando se habla de calidad en el
modelado conceptual, se debe distinguir entre la calidad del producto
(relacionada con las características del modelo conceptual) y la calidad del
proceso de modelado (relacionada en cómo se desarrollan los modelos) [12].
Desde esta perspectiva, el presente trabajo se centra en la calidad del
producto.
Si bien existen muchas definiciones de calidad en los distintos campos de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 21
investigación, no se ha encontrado una definición consensuada respecto qué es la
calidad de los modelos conceptuales. Al respecto, Moody [46], propone que
calidad de los modelos conceptuales podría definirse en base a la definición de
calidad de ISO 9000 [19], que declara que:
La totalidad de los rasgos y características de un producto o servicio que
influyen en su habilidad de satisfacer las necesidades implícitas o declaradas
Así, Moody dice que la calidad de los modelos conceptuales se podría definir
como:
La totalidad de los rasgos y características de un modelo conceptual que
influyen en su habilidad de satisfacer las necesidades implícitas o declaradas
Como lo establece Moody [46], es fundamental que toda propuesta para la
evaluación adhiera a estándares aceptados y aplicados prácticamente. En
particular, Moody propone que deberían ser consistente con las normas de calidad
ISO 9000 [19], e ISO/IEC 9126 [20], ya que un modelo conceptual es un tipo
particular de producto (ISO 9000) y, dentro de ISO/IEC 9126 los modelos
conceptuales existen como modelos de sistemas de información. Además declara
que al menos deberían adherir a ISO/IEC 9126, ya que dicha norma adhiere a ISO
9000.
Al respecto, la complejidad de un modelo conceptual puede estar
altamente influenciada por los diferentes elementos que lo componen, tales
como tareas, subprocesos, participantes, eventos, etc. Por lo tanto, no es
aconsejable definir una medida general para su complejidad [13]. Así, Rolon et
al en [47], proponen un conjunto de medidas para la calidad de modelos
conceptuales de procesos de negocio desarrollados en BPMN. Estas medidas
se basan en la propuesta de [48] de medidas para la calidad de proceso
software. No obstante, no se encontraron en la literatura, trabajos que se
refieran a la evaluación de modelos conceptuales de procesos de negocio. Por
ello, se propone un método que permita evaluar la calidad de estos modelos,
en función de su mantenibilidad (especialmente respecto de su entendibilidad
y adaptabilidad), independientemente de su representación, es decir,
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 22
independientemente del lenguaje de modelado o el marco de desarrollo de
dichos modelos.
En este contexto, existen distintos modelos de análisis para la evaluación
de diversos tipos de sistemas, los cuales fueron analizados para establecer los
pasos del método propuesto. En el Capítulo 3 se presenta una introducción y
descripción de los modelos de análisis más relevantes y utilizados de la
literatura.
Carlos H. Salgado 23
CAPÍTULO 3. Modelos de Análisis
3.1. Introducción.
En la actualidad existen distintos métodos para la evaluación de sistemas en
general. El objetivo final de dichos métodos es: decidir cuál de todos los
sistemas evaluados se adecua más a ciertos requerimientos y necesidades
particulares previamente establecidos. En este sentido se pueden encontrar
distintos tipos de situaciones de decisión. Esto lleva a la necesidad de tener
distintos tipos de métodos para realizar la evaluación de los sistemas
estudiados.
El presente trabajo se enfoca en el análisis y estudio de los modelos de
procesos de negocio. El objetivo principal es proponer una metodología que
permita evaluar si un modelo se adecua a las necesidades del negocio que
modela. Para alcanzar dicho objetivo, se analizaron distintos métodos de
evaluación y toma de decisión.
Acorde a lo expuesto previamente, se presenta una clasificación de las
distintas situaciones de decisión. Además, se presenta una breve descripción
de los métodos de decisión más relevantes conocidos en la actualidad. El
objetivo de este análisis es determinar cuáles son las características principales
que deben poseer los métodos de evaluación para ser eficientes y de utilidad.
Esto sirvió de guía en la definición de las características y propiedades a
incorporar en el método propuesto en el presente trabajo.
3.2. Decisión – Situaciones de Decisión
En todos los ámbitos del quehacer cotidiano, se encuentran situaciones en las
que se deben tomar decisiones que afectan a la consecución de un objetivo. En
este sentido, las decisiones se pueden clasificar teniendo en cuenta diferentes
aspectos, como por ejemplo la frecuencia con que se presenta el problema, los
factores que lo provocan, el alcance del mismo, entre otras tantas situaciones.
Así, las decisiones se clasifican en cuanto a las circunstancias que ellas
afrontan, sea cual sea la situación para decidir y cómo decidir.
En función de lo expresado previamente, las decisiones se pueden
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 24
clasificar en:
a) Decisiones programables: Es el caso de situaciones repetitivas y
rutinarias. Para ellas, se elabora un procedimiento definido para
gestionarlas de manera que no es necesario tratarlas nuevamente cada
vez que se presentan.
Para abordar este tipo de decisiones se elabora un procedimiento de
rutina para resolver un determinado problema que se presenta con cierta
frecuencia.
Las decisiones programadas encaran problemas que se pueden
solucionar mediante rutinas persistentes o búsqueda a través de
estructuras organizadas de información.
b) Decisiones no programables: Son aquellas que se deben tomar ante
situaciones novedosas, no estructurales pero que, en sí mismas, son
muy importantes.
Debido a que son novedosas, no es posible seguir ningún método
previsto para manejar el problema en cuestión. Además, su estructura y
naturaleza pueden ser demasiado complejas. Incluso, su relevancia e
importancia pueden requerir que se les dé un tratamiento a medida y
personalizado. Esto hace necesario de una gran creatividad y
experiencia por parte de quienes toman las decisiones, ya que se
prestan a distintas interpretaciones.
En otro sentido, las situaciones, ambientes o contextos en los cuales se
toman las decisiones, se pueden clasificar según el conocimiento y control que
se tenga sobre las variables que intervienen o influyen en el problema. Dichas
variables condicionarán la decisión final que se tome. De esta manera se
pueden clasificar dichas situaciones en:
a) Situaciones de Decisión bajo completa certeza: Se conocen los objetivos
a alcanzar y se tiene información confiable y medible del resultado de
cada alternativa considerada. Es decir, que se pueden predecir con
certeza las consecuencias de las elecciones realizadas. Este tipo de
problemas tienen resolución inmediata, sólo basta con elegir la
alternativa que brinde el mejor resultado. Esto es posible debido a que
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 25
se sabe con exactitud cuál será el resultado de cada alternativa. En
estas situaciones el problema de decisión se reduce a un problema de
optimización, ya que se trata de seleccionar la alternativa que brinde el
mejor resultado.
b) Situaciones de Decisión bajo completa incertidumbre: Se tiene poco
conocimiento acerca de las alternativas o sus resultados. En estos
procesos se cuenta con información acerca de cuáles son los resultados
posibles pero no se sabe cuál ocurrirá. Es decir, no se puede predecir el
escenario que se presentará. Además, no es posible cuantificar la
incertidumbre. No es posible aplicar probabilidades sobre la posibilidad
de que ocurra un evento u otro.
c) Situaciones de Decisión bajo riesgo: Se basa en la probabilidad de que
ocurra un cierto evento que impacte adversamente. El riesgo puede
verse como la medida de la posibilidad y dimensión (magnitud) de los
impactos adversos. Se relaciona con la frecuencia con que ocurre el
evento. Estas situaciones se dan cuando no se tiene la información
suficiente para predecir con certeza el resultado de alguna alternativa
dada, sin embargo se tiene cierto conocimiento que permite estimar la
probabilidad de que ocurra y pueda llevar a resultados esperados.
En esta sección se describió brevemente qué es una decisión, los tipos de
decisiones y las distintas situaciones en las que puede ser necesario tomar una
decisión. En este contexto, muchas veces es necesario elegir entre varias
opciones antes de tomar una decisión, lo que implica seguir un proceso para la
elección de la mejor opción. En la siguiente sección se describe el proceso a
seguir a la hora de tomar una decisión.
3.3. El Proceso de Toma de Decisión
El proceso de Toma de Decisión, según Herbet Simon en [49], puede definirse
como:
Un proceso de selección entre cursos alternativos de acción, basado en un
conjunto de criterios, para alcanzar uno o más objetivos.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 26
Es decir que el proceso de toma de decisión es un proceso en el cual se debe
elegir, de un conjunto de alternativas, cuál de ellas se adecua más a los
requisitos de un problema de manera tal de obtener el mejor resultado posible.
Este proceso se puede dividir en dos fases:
(i) Estructuración del problema de decisión, y
(ii) análisis del problema de decisión.
En la fase de estructuración, se comienza con la definición del problema,
es decir, se establece cuál es el problema a atacar. Una vez establecido el
mismo, se deben detectar las posibles soluciones para él, es decir se
establecen las alternativas entre las que se debe decidir. Al tener las
alternativas posibles, se deben definir los criterios más relevantes que servirán
de guía a la hora de determinar qué alternativa es la más apropiada. Dichos
criterios servirán como una medida, regla o estándar que guía la toma de
decisiones. Estos criterios se clasifican en:
(a) Cualitativos, criterios basados en el razonamiento y la experiencia de quien
toma las decisiones; y
(b) cuantitativos, se utilizan los datos y hechos asociados al problema y se
formulan expresiones matemáticas que describen los objetivos,
restricciones y relaciones existentes en el problema.
En cuanto a la fase de análisis, en primer lugar se hace una evaluación
profunda de las distintas alternativas. Esta evaluación dependerá del método
de evaluación en función de si la misma se realiza utilizando criterios
cualitativos o cuantitativos. Finalmente, y acorde a los resultados obtenidos en
la etapa de evaluación de alternativas, se determina cuál de ellas es la más
apropiada para dar respuesta al problema planteado.
Cuando existen dos o más criterios en conflicto y dos o más alternativas
de solución se dice que se está ante un problema de decisión multicriterio. Esto
da origen a lo que se ha denominado Análisis de Decisión Multicriterio. En la
siguiente sección se describe este tipo de análisis y los métodos basados en él
más difundidos.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 27
3.4. Análisis de Decisión Multicriterio
Como mencionan Martinez y Escudey en [50] “Los métodos de evaluación y
decisión multicriterio comprenden la selección entre un conjunto de alternativas
factibles, la optimización con varias funciones objetivo simultáneas, un agente
decisor y procedimientos de evaluación racionales y consistentes”.
Este tipo de análisis es una manera de modelar los procesos de decisión
en los que se deben considerar distintos aspectos, tales como:
• La decisión a tomar.
• Los eventos desconocidos que pueden afectar los resultados
obtenidos.
• Los posibles cursos de acción a seguir.
• Los resultados en sí mismos.
A través de los modelos multicriterio se puede estimar las posibles
consecuencias e implicaciones que pueden surgir por cada curso de acción
posible a seguir. De esta manera se puede comprender mejor la relación entre
las acciones y los objetivos que se desean alcanzar. Es importante, a la hora
de aplicar estos modelos, tener en cuenta que estos criterios pueden estar en
conflicto estricto. Es decir, que la satisfacción de un criterio puede ir en
detrimento de la satisfacción de otro. Algunos conceptos que se deben tener en
cuenta en estos modelos son:
• Alternativas: Soluciones o acciones que el decisor puede tomar.
• Atributos: Características utilizadas para describir las alternativas. Cada
alternativa puede caracterizarse por varios atributos. Dichos atributos
pueden ser cuantitativos (atributos objetivos) o cualitativos (atributos
subjetivos).
• Objetivos: Los objetivos son aspiraciones que indican direcciones de
perfeccionamiento de los atributos seleccionados, están asociados con
los deseos y preferencias del decisor.
• Metas: Aspiraciones que especifican niveles de deseos de los atributos.
• Criterios: Son los parámetros, directrices y puntos de referencia que
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 28
van a permitir evaluar las opciones o alternativas que se presentan en el
proceso de decisión.
Los métodos multicriterios son herramientas de gran ayuda a la hora de
consensuar la toma de decisiones en el contexto de situaciones complejas.
Estas herramientas ayudan a encontrar soluciones posibles, aunque no
necesariamente óptimas, para determinados problemas. Estas técnicas son de
utilidad en el caso de situaciones donde se pueden encontrar distintos puntos
de vista de distintos grupos o personas y es necesario llegar a un acuerdo que
satisfaga los intereses de todos los involucrados. De esta manera, todas las
partes interesadas participan en el proceso de toma de decisiones. En
resumen, el problema central de los métodos multicriterio consiste en:
1. Seleccionar la(s) mejor(es) alternativa(s).
2. Aceptar alternativas que parecen “buenas” y rechazar aquellas que
parecen “malas”.
3. Generar un listado ordenado de las alternativas consideradas (de la
“mejor” a la “peor”).
Como lo establecen Caballero y Romero en [51], el planteamiento clásico
de los Problemas de Toma de Decisiones, se fundamenta en abordarlos
considerando un único criterio de decisión. Este planeamiento se formula
mediante una única función, llamada función objetivo y una serie de
restricciones, que representan los recursos que son limitados y que influyen en
la decisión. Para obtener la solución al problema de decisión planteado, la
función objetivo se optimiza mediante técnicas matemáticas (maximizar,
minimizar), respetando las limitaciones establecidas por las restricciones y se
obtiene la mejor solución posible (solución óptima). Cuando la función objetivo
puede tomar un número indeterminado o infinito de valores, los cuales llevan a
un número infinito de posibles alternativas del problema, se dice que se está
ante una Decisión Multiobjetivo. En el caso de los problemas en que las
alternativas posibles son finitas, se denominan Problemas de Decisión
Multicriterio Discreta. Este último tipo de problemas es el más comúnmente
encontrado en la vida real y son descriptos en la siguiente sección.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 29
3.4.1. Métodos de Evaluación y Decisión Multicriterio Discretos
Como se mencionó previamente, estos problemas son los más comunes en la
vida real. Son utilizados para llevar a cabo una evaluación para poder tomar
una decisión respecto de problemas que admiten, dada su naturaleza y diseño,
un número finito de alternativas. Dichas alternativas se establecen a través de
[50]:
• Un conjunto de alternativas de solución estable y finito que satisfacen
ciertas restricciones posibles o previsibles. Cada alternativa es
identificable aunque no se conozca en forma exacta y total todas las
consecuencias cualitativas y cuantitativas que ella conlleve.
• Un conjunto de criterios de evaluación para evaluar cada alternativa y
analizar sus consecuencias. Este análisis se realiza en función de una
ponderación propuesta por quien toma las decisiones. Estos pesos
establecen la importancia o preferencia relativa de cada criterio.
• Una matriz de decisión o impacto. En esta matriz se resume la
evaluación de las distintas alternativas en función de los criterios
establecidos, una valoración precisa o subjetiva de las soluciones según
dichos criterios. La escala en que se miden las evaluaciones puede ser
cuantitativa o cualitativa y las medidas pueden ser expresadas en
escalas cardinal, ordinal, nominal y probabilística.
• Una metodología o modelo de agregación de preferencias. El objetivo es
obtener una síntesis global, ordenamiento o jerarquía de las
evaluaciones previamente efectuadas que permita establecer cuál es la
alternativa de solución que recibe la mejor evaluación global.
• Un proceso de toma de decisiones. En él se realiza una negociación
entre los actores de manera de llegar a un consenso respecto de la
mejor alternativa que satisfaga las necesidades de todos los
interesados.
Estos métodos, si bien es de suma importancia que tengan solidez y
fundamento teórico, deben ser fáciles de entender y aplicar por quienes toman
las decisiones. Si son complejos de aplicar y entender, es altamente probable
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 30
que se den situaciones en las que no se utilicen estos métodos. Esto se debe a
que, quienes deben aplicar estas técnicas multicriterios, no terminan de
comprenderlas y sienten que el proceso de decisión escapa a su control. Si
esto sucede, dicha situación puede ir en detrimento del proceso de decisión, ya
que quien lo lleva a cabo debe controlarlo en todo momento.
En las siguientes secciones se describen brevemente algunos de los
Métodos de Decisión Multicriterios Discretos más difundidos.
3.4.1.1. Ponderación Aditiva Simple (SAS - Simple Additive
Scoring)
Esta técnica se basa en el concepto de promedio ponderado. Se utilizan pesos
para indicar la importancia relativa de los atributos de idoneidad [52, 53]. Un
decisor asigna directamente un peso wi a cada atributo de idoneidad ai,
i=1,...,n. Estos pesos asignados son convertidos a pesos normalizados Wi,
i=1,...,n, tal que ∑ni=1Wi = 1. La puntuación total o el grado total de idoneidad S
de cada sistema se calcula a través de los siguientes pasos:
• Determinar las n componentes de idoneidad s1,......, sn que se obtienen
de la evaluación de los n atributos para el sistema evaluado.
• Multiplicar cada componente de idoneidad si por el peso normalizado Wi
de su correspondiente atributo.
• Sumar los productos sobre todos los atributos, es decir, S = ∑ni=1 Wisi.
Por lo tanto, SAS usa un modelo de agregación lineal ponderado simple.
Este método permite abordar situaciones de incertidumbre o en las que se
tiene poca información. Consiste en la construcción de una función de valor
para cada alternativa elegible y supone la transitividad o la comparabilidad de
preferencias. Es un método compensatorio y es muy dependiente de la
asignación de los pesos a los criterios y de la escala en que se miden las
evaluaciones. Es un método fácil de utilizar y por ello ampliamente difundido,
especialmente entre los inexpertos, ya que ayuda a entender el proceso de
decisión. Sin embargo, es muy manipulable lo que lo hace un método criticado.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 31
3.4.1.2. Teoría de Valor Multiatributo (MAVT: Multiattribute
Value Theory)
Esta técnica es utilizada para abordar problemas que involucran un conjunto
finito y discreto de alternativas que deben ser evaluadas basándose en
objetivos conflictivos. Para cada uno de dichos objetivos, se utilizan diferentes
criterios para medir el desempeño de cada alternativa en relación a ese
objetivo [54]. Usualmente, para la medición de dichos criterios, se utilizan
escalas diferentes. Es una técnica compensatoria, es decir que un bajo
desempeño de un criterio puede ser compensado por un buen desempeño de
otro criterio. MAVT, obtiene una evaluación global agregando los desempeños
individuales de los distintos atributos o criterios.
El objetivo de esta técnica es construir un medio para asociar un número
real con cada alternativa para producir un orden de preferencias sobre dichas
alternativas. EL mencionado orden de preferencias es consistente con el juicio
de valor del decisor.
Para lograr su objetivo, MAVT asume que para cada problema de
decisión existe una función que representa el juicio del decisor. A través de
dicha función se evalúan atributos de idoneidad ai, i = 1,......,n utilizando
funciones de valor que intentan representar matemáticamente los juicios
humanos. Una función de valor de atributo único traduce el desempeño de los
valores de atributos alternativos en una puntuación de valor que representa el
grado en el que se logra la decisión objetivo. Como tal, la función de valor vi
asocia un número (o “valor”) vi(a) con cada valor alternativo a del atributo ai de
manera tal que se obtiene un orden de preferencia sobre las alternativas
consistente de juicios de valor del decisor.
Para la agregación, se utilizan funciones de valor más complejas. La
función más comúnmente utilizada es la función de ponderación aditiva simple
S = ∑ni=1 Wivi(ai) donde Wi es el peso del atributo de idoneidad ai y vi(ai) es el
valor del atributo de idoneidad ai. Esta propuesta es válida si los atributos de
idoneidad son preferentemente independientes. Los pesos Wi son constantes
escalables que tienen que ser derivadas con respecto a los rangos de los
atributos. Los pesos deben sumar 1, es decir ∑ni=1Wi = 1.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 32
3.4.1.3. Teoría de Utilidad Multiatributo (MAUT: Multiattribute
Utility Theory)
Una técnica muy relacionada a MAVT es la Teoría de Utilidad Multiatributo
(MAUT por su sigla en Inglés de Multiattribute Utility Theory [55, 56]). Esta
técnica se basa en la teoría de la utilidad y necesita de suposiciones más
fuertes para asegurar la aditividad. Una de sus principales ventajas es que
puede considerar y representar directamente en su modelo soporte la
incertidumbre. Es decir, es de gran aplicabilidad cuando los riesgos o
incertidumbres tienen un rol significativo en la definición y evaluación de
alternativas.
La actitud del decisor hacia el riesgo se incorpora a través de una función
de utilidad de atributo único ui. Dicha función se obtiene del análisis de utilidad
y traduce los valores del atributo de idoneidad ai en “unidades de utilidad”.
Donde, una unidad de utilidad es un valor relativo entre 0 y 1, denotando 0 el
peor valor y 1 el mejor. Estas funciones, por naturaleza, se basan en el
concepto de probabilidad.
Al igual que en MAVT, la agregación se realiza a través de una función de
utilidad multiatributo total, generalmente una función de ponderación aditiva
simple (o en algunos casos multiplicativa) S, donde S = ∑ni=1 Wiui(ai). Los
atributos de idoneidad preferentemente deben ser independientes y los pesos
Wi, i=1,…,n deben sumar 1, es decir ∑ni=1Wi = 1. Al determinar la utilidad de
cada alternativa, se obtiene un ordenamiento total del conjunto de alternativas.
Al igual que MAVT, este método supone la transitividad o comparabilidad
de preferencias. Además, utiliza escalas de intervalos y acepta el principio de
preservación de orden.
Para la aplicación de MAUT, es necesario un alto nivel de información por
parte del decisor para la definición de las funciones de utilidad. Esto se debe en
parte a que permite abordar cuestiones de riesgo e incertidumbre, como se
mencionó previamente. No obstante sus virtudes, es una técnica difícil de
aplicar.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 33
3.4.1.4. Proceso Jerárquico Analítico (AHP: Analytic hierarchy
process)
AHP, creado por Thomas Saaty [57], permite organizar la información acerca
de un problema de decisión gráficamente y de manera eficiente, lo que
posibilita descomponerla para llevar a cabo un análisis por partes de dicha
información. Esta representación permite visualizar mejor los cambios en los
distintos niveles. Como dice Saaty [57]: Trata de desmenuzar un problema y
luego unir todas las soluciones de los subproblemas en una conclusión. El
método se basa en una serie de etapas, las cuales pueden resumirse en [57,
58]:
- Modelar el problema como una jerarquía que contiene la meta de decisión,
las alternativas para alcanzarlas y los atributos de idoneidad para evaluar
las alternativas. El decisor debe lograr desglosar el problema en sus
componentes más relevantes.
- Establecer prioridades (pesos normalizados) entre los elementos de la
jerarquía haciendo una serie de juicios basados en comparaciones de pares
de elementos. El decisor debe emitir sus juicios de valor o preferencias en
cada uno de los niveles jerárquicos establecidos. Esta tarea consiste en una
comparación de valores subjetivos por parejas (comparaciones binarias). El
decisor emite juicios de valor sobre la importancia relativa de los criterios y
de las alternativas. El objetivo es reflejar el dominio relativo de una
alternativa frente a otra, en términos de importancia, preferencia o
probabilidad, con respecto a un atributo, propiedad o cualidad común.
- Sintetizar estos juicios para mantener un conjunto de pesos totales para la
jerarquía. Esto se logra mediante una secuencia de multiplicaciones de las
matrices de pesos relativos en cada nivel de la jerarquía. Un aspecto sobre
el que se debe tener cuidado, es la consistencia del resultado con las
preferencias declaradas por el decisor. Esto afecta directamente a la calidad
de la decisión final.
- Chequear la consistencia de los juicios.
- Arribar a una decisión final basada en los resultados de este proceso.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 34
3.4.1.5. Métodos de Superación (Outranking Methods)
Estos métodos se basan en la idea de utilizar criterios estrictamente relativos.
Dichos criterios expresan un rango de indiferencia a preferencias fuertes de
una alternativa de manera separada para todos los atributos individuales.
Luego se promedian, a través de la media aritmética, las preferencias de los
atributos, de esta manera se establece la credibilidad de la relación de
superación de dos alternativas [59]. En estos casos las entradas no son
mandatorias. Otra opción para obtener el grado total de superación de dos
alternativas es utilizando un producto, esto hace que todos los atributos sean
mandatorios.
Debido al conflicto natural existente entre los criterios, muchas
alternativas en un problema multicriterio son incomparables. Estos métodos, en
general, admiten la existencia de alternativas incomparables. Esto lleva al
decisor a tener que analizar bajo qué criterios las alternativas muestran un
buen comportamiento y bajo cuáles no. De esta manera es posible realizar una
mejor elección de acuerdo al esquema de preferencias que el decisor
establece.
Existen diversas propuestas dentro de los métodos de superación. Dos de
dichas propuestas aplicadas en diversos ambientes son variantes de los
métodos ELECTRE y PROMETHEE.
ELECTRE (Fr. Elimination et Choix Traduisant la Réalité): ELECTRE es una
familia de métodos, propuestos por Roy Bernard [60], basados en relaciones de
superación utilizados para determinar una solución para un problema que, sin
ser óptima, pueda ser considerada satisfactoria. Además, estos métodos
permiten obtener una jerarquización de las acciones alternativas bajo análisis.
Hay dos partes principales para la aplicación de ELECTRE: (i) la construcción
de una o varias relaciones de superación, la cual apunta a comparar de manera
completa cada par de acciones; (ii) un procedimiento de explotación que se
elabora basados en las recomendaciones obtenidas en la primera fase. La
naturaleza de las recomendaciones depende del problema abordado: elegir,
clasificar u ordenar. Los criterios en estos métodos tienen dos conjuntos de
parámetros distintos: los coeficientes de importancia y los umbrales de veto.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 35
Actualmente se han desarrollado diversas versiones que proveen
procedimientos para resolver distintos problemas surgidos en el tratamiento de
la teoría de la decisión [61]. Entre dichas versiones se pueden mencionar:
Electre I: Pretende resolver una problemática P.α de selección del mejor
conjunto de acciones. Trabaja con relaciones de superación en las que, a cada
par de acciones, se asocian dos índices: (i) un índice de concordancia que
mide la intensidad de los argumentos a favor de la afirmación “la acción a
supera a la acción b”; y (ii) un índice de discordancia que mide la cantidad o
intensidad de argumentos contrarios dentro de los criterios bajo análisis, que
pone en duda la afirmación “la acción a supera a la acción b”.
Electre II: atiende a la problemática P. γ de ordenación completa o parcial de
acciones. Los autores de Electre II (Roy y Bertier, 1973) introdujeron varias
modificaciones al método. La concordancia y discordancia es definida como en
Electre I y se determinan dos límites o umbrales para cada uno de estos
índices. A partir de los mismos puede construirse una relación de superación
fuerte y otra débil, en función de las relaciones obtenidas entre los índices y los
umbrales para cada par de acciones a y b.
Electre III: como Electre II el problema abordado por Electre III es el de
ordenación de un conjunto de acciones (P. γ). Esta versión más sofisticada
utiliza relaciones de superación valorizadas (se obtiene de este modo un orden
completo como en el caso de los métodos MAUT o AHP). Ello implica que a la
relación de superación se le atribuye un escalar (entre 0 y 1) que mide el grado
de credibilidad de la relación de superación entre un par ordenado de acciones.
La comparación de pares de acciones respecto a un determinado atributo se
realiza mediante pseudocriterios que toman explícitamente en cuenta umbrales
de preferencia y de indiferencia, es decir que se consideran conceptos de la
teoría de conjuntos borrosos [62]. Utilizando una mayor cantidad de parámetros
a ser determinados por el decisor que en Electre II, se llega a la construcción
de dos preórdenes completos, los cuales finalizan en un ordenamiento
valorizado de las acciones.
Electre IV: Desarrollado por Roy y Hugonnard (1982), se basa en la
consideración de una familia de pseudocriterios (como Electre III). Su propósito
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 36
es obtener una ordenación de las acciones (P. γ), aunque no requiere la
ponderación de los criterios ya que funciona mediante una secuencia de
relaciones de superación anidadas. Se construyen dos relaciones de
superación (una fuerte y otra débil) sobre la base de consideraciones de
“sentido común” compatibles con la carencia de información respecto a la
importancia relativa de los criterios. La exploración de las relaciones se realiza
como en Electre III pero es más sencilla dado que hay solamente dos niveles
de superación.
Electre IS: Es una generalización del método ELECTRE I. Dado un conjunto
finito de acciones, valuados respecto de una familia coherente de criterios
cuantitativos o cualitativos (pseudocriterios), el método ayuda en la
comparación de las acciones en vista de obtener una alternativa final o un
subconjunto de alternativas (P.α). El método agrega las preferencias parciales
en una relación de superación neta que se analiza bajo la forma de un grafo. El
subconjunto buscado está constituido por el núcleo del grafo.
Electre TRI: Es una herramienta de ayuda a la decisión multicriterio,
especialmente concebida para tratar los problemas de clasificación o de
segmentación (P.β). El problema de segmentación consiste en examinar el
valor intrínseco de cada acción (solicitud, candidatos, proyectos, etc) a efectos
de proponer una recomendación o dictamen apropiado para cada una de ellas.
Partiendo de un conjunto discreto de acciones evaluadas respecto de una
familia de criterios cuantitativos y/o cualitativos, así como de un conjunto de
categorías correspondientes a recomendaciones o dictámenes predefinidos
(por ejemplo: bueno, regular, malo, muy malo,...), ELECTRE TRI provee a los
usuarios dos procedimientos diferentes que permiten afectar todas las
alternativas a dichas categorías. Estos procedimientos rechazan la posibilidad
de compensación total entre las valuaciones de la acción respecto a los
diferentes criterios (principio de la suma ponderada –lógica compensatoria). La
afectación de una acción cualquiera se fundamenta en la comparación de la
acción bajo análisis y de las acciones de referencia por medio de la relación de
superación. Ambos procedimientos difieren por su comportamiento (pesimista u
optimista) en relación a algunas acciones incomparables con las acciones de
referencia.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 37
PROMETHEE (Preference Ranking Organization Method for Enrichment
Evaluations): Este método fue propuesto por Jean Pierre Brans, [63]. Este
método consiste [64], como en Electre III, en la construcción de relaciones de
superación valorizadas, incorporando conceptos y parámetros que poseen
alguna interpretación física o económica fácilmente comprensibles por el
decisor. Estos métodos utilizan el concepto de pseudocriterio, construyen el
grado de superación entre dos acciones ordenadas considerando la diferencia
de puntuación que dichas acciones poseen respecto de cada atributo. Dichas
diferencias pueden ser evaluadas a través de seis funciones de valor utilizadas
de acuerdo a las preferencias del decisor. El decisor también debe
proporcionar los umbrales de indiferencia y preferencia asociados a los
pseudocriterios. A diferencia de Electre III, PROMETHEE no utiliza
explícitamente el concepto de índice de discordancia. Desde su origen, han
sido definidas diversas versiones del método. Así, en Promethee I se obtiene
un preorden parcial, en tanto que en Promethee II puede obtenerse un
preorden total considerando los flujos netos (entrantes — salientes) de cada
alternativa. Otras variantes del método plantean situaciones más sofisticadas
de decisión, en particular problemas con un componente estocástico. Así se
han desarrollado las versiones Promethee III, Promethee IV y Promethee V. En
Promethee V [65], se incorpora una filosofía de optimización entera a efectos
de abordar problemas de selección de inversiones con restricciones
presupuestarias (Problemática P.εεεε).
3.4.1.6. Marcas Lógicas de Preferencias (LSP: Logic Scoring of
Preferences)
LSP es un método cuantitativo que permite establecer una clasificación de
diferentes clases de sistemas. Para más información ver [66, 67, 68]
El primer paso en el proceso de evaluación se refiere a: establecer los
requerimientos del sistema, sus principales atributos y sus posibles valores.
Estos atributos se conocen como Variables de Performance (VP). A cada una
de estas variables se le asigna una Preferencia Elemental (PE) cuando se
aplica el Criterio Elemental (CE) correspondiente a la misma. Un CE es una
función que transforma los valores obtenidos de una VP en valores en el
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 38
intervalo [0, 1].
Las PE constituyen los parámetros de la Función de Criterios de LSP.
Esta función devuelve un valor global único que representa el grado de
satisfacción de los requerimientos del sistema. Se construye combinando las
PE. En otras palabras, un grupo de PE se sustituirá por una única PE que
indica el grado de satisfacción asignado por el evaluador al grupo de PE de
entrada. Con el fin de calibrar la Función de Criterios de LSP, se deben
considerar los requerimientos de los usuarios finales. El proceso de calibración
representa la fase más compleja de la evaluación.
La Preferencia Global E0 es la salida de la Función de Criterios. Para
obtener este valor, las PE se combinan teniendo en cuenta su importancia
relativa y una relación lógica entre ellas. Esta relación lógica se obtiene a
través de la creación de la estructura de agregación lógica. Dicha estructura
incluye los pesos y los operadores disponibles en la Lógica de Preferencias
Continua. Esta estructura resulta de las VP y su combinación con las
Funciones de Agregación.
LSP es un método aplicable a diferentes situaciones de la vida real y
desarrollado para soportar operadores lógicos observados en el razonamiento
humano [66]. Esto es fundamental en la evaluación de modelos de procesos de
negocio, puesto que en dichos modelos el razonamiento y el juicio de los
desarrolladores es muy importante. Cabe destacar que este método de
evaluación es la base para la definición del presente trabajo.
Carlos H. Salgado 39
CAPÍTULO 4. MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
4.1. Introducción
En el ámbito de los negocios actuales, las organizaciones necesitan de
herramientas que les permitan lograr un desempeño altamente competitivo y
productivo. Desde este punto de vista, es de suma utilidad para las
organizaciones tener un medio que les permita:
- Representar sus procesos de negocio eficientemente.
- Comunicarse e interactuar con otros procesos, ya sea de la misma
organización o de organizaciones con las que podría necesitar interactuar.
En función de los aspectos mencionados previamente, el objetivo del
trabajo es proveer a los diseñadores, analistas y/o desarrolladores un medio
que les ayude a obtener modelos de proceso de negocio de calidad,
independientemente de la notación en la que se construya el modelo. Esta
propuesta es aplicable en las distintas fases de la definición y el modelado de
los procesos de negocio de una empresa, institución, etc.
Para lograr su objetivo, la primera etapa del método propuesto consiste
en la determinación, agrupamiento y análisis de las características más
relevantes que debe satisfacer todo modelo conceptual de Proceso de
Negocio. De esta manera, se propone plasmar sobre una estructura dichas
características. Esta estructura permitirá, en las siguientes etapas del método,
estudiar el grado en que los modelos satisfacen las mismas.
Las características mencionadas, se tomaron de distintos estándares, la
experiencia de expertos en el modelado de Procesos de Negocio y el
estudio/análisis de modelos de algunos casos de estudio particulares.
Al aplicar el método en la evaluación de modelos de procesos de negocio,
las mencionadas características servirán:
- Como base para que modeladores, desarrolladores y principiantes se
introduzcan en las características comunes a todo modelo de Procesos de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 40
Negocio.
- Para introducir a los estudiantes en el modelado de procesos de negocio.
- Para los expertos en el Modelado de Procesos de Negocio, como punto de
partida para el análisis y la definición de modelos de procesos de negocio
de calidad. De manera que dichos modelos sirvan a la organización como
una herramienta, no sólo de comunicación de los procesos, sino también
que ayude a la mejora continua de dichos procesos.
Como se mencionó en el Capítulo 2, Moody en [46], afirma que es
fundamental que toda propuesta para la evaluación adhiera a estándares
aceptados y aplicados prácticamente. Particularmente, Moody establece que
dichas propuestas deberían ser consistente con los estándares de calidad ISO
9000 [19] e ISO/IEC 9126 [20]. Así, siguiendo la propuesta de Moody, se utilizan
conceptos de estándares como ISO 9000, ISO/IEC 9126, ISO/IEC 14598 [69], etc.
en la definición del método. Esto aumenta la probabilidad de aceptación en
distintos ámbitos y que se generalice su uso. Además, utilizar estándares en la
definición del método permite el uso de un vocabulario conocido y provee una
forma para realizar la evaluación y organizar los resultados. Principalmente, el
método se basa en el estudio de la mantenibilidad de los modelos conceptuales
de procesos de negocio. Por este motivo, se hace hincapié en las características
entendibilidad y adaptabilidad de la norma ISO/IEC 9126 para analizar la
mantenibilidad de los modelos evaluados. Se hace el estudio en base a los
elementos que pueden conformar un modelo conceptual de procesos de negocio,
independientemente del lenguaje de modelado. Además, el método propone la
especificación de quiénes están involucrados en las evaluaciones y cómo y
cuándo ellas deberían ser conducidas en el ciclo de vida del producto: el modelo
de proceso. Un punto que es omitido en la literatura de calidad de modelos
conceptuales.
En cuanto a los evaluadores, ellos pueden ser personas de la misma
empresa, es decir evaluadores internos, o personas externas a la organización
que actuarán como evaluadores externos.
Además, servirá a los responsables del proceso como apoyo en la toma de
decisiones. Por lo que es de mayor utilidad en las primeras fases del modelado de
los procesos de negocio. Esto reducirá los costos que implica detectar y solucionar
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 41
fallas o errores en etapas posteriores.
Todo proceso de evaluación debe ser documentado de manera que sirva a
sus propósitos. Así, la documentación que se obtiene debe ser organizada y
almacenada para poder aspirar a una mejora continua en la organización. Por este
motivo, en el método se propone una manera de documentar los resultados
obtenidos en la evaluación.
Cabe destacar, que la estructura propuesta en el método de ninguna manera
se considera estática. La misma se encuentra abierta a los cambios tecnológicos,
tanto en hardware como en software, a las cambiantes políticas empresariales de
gestión de negocios actuales y a posibles actualizaciones de los estándares de
modelado y calidad.
4.2. Fases del Método
EL método propuesto se divide en 4 fases bien diferenciadas, comenzando con
el establecimiento de los requerimientos de calidad a evaluar hasta el análisis
de los resultados obtenidos. Las 4 fases mencionadas son:
1. Determinación y Especificación de los Requisitos de Calidad
Deseados. En esta fase se definen y especifican las características de
calidad que se desean evaluar partiendo de una estructura mínima
propuesta en el método. Dicha estructura, se considera como base para
el análisis de todo modelo de procesos de negocio. Sin embargo, no es
una estructura estática y cerrada.
2. Definición de los Criterios Elementales de Evaluación. En esta fase
se deben definir los criterios elementales para evaluar las características
de calidad establecidas en la estructura obtenida en la fase anterior.
Estos criterios, son funciones que mapean los valores de cada
característica medible al intervalo [0, 1]. Dichos valores, denominados
preferencias elementales, serán utilizados como entrada a la Función de
Criterios definida en las etapas posteriores. Esta función combinará
estas preferencias elementales para obtener la evaluación global del
sistema analizado.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 42
3. Definición de la Estructura de Agregación para la Evaluación
Global. En esta fase se debe definir la Función de Criterios mencionada
en el punto anterior. Para su definición, se debe construir a través del
uso de los conectores de la lógica de preferencias continua (Apartado
4.2.3) la Estructura de Agregación Lógica. Para la construcción de dicha
estructura, se sigue una estrategia de agregación de las preferencias
elementales obtenidas en las primeras fases del método. A partir de esta
estructura, se obtiene una preferencia global que indicará el grado en
que el modelo estudiado satisface los requerimientos deseados.
4. Documentación, Análisis de Resultados y Conclusiones. Esta fase
corresponde a la fase final del método. En ella se debe realizar un
análisis y comparación de los resultados obtenidos en la evaluación de
los modelos. Dicha evaluación se debe llevar a cabo respecto de las
preferencias elementales, tanto parciales como globales, obtenidas en la
aplicación del método. Además, se debe especificar una documentación
de los resultados obtenidos. El objetivo de esta documentación es que
sirva como referencia e historial de la evolución del proceso de negocio
estudiado en futuras modificaciones y actualizaciones del mismo. Desde
otra perspectiva, esta documentación servirá como punto de referencia y
comparación a la hora de evaluar nuevos modelos y procesos de
negocio.
En las siguientes secciones se presenta la descripción de cada una de
estas fases.
4.2.1. Determinación y Especificación de los Requisitos de
Calidad Deseados
Esta fase se refiere al proceso de determinación de los requerimientos por
medio de una estrategia que, partiendo de una estructura base de
características y propiedades, permita ampliar dicha estructura de manera de
satisfacer y abarcar todos los aspectos de interés. Es decir, se incluyen
actividades que permiten determinar los artefactos y características que los
modelos de procesos de negocio deberían poder representar de manera de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 43
satisfacer las necesidades de los interesados. Como resultado de esta fase, se
obtiene una estructura de árbol que refleja las características y sub-
características de los procesos de negocio que todo modelo debería
representar.
Acorde a lo expresado en el párrafo anterior, en esta fase se deben
determinar claramente cuáles son los requerimientos que deben cumplir los
modelos de procesos, los principales atributos a evaluar y los rangos de
valores que estos atributos pueden tomar. Estos atributos son las llamadas
Variables de Preferencias.
Para poder desarrollar una lista exhaustiva de los requerimientos, es
necesario realizar un proceso de descomposición jerárquica. Inicialmente, se
definen todos los grupos más importantes de requerimientos y luego, a través
de descomposiciones sucesivas, cada grupo se descompone en subgrupos.
Repitiendo este proceso se obtiene una Estructura de Categorización de los
Requerimientos del Sistema, cuyas hojas representan las Variables de
Preferencias.
Como punto de partida para la obtención de la estructura de
categorización de requerimientos del sistema para modelos de procesos de
negocio, se propone una estructura básica. Para arribar a dicha estructura se
analizaron distintas propuestas de la literatura en las cuales se estudian
distintos aspectos del modelado de procesos de negocio. Al respecto, Kirikova
and Makna [70], establecen las características que deben tener las
herramientas de modelado de procesos de negocio, y qué objetos deben poder
modelar dichas herramientas. Estas características se basan en los elementos
que los lenguajes de modelado proveen para la representación de los distintos
procesos. Dichas características fueron consideradas a la hora de definir la
estructura propuesta. Además, se analizaron los modelos de procesos de
negocios propuestos por la OMG en la Especificación de BPMN [11] y por
Integrated DEFinition Methods (IDEF [43]) para un estudio de los distintos
aspectos y características que permiten representar cada uno de los elementos
y componentes de dichos procesos de negocio. El análisis se complementó con
la propuesta de Jiménez et al. [31], en donde los autores hacen un estudio
comparativo entre diferentes modelos de procesos de negocios. En ese
estudio, los autores dividen los elementos representables de un proceso de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 44
negocio en dos categorías: (1) Comunes a representaciones de negocio, y (2)
Centrados en aspectos informáticos. En función de dicha clasificación, y el
objetivo principal del presente trabajo, se hizo hincapié en la primera categoría
para la definición de la estructura de requerimientos básica propuesta.
Acorde a lo estudiado en las propuestas mencionadas previamente, se
realizó una clasificación de las características básicas que todo modelo de
proceso de negocio debe poder representar. A partir de dicha clasificación se
arribó a una estructura que, dependiendo de las necesidades propias del
proceso a modelar, sirve como base para lograr la estructura completa que
caracterice al problema particular. La Figura 4.1 muestra la estructura de
categorización de los requerimientos propuesta. Esta estructura establece los
elementos de los procesos de negocio (tareas o actividades, tipos de
estructuras de control de flujo, conexión entre actividades, participantes,
recursos, etc.) que se considera que todo modelo de procesos de negocio
debería poder representar claramente, independientemente del lenguaje de
modelado utilizado.
1. Tareas/Actividades 1.1. Simples/Atómicas 1.2. Compuestas/Subprocesos
2. Puntos de Sincronización del Flujo de Ejecución 2.1. Puntos de Decisiones 2.2. Puntos de Uniones 2.3. Puntos de división en Ejecución Paralela y/o Concurrente
3. Eventos 3.1. Eventos de Inicio 3.2. Eventos Intermedios 3.3. Eventos Finales
4. Participantes / Actores 4.1. Internos
4.1.1. Número de Participantes/Actores 4.1.2. Comunicación entre Participantes/Actores
4.2. Externos 4.2.1. Número de Participantes/Actores
5. Recursos 5.1. Producidos / Generados en el Proceso (Internos) 5.2. Externos
Figura 4.1. Estructura básica de categorización de requerimientos del sistema para la evaluación de Modelos de Procesos de Negocio
En los siguientes párrafos se describen cada uno de las características
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 45
incluidas en la estructura propuesta.
1. Tareas / Actividades. Todo proceso de negocio es considerado como una
secuencia de actividades realizadas en un cierto orden. Por lo tanto, todo
modelo de procesos de negocio debe poder representar las tareas a realizar
en el proceso. Dichas tareas, en general, se clasifican en dos tipos: (i)
actividades simples, una única acción a ser realizada de manera unitaria, o
(ii) compuestas, es decir que para lograr el objetivo de la misma se deben
realizar otras tareas que contribuyan a la realización de la tarea más
compleja. Esta clasificación de las tareas es la representada en el ítem 1 de
la estructura de requerimientos propuesta.
2. Puntos de Sincronización del Flujo de Ejecución. Una vez establecidas las
tareas a realizarse en el proceso, el siguiente aspecto fundamental es
establecer el flujo de ejecución de las mismas. Considerando las
características de los procesos de negocio actuales, dicho flujo puede ser
secuencial o paralelo. Además, en todo proceso de negocio se producen
situaciones en las cuales se debe tomar una decisión de qué acción o
actividad realizar de acuerdo a una condición o evento que pueda darse.
Por lo tanto, es fundamental que todo modelo pueda representar estas
situaciones de manera clara. Por ello, se incluye en la estructura de
requerimientos el ítem 2, el cual hace referencia a la posibilidad de
representar los flujos de ejecución considerando las distintas situaciones
planteadas anteriormente. Respecto de los ítems 2.1 y 2.2, en la estructura
de la Figura 4.1, el hecho de representar Decisiones y Uniones, se refiere a
la posibilidad de modelar situaciones en las que el flujo de ejecución se
deba dividir en distintos flujos (excluyentes o no) y luego unirse en un solo
hilo de ejecución. La variable 2.3, hace referencia a la representación de
puntos donde el flujo de ejecución del proceso se divide en flujos paralelos
y/o concurrentes.
3. Eventos. En el desarrollo de todo proceso de negocios, intervienen eventos
que afectan su ejecución. Estos eventos pueden ocurrir en distintos
momentos a lo largo del tiempo de vida del proceso. Además, ellos pueden
influir ampliamente en el correcto desempeño de las actividades que forman
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 46
el proceso. Por ello, es también muy importante poder modelar tanto la
ocurrencia como el momento en que estos eventos pueden suceder. Por
este motivo se incluyó, en la estructura propuesta, un ítem que permita
evaluar en qué grado un modelo representa los eventos que pueden ocurrir
en el proceso. De esta manera, el ítem 3 presenta una clasificación de los
eventos desde el punto de vista del momento durante el proceso en que
ellos ocurren.
4. Participantes / Actores. Otro aspecto importante a tener en cuenta en todo
proceso de negocio es saber quién o quiénes realizan las distintas
actividades del proceso. Es decir, conocer los participantes o actores
quienes interactúan en el proceso para que el mismo pueda ser puesto en
ejecución. Además, es de utilidad conocer el grado de comunicación
existente entre los participantes del proceso ya que ello puede ayudar a
detectar problemas y errores producidos debido a la falta de comunicación
entre los participantes. Por este motivo, se incluye en los requisitos el ítem
4. En él se clasifican los participantes en externos e internos, y se incluyen
características que permiten evaluar el número de participantes del proceso
y la comunicación entre ellos.
5. Recursos. Finalmente, es de esperar que todo proceso de negocio consuma
distintos tipos de recursos que ayuden a los participantes a realizar
eficientemente las actividades que le competen. Por ello, el ítem 5 de la
estructura de requerimientos, propone una clasificación de los recursos, de
manera que se pueda evaluar si los modelos analizados representan
claramente la utilización y disponibilidad de los recursos necesarios, como
así también si se puede determinar la correcta distribución de los mismos.
Cabe destacar que la presente clasificación se basa en el concepto de que
un recurso es “una entrada a un proceso de negocio que, típicamente, se
consume durante el procesamiento” [71], por ello bajo esta clasificación los
participantes no son considerados como un recurso.
4.2.2. Definición de los Criterios Elementales de Evaluación
En esta fase se deben definir los criterios para evaluar los atributos
establecidos en la estructura de requerimientos obtenida en la fase anterior
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 47
(Para más información acerca de la definición de los criterios elementales ver
[66, 67, 68]). Es decir, cada una de las Variables de Preferencias definidas en
la fase anterior es transformada en una Preferencia Elemental al aplicarle el
correspondiente Criterio Elemental. Un Criterio Elemental es una función que
transforma valores obtenidos de una Variable de Preferencias, correspondiente
a números reales obtenidos a partir de la observación de la realidad, en valores
que pertenecen al intervalo [0,1]. El correspondiente valor en dicho intervalo es
lo que se denomina Preferencia Elemental, y representa el grado de
satisfacción de los requerimientos, donde: 0 (cero) indica que no satisface el
requerimiento, 1 (uno) que lo satisface plenamente, y los valores intermedios
expresan satisfacciones parciales. La elección apropiada de estos criterios es
fundamental a la hora de determinar el nivel de precisión y la usabilidad del
modelo de evaluación. Para definirlos, es necesario tener alguna experiencia
previa que permita determinar cuál es el rango de valores aceptables para las
Variables de Preferencias.
El proceso de descomposición de la estructura de requerimientos finaliza
cuando las variables de preferencias pueden ser evaluadas exitosamente por el
correspondiente criterio elemental. En consecuencia, la posibilidad de introducir
el criterio elemental se investiga en cada paso de la descomposición de dicha
estructura. Puesto que el criterio elemental se puede organizar de diversas
maneras, la elección del tipo más apropiado de cada criterio elemental es muy
importante ya que permite al evaluador alcanzar el nivel deseado de
completitud y exactitud del criterio complejo total. Existen diversos tipos de
criterios elementales en precisión, alcance y facilidad de uso. Por lo tanto, es
necesario introducir una clasificación detallada de los criterios elementales y
una descripción precisa de cada tipo particular de criterios [67]. Acorde a ello,
se pueden clasificar en dos clases básicas:
- Criterios absolutos: Estos criterios de evaluación son aquellos utilizados
para determinar la preferencia absoluta de un atributo y que no están
relacionados con indicadores de otros sistemas comparativos. Es decir,
se aplican cuando se evalúa solamente un sistema y determinan cómo
el sistema analizado se relaciona a los requerimientos y no cómo se
relaciona a otro/s sistema/s que compiten. Dentro de estos tipos de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 48
criterios las variables pueden ser divididas en continuas y discretas. De
esta manera, se dice que se pueden tener criterios absolutos con
variables continuas y criterios absolutos con variables discretas.
- Criterios relativos: Se utilizan cuando es necesario establecer
indicadores relativos en la comparación de distintos sistemas, y no se
pretende evaluar la calidad de cada sistema en forma individual o
independiente. Es decir, analizan (y comparan) las relaciones de
performance entre distintos sistemas en competencia. Estos criterios no
son aplicables en la evaluación de un único sistema, se debe tener al
menos dos sistemas que compitan. Ellos no representan el cumplimiento
de los requerimientos absolutos, sino que establecen una clasificación
relativa que no puede ser interpretada de manera individual.
4.2.2.1. Rango Nominal de las Variables de Preferencias
Considere la siguiente notación de punto de referencia general de un criterio
elemental para una variable de preferencia x:
Cr(x) = {(xmin, e1), …, (xmax, ek)}, donde 0 ≤ xmin < xmax k>1
Al intervalo denotado por Int(x) = [xmin, xmax], se lo denomina rango
nominal o intervalo de valores nominales de la variable de preferencias x. Los
valores de x correspondientes a todos los sistemas en competencia, se supone
que están dentro del rango nominal. Desde luego, algunos valores de x pueden
caer fuera de dicho rango. Sin embargo, si x > xmax, la correspondiente
preferencia elemental será la misma que para el x = xmax. De la misma manera,
x < xmin, mantiene la misma preferencia que x = xmin. En consecuencia,
cualquier valor de x fuera del rango nominal representa una especie de falta de
comprensión de los requerimientos del usuario.
El rango nominal de las variables de preferencias debe ser
cuidadosamente seleccionado. Su tamaño puede ser controlado utilizando un
indicador llamado coeficiente de variación de la variable de preferencia,
denotado por Var(x) y definido como:
Var��� = 100 ×�� � − ������ � + ���� �%�
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 49
Puesto que se asume que xmin > 0, se sigue que 0 < Var(x) ≤ 100%.
Donde Var (x) = 100% sólo si xmin = 0.
Si xmin > 0, valores grandes del coeficiente de variación pueden indicar un
criterio inapropiado que no es fácilmente justificable.
Suponga que los usuarios necesitan medir la performance de varios
sistemas de computadoras a través de la medición del tiempo gastado para la
ejecución de algunos lotes de cargas de trabajo dados. Sea T el tiempo
gastado expresado en minutos, y sea el correspondiente criterio elemental:
Cr(T) = {(10, 100), (90, 0)}
En este caso, Int(T) = [10, 90] y Var(T) = 80%.
Obviamente es muy difícil justificar el criterio anterior puesto que no se
puede explicar por qué el tiempo gastado de 10 minutos o menos es necesario
cuando el tiempo gastado de 1 hora, o aún 80 minutos, no es considerado
inaceptable. En consecuencia, el criterio:
Cr(T) = {(10, 100), (30, 0)}, Var(T) = 50%.
será más justificable en la mayoría de los casos prácticos.
Los criterios elementales con coeficientes de variación grandes pueden
causar una situación donde computadoras que difieren en el orden de
magnitud, entren dentro de la misma competencia. Este serio error debería ser
prevenido puesto que causa problemas en el uso de los criterios elementales
relativos, y un peligroso desequilibrio del lado financiero del proceso de
evaluación.
Para sugerir un conjunto razonable de valores para el coeficiente de
variación, considere el criterio para el tiempo gastado de un programa de
referencia Cr(T). La forma más frecuente para este criterio es:
Cr(T) = {(Tmin, 100), (Tmax, 0)}
Si se denota a Tmax como: Tmax = c Tmin, c > 1, entonces el coeficiente de
variación es:
Var��� = � − 1� + 1
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 50
Valores justificables para c pueden ser fácilmente sugeridos. Por ejemplo,
suponga que alguna computadora en competencia A procesa programas de
referencia en un tiempo Tmin y otra computadora B lo hace en un tiempo 2Tmin.
Generalmente esto sugiere que si la computadora A procesa los programas en
un único turno, la computadora B trabajará 2 turnos. Si la computadora B
procesa los programas de referencia en más de 3Tmin, esto significa que B no
puede procesar la carga de trabajo de un único turno de A, aún si trabajo 24
horas por día. En este caso se puede concluir que B no pertenece a la misma
clase de computadoras que A. Además, si las computadoras pertenecen a la
misma clase, ellas deberían satisfacer el criterio Cr(T) para el caso: 2 ≤ c ≤ 3,
33.3% ≤ Var(T) ≤ 50%.
Por lo tanto, en los casos donde xmin > 0, el criterio elemental será
generalmente fácilmente justificable si Var(x) > 50%. En el caso donde Var(x) >
50%, se sugiere proveer una prueba de que el criterio es apropiadamente
seleccionado y refleja realistamente los requerimientos.
4.2.2.2. Clasificación de los Tipos de Criterios Elementales
Como se describe en la sección anterior, los criterios elementales se clasifican
en absolutos y relativos. Además de esta clasificación, cada una de estas
categorías se puede dividir en sub categorías. En función de ello, la Tabla 4.1
presenta una clasificación de los criterios elementales subdividiendo las clases
básicas de criterios elementales absolutos y relativos [68].
Tabla 4.1. Clasificación de Tipos de Criterios Elementales
Criterios Elementales Absolutos
Relativos Continuos Discretos
Criterios de Variable Única
Criterios Binarios Criterios de Variable Única
Criterios de Variable Normalizada
Criterios Multi-Nivel Criterios de Variable Normalizada
Criterios Multi-Variable Criterios Multi-Nivel
definidos como Subconjunto
Criterios Estadísticos
Criterios de Preferencia Directa Criterios Multi-Variable
Criterios de Punto Aditivo
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 51
A continuación se presenta una descripción de cada uno de estos tipos de
criterios.
4.2.2.2.1. Criterios Absolutos Continuos de Variable Única
Son los tipos de criterios más comunes. En ellos se tiene una única variable X
continua. Como primer paso para determinar el criterio elemental, se debe
definir el rango de valores de interés para la evaluación de la variable. Luego,
se deben determinar las coordenadas de los puntos más relevantes y su
preferencia de calidad. Dichas preferencias, se utilizarán como base para
establecer la preferencia de calidad del resto del intervalo de valores.
Algunos ejemplos de aplicación de estos criterios pueden ser el tiempo
activo de un procesador, tiempo medio entre fallas, etc. A manera de ejemplo,
para comprender mejor su aplicación y definición, considere la variable de
preferencia:
X = Tiempo T de Procesamiento de un programa de referencia (Benchmark1).
Si la carga de trabajo es distribuida de manera tal que se espera que la
computadora en competencia más rápida ejecute el programa en 30 mili-
segundos y si el tiempo de procesamiento es crítico, se puede definir el rango
nominal de las variables de preferencias con un coeficiente de variación
relativamente pequeño (33.3 %), de la siguiente manera:
- Int(T) = [30, 60]
- Criterio elemental: Cr(T) = {(30, 100), (45, 80), (60, 0)}
Este criterio refleja el punto de vista de la evaluación que el tiempo de
procesamiento de 45 mili-segundos satisface el 80% de los requerimientos,
mientras que un tiempo superior a los 60 mili-segundos no satisface los
requerimientos. La Figura 4.2 muestra gráficamente el criterio propuesto.
1 Benchmark: Punto de referencia por el cual algunas cosas pueden ser medidas. Para el caso particular,
un programa de referencia es un programa cuyo tiempo de procesamiento puede ser tomado como medida de referencia en la comparación de otros programas.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 52
Figura 4.2. Criterio elemental para la variable de preferencia: Tiempo de Procesamiento de un programa de referencia
4.2.2.2.2. Criterios Absolutos Continuos de Variable
Normalizada
Estos criterios suelen ser utilizados para evaluar la relación entre dos
características absolutas individuales del mismo sistema. Es decir, con
frecuencia en lugar del conjunto de variables de preferencias: xabs = (x1, …, xi,
…, xj, …,xn), se hace necesario analizar el conjunto modificado xnorm = (x1, …,
zi, …, xj, …,xn); donde zi denota la variable de preferencia normalizada zi = xi/xj.
Dicha variable de preferencias normalizada es usada para evaluar la relación
entre dos características individuales del mismo sistema. Por ejemplo, si:
xi = tiempo activo del procesador central durante la evaluación comparativa.
xj = tiempo total transcurrido del programa de referencia (benchmark),
entonces:
zi = utilización del procesador central.
Además, si:
- TO = Tiempo transcurrido para el Ordenamiento de archivos
monoprogramados2, y
- TR = Tiempo total transcurrido del programa de Referencia (la carga de
trabajo de referencia no incluye el sistema de ordenamiento),
entonces:
- TON: Tiempo de Ordenamiento Normalizado se define como:
o TON = TO/TR
2 Monoprogramados: que son ejecutados en un sólo procesador
0% 30 45 60
80%
100%
T
Grado de Satisfacción
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 53
En este caso, si el objetivo es evaluar y comparar la eficiencia de varios
sistemas de ordenamiento que se ejecutan sobre varias computadoras,
entonces no se debería simplemente comparar los tiempos de ordenamiento
transcurridos de las computadoras en competencia. En realidad, TO1 < TO2, no
necesariamente significa que el sistema de ordenamiento Nº 1 sea mejor que el
sistema de ordenamiento Nº 2. La relación TO1 < TO2 puede simplemente
reflejar el hecho de que la computadora Nº 1 es más rápida que la
computadora Nº 2. Si se desea evaluar y comparar la calidad de programas de
ordenamiento, es necesario eliminar la influencia de la velocidad de la
computadora. Esto se puede lograr mediante la normalización. Si el tiempo
total transcurrido del programa de referencia (TR) representa un indicador
confiable de la velocidad de una computadora, entonces el tiempo de
ordenamiento normalizado TON, refleja solamente la calidad del sistema de
ordenamiento. En consecuencia, si TON1 < TON2, indica que el sistema de
ordenamiento Nº 1 es más eficiente que el sistema de ordenamiento Nº 2.
El evaluador puede usar una calibración promedio de la computadora y
ajustar el tiempo de ordenamiento transcurrido tal que: TO = TR (es decir, TON
= 1). El criterio elemental correspondiente para evaluar la eficiencia de un
sistema de ordenamiento, puede ser definido ahora como sigue:
Cr(TON) = {(0.5, 100), (1, 70), (1.5, 0)}
El sistema de ordenamiento promedio es clasificado en el 70% y los
sistemas por debajo del promedio son severamente penalizados. La Figura 4.3
muestra gráficamente el criterio propuesto.
Figura 4.3. Criterio elemental para la variable de preferencia: Tiempo de Procesamiento de un programa de referencia
0% 0. 1 1.
70%
100%
T
Grado de Satisfacción
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 54
4.2.2.2.3. Criterios Absolutos Continuos Multi-variables.
Estos criterios son aquellos que se definen como una función de otras variables
de preferencias y/o variables adicionales. Pueden relacionarse con el concepto
de métrica indirecta, su valor se calcula a partir de otras variables y constantes.
En consecuencia, los criterios de variable normalizada también pertenecen a la
clase de criterios multi-variables.
Por ejemplo, suponga que un fabricante de computadoras ofrece
capacitación en su centro de formación. Algunos de estos cursos son ofrecidos
a un usuario y otros no. Sin embargo, el usuario necesita evaluar el potencial
de entrenamiento total de dicho centro, incluyendo los cursos que no se le han
ofrecido. Se podría definir, entonces, la variable de preferencia TTE (Tiempo
Total de Entrenamiento) como:
TTE = TCO + TCN
Donde:
- TCO es la suma de los tiempos de entrenamiento de los cursos
ofrecidos al Usuario: TCO = T1 + … + TK, donde Ti es el tiempo de
entrenamiento para el curso i ofrecido.
- TCN es la suma de los tiempos de entrenamiento de los cursos no
ofrecidos al Usuario: TCN = T1 + … + Tm, donde Tj es el tiempo de
entrenamiento para el curso j no ofrecido.
El criterio correspondiente para el tiempo total de entrenamiento (TTE)
expresado en meses puede definirse como sigue:
Cr(TTE) = {(10, 0), (20, 70), (30, 100)}
Este criterio indica que si TTE toma un valor de 20 meses, el grado de
satisfacción es de un 70%, y es de un 100% si supera los 30 meses, mientras
que menos de 10 meses no satisface las necesidades del usuario. La Figura
4.4 muestra gráficamente el criterio propuesto.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 55
Figura 4.4. Criterio elemental para la variable de preferencia: Tiempo Total de Entrenamiento
4.2.2.2.4. Criterios Absolutos Continuos de Preferencia Directa
Estos criterios se basan en la experiencia de los evaluadores. Se los considera
como los peores de los criterios ya que son muy subjetivos, lo que puede llevar
a errores voluntarios o involuntarios. Sin embargo, pueden encontrarse
situaciones donde éstos sean los únicos criterios a aplicar, ya que sólo se
puede evaluar a partir del criterio de los evaluadores.
Es decir, estos criterios se aplican cuando no es posible definir una
variable de performance de tal manera que se pueda desarrollar la escala de
preferencia. Por ejemplo, la Calidad de la Documentación (CD) es una variable
de preferencia importante, pero no existe un método simple para la medición
objetiva de dicha variable, ya que depende en gran medida de la perspectiva
del usuario que la evalúa. Por lo tanto, la escala de preferencia no puede ser
desarrollada, simplemente porque el valor de la variable de preferencia no
puede ser medido objetivamente. En tales casos el evaluador se ve forzado a
abandonar la evaluación de la variable de preferencia no medible, o
directamente a evaluar subjetivamente la correspondiente preferencia
elemental. En este tipo de criterio, el procedimiento de evaluación es llamado
Evaluación de Preferencia Directa (EPD), y puede ser expresado como el
mapeo trivial:
Cr = {(0, 0), (100, 100)}
Como se mencionó, EPD representa el peor método de evaluación. La
principal desventaja es que ofrece una variedad de oportunidades de errores
de evaluación subjetiva, ya sean intencionales o no intencionales. Además, es
0%
10
20
30
70%
100%
T
Grado de Satisfacción
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 56
fácil mostrar que usualmente un criterio EPD puede substituirse por varios
criterios elementales no EPD más simples. Generalmente, cada variable de
preferencia no medible puede ser descompuesta y sus componentes medibles
pueden ser derivados. Después que la descomposición es llevada a cabo la
única EPD que puede restar es el criterio que explícitamente considera el juicio
subjetivo del evaluador (si este es necesario). Este tipo de EPD se denomina
EPD residual. Por ejemplo, la calidad de documentación puede ser
descompuesto en:
- Número de páginas (medible).
- Número de ilustraciones (medible).
- Número de ejemplos y ejercicios (medible).
- Calificaciones de usuarios publicadas (medible).
- Evaluación del evaluador de claridad, completitud, estilo, etc. (EPD
residual).
Este ejemplo ilustra que, aún si el EPD no es completamente eliminado,
se lo puede reducir al EPD residual. En algunos casos el EPD residual puede
ser omitido sin disminuir la calidad y completitud de la evaluación. Sin embargo,
su eliminación tiene el inconveniente obvio que incrementa el número de
criterios elementales y en consecuencia requiere un incremento del esfuerzo de
evaluación. Por lo tanto, el EPD puede ser usado en algunos casos como el
método para reducir el esfuerzo (y costo) de evaluación. Sin embargo, la
estrategia general debe mantener el EPD bajo control y usarlo tan poco como
sea posible con una suficiente justificación.
4.2.2.2.5. Criterios Absolutos Discretos Binarios
Dentro de los criterios discretos y absolutos, son los criterios más simples. La
variable asociada al criterio se mapea a los siguientes valores: (i) x = 0, que
indica la ausencia del atributo de calidad, y (ii) x = 1, indica la presencia o
disponibilidad del atributo.
Es decir, estos criterios son aplicados para evaluar variables de
preferencia binarias. Si x denota una variable de preferencia binaria el
correspondiente criterio binario es:
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 57
Cr(x)={(0,0), (1,100)}
Como se mencionó, el valor x = 0 es usado para codificar la ausencia de
alguna característica y el valor x = 1 denota la presencia de la característica.
Entre estos criterios, se pueden encontrar dos clases principales de
ejemplos: (i) criterios binarios técnicos, y (ii) criterios binarios de chequeo de
contratos. Los primeros, hacen referencia a situaciones donde el evaluador
necesita acreditar la disponibilidad de alguna característica importante del
sistema o algún producto de software importante. Ejemplos típicos de estos
criterios son la disponibilidad de un paquete de programación, servicio de
mantenimiento las 24 hs, lector óptico de caracteres, opción de tiempo
compartido de un sistema operativo, etc. Los segundos son usados para forzar
al fabricante a aceptar cláusulas de contrato provistas por el usuario (desde
luego, esto no es posible en todo los casos, pero en la mayoría de las
situaciones prácticas ayuda al usuario a obtener un mejor contrato). Por
ejemplo, el usuario podría desear incluir en su contrato las siguientes cláusulas:
- Una prueba de aceptación que verifique todos los resultados de las
medidas de preferencia que el fabricante envió después de catalogar
como un punto de referencia (benckmarking) el sistema propuesto.
- Una garantía de que los costos de mantenimiento no cambiarán en los
siguientes x años.
- Un reemplazo de un especialista de soporte poco habilidoso o un
capacitador incompetente en un curso.
- Un período de garantía del Sistema Operativo y/o Hardware.
- Una garantía de tiempo de entrega del Hardware/Software, etc.
Una vez definido el conjunto de cláusulas requeridas, el usuario especifica
los correspondientes criterios binarios. En ellos, el valor cero de una variable de
preferencia denota que el fabricante no acepta la cláusula y el valor uno denota
que está de acuerdo en incluir tal cláusula en el futuro contrato. En el proceso
de agregar varios criterios elementales, algunos criterios elementales de
chequeo de contrato pueden hacerse requerimientos mandatarios, y otros
pueden ser usados para proveer un incremento de preferencia adicional.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 58
4.2.2.2.6. Criterios Absolutos Discretos Multi-nivel
Estos criterios constituyen una generalización del criterio binario. La variable de
preferencia puede tomar varios valores discretos y cada valor es mapeado en
una preferencia correspondiente. Por ejemplo, si N denota el número de
unidades de disco propuesto, un criterio multinivel puede ser:
Cr(N)={(2,0), (6,100)}
Este criterio especifica que el usuario espera que se propongan 3, 4, 5 ó 6
unidades.
Con frecuencia, la variable de preferencia discreta es usada para codificar
algunas características de sistema. Por ejemplo, al analizar la complejidad de
un Modelo de Procesos de Negocio, se desea evaluar la carga de trabajo de
los actores (CTA). Se puede considerar que, de acuerdo a la realidad, el tener
un único actor sobre el que recae toda la carga de trabajo es muy malo y que el
número óptimo de actores es 4. Luego, se podría definir el criterio elemental
como sigue:
Cr(CTA) = {(1,0), (2,30), (3,80), (4, 100)}
4.2.2.2.7. Criterios Absolutos Discretos Multi-variable
Estos criterios permiten agrupar varias variables discretas y modelar el
resultado en una única variable x también discreta. Es decir, x puede definirse
como la composición de k variables discretas d1, …, dk, o sea que x se define
como una función de las variables anteriores (x = f(d1, …,dk) y x ∈ {x1,…, xn}).
Un criterio discreto multinivel para x podría ser:
Cr(x)={(x1, E1), …., (xn, En)}
Dicho criterio es denominado criterio absoluto discreto multivariable, y
permite la reducción del número de criterios elementales. Es decir, en lugar de
usar k criterios elementales para las variables iniciales d1,..., dk, se puede
aplicar un único criterio para la variable compuesta x.
Para demostrar la idea básica de cómo organizar las variables de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 59
preferencias discretas compuestas, considere el ejemplo de la Tabla 4.2. El
sistema analizado tiene tres características principales denotadas f1, f2 y f3.
Cada realización particular del sistema puede soportar alguna de las
combinaciones de las características en la Tabla 4.2, un 1 denota la presencia
de la característica analizada y un cero denota su ausencia.
Tabla 4.2. Ejemplo de un criterio absoluto discreto multivariable con variables binarias
f3 f2 f1 E(%) 0 0 0 E0 0 0 1 E1 0 1 0 E2 0 1 1 E3 1 0 0 E4 1 0 1 E5 1 1 0 E6 1 1 1 E7
En consecuencia, la tabla muestra las 8 combinaciones posibles. El
evaluador necesita asignar una preferencia a cada combinación. Estas
preferencias son denotadas por E0, E1,…, E7.
La preferencia de cualquier combinación puede ser determinada
analíticamente con facilidad como sigue:
E = (1-f3)(1-f2)(1-f1)E0 + (1-f3)(1-f2)f1E1 + (1-f3)f2(1-f1)E2
+ (1-f3)f2f1E3 + f3(1-f2)(1-f1)E4 + f3(1-f2)f1E5
+ f3f2(1-f1)E6 + f3f2f1E7
Por lo tanto, la fórmula anterior y la Tabla 4.2 representan notaciones
equivalentes del mismo criterio absoluto discreto multivariable. Similarmente se
podría aplicar a variables no binarias.
4.2.2.2.8. Criterios Absolutos Discretos de Punto Aditivo
Al desarrollar criterios elementales compuestos, basados en un número
relativamente pequeño de criterios elementales, puede ser apropiado utilizar
criterios absolutos multivariables basados en fórmulas de punto aditivo simples.
Suponga que se tiene una variable de preferencia compuesta x, la cual es una
función de las variables de preferencia c1, c2,…, ck; x = f(c1, c2,…, ck). Cada
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 60
constituyente puede ser individualmente calificada usando una regla de puntos
de asignación apropiada pi(ci), i=1,…,k. Entonces, la variable de preferencia
compuesta puede ser definida simplemente como la suma de los puntos:
� = �����������
Si los puntos son escalados de tal manera que se satisface que 0 ≤ x ≤ 100, el
correspondiente criterio elemental puede definirse como el mapeo trivial:
Cr(x) = {(0, 0), (100, 100)}
es decir, x puede ser interpretado directamente como una preferencia
elemental. En un caso general, x puede pertenecer a un rango arbitrario de
puntos y el criterio elemental puede ser:
Cr(x) = {( xmin, 0), (xmax, 100)}
donde, xmin y xmax definen el rango esperado de x. Es importante resaltar que
en estos casos las variables de preferencias constituyentes pueden tener
ventajas y desventajas, y en consecuencia, puede haber puntos pi(ci) positivos
y negativos.
Por ejemplo, considérese un criterio para evaluar computadoras de hogar
donde se espera que las mismas sean utilizadas en aplicaciones profesionales
personales de manera que se necesita una impresora serial. Suponiendo que
se espera que la impresora trabaje en aplicaciones donde la calidad y
versatilidad de impresión es más importante que la velocidad, es posible
organizar el criterio elemental de punto aditivo presentado en la Tabla 4.3.
Este criterio se basa en diez constituyentes. Los 7 primeros son usados
para generar puntos positivos, mientras que los tres restantes representan
desventajas (impresión sin impacto, alimentación por fricción y área de
impresión reducida) y en consecuencia son utilizados para generar puntos
negativos de penalización. En el caso más conveniente, se esperan puntos no
negativos y los valores máximos de los puntos mostrados en la Tabla 4.3
manteniendo el máximo puntaje de 60 puntos.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 61
Tabla 4.3. Ejemplo de Reglas de Clasificación de Impresoras Seriales V
alo
res
Máx
imo
s es
per
ado
s Pu
nto
s
5 10
20
5 5 5 10
0 0 0
Co
nst
itu
yen
te
50
5 - 1 1 1 1 0 0 0
Reg
las
de
Cla
sifi
caci
ón
de
Imp
reso
ras
Ser
iale
s
Pu
nto
s
c 1/1
0
2c2
c 3
5c4
5c5
5c6
10c 7
-10c
8
-10c
9
-10c
10
Des
crip
ció
n d
el C
on
stit
uye
nte
Vel
ocid
ad d
e Im
pres
ión
(Car
acte
res
por
segu
ndo)
Núm
ero
de D
ensi
dad
e Im
pres
ión
Cal
idad
de
Impr
esió
n (e
valu
ació
n de
pr
efer
enci
a di
rect
a en
el r
ango
0 ≤
c3
≤ 2
0)
Aut
o T
este
o (S
i est
á di
spon
ible
en
tonc
es c
4 =
1)
Car
acte
res
Ala
rgad
os (
crite
rio b
inar
io)
Car
acte
res
defin
idos
por
el u
suar
io
(crit
erio
bin
ario
)
Grá
fico
de r
esol
ució
n de
pun
tos
(crit
erio
bin
ario
)
Mét
odo
de Im
pres
ión
sin
impa
cto
(den
otad
o po
r c 8
= 1
, en
otro
cas
o,
para
impr
esió
n co
n im
pact
o c 8
= 0
)
Mec
anis
mo
de a
limen
taci
ón s
in
trac
ción
(c 9
= 1
den
ota
alim
enta
ción
co
n fr
icci
ón, y
c9
= 0
den
ota
alim
enta
ción
con
trac
ción
)
Áre
a de
Impr
esió
n m
enor
que
8
pulg
adas
(de
nota
do p
or c
10 =
1; e
n ot
ro c
aso,
c10
= 0
)
Co
nst
itu
yen
te
c 1
c 2
c 3
c 4
c 5
c 6
c 7
c 8
c 9
c 10
Nº 1 2 3 4 5 6 7 8 9 10
Por lo tanto, es razonable definir el siguiente criterio elemental para la
evaluación de impresoras seriales (IS):
Cr(IS) = {(0, 0), (60, 100)}.
Obviamente, el criterio descrito puede ser desarrollado como un criterio
complejo agregando los diez criterios elementales constituyentes. En ese caso,
el número total de criterios elementales podría incrementarse sustancialmente
y los puntos negativos podrían no ser utilizados. De esta manera, los criterios
elementales de punto aditivo hacen posible una evaluación detallada de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 62
muchos componentes aditivos de una variable de preferencia compleja. Dicha
evaluación es posible sin necesidad de incrementar el número de criterios
elementales y la complejidad de su estructura de agregación.
4.2.2.2.9. Criterios Elementales Relativos de Variable Única
Son los criterios elementales relativos más simples y frecuentemente usados.
Como se mencionó previamente, los criterios relativos son utilizados cuando se
deben comparar dos o más sistemas que compiten. Para cada sistema
analizado se mide un indicador de preferencia, y a partir de ellos se define una
variable relativa a dichos indicadores.
Por ejemplo, si p1, p2, …, pm son los indicadores de preferencia de m
sistemas analizados y comparados, y pmin = min (p1,…,pm) y pmax = max
(p1,…,pm) representan los valores mínimo y máximo respectivamente, se
pueden definir dos variables de preferencias relativas utilizando pmin y pmax:
r = p/pmax, r ≤ 1
R = p/pmin, R ≥ 1
Las formas más frecuentes de estos criterios son:
Cr (r) = {(rmin, 0), (1, 100)}, rmin < 1
Cr (R) = {(1, 100), (Rmax, 0)}, Rmax > 1
Por ejemplo, si p denota el tiempo transcurrido de un programa de
referencia, entonces usualmente se aplica Cr(R), y Rmax se selecciona de 2 ≤
Rmax ≤ 3. Si Rmax = 2, las computadoras que sean dos o más veces más lentas
que la mejor computadora en competencia, se considerarán inaceptables y
obtendrán la preferencia cero. Los valores Rmax = 2 y Rmax = 3 mantienen los
coeficientes de variación:
Var (R) = 33.3%, R = 2
Var (R) = 50%, R = 3
Los valores Rmax > 3 mantiene Var(R) > 50 % y raramente son usados.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 63
4.2.2.2.10. Criterios Elementales Relativos Normalizados
Estos criterios son los criterios relativos definidos para variables de
preferencias normalizadas (sección 4.2.2.2). Por ejemplo, sea el tiempo de
ordenamiento normalizado definido como sigue (ver ejemplo sección 4.2.2.2):
S = TO/TMONO
TO denota el tiempo de ordenamiento transcurrido y TMONO el tiempo
transcurrido de monoprogramación de referencia. La referencia de
monoprogramación no puede contener un sistema de ordenamiento, puesto
que varias computadoras tienen diferentes programas de ordenamiento y la
carga de trabajo debería ser variable. Si la carga de trabajo es constante,
TMONO representa un indicador de la capacidad del hardware de
computadora. El tiempo de ordenamiento normalizado S indica la calidad del
sistema de ordenamiento. Puesto que el valor S para varios sistemas
competidores no es conocido por adelantado, usualmente es conveniente
introducir la variable de preferencia normalizada relativa:
ES = S/SMIN, ES ≥ 1
SMIN denota el valor mínimo de S obtenido sobre el conjunto de computadoras
competidoras. El criterio elemental normalizado relativo para evaluar ES ahora
puede definirse como sigue:
Cr (ES) = {(1, 100), (3, 0)}
El ejemplo anterior ilustra dos propiedades esenciales de los criterios
normalizados relativos:
1) Permiten la comparación relativa de la performance de los sistemas en
competencia sin conocer por adelantado el rango de valores esperados
de los indicadores de preferencia.
2) Eliminan la influencia de varios niveles de preferencia. Por lo tanto, los
criterios normalizados relativos son especialmente adecuados para
comparar, por ejemplo, la eficiencia de varios sistemas de programación
que incluyen la mayoría de las utilidades y programas de aplicación.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 64
4.2.2.3. Criterios Elementales Discretos Estadísticos
Cuando se deben analizar y estudiar un conjunto grande de sistemas
competidores, se pueden utilizar los valores medios de las variables de
preferencias y, haciendo un análisis estadístico de ellos, calcular la distribución
de cada variable de preferencia.
Dada una variable de preferencia x, su distribución normal es
caracterizada por los valores: mínimo (xmin), máximo (xmax), promedio ( x ) y la
desviación estándar (σx) como sigue:
- xmin = min(x1, …, xm),
- x = (x1 + … + xm)/m,
- xmax = max(x1, …, xm),
- σx = ∑
=
−
−
m
i
ixx
m 1
2)(
1
1
,
donde x1, …, xm denota un ejemplo de m valores medidos.
El objetivo central de estos criterios es determinar la preferencia
elemental E de acuerdo a la posición del valor de la variable de preferencia x
dentro de la correspondiente distribución de valores. Un criterio elemental
estadístico, se puede obtener fácilmente en dos etapas:
(i) se define una variable de preferencia auxiliar escalada z como una
función de xmin, x , xmax y σx, y
(ii) se desarrolla el mapeo Cr(z).
Las funciones escalonadas más importantes (y los correspondientes
criterios elementales estadísticos) son3:
a) Normalización estadística:
- ( )x
xxz σ/−=
- Cr(z) = {(xmin, 0), (0, A), (xmax, 100)}
- -3 ≤ xmin ≤ -1; 40% ≤ A ≤ 80%; 1 ≤ xmax ≤ 3
3 Los valores de xmin , A y xmax son a manera de ejemplo. Los mismos dependerán
exclusivamente del caso particular que se esté evaluando
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 65
b) Normalización de rango nominal:
- z = (x – xmin)/( xmax – xmin), 0 ≤ z ≤ 1,
- Cr(z) = {(xmin, 0), (xmax, 100)}
- 0 ≤ xmin < xmax ≤ 1.
c) Normalización de valor promedio:
- ( ) xxxz /−=
- Cr(z) = {(xmin, 0), (xmax, 100)}
- -1 ≤ xmin ≤ 0, 0 ≤ xmax ≤ 1.
Todos los criterios anteriores son definidos asumiendo que si z1 > z2,
entonces la preferencia correspondiente a z1 debe ser más grande que la
preferencia correspondiente a z2. Desde luego, la situación opuesta también es
posible y el criterio elemental correspondiente puede ser obtenido fácilmente
simplemente intercambiando 0 y 100 en Cr(z).
La normalización estadística es adecuada para las distribuciones
similares a la distribución normal. La normalización de rango nominal es
conveniente para distribuciones similares a la distribución uniforme y que tienen
puntos extremos xmin y xmax no demasiado grandes, los cuales son aislados del
resto de la distribución. La normalización de valor promedio es conveniente
para grupos pequeños de sistemas competitivos y desviaciones de datos
relativamente pequeñas.
Como un ejemplo, considere el criterio para la comparación de varios
paquetes de programación lineal (PL). TPL denota el tiempo transcurrido para
procesar un programa de referencia PL. Si TPPL denota el valor promedio de
TPL para todos los sistemas en competencia, la eficiencia relativa del paquete
PL (NPL) puede definirse usando la normalización del valor promedio:
NPL = (TPL – TPPL) / TPPL
En este caso, los valores más pequeños de PL son preferidos respecto de
los valores más grandes. Si TPL = TPPL/2 denota el mejor resultado esperado,
y T(P) = 2*TPPL representa el límite de aceptabilidad, entonces el
correspondiente criterio elemental estadístico se puede definir como sigue:
Cr (NPL) = {(- 0.5, 100) (0, 60) (1, 0)}
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 66
En el ejemplo anterior se asume que todos los paquetes PL en
competencia son procesados usando la misma computadora. Si el problema es
comparar paquetes PL que se ejecutan sobre diferentes computadoras
entonces, en lugar de TPL, se puede aplicar la variable normalizada TPLN =
TPL/TMONO. De manera similar para la comparación de programas tipo,
TMONO representa el tiempo transcurrido de la referencia de
monoprogramación e indica la performance de hardware total de cada
computadora analizada.
Desde el punto de vista del análisis de modelos de procesos de negocio,
considere el análisis de la calidad de un modelo en cuanto a su entendiblidad
respecto del número de tareas. Si se considera que: (i) un modelo con pocas
tareas puede decir poco de la realidad que el modelo representa, (ii) un modelo
con demasiadas tareas se puede hacer difícil de interpretar. Por ello, se puede
decir que un criterio elemental para evaluar esta característica presenta una
distribución normal, por lo que se aplica una normalización estadística.
Entonces, un criterio elemental para la evaluación de esta variable, puede
definirse, en función de la distribución normal y de σx. Así, un criterio elemental
para la evaluación de esta variable, podría definirse como sigue:
�1 = �0���� = 01 √2# ∙ %&�'()*&+, -. ���� ≠ 0
Donde:
NT: es el número de tareas del modelo
µ: Media del número de tareas. Se considera que es el número de tareas ideal
σ: Desviación estándar del número de tareas.
Para el caso NT = 0, el valor de la función se mapea a 0 ya que NT = 0
representa un modelo de proceso sin actividades, lo que se considera como
erróneo, ya que un modelo vacío no dice nada acerca del proceso que
representa.
Una vez que se definen los criterios elementales, la siguiente fase del
método consiste en la definición de la estructura de agregación, la cual es
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 67
utilizada para obtener la evaluación global del sistema. La siguiente sección
describe en detalle dicha fase.
4.2.3. Definición de la Estructura de Agregación de los Criterios
Elementales para la Evaluación Global
A partir de los requerimientos y de los criterios elementales definidos en las
primeras fases del método, se debe establecer una estrategia para agregar
dichos criterios elementales. De esta manera se obtiene, a partir de los criterios
elementales, un criterio global que constituirá la preferencia global que indicará
el grado de satisfacción de los requerimientos del modelo estudiado. En [66,
67, 68] se puede encontrar más detalles acerca de la construcción de la
estructura de agregación.
Para lograr dicha preferencia global, se utiliza una técnica de agregación
gradual a través de la cual se obtiene la estructura de agregación que culmina
en dicha preferencia. Este proceso se basa en un sistema de operadores
lógicos de preferencia continuos sofisticados. Estos operadores, tienen gran
poder expresivo para modelar las relaciones lógicas más complejas que
reflejan exactamente todos los requisitos específicos del usuario.
De esta manera, la preferencia global se obtiene a partir de la
combinación de los criterios elementales en una estructura de agregación de
preferencias, la cual constituye un modelo que representa un criterio complejo:
la preferencia global E, la cual indica el porcentaje global del cumplimiento de
los requerimientos establecidos.
Esta preferencia global es obtenida de una función construida a partir de
las preferencias elementales denominada Función de Criterios. El valor
retornado por esta función indica el grado de satisfacción de los requerimientos
del sistema.
Como se mencionó previamente, la función de criterios se construye
combinando las Preferencias Elementales. Esto significa que un grupo de
Preferencias Elementales de entrada es reemplazado por una única
Preferencia Elemental que es la de salida. Dicha preferencia de salida indica el
grado de satisfacción que el evaluador asigna al grupo de Preferencias
Elementales de entrada.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 68
Para calibrar la Función de Criterios, es necesario tener en cuenta las
necesidades de los usuarios finales. El proceso de calibrado representa la fase
más compleja de la evaluación. La Preferencia Global E0, que se obtiene como
salida de la Función de Criterios, es el resultado de la combinación de las
Preferencias Elementales teniendo en cuenta la importancia relativa de cada
una y la necesaria relación lógica entre ellas. Esta relación lógica se logra a
través de la creación de la estructura de agregación lógica, que incluye los
pesos y operadores disponibles en la Lógica de Preferencias Continua. Esta
estructura se construye a partir de las variables de preferencia y su
combinación con las Funciones de Agregación.
El calibrado de la estructura de agregación se realiza teniendo en cuenta
las características de las funciones de agregación (Ver Tabla 4.4), en las
cuales la función C es el mínimo –Conjunción Pura– y la función D es el
máximo –Disyunción Pura–.
Tabla 4.4. Símbolos y parámetros de la función andor
cod Operación Símbolo D r2 r3 r4 r5 1 Disjunction D 1.00 1.7e+103 1.7e+103 1.7e+103 1.7e+103 2 Strong QD (+) D++ 0.9375 20.630 24.300 27.110 30.090 3 Strong QD D+ 0.8750 9.521 11.095 12.270 13.235 4 Strong QD (-) D+- 0.8125 5.802 6.675 7.316 7.819 5 Medium QD DA 0.7500 3.929 4.450 4.825 5.111 6 Weak QD (+) D-+ 0.6875 2.792 3.101 3.318 3.479 7 Weak QD D- 0.6250 2.018 2.187 2.302 2.384 8 Square Mean SQU 0.6232 2.000 2.00 2.00 2.00 9 Weak QD (-) D-- 0.5625 1.449 1.519 1.565 1.596
10 Arithmetic Mean A 0.5000 1.00 1.00 1.00 1.00 11 Weak QC (-) C-- 0.4375 0.619 0.573 0.546 0.526 12 Weak QC C- 0.3750 0.261 0.192 0.153 0.129 13 Geometric Mean GEO 0.3333 0.000 -0.067 -0.101 -0.121 14 Weak QC (+) C-+ 0.3125 -0.148 -0.208 -0.235 -0.251 15 Medium QC CA 0.2500 -0.720 -0.732 -0.721 -0.707 16 Harmonic Mean HAR 0.2274 -1.000 -1.000 -1.000 -1.000 17 Strong QC (-) C+- 0.1875 -1.655 -1.550 -1.455 -1.380 18 Strong QC C+ 0.1250 -3.510 -3.114 -2.823 -2.606 19 Strong QC (+) C++ 0.0625 -9.060 -7.639 -6.689 -6.013 20 Conjunction C 0.0000 5.0e-324 5.0e-324 5.0e-324 5.0e-324
El rango entre la conjunción pura y la disyunción pura puede ser cubierto
por una secuencia de operadores de la Lógica de Preferencias Continua
ubicados equidistantemente C, C++, C+, C+-, CA, C-+, C-, C--, A, D--, D-, D-+,
DA, D+-, D+, D++, D. Cada operador corresponde a un valor específico de un
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 69
parámetro r, el cual es usado para ajustar las propiedades lógicas deseadas de
las funciones. Es decir, r habilita la transición de la conjunción a la disyunción.
Esto significa que, a través de r, se logra el ajuste del grado de
conjunción/disyunción de las funciones lógicas.
Como resultado de la combinación de las distintas funciones de
agregación, de acuerdo a las preferencias del evaluador, se obtiene una
estructura de árbol a partir de la cual se calcula el indicador global.
Una vez realizado el calibrado de la estructura de agregación, cada
modelo de proceso puede ser evaluado. Dando como entrada al modelo el
conjunto de criterios elementales correspondientes a las Variables de
Preferencia X1, ..., Xn, se obtiene un indicador de Preferencia Global E0 para
cada sistema evaluado.
Cabe destacar que en la creación de la función de criterios es muy
importante la participación del usuario final. Este enfoque da el poder expresivo
final para un modelado preciso de las necesidades del usuario. Es decir, es el
usuario final quien define lo que desea o necesita evaluar.
4.2.4. Documentación, Análisis de Resultados y Conclusiones
Como se mencionó al principio de este capítulo, esta fase corresponde a la
etapa final del método. En ella se debe realizar un análisis y comparación de
los resultados obtenidos en la evaluación de los modelos respecto de las
preferencias elementales, tanto parciales como globales, obtenidas en la
aplicación del método. Además, se debe documentar el proceso de evaluación
y los resultados obtenidos. Dicha documentación debe servir como referencia e
historial de la evolución de los modelos de proceso de negocio estudiados en
futuras evaluaciones de los mismos. Esta documentación puede servir como
punto de referencia y comparación a la hora de evaluar nuevos modelos y
procesos de negocio.
Es decir, esta fase trata con actividades de análisis y comparación de las
preferencias de calidad elementales, parciales y globales, y la justificación de
los resultados obtenidos. A partir de las metas establecidas y el punto de vista
de los interesados en los modelos y procesos de negocio a evaluar, esta etapa
culmina con las conclusiones y recomendaciones del caso.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 70
La etapa de análisis y evaluación de los resultados es una de las
actividades más relevantes del método. Por ello, es de suma utilidad tener la
información recopilada durante la aplicación del método volcada en estructuras
y representaciones que sean claras de leer e interpretar. Desde este punto de
vista, las tablas y plantillas de informe, pueden ser empleadas eficientemente
en este tipo de actividades. Por lo expuesto, se propone, como parte de la
documentación necesaria en esta etapa, la creación de tablas que muestren los
resultados obtenidos en la evaluación de los modelos estudiados. La Tabla 4.5,
muestra un ejemplo parcial de una tabla para el listado de los resultados de la
evaluación de los modelos. Dicha tabla está construida en función de la
estructura de requerimientos básica propuesta en el método.
Tabla 4.5. Modelo de tabla para listar los resultados de la evaluación.
Variables de Preferencia Peso Modelo 1 Modelo 2 1. Tareas/Actividades
1.1. Simples/Atómicas 1.2. Compuestas/Subprocesos Evaluación de la Función Lógica de agregación para la característica 1.
2. Puntos de Sincronización del flujo de Ejecución 2.1. Puntos de Decisión 2.2. Puntos de Unión 2.3. Puntos de división en Ejecución Paralela y/o
Concurrente
Evaluación de la Función Lógica de agregación para la característica 2.
3. Eventos 3.1. Eventos de Inicio 3.2. Eventos Intermedios Evaluación de la Función Lógica de agregación para la característica 3.1 y 3.2.
3.3. Eventos Finales Evaluación de la Función Lógica de agregación para la característica 3.
Evaluación de la Función Lógica de agregación para la características 1, 2 y 3.
………………….
Evaluación de la Función Lógica de agregación para la estructura Global.
Cabe resaltar que los renglones correspondientes a las funciones lógicas,
variarán dependiendo de la estructura de agregación correspondiente a la
evaluación particular.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 71
Además de la tabla descripta en el párrafo anterior, también se debe
documentar el proceso de evaluación a través de un informe de los resultados
obtenidos. Dicho informe podría consistir de un documento que contenga un
formulario con el formato mostrado en la Figura 4.5.
Formulario de evaluación:
Nº de Referencia: Fecha y Hora:
Evaluador/es Dependencia Externo/ Interno
Eval 1 Eval 2 Eval 3 ……
Modelo/s de Procesos de Negocio Evaluado/s
Nº de Modelo Modelador Fecha Lenguaje Valoración Evaluación Anterior
Nº de Referencia
Fecha Valoración
Funciones de Criterio Aplicadas Definida (D) /
Repositorio (R) Definición ID. Repositorio ID. Función de Criterio
Análisis de los Resultados
Sugerencias de Mejora
Figura 4.5. Formulario de relevamiento de resultados
Observando el formulario de la Figura 4.5, en la primera parte del mismo
se introducen los datos de quiénes realizan la evaluación (evaluadores), la
fecha de la misma y un número de referencia que será utilizado para acceder a
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 72
la información registrada para cotejar estos datos con los obtenidos en futuras
evaluaciones.
La segunda parte, se refiere a los datos de los modelos analizados: un
número de identificación, quién lo desarrollo (especialista, área o
departamento, empresa de desarrollo, etc.), la fecha de creación, el lenguaje
en que se desarrolló el modelo y, si existiese, los datos de la última evaluación
realizada al modelo.En la tercera parte del formulario, se incluye información de
las funciones de criterio utilizadas en la evaluación. El campo Definida (D)
/Repositorio (R), se refiere a si la función es definida para la evaluación
específica (D) o si es tomada de un Repositorio de Funciones de Criterio (R),
para el caso de que se utilicen funciones previamente definidas para la
evaluación de otros casos de estudio o en evaluaciones previas del mismo
caso. La creación de estos repositorios, es de gran utilidad dada la complejidad
inherente de definir nuevos criterios. Además, se pueden utilizar funciones de
criterio, tomadas de repositorios externos o de la web previamente definidos y
aplicarlos a la realidad que se esté estudiando. En estos casos se debe indicar
la identificación del repositorio de donde se la tomó. De la misma manera, en el
caso de definir nuevas funciones de criterio, se debe especificar su definición y,
además, deberían ser almacenadas en algún repositorio para reutilizarlas en
futuras evaluaciones.
Finalmente, se incluye en el formulario: una sección para registrar el
análisis de los resultados y las conclusiones acerca de los mismos y una
sección para registrar posibles recomendaciones y sugerencias respecto de
posibles acciones a seguir a partir de los resultados obtenidos en la evaluación
de los modelos analizados.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 73
CAPÍTULO 5. Casos de Estudio
5.1. Introducción
Uno de los aspectos primordiales de todo método de evaluación es mostrar que
el mismo es de utilidad práctica. Para alcanzar este objetivo, en [72] se
presenta una clasificación de tres propuestas de trabajo: (i) Experimentación,
(ii) Casos de estudio, (iii) Encuestas. A continuación se de una breve
descripción de cada una de ellas.
(i) Experimentos: Un experimento es un examen formal, riguroso y
controlado en el que los factores clave son identificados y manipulados. En
este sentido, los experimentos se utilizan cuando se tiene el control de la
situación y se pretende controlar su comportamiento directa, precisa y
sistemáticamente [48].
(ii) Casos de Estudio: Los casos de estudio se utilizan para monitorizar
proyectos, actividades o asignaciones. Los datos son recogidos para un
propósito específico del estudio. El caso de estudio está orientado
normalmente a analizar un determinado atributo o establecer relaciones
entre diferentes atributos [73].
La forma de saber si desarrollar un caso de estudio o un experimento,
dependerá del conocimiento que se tenga de las variables. En este sentido
los experimentos son más apropiados si se tiene un mayor grado de
conocimiento sobre las variables, mientras que si, por el contrario, se tiene
un bajo control sobre dichas variables podría ser más adecuada la
aplicación de un caso de estudio.
(iii) Encuestas: Una encuesta es, a menudo, un método de investigación que
se realiza de forma retrospectiva, cuando por ejemplo, una herramienta o
técnica ha estado usándose durante un período de tiempo [74]. Las
principales formas de recolectar los datos cualitativos o cuantitativos son
las entrevistas y los cuestionarios.
Las encuestas no proporcionan control sobre la aplicación del método y
aunque es posible comparar dicha aplicación a otras parecidas, no es
posible manipular las variables. Las encuestas tienen la habilidad de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 74
proporcionar una gran cantidad de variables a evaluar, pero es necesario
que el objetivo esté en obtener la mayor información posible de la menor
cantidad de variables, ya que la reducción simplifica la tarea del análisis
[48].
Para la validación práctica del método, y siguiendo la clasificación
propuesta en [72], se usaron dos casos de estudio. La decisión de utilizar
casos de estudio para la validación del método se debió a que, al evaluar
modelos de procesos de negocio, en general no se tiene un control absoluto de
las variables a evaluar. Esto se debe a que, en la mayoría de los casos, dichas
variables dependen de la realidad particular que se está estudiando. Por este
motivo se consideró más adecuada la aplicación de casos de estudio que la
realización de experimentos, en los que es necesario tener un mayor control de
las variables intervinientes, o el desarrollo de encuestas, para las cuales se
debería contar con un cierto historial de aplicación del método, y la opinión de
quienes lo utilizaron. En función de lo expresado, los casos de estudio
mencionados son:
(a) La evaluación de los modelos de proceso de negocio de una empresa del
medio, la cual pretende posicionarse satisfactoriamente con competitividad
en el mercado.
(b) La evaluación de metodologías ágiles de desarrollo de software. A la hora
de llevar a cabo un proyecto software, muchas veces es necesario decidir
qué metodología se adecúa más a las necesidades del proyecto. Por ello,
se decidió aplicar el método en la evaluación de las metodologías ágiles de
desarrollo de software, dada la amplia difusión que ellas tienen en la
actualidad.
5.2. Caso de Estudio 1: Evaluación de los Modelos de Procesos
de Negocio de una Empresa del Medio
Con el objetivo de obtener una primera valoración práctica del método, se
lo aplicó en la evaluación de los modelos de procesos de una empresa del
medio, la cual pretendía mejorar su posición en el mercado en el que compite.
Para lograr el objetivo, como primer paso en el análisis de la realidad de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 75
la empresa, además de determinar los procesos en juego, era necesario
conocer el enfoque empresarial de la misma. Por ello, se realizó un análisis de
los distintos enfoques de trabajo de las empresas para determinar en cuál de
ellos se encuadraba. Así, en la siguiente sección se presenta una clasificación
de los mencionados enfoques. Luego, se describe el proceso de aplicación del
método al caso de estudio y, finalmente, los resultados obtenidos.
5.2.1. Enfoques de Trabajo de las Empresas
Hoy en día las empresas sólo pueden sobrevivir si compiten con éxito en el
mercado interno y logran posicionarse en el mercado externo. Por esta razón,
en la última década las empresas de todo el mundo, a los fines de mantener su
nivel de competitividad debieron realizar importantes cambios y/o
incorporaciones en sus organizaciones y recursos. Esto se debe a que no
pueden permitir, por ejemplo, que los salarios y los costos de las materias
primas superen el del resto del mundo, ni prescindir de las nuevas tecnologías,
los nuevos materiales, equipos y formas de organización. En este sentido, para
alcanzar un determinado nivel de intercambio con un público objetivo
determinado, existen diversos enfoques bajo los cuales las empresas pueden
desarrollar sus actividades [75]:
1- El enfoque en la producción: Sostiene que los consumidores
favorecerán aquellos productos que estén siempre disponibles y sean de
bajo costo. Los directores de organizaciones con enfoque en la
producción concentran sus esfuerzos en alcanzar economías de escalas y
amplia distribución.
2- El enfoque en el producto: Sostiene que los consumidores favorecerán
aquellos productos que ofrezcan la mejor calidad o los mejores resultados.
Los directivos de las empresas con enfoque en el producto concentrarán
sus esfuerzos en hacer buenos productos y mejorarlos a lo largo del
tiempo.
3- El enfoque en las ventas: Establece que si a los consumidores no se les
estimula, no comprarán suficientes productos de la empresa. Por lo tanto,
la organización debe llevar a cabo políticas agresivas de venta y
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 76
promoción.
4- El enfoque en el marketing: Sostiene que la clave para alcanzar los
objetivos de la organización consiste en: (i) identificar las necesidades y
deseos del público destinatario; y (ii) entregar los resultados deseados de
una forma más efectiva y eficiente que la competencia.
5- El enfoque en el marketing social: Supone que la tarea de la
organización es identificar las necesidades, deseos e intereses de su
público destinatario. Proveer estas características de manera más efectiva
que la competencia y de forma que preserven o realcen el bienestar a
largo plazo de los consumidores y de la sociedad.
Es importante destacar que, en cualquiera de las tipologías anteriores, en
la actualidad resulta una herramienta de suma importancia la utilización de las
nuevas tecnologías. En este sentido es fundamental para la empresa realizar
inversiones que permitan la adquisición de este tipo de tecnologías. Estas
inversiones no resultan suficientes, eficaces y eficientes si sólo están dirigidas
a la compra de la última tecnología ofrecida en el mercado. Es decir, no
alcanza con la actualización de la maquinaría existente dentro de una empresa.
Además, las empresas deben enfocarse en la implementación de nuevas
estrategias de negocio que permitan alcanzar sus objetivos. Dichas estrategias
pueden ser clasificadas de acuerdo a las siguientes opciones:
a) Innovación: estrategias que enfatizan la introducción de nuevos servicios
y/o productos.
b) Minimización de costos: estrategias que enfatizan el uso de estrictos
controles de costos, evitan los gastos innecesarios de innovación o
mercadotecnia y el recorte de precios.
c) Limitación: estrategia que busca moverse hacia nuevos productos o
mercados sólo cuando se haya demostrado su viabilidad.
En este contexto, en el desarrollo de la estrategia elegida por las
empresas, lo que diferencia a las tecnologías aplicadas es su grado de rutina.
De esta manera, las tecnologías tienden hacia actividades rutinarias y no
rutinarias. Las primeras se caracterizan por su automatización y
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 77
estandarización. Mientras que las actividades no rutinarias son las
condicionadas por las demandas de los clientes.
Las tareas rutinarias están ligadas con estructuras más altas y
departamentalizadas. La rutina está asociada con la presencia de manuales de
operación, descripciones de puestos y otros documentos formalizados.
Mientras que las tecnologías no rutinarias se centran en el conocimiento de los
especialistas y en la delegación de tareas.
En base a la clasificación presentada previamente, el marco del presente
caso de estudio es una empresa del medio, dedicada a la fabricación e
impresión de etiquetas autoadhesivas, como por ejemplo Obleas de
vencimiento de Energas, para vehículos a Gas Natural, que pretende
posicionarse satisfactoriamente con competitividad en el mercado. El enfoque
elegido de dicha empresa es el de producción y la estrategia utilizada por su
nivel gerencial es la minimización de costos con tecnología rutinaria. U
5.2.2. El Caso de Estudio: Descripción del Problema
En el relevamiento realizado con la gerencia de la empresa se detectó que la
problemática de la misma radicaba principalmente en lo que se denomina
Parada de Planta. Dicho problema se debía a la falta de stock de materia prima
y a una comunicación y coordinación deficiente entre los distintos sectores de
la empresa. Así, una vez situados en la empresa, la gerencia refiere que su
“Logística Empresarial”4 está seriamente comprometida. Siendo sus
dificultades más sensibles las siguientes:
a) Interrupción del Ciclo de Pedido5, necesidad de tiempo extraordinario para
conseguir stock en la fábrica. Aquí, la falta de coordinación entre los
sectores involucrados en el modelo organizacional, originaban dos serios
inconvenientes: (i) la alteración del ciclo normal de pedido, por cuanto la
4 Conjunto de actividades y técnicas relacionadas con el flujo físico de materiales. Abarca el suministro
de materias primas, la producción, el almacenamiento, el transporte a almacenes regionales y el reparto a los clientes del producto, [75] B. P. Benegochea, J. A. de Diego, J. C. Adrián, M. Navasquillo, M. A. Melero, and G. de Miguel, Dirección de Marketing y Ventas vol. III: Edit. Cultural de Ediciones S.A, 1999. 5 Tiempo que transcurre entre la emisión de un pedido (orden de compra) y la recepción de la mercancía
solicitada. El tiempo total del ciclo se reparte entre las actividades de: Transmisión del pedido, Procesamiento del pedido, Preparación del pedido, Disponibilidad de stock, Producción y Entrega.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 78
escasez de materia prima disponible para la elaboración del producto
paralizaba la planta; (ii) en los intentos de paliar la primera situación, la
excesiva compra de materia prima originaba erogaciones importantes por
demás innecesarias.
b) Insuficiente coordinación de tareas entre los Departamentos constitutivos de
la Empresa.
c) Deficiente comunicación entre los responsables de los distintos
Departamentos de la empresa que participan en los procesos estudiados.
En el marco del trabajo, se contó con algunos modelos especificados en
BPMN del proceso de negocio de la organización que la misma poseía. Debido
a que uno de los problemas que más le preocupaban a la gerencia estaba
relacionado al proceso de Compras y Pagos de la organización, se tomó el
modelo de dicho proceso, Figura 5.1. Sobre dicho modelo se realizó un análisis
del mismo con el fin de determinar si el proceso que modelaba se adecuaba a
las necesidades de la empresa.
La prioridad de la gerencia era encontrar la solución a la Interrupción del
Ciclo de Pedido, bajo la premisa de proporcionar el mejor producto al mínimo
costo y en el menor tiempo. Acorde a ello, se desarrolló un nuevo Diagrama de
Proceso de Negocio modelado en BPMN, en el cual se propusieron posibles
modificaciones en el proceso respecto de los problemas planteados.
Para la confección de estos diagramas, se tomó la información relevante
que la Gerencia de la empresa brindó. A partir de dicha información se detectó
que, según el modelo de negocio, uno de los problemas era que, al haber un
faltante o escasez de materia prima en la línea de producción, se realizaba un
pedido al almacén de depósito. Sólo en ese instante el encargado del almacén
hacía un control de stock de la materia prima solicitada. Esto causaba que, si
no había material disponible, se hacía recién en ese instante la compra
correspondiente. Dicha forma de trabajar generaba una pérdida de tiempo
importante, ya que si en la línea de producción se agotaba el material, se
producía una parada de planta hasta que el proceso de compra y entrega del
material finalizara. En función de estos problemas, se arribó a los modelos de
las Figuras 5.2 a 5.5.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 79
Figura 5.1. Modelo del Proceso Compras y Pagos de la Empresa
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 80
Figura 5.2. Modelo del Proceso Compras y Pagos Propuesto
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 81
Figura 5.3. Subproceso Realizar Control Físico
Figura 5.4. Subproceso Elegir Proveedor
Figura 5.5. Subproceso Pagar Documento
Una vez que se tuvieron los modelos, se procedió a aplicar el método
para el análisis de los mismos con la finalidad de establecer la claridad y
entendibilidad de los mismos. En este sentido, en la siguiente sección se
muestran los resultados de la aplicación del método a los modelos analizados.
5.2.3. La Aplicación del Método en la Evaluación de los
Modelos Propuestos
Una vez que se obtuvieron los modelos y se estableció la problemática a
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 82
analizar, se aplicó el método para determinar si dichos modelos satisfacían los
criterios de calidad básicos que todo modelo conceptual de proceso de negocio
debe poseer, [76]. En este sentido, se utilizó la estructura de categorización de
requerimientos elementales para la evaluación de Modelos de Procesos de
Negocio propuesta en el método (Capítulo 4).
Cabe destacar, que la aplicación del método en este caso de estudio se
realizó sobre modelos desarrollados en BPMN. Dicha notación se ha
establecido como un estándar en la actualidad en cuanto al modelado de
procesos de negocio. Por ello se considera que la misma provee los elementos
para representar la gran mayoría de las situaciones a modelar de la realidad.
En el Anexo 1 se presenta una descripción detallada de los distintos elementos
provistos por BPMN para modelar los procesos de negocio.
5.2.3.1. Fase 1: Definición de la Estructura de Categorización de
Requerimientos para la Evaluación de los Modelos de
Procesos de Negocio de la Empresa en Estudio
Como lo establece el método, en la primera fase se definen y analizan los
requerimientos a evaluar. En este sentido, se tomó y aplicó la estructura de
categorización de requerimientos básica propuesta en el método, ya que lo que
se pretendía era evaluar si los modelos comparados satisfacían los
requerimientos de calidad para modelos de procesos de negocio. La Figura
5.6., muestra la estructura de categorización de requerimientos utilizada en la
evaluación de los modelos en el presente caso de estudio.
Al analizar los modelos, se puede observar que en ellos no se
representan los recursos y su distribución entre los participantes del proceso.
Esto se debe a que en el problema planteado por la gerencia de la empresa, no
se consideró necesario incluir un análisis de los recursos utilizados en el
proceso. Esta situación llevó a analizar la posibilidad de eliminar el ítem 5.
Recursos (como el método lo plantea, la estructura es totalmente flexible y se
debe adaptar a las necesidades del caso particular bajo estudio). Sin embargo,
dicha característica se mantuvo ya que se considera que la correcta
representación de los recursos utilizados, y su distribución, es muy importante
a la hora de comprender el proceso que el modelo representa, por lo tanto, ello
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 83
hace a la calidad del mismo.
1. Tareas/Actividades
1.1. Simples/Atómicas
1.2. Compuestas/Subprocesos
2. Puntos de Sincronización del flujo de Ejecución
2.1. Puntos de Decisiones
2.2. Puntos de Uniones
2.3. Puntos de división en Ejecución Paralela y/o Concurrente
3. Eventos
3.1. Eventos de Inicio
3.2. Eventos Intermedios
3.3. Eventos Finales
4. Participantes / Actores
4.1. Internos
4.1.1. Número de Participantes/Actores
4.1.2. Comunicación entre Participantes/Actores
4.2. Externos
4.2.1. Número de Participantes/Actores
5. Recursos
5.1. Producidos en el Proceso / Generados (Internos)
5.2. Externos
Figura 5.6. Estructura de Categorización de Requerimientos utilizada en la evaluación de los modelos estudiados.
5.2.3.2. Fase 2: Definición de los Criterios Elementales de
Evaluación
Una vez establecidos los requerimientos, y siguiendo con las fases del método,
se establecieron los criterios elementales asociados a cada una de las
variables de preferencia obtenidas en la estructura de requerimientos. De esta
manera, se obtuvieron las preferencias elementales de los correspondientes
requerimientos elementales obtenidos en la estructura de requerimientos.
Como se mencionó previamente, apartado 4.2.2 del Capítulo 4, los
criterios elementales son funciones que mapean los valores de las variables de
preferencia al intervalo [0,1]. Donde los valores de dichas variables, son
obtenidos de la observación de la realidad. Desde este punto de vista, uno de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 84
los mecanismos ampliamente difundido para medir y evaluar la calidad, es el
uso de métricas de calidad. Por ello, para la definición de los criterios
elementales se propone el uso de métricas, para la medición de modelos de
procesos de negocio, encontradas en la literatura. Dichas métricas han sido
probadas y validadas por los autores. Por ejemplo, Rolon, et al en [77]
proponen un conjunto de métricas para modelos conceptuales de procesos de
negocio representados con BPMN. Estás métricas están basadas en el marco
FMESP (por su sigla en inglés de Framework for the Modeling and Evaluation
of Software Processes) para la medición de procesos software [48]. Para la
definición de estas métricas, los autores se basaron en los distintos
constructores que provee BPMN para la construcción de los modelos. En el
Anexo 2, se presenta una descripción de las métricas propuestas en [77].
A continuación se presenta una propuesta para los criterios elementales
correspondientes a las variables de preferencia de la estructura de
requerimientos utilizada en la evaluación de los modelos.
Preferencia Global: 1. Tareas /Actividades Variable de Preferencia: 1.1. Tareas Simples/Atómicas Criterio elemental:
Donde:
- TNT(m): Indica el número total de tareas simples en el modelo de
proceso m.
- TNCS(m): Indica el número total de subprocesos colapsados (tareas
compuestas) en el modelo de proceso m.
Criterio elemental C1.1(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto de las tareas simples. El primer
tramo de la función que define al criterio elemental, se refiere a un modelo
vacío. Esta situación no dice nada acerca del proceso que representa el
modelo, por ello se considera que el criterio vale 0. El segundo tramo del
criterio, se refiere a la situación en la que todas las tareas son subprocesos
compuestos (TNT = 0 y TNCS ≠ 0). Esta situación, aporta información acerca
del proceso general, mas no acerca de la estructura de los subprocesos
0 si TNT(m) = 0 ^ TNCS(m) = 0
C1.1(m) = 1/TNCS(m) si TNT(m) = 0 ^ TNCS(m) ≠ 0
1/TNT(m) si TNT(m) ≠ 0
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 85
componentes. En el tercer tramo, se considera que a mayor cantidad de tareas,
más complejo el modelo y, por ende, más difícil de entender y adaptar a
nuevas modificaciones.
Variable de Preferencia: 1.2. Tareas Compuestas/Subprocesos Criterio elemental:
Donde:
- TNT(m): Indica el número total de tareas simples en el modelo de
proceso m.
- TNCS(m): Indica el número total de subprocesos colapsados (tareas
compuestas) en el modelo de proceso m.
Criterio elemental C1.2(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto del número de subprocesos
representados por tareas. El primer tramo de la función que define al criterio
elemental, se refiere a un modelo vacío. Esta situación no dice nada acerca del
proceso que representa el modelo, por ello se considera que el criterio vale 0.
El segundo tramo del criterio, se refiere a la situación en la que todas las tareas
son elementales (TNCS = 0 y TNT ≠ 0). Bajo el criterio analizado, se considera
que si el modelo no posee subprocesos la complejidad en cuanto a su
entendibilidad dependerá del número de tareas simples en el modelo, por ello
se lo define como 1/TNT(m). En el tercer tramo, se considera que a mayor
cantidad de tareas complejas/subprocesos, más complejo el modelo y, por
ende, más difícil de entender y adaptar a nuevas modificaciones, ya que se
deberán analizar dichas tareas en más detalle para poder comprender mejor el
modelo completo y el proceso que representa.
Preferencia Global: 2. Puntos de Sincronización del flujo de Ejecución Variable de Preferencia: 2.1. Decisiones Criterio elemental:
Donde TNGD (m): Indica el número total de nodos de decisión en el modelo de
0 si TNCS(m) = 0 ^ TNT(m) = 0
C1.2(m) = 1/ TNT(m) si TNCS(m) = 0 ^ TNT(m) ≠ 0
1/ TNCS(m) si TNCS(m) ≠ 0
1 si TNGD(m) = 0 C2.1(m) =
1/ TNGD(m) si TNGD(m) ≠ 0
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 86
proceso m. Esta métrica es una adaptación de la métrica TNG propuesta en
[77].
Criterio elemental C2.1(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto del número de nodos de decisión
del modelo. Mientras más puntos de decisión, más complejo de entender y
adaptar será el modelo. Se considera que si TNGD = 0 el criterio devuelve 1,
ya que el modelo no posee nodos de decisión.
Variable de Preferencia: 2.2. Uniones Criterio elemental:
Donde TNGU (m): Indica el número total de nodos de unión de flujos en el
modelo de proceso m. Esta métrica es una adaptación de la métrica TNG
propuesta en [77].
Criterio elemental C2.2(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto del número de nodos de unión del
modelo. Mientras más puntos de unión, más complejo de entender y adaptar
será el modelo. Se considera que si TNGU = 0 el criterio devuelve 1, ya que el
modelo no posee nodos de unión.
Variable de Preferencia: 2.3. Puntos de División en Ejecución Paralela Criterio elemental:
Donde NPF (m): Indica el número total de puntos en que el flujo de ejecución
se divide en flujos de ejecución paralelos en el modelo de proceso m.
Criterio elemental C2.3(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto del número de puntos de división
del flujo de ejecución en flujos de ejecución paralelos. Cuanto mayor sea la
cantidad de flujos de ejecución paralelos, más complejo de entender y adaptar
será el modelo. Si el modelo no posee flujos de ejecución paralelos (NPF = 0),
el criterio devuelve 1. Esto se debe a que la presencia de muchos flujos de
ejecución paralelos, puede influir en la claridad del modelo.
1 si TNGU(m) = 0 C2.2(m) =
1/TNGU(m) si TNGU(m) ≠ 0
1 si NPF(m) = 0 C2.3(m) =
1/NPF(m) si NPF(m) ≠ 0
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 87
Preferencia Global: 3. Eventos Variable de Preferencia: 3.1. Eventos de Inicio Criterio elemental:
Donde TNSE(m): Indica el número total de Eventos de Inicio en el modelo de
proceso m.
Criterio elemental C3.1(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto al número de eventos de inicio, ya
que a mayor cantidad de eventos, más complejo de entender será el modelo.
Se considera que si el modelo no posee eventos de inicio (TNSE(m) = 0) el
criterio devuelve 0 ya que no queda claro dónde comienza la secuencia de
ejecución de las actividades del proceso modelado.
Variable de Preferencia: 3.2. Eventos Intermedios Criterio elemental:
Donde TNIE(m): Indica el número total de eventos intermedios que ocurren
durante el proceso modelado en m.
Criterio elemental C3.2(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto al número de eventos
intermedios, ya que a mayor cantidad de eventos, más complejo de entender
será el modelo. Se considera que si el modelo no posee eventos intermedios
(TNIE(m) = 0) el criterio devuelve 1. La ausencia de estos eventos reduce la
complejidad del modelo, ya que no se deben analizar las causas y
consecuencias que ellos pueden generar en el flujo de ejecución del proceso
modelado.
Variable de Preferencia: 3.3. Eventos Finales Criterio elemental:
0 si TNSE(m) = 0 C3.1(m) =
1/TNSE(m) si TNSE(m) ≠ 0
1 si TNIE(m) = 0 C3.2(m) =
1/TNIE(m) si TNIE(m) ≠ 0
0 si TNEE(m) = 0 C3.1(m) =
1/TNEE(m) si TNEE(m) ≠ 0
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 88
Donde TNEE (m): Indica el número total de Eventos Finales en el modelo de
proceso m.
Criterio elemental C3.3(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto al número de eventos finales, ya
que a mayor cantidad de eventos, más complejo de entender será el modelo.
Se considera que si el modelo no posee eventos finales (TNEE(m) = 0) el
criterio devuelve 0 ya que puede no quedar claro donde finaliza la secuencia de
ejecución de las actividades del proceso modelado.
Preferencia Global: 4. Participantes/Actores Variable de Preferencia: 4.1.1. Número de Participantes/Actores (Internos) Criterio elemental:
Donde NPI (m): Indica el número total de participantes/actores internos en el
modelo de proceso m. Esta métrica es una adaptación de la métrica NP
propuesta en [77].
Criterio elemental C4.1.1(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto al número de
participantes/actores internos del proceso. A mayor cantidad de
participantes/actores, más complejo de entender será el modelo. Sin embargo,
se considera que si el modelo no posee participantes/actores (NPI(m) = 0) el
criterio devuelve 0 ya que esto podría interpretarse como que no se sabe quién
realiza las tareas del proceso modelado, lo que hace a la entendibilidad del
proceso modelado.
Variable de Preferencia: 4.1.2. Comunicación entre Participantes/Actores Criterio elemental:
Donde NMFI (m): Indica el número total de mensajes entre los
participantes/actores internos en el modelo de proceso m. Esta métrica es una
adaptación de la métrica NMF propuesta en [77].
Criterio elemental C4.1.2(m): Establece la complejidad del modelo en cuanto a
0 si NPI(m) = 0 C4.1.1(m) =
1/NPI(m) si NPI(m) ≠ 0
0 si NMFI(m) = 0 C4.1.2(m) =
1/NMFI(m) si NMFI(m) ≠ 0
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 89
su entendibilidad y su adaptabilidad respecto al número de mensajes entre los
participantes/actores del proceso. A mayor cantidad de mensajes entre
participantes/actores, más complejo de entender será el modelo. No obstante,
si el modelo no representa los mensajes entre los participantes/actores
(NMFI(m) = 0) el criterio devuelve 0 ya que esto podría interpretarse como que
no existe comunicación entre los distintos participantes del proceso. Esta
característica es de mucha importancia y por consiguiente se debe poder
determinar desde un modelo del proceso.
Variable de Preferencia: 4.2.1. Número de Participantes/Actores (Externos) Criterio elemental:
Donde NPE (m): Indica el número total de participantes/actores externos en el
modelo de proceso m.
Criterio elemental C4.2.1(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto al número de
participantes/actores externos del proceso. Se considera que si el modelo no
posee participantes/actores externos (NPE(m) = 0) el criterio devuelve 1, ya
que a mayor cantidad de participantes/actores externos, más complejo de
entender será el modelo.
Preferencia Global: 5. Recursos Variable de Preferencia: 5.1. Producidos en el Proceso / Generados (Internos) Criterio elemental:
Donde NRI (m): Indica el número total de recursos internos en el modelo de
proceso m. Esta métrica es una adaptación de la métrica NDOIn propuesta en
[77].
Criterio elemental C5.1(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto al número de recursos internos.
Se considera que si el modelo no posee recursos (NRI(m) = 0) el criterio
devuelve 0, ya que es importante modelar los recursos y su distribución entre
1 si NPE(m) = 0 C4.2.1(m) =
1/NPE(m) si NPE(m) ≠ 0
0 si NRI(m) = 0 C5.1(m) =
1/NRI(m) si NRI(m) ≠ 0
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 90
los distintos participantes del proceso. Sin embargo, a mayor cantidad de
recursos, el modelo será más complejo de comprender. Esto se debe a que
será necesario interpretar quién produce o utiliza mayor cantidad de recursos.
Por ello, si NRI(m) ≠ 0 se define el criterio como su inversa. De esta manera a
mayor cantidad de recursos en el modelo, más cercano a cero resultará el
Criterio.
Variable de Preferencia: 5.2. Externos Criterio elemental:
Donde NRE (m): Indica el número total de recursos externos en el modelo de
proceso m. Esta métrica es una adaptación de la métrica NDOIn propuesta en
[77].
Criterio elemental C5.2(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto al número de recursos externos
utilizados en el proceso. Se considera que si el modelo no posee recursos
externos (NRE(m) = 0) el criterio devuelve 0, ya que, al igual que con los
recursos internos, es de suma importancia modelar los recursos externos y su
distribución entre los distintos participantes del proceso. Igualmente, a mayor
cantidad de recursos externos en el modelo más complejo de comprender será
el mismo, al tener que interpretarse quién utiliza cada recurso.
Cabe destacar que los criterios propuestos no son estáticos y se
definieron en función de la realidad a evaluar. Esto quiere decir que pueden ser
modificados o cambiados en función de las necesidades de la realidad
analizada al momento de aplicar el método.
Una vez definidos los criterios, se aplicaron los mismos a los modelos a
evaluar. Acorde a ello, la Tabla 5.1, muestra el detalle de los valores obtenidos
al aplicar los criterios elementales propuestos a dichos modelos.
0 si NRE(m) = 0 C5.2(m) =
1/NRE(m) si NRE(m) ≠ 0
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 91
Tabla 5.1. Aplicación de los Criterios Elementales a los modelos evaluados
Criterio Elemental Valor del Criterio
Modelo 1 (m1) (Figura 5.2)
Modelo 2 (m2) (Figura 5.1)
1. Tareas/Actividades 1.1. Simples/Atómicas
TNT(m1) = 24 TNT(m2) = 44
C1.1(m1) = 0,042 C1.2(m2) = 0,022
1.2. Compuestas/Subprocesos
TNCS(m1) = 3 TNCS(m2) = 0
C1.2(m1) = 0,33 C1.2(m2) = 0,022
2. Puntos de Sincronización del flujo de Ejecución
2.1. Puntos de Decisión
TNGD(m1) = 5 TNGD(m2) = 9
C2.1(m1) = 0,2 C2.1(m2) = 0,11
2.2. Puntos de Unión
TNGU(m1) = 4 TNGD(m2) = 9
C2.2(m1) = 0,25 C2.2(m2) = 0,11
2.3. Puntos de división en Ejecución Paralela y/o Concurrente
NPF(m1) = 1 NPF(m2) = 1
C2.3(m1) = 1 C2.3(m2) = 1
3. Eventos 3.1. Eventos de Inicio
TNSE(m1) = 2 TNSE(m2) = 1
C3.1(m1) = 0,5 C3.1(m2) = 1
3.2. Eventos Intermedios
TNIE(m1) = 0 TNIE(m2) = 0
C3.2(m1) = 1 C3.2(m2) = 1
3.3. Eventos Finales
TNEE(m1) = 7 TNEE(m2) = 5
C3.3(m1) = 0,14 C3.3(m2) = 0,2
0 si TNT(m) = 0 ^ TNCS(m) = 0
C1.1(m) = 1/TNCS(m) si TNT(m) = 0 ^ TNCS(m) ≠ 0
1/TNT(m) si TNT(m) ≠ 0
0 si TNCS(m) = 0 ^ TNT(m) = 0
C1.2(m) = 1/ TNT(m) si TNCS(m) = 0 ^ TNT(m) ≠ 0
1/ TNCS(m) si TNCS(m) ≠ 0
1 si TNGD(m) = 0 C2.1(m) =
1/ TNGD(m) si TNGD(m) ≠ 0
1 si TNGU(m) = 0 C2.2(m) =
1/ TNGU(m) si TNGU(m) ≠ 0
1 si NPF(m) = 0 C2.3(m) =
1/ NPF(m) si NPF(m) ≠ 0
0 si TNSE(m) = 0 C3.1(m) =
1/ TNSE(m) si TNSE(m) ≠ 0
1 si TNIE(m) = 0 C3.2(m) =
1/ TNIE(m) si TNIE(m) ≠ 0
0 si TNEE(m) = 0 C3.3(m) =
1/ TNEE(m) si TNEE(m) ≠ 0
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 92
4. Participantes / Actores 4.1. Internos
4.1.1. Número de Participantes/Actores
NPI(m1) = 5 NPI(m2) = 5
C4.1.1(m1) = 0,2 C4.1.1(m2) = 0,2
4.1.2. Comunicación entre Participantes/Actores
NMFI(m1) = 5 NMFI(m2) = 5
C4.1.2(m1) = 0,2 C4.1.2(m2) = 0,2
4.2. Externos
4.2.1. Número de Participantes/Actores
NPE(m1) = 1 NPE(m2) = 1
C4.2.1(m1) = 1 C4.2.1(m2) = 1
5. Recursos 5.1. Producidos en el Proceso / Generados (Internos)
NRI(m1) = 0 NRI(m2) = 0
C5.1(m1) = 0 C5.1(m2) = 0
5.2. Externos
NRE(m1) = 0 NRE(m2) = 0
C5.2(m1) = 0 C5.2(m2) = 0
Una vez definidos los criterios elementales, y a partir de las variables de
preferencia de la estructura de requerimientos, se definió la estructura de
agregación para la evaluación de los modelos, acorde a lo establecido en el
método. Dicha estructura se explica en la siguiente sección.
5.2.3.3. Fase 3: Definición de la Estructura de Agregación para
la Evaluación Global
Según lo establece el método, la estructura de agregación es la estructura que
permite obtener la evaluación global de los sistemas analizados. De esta
manera, una vez definidos los criterios elementales, se procedió a construir
esta estructura. Para su obtención, se tuvieron en cuenta, no sólo las
propiedades generales que los modelos de proceso deben poder representar y
su importancia dentro del modelo analizado, sino también, algunas
características propias de los requisitos de la empresa. Por ejemplo, en cuanto
0 si NPI(m) = 0 C4.1.1(m) =
1/ NPI(m) si NPI(m) ≠ 0
0 si NMFI(m) = 0 C4.1.1(m) =
1/ NMFI(m) si NMFI(m) ≠ 0
1 si NPE(m) = 0 C4.2.1(m) =
1/ NPE(m) si NPE(m) ≠ 0
0 si NRI(m) = 0 C5.1(m) =
1/ NRI(m) si NRI(m) ≠ 0
0 si NRE(m) = 0 C5.2(m) =
1/ NRE(m) si NRE(m) ≠
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 93
a la importancia de la representación de los recursos, se le asignó un peso
menor respecto de las otras características, ya que a la empresa no le
interesaba, en esta etapa, la influencia de los recursos y su distribución. Bajo
estas consideraciones, se arribó a la estructura de agregación de la Figura 5.7.
Figura 5.7. Estructura de Agregación
Según lo establece el método, para la construcción de la estructura de
agregación se debe realizar una asociación de las variables de preferencias
mediante las funciones de agregación lógicas. Esta agregación debe hacerse
vinculando aquellas variables que estén más relacionadas entre sí, de manera
de ir obteniendo resultados parciales para la evaluación de las características
más generales establecidas en la estructura de requerimientos. Como se
describe en el método (Capítulo 4), las funciones de agregación lógica vinculan
las variables a través de operadores andor, cuya evaluación va desde la
Disyunción Pura (D) a la Conjunción Pura (C), en tanto que los valores
intermedios (D++ a C++) representan evaluaciones donde la ausencia de un
valor es compensado por la presencia de otro/s, siendo dicha compensación
mayor mientras más cerca esté el operador de la disyunción pura y menor
mientras más cerca de la conjunción pura esté.
De esta manera, en el primer nivel de agregación, se relacionaron entre sí
las variables correspondientes a las preferencias elementales de cada
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 94
categoría más general en la estructura de requerimientos. En cuanto a los
operadores lógicos, fueron seleccionados en función del grado de relevancia de
cada preferencia elemental. Dicha relevancia es medida respecto a si se
considera que es un requisito que siempre debe estar presente o si es un
requisito deseable pero que su ausencia no debe incidir demasiado en la
valoración del modelo. De esta manera, en el caso de las preferencias
elementales 1.1 y 1.2, ambas son de importancia a la hora de evaluar la
claridad y entendibilidad de los modelos. Sin embargo, la ausencia de tareas
simples puede indicar que el modelo representa una visión de más alto nivel
del proceso donde cada tarea en él representa un subproceso, por lo tanto no
debería incidir en la valoración del mismo. En cuanto a la ausencia de tareas
complejas (subprocesos), indica que el modelo está representando el proceso
al más bajo nivel, por lo que tampoco se debería desestimar en su valoración al
mismo. Por ello, se utilizó en la unión de estas variables el operador D-+. En
cuanto al peso asignado, debido a que se está evaluando la entendibilidad de
los modelos, se consideró de mayor importancia las tareas simples, porque
ellas indican el nivel más bajo de descomposición por lo que en el modelo se
encuentra toda la información pertinente acerca del proceso y no es necesario
analizar otros modelos que representen a los subprocesos.
De la misma manera se analizó el resto de las preferencias elementales y
se las agrupó en función de su relación y se seleccionaron los operadores
lógicos siguiendo el mismo tipo de análisis descrito en el parágrafo anterior.
En cuanto al resto de los niveles de agregación, se procedió de la misma
manera agrupando los requerimientos generales más relacionados entre si. De
esta manera, observando la Figura 5.7, se puede ver que las características 1,
2 y 3 de la estructura de requerimientos, se agregaron en un operador C-, esto
se debe a que son características que hacen a la determinación de las tareas a
realizar y del flujo en que ellas se ejecutan. Se seleccionó un operador
conjuntivo, debido a que se consideró que estos elementos son muy
importantes a la hora de analizar y entender el proceso que el modelo
representa, por lo que ayudarán también a la hora de entender mejor el
modelo. En el siguiente nivel de agregación se agregó la característica 4, que
indica quiénes realizan las tareas. Saber quiénes están a cargo de las tareas
es de suma importancia, por ello se considera que el modelo de un proceso de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 95
negocio debe reflejarlo claramente. Por este motivo, también se utilizó una
función conjuntiva en su agregación con la rama correspondiente a la
valoración del flujo de tareas. Finalmente, en la agregación de la característica
5 (recursos), debido a que el interés de la gerencia de la empresa no se
centraba en los recursos, se utilizó una función disyuntiva para la agregación
de esta característica. Además, se le asignó un peso notoriamente mayor a las
características relacionadas a las tareas y participantes del proceso que a la
característica recursos.
Como se puede observar, la construcción de la estructura de agregación
es fuertemente dependiente de la realidad que se está analizando. Por
ejemplo, si ahora se quisiera hacer más hincapié en la distribución de los
recursos, la estructura debería ser modificada de manera que se dé más peso
a esta característica y, probablemente, se la debería considerar como una
característica necesaria, es decir, se debería utilizar una función disyuntiva.
En las siguientes subsecciones se describen los resultados de la
aplicación del método al caso de estudio planteado.
5.2.3.4. Fase 4: Documentación, Análisis de los Resultados y
Conclusiones
Siguiendo con los pasos establecidos en el método, la etapa final del mismo
corresponde al análisis y comparación de los resultados obtenidos en la
evaluación de los modelos respecto de las preferencias elementales, tanto
parciales como globales, obtenidas en la aplicación del método. Además, se
debe realizar una documentación de los resultados obtenidos. Dicha
documentación servirá como referencia e historial de la evolución de los
modelos de proceso de negocio estudiados en futuras modificaciones y
actualizaciones de los mismos. Además, esta documentación puede servir
como punto de referencia y comparación a la hora de evaluar nuevos modelos
y procesos de negocio.
En cuanto a la evaluación de los modelos, según la estructura de
agregación y los criterios elementales propuestos, la misma se realizó
mediante una herramienta que permite realizar dicha evaluación de forma
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 96
automática, [78]. A partir de dicha herramienta se obtuvieron los resultados
mostrados en la Tabla 5.2.
Tabla 5.2. Resultados de la aplicación del método a los modelos (Ref-1).
Variables de Preferencia Peso Modelo 1 Modelo 2 1. Tareas/Actividades
1.1. Simples/Atómicas 0,6 0,042 0,022 1.2. Compuestas/Subprocesos 0,4 0,33 0,022
D-+ 0,35 0,24023376 0,022 2. Puntos de Sincronización del flujo de Ejecución
2.1. Puntos de Decisión 0,5 0,2 0,11 2.2. Puntos de Unión 0,5 0,25 0,11
C- 0,5 0,22397029 0,111 2.3. Puntos de división en Ejecución Paralela y/o
Concurrente 0,5 1 1
D-+ 0,35 0,78442014 0,78075887 3. Eventos
3.1. Eventos de Inicio 0,6 0,5 1 3.2. Eventos Intermedios 0,4 1 1
C- 0,7 0,66986598 1 3.3. Eventos Finales 0,3 0,14 0,25
D-+ 0,3 0,59067393 0,88288258 C- 0,5 0,48817677 0,30247469
4. Participantes / Actores 4.1. Internos
4.1.1. Número de Participantes/Actores 0,6 0,2 0,2 4.1.2. Comunicación entre
Participantes/Actores 0,4 0,2 0,2
C- 0,6 0,2 0,2 4.2. Externos
4.2.1. Número de Participantes/Actores 1 1 D+- 0,5 0,85393179 0,85393179 C- 0,7 0,65226859 0,52634624
5. Recursos 5.1. Producidos en el Proceso/Generados (Internos) 0,5 0 0 5.2. Externos 0,5 0 0 C- 0,3 0 0
D-+ 0,57404485 0,46322383
En función de los datos mostrados en la Tabla 5.2, obtenidos de la
aplicación de la estructura de preferencias de la Figura 5.1, en la cual se
aplicaron los criterios listados en la Tabla 5.1, se completó el formulario
propuesto en el método como parte de la documentación a realizar en el
proceso de evaluación. En este sentido, la Figura 5.2, muestra el formulario
propuesto con los datos asignados. En este formulario se encuentra
información acerca de los modelos evaluados, las funciones de criterio
utilizadas en la evaluación, y el análisis de los resultados obtenidos.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 97
Formulario de evaluación: Modelos de PN Empresa Autoadhesivos
Nº de Referencia: 1 Fecha: 22/10/2012
EVALUADORE/S Áreas o Dpto o Comisión Externo/ Interno
Eval 1 UNSL UNSL Externo
Eval 2 Carlos Salgado UNSL Externo
Modelo/s de Procesos de Negocio Evaluado/s
Nº de Modelo Desarrollador Fecha Lenguaje Evaluación Anterior
Fecha Nº de
Referencia
1 Carlos Salgado 08/10/2012 BPMN - -
2 Empresa Propietaria - BPMN - -
Funciones de Criterio Aplicadas
Definida (D) / Repositorio (R)
Criterio Elemental ID. Repositorio ID. Función de
Criterio
D Tareas/Actividades Simples/Atómicas
RFC-1 1
D Tareas/Actividades
Compuestas/Subprocesos RFC-1 2
D Puntos de Sincronización: Puntos
de Decisión RFC-1 3
D Puntos de Sincronización: Puntos
de Unión RFC-1 4
D
Puntos de Sincronización: Puntos de División en Ejecución Paralela
y/o Concurrente RFC-1 5
D Eventos de Inicio RFC-1 6
D Eventos Intermedios RFC-1 7
D Eventos Final RFC-1 8
D Participantes/Actores: Internos:
Número de Participantes RFC-1 9
D Participantes/Actores: Internos:
Comunicación entre Participantes RFC-1 10
D Participantes/Actores:
Externos: Número de Participantes RFC-1 11
D Recursos: Producidos en el
Proceso (Internos) RFC-1 12
D Recursos: Externos RFC-1 13
Análisis de los Resultados
De la observación de la Tabla Ref-1, se puede ver que ambos modelos resultan favorecidos en algunas características y en otras no. Así, el nuevo modelo desarrollado en función de las especificaciones de la gerencia (Modelo 1) resultó favorecido en las características 1, 2 y 4, mientras que el que la empresa poseía previamente (Modelo 2) resultó favorecido en las características 3, mientras que en las restantes características ambos modelos resultaron iguales. Sin embargo, el Modelo 1 resultó favorecido respecto del Modelo 2 en la evaluación global. Esto no se debe a que fue favorecido en una mayor cantidad de características, sino que lo fue en aquellas características más relevantes y de mayor peso.
Acorde a las consideraciones establecidas en la presente evaluación, este resultado indica que el Modelo 1 satisface en mayor medida los criterios de calidad de los modelos conceptuales de procesos de negocio en cuanto a la entendibilidad y adaptabilidad de los mismos.
Figura 5.8. Formulario de Documentación de la Evaluación
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 98
5.2.3.4.1. Beneficios para la Empresa
De la aplicación del método, en el análisis de los modelos, se detectó que
el nuevo modelo propuesto se adaptaba más a los estándares de calidad de los
modelos conceptuales. A partir de este análisis, la gerencia de la empresa
tomó los nuevos modelos y se los cotejó contra los procesos reales de la
organización De dicha observación, se detectó que los mismos no se
adecuaban a los nuevos modelos, los cuales fueron desarrollados en función
de las especificaciones de requerimientos realizados por la gerencia, sin tener
contacto previo con el modelo del proceso con que ya contaba la empresa.
Este trabajo llevó a la gerencia a detectar que, si bien el proceso se adaptaba a
su modelo, el modelo no se adecuaba a la realidad de sus requerimientos de
negocio. Por lo tanto, se debía hacer una reestructuración en la puesta en
ejecución del proceso de compras y pagos de la empresa.
Cabe destacar que este caso de estudio, sirvió para mostrar que la
aplicabilidad del método va más allá del análisis de modelos de PN en cuanto a
su entendibilidad y adaptabilidad. En este caso de estudio, la aplicación del
método sirvió para detectar inconsistencias en cuanto a los requerimientos del
PN y la implementación del mismo. Es decir, permitió detectar áreas del
proceso de negocio que necesitaban ser reestructuradas. Lo que es de gran
utilidad para una organización, ya que le permite adecuar sus procesos a las
necesidades reales de su negocio.
Actualmente la empresa se encuentra planificando su reestructuración,
definiendo los nuevos requerimientos e implementando los cambios para
adaptar el proceso a los nuevos modelos.
Como continuación del trabajo, se está planificando la aplicación del
método en otras áreas de la organización, como el proceso de ventas y
cobranzas.
5.3. Caso de estudio 2: Aplicando MEMPN en la comparación
de Metodologías Ágiles de Desarrollo de Software
Muchas veces, ante un proyecto de desarrollo de software surge la necesidad
de decidir qué medios utilizar para obtener un mejor producto. En función de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 99
ello, y ante la necesidad de determinar en qué situaciones es conveniente o
beneficioso utilizar una metodología ágil en el desarrollo de software, se decidió
utilizar MEMPN en la evaluación de tres de las más difundidas de estas
metodologías, [79]: OpenUp [80], eXtreme Programming (XP) [81] y Scrum
[82].
Para lograr el objetivo buscado, se siguieron los pasos establecidos en el
método propuesto a lo largo del proceso de evaluación. Cabe destacar que,
dado que el método fue desarrollado para la evaluación de modelos
conceptuales de PN, para llevar a cabo la evaluación de las metodologías
estudiadas, se tomaron los metamodelos de desarrollo de cada una de ellas.
Como paso siguiente, se aplicó el método a dichos metamodelos y se
determinó cuál se adecuó más a los requerimientos establecidos.
En las siguientes secciones se describe la manera en que las fases del
método de evaluación propuesto fueron aplicadas en el presente caso de
estudio.
5.3.1. Fase 1: Definición de la Estructura de Categorización de
Requerimientos para el Análisis de las Metodologías
Ágiles Estudiadas
Como se mencionó en la descripción del método (Capítulo 4), esta etapa se
refiere al proceso de determinación de los requerimientos que los modelos a
evaluar deberían satisfacer. Dichos criterios son categorizados en una
estructura de árbol: la estructura de categorización de requerimientos, cuyas
hojas representan los requerimientos elementales a evaluar, que son las
características medibles a través de algún medio. Como se mostró en la
Sección 4.2.1., el método propone una estructura de categorización básica
desde la cual se puede partir para obtener la estructura adecuada a la situación
particular. El análisis de los requerimientos se basó en la estructura básica
propuesta, y partiendo de las características y atributos a evaluar, se arribó a la
estructura de categorización de requerimientos que se muestra en la Figura.
5.9.
Para la obtención de esta estructura, el análisis comparativo de las
metodologías se realizó en base a tres características: 1) las distintas
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 100
actividades/subprocesos de las metodologías, 2) la colaboración entre los
miembros del equipo y 3) características más específicas de la propia
metodología como son los recursos. Por ello, la estructura propuesta en el
método fue redefinida restringiéndola a estas tres características.
1. Tareas/Actividades 1.1. Simples/Atómicas 1.2. Compuestas/Subprocesos
2. Participantes / Actores / Roles 2.1. Internos
2.1.1. Número de Participantes/Actores/Roles 2.1.2. Comunicación entre
Participantes/Actores/Roles 2.2. Externos
2.2.1. Número de Participantes/Actores 3. Recursos
3.1. Producidos en el Proceso / Generados (Internos) 3.2. Externos
Figura 5.9. Estructura de categorización de requerimientos del sistema a ser aplicada a la evaluación de Metodologías Ágiles
Así, se incluye la característica 1. Tareas. Básicamente, existen dos tipos
de tareas: (i) Las tareas simples, es decir tareas que son consideradas
atómicas y no son divididas en subtareas; (ii) tareas compuestas, es decir
tareas que, debido a su complejidad deberían se divididas en varias tareas
(simples o compuestas).
La característica 2, se refiere a los actores que participan en el proceso
de desarrollo. Los mismos pueden ser: (a) internos, por lo que se considera el
tamaño del equipo y además la interrelación entre ellos, ya que esto puede
influenciar fuertemente en la complejidad del proceso; y (b) externos, es decir
los actores que actúan como colaboradores en el proceso pero que no forman
parte del equipo de desarrollo.
Finalmente, la característica 3 se refiere a los recursos necesarios para
llevar a cabo el proyecto. Como se puede ver en la estructura de categorización
de requerimientos, también se consideran los recursos internos (o producidos
en el proceso) y externos. Los recursos internos, pueden influir en la
complejidad del proceso en el sentido de que pueden generar demoras en las
tareas que los necesiten si ellos no son entregados a tiempo. De la misma
manera, los recursos externos pueden introducir inconvenientes si ellos no
están disponibles.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 101
5.3.2. Fase 2: Definición de los Criterios Elementales de
Evaluación
El segundo paso del método establece que se deben definir los criterios
elementales para cada una de las características elementales resultantes en la
estructura de categorización de requerimientos definida en el paso anterior.
Como se mencionó en la Sección 4.2.2, existen distintos tipos de criterios
elementales, que se utilizan dependiendo de las características y tipos de
sistemas a evaluar. Dentro de dichos tipos, para la definición de los criterios
propuestos en este trabajo, se utilizó un criterio elemental estadístico para la
evaluación de las variables de performance de la característica Tareas /
Actividades. El objetivo central de estos criterios es determinar la preferencia
elemental E de acuerdo a la posición del valor de la variable de preferencia x
dentro de la correspondiente distribución de valores. Bajo estas
consideraciones, a continuación se detallan los criterios elementales
propuestos.
Preferencia Global: 1. Tareas /Actividades Variable de Preferencia: 1.1. Tareas Simples/Atómicas Criterio elemental:
����0� = � 0����� = 01 √2# ∙ %&�'(*)*&+, -. ����� ≠ 0
Donde:
- TNT: es el número de tareas simples del modelo. - µ: Media del número de tareas simples. Se considera que es el número
de tareas ideal. - σ: Desviación estándar del número de tareas simples.
Criterio elemental C1.1(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto de las tareas simples. Desde el
punto de vista del análisis de modelos de procesos de negocio, considerando el
análisis de la calidad de un modelo en cuanto a su entendiblidad respecto del
número de tareas, se puede decir que: (1) un modelo con pocas tareas puede
decir poco de la realidad que el modelo representa, (2) un modelo con
demasiadas tareas podría ser difícil de interpretar. Por esta razón, se puede
decir que un criterio elemental para evaluar esta característica presenta una
distribución normal, por lo que se aplica una normalización estadística.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 102
Entonces, un criterio elemental para la evaluación de esta variable, puede
definirse, en función de la distribución normal. El primer tramo de la función que
define al criterio elemental, se refiere a un modelo sin actividades elementales,
por ello se considera que el criterio vale 0, ya que esta característica se anula.
Variable de Preferencia: 1.2. Tareas Compuestas/Subprocesos Criterio elemental:
����0� = �0�����1 = 01 √2# ∙ %&�'(*)23&+, -. �����1 ≠ 0
Donde: - TNCS: es el número total de subprocesos colapsados (tareas
compuestas) del modelo. - µ: Media del número de tareas compuestas. Se considera que es el
número de tareas ideal. - σ: Desviación estándar del número de tareas compuestas.
Criterio elemental C1.2(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto de las tareas compuestas. En
este caso se realiza un análisis similar al criterio C11. Por esta razón, se puede
decir que un criterio elemental para evaluar esta característica presenta
también una distribución normal, por lo que se aplica una normalización
estadística y se define en función de la distribución normal. El primer tramo de
la función que define al criterio elemental, se refiere a un modelo sin
actividades compuestas, por ello se considera que el criterio vale 0, ya que esta
característica se anula.
Preferencia Global: 2. Participantes/Actores/Roles Variable de Preferencia: 2.1.1. Número de Participantes/Actores/Roles (Internos) Criterio elemental:
Donde NPI (m): Indica el número total de participantes/actores internos en el
modelo de proceso m. Esta métrica es una adaptación de la métrica NP
propuesta en [77].
Criterio elemental C2.1.1(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto del número de
0 si NPI(m) = 0 C2.1.1(m) =
1/NPI(m) si NPI(m) ≠ 0
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 103
participantes/actores/roles internos del modelo. En este criterio, a mayor
cantidad de participantes/actores/roles, menor será su valor. Esto significa que
mientras más participantes/actores/roles, más complejo la metodología
evaluada y por ende recibe una calificación menor. NPI = 0, indica que no hay
participantes/actores/roles, lo que indica que no se sabe quién realizará cada
tarea, lo que hace a la entendibilidad del proceso, por ello el criterio toma el
valor 0.
Variable de Preferencia: 2.1.2. Comunicación entre los Participantes/Actores/Roles (Internos) Criterio elemental:
Donde GAP indica el grado de colaboración entre los participantes.
Criterio elemental C2.1.2(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto de la comunicación entre
participantes/actores/roles internos del modelo. La comunicación entre los
participantes es fundamental, ya que este tipo de metodologías le da gran
importancia a los aspectos humanos más que al entorno de trabajo, acorde a lo
que pide el manifiesto de las metodologías ágiles6. En función de ello, en [83],
se presenta una comparación de distintas metodologías ágiles relativa a ciertos
parámetros, como excelencia técnica, simplicidad, etc. y también califica las
metodologías en función de la colaboración entre los miembros del equipo. De
esta manera, para la evaluación del criterio elemental asociado a la variable de
preferencia 2.1.2., se utilizó la calificación presentada en [83]. Para la definición
de este criterio se considera que mientras más grande sea el grado de
comunicación, será más exitoso el proyecto. Por ello el criterio tomará un valor
más elevado mientras más alto sea el valor de GAP.
Variable de Preferencia: 2.2.1. Número de Participantes/Actores (Externos) Criterio elemental:
6 http://agilemanifesto.org/
0 si GAP(m) = 0 C2.1.2(m) =
1 - 1/GAP(m) si GAP(m) ≠ 0
0 si NPE(m) = 0 C2.2.1(m) =
1/NPE(m) si NPE(m) ≠ 0
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 104
Donde NPE (m) es el número de Participantes/Actores/Roles externos del
modelo analizado.
Criterio elemental C2.2.1(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto al número de
participantes/actores/roles externos del proceso. En cuanto a los participantes
externos, se siguieron los mismos criterios que para 2.1.1., ya que a mayor
cantidad de participantes externos, mayor será la complejidad del proceso,
pues se deberá controlar más canales de comunicación. Por ende, el modelo
que lo represente será más complejo de analizar y comprender. Cabe destacar
que si NPE = 0, se considera que el criterio es 0 ya que, al menos debería
existir un participante o rol externo correspondiente al cliente, ya que si no
existe se podría pensar que no existe ningún destinatario para el producto.
Preferencia Global: 3. Recursos Variable de Preferencia: 3.1. Producidos/Generados en el Proceso (Internos) Criterio elemental:
Donde NRI representa el número de recursos internos necesarios para llevar a
cabo el proceso. Esta métrica es una adaptación de la métrica NDOIn
propuesta en [77].
Criterio elemental C3.1(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto del número de recursos internos
del modelo. Se considera que, a mayor cantidad de recursos necesarios, mayor
será la dependencia de las tareas a ellos, por lo que si un recurso no está
disponible en tiempo y forma retrasará la finalización en tiempo y forma de la
tarea. NRI = 0, indicaría la ausencia de recursos, por lo que se considera que el
criterio no se satisface, ya que representaría una situación en la que el proceso
no produce ningún resultado o salida.
Variable de Preferencia: 3.2. Externos Criterio elemental:
0 si NRI(m) = 0 C3.1(m) =
1/NRI(m) si NRI(m) ≠ 0
1 si NRE(m) = 0 C3.2(m) =
1/NRE(m) si NRE(m) ≠ 0
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 105
Donde NRE representa el número de recursos externos necesarios en el
proceso. Esta métrica es una adaptación de la métrica NDOIn propuesta en
[77].
Criterio elemental C3.2(m): Establece la complejidad del modelo en cuanto a
su entendibilidad y su adaptabilidad respecto del número de recursos externos
del modelo. Contrariamente al número de recursos internos, si NRE = 0 se
considera que no existe una dependencia de los procesos con el exterior en
cuanto a los recursos necesario, por lo que no existe la complejidad de tener
que esperar por un recurso externo no disponible. Por este motivo, si NRE = 0
el criterio elemental se evalúa a 1. No obstante, a mayor número de recursos
necesarios, mayor será la complejidad del proceso ya que mayor será la
dependencia del proceso con actores externos a él.
Cabe destacar que los criterios propuestos constituyen un conjunto
posible de funciones a utilizar en la evaluación de estas metodologías. Sin
embargo, de ninguna manera son estáticos. Ellos pueden ser modificados, e
incluso cambiados por otros, en función de las necesidades y experiencia de
cada grupo que necesite decidir qué metodología utilizar en su proyecto de
desarrollo.
5.3.3. Fase 3: Definición de la Estructura de Agregación para la
Evaluación Global
En esta etapa, a partir de los requerimientos y de los criterios elementales
definidos en las primeras fases del método, se debe establecer una estrategia
para agregar dichos criterios elementales. De esta manera se obtiene, a partir
de los criterios elementales, un criterio global que constituirá la preferencia
global que indicará el grado de satisfacción de los requerimientos del modelo
estudiado.
Para la construcción de dicha estructura, se debe realizar una asociación
de las variables de preferencias mediante las funciones de agregación lógicas.
Esta agregación se debe realizar vinculando las variables que estén más
relacionadas entre sí, de manera de obtener resultados parciales para la
evaluación de las características más generales. Las funciones de agregación
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 106
vinculan las variables a través de operadores andor, cuya evaluación va de la
Disyunción Pura (D) a la Conjunción Pura (C). Los valores intermedios (D++ a
C++) representan evaluaciones donde la ausencia de un valor es compensado
por la presencia de otro/s. Dicha compensación es mayor mientras más cerca
esté el operador de la disyunción pura y menor mientras más cerca de la
conjunción pura esté.
De esta manera, en el primer nivel de agregación, se relacionaron entre sí
las variables correspondientes a las preferencias elementales de cada
categoría general en la estructura de requerimientos. Los operadores lógicos,
fueron seleccionados en función del grado de relevancia de cada preferencia
elemental. Es decir, se considera si es un requisito que siempre debe estar
presente o si es un requisito deseable pero que su ausencia no debe incidir
demasiado en la valoración del modelo. En cuanto al resto de los niveles de
agregación, se procedió de la misma manera agrupando los requerimientos
generales más relacionados entre sí.
Cabe destacar que la construcción de esta estructura es fuertemente
dependiente de la realidad que se está analizando. En el presente caso, se
considera que todas las características debieran estar presentes. Por este
motivo, se utilizaron conjunciones relajadas de manera que, si una de las
características no se encuentra, degrada la evaluación del modelo pero no lo
anula.
Bajo estas consideraciones, se arribó a la estructura de agregación de la
Figura 5.10.
Figura 5.10. Estructura de agregación para la evaluación de Metodologías Ágiles
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 107
5.3.4. Fase 4: Documentación, Análisis de los Resultados y
Conclusiones
La etapa final corresponde al análisis y comparación de los resultados
obtenidos en la evaluación de los modelos respecto de las preferencias
elementales. Se debe realizar una documentación de los resultados obtenidos
que sirva como referencia e historial de la evolución de los MPN estudiados en
futuras modificaciones y actualizaciones de los mismos. Esta documentación
puede servir como punto de referencia y comparación a la hora de evaluar los
modelos de otras metodologías ya existentes o que surjan con las nuevas
tecnologías.
En cuanto a la evaluación de los modelos, la misma se llevó a cabo
mediante una herramienta que permite realizar dicha evaluación de forma
automática [78]. A partir de dicha herramienta se obtuvieron los resultados de
la evaluación global de las metodologías estudiadas. La Tabla 5.3 presenta el
resultado de evaluar las tres metodologías y los valores que toman los criterios
elementales asociados a cada variable de preferencia y a cada metodología.
Tabla 5.3. Resultados de la aplicación del método a los modelos de las Metodologías Ágiles estudiadas (Ref-2)
Variables de Preferencia Peso OpenUP XP Scrum 1. Tareas/Actividades
1.1. Simples/Atómicas 0,5 0,016319612 0,02383449 0,016319612 1.2. Compuestas/Subprocesos 0,5 0,021204863 0,017761195 0,015189105
C-- 0,4 0,01870141211 0,02071294719 0,01575049381 2. Participantes / Actores
2.1. Internos 2.1.1. Número de
Participantes/Actores/Roles 0,5 0,066666667 0,166666667 0,333333333
2.1.2. Comunicación entre Participantes/Actores
0,5 0,5 0,8 0,8
C- 0,6 0,20811898383 0,39545023389 0,52944454777 2.2. Externos
2.2.1. Número de Participantes/Actores/Roles
0,4 0 0 0
C- 0,3 0,02939791213 0,05585944642 0,07478685512 3. Recursos
3.1. Producidos/ Generados en el Proceso (Internos)
0,6 0,034482759 0,1 0,142857143
3.2. Externos 0,4 1 1 1 C-+ 0,3 0,10932774680 0,22919132094 0,29132647747
C-+ 0,03441713695 0,05191745733 0,05185112972
Además, en la Tabla 5.4, se muestra un resumen de los resultados
indicando la evaluación de cada característica general y la evaluación global
para cada metodología (cabe destacar, que la información en la tabla resume la
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 108
evaluación de las distintas características parciales). Los valores mostrados
son obtenidos a partir de la evaluación de cada función de agregación de la
estructura mostrada en la Figura. 5.10.
Tabla 5.4. Resumen de los resultados de la aplicación del método a los modelos de las Metodologías Ágiles estudiadas
Variables de Preferencia Peso OpenUP XP Scrum 1. Tareas/Actividades C-- 0,4 0,01870141211 0,02071294719 0,01575049381 2. Participantes / Actores / Roles C- 0,3 0,02939791213 0,05585944642 0,07478685512 3. Recursos C-+ 0.3 0,10932774680 0,22919132094 0,29132647747 C-+ 0,03441713695 0,05191745733 0,05185112972
5.3.4.1. Análisis de los resultados y Documentación
Acorde a los valores mostrados en las Tablas 5.3 y 5.4, se puede
observar que XP obtuvo el valor de la preferencia global más alto. Sin
embargo, en la evaluación de cada subcaracterística individual, Scrum obtiene
el valor más elevado en lo referente a recursos y participantes. A pesar de ello,
XP resulta mejor calificado debido a que obtiene una mejor valoración respecto
de las tareas, a la cual se le ha dado más peso en la evaluación. Lo que indica
que para esta situación y los requerimientos planteados es más conveniente
aplicar está metodología. Sin embargo, esto muestra que el resultado de la
evaluación puede variar dependiendo de las necesidades y requerimientos de
los interesados en la evaluación y de la experiencia del grupo de evaluadores.
Una vez finalizada la etapa de evaluación de los resultados, como lo
establecen las fases de método, se procedió a documentar la evaluación a
través del llenado del formulario propuesto. De esta manera se arribó al
formulario mostrado en la Figura 5.11.
De la aplicación del método al presente caso de estudio, se pudo
observar que, si bien el método fue definido para la evaluación de modelos
conceptuales de procesos de negocio, es de suma utilidad para la evaluación
de distintos tipos de procesos. Esto se debe a que estas metodologías pueden
ser consideradas como procesos de negocio, en los cuales el producto es el
software desarrollado.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 109
Formulario de evaluación: Comparación de Metodologías Ágiles de Desarrollo
Nº de Referencia: 1 Fecha y Hora: 15-12-2012
EVALUADORE/S Áreas o Dpto o Comisión Externo/ Interno
Eval 1 UNSL UNSL Externo Eval 2 Carlos Salgado UNSL Externo
Modelo/s de Procesos de Negocio Evaluado/s
Nº de Modelo Desarrollador Fecha Lenguaje Evaluación Anterior
Fecha Nº de
Referencia 1 - - SPEM - -
2 - - SPEM - -
3 - - SPEM - -
Funciones de Criterio Aplicadas Definida (D) /
Repositorio (R) Criterio Elemental ID. Repositorio
ID. Función de Criterio
D Tareas/Actividades Simples/Atómicas
RFC-1 1
D Tareas/Actividades
Compuestas/Subprocesos RFC-1 2
D Participantes/Actores: Internos:
Número de Participantes RFC-1 9
D Participantes/Actores: Internos:
Comunicación entre Participantes
RFC-1 14
D Participantes/Actores: Externos: Número de
Participantes RFC-1 11
D Recursos: Producidos en el
Proceso (Internos) RFC-1 12
D Recursos: Externos RFC-1 13 Análisis de los Resultados
De la observación de la Tabla Ref-2, se puede ver que la metodología XP se ve favorecida en la característica referente a las tareas, mientras que Scrum lo hace respecto de las otras dos características. Sin embargo, XP resultó mejor favorecido respecto de Scrum y OpenUP en la evaluación global. Esto no se debe a que fue favorecido en una mayor cantidad de características, sino a que lo fue en aquellas características más relevantes y de mayor peso para los requisitos de evaluación planteados.
Acorde a las consideraciones establecidas en la presente evaluación, este resultado indica que el XP satisface en mayor medida los criterios establecidos para la evaluación de las metodologías ágiles propuestas.
Figura 5.11. Formulario de Documentación de la Evaluación
5.4. Conclusión
De la aplicación del método en ambos casos de estudio se pudo observar
que el mismo será de utilidad, no sólo en la evaluación de modelos
conceptuales de procesos de negocio respecto de su mantenibilidad. Como se
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 110
pudo ver en el análisis del primer caso de estudio, el método sirvió a la
organización para detectar fallas de implementación de sus procesos de
negocio. Mientras que en el segundo caso, se pudo ver que el método es
aplicable en el estudio de distintos tipos de proceso que pueden verse como
PN. Cabe destacar que, poder realizar un análisis comparativo de las
metodologías ágiles, no sólo es de utilidad en el campo empresarial, sino que
también es de gran ayuda en el ámbito académico universitario. Ya que, en
dicho ámbito, es importante mostrar a los estudiantes de las carreras
informáticas, que la aplicabilidad de una u otra metodología depende de los
objetivos y requerimientos de cada caso particular.
Carlos H. Salgado 111
CAPÍTULO 6. Conclusiones
Los procesos de negocio pueden ser vistos como un recetario para hacer
funcionar un negocio y alcanzar las metas definidas en la estrategia de negocio
de la empresa. La ventaja de una empresa respecto de sus competidores
radica en su habilidad de gestión, y en la adecuada administración de recursos,
conocimientos y atributos, etc., de los que dispone dicha empresa, y de los
cuales la competencia carece o tiene en menor medida o calidad. Esto hace
posible la obtención de un rendimiento superior al de dichos competidores.
El mejoramiento continuo es un proceso que, en la actualidad, es
fundamental para todas las empresas u organizaciones porque les permite
renovar o mejorar sus procesos de negocio. Esto implica una constante
actualización que hace que las organizaciones sean más eficientes y
competitivas. Es decir, las organizaciones que trabajen con una filosofía de
mejora continua tendrán más posibilidades de permanecer en el mercado con
mayor eficiencia y nivel competitivo.
El modelado de procesos de negocio es la base para comprender mejor la
operación de una organización, documentar y publicar los procesos buscando
una estandarización en la organización, alcanzar mayor eficiencia en la
operación e integrar soluciones en arquitecturas orientadas a servicios. Estas
características le darán a la organización una herramienta de gran valor para
mantenerse en el nivel competitivo mencionado en el párrafo anterior.
Por otro lado, la calidad de los procesos de negocio en cuanto a su
entendibilidad, mantenibilidad y adaptabilidad, es de suma importancia para las
organizaciones. Desde este punto de vista, los modelos de procesos de
negocio ayudan a entender mejor los procesos. Por ello, tener modelos de
calidad es fundamental a la hora de evaluar los procesos, ya sea para
mejorarlos o introducir cambios debidos a nuevas políticas de negocio, nuevo
equipamiento, nuevas reglamentaciones legales, etc.
Lo mencionado anteriormente, plantea la necesidad de tener un medio
para evaluar la calidad de dichos modelos. En este sentido, se definió un
método para la evaluación de modelos conceptuales de procesos de negocio
que sirve a las organizaciones a la hora de evaluar los modelos de sus
procesos de negocio, como así también los procesos mismos.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 112
El método propuesto se centra en la determinación de los requerimientos
de calidad elementales deseables de todo modelo y en la determinación del
grado de satisfacción de dichos requerimientos por parte de los modelos
evaluados.
Es sabido que, para que tenga valor, todo método debe ser validado
prácticamente. Por esta razón, se aplicó MEMPN: Método para la Evaluación
de Modelos de Procesos de Negocio en diversos casos de estudio con la
finalidad de lograr dicha validación. Así, se presentaron dos casos de estudio,
aplicando el método en:
1) La evaluación de los modelos de procesos de negocio de una empresa del
medio que pretende posicionarse de manera competitiva en el mercado. En
la evaluación, los modelos de la empresa fueron contrastados contra
nuevos modelos. Estos últimos, fueron desarrollados a partir de las
especificaciones de las necesidades de la empresa en cuanto a uno de los
procesos en los que la gerencia observaba mayores problemas. Como
resultado de la aplicación del método, se detectó que los nuevos modelos
se adaptaban más a los estándares de calidad de los modelos
conceptuales. A partir de este análisis, la gerencia de la empresa tomó los
modelos propuestos y los cotejó contra los procesos reales de la
organización. De esta manera se detectó que los mismos no se adecuaban
a los nuevos modelos. Cabe destacar que dichos modelos fueron
desarrollados en función de las especificaciones de requisitos realizados
por la gerencia, sin tener contacto previo con el modelo del proceso con
que ya contaba la empresa. De esta forma, la aplicación del método en
este caso, llevó a la gerencia a detectar que, si bien el proceso se
adaptaba a su modelo, el modelo no se adecuaba a la realidad de sus
requerimientos de negocio. Por lo tanto, se debía hacer una
reestructuración en la puesta en ejecución del proceso analizado.
2) Desde otra perspectiva, y considerando que el proceso de desarrollo de
software puede verse como un proceso de negocio cuyo producto es el
software desarrollado, se utilizó MEMPN en la evaluación de los
metamodelos de los procesos de desarrollo de distintas metodologías
ágiles de desarrollo de software. Dicho análisis se realizó haciendo
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 113
hincapié en las tareas. El desarrollo de este caso de estudio sirvió para
mostrar que, si bien el método está definido para la evaluación de modelos
de procesos de negocio, es aplicable en la evaluación de otros procesos
como el proceso de desarrollo de software.
En cuanto a los modelos analizados en los casos de estudio, cabe
destacar que los mismos estaban desarrollados en BPMN en el primer caso y
en SPEM en el segundo. Esta es una de las virtudes del método, ya que es
aplicable independientemente de la notación utilizada en los modelos. Esto es
de gran ayuda debido a que en la actualidad existe una amplia variedad de
lenguajes, herramientas y metodologías para el modelado de procesos de
negocio.
La aplicación del método en los casos de estudio mencionados
previamente, mostró la versatilidad del mismo. Ya que, en ambos casos los
requisitos a evaluar fueron diferentes, por lo tanto las estructuras de
requerimiento fueron diferentes. Esto muestra, como se ha mencionado a lo
largo del presente informe, que las estructuras de requerimiento no son
cerradas, por el contrario son adaptables a las necesidades de la situación
particular a evaluar. Esto es fundamental, ya que cada proceso tendrá sus
propias reglas y necesidades a satisfacer. Desde esta perspectiva, el método
servirá como ayuda a los responsables de proyectos en la toma de decisiones
respecto de la calidad de los modelos conceptuales de procesos de negocio.
Esto se debe a que permitirá analizar, evaluar y comparar dichos modelos con
otros modelos, o contrastarlos con otras marcas de referencias. Donde dichas
marcas de referencias pueden ser propias de la organización o institución o
tomadas de la bibliografía o estándares.
Desde otro punto de vista, el método aporta una estructura de
características deseables en todo modelo conceptual de procesos de negocio y
un conjunto de criterios elementales que sirven como base para la evaluación
de los modelos. La definición de los criterios es de gran utilidad para la
comparación y estudio de los distintos modelos. Estos criterios pueden ser
almacenados en repositorios para su posterior utilización o redefinición. Ello
proveerá una fuente de información muy útil que ayudará en futuras
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 114
evaluaciones, ya sea de los mismos modelos como así también de modelos
nuevos, del mismo proceso o procesos de realidades diferentes.
Además, la información almacenada en la documentación generada en
las evaluaciones, podrá ser utilizada como un indicador para medir el grado de
avance en el proceso de mejora continua de los PN. Pudiendo comparar y
ajustar los valores de la evaluación a los indicadores de calidad.
Desde la perspectiva educativa, el método también proporciona un
importante aporte. Como surge de su aplicación en el segundo caso de estudio
presentado: una comparación de las distintas metodologías ágiles. Dicha
comparación puede ser utilizada para mostrar a los estudiantes de la Ingeniería
de Software las diferencias, bondades y desventajas de estas metodologías,
como también de cualquier otro tipo de metodología. Mostrando además que,
acorde a las características del proyecto en particular, se deberá adoptar una u
otra metodología de los objetivos que se pretendan alcanzar.
Carlos H. Salgado 115
CAPÍTULO 7. Trabajos Futuros
En la continuidad de esta propuesta, se espera:
- En base a los resultados obtenidos, continuar con el trabajo de refinamiento
y mejora de la estructura de requerimientos base propuesta en el método.
Para ello, se analizará la posibilidad de refinar las categorías de
preferencias ya incluidas en la estructura propuesta, como así también la
incorporación de nuevas categorías.
- Proseguir con el trabajo de mejora del método con la construcción de una
herramienta para la Web que permita su aplicación automatizada en el
análisis de los modelos estudiados. La disponibilidad de la herramienta en
la Web, posibilitará un mayor aprovechamiento y utilización del método en
distintos ámbitos.
- Crear un repositorio web de criterios elementales. Esto permitirá que los
criterios estén disponibles para su validación y utilización por parte de la
comunidad científica.
- Analizar la posibilidad de automatizar el cálculo de pesos de las variables
de preferencia en la estructura de agregación. De esta manera se podrá
proveer una guía para la elección de los pesos más adecuados, acorde a la
problemática particular estudiada.
- Analizar la posibilidad de utilizar el método para la elaboración de
estrategias de Comprensión de Procesos de Negocios. Entiéndase por tal
disciplina aquella que facilita el entendimiento de la tarea realizada por los
procesos de negocios a través de la interrelación de: i) la acción realizada
por el proceso (Dominio del Problema) y ii) las componentes de la
especificación/implementación del proceso que se utilizaron para llevar a
cabo dicha acción (Dominio de la Especificación).
- Estudiar la posibilidad de definir un meta método de evaluación que,
mediante las entradas adecuadas, posibilite la selección del método de
evaluación más adecuado para dominios específicos.
- Aplicar el método a otros dominios, como por ejemplo: Comprensión de
Programas, Seguridad Informática.
Carlos H. Salgado 116
ANEXO 1. BPMN: Business Process Management Notation
A1.1. BPMN
BPMN (Business Process Modeling Notation) es un estándar definido por
la BPMI (Business Process Management Initiative). El objetivo primario de
BPMN es proporcionar una notación que sea fácilmente comprensible por
todos los usuarios empresariales (desde los analistas de negocio que crean los
borradores iniciales de los procesos, hasta los desarrolladores técnicos
responsables de implementar la tecnología que realizará dichos procesos y,
finalmente, la gente de negocio que gestionará y supervisará estos procesos).
BPMN disminuye la brecha existente entre el diseño del proceso de negocio y
su implementación [11].
BPMN constituye un medio simple de comunicar información del proceso
de negocio a otros usuarios, proveedores, clientes, etc. Además, BPMN
permite que lenguajes basados en XML diseñados para la ejecución de
procesos de negocio (como por ejemplo WSBPEL), puedan ser vistos como
una notación orientada al negocio.
La especificación de BPMN define la notación y la semántica de un
Diagrama de Procesos de Negocio (DPN). De esta manera, la notación provee
una manera simple de comunicación de información de procesos a otros
clientes, proveedores e implementadores de procesos, y usuarios del negocio
[11].
A1.2. Visión General
En los últimos años se han desarrollado numerosos lenguajes de
ejecución de procesos de negocios que son ampliamente utilizados en la
implementación de Sistemas de Gestión de Procesos de Negocios (GPN).
Dichos lenguajes constituyen un mecanismo formal para la definición de estos
procesos, un ejemplo de estos lenguajes es WSBPEL.
Estos lenguajes están optimizados para la operación y la inter-operación
de los sistemas GPN, de manera que son lenguajes optimizados para
operaciones de software, por lo que no son adecuados para diseñar, gestionar
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 117
y supervisar procesos de negocio. WSBPEL, por ejemplo, tiene estructuras de
bloque y gráficas y utiliza los principios de modelos matemáticos formales. Este
apoyo técnico proporciona la base para la ejecución de procesos de negocio.
Es decir, permite: i) Manejar la naturaleza compleja de las interacciones
internas y de B2B (Business to Business) y ii) Tomar ventaja de los beneficios
de los servicios Web. De esta manera, debido a la naturaleza de WSBPEL, las
especificaciones de procesos de negocio escritos en dicho lenguaje pueden ser
engorrosas, disjuntas y no intuitivas. Por esta razón, si bien WSBPEL es un
lenguaje ejecutable que puede ser muy bien gestionado por un sistema
software, no puede ser utilizado para la comunicación entre los diferentes
actores del proceso de desarrollo (analistas, gerentes de negocios, etc.). Por lo
tanto, hay un nivel humano de “comunicación”, “interoperabilidad” y de
“portabilidad” que no es tratado por estos lenguajes de ejecución de procesos
de negocio basados en servicios web [11].
La visualización de los procesos de negocio como organigrama ha tenido
una gran aceptación por los principales actores de los negocios. Sin embargo,
para quienes estudian la forma en que las compañías trabajan y definen
procesos de negocio con organigramas simples, se crea una brecha técnica
entre los formatos de: i) El diseño inicial de los procesos de negocio y ii) Los
lenguajes de ejecución de procesos de negocio, basados en servicios Web
para sistemas de Gestión de Procesos de Negocio (GPN).
Dichos lenguajes constituyen un mecanismo formal para la definición de
estos procesos. Un ejemplo de estos lenguajes es WSBPEL. Por lo tanto, se
hace necesario un mecanismo formal que permita convertir una visualización
apropiada de los procesos de negocio a un formato de ejecución apropiado (un
lenguaje de ejecución de sistemas de GPN) para estos procesos de negocio.
Por lo expuesto en el párrafo precedente, BPMN surge como una solución
a esta brecha mencionada, ya que establece una estandarización en la
notación y provee un Diagrama de Proceso de Negocio (DPN), destinado a los
diseñadores y gerentes de procesos de negocio. Además, provee un mapeo al
lenguaje de ejecución WSBPEL. De esta manera, BPMN provee un mecanismo
de visualización estándar para los Procesos de Negocio definidos en un
lenguaje de procesos de negocio optimizado.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 118
Desde otro punto de vista, la notación gráfica de BPMN provee a las
empresas la capacidad de entender sus procedimientos de negocio internos,
dándoles a las organizaciones, a través de una notación estándar, la capacidad
de comunicar dichos procedimientos. Además, una notación gráfica facilita la
inserción de los analistas, gerentes, etc. en nuevas organizaciones. Esto es
fundamental debido: i) Al dinamismo actual en el mundo de los negocios,
donde las empresas surgen, se unen y divergen constantemente y ii) A que, en
las distintas etapas del ciclo de vida de una compañía, surgirán distintas
representaciones de los mismos procesos, acorde a la etapa del ciclo de vida
en que se encuentre. De la misma forma, facilitará la comprensión de las
colaboraciones del funcionamiento y las transacciones de negocio dentro y
entre las organizaciones. Esta característica asegura que los negocios sean
entendidos internamente y por los participantes en su negocio. Esto ayudará a
las organizaciones adaptarse rápidamente a nuevas circunstancias de negocio
internas y B2B. Por todo lo expuesto, BPMN sigue las notaciones de
organigramas, lo que le da una mayor legibilidad y proporciona un mapeo a
construcciones ejecutables.
A1.3. Alcance de BPMN
No obstante su amplia aplicabilidad, BPMN soporta sólo los conceptos de
modelado aplicables a procesos de negocio. BPMN no abarca otros tipos de
modelado que las organizaciones hacen para propósitos del negocio. Por
ejemplo, no es parte de BPMN el modelado de:
• Estructuras y recursos Organizacionales.
• Averías Funcionales.
• Modelos de Datos e información.
• Estrategias.
• Reglas de Negocio.
Además, si bien BPMN muestra el flujo de datos (mensajes), y la
asociación de artefactos de datos a las actividades, no es un Diagrama de flujo
de datos.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 119
A1.4. Usos de BPMN
Los modelos de procesos de negocio son usados para comunicar “una amplia
variedad de información a una amplia variedad de audiencias”. Por ello, BPMN
está diseñado para cubrir muchos tipos de modelos y permite la creación de
procesos de negocio punto-a-punto (end-to-end)7. Los elementos estructurales
de BPMN permiten al receptor diferenciar fácilmente entre las diferentes
secciones de un Diagrama BPMN. Hay tres tipos básicos de sub-modelos
dentro de un modelo BPMN punto-a-punto [11], estos son:
1. Procesos de Negocio Privado (interno)
2. Procesos Abstractos (público)
3. Procesos de Colaboración (globales).
Procesos de Negocio Privados (Internos): Son aquellos procesos internos a
una organización específica. Generalmente, se los conoce como workflows o
procesos de GPN, la Figura 1 muestra un ejemplo de este tipo de procesos. Si
se usan Carriles (Swimlanes)8, entonces un proceso de negocio privado estará
contenido dentro de un único Pool. El flujo de secuencia del proceso está
contenido dentro del Pool y no puede cruzar sus fronteras. El Flujo de
Mensajes puede cruzar las fronteras del Pool para mostrar las interacciones
existentes entre procesos de negocio privados separados. De esta manera, un
único Diagrama de Proceso de Negocio puede mostrar múltiples procesos de
negocio privados, cada uno con un mapeo WSBPEL separado. En este
contexto, es importante notar que un único proceso de negocio privado puede
ser mapeado a uno o más especificaciones WSBPEL.
Figura A-1.1. Ejemplo de Proceso de Negocio Privado [11]
Procesos Abstractos (Públicos): Representan las interacciones entre un
proceso de negocio privado y otros procesos o participantes. En la Figura 2 se
7 En la jerga de Ingeniería de Software a este tipo de diagramas BPMN se los conoce con el nombre de diagramas BPMN punto-a-punto.
8 Los conceptos de Swimlanes y Pool serán explicados en detalle en las secciones siguientes.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 120
puede observar un ejemplo típico de este tipo de procesos.
En un proceso abstracto sólo se incluyen aquellas actividades utilizadas
por los procesos de negocio privados para comunicar información al exterior. El
resto de las actividades “internas” de un proceso de negocio privado no son
mostradas. Debido a ello, el proceso abstracto muestra al mundo externo la
secuencia de mensajes requeridos para interactuar con dicho proceso de
negocio. Un único proceso abstracto puede ser mapeado a un único proceso
abstracto WSBPEL.
Los procesos abstractos están contenidos dentro de un Pool y pueden ser
modelados separadamente o dentro de un gran Diagrama BPMN para mostrar
el flujo de mensajes entre las actividades del proceso abstracto y otras
entidades. Si el proceso abstracto está en el mismo Diagrama que su
correspondiente proceso de negocio privado, entonces las actividades
comunes a ambos procesos pueden asociarse.
Figura A-1.2. Ejemplo de Proceso de Negocio Abstracto [11].
Procesos de Colaboración (Globales): Describen las interacciones entre dos
o más entidades de negocio. Estas interacciones se definen como una
secuencia de actividades que representa los patrones de intercambio de
mensajes entre las actividades involucradas. Un único proceso de colaboración
puede ser mapeado a varios lenguajes de colaboración, tales como ebXML
BPSS o RosettaNet.
Los procesos de colaboración pueden ser mostrados como dos o más
procesos abstractos que se comunican entre sí (un ejemplo de esta clase de
proceso se puede observar en la Figura 3). Con un proceso abstracto, las
actividades para los participantes de la colaboración pueden considerarse los
“puntos de contacto” (“touch-points”) entre los participantes.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 121
Figura A-1.3. Ejemplo de un proceso de negocio de colaboración [11]
A1.5. Tipos de Diagramas de Proceso de Negocio
Dentro y entre los tres sub-modelos BPMN descritos en la sección anterior, se
pueden crear muchos tipos de Diagramas. En este sentido, los tipos de
procesos de negocio que pueden modelarse con BPMN son:
• Actividades de proceso privado de alto nivel (no averías funcionales).
• Proceso de negocio privado detallado.
• Proceso de negocio viejo o actual.
• Proceso de negocio nuevo o a construir.
• Proceso de negocio privado detallado con interacción a una o más
entidades externas (o procesos de “caja negra”).
• Dos o más procesos de negocio privados detallados que interactúan.
• Proceso de negocio privado detallado relacionado a un Proceso
Abstracto.
• Proceso de negocio privado detallado relacionado a un Proceso de
Colaboración.
• Dos o más Procesos Abstractos.
• Relación de Proceso Abstracto a Proceso de Colaboración.
• Solamente Proceso de Colaboración (e.g., ebXML BPSS or RosettaNet).
• Dos o más procesos de negocio privados detallados que interactúan a
través de sus Procesos Abstractos.
• Dos o más procesos de negocio privados detallados que interactúan a
través de un Proceso de Colaboración.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 122
• Dos o más procesos de negocio privados detallados que interactúan a
través de sus Procesos Abstractos y de un Proceso de Colaboración.
Si bien BPMN permite todos los tipos de diagramas anteriores, se debe
tener en cuenta que no es conveniente combinar demasiados tipos de sub-
modelos. Esto se debe a que el diagrama puede volverse difícil de entender.
Por este motivo, es recomendable establecer un propósito enfocado para el
DPN, como un proceso privado o un proceso de colaboración.
A1.6. Mapeos BPMN
Puesto que BPMN cubre un amplio rango de usos, mapeará a más de un
lenguaje de especificación de bajo nivel:
• WSBPEL es el lenguaje primario al que BPMN mapea, pero éste cubre
un único proceso de negocio privado ejecutable. Si un Diagrama BPMN
describe más de un proceso de negocio interno, entonces habrá un
mapeo separado para cada uno de los procesos de negocio internos.
• Las secciones abstractas de un Diagrama BPMN son mapeadas a
especificaciones de interfaces de un servicio Web, tales como los
procesos abstractos de WSBPEL.
• Las secciones de modelos de Colaboración de un Diagrama BPMN
pueden ser mapeadas a modelos de Colaboración tales como ebXML
BPSS y RosettaNet.
Un DPN no está diseñado para expresar gráficamente toda la información
requerida para ejecutar un proceso de negocio. Por este motivo, los elementos
gráficos de BPMN poseen atributos que proveen información adicional para
brindar la información faltante que se requiere para ejecutarlos.
A1.7. Extensibilidad de BPMN y Dominios Verticales
Otras de las ventajas que posee BPMN es que permite a los modeladores
extender la notación. Dicha tarea se lleva a cabo a través de la definición de
elementos o Artefactos no estándares. Generalmente, la creación de este tipo
de elementos es necesaria para expresar una necesidad específica. Los
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 123
requerimientos únicos de un dominio vertical son un ejemplo de tales
necesidades. No obstante esta extensibilidad, los diagramas deberían
conservar el aspecto visual básico de modo que un Diagrama de cualquier
modelador pueda ser fácilmente entendido por cualquier observador del
Diagrama. Por ello no se debe alterar la presentación de los elementos de flujo
básicos (Eventos, Actividades y Compuertas (Gateways)), como tampoco se
deberían agregar nuevos elementos de flujo a un DPN, puesto que no hay
especificaciones de cómo los Flujos de Secuencia y Mensajes se conectarán a
cualquier Objeto de Flujo Nuevo. Además, esto puede afectar los mapeos a
lenguajes de ejecución.
Para modelar conceptos de modelado adicionales, BPMN provee el
concepto de Artefactos que pueden vincularse a los Objetos de Flujo existentes
a través de Asociaciones. Dichos Artefactos no afectan la Secuencia o Flujo de
Mensajes básicos, ni el mapeo a lenguajes de ejecución.
Igualmente, los elementos gráficos de BPMN permiten expresar
información especializada a través del uso de marcadores especializados. Por
ejemplo, los elementos para la representación de eventos tienen centros
abiertos para los marcadores que BPMN estandariza y para los definidos por el
usuario.
A1.8. Diagramas de Proceso de Negocio
Generalmente, los participantes de un proceso de negocio pueden ver a un
diagrama de negocio de manera diferente. Esto se debe a que: i) Cada
participante tiene su propio punto de vista respecto de cómo los procesos se
aplicarán y ii) Un diagrama BPMN puede describir los procesos de diferentes
participantes.
Un participante puede ver una actividad como interna mientras que otras
serán externas para él. Es decir, cada participante tendrá una perspectiva
diferente respecto de las actividades según dichas actividades se vinculen al
proceso del que él es responsable. No obstante esta visión dependiente del
participante, el diagrama que representa el proceso sigue siendo el mismo.
Uno de los objetivos de BPMN es proveer una notación simple y que
pueda ser adoptada por los analistas de negocio, permitiéndoles describir
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 124
procesos de negocio complejos y realizar su mapeo a lenguajes de ejecución
de sistemas de GPN. En este sentido, BPMN clasifica los objetos gráficos en
dos grupos. En primer lugar, provee una lista de elementos centrales que dan
soporte a los requerimientos de una notación simple y definen el aspecto visual
básico de BPMN. La mayoría de los procesos de negocio pueden ser
modelados adecuadamente con estos elementos. En segundo lugar, se provee
una lista completa de elementos, que incluye los elementos centrales, la cual
da soporte a situaciones de modelado avanzadas.
Además, BPMN adiciona a los elementos gráficos atributos no gráficos.
Estos atributos permiten incluir información que, si bien es necesaria para
mapear a un lenguaje de ejecución o para otros propósitos de modelado, no es
posible representar mediante los elementos gráficos de BPMN.
En la siguiente sección se presenta una descripción de los objetos
gráficos de BPMN y sus relaciones.
A1.9. Conjunto de Elementos Centrales de DPN
Como se mencionó en la sección previa, BPMN intenta satisfacer los
requerimientos de simplicidad y claridad de las especificaciones. Estos
requerimientos son manejados a través de la organización de los aspectos
gráficos en categorías específicas.
Para ello, se provee un conjunto pequeño de categorías de notación de
forma tal que un diagrama BPMN sea fácil de entender. Asimismo, dentro de
las categorías básicas, se pueden agregar variaciones e información adicional.
Ambas incorporaciones, si son realizadas correctamente, permiten soportar
requerimientos de complejidad. Es importante notar que dicho soporte se
realiza sin cambiar el aspecto visual básico del diagrama. Las cuatro categorías
básicas de elementos son:
1. Objetos de Flujo
2. Objetos de Conexión
3. Carriles (Swimlanes)
4. Artefactos
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 125
Los Objetos de Flujo son los elementos gráficos principales para definir el
comportamiento de un Proceso de Negocio. Hay tres Objetos de Flujo:
1. Eventos
2. Actividades
3. Compuertas (Gateways)
Hay tres maneras de conectar Objetos de Flujo entre sí o a otra
información. Hay tres Objetos de Conexión:
1. Flujo de Secuencia
2. Flujo de Mensaje
3. Asociación
Hay dos maneras de agrupar los elementos de modelado primario a
través de “carriles” (“Swimlanes”):
1. Pools
2. Lanes
Finalmente, información adicional acerca del Proceso se puede incluir a
través de los Artefactos. BPMN provee tres Artefactos estandarizados:
1. Objetos de Datos
2. Grupos
3. Anotaciones
No obstante este reducido conjunto de artefactos estándares, los
modeladores o herramientas de modelado son libres de agregar tantos
Artefactos como sea necesario.
Las Tablas A-1.1 a A-1.4 despliegan una lista de los elementos de
modelado centrales descriptos por la notación.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 126
Tabla A-1.1. Conjunto de Elementos Centrales de DPN: Objetos de Flujo
Elemento Descripción Notación
Evento
Un evento es algo que “ocurre” durante el
curso de un proceso de negocio. Estos
eventos afectan el flujo del proceso y
usualmente tienen una causa (dispara-
dor) o un impacto (resultado). Los even-
tos son círculos con centros abiertos que
permiten marcadores internos que dife-
rencian distintos disparadores o resulta-
dos. Hay tres tipos de eventos, basados
en cuándo ellos afectan el flujo: Inicio,
Intermedio y Final.
Actividad
Una Actividad es un término genérico
para el trabajo que una compañía realiza.
Una actividad puede ser atómica o no-
atómica (compuesta). Los tipos de activi-
dades que pueden ser parte de un
proceso son: Proceso, Sub-Proceso y
Tarea. Las Tareas y Sub-Procesos son
rectángulos redondeados. Los Procesos
están contenidos dentro de un Pool.
Compuerta
(Gateway)
Una compuerta es usada para controlar
la convergencia y divergencia del Flujo
de Secuencia. Esto determinará las
ramificaciones, bifurcaciones, combina-
ciones, y uniones de caminos. Los Mar-
cadores Internos indicarán el tipo de con-
trol de comportamiento.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 127
Tabla A-1.2. Conjunto de Elementos Centrales de DPN: Objetos de Conexión
Elemento Descripción Notación
Flujo de
Secuencia
Muestra el orden en que las actividades
serán ejecutadas en un Proceso.
Flujo de Mensaje Muestra el flujo de mensajes entre dos
participantes. En BPMN, dos Pools
separados en un Diagrama representan
los dos participantes (e.g., entidades de
negocio o roles de negocio).
Asociación Muestra la asociación de información con
Objetos de Flujo. Una Cabeza de Flecha
en la Asociación indica la dirección del
flujo.
Tabla A-1.3. Conjunto de Elementos Centrales de DPN: Carriles
Elemento Descripción Notación
Pool Representa un Participante en un
Proceso. También actúa como un “carril”
(“swimlane”) y un contenedor gráfico para
particionar un conjunto de actividades de
otros Pools, usualmente en el contexto
de situaciones de B2B.
Lane Un Lane es una sub-partición dentro de
un Pool y extenderá la longitud entera del
Pool, vertical u horizontalmente. Son usa-
dos para organizar y categorizar las acti-
vidades.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 128
Tabla A-1.4. Conjunto de Elementos Centrales de DPN: Artefactos
Elemento Descripción Notación
Objeto de Datos Son considerados Artefactos ya que no
tienen un efecto directo sobre el Flujo de
Secuencia o el Flujo de Mensajes del
Proceso. No obstante ello, proveen
información acerca de qué actividades
deben ejecutarse y/o qué producen ellas.
Grupo
(una caja
alrededor de un
grupo de objetos
dentro de la
misma categoría)
Un agrupamiento de actividades que
están dentro de la misma categoría. Este
tipo de agrupamiento no afecta el Flujo
de secuencia de las actividades dentro
del grupo. El nombre de la categoría
aparece sobre el diagrama como el rótulo
del grupo. Las categorías pueden utilizar-
se para propósitos de documentación o
análisis. Los grupos son una de las
maneras en que las categorías pueden
ser desplegadas visualmente en el dia-
grama.
Anotaciones de
Texto
(ligada con una
Asociación)
Las Anotaciones de Texto son un meca-
nismo que permite al modelador proveer
información adicional al lector de un
Diagrama BPMN.
A1.10. Conjunto Extendido de Elementos de DPN
La Tabla 5 presenta los elementos extendidos de DPN. En esta lista, se
han omitido los elementos centrales de la notación aunque los mismos están
incluidos en ella.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 129
Tabla A-1.5.Conjunto de Elementos Extendidos de DPN
Elemento Descripción Notación EVENTOS
Dimensión del Flujo (e.g., Inicio, Intermedio, Final) • Inicio (Ninguno,
Mensaje, Temporizador, Condicional, Señal, Múltiple).
• Intermedio (Ninguno, Mensaje, Temporizador, Error, Cancelación, Compensación, Condicional, Vínculo (Link), Señal, Múltiple)
• Final (Ninguno, Mensaje, Error, Cancelación, Compensación, Señal, Terminador, Múltiple)
Como su nombre lo dice, el Evento de Inicio indica dón-de comenzará un proceso particular.
Inicio
Los Eventos Intermedios ocurren entre un Evento de Inicio y un Evento Final. Ellos Afectan el flujo del proceso, pero no iniciarán o terminarán (directamente) el proceso.
Intermedio
Como su nombre lo dice, el Evento Final indica dónde finalizará un proceso.
Final
Dimensión de Tipo (Ninguno, Mensaje, Temporizador, Error, Cancelación, Compensación, Condicional, Vínculo (Link), Señal, Múltiple, Terminador)
Los Eventos de Inicio y los Intermedios tienen “Dispa-radores” que definen las causas del evento. Hay múltiples maneras de que estos eventos puedan ser disparados. Los Eventos Finales pue-den definir un “Resultado” que es una consecuencia de un Flujo de Secuencia que finaliza. Los Eventos de Inicio sola-mente pueden reaccionar (“capturar”) ante un Dispa-rador. Los Eventos Finales sólo pueden crear (“devolver”) un Resultado. Los eventos intermedios pueden capturar o devolver un Disparador. Para los
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 130
Elemento Descripción Notación Eventos, en los disparado-res de captura, los marca-dores son sin llenar, y para los Disparadores y Resulta-dos que devuelve, los mar-cadores son llenados
Rotura de Proceso (cosas fuera del control del proceso hacen que el proceso sea pausado)
Una Rotura del Proceso es una localización en el Pro-ceso que muestra dónde una demora esperada ocu-rrirá dentro de un Proceso. Se usa un Evento Interme-dio para mostrar el compor-tamiento actual. Además, un Artefacto de Rotura de Proceso, diseñado por un modelador o herramienta de modelado, puede asociarse con el evento para resaltar la ubicación de la demora dentro del flujo.
Conector Fuera de Página
Generalmente es usado pa-ra impresiones, este objeto mostrará dónde el Flujo de Secuencia deja una página y luego reinicia sobre la siguiente página. Se puede usar un Evento Intermedio de Enlace como un Conec-tor Fuera de Página.
ACTIVIDADES Tarea (Atómica) Una Tarea es una actividad
atómica incluida dentro de un Proceso. Una Tarea se usa cuando el trabajo en el Proceso no es descom-puesto en un nivel más fino de detalle del Modelo de Proceso.
Proceso/Sub-Proceso (no atómico)
Un Sub-Proceso es una actividad compuesta incluida dentro de un Proceso. Es compuesta en el sentido de que puede ser descompuesta en un nivel más fino de detalle (un Proceso) a través de un conjunto de sub-actividades (Ver las dos figuras siguientes en la tabla).
Sub-Proceso Colapsado
Los detalles del Sub-Pro-ceso no están visibles en el Diagrama. Un signo “+” en el centro inferior del rectán-gulo indica que la actividad
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 131
Elemento Descripción Notación es un Sub-Proceso y tiene un nivel más bajo de deta-lle.
Sub-Proceso Expandido
La frontera del Sub-Proceso es expandida y los detalles (un Proceso) son visibles dentro de su frontera. El Flujo de Secuencia no pue-de cruzar la frontera de un Sub-Proceso.
Instancia Múltiple Los atributos de las Tareas y Sub-Procesos determina-rán si son repetidas o ejecu-tadas sólo una vez. Un indi-cador paralelo pequeño se-rá desplegado en el centro inferior de la actividad.
Transacción Una transacción es un Sub-Proceso soportado por un protocolo especial. Este protocolo asegura que to-das las partes involucradas acuerdan que todas las acti-vidades deberían ser com-pletadas o canceladas. Los atributos de la actividad de-terminarán si dicha activi-dad es una transacción. Una frontera con doble línea indica que el Sub-Proceso es una Transac-ción.
Sub-Proceso Anidado/Embebido
Un Sub-Proceso anidado (o embebido) es una actividad que comparte el mismo conjunto de datos que su proceso padre. Esto es opuesto a un Sub-Proceso que es independiente, reu-sable y referenciado desde el proceso padre. Los datos necesitan ser pasados al Sub-Proceso referenciado, pero no al Sub-Proceso anidado.
No hay un indicador especial para Sub-Procesos anidados
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 132
Elemento Descripción Notación COMPUERTAS DE CONTROL
Tipos de Compuertas de Control
Los íconos dentro del Dia-mante indican el tipo de flujo de control. Los tipos de control incluidos son: • Decisión y Unión Exclu-
siva. Basadas en Da-tos, que pueden mos-trarse con o sin el mar-cador “X”, y basadas en Eventos.
• Decisión y Unión Inclu-siva.
• Complejas – Condicio-nes y situaciones com-plejas.
• División y Unión Parale-la.
Cada tipo de control afecta a los Flujos de entrada y de salida.
Fork BPMN usa el término “fork” para referirse a la división de un paso en dos o más pasos paralelos. Es un lugar en el Proceso donde las actividades pueden eje-cutarse concurrentemente en vez de secuencialmente. Hay dos opciones: 1. Puede usarse un Flujo
de Secuencia de Salida Múltiple. Un flujo sin con-trol es el método preferi-do en la mayoría de las situaciones para repre-sentarlo.
2. Se puede usar una Com-puerta Paralela. Se usa en raras ocasiones, usualmente en combina-ción con otras Compuer-tas.
1.
2.
Join BPMN usa el término “join” para referirse a la combina-ción de dos o más pasos paralelos en un solo paso. Se usa una compuerta
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 133
Elemento Descripción Notación Paralela para mostrar la unión de múltiples Flujos.
Decisión, Punto de Ramificación
Las Decisiones son Compuertas dentro de un proceso de negocio donde el flujo de control puede tomar uno o más pasos alternativos (Ver las cinco figuras siguientes en la tabla).
Exclusivo Una compuerta Exclusiva restringe el flujo tal que so-lamente una, de un conjun-to de alternativas, se puede elegir durante la ejecución. Hay dos tipos de Compuer-tas Exclusivas: basadas en Datos y basadas en Even-tos.
Basada en Datos Esta decisión representa un punto de ramificación donde las alternativas están basa-das en expresiones condi-cionales contenidas dentro del Flujo de Secuencia sa-liente. Solamente una de las Alternativas será elegi-da.
Basada en Eventos
Esta decisión representa un punto de ramificación donde las Alternativas están basa-das en un Evento que ocu-rre en ese punto en el Pro-ceso. El Evento específico, usualmente la recepción de un Mensaje, determina cuá-les de los pasos se toma-rán. Se pueden usar otros tipos de Eventos como por ejemplo Temporales. Solamente una de las Alternativas será elegida. Hay dos opciones para reci-bir Mensajes: 1. Se pueden usar Tareas
de Recepción de Tipos. 2. Se pueden usar Eventos
Intermedios de Mensajes de Tipo.
1.
2.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 134
Elemento Descripción Notación Inclusivo Esta Decisión representa un
punto de ramificación donde las Alternativas están basa-das en expresiones condi-cionales contenidas dentro del Flujo de Secuencia que sale. En algún sentido es un agrupamiento de Decisio-nes Binarias (Si/No) inde-pendientes relacionadas. Puesto que cada paso es independiente, todas las combinaciones de los pasos pueden ser tomadas, de cero a todas. Sin embargo, debería ser diseñado de manera que al menos un paso sea tomado. Se puede usar una condición por de-fecto para asegurarse que al menos un paso sea to-mado. Hay dos versiones de este tipo de decisión: 1. La primera usa una co-
lección de Flujos de Secuencia condicionales, marcadas con un mini-diamante.
2. La segunda usa una Compuerta Inclusiva.
1.
2.
Merging BPMN usa el término “merge” para referirse a la combinación exclusiva de dos o más pasos en un paso. Se usa una Compuer-ta Exclusiva de Unión para mostrar la unión de Flujos múltiples. Si todos los flujos entrantes son alternativos, entonces no es necesaria una Compuerta. Es decir, los flujos sin control pro-veen el mismo comporta-miento.
OBJETOS DE CONEXIÓN Flujo de Secuencia Un Flujo de Secuencia es usado para mostrar el orden
en que las actividades se ejecutarán en el proceso (Ver las seis figuras siguientes en la tabla).
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 135
Elemento Descripción Notación Flujo Normal Se refiere al flujo que se
origina desde un Evento de Inicio y continúa a través de las actividades vía pasos paralelos y alternativos has-ta terminar en un Evento Final.
Flujo sin control Se refiere a flujos que no son afectados por alguna condición o no pasan a través de una compuerta. El ejemplo más simple es un Flujo de Secuencia único que conecta dos activida-des. También se puede aplicar a Flujos de Secuen-cia Múltiple que convergen a o divergen de una activi-dad. Para cada Flujo de Secuencia sin control un “Token” fluirá desde el objeto de origen al objeto destino.
Flujo Condicional El flujo de Secuencia puede tener expresiones de condi-ción que se evalúan en tiempo de ejecución para determinar si el flujo se usará o no. • Si el flujo condicional es-
tá saliendo de una acti-vidad, el Flujo de Se-cuencia tendrá un dia-mante en el comienzo de la línea.
• Si el flujo condicional es-tá saliendo de una com-puerta, la línea no tendrá el diamante.
Flujo por Defecto Para las Decisiones Exclu-sivas Basadas en Datos o las Decisiones Inclusivas, un tipo de flujo es el flujo de condición por defecto. Este flujo se usa sólo si todos los flujos condicionales de Sali-
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 136
Elemento Descripción Notación da no son verdaderos en tiempo de ejecución. Estos Flujos de Secuencia tienen una barra diagonal que se agrega al comienzo de la línea.
Flujo de Excepción EL Flujo de Excepción ocu-rre fuera del Flujo Normal del Proceso y se basa en un Evento Intermedio que ocurre durante la ejecución del Proceso.
Flujo de Mensaje Un Flujo de Mensaje es usado para mostrar el flujo de mensajes entre dos enti-dades que están prepara-das para enviar y recibir di-chos mensajes. En BPMN, dos Pools separados en el Diagrama representan las dos entidades.
Asociación de Compensación
Representa una Asociación de Compensación fuera del Flujo Normal del Proceso y está basada sobre un even-to (un Evento Intermedio de Compensación) que es dis-parado a través de la falla de una Transacción o de un Evento de Compensar (un Evento Intermedio de Com-pensación). El destino de la asociación debe ser marca-do como una Actividad de Compensación.
Iteración BPMN provee dos mecanismos para iterar dentro de un Proceso (Ver las dos figuras siguientes en la tabla).
Actividad de Iteración
Los atributos de las Tareas y Sub-Procesos determinan si son repetidas o ejecuta-dos sólo una vez. Hay dos tipos de itera-ciones: Estándar y Multi-Instancia. Un indicador de iteración pequeño se des-pliega en el centro inferior de la actividad.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 137
Elemento Descripción Notación Flujo de Secuencia de Iteración
Pueden crearse Iteraciones conectando un Flujo de Secuencia a un objeto “con-tra corriente”. Un objeto es considerado contra corrien-te si tiene un Flujo de Secuencia saliente que lleva a unas series de otros Flujos de Secuencia, el último de los cuales es un Flujo de Secuencia entrante al objeto original.
Carlos H. Salgado 138
ANEXO 2. Métricas para el modelado de Procesos de Negocio
Rolón et al, en [77], proponen un conjunto de métricas para el modelado
de procesos de negocio con BPMN. Dichas métricas son clasificadas por los
autores en: (i) métricas bases, las cuales son definidas en función de los
distintos constructores que provee BPMN, y (ii) métricas derivadas, las cuales
son definidas como combinaciones de las métricas base.
A2.1. Métricas Base
En las Tablas A-2.1 a A-2.9 se muestran las métricas base
correspondientes a los distintos tipos de elementos provistos por BPMN como
Eventos, de flujo, Tareas, Carriles, etc.
Tabla A-2.1. Métricas Base definidas para el elemento Evento de inicio.
Elemento
Central Notación
Nombre
Métrica Métrica Base
Eventos
de Inicio
Inicio NSNE Número de Eventos de Inicio simple
Tiempo NSTE Número de eventos de Inicio de Tiempo
Mensaje NSMsE Número de Eventos de Inicio de Mensaje
Regla NSRE Número de Eventos de Inicio de Regla
Vínculo NSLE Número de Eventos de Inicio de Vínculo
Múltiple NSMuE Número de Eventos de Inicio Múltiple
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 139
Tabla A-2.2. Métricas Base definidas para el elemento Eventos intermedios.
Elemento
Central Notación
Nombre
Métrica Métrica Base
Eventos
Intermedios
Intermedio NINE Número de Eventos Intermedios simples
Tiempo NITE Núm. de Eventos Intermedios de Tiempo
Mensaje NIMsE Núm. de Eventos Intermedios de Mensaje
Error NIEE Número de Eventos Intermedios de Error
Cancelación NICaE Número de Eventos Intermedios de
Cancelación
Compensación NICoE
Núm. de Eventos Intermedios de
Compensación
Regla NIRE Número de Eventos Intermedios de Regla
Vínculo NILE Núm. de Eventos Intermedios de Vínculo
Múltiple NIMuE Núm. de Eventos Intermedios Múltiples
Tabla A-2.3. Métricas Base definidas para el elemento Eventos finales.
Elemento
Central Notación
Nombre
Métrica Métrica Base
Eventos
Finales
Final NENE Número de Eventos Finales Simples
Mensaje NEMsE Número de Eventos Finales de Mensaje
Error NEEE Número de Eventos Finales de Error
Cancelación NECaE Núm. de Eventos Finales de Cancelación
Compensación
NECoE Núm. de Eventos Finales de Compensación
Vínculo NELE Número de Eventos Finales de Vínculo
Múltiple NEMuE Número de Eventos Finales Múltiples
Terminación NETE Núm. de Eventos Finales de Terminación.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 140
Tabla A-2.4. Métricas Base para el elemento Actividad atómica (tareas).
Elemento
Central Notación
Nombre
Métrica Métrica Base
Tareas
Tarea NT Número de Tareas
Bucle NTL Número de Tareas de Bucle
Instancias
Múltiples
NTMI Número de Tareas de Instancia Múltiple
Compensación NTC Número de Tareas de Compensación
Tabla A-2.5. Métricas Base para el elemento Actividad compuesta (sub-proceso)
Elemento
Central Notación
Nombre
Métrica Métrica Base
Sub-
Procesos
Colapsados
Sub-Proceso
Colapsado
NCS Número de Sub-Procesos Colapsados
Bucle NCSL
Número de Sub-Procesos Colapsados de
Bucle
Instancia
Múltiple
NCSMI Número de Sub-Procesos Colapsados de
Instancia Múltiple
Compensación NCSC
Número de Sub-Procesos Colapsados de
Compensación
Ad-Hoc
NCSA Número de Sub-Procesos Colapsados Ad-
Hoc
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 141
Tabla A-2.6. Métricas Base para el elemento Nodos.
Elemento Central Notación Nombre
Métrica Métrica Base
Decisión
Exclusiva
Basada en Datos
(XOR)
NEDDB Número de Decisión/Unión Exclusiva
Basada en Datos
Decisión
Exclusiva
Basada en
Eventos (XOR)
NEDEB Número de Decisión/Unión Exclusiva
Basada en Eventos
Inclusiva (OR) NID Número de Decisión/Unión Inclusiva
Compleja NCD Número de Decisión/Unión Compleja
Paralela (AND) NPF Número de Bifurcaciones/uniones
Paralelas
Tabla A-2.7. Métricas Base para los Objetos de Conexión
Elemento
Central Notación
Nombre
Métrica Métrica Base
Flujo de
Secuencia
NSFA Número de Flujos de Secuencia
entre actividades
NSFE Número de Flujos de secuencia
procedente de un evento
NSFG
Número de Flujos de Secuencia
procedentes de un Nodo
decisión/unión
NSFL Número de Flujos de Secuencia
Bucle
Flujo de
Mensaje NMF Número de Flujos de Mensaje entre
participantes en el Proceso
ó
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 142
Tabla A-2.8. Métricas Base para los Carriles
Elemento
Central Notación
Nombre
Métrica Métrica Base
Participantes
NP Número de Participantes en el
Proceso
Carriles
NL Número de Carriles en el
Proceso
Tabla A-2.9. Métricas Base para los Artefactos.
Elemento
Central Notación
Nombre
Métrica Métrica Base
Objetos de
Datos
(Entradas) NDOIn
Número de Objetos de Datos de
entrada a actividades en el Proceso
Objetos de
Datos
(salidas) NDOOut
Número de Objetos de Datos de
Salida de actividades en el proceso.
A2.2. Métricas Derivadas.
Como lo plantean los autores de las métricas, “con la definición de todas
las métricas base es posible conocer el número de elementos significativos que
componen el diagrama de procesos de negocio. Y es a partir de las métricas
base que se ha definido un conjunto de métricas derivadas, con las cuales es
posible conocer las proporciones existentes entre los diferentes elementos del
modelo”.
Dichas métricas son:
• TNSE. Número Total de Eventos de Inicio del Modelo
TNSE = NSNE+NSTE+NSMsE+NSRE+NSLE+NSMuE
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 143
• TNIE. Número Total de Eventos Intermedios del modelo
TNIE = NINE+NITE+NIMsE+NIEE+NICaE+NICoE+NIRE+NILE+NIMuE
• TNEE. Número Total de Eventos Finales del Modelo
TNEE = NENE+NEMsE+NEEE+NECaE+NECoE+NELE+NEMuE+NETE
• TNT. Número Total de Tareas del Modelo
TNT = NT+NTL+NTMI+NTC
• TNCS Número Total de Sub-Procesos Colapsados del Modelo
TNCS = NCS+NCSL+NCSMI+NCSC+NCSA
• TNE Número Total de Eventos del Modelo
TNE = NTSE + NTIE + TNEE
• TNG Número Total de Decisiones/Uniones del Modelo
TNG = NEDDB+NEDEB+NID+NCD+NPF
• TNDO. Número Total de Objetos de Datos en el Modelo
TNDO = NDOIn + NDOOut
• CLA. Nivel de Conectividad entre Actividades
CLA = TNT
NSFA
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 144
• CLP. Nivel de Conectividad entre Participantes
CLP = NMF
NP
• PDOPIn. Proporción de Objetos de Datos como productos de entrada y el
total de Objetos de Datos.
PDOPIn = NDOIn
TNDO
• PDOPOut. Proporción de Objetos de Datos como productos de salida y el
total de Objetos de Datos.
PDOPOut = NDOOut
TNDO
• PDOTOut. Proporción de Objetos de Datos Producto resultante de las
Actividades del Modelo.
PDOTOut = NDOOut
TNT
• PLT. Proporción de Participantes y/o carriles y las actividades del Modelo
PLT = NL
TNT
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 145
Referencias Bibliográficas
[1] M. A. Rappa, "The utility business model and the future of computing
services," IBM Systems Journal, vol. 43, pp. 32-42, 2004. [2] J. Becker, M. Rosemann, and C. von Uthmann, "Guidelines of Business
Process Modeling," Business Process Management, Models, Techniques and Empirical Studies (BPM´00). Springer, pp. 30-49, 2000.
[3] V. Vitolins, "Business Process Measures," in Int. Conference on BALTIC DB&IS. Riga, Latvia., 2004, pp. 186-197.
[4] C. Dewalt, "Business Process Modeling with UML," Johns Hopkins University, 1999.
[5] T. Dufresne and J. Martin, "Process Modeling for e-Business," Spring 2003, INFS 770 - Methods for Informations Systems Engineering: Knowledge Management and E-Business. George Mason University, 2003.
[6] S. A. White, "Process Modeling Notations and Workflow Patterns," in Workflow Handbook 2004, L. Fischer, Ed., ed: Published in association with the Workflow Management Coalition (WfMC), 2004.
[7] FIPS, "Integration Definition for Function Modeling (IDEF0)," National Institute of Standards and Technology, StandardDecember 1993.
[8] R. J. Mayer, C. P. Menzel, M. K. Painter, P. S. de White, T. Blinn, and B. Perakath, "Information Integration for Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report," College Station, Texas, Interim Technical ReportSeptember 1995.
[9] H. E. Erickson and M. Penker, "Business Modeling with UML- Business Patterns at Work," ed. I. John Wiley & Sons. USA: Robert Ipsen., 2000.
[10] OMG, "OMG Unified Modeling Language (OMG UML), Infrastructure, version 2.2," Object Management GroupFebruary 2009.
[11] OMG, "Business Process Modeling Notation (BPMN)," BPMI - OMG. http://www.omg.org/spec/BPMN/1.22009.
[12] M. Piattini, F. Ó. Garcia Rubio, and I. Caballero, Calidad de Sistemas Informáticos: Alfaomega-RA-MA, 2007.
[13] Fenton, "Software Measurement: A Necessary Scientific Basis," IEEE Transactions on Software Engineering. 20(3), pp. 199-206, 1994.
[14] G. Lindland, G. Sindre, and A. Solvberg, "Undestanding Quality in Conceptual Modelling," IEEE Software 11(2), pp. 42-49, 1994.
[15] J. Krogstle, G. Lindland, and G. Sindre, "Toward a Deeper Understanding of Quality in Requirements Engineering," in 7th International Conference on Advanced Information Systems Engineering (CAISE), Jyvaskyla - Finlandia, 1995, pp. 82-95.
[16] L. Moody, G. Shanks, and P. Darke, "Improving the Quality of Entity Relationship Models - Experience in Research and Practice," in 17th International Conference on Conceptual Modelling, Singapure, 1998, pp. 255-276.
[17] R. Schuette and T. Rotthowe, "The Guidelines of Modeling - An Approach to Enhance the Quality in Information Models," in 17th International Conference on Conceptual Modelling, Singapure, 1998, pp. 240-254.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 146
[18] M. Genero, M. Piattini, A. Cruz-Lemus, and L. Reynoso, "Métricas Para Modelos UML," Novática Upgrade, pp. 61-65, julio-agosto 2004.
[19] ISO, "ISO Standard 9000-2000: Quality Management Systems: Fundamentals and Vocabulary, International Standards Organisation (ISO)." 2000.
[20] ISO/IEC, "ISO/IEC Standard 9126: Software Product Quality, International Standards Organisation (ISO), International Electrotechnical Commission (IEC)," 2001.
[21] A. Dasso, A. Funes, C. Salgado, and M. Peralta, "DBMS Evaluation Using Quantitative Methods," in VI Workshop de Investigadores en Ciencias de la Computación WICC'04, Neuquén, Argentina, 2004.
[22] N. Debnath, M. Peralta, C. Salgado, A. Funes, A. Dasso, D. Riesco, G. Montejano, and R. Uzal, "Web Programming Language Evaluation using LSP," Proceedings de CAINE03, Las Vegas, USA, 2003.
[23] A. Dasso, A. Funes, M. Peralta, and C. Salgado, "UML Tool Evaluation Requirements," ASIS 2005 - JAIIO 2005". Rosario (Santa Fé, Argentina). 2005.
[24] N. Debnath, C. Salgado, M. Peralta, D. Riesco, G. Montejano, and M. Berón, "MEBPCM: A Method for Evaluating Business Process Conceptual Models. A Study Case," in Ninth International Conference on Information Technology: New Generations (ITNG), Las Vegas, Nevada, USA, 2012.
[25] C. Salgado, M. Peralta, M. Berón, D. Riesco, and G. Montejano, "SLMPN: un Modelo para la Evaluación y Comparación de Lenguajes de Modelado de Procesos de Negocio," Proceedings of ASSE 2010 - 39 JAIIO 2010 - UADE, Buenos Aires, 2010.
[26] C. Salgado, M. Peralta, D. Riesco, G. Montejano, and M. Berón, "Evaluación de Modelos Conceptuales de Procesos de Negocio," in XIV Workshop de Investigadores en Ciencias de la Computación, WICC'12, Posadas, Misiones, Argentina, 2012.
[27] C. Salgado, M. Peralta, D. Riesco, M. Berón, and G. Montejano, "Modelado de Procesos de Negocio: Evaluación y Comparación de Modelos y Lenguajes de Modelado," in XIII Workshop de Investigadores en Ciencias de la Computación, WICC'2011, Rosario, Santa Fe, Argentina, 2011.
[28] N. Debnath, C. Salgado, M. Peralta, D. Riesco, M. Berón, and G. Montejano, "A Strategy Based on Lsp for the Evaluation of Specific Languages for Business Process Modeling," in 20th International Conference on Software Engineering and Data Engineering (SEDE 2011), Las Vegas - USA, 2011.
[29] N. Debnath, I. Lee, C. Salgado, M. Peralta, D. Riesco, M. Berón, G. Montejano, and L. Baigorria, "A strategy based on LSP for the evaluation of specific languages for business processes modeling," Journal of Computational Methods in Science and Engineering, vol. 12, pp. 147-160, 2012.
[30] N. Debnath, C. Salgado, M. Peralta, D. Riesco, and G. Montejano, "Optimization of the Business Process metrics definition according to the BPDM standard and its formal definition in OCL," in ACS/IEEE International Conference on Computer Systems and Applications - AICCSA 2010, Tunes, 2010.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 147
[31] C. Jiménez, L. Farías, and F. Pinto, "Análisis de Modelos de Procesos de Negocios en relación a la dimensión informática.," Revista Electrónica del DIICC. http://www.inf.udec.cl/revista/ediciones/edicion9/cjimenez.pdf, 2004.
[32] G. Sparks, "An Introduction to UML.," The Business Process Model. Sparx Systems, www.sparxsystems.com.au, 2000.
[33] Z. Irani, V. Hlupic, and G. M. Giaglis, "Business Process Re-Engineering: a Modeling Perspective," International Journal of Flexible Manufacturing Systems, pp. 99-104., 2001.
[34] WfMC, "Terminology & Glosary," Workflow Management Coalition. Document Number: WFMC-TC-1011. Document Status: Issue 3.0, 1999.
[35] R. Villarroel Acevedo, "Mejoramiento del Proceso de Gestión de Configuración de Software," 2004.
[36] J. Berrocal, J. M. García, and J. M. Murillo, "Hacia una gestión del proceso software dirigida por Procesos de Negocio," Quercus Software Engineering Group -Dept. de Ingeniería de Sistemas Informáticos y Telemáticos Universidad de Extremadura, Cáceres, España.
[37] F. Ruiz, "Tecnología para la Gestión de Procesos de Negocio," Universidad de Castilla-La Mancha-Escuela Superior de Informática, 2006.
[38] S. SOA agenda. Soluciones Java, y BPM, "Que es BPM, Que es BPMS," Journal of Computer Science and Information Management, Publication of the Association of management/International Association of Management, 2010.
[39] A. R. Rodríguez and L. García Ávila, "La Gestión de los Procesos de Negocio en las Empresas de Telecomunicaciones," Empresa de Telecomunicaciones de Cuba S. A ,Cuba - Universidad Central "Martha Abreu" de Las Villas Cuba, Santa Clara, Cuba, 2008.
[40] A. Sharp and P. McDermott, "Workflow Modeling: Tools for Process Improvement and Application Development.," London: Artech House, 2001.
[41] B. Mora, F. Ruiz, F. García, and M. Piattini, "Experiencia en transformación de modelos de procesos de negocios desde BPMN a XPDL.," IDEAS, 2007.
[42] A. R. Rodríguez, "Lenguajes, notaciones y herramientas para el modelado y análisis de procesos," http://www.gestiopolis.com/administracion-estrategia/lenguajes-notaciones-y-herramientas-en-analisis-de-procesos.htm, 2008.
[43] I. K. Knowledge Based Systems, "Integrated DEFinition Methods.," http://www.idef.com/Home.htm, 1999.
[44] H.-E. Eriksson and M. Penker, Business Modeling With UML: Business Patterns at Work, 1 ed.: John Wiley & Sons, Inc. New York, NY, USA, 1998.
[45] P. Kruchten, "The 4+1 View Model of Architecture," Piscataway, NJ: IEEE Software., 1995.
[46] D. Moody, "Theoretical and practical issues in evaluating the quality of conceptual models: current state and future directions," Data & Knowledge Engineering. Elsevier B.V., pp. 243–276, 2005.
[47] E. Rolon, F. Ruiz, F. Ó. Garcia Rubio, and M. Piattini, "Aplicación de Métricas Software en la Evaluación de Modelos de Procesos de
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 148
Negocio," Revista Electrónica de la Sociedad Chilena de Ciencia de la Computación, 2005.
[48] F. Ó. García Rubio, "FMESP: Marco de Trabajo Integrado para el Modelado y la Medición de los Procesos Software," Doctoral, Departamento de Informática, U.C.L.M. Universidad de Castilla La Mancha. España, Ciudad Real. España, 2004.
[49] H. Simon, The New Science of Management Decision. New York, 1960. [50] E. Martínez and M. Escudey, "Evaluación y Decisión Multicriterio -
reflexiones y experiencias," Editorial Universidad de Santiago/UNESCO, Santiago de Chile., 1998.
[51] R. Caballero and C. Romero, "Teoría de la Decisión Multicriterio: un Ejemplo de Revolución Científica Kuhniana," BEIO, Boletín de Estadística e Investigación Operativa, vol. 22 Nº 4, pp. 9-15, 2006.
[52] P. Jankowski and L. Richard, "Integration of GIS-based suitability analysis and multicriteria evaluation in a spatial decision support system for route selection.," Environment and Planning B, Vol. 21, No. 3, pp. 326–339, 1994.
[53] I. Heywood, J. Oliver, and S. Tomlinson, "Building an exploratory multi-criteria modelling environment for spatial decision support.," In P. Fisher (Ed.) Innovations in GIS 2, pp. 127–136, Taylor & Francis, London, UK., 1995.
[54] D. von Winterfeldt and W. Edwards, Decision Analysis and Behavioral Research. New York: Cambridge University Press, 1986.
[55] R. L. Keeney and H. Raiffa, "Decisions with Multiple Objectives: Preferences and Value Tradeoffs (2nd Edition)." Cambridge University Press, Cambridge., 1993.
[56] R. Janssen and P. Rietveld, "Multicriteria analysis and geographical information systems: an application to agricultural land use in the Netherlands.," In H.J. Scholten and J.C.H. Stillwell (Eds.) Geographical information systems for urban and regional planning, pp. 129–139, Kluwer Academic Publishers, Dordrecht, The Netherlands.
[57] T. L. Saaty, "The Analytic Hierarchy Process.," McGraw Hill, New York, USA., 1980.
[58] R. Banai, "Fuzziness in geographic information systems: contributions from the analytic hierarchy process," International Journal of Geographical Information Systems, Vol. 7, No. 4, pp. 315–329, 1993.
[59] A. Kangas, J. Kangas, and J. Pykäkäinen, "Outranking Methods As Tools in Strategic Natural Resources Planning.," Silva Fennica,Vol. 35, No. 2, pp. 215–227, 2001.
[60] R. Bernard, "Classement et choix en présence de points de vue multiples (la méthode ELECTRE)," la Revue d'Informatique et de Recherche Opérationelle (RIRO). vol. 8, pp. 57-75, 1968.
[61] J. Figueira and M. E. Salvatore Greco, "Multiple Criteria Decision Analysis: State of the Art Surveys.," New York, Springer Science + Business Media, Inc.. ISBN 0-387-23081-5, 2005.
[62] L. A. Zadeh, "Fuzzy Sets," Information and Control, vol. 8, pp. 338-353, 1965.
[63] J. P. Brans, "L’ingénièrie de la décision: élaboration d’instruments d’aide à la décision. La méthode PROMETHEE.," Presses de l’Université Laval., 1982.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 149
[64] J. P. Brans and P. Vincke, "A preference ranking organisation method: The PROMETHEE Method for MCDM," Management Science, pp. 647-656, 1985.
[65] J. P. Brans and B. Mareschal, "PROMETHEE V: MCDM problems with segmentations constraints," INFOR 30/2, pp. 85-96, 1992.
[66] J. J. Dujmovic, G. De Tré, and S. Dragicevic, "Comparison of Multicriteria Methods for Land-use Suitability Assessment," IFSA-EUSFLAT, 2009.
[67] J. J. Dujmovic, "Quantitative Methods for Software Evaluation," Lecture Notes, Graduate Software Engineering Program. Universidad Nacional de San Luis, San Luis, Argentina., 1998.
[68] J. J. Dujmovic, "A Method for Evaluation and Selection of Complex Hardware and Software Systems," The 22nd International Conference for the Resource Management and Performance Evaluation of Enterprise Computing Systems. CMG96 Proceedings, vol. 1, pp. 368-378, 1996.
[69] ISO/IEC, "ISO/IEC Standard 14598: Software Product Evaluation, International Standards Organisation (ISO), International Electrotechnical Commission (IEC)," 1999.
[70] M. Kirikova and J. Makna, "Renaissance of Business Process Modelling," in Information Systems Development. Advances in Theory, Practice, and Education, S. US, Ed., ed, 2005, pp. 403-414.
[71] S. Systems. Modelando Procesos de Negocios. [72] C. Robson, Real world research: A resource for social scientists and
practitioners-researchers: Blacwell, 1993. [73] M. Serrano, M. Piattini, C. Calero, M. Genero, and D. Miranda, "Un
método para la definición de métricas de software.," in 1er Workshop en Métodos de Investigación y Fundamentos filosóficos en Ingeniería del Software y Sistemas de Información (MIFISIS'2002),, 2002, pp. 65-74.
[74] S. Pflegeer, "Experimental design and analysis in software engineering part 1-5," ACM Sigsoft Software Engineering Notes,, vol. 19, pp. 16-20, 1994.
[75] B. P. Benegochea, J. A. de Diego, J. C. Adrián, M. Navasquillo, M. A. Melero, and G. de Miguel, Dirección de Marketing y Ventas vol. III: Edit. Cultural de Ediciones S.A, 1999.
[76] C. Salgado, M. Peralta, M. Berón, and G. Montejano, "Un Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio. Un Caso de Estudio," in ASSE - JAIIO 2012, Argentina, 2012.
[77] E. Rolon, F. Ó. Garcia Rubio, F. Ruiz, and M. Piattini, "Validating a Set of Measures for Business Process Models Usability and Maintainability," 2006.
[78] A. Dasso, A. Funes, M. Peralta, and C. Salgado, "Una Herramienta para la Evaluación de Sistemas," in Workshop de Investigadores en Ciencias de la Computación, WICC 2001, Universidad Nacional de San Luis, San Luis, Argentina, 2001.
[79] C. Salgado, M. Peralta, M. Berón, D. Riesco, G. Montejano, and L. Baigorria, "Aplicando MEMPN: un Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio en la Comparación de las Metodologías Ágiles para Desarrollo de Software," in ASSE - JAIIO 2013, Argentina, 2013.
[80] M. Yang, "Introduction to OpenUP," http://epf.eclipse.org/wikis/openup/, 2012.
MEMPN: Método para la Evaluación de Modelos Conceptuales de Procesos de Negocio
Carlos H. Salgado 150
[81] XP, "Extreme Programming: A gentle introduction," http://www.extremeprogramming.org/, 2012.
[82] J. Eaglesham, "Scrum Overview," http://epf.eclipse.org/wikis/scrum/, 2012.
[83] J. Highsmith, Agile Software Development Ecosystems, 2006.