Universidad Nacional de San Luis Tesis de Maestría en ...sel.unsl.edu.ar/lacis/tesis_grado/2013/Informe_Completo...Proyecto de Investigación: Ingeniería de Software: Aspectos de

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


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


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.


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


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.


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


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


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.


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



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



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.



• 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



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.



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.



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



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.



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



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



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



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,



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.


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



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



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.



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.



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



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.



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



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.



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.



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.



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.



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.



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



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.



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



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.


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



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



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.



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



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



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



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



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



(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



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 ×�� − �� + �� %�



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



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



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.



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



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




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.



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




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:



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.



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



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



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.



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



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.



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.



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



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)}



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



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.



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



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.



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.



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



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.



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



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



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



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



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.



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.



Figura 5.1. Modelo del Proceso Compras y Pagos de la Empresa



Figura 5.2. Modelo del Proceso Compras y Pagos Propuesto



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



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



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


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



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



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.


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



proceso m. Esta métrica es una adaptación de la métrica TNG propuesta en

[77].


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].


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.


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



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.


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.


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



Donde TNEE (m): Indica el número total de Eventos Finales en el modelo de

proceso m.


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].


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



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.



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].


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



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].


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



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





NPI(m1) = 5 NPI(m2) = 5

C4.1.1(m1) = 0,2 C4.1.1(m2) = 0,2


NMFI(m1) = 5 NMFI(m2) = 5

C4.1.2(m1) = 0,2 C4.1.2(m2) = 0,2

4.2. Externos


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) ≠



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



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



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



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.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.



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


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


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



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



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



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.



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.


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.



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.


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].


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



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.


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



Donde NPE (m) es el número de Participantes/Actores/Roles externos del

modelo analizado.



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].


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



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].


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



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



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


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



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.



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


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


Número de Participantes RFC-1 9


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



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.


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.



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



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



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.


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.


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



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.



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.



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.



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.



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.


través de un Proceso de Colaboración.




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



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



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



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.



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.



Tabla A-1.2. Conjunto de Elementos Centrales de DPN: Objetos de Conexió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


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.



Tabla A-1.4. Conjunto de Elementos Centrales de DPN: Artefactos


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.



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



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



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



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



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.



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).



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-



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.



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.


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



Tabla A-2.2. Métricas Base definidas para el elemento Eventos intermedios.

Elemento

Central Notación

Nombre


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


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.



Tabla A-2.4. Métricas Base para el elemento Actividad atómica (tareas).

Elemento

Central Notación

Nombre


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


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



Tabla A-2.6. Métricas Base para el elemento Nodos.

Elemento Central Notación Nombre


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


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

ó



Tabla A-2.8. Métricas Base para los Carriles

Elemento

Central Notación

Nombre


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


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



• 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



• 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



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.



[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.



[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



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.



[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.



[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.

Documents

Universidad Nacional de San Luis Tesis de Maestría en ...sel.unsl.edu.ar/lacis/tesis_grado/2013/Informe_Completo...Proyecto de Investigación: Ingeniería de Software: Aspectos de