0

Metodología de Gestión de los Procesos de Negocio

Sustentada en el uso de Patrones

Tesis Doctoral Presentada a la

Universidad Central de Venezuela

Por

M. Sc. Pedro Nolasco Bonillo Ramos

Como requisito parcial para optar al título de

DOCTOR EN CIENCIAS DE LA COMPUTACIÓN

Tutora

Dra. Nancy Zambrano

Mayo, 2008

Universidad Central de Venezuela Facultad de Ciencias

Escuela de Computación Postgrado en Ciencias de la Computación

i

Prolegómenos

Dedicatoria

A mi Creador, Hermano y Fuego de mi Espíritu, por habitar cada día en mi corazón,

fortaleciéndolo con sus dones y acrecentándolo con su sabiduría.

A mi guía Espiritual, mi Amor y Compañía. Virgen María, tus oraciones y

bendiciones día a día en mi corazón.

A mi Madre, Amiga incondicional, Instrumento divino de Dios en la formación de

mi vida, a ti Lourdes, a quien dedico especialmente mi trabajo con gran honor y especial

aprecio.

A Doris mi Esposa, Amiga, Compañera, Confidente. Por tu apoyo, paciencia,

fortaleza y comprensión.

A Francelis, Doris Daniela y Pedro Jesús mis Hijos, Por ser mis fuentes de orgullo e

impulso en la vida, todo mi amor es de ustedes hijos, todo lo que soy y hago.

ii

Agradecimiento

Agradezco con todo mi corazón a mi Madre, quien con sacrificios y esperanzas ha

logrado hacer de mí un Hombre Sabio. Lourdes, te amo, este triunfo es realmente tuyo, te lo

agradeceré toda mi vida.

Agradezco a todos mis Docentes y Formadores. En especial a la Profesora Nancy

Zambrano, por su apoyo y Fe.

Agradezco a mi tutora por su dedicación, empeño y amistad en la realización de este

trabajo, Gracias Profesora Nancy Zambrano.

iii

Resumen

El principal objetivo de este trabajo de tesis doctoral es formular una propuesta metodológica que permita la gerencia de los procesos del negocio (BPM), sustentada en el uso de patrones. En este trabajo se propone una taxonomía de patrones y su representación a través de una arquitectura de procesos, componentes y aplicaciones en el dominio BPM. Además se extiende la especificación de los patrones propuesta por Acosta y Zambrano en el 2004, obteniendo un nuevo meta-patrón acorde con la taxonomía, con elementos que permiten medir la calidad de los patrones en el proceso y el producto de software, a través del uso de Estilos de Arquitectura Basados en Atributos (ABAS) y los modelos de calidad ISO14-598 e ISO-9126. Tomando en cuenta esta combinación de métodos, herramientas y técnicas, se propone un conjunto de pasos que en el ámbito de BPM, permiten identificar los procesos claves, modelarlos y analizarlos, simularlos, implantarlos de forma asistida (tanto los nuevos procesos como sus versiones), evaluarlos, monitorearlos y mejorarlos. Con la finalidad de poner en practica la metodología se presenta un caso de estudio con el proceso de Gestión de Versiones de la Librería de Infraestructura de Tecnología de la Información (ITIL). Palabras Claves: Ingenieria de Software, Taxonomia de Patrones, BPM, Metodología BPM, Proceso de Gestión de Versiones, ITIL.

Abstract The main objective of this work is to propose a methodology that allow the Business Processes Management (BPM), based in the use of patterns. This Work propose a taxonomy of patterns and its representation through of an architecture of processes, components, and applications in the BPM scope. In addition, it opens out the pattern especifications propose for Acosta and Zambrano in 2004, obtain a new meta-pattern according with taxonomy, with elements that permit measurement that quality of patterns in the proccess and product of software, through of Attribute-Based into Architectural Styles (ABAS) and quality models ISO14-598 and ISO-9126. Considering this combination from methods, tools and techniques, its propose a whole of steps that in the BPM scope, allows identify the key processes, model and analyze, simulate, implant in a assisted way (such as new processes as their versions); evaluate, monitore them and improve. With the purpose of verify in practices the methodology show a case of study with the Release Management process of Library Infrastructure Technology Information (ITIL).

Keywords: Software Engineer, Pattern Taxonomy, BPM, BPM Methodology, Release Management Process, ITIL.

iv

Índice Prolegómenos ....................................................................................................................................................... i 

Dedicatoria ..................................................................................................................................................... i Agradecimiento ............................................................................................................................................. ii 

Resumen ............................................................................................................................................................. iii Índice.................................................................................................................................................................. iv 

Índice Tablas.................................................................................................................................................. v Índice Figuras ................................................................................................................................................ v 

Introducción ........................................................................................................................................................ 1 Capítulo I El Problema ........................................................................................................................................ 4 

1.1 Contexto .................................................................................................................................................. 4 1.2 Formulación del Problema....................................................................................................................... 9 

1.2.1 El Problema .................................................................................................................................. 9 1.2.2 Manifestaciones del Problema.....................................................................................................10 1.2.3 Evidencias del Problema .............................................................................................................11 

1.3 Objetivos.................................................................................................................................................12 1.3.1 Objetivo General .........................................................................................................................12 1.3.2 Objetivos Específicos ..................................................................................................................12 

1.4 Justificación ............................................................................................................................................13 1.5 Delimitación ...........................................................................................................................................14 1.6 Limitaciones ...........................................................................................................................................14 

Capítulo II Marco Teórico..................................................................................................................................15 2.1 Antecedentes de la Investigación............................................................................................................15 2.2 Bases Teóricas ........................................................................................................................................18 

2.2.1 Procesos de Desarrollo ................................................................................................................19 2.2.2 Construcción de Software Basado en Componentes ...................................................................20 2.2.3 Taxonomías de Patrones..............................................................................................................22 2.2.4 Gerencia de los Procesos del Negocio.........................................................................................26 2.2.5 Relación entre el Uso de patrones y BPM...................................................................................32 2.2.6 Librería de Tecnología de la Información (ITIL) ........................................................................33 

Capítulo III Metodología....................................................................................................................................37 3.1 Tipo de Investigación .............................................................................................................................37 3.2 Diseño de Investigación..........................................................................................................................37 3.3 Población y Muestra ...............................................................................................................................38 3.4 Técnicas e Instrumentos de Recolección de Datos .................................................................................39 3.5 Procedimiento de Análisis de Datos .......................................................................................................40 3.6 Metodología a utilizar en función de los objetivos específicos de la investigación (SESL)...................41 

3.6.1. Determinar la naturaleza del sistema..........................................................................................42 3.6.2. Decidir el tipo de evaluación ......................................................................................................42 3.6.3. Identificar los individuos (Stakeholder) que afectan el sistema .................................................43 3.6.4. Estudiar y Analizar: Preguntas Claves .......................................................................................43 3.6.5. Retroalimentación de los resultados ...........................................................................................43 

Capítulo IV Formulación de la Metodología de Gerencia de Procesos de Negocio Sustentada en el Uso de Patrones ..............................................................................................................................................................44 

4.1. Naturaleza del Sistema ..........................................................................................................................44 4.1.1 Entidades .....................................................................................................................................45 4.1.2 Relaciones ...................................................................................................................................47 4.1.3 Ambiente .....................................................................................................................................47 4.1.4 Objetivos .....................................................................................................................................48 4.1.5 Características .............................................................................................................................50 4.1.6 Principios.....................................................................................................................................51 4.1.7 Sub-Sistema de Control ...............................................................................................................51 

v

4.2 Tipo de Evaluación .................................................................................................................................52 4.3 Stakeholders............................................................................................................................................53 4.4 Preguntas Claves.....................................................................................................................................54 4.5 Diseño de la Metodología de Gerencia de Procesos de Negocio Sustentada en el Uso de Patrones ......54 4.6. Retroalimentación..................................................................................................................................64 4.7. Propuesta de Automatización de la Metodología ..................................................................................65 

Capítulo V Caso de Estudio ...............................................................................................................................86 5.1. Crear Proceso.........................................................................................................................................86 5.1.1 Analizar...............................................................................................................................................86 5.1.1 Diseñar Proceso...................................................................................................................................89 5.1.3 Modelar................................................................................................................................................91 5.1.4 Configurar............................................................................................................................................93 

Capítulo VI Conclusiones y Recomendaciones..................................................................................................95 Referencias Bibliográficas................................................................................................................................100 Anexo 1 Descripción Taxonomía de Patrones..................................................................................................103 

A1.1 Patrón de Análisis. .............................................................................................................................103 A1.2 Patrón Arquitectural...........................................................................................................................105 A1.3 Patrones de Diseño.............................................................................................................................107 A1.4 Patrón de Interacción .........................................................................................................................112 A1.5 Patrón de Flujo de Trabajo.................................................................................................................113 

Anexo 2 Formato de Solicitud de Requerimiento ............................................................................................122 Anexo 3 Cartelera de Actividades Propuestas..................................................................................................124 Anexo 4 Escenario Proceso de Gestión de Versiones ITIL en base al Patrón de Análisis de Producción .......125 Anexo 5 Artículos Arbitrados Publicados ........................................................................................................127 

Índice Tablas

Tabla 1 Fases del Proceso versus Objetivos de la Construcción de Software Basado en Componentes. (Gamma et al., 1995) .........................................................................................................................................21 Tabla 2 Metapatrón adaptado de Acosta, Zambrano (2004) y Kazman, Klein (2004) ......................................26 Tabla 3 Caso de uso General Prototipo BPMS Metodología Gerencia de Procesos de Negocio Sustentada en el Uso de Patrones. ............................................................................................................................................67 Tabla 4 Caso de Uso Administrador Modelo ....................................................................................................70 Tabla 5 Caso de Uso Administrador Patrones...................................................................................................76 Tabla 6 Caso de Uso Administrador Interfaz ....................................................................................................78 Tabla 7 Caso de Uso Administrador de Tareas .................................................................................................79 Tabla 8 Caso de Uso Administrador de Eventos Tarea .....................................................................................81 Tabla 9 Caso de Uso Administrador de Identidad.............................................................................................83 Tabla 10 Caso de Uso Administrador de Estado Transición .............................................................................85 Tabla 11 Relación Procesos ITIL con el Mapa de Procesos ETOM. Adaptado de TMF ..................................88 

Índice Figuras

Figura 1: Tecnologías relacionadas en el Desarrollo OO Actual. (Tepfenhart et al., 1997)..............................16 Figura 2. Diferentes tipos de Patrones y su Relación ........................................................................................24 Figura 3. Relación entre las bases teóricas ........................................................................................................25 Figura 4: La evolución de EAI/BPM. (Vollmer et al., 2004) ............................................................................27 Figura 5: Arquitectura BPM. (Vollmer et al., 2004) .........................................................................................28 Figura 6: estándares BPM según BPMI ............................................................................................................30 Figura 7: Marco Referencial para BPM sustentada en el uso de Patrones. (Bonillo, 2005) ..............................32 Figura 8: Organización de Soporte Interno en términos de Sistemas. ...............................................................48 Figura 9: Sistema de Control de la Organización de Soporte Interna................................................................52

vi

Figura 10: Estructura de la Metodología de Gerencia de Procesos Sustentada en el Uso de Patrones “Process Management”. ...................................................................................................................................................54 Figura 11: Sub-Proceso Analizar de la Metodología Gerencia de Procesos......................................................55 Figura 12: Sub-Proceso Analizar de la Metodología Gerencia de Procesos (continuación). ............................55 Figura 13: Sub-Proceso Analizar de la Metodología Gerencia de Procesos (continuación). ............................56 Figura 14: Sub-Proceso Diseñar de la Metodología Gerencia de Procesos. ......................................................57 Figura 15: Sub-Proceso Modelar de la Metodología Gerencia de Procesos (continuación)..............................58 Figura 16: Sub-Proceso Configurar de la Metodología Gerencia de Procesos..................................................59 Figura 17: Sub-Proceso.Configurar de la Metodología Gerencia de Procesos (continuación)..........................60 Figura 18: Sub-Proceso Mantenimiento de la Metodología Gerencia de Procesos. ..........................................61 Figura 19: Sub-Proceso Mantener Configuraciones de la Metodología Gerencia de Procesos (continuación).62 Figura 20: Sub-Proceso Mantener Configuraciones de la Metodología Gerencia de Proceso (mantenimiento de plataforma). .......................................................................................................................................................62 Figura 21: Sub-Proceso Monitorear de la Metodología Gerencia de Procesos. ................................................63 Figura 22. Caso de uso General Prototipo BPMS Metodología Gerencia de Procesos de Negocio Sustentada en el Uso de Patrones. .......................................................................................................................................66 Figura 23. Caso de uso Administrador Modelo.................................................................................................68 Figura 24 Caso de uso Administrador Patrones. ...............................................................................................70 Figura 25 Caso de uso Administrador Interfaz..................................................................................................76 Figura 26 Caso de uso Administrador de Tareas...............................................................................................78 Figura 27 Caso de uso Administrador de Eventos Tarea...................................................................................80 Figura 28 Caso de uso Administrador de Identidad. .........................................................................................82 Figura 29 Caso de uso Administrador de Estado Transición.............................................................................84

1

Introducción

“El ambiente de los negocios ha empezado a ser más y más turbulento que en

las décadas pasadas, la tecnología de la información comienza a ser un

riesgo, un impedimento para el motor del progreso.” (Shael, 1999)

Las empresas actuales requieren de modelos de negocios complejos con una estructura organizacional, procesos y sistemas que deben ser diseñados explícitamente. El trabajo de diseñar estos modelos de negocio es claramente interdisciplinario, ya que requiere conocimientos de desarrollo del negocio, los diferentes procesos que ocurren en la empresa y de la gerencia de los procesos y las aplicaciones tecnológicas.

En el ámbito de la ingeniería de software sería conveniente poder contar con un sistema de métodos, herramientas y técnicas que permitan reutilizar las mejores prácticas, hacer seguimiento sobre la combinación de estas mejores prácticas y medir la calidad del proceso y producto de software que se obtiene, según cada uno de los procesos que se implementen en cada dominio.

En base a esto, el propósito de este trabajo es Diseñar e Implementar una metodología que permita la gestión de los procesos de negocio, sustentada en el uso de patrones.

Este trabajo se fundamenta en las siguiente líneas de investigación del área de Ingeniería de Software: Metodologías orientadas a objeto de desarrollo de software, Modelos, Métodos, Técnicas y Herramientas de desarrollo de software, Interacción Humano Computador, Patrones de diseño, Componentes y reutilización de software, Desarrollo de aplicaciones basadas en Internet, Arquitectura de software, Calidad de software e Ingeniería orientada a modelos.

La gerencia de los procesos del negocio y el uso de patrones en la ingeniería de software son ambos, problemas de vieja data, en este trabajo, se trata de estudiarlos según las nuevas tecnologías, considerando las potencialidades de un modelo que incluya componentes reutilizables.

En el ámbito de los procesos de negocio, la solución tecnológica por excelencia se refiere al término Flujo de Trabajo o “workflow”, que es el proceso a través del cual las tareas de los individuos son coordinadas para completar una transacción (usando los procesos del negocio definidos) dentro de una organización. El “workflow” es un conjunto de mecanismos que automatizan los procesos de trabajo. Estos mecanismos relacionan entre sí los aspectos de la administración, establecen prioridades entre las diversas tareas de cada empleado y optimizan las comunicaciones entre las distintas unidades operativas.

Para que eso se logre es necesario definir cuáles son las distintas tareas que se realizan en una organización; quiénes participan en su ejecución; quiénes son responsables de las

2

mismas; cuál es la secuencia de procesos de cada tarea y cuáles son las acciones que inician cada proceso.

Aunque la contribución de los Flujos de Trabajo tradicionales modelados por la WFMC (Workflow Management Coalition), es aún notable, hay una nueva generación que quizás sea un híbrido que reúne lo mejor de todos los sistemas de “workflow” y otras tecnologías: los Sistemas de Gerencia de Procesos de Negocio (BPMS).

Los BMPS incorporan amplias capacidades de integración con modernas arquitecturas Java, .Net y XML. Adicionalmente, suman otras tecnologías como Web Services, Motores de Reglas de Negocio y de Monitoreo de las Actividades del Negocio (BAM). De acuerdo con Howard Smith y Peter Fingar (2003), avalados por la BPMI (Business Process Management Initiative) y la WFMC, hoy en día se puede afirmar que “los BPMS permiten a las empresas modelar, implementar y gestionar los procesos de negocio, que abarcan múltiples aplicaciones empresariales, departamentos, y proveedores, pero sin un marco referencial integrado”.

Los BPMS han evolucionado desde la integración de arquitecturas de negocio, donde se contempla la transformación y enrutamientos de los datos, administración de eventos, automatización de procesos y el uso de adaptadores en los años 90; a la integración en el 2000 de los procesos de negocio a través del modelaje básico de los procesos, la gerencia de los proveedores, conectividad entre empresas a través del comercio electrónico y formación de ciertas plantillas de procesos para industrias verticales; hasta llegar al concepto que actualmente se maneja (a partir del 2004) que involucra: aplicaciones de flujo de trabajo, modelaje sofisticado de procesos, monitoreo de las actividades asociadas a los procesos de negocio (Bussines Activity Monitoring, BAM por sus siglas en inglés), exposición de las funcionalidades de las aplicaciones a través de servicios web, utilización de manejadores de reglas de negocio, soporte a múltiples dispositivos de acceso a la información en cualquier lugar y desde cualquier posición (“aware-contex”) a través del uso de portales, utilización de herramientas para la gerencia del ciclo de vida del desarrollo asistido de las aplicaciones de software que apoyan los procesos, soporte móvil de los procesos y las interfaces, extracción, transformación y carga de datos que son utilizados por los procesos y la capacidad de simulación sobre los procesos y versionamiento de los mismos (optimización de procesos Bussines Process Optimization, por sus siglas en inglés BPO).

A pesar de todas las características antes mencionadas, los BPMS adolecen de un marco referencial global e integral que establezca metodológicamente su implementación y utilización. En lo que respecta a su implementación, la mayoría de los patrones de software no están soportados de forma precisa. El mercado de las arquitecturas de BPM tiende a concentrarse en flujos de sistema a sistema y está emergiendo lentamente en cuanto al flujo humano-humano asistido por el computador. Con base en lo anterior, BPMI es la organización que asume la elaboración de los estándares (BPA, BPMN y BPMS; análisis, notación y semántica respectivamente) que sustentan el concepto de BPM enfocándose

3

sobre el proceso del negocio como el punto de partida entre el ambiente del mismo y su puesta en práctica a través de la tecnología. Actualmente “workflow” Management Coalition se está unificando con el BPMI.

Con la finalidad de alcanzar el objetivo planteado, este documento se estructura de la siguiente manera:

En el Capítulo I, El Problema, se inicia con la contextualización en espacio y tiempo del problema de investigación, sus manifestaciones y evidencias, luego se presentan los objetivos, la justificación, delimitación y las limitaciones.

En el Capítulo II, Marco Teórico, se establece a partir de estudios anteriores, cómo se han utilizado los procesos de desarrollo de software actuales y su relación con la construcción de software basado en componentes, se especifica la necesidad de utilizar las mejores practicas en cada dominio a través de una taxonomía de patrones y sus relaciones, se estudia teóricamente el “sistema social de la gerencia de los procesos de negocio” ignorando el hecho que la tecnología cambia la estructura organizacional y la cultura, enfocándose en el estudio inicial del sistema social o técnico. Definiendo a partir de la investigación documental y bibliográfica el estudio de la naturaleza del sistema abordando los temas de patrones de software, necesidad de medir la calidad de los patrones de software en el proceso de construcción de software y la relación entre el uso de patrones, ITIL y el dominio de estudio BPM específicamente en lo relativo al caso de estudio (procesos de Gestión de Versiones).

En el Capítulo III, Metodología, se describen las unidades de análisis, o de investigación, las técnicas de observación y recolección de datos, los instrumentos, los procedimientos y las técnicas de análisis de la instanciación de la metodología Systemic Evaluation for Stakeholder Learning (SESL) que es utilizada para llevar a cabo la presente investigación.

En el Capítulo IV, Formulación de la Metodología de Gerencia de Procesos de Negocio sustentada en el Uso de Patrones, se realiza la formulación de la metodología, tomando en cuenta los elementos referentes al dominio del caso de estudio BPM y los instrumentos metodológicos utilizados.

En el Capítulo V, Caso de Estudio, se detallan los pasos utilizados en la aplicación de la metodología al caso de estudio del proceso de Gestión de Versiones de ITIL, se exponen los detalles del modelado de los procesos, su puesta en producción y la evaluación y mejora de los mismos.

Finalmente en el Capítulo VI, Conclusiones y Recomendaciones, se detallan las conclusiones y recomendaciones que se obtienen de la aplicación de la metodología al caso de estudio, y de los resultados finales.

A continuación se inicia con el planteamiento del objeto de estudio o contexto.

4

Capítulo I El Problema

Para iniciar este capitulo a continuación se describe, en espacio y tiempo el contexto en el cual esta inmersa la investigación doctoral, para luego formular el problema, describir sus manifestaciones y evidencias, formular el objetivo general y los objetivos específicos, describir la justificación de la investigación su delimitación y sus limitaciones.

1.1 Contexto

La nueva economía, denominada “digital” e inteligencia en red por Tapscott (1998), se mueve en un mundo cada vez más volátil, global y competitivo, en las últimas décadas se puede apreciar cómo han surgido distintas modas gerenciales para afrontar los problemas de las organizaciones en función de sus entornos (interno/externo), pero fundamentalmente en pro de mejorar el manejo de la información, la cual cada día es, en todas sus formas, más gestionada a través de Internet y en las propias redes internas de las organizaciones. (Bonillo, 2005d).

Las empresas actuales, requieren de modelos de negocios complejos con una estructura organizacional, procesos y sistemas que deben ser diseñados explícitamente, incluyendo: (1) Diseño del modelo de negocio: estructura del negocio y diseño del producto y el valor agregado –en relación a soluciones tradicionales- que éste aportará, estrategia de captura de mercado y distribución; (2) Diseño del sitio Web a través del cual se canalizará la oferta; (3) Diseño de los procesos de negocios -procesamiento de pedidos, generación del producto o servicio, logística, etc. –que implementen la oferta, a través de una cierta estructura y funcionamiento organizacional; (4) Diseño de los sistemas computacionales que manejen las transacciones que se capturan del sitio, mantienen las bases de datos (clientes, productos, contable/financieras) necesarias para procesar eficientemente tales transacciones y automatizar/apoyar con información apropiada los procesos mencionados en el punto tres (Barros, 2002).

El trabajo de diseñar estos modelos de negocio es claramente interdisciplinario, ya que requiere conocimientos de: desarrollo de negocios, los diferentes procesos que ocurren en la empresa, las Tecnologías de la Información y la Comunicación (TIC), diseño organizacional, manejo de recursos humanos, habilidades de innovación entre otros. Por lo tanto, sería difícil que una sola persona pudiera tener todo el conocimiento y formación para hacer tal trabajo.

Esto genera la necesidad de trabajar con equipos de diseño en los cuales se encuentren los talentos enunciados. Sin embargo, los profesionales que puedan facilitar el trabajo de un equipo de este tipo deben tener conocimientos profundos de una metodología de diseño que oriente todo el trabajo y conocimientos apropiados en todos los otros temas que son relevantes. Lo anterior confirma la necesidad y conveniencia de realizar diseños explícitos

5

de los negocios en base a los procesos, sus prácticas de gestión y a las TIC disponible, es decir realizar una Ingeniería de Negocio (Barros, 2002).

Los cambios producidos en las organizaciones para lograr esta adaptación han sido acciones continuas y rápidas, a través del desarrollo de nuevas interrelaciones entre las TIC, con base en los casos de éxito surgidos en cada uno de los dominios específicos. A partir de la década de los ochenta se presenta en las ciencias de la computación un cambio de paradigma hacia la computación centrada en red, surgiendo un conjunto de técnicas, en la Ingeniería de Software, que enfocan al software como un producto de ingeniería que debe definir, crear y aplicar: (1) una metodología bien definida dirigida a un ciclo de vida de planeamiento, desarrollo, y mantenimiento; (2) un conjunto establecido de componentes de software que documenta cada paso en el ciclo de vida y muestra un seguimiento, y (3) un conjunto de hitos predecibles que pueden ser revisados a intervalos regulares a través del ciclo de vida del software. (Pressman, 1997).

La Ingeniería de Software ha evolucionado en todas sus áreas: análisis de requisitos, procesos de desarrollo de software, interacción humano-humano asistida por el computador, estrategias de implementación, modelos de costos, etc. Sin embargo, aún está por debajo de las necesidades de calidad demandadas por las organizaciones y los sistemas cada vez más complejos; además estos esfuerzos han surgido de forma independiente y no se integran (en muchos casos se oponen y se complementan a la vez, pretendiendo crear el software desde varias perspectivas al mismo tiempo), demostrando así la ausencia de un marco referencial que las una y que facilite el seguimiento y la evaluación necesaria para garantizar su eficacia, desde una perspectiva integral.

En este contexto, existen considerables esfuerzos de investigación y desarrollo con el objetivo de perfeccionar el proceso de producción de software unificado, tanto a través de estudios teóricos, como de estudios aplicados.

La construcción de aplicaciones ha sido siempre una tarea compleja, pero esta complejidad, lejos de reducirse, es cada vez mayor: la aparición de nuevos y sofisticados dispositivos periféricos, la computación sin cable, los grupos de usuarios cada vez más heterogéneos y exigentes, la velocidad con que se deben construir los productos debido a la competencia y exigencias del mercado; son todos factores que conllevan a la necesidad de definir nuevos métodos o adaptaciones de métodos existentes (reflexión sobre los métodos hasta lograr una metodología), a fin de abordar de manera integrada, clara y precisa la construcción de software centrado en los usuarios.

En muchos casos la complejidad tecnológica provoca que el ingeniero de software dedique un mayor esfuerzo a conocer aspectos técnicos, que a entender el problema que debe resolver el software a desarrollar. Una de las tareas críticas en la Ingeniería del Software y que tiene una mayor repercusión sobre la productividad y la calidad final del software es el modelado conceptual. (Bonillo, 2004b)

Estudios relacionados con la construcción de software en ambientes Cliente/Servidor y Orientados a Objetos sostienen la tesis de que las tareas más críticas siguen estando en la

6

especificación y en el análisis de requisitos, y que los errores introducidos en esta etapa del proceso de producción de software pueden tener un impacto considerable en la fiabilidad, el costo y la seguridad del sistema, de tal forma que se evidencia la necesidad de herramientas de desarrollo que proporcionen construcciones de alto nivel que permitan especificar sistemas, usando conceptos próximos al espacio del problema y no al de la solución.

La falta de rigor que presentan los métodos y entornos actuales en la definición de los elementos de modelado dificultan la obtención de software que sea funcionalmente equivalente a la descripción capturada en el esquema conceptual.

Si se analizan los métodos de desarrollo más utilizados en la industria del software, se puede observar que muchas veces el esfuerzo invertido en la realización de algunas tareas (como puede ser el modelado conceptual) y en la producción de documentación, no tiene ningún reflejo directo en el producto final.

Estos problemas invitan a replantearse la forma de abordar los procesos de desarrollo de software. Estos procesos necesitan métodos y herramientas que: (1) aborden el proceso de desarrollo con rigor y de forma sistémica, proporcionando los modelos y las etapas exclusivamente necesarias para la producción de software; (2) se centren en la especificación precisa del espacio del problema; (3) ayuden al analista a tomar decisiones en el proceso de modelado conceptual; (4) faciliten la generación asistida de código tanto de estructura como de comportamiento a partir de esquemas conceptuales; (5) ofrezcan independencia tecnológica, ocultando la tecnología subyacente a los desarrolladores; y (6) produzcan software de calidad funcionalmente equivalente a su especificación.

El paradigma de la orientación a objetos promulga desde sus inicios una orientación hacia el modelado de estándares conceptuales expresivos, con una semántica bien definida basada en un modelo formal. Actualmente la orientación a objetos (y en general la mayoría de métodos de modelado orientado a objetos –OO-) carece de guías precisas que ayuden al analista en la etapa de modelado a detectar los estándares que están presentes en el esquema conceptual del sistema (Douglas et al., 1996).

Uno de los esfuerzos asociados al tratamiento de este problema es presentado en noviembre de 2000, cuando el OMG (Object Management Group) hizo pública la iniciativa MDA (Model Driven Architecture), una variante de una nueva tendencia extendida por todo el mundo denominada Ingeniería de Modelos. Las ideas básicas de la ingeniería de modelos están relacionadas con otras propuestas como la programación generativa, lenguajes para dominios concretos, computación integrada con modelos, factorías de software, etc.

MDA puede definirse como la consecución de los principios de la Ingeniería de Modelos haciendo uso de un conjunto de estándares del OMG como MOF (Meta Object Facility), XMI (XML Metadata Interchange), OCL (Object Constraint Languaje), UML (Unified Modeling Languaje), CWM (Commond Warehouse Metamodel), SPEM (Software Process Engineering Metamodel), etc.

7

De un modo similar a cómo el principio básico “todo es un objeto” resultó fundamental para establecer la tecnología orientada a objetos durante la década de los 80, MDA en la actualidad se concentra en los modelos, sin embargo esta iniciativa aun no ha producido los resultados esperados.

Los métodos de desarrollo han proliferado pero lo único que proporciona la mayoría son lenguajes para describir esquemas conceptuales y diseños; además de esto, deberían proporcionar diseños prácticos y efectivos. Una alternativa para esto es la utilización de los patrones de software, los patrones de software han surgido y evolucionado a partir de varias iniciativas: la de Kent Beck y Ward Cunningham, dos de los pioneros de Smalltalk, también a partir de las ideas de Christopher Alexander, que desarrolló una teoría y una colección de patrones para el mundo de la arquitectura urbanística (Alexander et al., 1977), y de las ideas de Peter Coad (Coad et al., 1999) en las cuales presenta distintos patrones de análisis y diseño como una serie de relaciones entre elementos (dos o tres) de bajo nivel (clases).

Bruce Anderson lideró talleres en OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) a principios de los 90 en los cuales se investigó y se desarrolló un libro sobre arquitecturas software. Jim Coplien en su libro (Coplien et al., 1995) describió modismos útiles en C++. Basados en la mayoría de estos trabajos se constituyó el grupo de Hillside para investigar estas ideas en un futuro. El empuje más grande para su conocimiento público fue la publicación del libro Design Patterns, Elements of Reusable Object-Oriented Software (Gamma et al., 1995) de la banda o grupo de los cuatro “Gand or Group of Four” (GoF), y la conferencia PLoP (Pattern Language of Programming) que inició en 1994 el grupo de Hillside.

Todavía existen discrepancias entre los investigadores a la hora de definir qué es un patrón, por lo que es bastante difícil encontrar definiciones de patrón que sean idénticas. En el libro de Fowler (1997) se encuentra una definición genérica interesante: “Un patrón es una idea que ha sido utilizada en un contexto práctico y que probablemente será útil en otros”. El término idea expresa que un patrón puede ser cualquier “cosa”. La expresión contexto práctico refleja el hecho de que se desarrollan (algunos autores prefieren: descubren) gracias a la experiencia práctica en proyectos reales.

Por otro lado, los patrones de software no son más que un conjunto de soluciones a problemas habituales en el diseño de software orientado a objetos. Una definición más formal podría ser: “Un patrón es una solución a un problema, aceptada como correcta, a la que se ha dado un nombre y que puede ser aplicada en otros contextos”.

El concepto de patrón en la ingeniería de software, desde sus inicios fue planteado de forma general para todas las disciplinas, sin embargo inicialmente surgieron como patrones de diseño (patrones de un nivel de abstracción menor y están por lo tanto más próximos a lo que sería el código fuente final), pero actualmente los patrones constituyen un concepto más general, representando estructuras conceptuales aplicables durante las fases de análisis, diseño, construcción de la interfaz de usuario e implantación.

8

La aplicación de patrones a los métodos de desarrollo de software aporta beneficios interesantes ya que, entre otras muchas aplicaciones, permiten: (1) definir guías de modelado mediante lenguajes de patrones (Coplien et al., 1995); (2) estructurar el proceso de generación asistida de código, y; (3) ofrecer soluciones reutilizables y probadas, que sean lo suficientemente abstractas cómo para ser utilizadas en cualquier lenguaje de programación.

La utilización de patrones en las nuevas tecnologías está evolucionando a pasos agigantados gracias a los estándares y las aplicaciones surgidas en estos últimos años. Aunque la contribución de las aplicaciones tradicionales de flujo de trabajo, “ad hoc”, administrativos y colaborativos, es aún notable, hay una nueva generación que quizás sea un híbrido que reúne lo mejor de todos los sistemas de flujo de trabajo y otras tecnologías basadas en patrones.

Como las empresas cada vez más se están orientando hacia los procesos, destacándose principalmente por el e-Business, esta nueva generación de tecnología BPMS (Business Process Management System) está siendo actualmente más investigada y perfeccionada. "La gerencia de los procesos del negocio se refiere a diseñar, ejecutar y optimizar los procesos funcionales del negocio a través de toda la organización incorporando los sistemas, a los procesos y a la gente" (Vollmer, 2004).

BPM es la "integración caracterizada por flujo de trabajo orquestado, orientado a aplicaciones a través de usos internos múltiples y/o entre los socios externos" (Harris, 2003). La puesta en práctica de las soluciones de BPM ha emergido como estrategia dominante, que las organizaciones están adoptando para mejorar la eficacia de sus procesos del negocio. Las herramientas de BPM son capaces de apoyar este tipo de actividad debido a su capacidad de coordinar interacciones entre: (1) los sistemas de información; (2) los procesos del negocio, y; (3) la gente que los utiliza. Esto da visibilidad de las empresas en el estado de los procesos y tiende a permitir cambios de los procesos sobre una base en uso.

Los esfuerzos han tendido a la integración temprana de aplicaciones empresariales (IAE) y la tecnología de la Extracción, Transformación y Carga (ETC o ETL por sus siglas en inglés Extraction-Transformation-Load) que permite la generación de reportes operacionales y multidimensionales sin afectar el desempeño de las aplicaciones, que han sido fortalecidas con nuevas características que proporcionan la integración de la información de la empresa (EII), el flujo de trabajo, la gerencia de los procesos del negocio (GPN o BPM por sus siglas en inglés), la integración a través de un modelo de objetos único para todos los sistemas (canónico), la utilización de portales y la ubicuidad por medio de los dispositivos móviles.

Sin embargo esta tecnología, adolece de un marco referencial global que identifique las características esenciales a nivel estructural y de comportamiento de las relaciones taxonómicas desde el análisis hasta el código pasando por la interfaz. En lo que respecta a su implementación, no se ofrecen pautas claras para obtener la representación de los patrones conceptuales en el producto de software e insertarlos en el proceso de

9

construcción (Bell, 2003). No existe una propuesta metodológica que indique como implementarla en la industria, tal como se propone en esta investigación doctoral.

1.2 Formulación del Problema

A continuación se describe el problema de investigación, sus manifestaciones y evidencias.

1.2.1 El Problema

En base a todo lo expuesto anteriormente, surgen las siguientes interrogantes:

• ¿Es posible crear un marco referencial que permita verificar la relación y trazabilidad sobre la combinación de los diferentes patrones (análisis, arquitectural, diseño, interfaz e implementación) a lo largo del ciclo de vida del proceso de desarrollo de software en el dominio de la gestión de los procesos del negocio?,

• ¿Cómo dotar a estos patrones de especificaciones que van mucho más allá de su utilización, relacionándolos en un marco referencial y asociándolos con el dominio de la gerencia de los procesos de negocio?,

• ¿Qué tan ventajoso sería esto de cara a la ingeniería de software y en cuanto a la trazabilidad (auditoria de utilización y combinación de los mismos) entre los diferentes patrones?,

• Si se consigue capturar y representar estos patrones de forma no ambigua, ¿Se podrían construir procesos de desarrollo asistidos que traduzcan correctamente los patrones modelados al espacio de la solución?,

• ¿Cómo representar los patrones conceptuales que resulten en el espacio de la solución, mediante estructuras software de calidad que permitan implementar correctamente la semántica de los mismos en distintos entornos de producción de software?,

• ¿El paradigma de BPM puede ser utilizado para verificar aspectos de desarrollo de software basado en patrones?, y

• ¿Cómo verificar, de manera estática y asequible, hasta dónde nos es posible asegurar con el conocimiento disponible, que al combinar ciertos patrones no se han violado las condiciones de funcionamiento correcto de ninguno de ellos, garantizando su eficacia en el dominio de implementación (BPM)?

La búsqueda de respuestas a estas preguntas permite plantear un problema de investigación fundamentado en la hipótesis de que las organizaciones en general fallan en la gestión de los procesos del negocio, principalmente por factores como:

1. Retorno de Inversión (ROI) negativo a pesar de las grandes inversiones en TIC;

2. La nueva economía digital del conocimiento, centrada en la computación en red sin límites espaciales, fundamentada en la multidisciplinaridad,

3. Los modelos de negocio complejos:

10

- Sin un marco referencial, en los cuales la ingeniería de software está por debajo de las necesidades de calidad del proceso y el producto de software (no siendo este el único factor que influye en la calidad del software),

- Presentando esfuerzos independientes, sin capacidad de seguimiento y evaluación,

- Donde la mayoría de los métodos de modelado orientados a objeto (OO) carecen de guías precisas que ayuden al analista en la etapa de modelado a detectar los patrones que están presentes en el esquema conceptual, lo que repercute directamente sobre la calidad del proceso y el producto final;

4. La utilización de patrones en las nuevas tecnologías tales como BMP adolece de un marco referencial global que identifique las características esenciales a nivel estructural y de comportamiento de las relaciones taxonómicas, desde el análisis hasta el código pasando por la interfaz,

5. En su implementación la mayoría de los patrones conceptuales utilizados en el dominio de BPM no están soportados de forma precisa:

- Concentrándose en flujos de sistema a sistema y emergiendo lentamente en cuanto al flujo humano-humano asistido por el computador,

- Proporcionando soluciones propietarias de tecnologías y no estándares las cuales carecen generalmente de la agilidad ofrecida por la utilización de lenguajes de procesos y patrones,

- Intentando crear flujos de trabajo pequeños que se pueden utilizar en contextos más generalizados, pero dejando a un lado la usabilidad;

Finalmente no existe una propuesta metodológica que indique como implementar en el dominio de BPM esta nueva tecnología sustentada en el uso de patrones.

1.2.2 Manifestaciones del Problema

Las expectativas de reducción de costos o de aumento de productividad, posibilitadas por la adopción de TIC han llevado a las empresas occidentales a aumentar progresivamente sus inversiones en las mismas. Así, mientras las inversiones en tecnologías de la información que las empresas realizaron en los años sesenta representaban tan sólo el 3% del total de inversiones en equipo, en 1996 la cifra aumento hasta representar el 45%. Más aún, en algunos sectores, como en telecomunicaciones o seguros, las inversiones en TIC constituyen más de las ¾ partes del total de inversiones en equipo (MacDonald, 1998). Estos estudios se han repetido para los años 2000-2008, arrojando resultados similares que se orientan más bien a una mayor inversión en TIC.

En una línea similar, Strassmann (2007), conocido consultor norteamericano que ha estudiado con profundidad el impacto de las tecnologías de la información en las organizaciones, señala que no hay una relación directa entre la inversión de las empresas en

11

TIC y el retorno que consiguen de esa inversión. No existe tal correlación, y lo que hace rentable las TIC en una empresa no es el mero hecho de tenerlas, sino "cómo" se utilizan.

En este sentido, es ampliamente conocida la demanda por buenos instrumentos de gestión del negocio dentro del contexto de la ingeniería de software. En general, los criterios que se utilizan para evaluar un producto de software, son más bien cualitativos, sin presentar una estandarización que permita a los especialistas valorar aspectos y evidenciar criterios mínimos de confiabilidad.

Al respecto, cabe señalar que, aunque este es un problema ampliamente reconocido, existen escasas instancias de propuestas para la gestión de los procesos del negocio, que permitan determinar su influencia positiva sobre la Organización. Algunas de las iniciativas principales provienen a partir del año 2000, de los esfuerzos del Instituto de Ingeniería e Software (SEI) y en los modelos de Capacidad y Madurez Organizacional en búsqueda de garantizar una relación entre el retorno de inversión positivo y los procesos de desarrollo de software.

1.2.3 Evidencias del Problema

A pesar que los análisis económicos indican que las TIC deben tener un claro impacto positivo en el aumento de la eficiencia de las empresas, la verdad es que algunas cifras ponen este hipotético impacto en duda. Quizás el ejemplo más conocido sea el de la denominada Paradoja de la Productividad (Cornella, 1996): ¿Cómo podía explicarse que a pesar de la continua inversión en tecnología, y en especial en TIC, durante los años 70 y 80, no se consiguió un crecimiento de la productividad similar al que se había conseguido en los años 50 y 60, cuando tales tecnologías apenas existían?.

En los países subdesarrollados (como es el caso de Venezuela) se requiere de esfuerzos para la gestión de los procesos del negocio, orientados a obtener un equilibrio adecuado entre la adquisición de la tecnología del exterior, el desarrollo y utilización de la capacidad tecnológica de la propia empresa y, la selección, adaptación y generación de la tecnología que se demanda para producir; ya que, en estos países, las empresas no poseen capacidad, ni tradición suficientes en el desarrollo de tecnologías, siendo la principal opción el recurrir a la transferencia de tecnología, provenientes éstas de países desarrollados (Paredes, 2004).

Estos modelos son comúnmente difíciles de adoptar y es la organización la que debe adaptarse a las TIC. Existen otras causas que influyen en la productividad (puesto de trabajo, ambiente, etc.) sin embargo esta investigación se concentra en los relativos a la ingeniería de software, en la que se han utilizado diferentes técnicas tradicionales como observación, protocolos verbales, opiniones de los usuarios (entrevistas, discusiones grupales, cuestionarios), grupos de enfoque específico, etc., para obtener datos con la finalidad de satisfacer mejor las necesidades y requerimientos del usuario (Navasa et. Al, 1999).

Además de la variable costo, al analizar el entorno en el que se desenvuelven estas tecnologías resulta importante observar otros indicadores de evaluación, estos indicadores

12

pueden clasificarse en cuatro tipos: (1) Complejidad de la gerencia de tecnología de información (madurez en los procesos, dispersión de los usuarios finales, disponibilidad de los servicios de TIC, niveles de servicio); (2) Complejidad del software (número de plataformas de software diferentes, número de aplicaciones cliente servidor, porcentaje total de software de aplicación critico, porcentaje de aplicaciones de oficina); (3) Complejidad del hardware (número de arquitecturas de hardware distintas, retorno anual de una computadora personal, niveles de redundancia, porcentajes de usuarios con dispositivos móviles), y; (4) Indicadores financieros (Valor Económico Agregado – EVA -, Valor de Mercado Agregado – MVA -, Valor Actual Neto – VAN -, Valor Presente Neto – VPN -, Tasa Interna de Retorno – TIR -, etc.) (Strassman, 1997).

A pesar de los grandes cambios tecnológicos ocurridos en los últimos 10 años esta situación sigue siendo la misma, observándose más bien un crecimiento en la complejidad de las organizaciones y en la dificultad de poder determinar como afecta de manera positiva en el negocio la TIC. (Strassman, 2007).

1.3 Objetivos

Seguidamente se presenta el objetivo general y los objetivos específicos de esta investigación.

1.3.1 Objetivo General

El objetivo general de esta investigación es Diseñar e Implementar una metodología que permita la gestión de los procesos de negocio sustentada en el uso de Patrones.

1.3.2 Objetivos Específicos

Para lograr el objetivo general es necesario cumplir con los siguientes objetivos específicos:

1. Caracterizar las organizaciones como un sistema complejo (en el ámbito de las ciencias gerenciales y las ciencias de la computación, con especial énfasis en la ingeniería de software) que tiene como objetivo gerenciar los procesos del negocio a través de las TIC, a fin de definir sus procesos de: desarrollo de software, uso de patrones y gerencia de los procesos de negocio;

2. Analizar algunos métodos de: construcción de software, modelado orientado a objetos, especificación de patrones, definición de arquitecturas de software, evaluación de arquitecturas de software, evaluación de la calidad del proceso y el producto de software y gestión de los procesos del negocio. A fin de seleccionar mediante el análisis los elementos importantes que serán incorporados en la metodología a proponer;

3. Establecer los lineamientos teóricos, gerenciales, técnicos y financieros, implícitos la propuesta metodológica;

13

4. Definir un marco referencial integrado, claro y eficaz, con base en el uso de los patrones, su taxonomía, organización, combinación, especificación, trazabilidad e implementación en el dominio de la gerencia de los procesos del negocio;

5. Proponer una metodología sustentada en la gerencia de los procesos del negocio y el uso de los patrones haciendo especial énfasis en la trazabilidad, seguimiento y evaluación de herramientas y métodos que:

- aborden el proceso de desarrollo con formalidad y de forma sistémica, proporcionando los modelos y las etapas exclusivamente necesarias para la producción de software;

- se centren en la especificación precisa del espacio del problema;

- ayuden al analista a tomar decisiones en el proceso de modelado conceptual;

- faciliten la generación asistida de código tanto en estructura como en funcionalidad a partir de esquemas conceptuales;

- ofrezcan libertad tecnológica, independiente de la tecnología subyacente a los desarrolladores; y

- promuevan software de calidad funcionalmente equivalente a su especificación;

6. Especificar una propuesta de desarrollo de un prototipo de bajo nivel que exprese la metodología en términos de las TIC disponible.

A continuación se presenta la justificación de la investigación doctoral.

1.4 Justificación

En esta tesis doctoral se plantea la definición de la metodología para la gestión de los procesos del negocio sustentada en el uso de patrones, buscando establecer las relaciones y condiciones necesarias entre la multidisciplinaridad, el modelo de negocio complejo de las organizaciones actuales y la ingeniería de software, a fin de obtener una buena gestión de los procesos con apoyo de las TIC y una forma de evaluar exitosamente la gerencia de los proceso en el marco de los intereses del negocio. Lo que corresponde con la justificación teórica de la investigación.

Como justificación metodológica de la investigación, el proceso de Gestión Tecnológica requiere de esfuerzos en cualquier organización para buscar un cambio en condiciones favorables y así poder realizar transferencia de tecnologías e innovaciones tecnológicas, en función de los recursos financieros y de las necesidades económicas de cada organización y país. Esta investigación ofrecerá un conjunto de normas, estándares, lineamientos, métodos, herramientas y técnicas a seguir para la gerencia de los procesos de negocio, en estas organizaciones.

14

Desde la perspectiva institucional y social, las empresas en Venezuela toman decisiones referentes a la tecnología que utilizan y la gerencia de los procesos de negocio, pero sin tener mucha conciencia de ello; se utilizan enfoques que tienden a subestimar o ignorar aspectos importantes de la selección y uso de la tecnología que compran y de los procesos que se administran. En el marco de esta aseveración, la justificación institución y social de esta investigación se refiere a los aportes y beneficios que tendrá la empresa en cuanto a un modelo formal a seguir para la gestión de los procesos del negocio sustentada en el uso de patrones.

1.5 Delimitación

Este estudio está circunscrito al área de gerencia de procesos de negocio y los patrones de software, dentro del contexto mundial de la realidad legal, sociopolítica, jurídica, económica y tecnológica existente en las ciencias computacionales y la ingeniería de software para el año 2007: software libre, software abierto, computación en red, interacción humano-humano asistida por el computador. Específicamente de los procesos de negocio existentes, se toma como caso de estudio el proceso de gestión de versiones de ITIL.

Por otro lado, los resultados que arrojará la presente investigación doctoral serán alternativas de soluciones generales, de allí que su aplicación en áreas específicas de la ingeniería de software requerirán un estudio previo para ajustar apropiadamente estas soluciones a las particularidades y singularidades de un dominio en específico.

1.6 Limitaciones

Se puede apreciar, que la tecnología aun no esta totalmente preparada para afrontar el concepto general de gerencia de los procesos de negocio, sin embargo se inician los esfuerzos por garantizar la disponibilidad de repositorios de información de patrones, pero no una relación taxonómica y de auditoria entre los mismos.

De tal forma que la limitación fundamental de este estudio de investigación doctoral es la disponibilidad de un software que permita aplicar todo el concepto en el cual se expone la propuesta metodológica. En este sentido durante la ejecución de la investigación se realizo la especificación de los Casos de Uso de un Prototipo de Sistema de Gerencia de Procesos de Negocio sustentado en el uso de Patrones, lo que permitiría aplicar la metodología propuesta.

15

Capítulo II Marco Teórico

2.1 Antecedentes de la Investigación

Para iniciar el marco teórico resulta conveniente citar algunos estudios preexistentes vinculados al tema de investigación desde la perspectiva de la paradoja de la productividad:

1. A inicio del 2002, Win Van Grembergen, en el capítulo uno de su libro: “Information Technology Evaluation Methods and Management” (Win, 2002), cita los resultados obtenidos en 2002 de un estudio realizado a diecisiete (17) países desarrollados durante los años 1995 y 1999. En estos países, los retornos de la inversión en TIC aumentan considerablemente. Lo anterior, se produce, según el estudio, porque se han reconocido dos tipos de beneficios: Complementarios Macroeconómicos y Complementarios Personales. Estos beneficios se conjugan y contribuyen al aumento del retorno de la inversión. Sin embargo, no existe una relación directa entre la inversión en TIC para la gerencia de los procesos del negocio y su retorno de inversión positivo;

2. En el mes de Septiembre del 2007, Paul Strassmann publica un artículo referente a la importancia del retorno de inversión en las inversiones de TIC "Why ROI ratios are now crucial to IT investment", destacando el problema planteado;

3. Para Diciembre del 2007 Alinean presenta su metodología: "Alinean’s ROI Dashboard™ Methodology" asociada al cálculo de retorno de inversión de TIC como una mejora asociada a los activos intangibles e indicadores de impacto estratégico en la organización.

En cuanto a los antecedentes de la investigación en el ámbito de la ingeniería de software, esta tesis se sitúa en el área de trabajo de los entornos de modelado y producción de software orientado a objetos (OO), entre los cuales destaca el artículo “A Unified Object Topology” (Tepfenhart et al., 1997).

En este artículo se propone un mapa (ver, Figura 1) sobre el cual se proyecta una serie de técnicas utilizadas en el desarrollo de software OO, como son: el Modelado del Dominio, los Patrones de Diseño, los Estilos Arquitectónicos, los Marcos de Trabajo ("Frameworks") y los Componentes de Software ("Kits") .

Los procesos de producción de software actuales hacen uso de estas técnicas y de las relaciones inherentes entre ellas. Estas relaciones inducen una serie de caminos a recorrer para la construcción de sistemas de software. Estas técnicas se han “medido” y distribuido en el mapa con relación a los atributos de Implementación (nivel concreto o abstracto de programación) y Dependencia del Dominio (independiente del dominio o específico para un caso particular), relacionándose unas con otras.

16

Cuando se desarrolla un sistema de software existe una gran diversidad de problemas en los que el desarrollador debe centrarse. De forma simplificada debe: (1) analizar el dominio de la aplicación; (2) definir una arquitectura; (3) implementar las clases del dominio; (4) construir un software de calidad; y (5) crear un sistema cohesivo con los elementos obtenidos.

Este proceso puede verse como el recorrido de una serie de caminos a través del mapa presentado en la Figura 1. Se puede observar que en las propuestas de desarrollo de software actuales los Patrones de Diseño actúan como puente entre los Patrones Conceptuales de los Modelos del Dominio (Elementos de Modelado) y su implementación (lo que en el artículo se denomina “Kits”).

Si se analizan los caminos existentes (a través de los elementos que integran la Figura 1), surge una serie de problemas con las técnicas y las rutas que las unen. Por ejemplo, de las rutas introducidas, el camino que une los modelos del dominio con su implementación a través de los patrones de diseño presenta algunos problemas: (1) los métodos OO existentes no describen los dominios de forma clara y sin ambigüedades; (2) la caracterización del dominio del problema para el desarrollo de aplicaciones es extremadamente compleja; (3) no se proporcionan guías precisas para el modelado del dominio; (4) los patrones de diseño son demasiado generales y no son directamente aplicables a problemas específicos; (5) no existe una correspondencia precisa entre los modelos del dominio, los patrones de diseño y su implementación (”kits”); (6) en la mayoría de los procesos de producción de software, la transición entre los modelos del dominio, los patrones de diseño y los ”kits” se realiza de forma manual; y (7) la estructura y el comportamiento de los patrones conceptuales se implementa de forma “ad hoc” por lo que la calidad del producto de software final dependerá del implementador.

Figura 1: Tecnologías relacionadas en el Desarrollo OO Actual. (Tepfenhart et al., 1997)

En la Ingeniería del Software, los patrones intentan describir soluciones que han resuelto de forma exitosa problemas comunes del proceso de producción de software. Algunos

17

ejemplos de patrones arquitecturales son: capas, filtros y conexiones, modelado vistas y controles (MVC).

Los patrones (Schmidt, 1996) reflejan las estructuras conceptuales comunes a dichas soluciones, que pueden aplicarse de forma repetida cuando se está produciendo software (analizando, diseñando, e implementando) en un contexto particular.

Representan el conocimiento y la experiencia que subyacen en muchos esfuerzos de diseño y reingeniería de los desarrolladores, consiguiendo mayor flexibilidad y capacidad de reutilización en su software. Además, proporcionan modelos útiles, especificaciones de cómo utilizarlos, y asunciones y restricciones sobre su utilización.

Facilitan la reutilización y el acto de compartir y re-usar el conocimiento, de forma eficaz permitiendo a los desarrolladores aprovechar soluciones previas y adaptarlas a sus problemas específicos. Los patrones existen en las diversas fases del desarrollo de software. Los desarrolladores no los inventan, sino que los descubren debido a su experiencia en la construcción de sistemas.

En cuanto a los antecedentes de la investigación desde la perspectiva de los procesos de negocio, existen diversas definiciones del término en la literatura, las cuales entran en conflicto a menudo, así solamente se consideraran en esta investigación las más influyentes:

• Moore y Whinston (1996) proponen una visión de procesos como colecciones de modelos de decisión. Según estos autores, los procesos son identificados por los tipos de decisiones implicadas en ellas y contienen una secuencia de tareas. Estas tareas son las unidades identificables más pequeñas del análisis. Es preciso citar que su configuración óptima es el factor de diseño crítico que afecta la eficacia de las organizaciones en función de estos procesos,

• En 1998 Davenport define un proceso de negocio como "la organización lógica de la gente, materiales, energía, equipo y procedimientos en las actividades del trabajo diseñadas para producir un resultado final especifico",

• Por otra parte, Hammer y Champy (1996), definen proceso de negocio como un "sistema de actividades que, juntas, producen un resultado que da valor a un cliente",

• Alternativamente, Earl (1996) define proceso de negocio como una "forma lateral u horizontal que encapsula la interdependencia de las tareas, de los papeles, de la gente, de los departamentos y de las funciones requeridas para proveer a un cliente un producto o un servicio".

En el ámbito de los procesos de negocio la solución tecnológica por excelencia se refiere al término flujo de trabajo o “workflow”, proceso a través del cual las tareas de los individuos son coordinadas para completar una transacción (usando los procesos del negocio definidos) dentro de una organización (Davenport, 1998).

18

El “workflow” es un conjunto de mecanismos que automatizan ciertos procesos de trabajo. Estos mecanismos relacionan entre sí los aspectos de la administración, establecen prioridades entre las diversas tareas de cada empleado y optimizan las comunicaciones entre las distintas unidades operativas. (White, 1996).

Para que eso se logre es necesario definir cuáles son las distintas tareas que se realizan en una organización; quienes participan en su ejecución; quiénes son responsables de las mismas; cuál es la secuencia de procesos de cada tarea y cuáles son las acciones que inician cada proceso (Shcmidt, 1990).

Aunque la contribución de los flujos de trabajo tradicionales de producción, “ad hoc”, administrativos y colaborativos, es aún notable, hay una nueva generación que quizás sea un híbrido que reúne lo mejor de todos los sistemas de “workflow” y otras tecnologías: los BPMS, los cuales son sistemas que integran las facilidades de flujo de trabajo en una arquitectura orientada a servicios, con modelaje y simulación de procesos y generación asistida de aplicaciones.

Como las empresas cada vez más se están orientando hacia los procesos, destacándose principalmente por el e-Business, esta nueva generación de aplicaciones supera las limitaciones anteriores, conocidas en los 90, incorporando amplias capacidades de integración con modernas arquitecturas Java, .Net y XML, principalmente. (Bonillo, 2007b)

Adicionalmente, se les están sumando otras tecnologías como Servicios Web, Motores de Reglas de Negocio y Monitoreo de las Actividades del Negocio (BAM-Business Activity Monitoring). De acuerdo con Howard Smith y Peter Fingar, avalados por la BPMI (Business Process Management Initiative) y el WFMC (WorkFlow Management Coalition), hoy en día se puede señalar que “los BPMS permiten a las empresas modelar, implementar y gestionar los procesos de negocio, que abarcan múltiples aplicaciones empresariales, departamentos, y proveedores partners, detrás de los cortafuegos y sobre Internet”.

Cada vez más los BPMS, van adquiriendo mayor importancia en las empresas de todos los sectores. Principalmente porque las empresas saben que todos los recursos bien integrados y orquestados permiten una verdadera agilidad. Las empresas se han dado cuenta que aunque han hecho grandes inversiones en Sistemas, Aplicaciones y Tecnologías, aún no han alcanzado la flexibilidad y agilidad que se requiere hoy en día. Mirando un poco el avance de esta tecnología, el desarrollo y uso de los sistemas de “workflow” ha evolucionado desde simplemente automatizar el enrutamiento de actividades entre personas, a coordinar los procesos de negocio utilizando todos los recursos. (Hayward, 2003).

2.2 Bases Teóricas

A continuación se presentan los fundamentos para la investigación, donde tendrán relevancia los procesos de desarrollo de software, la construcción de software basado en

19

componentes, taxonomía de patrones y su relación con la calidad de software y gestión de los procesos del negocio e ITIL.

2.2.1 Procesos de Desarrollo

En los últimos años se han estudiado entre otras, dos corrientes en lo referente a los procesos de desarrollo de software, los llamados métodos pesados y los métodos ágiles. La diferencia fundamental entre ambos es que mientras los métodos pesados intentan conseguir el objetivo común por medio de orden y documentación, los métodos ágiles lo hacen mejorando los procesos de comunicación directa e inmediata entre las personas que intervienen en el proceso. Los métodos de desarrollo de software considerados en esta investigación, son: Unified Processs (UP) como método pesado, XP (eXtreme Programming Project) y FDD (Feature Driven Development) en el caso de los métodos ágiles.

En cuanto a estos procesos de desarrollo de software, se tiene que si el proyecto es suficientemente grande como para compensar la adaptación, se puede decir que UP es una buena base, ya que permite conseguir una mayor y mejor estructura y disciplina del proceso de desarrollo. Una buena posibilidad de reducir el trabajo a realizar es la reutilización de modelos, procesos, etc. ya definidos en implementaciones previas de UP en distintos ámbitos.

Con relación a la arquitectura, XP con las metáforas del sistema, intenta determinar una arquitectura óptima en etapas tempranas del desarrollo. FDD, aún cuando se centra en la calidad, deja todo el peso de las decisiones arquitecturales al arquitecto principal, pero no especifica como estas decisiones tienen relación con la calidad del sistema en desarrollo.

Por otra parte, se tiene un problema generalizado para todos estos procesos de desarrollo: la selección de la arquitectura adecuada o combinación de diferentes estilos arquitecturales para un sistema de software es un problema que aún no ha sido resuelto y que se ha tratado ampliamente en la literatura. El crecimiento de la complejidad de los sistemas, construidos usualmente a través de la integración de componentes, incrementa la necesidad de obtener enfoques más rigurosos que conduzcan este proceso de decisión.

Todos los procesos de desarrollo, tienen ausencia de una clara relación entre los patrones, los componentes, la arquitectura y las características de calidad asociadas a la misma, UP por su parte, no tiene una asociación de los requerimientos no funcionales con los casos de uso, una mala selección de los principales casos de uso afecta la arquitectura del sistema, el modelo de prueba utilizado para evaluar la arquitectura no tiene guías precisas para determinar esta relación. (Losavio et al., 2004).

Una vez especificado el contexto de uso de la metodología, seguidamente se aborda el tema de la construcción de software basado en componentes.

20

2.2.2 Construcción de Software Basado en Componentes

Cuando se habla de componentes, se pueden encontrar algunas definiciones relacionadas con la implementación, donde están aquellas que entienden por componente un paquete coherente de código que: (i) puede ser desarrollado y distribuido independientemente, (ii) tiene interfaces explícitas y bien especificadas para el servicio que ofrece, (iii) tiene interfaces explícitas y bien especificadas para el servicio que espera de otros componentes, y (iv) puede ser compuesto junto con otros componentes, quizás extendiendo alguna de sus propiedades, pero sin modificar al componente propiamente dicho (D´sousa et al., 1999).

Una definición más general la ofrecen Jacobson, Griss y Jonsson (1997) y que es la que se considera para esta investigación, quienes lo definen como un artefacto que ha sido desarrollado específicamente para ser reutilizado. En este caso un componente podría ser tanto un caso de uso como cualquier otra entidad reutilizable que surja durante el proceso de desarrollo y que sea utilizado en cualquier actividad, siempre que no requiera conocimiento del software que lo utiliza.

Los objetos COM y los “JavaBeans” son ejemplo de tecnologías de componentes. Los componentes pueden ser objetos en el sentido usual de OO, excepto que satisfacen guías adicionales dirigidas a hacerlos auto-contenidas. Usan otras componentes mediante agregación y por lo general interactúan con otras componentes a través de los eventos (Braude, 2003).

La construcción de software basado en componentes persigue tres objetivos principales: la reutilización, la adaptación y la extensión (la reutilización implica la adaptación y la extensión):

1. Un componente es reutilizable en la medida en que sus servicios pueden ser utilizados por otro componente.

2. Un componente es adaptable si su proveedor ha previsto los posibles cambios que puede sufrir dicho componente.

3. Un componente es extensible si su proveedor proporciona los mecanismos para modificar los servicios que ofrece el componente.

De acuerdo con el objetivo que se persiga, los componentes en las diferentes fases del proceso de desarrollo de software pueden ser desarrollados de acuerdo con los aspectos que se mencionan en la Tabla 1.

Con relación a la obtención de requisitos, tres son los aspectos principales:

1. El análisis vertical, centrado en un dominio o un área de negocio concreta; cuyo objetivo es que los componentes resultantes puedan convertirse en estándares para cualquier aplicación desarrollada posteriormente en ese dominio y que apunte hacia su reutilización (Szyperski, 1997);

2. El análisis horizontal, realizado de forma genérica para dar servicio a un amplio rango de aplicaciones, sin restringirse a un dominio de negocio dado; y

21

3. Análisis específico, realizado en un dominio concreto (Allen et al., 1998), para obtener componentes “ad hoc” donde el énfasis no se hace tanto en la reutilización sino más bien en la extensión.

Objetivo Fase

Reutilización Extensión Adaptación

Obtención de Requisitos

- análisis vertical - análisis horizontal

- análisis específico

Partición en componentes

- casos de uso - patrones - entidades del dominio - componentes Existentes

- previsión de cambios

Interacción de Componentes

- empaquetar

- herencia - interfaces - agregación

- parametrización - patrones de diseño - programación adaptativa - relación/clase de contexto

Tabla 1 Fases del Proceso versus Objetivos de la Construcción de Software Basado en Componentes. (Gamma et al., 1995)

La utilización de los enfoques depende de lo que se desea realizar con el diseño del componente dentro del dominio, si se busca la extensión se debe utilizar el análisis especifico, si se desea la reutilización se debe integrar el enfoque vertical para los elementos específicos del dominio y el aspecto horizontal en relación al comportamiento del componente con el resto de las aplicaciones del dominio, teniendo en cuenta la particularidad del diseño sin perder de vista las interacciones del componente con otras aplicaciones, finalmente si se desea observar la extensión y la reutilización se debe realizar una integración sistémica entre el enfoque especifico, vertical y horizontal.

Durante la obtención de requisitos se han identificado todas las funcionalidades que deben ser soportadas, pero la distribución de dichas funcionalidades puede darse de inmediato, o puede construirse adaptando los componentes existentes. La partición de componentes puede realizarse a través de: los casos de uso, los patrones de diseño, las entidades del dominio, la evolución prevista del sistema; y, los componentes ya existentes.

Con relación a la interacción de componentes, se dice que es directa (interacción simple) cuando el servicio ofrecido se ajusta a las formas y necesidades del servicio requerido. Si las formas no son las adecuadas, es necesario realizar previamente un proceso de empaquetamiento (“wrapper”). Esta situación se presenta, por ejemplo, cuando se quiere reutilizar la funcionalidad soportada por sistemas “legacy” donde la forma de interactuar no es la más adecuada. En este caso, el sistema "legacy" se empaqueta dentro de un software que le da apariencia de componente (Allen et al., 1998).

22

Por otro lado, si el problema es cierto desajuste entre las necesidades solicitadas y las necesidades ofrecidas, se tendrá que recurrir a la adaptación o a la extensión del componente; para esto, los mecanismos más comunes son: (i) Herencia cuando una clase o un caso de uso del componente define un comportamiento que quien reutiliza dicho componente hereda, y además aumenta añadiéndole sus propias características específicas (Jacobson et al., 1997); (ii) Interfaces, cuando se definen interfaces sin implementar o con una implementación por defecto, y quien reutiliza el componente define su propia implementación (Larsen, 1999); (iii) Agregación, el componente a reutilizar ofrece una clase que puede ser extendida creando una nueva clase que contiene instancias de la primera; y, (iv) “Glue Component”, este componente actúa como intermediario de un conjunto de componentes con el resto del sistema, extendiendo la funcionalidad del grupo de componentes (D´sousa et al. 1999).

En el caso de la adaptación los mecanismos más utilizados son: (1) parametrización, en los casos más comunes, se definen parámetros o macro expresiones, el componente parametrizado será especializado asignando un valor real al parámetro (Jacobson et al., 1997); (2) patrones de diseño, utilizar patrones para resolver problemas de diseño recurrentes al diseñar lógica de negocio extensible; (3) programación adaptativa, aquí el comportamiento no está implementado de forma exhaustiva y además se define un patrón de propagación que proporciona un conjunto de restricciones que deben cumplir los programas de la familia denotada por el programa adaptativo; y, (4) relaciones y clases de contexto, en una relación de contexto se relaciona una clase base con varias clases de contexto. Estas no heredan de la clase base, ni se consideran subclases, sino que definen atributos y métodos para sus instancias.

Seguidamente se estudian los diferentes tipos de patrones que han surgido a través de la Ingeniería de Software a fin de establecer sus relaciones y una clasificación general.

2.2.3 Taxonomías de Patrones

Actualmente, el uso de patrones en el proceso de producción de software es uno de los temas más tratados, generando un gran interés entre investigadores y desarrolladores. Un patrón captura la experiencia y conocimiento de expertos, quienes han producido soluciones exitosas a problemas, a fin de que esas soluciones queden a disposición de personas con menos experiencia; sin embargo, los patrones no proveen siempre las soluciones definitivas, algunas veces, los usuarios de patrones deben tener creatividad para utilizar, instanciar o implementar un patrón.

Los patrones pueden aplicarse a nivel del: análisis de requisitos, el diseño de la arquitectura, el diseño detallado, la interacción con el usuario, el flujo de trabajo y el código. Con lo que puede establecerse la siguiente clasificación:

• Patrones de análisis: Los patrones de análisis son grupos de conceptos que representan una construcción común en el mundo del modelado conceptual. Pueden ser relevantes a un dominio o ser adaptados a muchos dominios. La idea central es la construcción de

23

escenarios utilizando patrones. Se pretende tener una visión más conceptual y estructural de las situaciones, con el fin de identificar la naturaleza intrínseca de las mismas. Con esa visión, es posible determinar el tipo de escenario correspondiente a cada situación y así, elegir un patrón de un catálogo, re-usando su estructura con el fin de derivar el escenario más fácil y directamente. Los patrones de análisis consisten en un texto guía, que para cada componente del escenario incluye pautas acerca del contenido que deberá tener dicho componente. Por ejemplo el patrón de análisis para realizar una actividad productiva es aplicado al escenario de diseño de una agenda de reuniones de tal forma de reutilizar las características de una actividad productiva en el dominio específico de una agenda de reuniones. Los patrones de Flujo de Trabajo (Bonillo, 2005c) son escenarios de los patrones de análisis descritos en el Anexo 1.1, por lo que no se mencionan en la taxonomía.

• Patrones de arquitectura (Arquitecturales): Son esquemas fundamentales de organización de un sistema software. Especifican una serie de subsistemas y sus responsabilidades respectivas e incluyen las reglas y criterios para organizar las relaciones existentes entre ellos. Algunos ejemplos son: capas, filtros y conexiones; modelos, vistas y controles (MVC).

• Estilos Arquitectónicos: representan una generalización de los patrones de arquitectura, dado que expresan los componentes y las relaciones del esqueleto estructural y general de una aplicación independiente del contexto y de otros estilos, son una categorización de sistemas. Algunos estilos típicos son las arquitecturas basadas en flujos de datos, las de invocación implícita, las jerárquicas, las centradas en datos o en intérprete-maquina virtual.

• Patrones de diseño: Son patrones de un nivel de abstracción menor que los patrones de arquitectura. Están por lo tanto más próximos a lo que sería el código fuente final. Su uso no se refleja en la estructura global del sistema. Por ejemplo: “abstract factory”, “constructor” y “chain responsability”.

• Patrones de Interacción: también conocidos como Patrón de Interfaz, describe una solución exitosa a un problema recurrente concerniente a la interfaz de usuario, en un contexto dado. Un Patrón de Interacción es un medio de comunicación que se expresa en una notación sencilla, a fin de ser entendida por las personas del equipo de diseño de la interacción que generalmente es multidisciplinario. Algunos ejemplos son: formatos de datos de fechas y representación visual jerárquica del estado del sistema.

• Patrones de Implementación: Se refieren a la forma de programar o implementar una solución en un lenguaje específico, se asocia con los términos en inglés “kit” e “Idiom”.

En el Anexo 1, se describen con mayor detalle cada uno de los patrones antes mencionados. A partir de esta descripción, es preciso notar que lo que diferencia a los tipos de patrones entre sí, está relacionado con su nivel de abstracción (patrones aislados versus familias –

24

lenguajes o catálogos – de patrones). Esta clasificación, basada en lo planteado por Bushmann et al. (1996), se resume en la Figura 2 que se muestra a continuación.

Figura 2. Diferentes tipos de Patrones y su Relación (Bonillo, 2008)

En general los patrones tienen una limitación: son difíciles de especificar y evaluar en base a un modelo de calidad particular, por lo que el estudio de los temas de ADL (Architecture Definition Language) y ABAS (Atribute-Based Architecture Styles), como estructuras que extiende la representación dada por el Grupo de los Cuatro (GoF) con la finalidad de especificar la información sobre los patrones y las características de calidad relativas, se consideran relevantes y fueron especificados para esta investigación doctoral inicialmente como anexo y luego como un articulo de investigación. (Bonillo, 2006a)

De acuerdo a todo lo anterior, las descripciones de GoF pueden ser extendidas utilizando ABAS como un estilo y no una técnica (forma eficiente y eficaz de utilizar una herramienta), de tal forma de expresar las características relacionadas con la calidad. La relación entre los aspectos teóricos desarrollados se puede resumir como se muestra en la Figura 3.

25

Figura 3. Relación entre las bases teóricas (Bonillo, 2008)

Con la finalidad de incorporar el concepto de ABAS en la taxonomía de patrones expuesta con anterioridad y tomando como referencia la representación de patrones de interacción en base a un metapatrón propuesto por Acosta y Zambrano (2004), a continuación se obtiene la siguiente representación extendida:

Nombre (título), autor clasificación, dominio (usos conocidos) y rango.

Nombre: Idea Central por la cual se identifica el patrón. Autor: Nombre de la persona que creó el patrón. Clasificación: Se refiere al tipo de patrón de acuerdo a la taxonomía antes mencionada. Dominio: Indica el o los dominios en los cuales el patrón ha sido implementado. Rango: es el grado de confiabilidad de este patrón con respecto a los dominios en los cuales ha sido implementado.

Problema Describe el problema que será resuelto, desde el punto de vista del usuario.

Solución Describe, en una forma narrativa y gráfica, la solución al problema. Con base en: Objetivo, Intención, Motivación, Actores o Participantes, Recursos, Estructura, Episodios, Colaboraciones e Implementación.

Atributos de Calidad Atributos de calidad de interés, el contexto de uso, contrastes y atributos relevantes (requerimientos específicos).

26

Medidas de atributos de Calidad

Un resumen de lo que es discutido en la descripción del problema, usando términos específicos relacionados con aspectos medibles de los atributos del modelo de calidad. Esto incluye una discusión de los eventos que pudieran hacer que la arquitectura responda o cambie.

Parámetros de atributos de Calidad

Un resumen de lo que será discutido en la sección de solución, pero especificando términos relevantes a los parámetros de los atributos especificados en el modelo de calidad.

Análisis del Modelo de Calidad

Una descripción de cómo los atributos del modelo de calidad serán relacionados formalmente con los elementos del patrón y las conclusiones sobre la conducta arquitectural que se obtiene con el modelo.

Contexto Presenta las condiciones bajo las cuales el patrón es utilizado.

Fuerza Conflictos que pudiesen restringir la solución. Incluyendo las excepciones.

Consecuencias Describe el resultado de aplicar el patrón.

Ejemplos/Contra-ejemplos Muestra ejemplos y contraejemplos de la solución propuesta.

Patrón Relacionado Otros patrones que se relacionan con el patrón descrito.

Tabla 2 Metapatrón adaptado de Acosta, Zambrano (2004) y Kazman, Klein (2004)

Es importante citar que la usabilidad del patrón indicada en la representación de Acosta y Zambrano (2004) es, en este caso, un atributo de calidad. Además un patrón no requiere, generalmente, todos los elementos antes mencionados, a fin de cumplir su objetivo, un patrón debe tener como mínimo los siguientes elementos: Nombre, Problema, Solución, Contexto y Fuerzas.

2.2.4 Gerencia de los Procesos del Negocio

La Gerencia de Procesos del Negocio es el término general para los servicios Web y las herramientas que apoyan los procesos de forma explícita (tales como el análisis, definición, ejecución, supervisión y administración de procesos), incluyendo la interacción humano-humano asistida por el computador.

El desarrollo de servicios Web y los lenguajes de integración basados en XML ha permitido el desarrollo de patrones para los procesos de negocio. En consecuencia, la Gerencia de los Procesos del Negocio (por sus siglas en ingles Business Process Management) abarca la Integración de los Procesos de Negocios (BPI) y por lo tanto la Integración de las Aplicaciones Empresariales (EAI). (Ver, Figura 4).

27

Figura 4: La evolución de EAI/BPM. (Vollmer et al., 2004)

Los usos de BPM permiten a las compañías implementar y administrar procesos a través de unidades de negocio tanto internas como externas y sus relaciones. Según Giga (Vollmer et al., 2004) "La gerencia de proceso del negocio se refiere a diseñar, ejecutar y optimizar los procesos funcionales del negocio a través de toda la organización incorporando los sistemas, a los procesos y a la gente". Forrester (Harris et al., 2003) definen BPM como "integración caracterizada por flujo de trabajo orquestado, orientado a aplicaciones a través de usos internos múltiples y/o entre los socios externos". Los BPMS consisten en dos elementos: (1) el diseñador de procesos; (2) y el motor de proceso.

Las capacidades de los Servicios Web permiten a las herramientas de BPM apoyar la ejecución del proceso de forma automatizada. Vollmer et al. (2004) discuten que la puesta en práctica de las soluciones de BPM ha emergido como estrategia dominante, que las organizaciones están adoptando para mejorar la eficacia de sus procesos del negocio.

Las herramientas de BPM son capaces de apoyar este tipo de actividad debido a su capacidad de coordinar interacciones entre: (1) los sistemas de información; (2) los procesos del negocio, y; (3) la gente que los utiliza. Esto da visibilidad de las empresas en el estado de los procesos y tiende a permitir cambios de los procesos sobre una base en uso.

En la Figura 5 se presenta la arquitectura que soporta los BPMS, en la base inferior se encuentra la capa de integración de datos (bases de datos distribuidas, replicación de datos, extracción transformación y carga de datos, integración de la información de la empresa, intercambio electrónico de datos y los elementos de dato como tal), a continuación la capa de integración de aplicaciones (modelo de objetos canónico y distribuido, integración de aplicaciones empresariales y las aplicaciones), seguidamente la capa de integración de la presentación (portales, dispositivos de presentación y adaptación de aplicaciones a

28

dispositivos móviles) y finalmente la capa de integración de los procesos (BPM y flujo de trabajo)

Figura 5: Arquitectura BPM. (Vollmer et al., 2004)

En la Iniciativa para la Gerencia de los Procesos de Negocio (BPMI, hoy por hoy unida a la OMG), se definen especificaciones estándares y abiertas, tales como la notación en la que se modelan los procesos del negocio (BPMN) y el lenguaje de consulta de procesos (BPQL), que permite la gerencia estándar del análisis del proceso, basada en el negocio y a través de los BPMS. Los estándares en los cuales se enfoca BPMI son los siguientes (ver, Figura 6):

1. BPML: Es el lenguaje en el que se modelan los procesos de negocio, se puede definir como un metalenguaje para modelar los procesos. BPML proporciona un modelo abstracto de ejecución para los procesos de colaboración y transaccionales, basado en el concepto de una máquina transaccional de estado. Se ha definido como medio para dar convergencia al uso del proceso dentro de las empresas, tanto de las transacciones distribuidas síncronas como asíncronas.

2. BPMN: Una notación estándar para el modelaje de los procesos de negocio (BPMN), la cual permite entender los procedimientos internos a través de una notación gráfica

Integración Basada en Procesos

Gerencia de Procesos de Negocio Flujos de Trabajos

Presentación de Integración

Anfitrión (Host): Presentación Adaptadores Moviles Portales

Integración de Aplicaciones

Objetos Distribuidos

Integración de las Aplicaciones Empresariales

Anfitrion (Host): Aplicación

Integración de Datos

Bases de Datos Distribuidas

Integración de Información Empresarial

Extracción , Carga y Trasformación

Replica de Datos Anfitrión (Host): Datos

Integración de Datos Empresariales

29

(Business Process Diagram-BPD-) permitiendo la comunicación de estos en una forma estándar. Esta notación facilita además el entendimiento de las colaboraciones, del rendimiento y de las transacciones, permitiendo la reutilización. Establece una relación entre los elementos gráficos y los constructores de los bloques estructurados del lenguaje de ejecución de procesos (BPEL), incluyendo BPML y BPEL4WS (BPEL para servicios Web).

3. BPSM: Es un "framework" conceptual que incluye patrones arquitecturales y de flujo de trabajo para BPM.

4. BPXL: Es un estándar del BPMI para extender BPEL4WS a fin de que pueda manipular transacciones, reglas de negocio, administración de tareas e interacción humano-humano asistida por el computador.

5. BPQL: Es una interface para administrar la infraestructura de los procesos de negocio que incluye facilidades de ejecución de procesos (“Process Server”) y facilidades para el desarrollo de procesos (“Process Repository”). Esta interface permite a los analistas de proceso revisar el estado de los mismos y controlar su ejecución, se basa en el protocolo simple de acceso a objetos (SOAP). La utilidad correspondiente al repositorio permite implementar procesos desde el administrador de modelos y está basada en el protocolo de autorización de versionamiento distribuido (WebDAV). La administración de las interfaces BPQL puede ser expuesta a través de servicios UDDI (Universal Description, Discovery and Integration) a fin de registrar los procesos, adquirir y descubrir los mismos en un catálogo de servicios web.

6. BPEL: (Business Process Execution Language) es un lenguaje basado en XML diseñado para compartir tareas en ambientes distribuidos –incluso a través de múltiples organizaciones- usando una combinación de servicios Web. Escrito por desarrolladores de BEA Systems, IBM y Microsoft, BPEL combina y substituye IBM's WebServices Flow Language (WSFL) y la especificación Microsoft's XLANG. (BPEL es también conocido como BPELWS o BPEL4WS). Usando BPEL, un programador describe formalmente un proceso del negocio que ocurre a través de la Web de tal forma que cualquier entidad pueda realizar unos o más pasos en el proceso de la misma manera.

7. WS-CDL: Es un lenguaje de descripción de coreografía de servicios, este lenguaje está basado en XML y describe las colaboraciones entre las entidades a través de un punto focal con un comportamiento común y complementario, donde el orden del intercambio de mensajes se determina a partir de los objetivos del negocio. Esta especificación de servicios Web ofrece un puente de comunicación entre los ambientes computacionales heterogéneos.

30

Figura 6: estándares BPM según BPMI

Gartner (2005), propone un conjunto de criterio que permiten evaluar las arquitecturas de BPM, estos son: (1) Herramientas gráficas – diseño, análisis, modelado y definición de procesos.; (2) Motor de la ejecución (“run-time”), máquina de estado que ejecuta el flujo de proceso definido. El motor puede invocar los servicios o las tareas automatizadas que el ser humano tiene que terminar. Los servicios se pueden proporcionar a través de la arquitectura de servicios y por otros proveedores (“outsourcers”); (3) Agilidad, implica la disponibilidad de realizar cambios a los procesos en ejecución, la administración de la lista de tareas y las prioridades del trabajo; (4) Herramientas para supervisar y para administrar flujos, incluye el funcionamiento de los procesos, el grado de terminación o las condiciones de finalización. Puede también cubrir los elementos que produjeron la finalización del proceso, compensación, balanceo de carga y transferencia, y; (5) Herramientas para el control de gestión a través de los datos almacenados que permiten las mediciones y los ajustes (control de proceso estadístico BAM) del negocio.

De acuerdo a esto, los requisitos funcionales con los que debe cumplir una aplicación de BPM, son los siguientes:

1. Análisis de procesos de negocio (BPA): se refiere a cuales procesos deben ejecutarse y cómo estos están estructurados, lo que implica las actividades de administración del modelo de procesos, actualización de formas, modelo organizacional (roles, grupos,

31

usuarios, departamentos, localidades, etc.), especificación de flujos, interfaz gráfica amigable y manejo estructurado de procesos.

2. Business Rule Engine (BRE): incluye las actividades de configuración de usuarios, configuración de áreas y localidades, asignación de responsables, tipos de casos y tipificaciones, reglas de notificación y escalamientos, detección de solapamientos, configuración de mecanismos de notificación, manejo de soluciones, modelos de acuerdos de servicio y capacidad para el manejo de excepciones.

3. Generación de códigos: se refieres las actividades de especificación de estándares, integración con tecnologías EAI, integración con herramientas de análisis, arquitectura WEB, soporte de arquitectura de servicios, compilación de procesos, soporte a procesos de larga duración, compensación y reverso de transacciones, manejo de colas, manejo de versiones, generación del flujo de trabajo, optimización de lista de trabajo y soporte e interacción.

4. Integración y Colaboración: incluye las actividades de actualización y modificación de procesos, control de configuraciones, desactivación y activación de procesos, exportación de datos, exportación de procesos, gestión de históricos, gestión de procesos, importación de datos, importación de procesos, migración de flujos de trabajo, administración de usuarios, facilidades de comunicación, reportes y administración.

5. Monitoreo de las Actividades del Negocio (BAM): incluye las actividades de monitoreo de procesos en ejecución, consola flexible de presentación gráfica (“Dashboard”), manejo de eventos y capacidad de análisis.

6. Interfaz de Aplicación: incluye las actividades de administración de patrones de eventos de interacción, administración de patrones de interfaz, mantenibilidad de la interfaz y usabilidad de la interfaz.

7. Optimización: incluye las actividades de manejo de escenarios, administración y manejo de servicios y administración y manejo de interfaces.

Según Gartner (Bell y Sinur, 2003), los vendedores principales están proporcionando soluciones propietarias de tecnologías y no estándares las cuales carecen generalmente de la agilidad ofrecida por la utilización de lenguajes de patrones y procesos tales como BPEL, estos vendedores intentan crear los flujos de trabajo pequeños que se pueden utilizar en contextos más generalizados, pero dejando a un lado la usabilidad.

Esto conlleva a la necesidad un marco referencial que integre estos conceptos, relación que se describe a continuación.

32

2.2.5 Relación entre el Uso de patrones y BPM

En base a todo lo antes descrito, sobre BPM, y los aspectos teóricos resumidos a través de la Figura 3, se propone un marco referencial integrado (ver, Figura 7) a fin de sortear todos los problemas planteados a través de esta investigación.

La Figura 7 muestra, según el nivel de abstracción cómo los estándares propuestos por el BPMI y OMG se relacionan con la taxonomía de patrones. Además de la representación de la arquitectura BPM integrada a través de un ADL (una arquitectura en que los patrones se expresan a través de componentes, las aplicaciones a través de componentes y patrones y los procesos a través de las aplicaciones y los patrones; todo esto en el marco de una metodología de desarrollo de software). La medición y trazabilidad se logra a través de la posibilidad de dotar a los patrones de especificaciones de calidad con el uso de ABAS, en el marco de un modelo de calidad (ISO9126 para la calidad del producto e ISO14598 para la calidad del proceso).

Figura 7: Marco Referencial para BPM sustentada en el uso de Patrones. (Bonillo, 2008)

33

Para la implementación de la metodología que se propone a través de esta tesis doctoral, es necesario la selección de un proceso caso de estudio, el cual en este caso se corresponde con el proceso de Gestión de Versiones de ITIL, por lo que a continuación se describen los procesos principales de ITIL.

2.2.6 Librería de Tecnología de la Información (ITIL)

ITIL son las siglas en inglés para Librería de Infraestructura de Tecnologías de Información, que no es más que una serie de documentos que definen un marco de trabajo de las mejores prácticas que permiten ofrecer servicios de Tecnologías de Información y Comunicación de mayor calidad, en cualquier empresa que utilice la tecnología. Este marco de trabajo cubre diferentes áreas, pero su principal enfoque está en la Gerencia de los Servicios de Tecnología de Información.

ITIL separa la Gerencia de los Servicios de Tecnología de Información en 2 sub-áreas: Entrega de Servicio (“Services Delivery”) y Soporte de Servicio (“Services Support”). Dentro de cada una de estas sub-áreas ITIL define los procesos relacionados a ellas de la siguiente forma:

Entrega de los Servicios (“Services Delivery”):

• Gestión de Nivel de Servicio (“Service Level Management”): El objetivo último de la Gestión de Niveles de Servicio es poner la tecnología al servicio del cliente. La tecnología, al menos en lo que respecta a la gestión de servicios de TI, no es un fin en sí misma sino un medio para aportar valor a los usuarios y clientes. La Gestión de Niveles de Servicio debe velar por la calidad de los servicios de TI alineando tecnología con procesos de negocio y todo ello a unos costos razonables. Para cumplir sus objetivos es imprescindible que la Gestión de Niveles de Servicio: Conozca las necesidades de sus clientes. Defina correctamente los servicios ofrecidos. Monitoree la calidad del servicio respecto a los objetivos establecidos en los Niveles de Acuerdo de Servicio (SLA).

• Gestión de Disponibilidad (“Availability Management”): El objetivo del proceso de Gestión de la Disponibilidad es optimizar la capacidad de la infraestructura de TI y la organización de soporte para la entrega de un nivel sostenido de disponibilidad que permita al negocio satisfacer sus objetivos. Esto se alcanza determinando los requisitos de disponibilidad del negocio y equipando estos a la capacidad de la infraestructura de TI y a la organización de soporte, además se debe asegurar que se proporcione el servicio acordado de disponibilidad.

• Gestión de Capacidad (“Capacity Management”): La Gestión de la Capacidad es la encargada de que todos los servicios de TI se vean respaldados por una capacidad de proceso y almacenamiento suficiente y correctamente dimensionada. Sin una correcta Gestión de la Capacidad los recursos no se aprovechan adecuadamente y se realizan inversiones innecesarias que acarrean gastos adicionales de mantenimiento y administración, o aún peor, los recursos son insuficientes con la consecuente

34

degradación de la calidad del servicio. Entre las responsabilidades de la Gestión de la Capacidad se encuentran: Asegurar que se cubran las necesidades de capacidad de TI tanto presentes como futuras. Controlar el rendimiento de la infraestructura de TI. Desarrollar planes de capacidad asociados a los niveles de servicio acordados. Gestionar y racionalizar la demanda de servicios de TI.

• Gestión Financiera (“Financial Management”): Aunque casi todas las empresas y organizaciones utilizan las tecnologías de la información en prácticamente todos sus procesos de negocio es común que no exista una conciencia real de los costos que esta tecnología supone. Esto conlleva a serias desventajas: Se desperdician recursos tecnológicos; No se presupuestan correctamente los gastos asociados, y; Es prácticamente imposible establecer una política consistente de precios. El principal objetivo de la Gestión Financiera es el de evaluar y controlar los costos asociados a los servicios de TI de forma que se ofrezca un servicio de calidad a los clientes con un uso eficiente de los recursos necesarios. Si la organización de TI y/o sus clientes no son conscientes de los costos asociados a los servicios no podrán evaluar el retorno a la inversión ni podrán establecer planes consistentes de inversión tecnológica.

• Gestión de Continuidad de Servicios (“IT Services Continuity Management”): La misión de la Gestión de Continuidad de Servicios de TI es soportar el proceso general de Gestión de Continuidad de Negocio asegurándose de que las facilidades de TI técnicas y de servicio (incluidos sistemas informáticos, redes, aplicaciones, telecomunicaciones, soporte técnico y escritorio de servicio) se puedan recuperar dentro de los márgenes de tiempo de negocio requeridos y acordados.

Soporte a los Servicios (“Services Support”):

• Escritorio de Servicio (“Service Desk”): El objetivo primordial, aunque no único, del Centro de Servicios es servir de punto de contacto entre los usuarios y la Gestión de Servicios de TI. Un Centro de Servicios, en su concepción más moderna, debe funcionar como centro neurálgico de todos los procesos de soporte al servicio: (1) registrando y monitorizando incidentes; (2) aplicando soluciones temporales a errores conocidos en colaboración con la Gestión de Problemas; (3) colaborando con la Gestión de Configuraciones para asegurar la actualización de las bases de datos correspondientes, y; (4) gestionando cambios solicitados por los clientes mediante peticiones de servicio en colaboración con la Gestión de Cambios y Versiones. Pero también debe jugar un papel importante dando soporte al negocio identificando nuevas oportunidades en sus contactos con usuarios y clientes.

• Gestión de Incidentes (“Incident Management”): La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible. La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a

35

restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.

• Gestión de Problemas (“Problem Management”): Las funciones principales de la Gestión de Problemas son: (1) investigar las causas subyacentes a toda alteración, real o potencial, del servicio de TI; (2) determinar posibles soluciones a las mismas; (3) proponer las peticiones de cambio (RFC) al proceso de Gestión de Cambios, necesarias para restablecer la calidad del servicio, y; (4) realizar Revisiones Post Implementación (PIR) para asegurar que los cambios han surtido los efectos buscados sin crear problemas de carácter secundario. La Gestión de Problemas puede ser: (a) reactiva: analiza los incidentes ocurridos para descubrir su causa y propone soluciones a los mismos, y; (b) proactiva: monitorear la calidad de la infraestructura de TI y analiza su configuración con el objetivo de prevenir incidentes incluso antes de que estos ocurran.

• Gestión de Configuración (“Configuration Management”): Las cuatro principales funciones de la Gestión de Configuraciones pueden resumirse en: (1) llevar el control de todos los elementos de configuración de la infraestructura de TI (CI) con el adecuado nivel de detalle y gestionar dicha información a través de la Base de Datos Centralizada de Configuración (CMDB); (2) proporcionar información precisa sobre la configuración de TI a todos los diferentes procesos de gestión; (3) interactuar con las Gestiones de Incidentes, Problemas, Cambios y Versiones de manera que estas puedan resolver más eficientemente las incidencias, encontrar rápidamente la causa de los problemas, realizar los cambios necesarios para su resolución y mantener actualizada en todo momento la CMDB, y; (4) monitorear periódicamente la configuración de los sistemas en el entorno de producción y contrastarla con la almacenada en la CMDB para subsanar discrepancias.

• Gestión de Cambios (“Change Management”): El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso de cambio para asegurar que, si éste se lleva a cabo, se haga de la forma más eficiente, siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y continuidad del servicio de TI. Las principales razones para la realización de cambios en la infraestructura de TI son: (a) solución de errores conocidos; (b) desarrollo de nuevos servicios; (c) mejora de los servicios existentes, y; (d) normativa legal.

• Gestión de Versiones (“Release Management”): La Gestión de Versiones es la encargada de la implementación y control de calidad de todo el software y hardware instalado en el entorno de producción. La Gestión de Versiones debe colaborar estrechamente con la Gestión de Cambios y de Configuraciones para asegurar que toda la información relativa a las nuevas versiones se integre adecuadamente en la CMDB de forma que ésta se halle correctamente actualizada y ofrezca una imagen real de la configuración de la infraestructura de TI. La Gestión de Versiones también debe mantener actualizada la Biblioteca de Software Definitivo (DSL), donde se guardan copias de todo el software en producción, y el Depósito de Hardware Definitivo (DHS),

36

donde se almacenan piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción.

• Una vez descrito el marco teórico que integra la tesis doctoral, a continuación se describe la metodología a través de la cual se propondrá en el ámbito de la gerencia de procesos de negocio con el uso de patrones, el logro de los objetivos específicos de esta investigación.

37

Capítulo III Metodología

En este Capítulo se describen las bases metodológicas utilizadas para realizar el trabajo de tesis doctoral, “la metodología constituye la médula del plan, se refiere a la descripción de las unidades de análisis, o de investigación, las técnicas de observación y recolección de datos, los instrumentos, los procedimientos y las técnicas de análisis”. (Tamayo, 2000).

3.1 Tipo de Investigación

De acuerdo al problema planteado, referido a la necesidad de proponer en las ciencias de la computación, en el área especifica de la ingeniería de software una metodología para la gerencia de los procesos de negocio sustentada en el uso de patrones, esta investigación doctoral se define del tipo Proyecto Factible. La misma consiste según la Universidad Experimental Simón Rodríguez (1999) en: “una proposición sustentada en un Modelo Operativo factible, orientada a resolver un problema planteado o a satisfacer necesidades en una institución o campo de interés nacional” (p. 79).

En atención a esta modalidad de investigación, se introducirán tres grandes fases en el estudio, a fin de cumplir con los requisitos involucrados en un Proyecto Factible. En la primera de ellas, inicialmente se desarrolla un diagnóstico de la situación existente en la realidad objeto de estudio a través del marco teórico, a fin de determinar la utilidad del uso de la metodología. En la segunda fase del proyecto y atendiendo a los resultados del diagnóstico, se formula un conjunto de propuestas conducentes al diseño de la metodología. En la tercera fase se aplica la metodología diseñada a un caso de estudio.

En esta investigación será necesario realizar una exploración práctica expresada a través de un caso de estudio, revisando el proceso de Gestión de Versiones en el dominio de los procesos de Soporte de Servicio de ITIL, estableciendo la realidad del fenómeno a estudiar, recopilando información sobre el proceso y la factibilidad de aplicar la metodología en el mismo.

3.2 Diseño de Investigación

El diseño de la investigación que sustenta este proyecto de tesis doctoral será el de Campo, ya que se recolectarán datos obtenidos directamente de la realidad, lo que permitirá que la investigación adquiera gran valor debido a la posibilidad de levantar la información necesaria para el diseño de la metodología. En la Investigación de Campo los datos de interés para este trabajo se reunirán en forma directa de la realidad, es decir, el fenómeno será estudiado en la situación real donde se produce. Sabino, C. (2000).

El diseño de esta investigación doctoral también es denominado documental, dado que se sustentara en investigaciones de otros autores cuya fuente de información siempre procede

38

de documentos escritos, pues esa es la forma uniforme en que se emiten los informes científicos.

3.3 Población y Muestra

Para Tamayo y Tamayo, una población está determinada por sus características definitorias, por tanto, el conjunto de elementos que posea esta características se denominará población, la cual es la totalidad del fenómeno a estudiar, en donde las unidades poseen una característica común, que se estudia y da origen a los datos de la investigación. (Tamayo, 2000).

Dado que la investigación pretende presentar una metodología, la muestra deberá ser definida de tal forma de poder abstraer características que permitan su aplicación y estudio a otras organizaciones ofreciendo conclusiones pertinentes.

La población de esta investigación doctoral se corresponde con los procesos de negocio de las empresas actuales en diferentes dominios. Dado que esta población es muy amplia es necesario reconocer un dominio especifico como los son los procesos de Gerencia de TI que se aplican según el estándar internacional ITIL a cualquier organización.

La unidad de análisis para esta investigación doctoral será un proceso en específico de ITIL: el proceso de Gestión de Versiones propuestos, el cual representa el caso de estudio y la muestra de la investigación doctoral.

Básicamente las muestran se dividen en dos grandes ramas: las muestras no probabilísticas y las muestras probabilísticas. En esta última todos los elementos de la población tienen la misma posibilidad de ser seleccionados. En las muestras no probabilísticas, la elección no depende de la probabilidad, sino de las causas relacionadas con las características del investigador o del que hace la muestra. Aquí el procedimiento no es mecánico, ni en base a fórmulas de probabilidad, sino que depende del proceso de toma de decisiones de una persona o grupo de personas.

En particular, esta investigación doctoral busca muestras no probabilísticas, debido a que suponen un procedimiento de selección informal y un proceso arbitrario. La ventaja de este tipo de muestra es su utilidad para un determinado diseño de estudio, que requiere no tanto de una representatividad de los elementos de la población, sino de una cuidadosa y controlada selección de sujetos con ciertas características especificadas previamente en el planteamiento del problema.

Sin embargo, hay diversas clases de muestras no probabilísticas tales como:

• Muestras de sujetos voluntarios: la elección de los individuos que serán sujetos dependen de circunstancias fortuitas.

• Muestras de expertos: es utilizada en estudios que requieren la opinión de sujetos expertos.

39

• Sujetos tipos o Stakeholders: se utilizan en investigaciones de tipo exploratorio, donde el objetivo es la riqueza, profundidad y calidad de la información, y no la cantidad y estandarización.

• Muestras por cuota: se utilizan en estudios de opinión y de mercadotecnia.

Para identificar todos estos factores el estudio tomara una muestra no probabilística de la clase de sujeto tipo o stakeholders, del proceso de Gestión de Versiones de ITIL.

El termino Stakeholders es utilizado para referirse a un grupo de individuos identificables quienes pueden ser afectados o son afectados por un sistema.

Ciertas investigaciones sobre el uso de stakeholders describen algunos métodos para identificarlos: (1) realizando grupos demográficos (sexo, edad, cargo, etc.); (2) preguntándole a las personas, quiénes de ellas piensan que deben ser considerados como principales stakeholders; (3) estudiando (o creando) cuentas etnográficas para encontrar quiénes expresan intereses pertinentes.

3.4 Técnicas e Instrumentos de Recolección de Datos

Dado que el diseño de investigación documental depende fundamentalmente de la información que se recoge o consulta en documentos, entendiéndose este término, en sentido amplio, como todo material de índole permanente, es decir, al que se puede acudir como fuente o referencia en cualquier momento o lugar, sin que se altere su naturaleza o sentido, para que aporte información o rinda cuentas de una realidad o acontecimiento, la técnica e instrumento de recolección de datos de datos empleada en esta investigación doctoral será: la revisión bibliográfica, la encuesta, le entrevista y la observación descriptiva, las cuales se describen a continuación:

• Revisión Bibliográfica: Se debe recurrir a la técnica de revisión bibliográfica; tanto de libros, folletos, documentos, revistas, artículos y seminarios, los cuales vienen a brindarle al investigador todo el soporte del marco teórico, lo que significa que se percata de todo lo escrito o que esté relacionado con el tema que escogió como investigación. La Revisión Bibliográfica, se utiliza como base complementaria a la investigación central, con el fin de recopilar y revisar todos aquellos documentos que permitan confrontar el aspecto teórico con la situación real o práctica dentro del modelo de evaluación de las capacidades tecnológicas necesarias en el mercado de la gerencia de procesos de negocio a través del uso de patrones. Es importante señalar que esta revisión se efectúa antes y durante la investigación, con el objetivo de cotejar información, obtener nuevas ideas, indagar la naturaleza de los datos y realizar nuevas conclusiones.

• Encuesta: Entendiéndose ésta, “como un conjunto de preguntas recogidas en un cuestionario para conocer la opinión del público sobre un asunto determinado” (Encarta, 1998, p. 85). La Encuesta, será dirigida a la población seleccionada de manera intencionada. Este instrumento sirve para obtener información acerca de los principales

40

aspectos que contendrá la metodología de gerencia de los procesos de negocio sustentada en el uso de patrones, precisando los aspectos a considerar para la elaboración de dicha metodología. Este tipo de instrumento, permite obtener información que por lo general el individuo no suministra durante una entrevista, y que puede ser relevante para la investigación a desarrollar.

• Entrevista: la cual consiste en la obtención de los datos de manera verbal por parte de un sujeto informante”. Esta se caracteriza por establecer una relación directa con el entrevistado, quien deberá suministrar la información solicitada en forma verbal. La ventaja de utilizar esta técnica, es que la persona entrevistada conversa libremente, proporciona la información de manera directa y espontánea.

• Observación Descriptiva: La observación descriptiva es la más común entre las técnicas de investigación; la observación sugiere y motiva los problemas y conduce a la necesidad de la sistematización de los datos (Tamayo, 2000, p. 55). Esta técnica se utiliza en este estudio sin necesidad de contar con un instrumento de registro lo que facilita su aplicación en el lugar donde ocurren los hechos. En esta etapa se toman en cuenta todos los elementos, que de una u otra forman guardan relación con la investigación. Se efectúa una observación de tipo participante directa, ya que el autor durante sus 11 años de carrera profesional ha pertenecido a diferentes organizaciones de gerencia de sistemas tecnológicos y posee una certificación formal en los procesos de soporte de servicio de ITIL, además de la experiencia de 6 años en el área de gerencia de procesos de negocio.

3.5 Procedimiento de Análisis de Datos

Con respecto a la medición de los instrumentos se utilizará el juicio de expertos, ésta actividad se realiza durante todas las fases de la investigación, a fin de someter la metodología, a la consideración de Profesionales de Ingeniería de Software para facilitar el montaje técnico y metodológico de los instrumentos, tanto en sus aspectos de estructura como de contenido, con la finalidad que lo evalúen pedagógicamente, de tal forma de tomar como base sus observaciones, para hacer las correcciones que tuvieran lugar, garantizando de esta forma la calidad y efectividad de la metodología.

En relación a la presentación y análisis de los datos se tabulan los mismos, donde cada respuesta se expresará en términos de frecuencias absolutas y relativas representadas en porcentajes (%) y para aquellas preguntas de opinión se tomará en cuenta el criterio de repetición de contenido, con el objeto de determinar su frecuencia. Por último, se elaboran cuadros estadísticos y gráficos para su mejor visualización, a fin de obtener información para formular conclusiones y recomendaciones.

41

3.6 Metodología a utilizar en función de los objetivos específicos de la investigación (SESL)

El procedimiento metodológico a seguir para lograr los objetivos específicos, se constituirá en la aplicación de una instanciación de la metodología Systemic Evaluation for Stakeholder Learning (SESL) propuesta por Magnus Ramage en 1997, para los sistemas de trabajo cooperativo (Cooperative Work): “La combinación de la tecnología, personas, y la organización que facilita la comunicación y coordinación necesaria para que un grupo trabaje efectivamente con la finalidad de alcanzar un objetivo común”.

Según SESL la construcción de una metodología es una tarea compleja, metodológicamente difícil (debido a que los métodos comúnmente utilizados en los dominios son imprecisos al ser generalizados en múltiples problemas), prácticamente confusa (los efectos del cambio pueden verse sólo después de un largo período de tiempo y en diferentes sitios), psicológicamente compleja (los diseñadores y usuarios de la metodología deben adoptar un estilo copérnico, cambiando desde la tecnología en uso, hasta la organización) y políticamente frustrante (al iniciar la utilización de la metodología en la organización empieza a verse la poca prioridad que tiene y se inician los conflictos de interés).

Debido a la complejidad de la tarea, el diseño de una metodología dependerá de los diferentes significados que tiene el término para diferentes personas. En el ambiente de computación, suele utilizarse el término metodología como “el estudio de un conjunto de métodos, herramientas y técnicas que se asocian a la utilización de un sistema de computación con la finalidad de hacerlo mejor” o “los métodos, herramientas y técnicas para determinar donde el sistema de computación cumple con un conjunto de criterios o requerimientos”.

El criterio o las acciones para mejorar, pueden referirse a cuestiones de la ingeniería de software (eficacia, el funcionamiento del sistema, en los cuales la metodología y sus métodos son más asociada como una prueba cerrada); o se puede relacionar con las mejoras de uso, el logro de las especificaciones y requerimientos. Es por esto que el término metodología puede ser visto dependiendo del objetivo del evaluador, pero usualmente, aislado del mundo real.

De esta forma la relación entre la metodología y el mundo real es poca, omitiendo los diferentes puntos de vistas y perspectivas, y no involucrando un aprendizaje real. Una metodología que propone cómo sortear estas deficiencias es la SESL, para los sistemas de trabajo cooperativo, con la finalidad de evaluar un dominio a fin de utilizar una herramienta, implementar un método o proponer una nueva metodología, entre los cuales se enmarca este trabajo de investigación doctoral.

Esta metodología propone los siguientes pasos dentro de un flujo de estados:

1. Determinar la Naturaleza del Sistema.

2. Determinar el tipo de evaluación.

42

3. Identificar grupo de individuos que pueden ser afectados o que afectan al sistema.

4. Estudiar y Analizar preguntas claves.

5. Obtener la retroalimentación de los resultados.

Los pasos propuestos por la metodología SESL, se relacionan con las fases que rigen un Proyecto Factible de la siguiente forma:

1. Diagnostico de necesidades, lo cual se realizara a través del paso de determinación de la naturaleza del sistema de la metodología SESL;

2. La Formulación de la propuesta metodológica, a través de los pasos de determinación del tipo de evaluación, la identificación de los “stakeholders” y el estudio de las preguntas claves de SESL, y

3. El análisis de la factibilidad de la aplicación de la metodología a los procesos de Soporte a los Servicios de ITIL como caso de estudio, lo que se corresponde con el paso de obtención de retroalimentación de los resultados de la metodología SESL. Estos pasos se describen con detalle a continuación:

3.6.1. Determinar la naturaleza del sistema

Como SESL es una metodología para evaluar sistemas cooperativos (CSCW), es de vital importancia decidir cuál es el sistema a evaluar, a fin de utilizar una herramienta, implementar un método o proponer una metodología en este dominio.

Se puede establecer a partir de estudios anteriores cómo estos sistemas son utilizados dependiendo del contexto, la organización y la situación cultural. Se debe estudiar teóricamente el “sistema social” – el contexto dentro del cual la tecnología se encuentra, sin referenciar a la tecnología como tal, ignorando el hecho de que la tecnología cambia la estructura organizacional y la cultura, enfocándose en el estudio inicial del sistema social o técnico, que es lo que el autor determina como el estudio de la naturaleza del sistema. Para este estudio se representa el sistema del cual se quiere inferir la metodología utilizando la teoría general de sistemas.

3.6.2. Decidir el tipo de evaluación

Es de mucha ayuda considerar que tipo de evaluación se va a conducir. No tener esto claro puede invalidar los criterios del evaluador. Ramage propone seis tipos de evaluación:

1. Evaluación de los efectos del sistema.

2. Evaluación formativa.

3. Evaluación de conceptos (en proyectos de investigación doctoral).

4. Evaluación exclusivamente de los efectos organizacionales y partes psicológicas del sistema.

5. Evaluación para la compra de nuevos productos.

43

6. Evaluación de los efectos de un sistema CSCW en la Organización.

Las siguientes preguntas simbolizan la forma clásica de evaluación: ¿Qué pasa cuando un nuevo sistema de computación es introducido dentro de una organización?, ¿Cómo éste cambia el trabajo de la organización, sus miembros y los resultados? (tales como las ganancias), ¿Cómo estas tecnologías cambian de acuerdo a las necesidades de la organización?.

Algunos modelos típicos de estos estudios de evaluación son: la investigación de cada pregunta y, como realizar ésta dentro de la organización; se estudia que es lo que se esta haciendo, y se realizan entrevistas; se estructuran las ideas en términos de la teoría preferida y; se presenta una conclusión a los miembros de la organización. De esta forma se realiza algo muy parecido a una investigación cualitativa. Es usual que en este tipo de investigación el investigador/evaluador sea alguien externo a la Organización, normalmente denominado consultor.

De igual forma los miembros de la organización realizan sus propias evaluaciones sobre el efecto de los sistemas: los gerentes y supervisores necesitan saber que está sucediendo, para decidir si deben realizar algún tipo de cambio.

3.6.3. Identificar los individuos (Stakeholder) que afectan el sistema

La próxima pregunta a realizar es, quiénes son los stakeholders y en que están interesados. Una simple regla es buscar a quienes afecta, dependen de o pueden influenciar al sistema, y en que forma son afectados o influenciados por el sistema. Otra forma, es tener un grupo representativo que en conjunto construyen un mapa de stakeholders.

3.6.4. Estudiar y Analizar: Preguntas Claves

El análisis del sistema podría depender del estudio exacto de los métodos utilizados y el tipo de evaluación realizada. Un experimento de laboratorio podría tener diferentes tipos de relaciones entre el estudio y el análisis etnográfico. Nuevamente esto podría depender del conocimiento teórico del evaluador.

Una vez establecidas y analizadas las preguntas claves es necesario obtener la información asociada a estas preguntas en la Organización, la metodología no sugiere una técnica en especial sin embargo las que se utilizaran serán las indicadas como técnicas e instrumentos de recolección de datos.

3.6.5. Retroalimentación de los resultados

La comunicación es de vital importancia en la evaluación: al menos indicarle a las personas los resultados de la evaluación y qué es lo que se ha determinado a través de la misma. La siguiente parte es realizar el proceso de construir la decisión con la finalidad de utilizar una herramienta, implementar un método o proponer una metodología.

A continuación a partir de SESL se formula la nueva metodología.

44

Capítulo IV Formulación de la Metodología de Gerencia de Procesos de Negocio Sustentada en el Uso de Patrones

En este Capítulo se formula la metodología de gerencia de procesos de negocio sustentada en el uso de patrones, aplicando los pasos propuestos por la metodología SESL planteada en el Capítulo anterior.

4.1. Naturaleza del Sistema

Inicialmente la metodología SESL reseña que es de vital importancia decidir cual es el sistema a evaluar o medir a fin de formular una metodología. De acuerdo como se ha descrito en el Capítulo II Marco Teórico, la presente investigación plantea una metodología para la gerencia de los procesos de negocio sustentada en el uso de patrones. De tal forma que el sistema objeto de estudio es descrito en el marco teórico de esta investigación doctoral.

Dado que la metodología se especificará en el dominio particular de un caso de estudio representado por los procesos de Soporte a los Servicios propuesto por ITIL, a continuación se describirá la naturaleza del dominio donde se ejecutan estos procesos: la organización de soporte interno, la cual enmarca a la gerencia de tecnología de la información y se asocia a los procesos de soporte que brindan los operadores a los empleados de la compañía a través de un escritorio de ayuda (service desk, helpdesk o call center), directamente desde el centro de atención (utilizando las herramientas de control remoto de fallas y / o el soporte telefónico) o en sitio enviando a un técnico de servicio de campo, con la finalidad de reparar tanto fallas en los computadoras personales, así como también en los dispositivos asociados a la red que los empleados utilizan (servidores, impresoras de red, etc.).

Utilizando la teoría general de sistemas como marco referencial para determinar la naturaleza del sistema del dominio en el cual se propondrá el caso de estudio de la metodología puede describirse como un conjunto de ENTIDADES caracterizadas por poseer ciertos ATRIBUTOS, los cuales mantienen RELACIONES entre sí y están localizados en un determinado AMBIENTE de acuerdo a un cierto OBJETIVO.

La representación del sistema de estudio utilizando la teoría general de sistemas, presenta una utilidad práctica, ligada a la sencillez, proponiendo un enfoque top-down en su descripción. La metodología que se propone en esta investigación doctoral, está basada en una conjunción de los conceptos relativos a la gerencia de los procesos de negocio y los patrones de software, la organización de soporte interno, los objetivos del evaluador y la teoría general de sistemas. (Bonillo, 2004a).

45

La Gerencia de los Procesos de Negocio de Soporte a los servicios propuesto por ITIL (GPNSOP) puede ser representado en términos de la teoría general de sistemas de la siguiente manera: GPNSOP= <Entidades, Atributos, Relaciones, Ambiente, Objetivos, Control, Métodos> (e.q. 1)

GPNSOP= <Entidades ={Usuarios, Escritorio de Ayuda, Servicio de Campo, Gerencia de TI},

Atributos ={Propiedades distinguibles de la entidades},

Relaciones ={ Usuarios-Helpdesk (atención telefónica o remota) M:1,

Usuarios-Servicio de Campo (soporte en sitio) M:1,

Usuarios-Gerencia de TI (acuerdo de servicio) M:1,

Helpdesk-Servicio de Campo (asignación de reporte) M:1,

Helpdesk-Gerencia de TI (gestión soporte telefónico o remoto y

acuerdo de servicio) 1:1,

Servicio de Campo-Gerencia de TI (gestión soporte en sitio y

acuerdo de servicio) 1:1},

Ambiente ={organización de soporte interno}

={Usuarios, Escritorio de Ayuda, Servicio de Campo, Gerencia de TI},

Objetivos ={sistema, ambiente, observador, consultor},

Control ={Sensores, Dispositivos, Unidades activadoras}

Métodos ={Ecuaciones y Procesos} >

Seguidamente se describen cada uno de estos componentes.

4.1.1 Entidades

Representan la esencia del sistema con los ATRIBUTOS que determinan las propiedades cuantitativas (dimensional) y cualitativas (no dimensional) de cada una de estas ENTIDADES. Como se muestra a continuación: Entidades = {Grupo de Personas ó Stakeholders básicos de la Metodología}

{Usuarios, Escritorio de Ayuda, Servicio de Campo, Gerencia de TI}

(e.q. 2)

Usuarios: personas que por su definición de negocio, establecen una relación laboral y / o administrativa con la empresa con la finalidad de obtener un salario, y que realizan labores que involucran la utilización de un medio físico tecnológico, el cual puede ser monitoreado y reparado en forma remota o local, y poseen los siguientes atributos: realizan su trabajo a través de computadores personales de escritorio o portátiles, (las cuales deben adaptarse a la gran cantidad de posibilidades de conexión, ancho de banda, actualizaciones de software, etc.) dentro o fuera de la empresa (desde sus oficinas, hogares u otras localidades). Acceden

46

los sistemas de información de la Organización que sustentan el negocio y que se ejecutan en una computadora que también puede ser monitoreado en forma local o remota.

Escritorio de Ayuda (Service Desk): Conjunto de empleados que por su condición profesional aseguran telefónicamente o por control remoto, en primer nivel de soporte, la continuidad de los sistemas de hardware y software que apoyan el logro de los objetivos de los usuarios. Los atributos principales del Escritorio de Ayuda son: los empleados son organizados de acuerdo a su perfil de soporte en grupos y en la misma localidad física, lo cual define un call center, la atención se realiza normalmente en forma telefónica (a través de una central que puede direccionar las llamadas, según el perfil del empleado – ACD - e inclusive, direccionar las llamadas y la información del cliente contenida en los sistemas de información existentes – CTI), y actualmente a través de contactos por Web, correo electrónico y salas de Chat (Contact Center), con un perfil de comunicación verbal y un nivel de comprensión del negocio alto, desarrollando la capacidad de clasificar el incidente del usuario dentro de una taxonomía que permita resolverlo según los estándares de calidad y los acuerdos de servicio, la consulta a bases de datos de conocimientos y el uso de otras herramientas tecnológicas que permiten dar respuesta efectiva al usuario según el flujo de trabajo establecido en el negocio.

Servicio de Campo: Conjunto de empleados que por su condición profesional aseguran en sitio (en segundo nivel de soporte), la continuidad de los sistemas de hardware y software que apoyan el logro de los objetivos de los usuarios (a través de los procesos de gestión de problemas, cambios, versiones, configuraciones y acuerdos de servicio).

Con los siguientes atributos: poseen los conocimientos y habilidades específicas asociadas a resolver problemas complejos de soporte (especialistas), garantizando la operatividad de la tecnología de información, además, de los mecanismos que le permiten trasladarse hasta el usuario y resolver el problema en sitio. Instalan y configuran las computadoras personales de escritorio y portátiles, así como los servidores, las redes, los servicios de telefonía, y las aplicaciones de software, además, del control de los activos y los cambios realizados sobre los mismos, y las plataformas tecnológicas para garantizar la continuidad del negocio. No necesariamente pertenecen a la misma organización a la cual se presta el soporte, pueden ser empleados de un outsourcing externo de soporte de segundo nivel (proveedores).

Gerencia de Tecnología de la Información: Conjunto de empleados que por su condición profesional garantizan la excelencia y continuidad efectiva del negocio de TI, a través de la gerencia de todos los componentes de TI, orientados a la consolidación y crecimiento de la organización, mediante la exitosa consecución, implantación, integración de productos y servicios tecnológicos para apoyar el logro de los objetivos de los usuarios. Con atributos de: gerencia de la TI, toma de decisiones en los procesos operacionales y de entrega de servicios, aseguramiento y negociación de los acuerdos de servicio y la calidad en el servicio, con capacidades de auditar al Escritorio de Ayuda y a Servicio de Campo, para gestionar la continuidad del negocio.

47

Estas entidades establecen las relaciones que se muestra a continuación.

4.1.2 Relaciones

Entre las ENTIDADES anteriormente citadas se producen las siguientes relaciones (ver, Figura 8): Relaciones ={ Usuarios-Helpdesk (atención telefónica o remota) M:1,

Usuarios-Servicio de Campo (soporte en sitio) M:1,

Usuarios-Gerencia de TI (acuerdo de servicio) M:1,

Helpdesk-Servicio de Campo (asignación de reporte) M:1,

Helpdesk-Gerencia de TI (gestión soporte telefónico o remoto y

acuerdo de servicio) 1:1,

Servicio de Campo-Gerencia de TI (gestión soporte en sitio y

acuerdo de servicio) 1:1}

(e.q. 3)

Estas relaciones se desarrollan y desenvuelven en el marco del ambiente del sistema que se describe seguidamente.

4.1.3 Ambiente

Está constituido por todas las entidades que al determinarse un cambio en sus atributos o relaciones pueden modificar el sistema, de esta forma el ambiente es el conjunto determinado por las entidades: Usuarios, Escritorio de Ayuda, Servicio de Campo y Gerencia de TI. Ambiente = {Entidades y su sinergia}

= {Usuarios, Escritorio de Ayuda, Servicio de Campo, Gerencia de TI y las relaciones}

(e.q. 4)

Todas estas entidades se enmarcan en lo que se denominará la Organización de soporte interna, y que definen un sistema abierto: conjunto de partes en constante interacción (lo cual resalta la característica de interdependencia de las partes) constituyendo un todo sinérgico (el todo es mayor que la suma de las partes), orientado hacia determinados propósitos (con comportamiento teleológico, es decir, orientado hacia los fines) y en permanente relación de interdependencia con el ambiente externo (interdependencia que debe entenderse como la doble capacidad de influenciar el medio externo y de ser influenciado por él), y con controles por retroalimentación positiva y negativa

En la siguiente figura, se presenta la organización de soporte interno en términos de la teoría general de sistemas.

48

Empresa

Organización de Soporte Interno

USUARIOS HELPDESK

CAMPOGERENCIATI

Soporte Telefónico o Remoto

Soporte en Sitio

Asignación de Soporte

Gerencia Soporte Telefónico o remoto y Acuerdos de Servicio

Gerencia Soporte en Sitio y Acuerdos de Servicio

Acuerdos de Servicio

1M

M

1

M

1

1 1

1

1

1

M

Figura 8: Organización de Soporte Interno en términos de Sistemas.

4.1.4 Objetivos

Entre los objetivos de la Organización de Soporte Interno en términos de Sistemas, pueden representarse como:

Objetivo = sistema, ambiente, observador, consultor (e.q. 5)

Objetivo del Sistema: Brindar a las organizaciones la posibilidad de detectar y resolver incidentes en forma remota o en sitio, asegurando los niveles de servicio establecidos a través de la gerencia de tecnología de la información, reparando los componentes de hardware y software del usuario, configurando los valores de las aplicaciones y del software de sistema, transfiriendo soluciones de software a la computadora personal, configurando software, proporcionando formación a los usuarios (o incluso a otros miembros del Helpdesk), con un enfoque basado en ejemplos, reduciendo al mínimo la necesidad de enviar al personal de Servicio de Campo a otras ubicaciones, acelerando la

49

identificación de las fallas en primer nivel, y el aumento de la productividad del Escritorio de Ayuda y Servicio de Campo, tanto en la cantidad de llamadas como en la velocidad de respuesta, atención y calidad de servicio.

Objetivo del Ambiente: Sustentar y Controlar de manera eficiente la atención de los usuarios a través de la organización de soporte y de acuerdo a la gerencia de los procesos y los intereses del negocio.

Objetivo del Observador: Verificar a través de un caso de estudio (procesos de gestión de versiones de ITIL) la eficacia de la metodología para la gerencia de los procesos de negocio sustentada en el uso de patrones.

Objetivo del Consultor: Análisis, diseño, construcción, y mejora de la metodología de gerencia de procesos de negocio sustentada en el uso de patrones.

En forma general el macro objetivo de la metodología de gerencia de procesos de negocio sustentada en el uso de patrones, puede expresarse a través de la maximización de la eficacia (relación entre eficiencia y efectividad) de la organización de soporte interno a través de los procesos de negocio de soporte a los servicios es los cuales ITIL ofrece estándares internacionales.

La efectividad se puede definir como la relación entre los resultados logrados y los objetivos propuestos por la organización.

Efectividad = ObjetivosSalidas

(e.q. 5.1)

La efectividad se vincula con la productividad, a través del impacto en el logro de mayores y mejores productos, sin embargo adolece de la noción de uso de recursos.

Por su parte, la eficiencia es la relación entre el “qué” y el “cómo”; en consecuencia es la relación entre la causa formal y la causa eficiente [CAL 96].

Eficiencia = EntradasSalidas

(e.q. 5.2)

Al considerar la efectividad y la eficiencia por separado, se obtienen dos dimensiones diferentes, la primera caracterizada por un estilo efectivista ya que considera la efectividad como único criterio donde lo importante es el resultado sin importar el costo; y la segunda caracterizada por una preocupación exagerada de la eficiencia que lleva a poner énfasis en la administración, descuidando el cumplimiento de los objetivos, de los resultados de la calidad y de la productividad.

Finalmente la relación necesaria entre la eficiencia y la efectividad se logra a través de la eficacia, es decir la relación existente entre los recursos usados, los objetivos de la organización y el uso de insumos para lograr estos objetivos:

50

Eficacia = dEfectivida

Eficiencia=

EntradasObjetivos

(e.q. 5.3)

Si el ambiente es dinámico, la eficacia estará determinada por un balance entre la eficiencia y la efectividad. En cambio, si se está en presencia de ambientes estables se procura maximizar tanto la eficiencia como la efectividad.

En el caso particular de la metodología, se busca maximizar en la gerencia de los procesos de negocio, la ecuación:

Max(EntradasObjetivos )= Max(

CostosSLA )

(e.q. 5.4)

Tanto la eficacia como la eficiencia y efectividad permiten medir y conocer en cualquier momento el grado en que se están satisfaciendo los atributos que los clientes o usuarios valoran de los productos o servicios recibidos.

A continuación se presentan las características y los principios que dictan el comportamiento del sistema.

4.1.5 Características

Las características del Sistema son las siguientes:

Adaptable: Este sistema se adapta a las exigencias del entorno, lo que implica cambios estructurales o de proceso. Por ejemplo, cuándo debe afrontar a más de un tipo o clase de usuarios (usuarios internos y usuarios de otras compañías en calidad de “outsourcing”), el Escritorio de Ayuda, Servicio de Campo y la Gerencia de TI se extienden y cambian su estructura hasta el punto de ofrecer en “outsourcing” los propios servicios de la organización de soporte a otros proveedores brindado igualmente el servicio de atención remota.

Estable: Se evidencia en el sistema efectividad ante cambios externos, además, de un equilibrio temporal durante estos cambios hacia la estabilidad del sistema. Por ejemplo, se pueden modificar los acuerdos de servicio según el tipo de cliente, su ubicación física o su dependencia estructural con la finalidad de garantizar un soporte especifico en un momento determinado y de acuerdo a las necesidades de la organización, como confirmación del soporte remoto para las computadoras personales, o control remoto automático en el caso de los servidores, e igualmente el Escritorio de Ayuda y Servicio de Campo pueden adaptar sus turnos y formas de atención con la finalidad de tener en cuenta eventos especiales y fallas generales como la caída de un troncal de red.

51

Eficiente: El sistema atiende los objetivos con economía de medios, maximizando la rentabilidad de la organización de soporte. Por ejemplo, gracias a los beneficios de las herramientas de control remoto se disminuyen los costos a todo lo largo del ciclo de atención del cliente.

Sinergia: El sistema es mayor que la suma de sus partes y amplia sus capacidades individuales, gracias a las propiedades emergentes. La organización de soporte interno sustenta el negocio de soporte propio y el de “outsourcing”.

4.1.6 Principios

Principios de los sub-sistemas y sus elementos:

Interacción: Los elementos del sistema intercambian datos e información entre sus sub-sistemas, sus elementos y también con el ambiente externo e interno del sistema. Toda la Información de los clientes es almacenada con la finalidad de acelerar el proceso de control remoto y llevar un registro de auditoria. Dentro de este mismo registro se definen los perfiles que permiten determinar que tipo de servicio se presta al cliente.

Determinismo: Comportamiento esperado de acuerdo a las entradas y salidas (intercambio controlado y no controlado). La Gerencia de TI establece los acuerdos de servicio que permiten a través de un reporte de actividades o desempeño medir la satisfacción de los usuarios, la evaluación del Escritorio de Ayuda y de Servicio de Campo y las medidas correctivas de la organización de soporte.

Subsidiaridad: Es la propiedad de los sistemas de formar parte de otros de mayor nivel y de estar conformados por otros de menor nivel. La Organización de soporte interno pertenece a la Organización total de la empresa y enmarca al Escritorio de Ayuda, a Servicio de Campo y a la Gerencia de TI la cual a su vez tiene empleados que pueden ser atendidos en forma local o a través de las herramientas de control remoto.

Equifinalidad: Lograr el mismo objetivo de diferentes maneras: El soporte remoto puede ser local en la computadora personal o remota del cliente o puede ser en sitio, a pesar que el contacto con el cliente sea en forma telefónica, por Web, correo electrónico o por Chat. La regulación del comportamiento del sistema se realiza a través del sub-sistema de control, el cual actúa como un sistema dinámico diseñado para interactuar con el sistema a controlar, logrando un sistema con características propias.

4.1.7 Sub-Sistema de Control

Puede describirse el sistema en términos de control de acuerdo a la ley de variedad de requisitos, como un conjunto de sensores, dispositivos de control y unidades activadoras que se relacionan entre sí para garantizar la eficiencia del sistema objeto, determinar desviaciones, e indicando las acciones correctivas.

Control ={Sensores, Dispositivos, Unidades activadoras} (e.q. 6)

52

A través del Sistema de Administración y Medición y los constantes ciclos de retroalimentación de la organización de soporte interno, se capturan las medidas de rendimiento de los procesos, se realiza un control comparativo con los registros históricos de las medidas esperadas y se crea un plan de ajuste para los procesos como se muestra en la Figura 9. Si se presentan medidas de rendimiento alejadas de las esperadas o que no representen una mejora considerable al proceso anterior, se crea un plan de ajuste (Retroalimentación Negativa –Feedback-). Si ocurre alguna eventualidad, se participa para afrontar la contingencia (Feedback). Si antes de implantar el proceso, se somete a una simulación, éste podrá ser ajustado con mayor precisión a los datos reales (Retroalimentación Positiva: Feedforward).

Figura 9: Sistema de Control de la Organización de Soporte Interna.

Una vez descrito el sistema a evaluar utilizando la teoría general de sistemas, el siguiente paso de la metodología SESL, consiste en determinar el tipo de evaluación a conducir.

4.2 Tipo de Evaluación

La metodología SESL, sugiere la existencia de cinco tipos de evaluación:

• Evaluación formativa.

• Evaluación de los efectos del sistema.

• Evaluación de los efectos organizacionales y partes psicológicas del sistema.

Reporte de Falla del Usuario

Soporte Telefónico, Remoto o en Sitio Resolución de Falla

Medidas de Rendimiento

Control ComparativoPor fases

Medidas de rendimiento esperadas

Plan de Ajuste

53

• Evaluación de conceptos (en proyectos de investigación doctoral), y

• Evaluación para la compra de nuevos productos.

El tipo de evaluación que se realizara al sistema objeto de estudio, será la evaluación de los conceptos presentes en la Propuesta de Metodología para la Gerencia de los Procesos de Negocio Sustentada en el Uso de Patrones. Esta investigación doctoral busca validar y relacionar conceptos de las ciencias de la computación, específicamente en el área de la ingeniería de software a fin de administrar procesos de negocio a través de la utilización de patrones, permitiendo la reutilización de mejores prácticas, estableciendo relaciones inexistentes en la actualidad y auspiciando la calidad del proceso y el producto de software a través de la revisión del uso y la relación de los diversos patrones en el dominio BPM.

4.3 Stakeholders

La próxima pregunta a realizar es, quiénes son los stakeholders y en qué están interesados. Una simple regla es buscar a quiénes afecta, dependen de o pueden influenciar al sistema; y en que forma son afectados o influenciados por el sistema.

En el sistema objeto de estudio, los stakeholders pueden ser definidos a través de las entidades que según la teoría general de sistemas integran la organización de soporte interno: Usuarios, Escritorio de Ayuda, Servicio de Campo y Gerencia de TI.

Stakeholders = {Entidades} (e.q. 2)

Los intereses a considerar por cada uno de estos stakeholders son los siguientes:

Usuarios: Maximizar la eficiencia de la resolución.

Escritorio de Ayuda: Minimizar el tiempo de atención. Maximizar el cumplimiento del acuerdo de servicio de primer nivel de soporte (porcentaje de llamadas que deben ser resueltas en primer nivel de soporte). Maximizar la resolución de problemas remotos. Maximizar el nivel de experticia del usuario a través de un enfoque basado en aprendizaje. Minimizar los costos de soporte. Minimizar el tiempo de conexión del control remoto. Maximizar las capacidades de interacción personal durante el control remoto (voz, Chat, etc.).

Servicio de Campo: Minimizar los costos de servicio, minimizar la cantidad de problemas en sitio.

Gerencia de TI: Minimizar los costos de planeación, adquisición, implantación, operación y reemplazo de las TI que apoyan a la organización de soporte interno, Maximizar el retorno de inversión de las aplicaciones de TI.

54

4.4 Preguntas Claves

De acuerdo a los intereses establecidos para los stakeholders, a continuación es necesario establecer las preguntas claves, en el estudio del sistema a evaluar al describir las entidades en términos de sistemas, se determinó, cuáles son las áreas principales de estudio y cuáles son los principales objetivos de cada uno de ellos.

Se construyeron las preguntas claves, se realizo un cuestionario por stakeholder, se realizaron entrevistas y observación descriptiva sobre cada uno de ellos y se obtuvo la información necesaria de acuerdo a las técnicas de recolección de datos descritas en el marco metodológico de esta investigación doctoral. Esta información esta disponible y puede ser solicitada al investigador.

4.5 Diseño de la Metodología de Gerencia de Procesos de Negocio Sustentada en el Uso de Patrones

Una vez establecidas las preguntas asociadas a los intereses de los stakeholders y obtenidos los valores a través de una herramienta de recopilación de información, se procedió al diseño de la metodología.

La propuesta metodológica para la gerencia de los procesos de negocio sustentada en el uso de patrones (Bonillo, 2005b) está conformada por dos macro-procesos (ver, Figura 10): (4.5.1) Creación de los procesos de negocio; y (4.5.2) Administración de los procesos de negocio en ejecución.

Figura 10: Estructura de la Metodología de Gerencia de Procesos Sustentada en el Uso de Patrones “Process Management”.

El primer macro-proceso 4.5.1 incluye los siguientes sub-procesos:

4.5.1.1 Análisis y evaluación de los requerimientos tomando en cuenta el tipo de prioridad y en base a las prácticas de elicitación de requisitos de la ingeniería de software.

4.5.1 CREAR PROCESO

4.5.1.1 Analizar 4.5.1.2 Diseñar

4.5.1.3 Modelar 4.5.1.4 Configurar

4.5.2 ADMINISTRAR PROCESO

4.5.2.1 Mantener Configuración

4.5.2.2 Monitorear

55

En este subproceso, el Cliente solicita un requerimiento sobre un proceso existente o uno nuevo a un Escritorio de Servicio (Service Desk), el analista del negocio (Custodio del Proceso) identifica el requerimiento de acuerdo a las prácticas de elicitación de requisitos de la ingeniería de software: describe el requerimiento en termino de los requisitos funcionales y no funcionales, le asigna una prioridad y evalúa una cartelera de las posibles actividades a realizar en el tiempo. (ver, Figuras 11 y 12)

Figura 11: Sub-Proceso Analizar de la Metodología Gerencia de Procesos.

Figura 12: Sub-Proceso Analizar de la Metodología Gerencia de Procesos (continuación).

Se evalúa el requerimiento definido y se le asigna prioridad según su nivel de impacto y urgencia.

Sub-Proceso: 4.5.1.1 Analizar

1.1.1 .1 Describir

Requerimiento

1.1.1.2 Definir

Prioridad

1.1.1.3 Evaluar

Cartelera de Actividades

Requerimiento Requerimiento Definido

Prioridad Asignada

Cliente Custodio Proceso

Cliente Custodio Proceso

Se evalúa el requerimiento y se define como funcional o no

funcional según sus especificaciones

Se definen las actividades y el tiempo para realizarse según el

impacto y urgencia del requerimiento.

Sub-Proceso: 4.5.1.1 Analizar

1.1.1 Identificar

Requerimientos

Cliente

Requerimiento

1.1.1 .1 Describir

Requerimiento

1.1.1.2 Definir

Prioridad

Requerimiento

1.1.1.3 Evaluar Cartelera

de Actividades

Requerimiento Definido

1.1.2 Levantar

Información

Service Desk Cliente Custodio

Se identifica claramente el alcance inicial del proceso.

Requerimiento

56

A continuación el analista del negocio, consulta los patrones de análisis disponibles en el domino y los relaciona con el requerimiento. Finalmente se levanta cualquier otra información que sea necesaria para determina la situación actual de cómo funciona el proceso y se invoca a un proceso de gestión de cambio a fin de introducir el nuevo requerimiento (RFC) en la arquitectura de procesos existente. (ver, Figura 13).

Figura 13: Sub-Proceso Analizar de la Metodología Gerencia de Procesos (continuación).

4.5.1.2 Diseño de un modelo estandarizado del proceso tomando en cuenta los patrones de análisis en el dominio. En este subproceso el analista del negocio (custodio del proceso) compara el proceso según los requerimientos del usuario, con los patrones de análisis (mejores practicas del dominio) a fin de identificar las brechas existentes y los riesgos organizacionales de asumir los mismos. (ver, Figura 14).

A continuación negocia con el cliente los riesgos, seguidamente el Analista del Negocio con el Arquitecto de Sistemas realiza un diseño en papel del modelo del proceso de acuerdo a los estilos arquitecturales y los patrones arquitecturales que se asocien a los patrones de análisis seleccionados o a los requerimientos específicos del usuario. (Esto es sólo un esqueleto de la aplicación y la selección de los posibles componentes que se puedan incluir en el mismo, se puede utilizar una herramienta de diagramación).

Para finalizar este subproceso el analista del negocio con el cliente define un cronograma definitivo de actividades en el tiempo e invoca a un proceso de desarrollo de software, en el cual el analista del negocio consulta a un arquitecto de sistema a fin de selecciona un

Sub-Proceso: 4.5.1.1 Analizar

1.1.2 Levantar

Información

1.1.2.1 Mapear al Marco Referencial

del Proceso

1.1.2.2 Levantar Situación Actual

Requerimiento Definido

1.1.1 Identificar

Requerimientos

Cliente Custodio

Se documenta toda la información necesaria para dar inicio al

modelado

Requerimiento Definido bajo el marco de referencia Gestión de

Cambios

RFC Mapa de Procesos

(Patrones de Análisis)

Ubicación en el mapa de procesos

Se ubica el requerimiento en el mapa de procesos bajo el marco referencial.

(Patrónes de Análisis)

Se remite el requerimiento al personal de procesos quien debe

evaluarlo y generar un formato de recolección de información.

57

proceso de desarrollo (UP, XP o FDD) según el caso y configurar un ambiente de desarrollo (hardware y software).

Figura 14: Sub-Proceso Diseñar de la Metodología Gerencia de Procesos.

4.5.1.3 Modelado, diagramación y simulación. En este subproceso el analista del negocio realiza un diagrama del proceso de acuerdo al modelo realizado en la fase anterior, en una herramienta de análisis de proceso BPA (seleccionado los diagramas ya existentes para los patrones de análisis, estilos arquitecturales y patrones arquitecturales elegidos en el subproceso de diseño).

Seguidamente el analista del negocio realiza una simulación en la herramienta de BPA a fin de detectar tendencias (cuellos de botellas, ciclos, etc.) y solicita la aprobación de la simulación del proceso al cliente.

A continuación el Analista del Negocio con el Arquitecto de Sistemas integra el diagrama del proceso actual con el diagrama general existente para la arquitectura de todos los procesos y realiza nuevamente una simulación a fin de verificar las tendencias con respecto a la arquitectura general de procesos, solicita la aprobación del usuario, realiza un informe final del diseño y el modelado del proceso e indica al Arquitecto de Sistemas que coloque

Sub-Proceso: 4.5.1.2 Diseñar

1.2.1 Estandarizar

Procesos

1.2.2 Evaluar Riesgo

Analista de Negocio

Analista de

Proceso Estandarizado

Modelo de Objetos

Canónico (Estilos Arquitecturales y

Patrones de Diseño)

Objeto Educativo Canónico

1.2.3 Realizar Modelo

Propuesto

Proceso con Riesgos Definidos

1.2.4 Efectuar Setup del

Laboratorio

Proceso Modelado

Se analizan los riesgos y las brechas basado en el concepto de mejores

prácticas

Se estandariza la propuesta aplicando mejores prácticas

Implica el levantamiento de información para el diseño del

proceso y el llenado de las tablas de configuración de la Herramienta de

Analisis de Procesos (BPA)

Arquitecto de Sistema

58

en producción el proceso, o lo que es lo mismo que exporte desde la herramienta de BPA al motor de Ejecución del Proceso el BPEL (Lenguaje de Ejecución de Procesos propuesto por el BPMI) y el UML (Lenguaje de Modelación Unificado) que serán insumos para el proceso de desarrollo de software. (ver, Figura 15).

Figura 15: Sub-Proceso Modelar de la Metodología Gerencia de Procesos (continuación).

4.5.1.4 Configuración e implementación de la lógica de integración, de negocios y de presentación del proceso a través de la orquestación de servicios, objetos, el uso de patrones de diseño y de interfaz con base en la fase de modelado. (ver, Figura 16).

En este subproceso, el arquitecto toma los diagramas UML creados por la herramienta de BPA y los requerimientos funcionales y no funcionales del análisis de requisitos del proceso y completa los diagramas UML según el proceso de desarrollo seleccionado (UP, XP o FDD).

A continuación a partir de los diagramas UML, el BPEL y los patrones de diseño relacionados con los patrones de análisis, estilos arquitecturales y patrones arquitecturales seleccionados en los subprocesos anteriores, el arquitecto solicita al desarrollador que construya la lógica de negocio de la aplicación que sustentará al proceso (el desarrollador además de seleccionar los patrones de diseño también seleccionara el idiom en el cual

Sub-Proceso: 4.5.1.3 Modelar

1.3.1 Diagramar

1.3.2 Simular Prueba

Funcional

1.3.3 Integrar

Arquitectura

1.3.4 Simular Prueba Integral

Modelo Objeto (Estilos Arquitecturales

Patrones de Diseño Patrones Arquitecturales)

Cliente

Custodio Proceso

Procesos Modelados

Simulación Aprobada

Procesos Integrados

Se construye el proceso bajo la herramienta BPA la cual genera un documento

BPMN.

Se integra el proceso con la Malla de Macro Procesos

Se configura el ambiente integrado para su simulación final,, la cual debe generar los

archivos BPEL y UML, así como el informe de modelado y el informe de simulación para luego

ser validado con el cliente.

Se configura el ambiente funcional y se realiza la

simulación, los resultados de la misma deben ser

aprobados por el cliente

Arquitecto de Sistemas

59

realizara el desarrollo de la lógica de negocio, por ejemplo Enterprise Java Bean EJB y el Contenedor de Aplicaciones Java EAR).

De igual forma de acuerdo a los patrones de interacción relacionados con los patrones de análisis, los estilos arquitecturales y patrones arquitecturales seleccionados en los subprocesos anteriores, el BPEL y las interfaces asociadas automáticamente con el BPEL a través de la herramienta de BPA, el arquitecto solicita al desarrollador que construya la interfaz de la herramienta que soportará al proceso (el desarrollador además de seleccionar los patrones de interacción, también seleccionará los patrones de flujo de trabajo y el idiom en el cual realizará el desarrollo de la interfaz, por ejemplo Java Server Page JSP).

Figura 16: Sub-Proceso Configurar de la Metodología Gerencia de Procesos. Seguidamente el arquitecto solicita al especialista de integración (desarrollador) que realice las integraciones entre el BPEL, la interfaz y la lógica de negocio. Teniendo el BPEL, la lógica de negocio y la interfaz integrada el arquitecto procede a colocar en el BPEL los indicadores de gestión que se medirán para el proceso, para esto selecciona de un conjunto

Sub-Proceso: 4.5.1.4 Configurar

1.4.4 Construir los

reportes

1.4.5 Configurar el

BPEL

Tablas del Sistema

Generador de Reportes

JSP Generados por Aplicación BPM

UML Generado o Exportado BPA

1.4.3 Construir Interfaz

1.4.2 Construir Lógica de Negocios

1.4.1 Completar UML

UML o BPA

Arquitecto

Se le da completitud al ambiente de configuración en el archivo BPEL; Se le

dan configuraciones completas al UML.

Se generan las tablas de la base de datos, los servicios y lógica de negocios (EJB)

patrones de workflow.

UML Completo

Desarrollador

JSP

Desarrollador

Se construye la interfaz del usuario a partir de los JSP

generados por el configurador de aplicación a fin de darle

usabilidad (patrones de interfaz y flujo de trabajo).

Tablas de Requerimientos

Requerimiento

1.4.6 Realizar Pruebas Unitarias

Paginas Opcional

JSP Portal EAR

Completos

EJB

Crear Tablas

Arquitectura

Descripcion del servicio (wsdl)

Servicio expuesto y disponible

Arquitecto

60

previamente definido de acuerdo al patrón de análisis, los indicadores necesarios y a su vez solicita al desarrollador que construya los reportes necesarios para desplegar los indicadores, el BPMS contiene normalmente un modulo de BAM el cual almacena estos indicadores en el tiempo de acuerdo a estructuras de inteligencia de negocio.

Finalmente el Arquitecto solicita al Analista del Negocio la certificación del producto de software que sustenta el proceso, para luego culminar el proceso de gestión de cambio de la arquitectura de procesos y solicitar un pase a producción (ver, Figura 17).

Figura 17: Sub-Proceso. Configurar de la Metodología Gerencia de Procesos (continuación).

Sub-Proceso: 4.5.1.4 Configurar (Continuación)

1.4.4 Construir los

reportes

1.4.5 Configurar el

BPEL

Generador de Reportes

Se configura el BPEL, la lógica de negocios, los reportes, la interfaz, las

excepciones, los mensajes, notificaciones, compensaciones y se integra al proceso de la aplicación

integrado en un contenedor.

JSP Generados por Aplicación BPM

UML Generado o Exportado BPA

1.4.3 Construir Interfaz

1.4.2 Construir Lógica de Negocios

1.4.1 Completar UML

UML y BPA

Arquitecto

UML Completo

JSP

Desarrollador

Se construye la interfaz del usuario a partir de los JSP

generados por el configurador de aplicación a fin de darle

usabilidad (patrones de interfaz y evento).

Tablas de Requerimientos

Requerimiento

1.4.6 Realizar Pruebas Unitarias

Paginas Opcional

JSP Portal EAR

Completos

EJB

Gestión de Cambios

Administrador de Cambios

UML Generado o Exportado BPA

Pase a Producción

Se realizan las pruebas funcionales y pruebas integrales, cuyos resultados son validados por los clientes para proceder a

su implantación.

61

El otro macro-proceso 4.5.2 corresponde a la administración de los procesos en ejecución y comprende:

4.5.2.1.1 Mantenimiento de las aplicaciones (procesos en producción), a través de este subproceso los clientes solicitan las modificaciones menores a 40 horas de desarrollo sobre la interfaz de usuario y los reportes y que no implique un cambio en el flujo del proceso, de esta forma el área de mantenimiento de aplicaciones analiza y valida el requerimiento, diseña el cambio y realiza pruebas, para finalmente solicitar un control de cambio y un pase a producción de los cambios solicitados. (ver, Figura 18)

Figura 18: Sub-Proceso Mantenimiento de la Metodología Gerencia de Procesos.

4.5.2.1.2 Mantenimiento de variables del proceso, en este subproceso el cliente solicita cambios puntuales sobre las variables de configuración del proceso en producción, el área de mantenimiento de aplicaciones realiza los cambios y solicita igualmente que los mismos sean pasados a producción. (ver, Figura 19).

Sub-Proceso: 4.5.2.1 Mantener de Aplicaciones

2.1.2 Mantenimiento de

Variables del Proceso

Cliente

2.1.1.1 Analizar y Validar tipo

de requerimiento

2.1.1.2 Diseñar

Solicitud

FOR-0069

2.1.1.3 Aplicar Prueba

Validación por proyecto ProcessWare

2.1.3 Mantenimiento de

la Plataforma

Líder Mantenimiento de Aplicaciones

Se verifican los datos y su funcionalidad a través de las

pruebas validadas por el cliente.

2.1.1 Mantenimiento de

Aplicaciones

Prototipo de la Aplicación

Gestión de Cambios

Pase a Producción

RFC

Se realizan las modificaciones en las aplicaciones que están en producción para solicitudes que sean menores a 40 horas.

Se identifica, disgrega y valida con el cliente el requerimiento solicitado.

Se construye el requerimiento solicitado con fecha de compromiso y se valida con el cliente.

62

Figura 19: Sub-Proceso Mantener Configuraciones de la Metodología Gerencia de Procesos

(continuación).

4.5.2.1.3 Mantenimiento de Plataforma, a través de este subproceso ese configura la plataforma de hardware y software donde se ejecutan los procesos en producción, incluyendo los posibles cambios. (ver, Figura 20).

Figura 20: Sub-Proceso Mantener Configuraciones de la Metodología Gerencia de Proceso

(mantenimiento de plataforma).

Sub-Proceso: 4.5.2.1 Mantener Configuraciones

Cliente

Solicitud

2.1.3 Mantenimiento de

la Plataforma

Líder Mantenimiento de Aplicaciones

2.1.1 Mantenimiento de

Aplicaciones

Se realizan las modificaciones en las aplicaciones que están en producción para solicitudes que sean menores a 40 horas.

2.1.2 Mantenimiento de

Variables de Procesos

Datos del Proceso Actualizado

Sub-Proceso: 4.5.2.1 Mantenimiento de Plataforma

2.1.3 Mantenimiento de

Variables de Procesos

2.1.1 Mantenimiento de

Aplicaciones

Se configura la plataforma de hardware, software, parámetros de WAS, bases de datos, sistema operativo, servidor Web y BPM para el respectivo pase a producción de la RFC.

2.1.2 Mantenimiento de

la Plataforma

Hosting de Base de Datos

Hosting S O

Hosting Aplicaciones

BPM Configurado

Hardware Configurado

Software Configurado

WAS Configurado

Base Datos Configurado

S.O. Configurado

Servidor Web Configurado

RFC

Gestión de Cambios Administrador

Pase a Producción

63

4.5.2.2 Monitoreo de la Plataforma, en este subproceso el Gerente del proceso solicita al especialista de aplicaciones los indicadores, reportes y mediciones en tiempo real (Dashboard) sobre los procesos, igualmente se monitorean las variables correspondientes al funcionamiento del hardware y software (variables MIBS).

Figura 21: Sub-Proceso Monitorear de la Metodología Gerencia de Procesos. En cada uno de los subprocesos antes mencionados se tienen un conjunto de roles de usuarios los cuales se describen a continuación: Escritorio de Servicios “Service Desk”: Ser el punto único de contacto entre los Clientes y Usuarios, responsable de la recepción de todas las solicitudes que tengan vinculación con la Plataforma de Procesos. Por otra parte, mantiene informado al Cliente acerca del status del requerimiento emitido. Cliente: Cualquier persona de la Empresa que requiera emitir un incidente, llamada o solicitud de servicio sobre la Plataforma de Procesos. Analista de Negocio o Custodio de Procesos: Recibe la solicitud, la analiza disgregando la información de acuerdo a su funcionalidad, calidad, impacto, urgencia, riesgo, brechas, entre otros. Hasta llegar a la diagramación, modelado y simulación del requerimiento solicitado por un cliente. Se apoya en el Arquitecto a fin de Bajar las especificaciones de negocio al área de ingeniería de software.

Sub-Proceso: 4.5.2.2 Monitorear

2.2.2 Monitorear Plataforma

Especialista Mantenimiento de Aplicaciones

Gerente de Proceso

Tabla BPA Definición de Indicadores Dashboard

Se refiere al monitoreo de todas las variables asociadas al funcionamiento de la plataforma.

2.2.1 Monitorear Funciones

Especialista en Monitoreo

y Control

Hosting de Aplicaciones

Tablas BPA Variables

MIBS

Se refiere a las mediciones que los gerentes de los procesos desean tener en tiempo real (dashboard).

Dashboard

Medicion Software

Monitoreo

64

Administrador de Cambios: Recibe todas las peticiones de cambio emitido dentro de la Gestión de Procesos para realizar los respectivos cambios requeridos en la solución de un requerimiento. Arquitecto: Especialista en procesos y en la herramienta de Modelamiento (BPA) que se encarga de verificar, darle asesoría y validar los diagramas modelados por el Custodio de Procesos dentro del Centro de Modelado para luego remitirlos al Configurador. Prepara el ambiente en la plataforma para darle completitud a la simulación a través del enriquecimiento de datos necesarios en la emisión de los archivos UML y BPEL. Se apoya en los desarrolladores a fin de construir la lógica de negocio, la interfaz, los reportes. Líder Mantenimiento Aplicaciones: Gestiona la distribución y asignación de las solicitudes emitidas para el mantenimiento en las aplicaciones de los procesos que se encuentran en producción. Especialista Mantenimiento Aplicaciones: Ejecuta las modificaciones, carga y configuración de los datos, usuarios y grupos de aplicaciones de los procesos que se encuentran en producción. Líder Mantenimiento Operativo: Dirigir, supervisar y gestionar todo requerimiento que supera las 40 horas. Hosting Aplicaciones: Grupo de Operaciones que mantiene la Plataforma de Aplicaciones que se encuentran en producción. Hosting Sistema Operativo: Grupo de Operaciones que mantiene el Sistema Operativo de las aplicaciones que se encuentran en producción. Hosting Base de Datos: Grupo de Operaciones que mantiene las base de Datos de las aplicaciones que se encuentran en producción. Gerente Proceso: Emite la información necesaria para la emisión del panel de control de medición de métricas (Dashboard). Especialista Monitoreo y Control: Grupo que evalúa las variables de plataforma de hardware y software de aplicaciones monitoreando su funcionamiento.

4.6. Retroalimentación

Esta es la etapa final de la metodología, una vez puestos en producción los procesos, éstos son analizados con el objetivo de obtener resultados que conduzcan a conclusiones relevantes en cuanto al comportamiento de los mismos.

Con este análisis se puede determinar la forma en que la metodología beneficia o no a la organización, y al mismo tiempo realizar refinamientos del uso de la misma según los casos

65

particulares, o el estudio de otros agentes que ayuden a aumentar el impacto de los procesos.

De esta forma la metodología no sólo permite comunicar los resultados, sino que, además ofrece la posibilidad de variar ciertos factores relevantes en el impacto, para validar nuevamente su influencia principalmente con respecto al uso de los patrones y la medición de la calidad en el proceso de desarrollo de software. Sin embargo muchos son los factores que directa e indirectamente debe tomarse en cuenta como restricciones que se anidan y que facilitan o no la implementación de la metodología, basadas todas en los diferentes intereses planteados para cada stakeholder. (Bonillo, 2006b)

Es importante citar que durante el desarrollo de la investigación se evaluaron aplicaciones propietarias y de software libre que permitieran la automatización de los conceptos expuestos, sin embargo no se encontró una herramienta que permitieran ejecutar las funciones descritas, es por esto que en el siguiente capitulo se expone el análisis de un prototipo de aplicación que permita la automatización integral de la metodología descrita.

4.7. Propuesta de Automatización de la Metodología

En este aparte se especifican los casos de uso del prototipo de bajo nivel de BPMS sustentado en el uso de Patrones que permitirá implementar la administración de los patrones en base a la taxonomía y las relaciones teóricas establecidas en esta investigación (ver, Figura 7), para esto se realiza el modelaje del sistema a través de los casos de usos y se propone un sistema de generación asistida de aplicaciones en base al uso de los patrones. A continuación se muestra la especificación de los casos de uso más significativos (se desarrollaron todos los casos de usos y están disponibles en caso de que se deseen consultar, se pueden solicitar enviando un correo electrónico al autor pbonillo@cantv.net). Es importante mencionar que los mismos surgen del análisis de los requerimientos funcionales del cliente y del diseñador. Para la especificación de los casos de uso, se utilizó la plantilla propuesta por Díaz y Matteo (2002). Se presenta el caso de uso general y a continuación se explica cada uno de los casos de uso a través de una tabla. A continuación se presenta el caso de uso general y su descripción y sucesivamente se presenta la información del resto de los casos de uso.

66

Figura 22. Caso de uso General Prototipo BPMS Metodología Gerencia de Procesos de Negocio Sustentada en el Uso de Patrones.

Caso de Uso General Resumen Recibe las solicitudes de los Modeladores, Administradores, Usuarios y Procesos

Externos o Procesos de Negocio y administra el modelo de proceso, los patrones (análisis-proceso, interfaz, interacción y flujo de trabajo), la interfaz, los eventos de las tareas, las tareas, la identificación de los entes involucrados en las tareas, los datos asociados al sistema (identificación de proceso tarea, etc.), las notificaciones y los reportes tanto del sistema como del monitoreo de la actividad de los procesos y las tareas

Actor Modelador, Administrador, Usuario, Proceso Externo o Negocio Precondición Descripción INICIA CUANDO <Modelador><Administrador><Usuario><Proceso Externo o

Negocio><invoca a Administrador de Modelo><invoca Administrador de

67

Patrones><invoca Administrador Interfaz> 1. <Modelador>│<invoca Administrador Modelo> 2. <Administrador>│<invoca Administrador Modelo> 3. <Administrador><Usuario><Proceso Externo o Negocio>│ <invoca Administrador Interfaz> <Administrador Interfaz>│

<recibeparametros><parámetros de Interfaz deben ser correctos> <Administrador Interfaz>│<invoca Administrador Eventos Tarea> <Administrador Eventos Tarea>│<invoca Administrador Tarea> <Administrador Tarea>│<invoca Administrador Identidad> <Administrador Tarea>│<invoca Administrador Sistema> <Administrador Tarea>│<invoca Administrador Notificaciones> <Administrador Tarea>│<invoca Administrador Reportes>

4. <Administrador>│<invoca Administrador Reportes> Trayectorias Alternativas <parámetros Interfaz incorrectos>

1. <Modelador><Administrador><Usuario><Proceso Externo o Negocio>│<vuelve a enviar los parámetros de Interfaz><parámetros de Interfaz deben ser correctos>

Poscondición El Modelador, Administrador, Usuario, Proceso Externo o Negocio recibe respuesta del requerimiento si los parámetros iníciales son correctos, en caso contrario recibe un error.

Requisito No Funcional

Comentario

Tabla 3 Caso de uso General Prototipo BPMS Metodología Gerencia de Procesos de Negocio Sustentada en el Uso de Patrones.

A continuación se inicia la explicación específica de cada uno de estos casos de uso que conforman el caso de uso general.

68

Figura 23. Caso de uso Administrador Modelo.

Caso de Uso Administrador Modelo Resumen Recibe las solicitudes del Modelador a través del servicio de administración de

Modelo, procesa las solicitudes y envía la respuesta. Actor Administrador Modelo, Administrador Patrones y Administrador Identidad Precondición Descripción <Administrador Modelo>INICIA CUANDO <Modelador><invoca al Servicio de

Administración de Modelos> 1. <Administrador>│<interfaz de invocación del Servicio de Administración de

Modelos><introduce parámetros iníciales de modelo><parámetros de modelo deben ser correctos>

2. <Administrador Modelo>│ <recibeparametros><parámetros de modelo deben ser correctos>

3. <Administrador Modelo>│<procesa modelo> SI <consultar Modelo>ENTONCES

4. <Administrador Modelo>│<Consulta Modelo> FIN SI

SI <crear Modelo>ENTONCES 5. <Administrador Modelo>│<crear modelo> <interfaz de invocación del Servicio Administración Identidad> <Consultar Identidad><Crear Identidad><Modificar Identidad>

SI <Patrón Análisis>ENTONCES

69

<interfaz de invocación del Servicio Administración Patrones análisis> <recuperarPatron> FIN SI

SI <PatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <recuperarPatron> FIN SI

SI <PatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <recuperarPatron> FIN SI

SI <PatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <recuperarPatron> FIN SI

FIN SI SI <modificarModelo>ENTONCES

6. <Administrador Modelo>│<modifica modelo> <interfaz de invocación del Servicio Administración Identidad> <Consultar Identidad><Crear Identidad><Modificar Identidad>

SI <PatronAnalisis>ENTONCES <interfaz de invocación del Servicio Administración Patrones análisis> <recuperarPatron> FIN SI

SI <PatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <recuperarPatron> FIN SI

SI <PatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <recuperarPatron> FIN SI

SI <PatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <recuperarPatron> FIN SI

FIN SI SI <validarModelo>ENTONCES

7. <Administrador Modelo>│<valida modelo> <interfaz de invocación del Servicio Administración Identidad> <validar Identidad>

SI <simularModelo>ENTONCES 8. <Administrador Modelo>│<simula modelo> <interfaz de invocación del Servicio Administración Identidad> <validar Identidad>

SI <eliminarModelo>ENTONCES 9. <Administrador Modelo>│<elimina modelo>

SI <capturarError> ENTONCES 10. <Administrador Modelo>│<capturaError>

FIN SI 11. <Administrador Modelo>│<enviaRespuesta> END < Administrador Modelo> Trayectorias Alternativas <parámetros modelo incorrectos>

1. <Administrador>│<pantalla de invocación del servicio de Administración de Modelo><vuelve a enviar los parámetros de modelo><parámetros de modelo deben ser correctos>

Poscondición El Proceso Externo recibe respuesta del requerimiento de administración de modelo si los parámetros iníciales son correctos, en caso contrario recibe un error.

70

Requisito No Funcional

Comentario

Tabla 4 Caso de Uso Administrador Modelo

Figura 24 Caso de uso Administrador Patrones.

Caso de Uso Administrador Patrones Resumen Recibe las solicitudes del Administrador a través del servicio de administración de

Patrones, procesa las solicitudes y envía la respuesta. Actor Proceso Externo, Administrador Interfaz, Administrador Patrones interacción,

Administrador Identidad, Administrador Eventos Interfaz, Administrador Tarea Precondición Descripción <Administrador Patrones>INICIA CUANDO <Administrador><invoca al Servicio de

Administración de Patrones>

71

1. <Administrador>│<interfaz de invocación del Servicio de Administración de

Patrones><introduce parámetros iníciales de patrones><parámetros de patrones deben ser correctos>

2. <Administrador Patrones>│ <recibeparametros><parámetros de patrón deben ser correctos><interfaz de invocación del Servicio de Administración de Identidad><verificarPermisologia>

3. <Administrador Patrones>│<procesapatron> SI <configurarPatron>ENTONCES

4. <Administrador Patrones>│ <interfaz de invocación del Servicio de Administración Identidad> <seleccionarPermisologia><configurarPermisologiaPatron>

SI <ConfigurarPatronAnalisis>ENTONCES <interfaz de invocación del Servicio Administración Patrones análisis> <configurarPatronAnalisis> FIN SI

SI <ConfigurarEstiloArquitectural>ENTONCES <interfaz de invocación del Servicio Administración Estilo Arquitectural> <configurarEstiloArquitectural> FIN SI

SI <ConfigurarPatronDiseño>ENTONCES <interfaz de invocación del Servicio Administración Patrones Diseño> <configurarPatronDiseño> FIN SI

SI <ConfigurarPatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <configurarPatronInterfaz> FIN SI

SI <ConfigurarPatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <configurarPatronEventosInteraccion> FIN SI

SI <ConfigurarPatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <configurarPatronFlujoTrabajo> FIN SI

FIN SI SI <EliminarPatron> ENTONCES

5. <Administrador Patrones>│ <verificaRelaciones><eliminaRelaciones>

SI <EliminarPatronAnalisis>ENTONCES <interfaz de invocación del Servicio Administración Patrones análisis> <eliminarPatronAnalisis> FIN SI

SI <EliminarEstiloArquitectural>ENTONCES <interfaz de invocación del Servicio Administración Estilo Arquitectural> <eliminarEstiloArquitectural> FIN SI

SI <EliminarPatronDiseño>ENTONCES <interfaz de invocación del Servicio Administración Patrones Diseño> <eliminarPatronDiseño> FIN SI

SI <EliminarPatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <eliminarPatronInterfaz> FIN SI

SI <EliminarPatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <eliminarPatronEventosInteraccion> FIN SI

SI <EliminarPatronFlujoTrabajo>ENTONCES

72

<interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <eliminarPatronFlujoTrabajo> FIN SI

FIN SI SI <validarPatron>ENTONCES

6. <Administrador Patrones>│ SI <ValidarPatronAnalisis>ENTONCES

<interfaz de invocación del Servicio Administración Patrones análisis> <validarPatronAnalisis> FIN SI

SI <ValidarEstiloArquitectural>ENTONCES <interfaz de invocación del Servicio Administración Estilo Arquitectural> <validarEstiloArquitectural> FIN SI

SI <ValidarPatronDiseño>ENTONCES <interfaz de invocación del Servicio Administración Patrones Diseño> <validarPatronDiseño> FIN SI

SI <ValidarPatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <validarPatronInterfaz> FIN SI

SI <ValidarPatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <validarPatronEventosInteraccion> FIN SI

SI <ValidarPatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <validarPatronFlujoTrabajo> FIN SI

FIN SI SI <aplicarPatron>ENTONCES

7. <Administrador Patrones>│ SI <AplicarPatronAnalisis>ENTONCES

<interfaz de invocación del Servicio Administración Patrones análisis> <aplicarPatronAnalisis> FIN SI

SI <AplicarEstiloArquitectural>ENTONCES <interfaz de invocación del Servicio Administración Estilo Arquitectural> <aplicarEstiloArquitectural> FIN SI

SI <AplicarPatronDiseño>ENTONCES <interfaz de invocación del Servicio Administración Patrones Diseño> <aplicarPatronDiseño> FIN SI

SI <AplicarPatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <aplicarPatronInterfaz> FIN SI

SI <AplicarPatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <aplicarPatronEventosInteraccion> FIN SI

SI <AplicarPatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <aplicarPatronFlujoTrabajo> FIN SI

FIN SI SI <recuperarPatron>ENTONCES

8. <Administrador patrón>│ SI <RecuperarPatronAnalisis>ENTONCES

73

<interfaz de invocación del Servicio Administración Patrones análisis> <recuperarPatronAnalisis> FIN SI

SI <RecuperarEstiloArquitectural>ENTONCES <interfaz de invocación del Servicio Administración Estilo Arquitectural> <recuperarEstiloArquitectural> FIN SI

SI <RecuperarPatronDiseño>ENTONCES <interfaz de invocación del Servicio Administración Patrones Diseño> <recuperarPatronDiseño> FIN SI

SI <RecuperarPatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <recuperarPatronInterfaz> FIN SI

SI <RecuperarPatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <recuperarPatronEventosInteraccion> FIN SI

SI <RecuperarPatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <recuperarPatronFlujoTrabajo> FIN SI

FIN SI SI <crearPatron>ENTONCES

9. <Administrador patrón>│ SI <CrearPatronAnalisis>ENTONCES

<interfaz de invocación del Servicio Administración Patrones análisis> <crearPatronAnalisis> FIN SI

SI <CrearEstiloArquitectural>ENTONCES <interfaz de invocación del Servicio Administración Estilo Arquitectural> <crearEstiloArquitectural> FIN SI

SI <CrearPatronDiseño>ENTONCES <interfaz de invocación del Servicio Administración Patrones Diseño> <crearPatronDiseño> FIN SI

SI <CrearPatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <crearPatronInterfaz> FIN SI

SI <CrearPatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <crearPatronEventosInteraccion> FIN SI

SI <CrearPatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <crearPatronFlujoTrabajo> FIN SI

FIN SI SI <modificarPatron>ENTONCES

10. <Administrador patrón>│ SI <adaptarPatron>ENTONCES SI <AdaptarPatronAnalisis>ENTONCES

<interfaz de invocación del Servicio Administración Patrones análisis> <adaptarPatronAnalisis> FIN SI

SI <AdaptarEstiloArquitectural>ENTONCES <interfaz de invocación del Servicio Administración Estilo Arquitectural> <adaptarEstiloArquitectural>

74

FIN SI SI <AdaptarPatronDiseño>ENTONCES

<interfaz de invocación del Servicio Administración Patrones Diseño> <adaptarPatronDiseño> FIN SI

SI <AdaptarPatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <adaptarPatronInterfaz> FIN SI

SI <AdaptarPatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <adaptarPatronEventosInteraccion> FIN SI

SI <AdaptarPatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <adaptarPatronFlujoTrabajo> FIN SI

FIN SI SI <evaluarPatron>ENTONCES SI <EvaluarPatronAnalisis>ENTONCES

<interfaz de invocación del Servicio Administración Patrones análisis> <evaluarPatronAnalisis> FIN SI

SI <EvaluarEstiloArquitectural>ENTONCES <interfaz de invocación del Servicio Administración Estilo Arquitectural> <evaluarEstiloArquitectural> FIN SI

SI <EvaluarPatronDiseño>ENTONCES <interfaz de invocación del Servicio Administración Patrones Diseño> <evaluarPatronDiseño> FIN SI

SI <EvaluarPatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <evaluarPatronInterfaz> FIN SI

SI <EvaluarPatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <evaluarPatronEventosInteraccion> FIN SI

SI <EvaluarPatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <evaluarPatronFlujoTrabajo> FIN SI

FIN SI SI <calificarPatron>ENTONCES SI <CalificarPatronAnalisis>ENTONCES

<interfaz de invocación del Servicio Administración Patrones análisis> <calificarPatronAnalisis> FIN SI

SI <CalificarEstiloArquitectural>ENTONCES <interfaz de invocación del Servicio Administración Estilo Arquitectural> <calificarEstiloArquitectural> FIN SI

SI <CalificarPatronDiseño>ENTONCES <interfaz de invocación del Servicio Administración Patrones Diseño> <calificarPatronDiseño> FIN SI

SI <CalificarPatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <calificarPatronInterfaz> FIN SI

75

SI <CalificarPatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <calificarPatronEventosInteraccion> FIN SI

SI <CalificarPatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <CalificarPatronFlujoTrabajo> FIN SI

FIN SI SI <clasificarPatron>ENTONCES SI <ClasificarPatronAnalisis>ENTONCES

<interfaz de invocación del Servicio Administración Patrones análisis> <clasificarPatronAnalisis> FIN SI

SI <ClasificarEstiloArquitectural>ENTONCES <interfaz de invocación del Servicio Administración Estilo Arquitectural> <clasificarEstiloArquitectural> FIN SI

SI <ClasificarPatronDiseño>ENTONCES <interfaz de invocación del Servicio Administración Patrones Diseño> <clasificarPatronDiseño> FIN SI

SI <ClasificarPatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <clasificarPatronInterfaz> FIN SI

SI <ClasificarPatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <clasificarPatronEventosInteraccion> FIN SI

SI <ClasificarPatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <clasificarPatronFlujoTrabajo> FIN SI

FIN SI SI <reingenieriaPatron>ENTONCES SI <ReingenieriaPatronAnalisis>ENTONCES

<interfaz de invocación del Servicio Administración Patrones análisis> <reingenieria<PatronAnalisis> FIN SI

SI <ReingenieriaEstiloArquitectural>ENTONCES <interfaz de invocación del Servicio Administración Estilo Arquitectural> <reingenieriaEstiloArquitectural> FIN SI

SI <ReingenieriaPatronDiseño>ENTONCES <interfaz de invocación del Servicio Administración Patrones Diseño> <reingenieriaPatronDiseño> FIN SI

SI <ReingenieriaPatronInterfaz>ENTONCES <interfaz de invocación del Servicio Administración Patrones Interfaz> <reingenieriaPatronInterfaz> FIN SI

SI <ReingenieriaPatronEventosInteraccion>ENTONCES <interfaz de invocación del Servicio Administración Patrones Eventos> <reigenieriaPatronEventosInteraccion> FIN SI

SI <ReingenieriaPatronFlujoTrabajo>ENTONCES <interfaz de invocación del Servicio Administración Patrones Flujo Trabajo> <reingenieriaPatronFlujoTrabajo> FIN SI

FIN SI

76

FIN SI SI <capturarError> ENTONCES 11. <Administrador Patrones>│<capturaError>

FIN SI 12. <Administrador Patrones>│<enviaRespuesta> END < Administrador Patrones> Trayectorias Alternativas <parámetros patrón incorrectos>

1. <Proceso Externo>│<pantalla de invocación del servicio de Administración de Patrones><vuelve a enviar los parámetros de patrón><parámetros de patrón deben ser correctos>

Poscondición El Proceso Externo recibe respuesta del requerimiento de administración de patrón si los parámetros iníciales son correctos, en caso contrario recibe un error.

Requisito No Funcional

Comentario

Tabla 5 Caso de Uso Administrador Patrones

Figura 25 Caso de uso Administrador Interfaz.

77

Caso de Uso Administrador Interfaz Resumen Recibe las solicitudes de procesos externos a través del servicio de administración

de Interfaz, procesa las solicitudes y envía la respuesta. Actor Proceso Externo, Administrador Interfaz, Administrador Patrones interacción,

Administrador Identidad, Administrador Eventos Interfaz, Administrador Tarea Precondición Descripción <Administrador patrón interacción>INICIA CUANDO <Proceso Externo><invoca al

Servicio de Administración de Interfaz>

13. <Proceso Externo>│<interfaz de invocación del Servicio de Administración de Interfaz><introduce parámetros iníciales de Interfaz><parámetros de Interfaz deben ser correctos>

14. <Administrador Interfaz>│ <recibeparametros><parámetros de Interfaz deben ser correctos><interfaz de invocación del Servicio de Administración de Identidad><verificarPermisologia>

15. <Administrador Interfaz>│<procesaInterfaz> SI <crearInterfaz>ENTONCES

16. <Administrador Interfaz>│ <interfaz de invocación del Servicio de Administración Patrones Interacción> <seleccionarPatron><configurarPatron><aplicarPatron>

FIN SI SI <modificarInterfaz>ENTONCES

17. <Administrador Interfaz>│ <interfaz de invocación del Servicio de Administración Patrones Interacción> <seleccionarPatron><configurarPatron><aplicarPatron>

FIN SI SI <validarInterfaz>ENTONCES

18. <Administrador Interfaz>│ <interfaz de invocación del Servicio de Administración Patrones Interacción> <seleccionarPatron><validarPatron>

FIN SI SI <mostrarInterfaz>ENTONCES

19. <Administrador Interfaz>│<mostrarInterfaz> FIN SI SI <eliminarInterfaz>ENTONCES

20. <Administrador Interfaz>│<eliminarInterfaz> FIN SI SI <capturarEventoInterfaz>ENTONCES

21. <Administrador Interfaz>│ <interfaz de invocación del Servicio de Administración Evento Interfaz> <validarEventoInterfaz>

FIN SI SI <capturarOperacionInterfaz>ENTONCES

22. <Administrador Interfaz>│ <interfaz de invocación del Servicio de Administración Tarea> <ejecutarTarea>

FIN SI SI <capturarError> ENTONCES

23. <Administrador Interfaz>│<capturaError> FIN SI

24. <Administrador Interfaz>│<enviaRespuesta> END < Administrador Interfaz> Trayectorias Alternativas <parámetros Interfaz incorrectos>

2. <Proceso Externo>│<pantalla de invocación del servicio de Administración de Interfaz><vuelve a enviar los parámetros de Interfaz><parámetros de Interfaz deben ser correctos>

Poscondición El Proceso Externo recibe respuesta del requerimiento de administración de Interfaz si los parámetros iníciales son correctos, en caso contrario recibe un error.

78

Requisito No Funcional

Comentario

Tabla 6 Caso de Uso Administrador Interfaz

Figura 26 Caso de uso Administrador de Tareas.

Caso de Uso Administrador de Tareas Resumen Recibe las solicitudes de procesos externos a través del servicio de administración

de la tarea, procesa la tarea y envía la respuesta. Actor Proceso Externo, Administrador de Tareas, Administrador Identidad, Administrador

Estado Transición, Administrador Documentación, Administrador Acuerdos de Servicio, Administrador

Precondición Administrador Interfaz, Administrador Eventos Descripción <Administrador de Tareas> INICIA CUANDO <Proceso Externo><invoca al Servicio

de Administración de Tareas> 1. <Proceso Externo>│<interfaz de invocación del Servicio de Administración de

Tareas><introduce parámetros iníciales para la tarea><parámetros de la tarea deben ser correctos>

2. <Administrador de Tareas>│

79

a. <recibeRequerimiento> b. <asignaParametrosIniciales> c. <creaInstancia> d. <asignaParametrosNuevaInstacia> <parámetros de la tarea deben ser correctos>

3. <Administrador de Tareas>│<procesaRequerimiento> SI <modificar> ENTONCES 4. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Identidad ><verificaPermisología> 5. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de EstadoTransicion><verificaEstadoTransicion> 6. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Documentacion><verificaDocumentacion> 7. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Acuerdos de Servicio><verificaAcuerdodeServicio> 8. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Calendario><calculaTiempos> 9. <Administrador de Tareas>│<asignaAuditoria> 10. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Notificaciones><verificaNotificacion> FIN SI SI <completar> ENTONCES 11. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Identidad ><verificaPermisología> 12. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de EstadoTransicion><verificaEstadoTransicion> 13. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Documentacion><verificaDocumentacion> 14. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Acuerdos de Servicio><verificaAcuerdodeServicio> 15. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Calendario><calculaTiempos> 16. <Administrador de Tareas>│<asignaAuditoria> 17. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Notificaciones><verificaNotificacion> 18. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Encuesta><verificaEncuesta> 19. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Soluciones><verificaSolucion> FIN SI SI <eliminar> ENTONCES 20. <Administrador de Tareas>│<eliminaTarea> FIN SI 21. <Administrador de Tareas>│<interfaz de invocación del Servicio del

Administrador de Notificacion><verificaExpiracion> 22. <Administrador de Tareas>│<enviaRespuesta>

END < Administrador de Tareas> Trayectorias Alternativas <parámetros de la tarea incorrectos>

1. <Proceso Externo>│<pantalla de invocación del servicio de Administración de Tareas><vuelve a enviar los parámetros de la tarea><parámetros de la tarea deben ser correctos>

Poscondición El Proceso Externo recibe respuesta de la operación o el error asociado a la ejecución del requerimiento a través del administrador de tareas si los parámetros iníciales son correctos, en caso contrario recibe un error.

Requisito No Funcional

Comentario

Tabla 7 Caso de Uso Administrador de Tareas

80

Figura 27 Caso de uso Administrador de Eventos Tarea

Caso de Uso Administrador de Eventos Resumen Recibe las solicitudes de procesos externos a través del servicio de administración

de eventos de tarea, procesa los eventos y envía la respuesta. Actor Proceso Externo, Administrador Eventos, Administrador Notificaciones,

Administrador Tarea Precondición Administrador Interfaz Descripción <Administrador de Eventos> INICIA CUANDO <Proceso Externo><Administrador de

Interfaz><Administrador de Tareas><invoca al Servicio de Administración de Eventos>

1. <Proceso Externo><Administrador de Interfaz><Administrador de

Tareas>│<interfaz de invocación del Servicio de Administración de Eventos><introduce parámetros iníciales para el evento><parámetros del evento deben ser correctos>

2. <Administrador de Eventos>│<recibeEvento><parámetros del evento deben ser correctos>

3. <Administrador de Eventos>│<procesaEvento> SI <verificarRecordatorio> ENTONCES

81

4. <Administrador de Eventos>│<interfaz de invocación del Servicio del Administrador de Notificaciones><verificaRecordatorio>

FIN SI SI <verificarExpiracion> ENTONCES

5. <Administrador de Eventos>│<interfaz de invocación del Servicio del Administrador de Notificaciones><verificaExpiracion>

FIN SI SI <verificarEliminacion> ENTONCES

6. <Administrador de Eventos>│<interfaz de invocación del Servicio del Administrador de Tareas><verificaEliminacion(comounamodificacion)>

FIN SI SI <reanudarTarea> ENTONCES

7. <Administrador de Eventos>│<reanudaTarea> FIN SI SI <suspenderTarea> ENTONCES

8. <Administrador de Eventos>│<suspendeTarea> FIN SI SI <capturarError> ENTONCES

9. <Administrador de Eventos>│<capturaError> FIN SI

10. <Administrador de Eventos>│<enviaRespuesta> END < Administrador de Eventos> Trayectorias Alternativas <parámetros evento incorrectos>

1. <Proceso Externo><Administrador de Interfaz><Administrador de Tareas>│<pantalla de invocación del servicio de Administración de Eventos><vuelve a enviar los parámetros del evento><parámetros del evento deben ser correctos>

Poscondición El Proceso Externo, Administrador de Interfaz, Administrador de Tareas recibe respuesta del evento o el error asociado a la ejecución del requerimiento de evento a través del administrador de eventos si los parámetros iníciales son correctos, en caso contrario recibe un error.

Requisito No Funcional

Comentario

Tabla 8 Caso de Uso Administrador de Eventos Tarea

82

Figura 28 Caso de uso Administrador de Identidad.

Caso de Uso Administrador de Identidad Resumen Recibe las solicitudes de procesos externos a través del servicio de administración

de identidad, procesa las solicitudes contra un LPAD, meta directorio, o base de datos de identificación de usuarios y envía la respuesta. Tomando en cuenta una jerarquía donde una persona o grupo de personas tienen asociada una ubicación geográfica (localidad) y pertenecen a una estructura organizacional (organigrama); las personas están asociadas a los grupo funcionales; las personas y los grupos tiene asociados roles y los roles tienen asociadas permisologías corresponden con el mayor nivel de la jerarquía.

Actor Proceso Externo, Administrador de Tareas

83

Precondición Administrador de Tareas Descripción <Administrador de Identidad> INICIA CUANDO <Proceso Externo><Administrador

de Tareas><invoca al Servicio de Administración de Identidad>

• <Proceso Externo><Administrador de Tareas>│<interfaz de invocación del Servicio de Administración de Identidad><introduce parámetros iníciales de identidad><parámetros de identidad deben ser correctos>

• <Administrador de Identidad>│<recibeIdentidad><parámetros de identidad deben ser correctos>

• <Administrador de Identidad>│<procesaIdentidad> SI <consultarIdentidad> ENTONCES

• <Administrador de Identidad>│<consultaIdentidad> FIN SI SI <crearIdentidad> ENTONCES

• <Administrador de Identidad>│<crearIdentidad> FIN SI SI <modificarIdentidad> ENTONCES

• <Administrador de Identidad>│<modificarIdentidad> FIN SI SI <eliminarIdentidad> ENTONCES

• <Administrador de Identidad>│<eliminarIdentidad> FIN SI SI <asociarIdentidad> ENTONCES

• <Administrador de Identidad>│<asociarIdentidad(roles a permisologia;personas o grupos a roles;personas a grupos;localidades a personas o grupos; estructura organizacional a persas o grupos>

FIN SI SI <validarIdentidad> ENTONCES

• <Administrador de Identidad>│<validarIdentidad> FIN SI SI <capturarError> ENTONCES

• <Administrador de Identidad>│<capturaError> FIN SI

• <Administrador de Identidad>│<enviaRespuesta> END < Administrador de Identidad> Trayectorias Alternativas <parámetros identidad incorrectos>

1. <Proceso Externo><Administrador de Tareas>│<pantalla de invocación del servicio de Administración de Identidad><vuelve a enviar los parámetros de Identidad><parámetros de Identidad deben ser correctos>

Poscondición El Proceso Externo, Administrador de Tareas recibe respuesta del requerimiento de identidad o el error asociado a la ejecución a través del administrador de identidad si los parámetros iníciales son correctos, en caso contrario recibe un error.

Requisito No Funcional

Comentario

Tabla 9 Caso de Uso Administrador de Identidad

84

Figura 29 Caso de uso Administrador de Estado Transición.

Caso de Uso Administrador de Estado Transición Resumen Recibe las solicitudes de procesos externos a través del servicio de administración

de estado transición, procesa las solicitudes y envía la respuesta. Actor Proceso Externo, Administrador de Tareas Precondición Administrador de Tareas Descripción <Administrador de Estado Transición> INICIA CUANDO <Proceso

Externo><Administrador de Tareas><invoca al Servicio de Administración de Estado Transición>

1. <Proceso Externo><Administrador de Tareas>│<interfaz de invocación del

Servicio de Administración de Estado Transición><introduce parámetros iníciales de estado transicion><parámetros de estado transición deben ser correctos>

2. <Administrador de Estado Transición>│<recibeestadotransicion><parámetros

85

de estado transición deben ser correctos> 3. <Administrador de Estado Transición>│<procesaEstadoTransicion>

SI <consultarEstadoTransicion> ENTONCES 4. <Administrador de Estado Transición>│<consultaEstadoTransicion>

FIN SI SI <crearEstadoTransicion> ENTONCES

5. <Administrador de Estado Transición>│<crearestado><creartransicion> FIN SI SI <modificarEstadoTransicion> ENTONCES

6. <Administrador de Estado Transición>│<modificarestado><modificartransicion>

FIN SI SI <eliminarEstadoTransicion> ENTONCES

7. <Administrador Estado Transición>│<eliminarEstado><eliminarTransicion> FIN SI SI <validarEstadoTransicion> ENTONCES

8. <Administrador Estado Transición>│<validarEstado><validarTransicion> FIN SI SI <asociarCalculoTiempo> ENTONCES

9. <Administrador Estado Transición>│<asociaCalculoTiempoEstadoTransicion>

FIN SI SI <capturarError> ENTONCES

10. <Administrador Estado Transición>│<capturaError> FIN SI

11. <Administrador Estado Transición>│<enviaRespuesta> END < Administrador Estado Transición> Trayectorias Alternativas <parámetros estado transición incorrectos>

1. <Proceso Externo><Administrador de Tareas>│<pantalla de invocación del servicio de Administración de Estado Transición><vuelve a enviar los parámetros de Estado Transición><parámetros de Estado Transición deben ser correctos>

Poscondición El Proceso Externo, Administrador de Tareas recibe respuesta del requerimiento de Estado Transición o el error asociado a la ejecución a través del administrador de Estado Transición si los parámetros iníciales son correctos, en caso contrario recibe un error.

Requisito No Funcional

Comentario

Tabla 10 Caso de Uso Administrador de Estado Transición

Durante la especificación de estos casos de uso se evidencia la necesidad del concepto de patrones de flujo de trabajo como escenarios de los patrones de análisis, en el Anexo A1.5, se proponen los mismos.

Una vez finalizada la especificación de los casos de uso se sugiere la incorporación de estos conceptos a un BPMS existente, para los efectos de la investigación se seleccionó a través de una matriz de evaluación para BPMS (Bonillo, 2005a), el software libre Uengine y se inicio la incorporación de los conceptos en esta herramienta, los resultados están disponibles y pueden ser consultados, al investigador.

El próximo capítulo versará sobre el análisis de los resultados obtenidos de la aplicación de esta metodología en el Proceso de Gestión de Versiones de ITIL.

86

Capítulo V Caso de Estudio

Este Capítulo consiste en la aplicación de la metodología a un caso del mundo real utilizando como dominio el proceso de Gestión de Versiones de ITIL. A continuación para este proceso se procederá a aplicar cada uno de los pasos propuestos en el capitulo anterior:

5.1. Crear Proceso:

En esta fase de la metodología se analiza, diseña, modela y configura el proceso de Gestión de Versiones de ITIL, lo cual se describe a continuación:

5.1.1 Analizar:

Consiste en la evaluación de los requerimientos tomando en cuenta el tipo de prioridad, se identifica el proceso y se le asigna prioridad dentro de la organización.

De acuerdo a lo establecido en la metodología una persona de la organización solicita la creación o modificación de un proceso a través de un formato de solicitud (Ver Anexo, 2), a continuación se identifica el requerimiento.

Para los efectos del caso de estudio, se asumirá que se requiere en una organización dada la creación del proceso sin que el mismo haya sido analizado o modelado con anterioridad, por lo que se dará por sentado la fase 5.1.1.1 Identificación del Requerimiento, que incluye:

• La descripción del requerimiento: En este caso la descripción del requerimiento concuerda con la necesidad de crear un proceso de Gestión de Versiones.

• Definir prioridad: La prioridad será la mayor dado que el proceso que constituye el caso de estudio, no compite con otros procesos para el análisis en la organización, y ;

• Evaluar cartelera de actividades: Las actividades principales se corresponden con 2 grandes fases (meta-procesos de la metodología) y en ellas se indica la descripción de los pasos sugeridos. (Ver, Anexo 3).

Seguidamente se inicia la fase 1.1.2 de Levantamiento de Información:

5.1.1.2.1 Mapear al Marco Referencial del Proceso y establecer los Patrones de Análisis: Para el caso de estudio, el marco referencial de procesos será ITIL. Es preciso citar que estos procesos de soporte a los servicios de ITIL, forman parte de un proceso mayor el cual varia dependiendo del dominio, por ejemplo en el área de Telecomunicaciones existe un mapa de procesos definido por el Foro Mundial de Gestión de Empresas de Telecomunicaciones (TeleManagementForum) el cual define un marco de procesos denominado ETOM (de las siglas en inglés Enhanced Telecom Operations Map), en el que los procesos de soporte a los servicios sugeridos por ITIL se relacionan con los procesos de ETOM según como se muestra a continuación.

87

Proceso ITIL Procesos ETOM Nivel 2 Relacionados Escritorio de Ayuda (Service Desk)

CRM Support & Readiness Customer Interface Management Selling Order Handling Retention & Loyalty S/P Interface Management Supply Chain development & Change Management

Gerencia de Incidentes (Incident Management)

Customer Interface Management Selling Order Handling Problem Handling Customer QoS/SLA Management Retention & Loyalty Service Configuration & Activation Service Problem Management Resource Provisioning Resource Trouble Management Resource Performance Management S/P Support & Readiness S/P Requisition Management S/P Problem Reporting & Management S/P Interface Management Supply Chain Development & Change Management

Gerencia de Problemas (Problem Management)

SM&O Support & Readiness Service Problem Management RM&O Support & Readiness Resource Trouble Management S/P Problem Reporting and Management S/P Performance Management Supply Chain Development & Change Management

Gerencia de Configuración (Configuration Management)

CRM Readiness & Support Customer QoS/SLA Management SM&O Support & Readiness Service Configuration and Activation Service Problem Management Service Quality Management RM&O Support & Readiness Resource Provisioning Resource Trouble Management Resource Performance Management Resource Data Collection & Processing S/P Requisition Management Product & Offer Capability Delivery Product & Offer Development & Retirement Service Strategy & Planning Service Capability Delivery Resource Development & Retirement Supply Chain Strategy & Management Supply Chain Development & Change Management Group Enterprise Management Asset Management

Gerencia de Cambios (Change Management)

SM&O Support & Readiness RM&O Support and Readiness

88

Resource Provisioning Resource Trouble Management Product & Offer Development & Retirement Service Development & Retirement Resource Development & Retirement Supply Chain Development & Change Management

Gerencia de Versiones (Release Management).

SM&O Support & Readiness Service Configuration and Activation Service Problem Management RM&O Support & Readiness Product & Offer Capability Delivery Product & Offer Development & Retirement Service Capability & Delivery Service Development & Retirement Resource Capability Delivery Resource Development & Retirement

Tabla 11 Relación Procesos ITIL con el Mapa de Procesos ETOM. Adaptado de TMF

Una vez relacionados los procesos con el marco referencial ITIL a continuación es necesario especificar los mismos en base a un Patrón de Análisis, en el caso del proceso de Gestión de Versiones, el mismo puede ser especificados como escenario del Patrón de Análisis “Producción” Propuesto por Ridao en el 2001 (descrito en el Anexo A1.1).

Una vez que se ha estipulado según un marco referencial cual es la mejor práctica para el proceso (lo que para los efectos de esta investigación doctoral a su vez se especifica como un conjunto de escenarios del Patrón de Análisis de Producción), se procede con el siguiente paso.

5.1.1.2.2. Levantar la situación actual del proceso, esto es estudiar como se ejecuta el proceso actualmente en la organización, con respecto al caso de estudio se asume que el proceso se está ejecutando a través del intercambio de correos electrónicos, sin una base de datos especifica y sin seguimiento y auditoria, por lo que será necesario implementarlo de acuerdo a una mejor práctica, sin embargo es preciso aclarar que este paso de la metodología lo que permite es identificar brechas entre como se ejecuta el proceso actualmente en la organización y como debería ejecutarse según el patrón de análisis, a fin que se pueda determinar como será modelado el procesos y si se asumirá la implementación de las diferencias encontradas y los riesgos.

Es importante citar que una vez estudiado el proceso desde la mejor práctica y de acuerdo a cómo se ejecuta en la actualidad en la organización, se decidirá la forma como se implementará el mismo y sus diferencias, lo que significara que se requiere realizar un cambio en la organización, es por esto que en este punto de la metodología se envía un requerimiento de cambio (RFC) al proceso de gestión de cambio (si el mismo existe), con la finalidad de indicar que se inicia el cambio en un nuevo proceso o en un proceso existente (es decir la metodología a su vez da por sentado que debe existir un proceso de gestión de cambio en la organización y que se debe invocar al mismo), seguidamente se procede con la siguiente fase.

89

5.1.1 Diseñar Proceso

Esta fase se inicia con la Estandarización de los Procesos (Paso 5.1.2.1) esta estandarización se refiere a indicar en base al análisis de brecha como se implementará el proceso tomando en cuenta su situación actual y la mejor práctica (para el caso de estudio se implementará el proceso de acuerdo a la mejor práctica).

Seguidamente en 5.1.2.2 se evalúa el riesgo de implementar las diferencias encontradas en el análisis de brechas, para el caso de estudio no se tendrán brechas, pues se implementará el proceso de acuerdo al patrón de análisis.

A continuación se realiza 5.1.2.3 Modelo propuesto de los procesos. Este modelo se realiza utilizando cualquier herramienta que permita realizar un diagrama en un lenguaje de modelado de procesos (IDEF, BPMN, BPA, UML, etc.), en el caso del proceso de Gestión de Versiones esto se realiza a través de los dibujos incluidos en la descripción de los escenarios presentados en el Anexo 4.

Es importante citar en este punto, que la metodología sugiere, que para poder modelar adecuadamente los procesos es necesario nombrar los objetos, las clases y sus relaciones a partir de un modelo canónico o único de objetos de la organización (MOC).

El MOC es el esquema teórico que define los objetos pertenecientes a la arquitectura, indica su amplitud, estructura y los estandariza para lograr un idioma de comunicación claro y preciso. El MOC al ser el elemento modelador de la arquitectura, define fundamentalmente la estructura de los datos y servicios que viajan a través de la capa de integración. (Bonillo, 2007a)

El MOC define en primer lugar, a los objetos que representan los datos corporativos (por ejemplo: cliente, facturación, etc.) definiendo el tipo, cantidad y estructura de los campos que los componen. De esta forma, una de las funciones que cumple el MOC es la de ser un diccionario de datos evolutivo que garantiza unicidad y claridad en las integraciones entre las aplicaciones.

El segundo elemento que define el MOC y probablemente el de mayor relevancia, es la infraestructura de servicios que arropa y reagrupa lógicamente a las funcionalidades de la organización de acuerdo a estándares para el soporte a los servicios, como es el caso de la iniciativa de java OSS/J (OSS/J, 2005).

El MOC es entonces también un diccionario de servicios corporativos que basado en el universo de funcionalidades disponibles y deseadas, construye agrupaciones lógicas alineadas con el Mapa ideal de Aplicaciones. La importancia de los servicios (y del esquema generado por el MOC) se deriva de la utilidad que los mismos tienen como herramienta indispensable para el modelado de los procesos de negocio a partir de la implementación que de ellos se hace en arquitectura de una forma única estándar orientada a la reutilización.

90

Ya existen esfuerzos significativos para proporcionar en cada dominio un modelo de objetos canónicos, en el caso de las empresas de telecomunicaciones, TMF basado en ETOM sugiere un SID (Modelo Compartido de Datos e Información).

5.1.2.4 Diseño de la configuración de laboratorio de hardware y software en el cual se modelarán e implementarán los procesos, como consecuencia de aplicar la metodología, para el caso de estudio se sugiere la siguiente arquitectura:

1. Centro de Modelado de Procesos (CMP): El centro de modelado es la unidad encargada de generar (modelar) los distintos procesos de la organización y de administrar todos los modelos existentes, para modificación y actualización de los mismos. Este CMP consta de equipos para el personal encargado de modelar y de administrar los procesos.

En base al caso de estudio, El CMP sugerido posee una computadora tipo Desktops para el modelado particular y aislado de los procesos y otra computadora tipo servidor como equipo para la Integración y Pruebas de todos los procesos y sus relaciones.

De acuerdo al caso de estudio se realizo una selección de la herramienta BPMS que se utilizaría en la organización, resultando seleccionado el BPMS de Software libre Uengine de acuerdo a los 95 criterios especificados para un BPMS y el método DESMET. De tal forma que en estos Desktops se tendrá la distribución libre del sistema operativo Linux Centus OS, la Base de Datos de distribución libre Hypersonic (con la finalidad de almacenar las variables que utiliza el modelador de procesos de Uengine), la herramienta de escritorio de distribución libre OpenOffice para el diseño de los procesos y Uengine para el modelado de los procesos, además del sistema controlador de versiones (CSV) y la herramienta de conexión remota (VNC). El Equipo de integración de todos los procesos, necesariamente necesitará un hardware de mayor capacidad a fin de lograr la integración de todos los procesos el cual es el servidor de desarrollo, parte del CCP.

2. Centro de Coreografía de Procesos (CCP): El centro de coreografía es la unidad encargada de generar la aplicación correspondiente por cada proceso que se haya modelado, uniendo los servicios, objetos, notificaciones, mensajes y excepciones con todas las aplicaciones que soportan los distintos procesos de la organización. Adicionalmente y en apoyo con la unidad de soporte de aplicaciones, se administran (mantenimiento adaptativo, correctivo y preventivo) todas las aplicaciones en producción.

Este CCP consta de servidores y equipos para el personal encargado de generar la completitud para la creación de las aplicaciones y de administrar las aplicaciones existentes, así como, de permitir la conexión de usuarios.

El CCP posee tres servidores para su operación. El servidor de desarrollo, al cual se conectan los consultores del CCP para generar la completitud de los modelos (UML,

91

WSDL y BPEL), realizar la coreografía para cada proceso y para la creación de la aplicación final, así como administrar las aplicaciones de los distintos procesos existentes en la organización realizando también las pruebas unitarias. El servidor de calidad (QA) el cual contiene una muestra “real” (lo más cercana posible al sistema en producción) del mapa de aplicaciones para cada proceso de la organización y en el que se realizan las pruebas integrales y el servidor de Producción, donde se encuentran todas las aplicaciones en ambiente productivo y donde debe existir una instancia del BPMS por cada aplicación existente con otra para la alta disponibilidad.

En estos Servidores se sugiere la distribución libre del sistema operativo Linux Red Hat 4 Application Server, la Base de Datos de distribución libre Hypersonic (con la finalidad de almacenar las variables que utiliza el administrador de procesos de Uengine), y Uengine para la administración de los procesos, además del sistema controlador de versiones CSV y la herramientas de conexión remota VNC y Secure Shell.

A continuación se describe el siguiente paso de la metodología.

5.1.3 Modelar

Consiste en: 5.1.3.1 Diagramar los procesos en un ambiente local con la herramienta de modelado de procesos del CMP (Uengine para el caso de estudio) tomado en cuenta además el MOC. En este paso además se decide cual será el estilo arquitectural, el patrón arquitectural y los patrones de diseño, interacción y código que se asociaran al proceso. Para los procesos del caso de estudio se seleccionaron los siguientes patrones:

Estilos arquitectónicos:

Estilos de Flujo de Datos: Esta familia de estilos enfatiza la reutilización y la modificabilidad. Es apropiada para sistemas que implementan transformaciones de datos en pasos sucesivos. El proceso de Gestión de Versiones de ITIL aplica este estilo ya que para hacer el manejo de una nueva versión de un producto se debe hacer transformaciones de datos de manera sucesiva actualizando la CMDB.

• Sistemas de control de procesos: Se caracterizan no sólo por los tipos de componentes, sino por las relaciones que mantienen entre ellos. En el caso de del proceso de Gestión de Versiones de de ITIL, se observa que el estilo arquitectónico Sistemas de control de procesos esta presente ya que se tiene una relación entre diferentes componentes como Gestión de Cambios y Gestión de Configuraciones.

Patrones arquitectónicos:

Tubería y filtros: Una tubería (pipeline) es una arquitectura que conecta componentes computacionales (filtros) a través de conectores (pipes), de modo que las comunicaciones se ejecutan como un flujo. El sistema tubería-filtros se percibe como una serie de transformaciones sobre sucesivas piezas de los datos de entrada. Los datos entran al sistema y fluyen a través de los componentes. De esta manera para que una

92

nueva versión sea aceptada debe pasar por un procedimiento aplicando los Estilos arquitectónicos Tubería y filtros (pipe&filter).

• Arquitecturas de Pizarra o Repositorio: En este estilo arquitectónico hay dos componentes principales; una estructura de datos que representa el estado actual y una colección de componentes independientes que operan sobre él. Haciendo la analogía con respecto a este estilo y al proceso de gestión de Versiones de ITIL, se tiene que la estructura de datos es la conocida como CMDB y los diferentes componentes que operan sobre la CMDB son Gestión de versiones, Gestión de Cambios y Gestión de Configuraciones.

Patrones de diseño:

Command: Este patrón permite solicitar una operación a un objeto sin conocer realmente el contenido de la operación, ni el receptor real de la misma. Para ello se encapsula la petición como un objeto, con lo que además se facilita la parametrización de los métodos. En el caso del Proceso de Gestión de Versiones de ITIL se aplica este patrón, ya que debe "deshacer" un versionamiento no exitoso.

Memento: Tiene como finalidad almacenar el estado de un objeto (o del sistema completo) en un momento dado de manera que se pueda restaurar en ese punto de manera sencilla. Para ello se mantiene almacenado el estado del objeto para un instante de tiempo en una clase independiente de aquella a la que pertenece el objeto (pero sin romper la encapsulación), de forma que ese recuerdo permita que el objeto sea modificado y pueda volver a su estado anterior. En el proceso de Gestión de Versiones de ITIL, se puede ver la aplicación de este patrón ya que si una versión no es exitosa y se debe regresar, la versión anterior del mismo se encuentra almacenada.

• Fotografía (Snapshot): Este patrón captura una fotografía del estado de un objeto para que este estado pueda luego ser restaurado. El objeto que inicia la captura o restauración del estado no necesita conocer nada acerca de la información del estado. Sólo necesita saber que el objeto cuyo estado está siendo capturado o restaurado, implementa una interfaz particular. En el proceso de Gestión de Versiones de ITIL se puede ir a una versión específica del proceso.

Patrones de Interacción:

• Portal: Se utilizaron todos los patrones de interacción disponibles en Liferay que es el portal de manejo de contenido, en el que se construyo el motor de procesos de Uengine, el cual permite tomar cualquier pantalla y aplicar patrones de interacción más atómicos como calendarios, botones de selección, etc.

Idiom:

• El idiom seleccionado es Java, ya que Uengine esta está desarrollada bajo éste lenguaje de programación.

93

Es importante citar que al realizar la selección de estos patrones y considerar los mismos en la elaboración del caso de estudio, además de utilizar las mejores prácticas se obtuvo un menor tiempo de diseño de los procesos comparado con un proceso de la misma complejidad que se realizó en el modelador de procesos Uengine sin aplicar los patrones, fundamentalmente dada la capacidad de reutilizar el conocimiento ya existente tanto para su adaptación como para su extensión.

Para modelar los procesos según las mejores prácticas la metodología sugiere que los patrones de análisis y sus escenarios se expresen a través de los patrones de flujo de trabajo descritos en el Anexo A1.5.

Lo que sugiere entonces la metodología, es que al modelar el proceso se utilicen de forma automática estos patrones de flujo de trabajo, con la finalidad de cumplir con esto en el caso de estudio, se realizaron en la herramienta Uengine, estos procesos correspondientes a los patrones de flujo de trabajo y se incluyeron de tal forma que puedan ser utilizados automáticamente en el modelado de los procesos del caso de estudio.

5.1.3.2 Simular Prueba Funcional, se realiza una simulación de la funcionalidad del proceso en la herramienta de modelado (las herramientas de modelado de procesos, comúnmente contienen la funcionalidad de realizar una simulación a fin de detectar tendencias, cuellos de botella en los procesos modelados).

5.1.3.3 Integrar Arquitectura de Procesos y 5.1.3.4 Simular Prueba Integral.

Para finalizar el subproceso de modelar, se realizar una simulación integral de todos los procesos, esto con la finalidad de detectar problemas sobre la sinergia de los procesos y sus consecuencias.

5.1.4 Configurar

En este paso, se tomo el proceso de Gestión de Versiones de ITIL y se realizó una Implementación en el Motor de Ejecución de Procesos de Uengine, de tal forma que se realizaron las siguientes acciones:

5.1.4.1 Completar los diagramas UML, se realizaron todos los diagramas UML del caso de estudio, y se verificaron los mismos de acuerdo al resultado obtenido en el diseñador de procesos Uengine;

5.1.4.2 Construir la Lógica de Negocio, en este paso se utilizaron las bondades del diseñador de procesos de Uengine y se construyeron las reglas de negocio, las tablas, las interacciones, los servicios locales, servicios Web (en este caso la metodología contempla que si es necesario realizar servicios Web y alguna otra lógica de negocio especial, se contacte a un proceso de Arquitectura el cual construirá estos servicios, en este caso no fue necesario dado que los procesos se modelaron de forma local) y las tablas de acuerdo a los estilos arquitecturales, patrones arquitectónicos y patrones de diseño seleccionados en el paso 5.1.3;

94

5.1.4.3 Construir Interfaz, en este paso se utilizaron los patrones de interfaz disponibles en Uengine al realizar la acción de mejorar “customize” las ventanas del objeto Trabajo Humano “Human Work” de Uengine;

5.1.4.4 Construir Reportes, para la creación de los reportes se utilizo la propiedad de análisis multidimensional que incluye a través de creación de cubos la aplicación Uengine, se aplicaron costos a las actividades y se configuraron los tiempos, teniendo todos estos datos disponibles en el momento de generar los reportes.

5.1.4.5 Configurar el BPEL, se procedió a la revisión del BPEL y su implementación en el Motor de Ejecución de procesos de Uengine;

5.1.4.6 Realizar Pruebas Unitarias, finalmente en esta fase se realizó la prueba unitaria en el motor de ejecución, simulando a través de ejemplos todas las alternativas posibles para los diferentes flujos de trabajos modelados para el Proceso de Gestión de Versiones de ITIL.

El resto de los pasos de la metodología (5.2.1 Mantener configuraciones y 5.2.2 Monitoreo) no se realizaron dado que se llego solo a la configuración de los procesos de acuerdo al alcance contemplado en el caso de estudio. Sin embargo los mismos se refieren a las tareas de mantenimiento una vez que los procesos sean colocados en producción.

A continuación se describen las conclusiones y recomendaciones de la investigación.

95

Capítulo VI Conclusiones y Recomendaciones

En la caracterización de las organizaciones como sistema complejo, fue de gran utilidad la representación de las mismas a través de la teoría general de los sistemas, permitiendo así seleccionar los procesos de desarrollo de software UP, XP y FDD, los diferentes patrones de software, lo que condujo al planteamiento de una nueva taxonomía de patrones, con su representación a través de un metapatrón (incluyendo su medición de calidad con ABAS e ISO-9126 e ISO-1458) y la posterior relación de todos estos conceptos en el dominio de gerencia de procesos de negocio.

Es importante citar que con base en todo lo discutido hasta este momento de la investigación, no existe en la actualidad un tratamiento lo suficientemente exhaustivo y consolidado de los temas de gerencia de los procesos del negocio sustentada en el uso de patrones, tomando en cuenta la trazabilidad y la calidad del proceso y el producto de software. Mediante esta investigación se atacan estas deficiencias, proponiendo la construcción de:

1. Una tecnología de patrones para la metodología de gerencia de procesos de negocio con base en la construcción sustentada en componentes de software: un estudio de las alternativas existentes para la selección, aplicación y verificación de patrones y de la composición de componentes de software desde el punto de vista de los condicionantes planteados aquí (trazabilidad, medición de calidad, verificación estática, automática y asequible).

2. Una definición de patrón abierta y aplicable en muy diversos ámbitos del diseño, desarrollo y mantenimiento del software sin perder de vista que el software es uno sólo a pesar de los diversos enfoques de patrones y construcción que existen en la ingeniería de software, y que debe existir un marco referencial que integre estos enfoques en pro de una sola actividad de elaboración de software.

3. Un método de modelado de patrones que permita la trazabilidad, y que puede ser aplicado sobre entidades de muy diferentes tipos y en etapas diversas del ciclo de vida del software. Este método de modelado y verificación tiene además características especiales:

- Puede ser utilizado con facilidad por una organización de desarrollo, sin necesidad de conocimientos sobre métodos formales.

- Fomenta la colección y uso de conocimiento que habitualmente se pierde.

- Permite gestionar este conocimiento sin necesidad de integrarlo en el código fuente de los programas desarrollados.

- No está ligado a ningún lenguaje de desarrollo específico ni a ningún propósito específico.

96

4. Un sistema de verificación de componentes plenamente viable en la práctica:

- Las herramientas pueden desarrollarse en base a tecnologías en red.

- Los conocimientos básicos necesarios encajan en el perfil típico de los profesionales del desarrollo de software, no planteando un gran choque de mentalidad en su adquisición en el caso que sea necesario.

5. Diversos prototipos que apoyan la viabilidad de los métodos propuestos.

El uso de los patrones en la construcción de software basado en componentes suele recurrir a descripciones de las interfaces de los componentes, entendidas (con las variaciones procedentes en cada caso) como una colección de métodos y de parámetros que reciben las denominadas signaturas. Cuando se combinan patrones y componentes, es frecuente que se verifique que dichas signaturas encajan correctamente, y existen medios (que han alcanzado plena difusión) para detectar esto en etapas tempranas de ese proceso de combinación. Sin embargo, existen defectos que no tienen relación alguna con las signaturas de los componentes, y que surgen también de su combinación. Y estos defectos no suelen detectarse de forma automatizada; no parece haber alcanzado amplia difusión algún método encaminado a tener en cuenta las restricciones de funcionamiento de los componentes y a poner en relación esas restricciones, sean del tipo que sean (funcionales, de rendimiento, de propósito y de dominios). La experiencia profesional demuestra que en muchas ocasiones estos defectos se detectan en la fase de prueba, o peor aún, en la fase de explotación, la metodología propuesta permite detectar en las etapas tempranas estas consistencias con un menor impacto en las últimas etapas del desarrollo.

Muchos de estos defectos podrían detectarse en etapas tempranas, tales como las incongruencias de signaturas. Sólo se necesitaría un método que permitiese adjuntar a cada componente una descripción de las restricciones conocidas respecto a su funcionamiento, y utilizar esas restricciones en un sistema de verificación. Tal como se propone en el metapatrón utilizado a través de la metodología expuesta en este trabajo.

Este método debería presentar ciertas propiedades importantes. La verificación debería ser estática en el sentido descrito; no se trata de probar el sistema en ejecución, sino de llegar a conclusiones mediante el análisis a priori de la información disponible, es decir ver el resultado de la calidad del patrón en el proceso y el producto de software. La verificación debe también ser automática porque eso es lo que posibilita que sea realizada repetidamente, a un bajo costo y que ofrezca resultados no ambiguos, esto en especial se permite bajo el paradigma BPM.

Algunos métodos formales (u otras técnicas) podrían ser utilizados para propósitos similares a los planteados aquí; pero la percepción que se tiene de los métodos formales y su dificultad de adopción impiden en la práctica una difusión a gran escala. La metodología propuesta observa en todo momento como prioritario la simplicidad, viabilidad técnica, flexibilidad de aplicación y facilidad de adopción que otras técnicas no contemplan.

97

Durante la elaboración de esta tesis doctoral se han logrado avances no sólo en cuanto a la definición de las bases teóricas y metodológicas, sino también en el sentido práctico, se realizo un proceso de evaluación de un BPMS en software libre, siendo seleccionado Uengine, se realizaron seis tesis de pregrado en ciencias de la computación, en las cuales, se utilizó Uengine y se aplico la metodología de gestión de procesos de negocio sustentada en el uso de patrones en los procesos de soporte a los Servicios de ITIL: Escritorio de Servicio, Gestión de Incidentes, Gestión de Problemas, Gestión de Cambio, Gestión de Versiones, Gestión de Configuración; en relación a la taxonomía de patrones, se realizo una tesis de pregrado en ciencias de la computación, donde se automatizo un proceso de utilización del metapatrón, se relacionaron algunos patrones y se midieron sus atributos de calidad para un caso de estudio.

La propuesta de tesis aquí planteada es que es posible dotar a la tecnología de patrones de esos métodos. Y la demostración de esta tesis se ha basado en la construcción de un marco referencial integrado, una propuesta metodológica y su aplicación en seis casos de estudio. La validación de la metodología desarrollada se basa en la implementación de prototipos del sistema de verificación a través de los casos de estudio en el dominio de la gerencia de los procesos de negocio (BPM), la aplicación de esos prototipos a diferentes tipos de problemas, y el sometimiento de la metodología al dictamen de expertos en los diferentes ámbitos involucrados.

El proceso de desarrollo de prototipos mediante el caso de estudio, siempre mediante técnicas fiables y ampliamente disponibles, sirvió para constatar que el desarrollo de herramientas que soporten la metodología es técnicamente viable.

En la realización del arqueo bibliográfico y demás consultas hechas a las diferentes fuentes documentales para la realización de la presente investigación, y en el tiempo mismo de recolección de toda la data necesaria para la misma, no se hicieron presente situaciones emergentes no solucionables que impidiesen la consecución de los objetivos planteados.

Específicamente, resultó complicado establecer las diferencias entre estilos arquitecturales, patrones de arquitectura y patrones de diseño, eso sin mencionar los patrones de análisis, código (o "idioms"). Por esa razón, inicialmente se utilizaron indiscriminadamente, luego se establecieron las diferencias entre ellos y se aclaró que no sólo se habla de patrones de diseño al nivel de “diseño detallado”, sino que también se puede hablar de patrones de diseño al nivel de arquitecturas. Es por esto que algunos autores lo tratan como sinónimos; además, hay métodos y técnicas que pueden ser aplicados, tanto en estilos como en patrones arquitecturales, por lo que su diferenciación, quizás, no sea necesaria.

Es importante explicitar los problemas para la selección y aplicación de patrones. Y no es de extrañar que la mayoría de estos problemas estén relacionados con la selección de los mismos. No es extraño, pues, a veces, las diferencias entre unos y otros son muy sutiles, lo que puede ser factor determinante en desarrolladores con poca experiencia.

También se observa que los patrones de diseño tienen una limitación: es difícil evaluarlos con base en un modelo de calidad particular, por lo que el estudio del tema ABAS, una

98

estructura que extiende la representación dada por GoF con la finalidad de especificar la información sobre las características de calidad relativas a cada patrón, fue pertinente para profundizar en el tema de patrones.

Con relación a los ADLs, vale mencionar que todos los elementos constitutivos que se mencionaron en el texto, son deseables; pues, Vestal (1996), en sus investigaciones sobre el tema, concluye que todos los ADLs deben soportarlos en algún grado.

El enfoque de diseño arquitectural de UP encaja como un "framework" de procesos genérico que puede ser fácilmente modificado para el método J. Bosch o el método ABD o cualquier combinación de los metidos expuestos.

Por otra parte, el método UP y el método Bosch coinciden en el hecho de que la arquitectura inicial debe ser seleccionada sobre la funcionalidad básica, por ejemplo a partir de las abstracciones principales del sistema. Esta arquitectura inicial es entonces transformada en el proceso de diseño arquitectural.

Por otra parte, UP considera la revisión, que son los puntos principales de ATAM, en el modelo de prueba.

Los siguientes principios generales de diseño arquitectural son propuestos para sintetizar las principales actividades de los métodos de diseño discutidos (Losavio et al., 2004):

1. Iniciar con los requisitos funcionales.

2. Capturar los requisitos no funcionales (calidad y negocio)

3. Diseñar estrategias que pueden basarse o reutilizar estilos arquitecturales o patrones

4. Diseño de la arquitectura por transformaciones sucesivas.

Se puede concluir la investigación, determinando que no existe actualmente un tratamiento lo suficientemente exhaustivo y consolidado de los temas de gerencia de los procesos de negocio sustentada en el uso de Patrones basados en componentes y su calidad, a pesar de su gran importancia.

Sin métricas para evaluar el diseño basado en componentes reutilizable no se puede realizar una verdadera ingeniería del software. Para resolver este conflicto, una posible solución a largo plazo puede basarse en dos ideas principales. En primer lugar, no puede haber consenso sobre temas demasiado genéricos. Por ello, es preciso definir y consensuar modelos de calidad para productos muy específicos. Y en segundo lugar, la evaluación de la calidad del diseño basado en componentes (es decir, las medidas que se realizan sobre sus atributos de calidad) debiera hacerse por entidades independientes, al menos hasta que los desarrolladores y arquitectos de software adquieran la madurez del tema de calidad, todo esto dentro de un paradigma sistémico como lo es BPM y bajo una metodología que permita la gestión de los patrones de forma auto asistida y por conocimiento previo para la reutilización en base a la extensión y la adaptación de componentes.

99

Como una recomendación importante resalta la aplicación de esos prototipos a problemas muy diferentes permitiendo comprobar la flexibilidad y amplitud de la propuesta metodológica. Deliberadamente, se deberán elegir casos de estudio variados, no relacionados entre sí, representativos de diversos aspectos del desarrollo del software, y sobre todo se deberá tratar de casos de estudio que no se habían tenido en cuenta a la hora de formular el modelo o las herramientas.

Como trabajo futuro, se recomienda la automatización de la metodología a través de un BPMS, esto es incluir el sistema de administración de patrones dentro del BPMS y utilizar la metadata resultante en los diferentes pasos a fin de agilizar el proceso de desarrollo teniendo disponible la medición de calidad de los patrones de forma automatizada.

100

Referencias Bibliográficas Acosta, E. y Zambrano, N. Patrones de Interfaces: un concepto integrador en el desarrollo de aplicaciones. XXVII Conferencia Latinoamericana de Informática CLEI´2001. Mérida, 2001.

Acosta, E. y Zambrano N. Patterns and Objects for User Interface Construction, in Journal of Object Technology, vol. 3 no. 3 March-April 2004 pp. 75-90

Alexander, C. The Timeless Way of Building. Oxford University Press, 1979.

Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fidsdahl-King, I., Angel, Sh. A Pattern Language. Oxford University Press, New York, 1977.

Allen, P. y Frost, S. Component-Based Development for Enterprise Systems. Applying the SELECT PerspectiveTM. Cambridge University Press. 1998.

Barros, O. Arquitectura de Aplicaciones en e-Business. Documento de Trabajo Nº 26, CEGES, Dpto. de Ingeniería Industrial, U. de Chile. 2002.

Bell, T. BPM Taxonomy: Creating Clarity in a Confusing Market, Gartner Research Note, Technology, T-18-9669. 2003.

Bonillo, P. Modelo Sistémico de Evaluación de Software de Control Remoto. ARTICULO ARBITRADO. Revista Tecnica de la Universidad del Zulia, 2004.

Bonillo, P. Modelo de Calidad de Software Educativo. Jornadas de Postgrado de la UPEL. Caracas. Distrito Capital, 2004

Bonillo, P. Evaluación de Arquitecturas de Gerencia de Procesos de Negocio. LV Convención Anual de ASOVAC. Caracas. Distrito Capital, 2005.

Bonillo, P. Propuesta Metodológica para la Gerencia de Procesos de Negocio. LV Convención Anual de ASOVAC. Caracas. Distrito Capital, 2005.

Bonillo, P. Patrones de Flujo de Trabajo para la Gerencia de Procesos de Negocio. LV Convención Anual de ASOVAC. Caracas. Distrito Capital, 2005.

Bonillo, P. Gerencia de la Tecnologia de Informacion y Comunicación en Organizaciones Transcomplejas en la Posmodernidad. Caso de Estudio: Compañía Anonima Nacional de Telefonos de Venezuela (CANTV). Jornadas de Investigación en Gerencia Universidad Yacambú. Barquisimeto. Estado Lara, 2005.

Bonillo, P. Propuesta de un Meta-Patrón para la Evaluación de la Calidad en los Patrones de Software. LVI Convención Anual ASOVAC. Cumana. Estado Sucre, 2006.

Bonillo, P. Propuesta Metodológica para la Gerencia de los Procesos de Negocio. ARTICULO ARBITRADO. Revista de Gestão da Tecnologia e Sistemas de Informação Journal of Information Systems and Technology Management. Vol. 3, No. 2, 2006, p. 143-162. ISSN online: 1807-1775. Sao Paulo. BRASIL, 2006.

Bonillo, P. Propuesta de un Marco de Arquitectura Empresarial para la Gestión de Tecnología y Sistemas de Información. CONTECTSI. Sao Paulo. BRASIL, 2007.

101

Bonillo, P. Propuesta de una Arquitectura de Software Empresarial Orientada a Servicios. CONTECTSI Sao Paulo. BRASIL, 2007.

Bonillo, P. Methodological Proposal for Business Process Management sustained in the use of Patterns. Journal Object Technology, Vol 7. No. 5. Sep-Oct 2008.

Bosch, J. Design & Use of Software Architectures. Addison Wesley, 2000.

Braude, E. Ingeniería de software. Una perspectiva orientada a objetos. México: Alfaomega. 2003.

Coad, P. y May, M. JAVA Design: Building Better Apps and Applets 2nd Edition. Yourdon Press, Upper Saddle River, 1999.

Coplien, J. y Schmidt, D. Pattern Languages of Program Design. Addsion- Wesley, Reading, MA, 1995.

Cornella, A. Los Recursos de Información, McGrall-Hill S.A., España, p. 76,27. 1996

Davenport, T. Process Innovation – Reengineering Work through Information Technology. Harvard Business School Press, Boston, Massachusetts, 1998.

Douglas, P., Alliger G. y Goldberg R. Client-Server and Object-Oriented Training. En Computer, páginas 80–84. June, 1996.

Earl M.J.: The New and the Old of Business Process Redesign. Journal of Strategic Information Systems, Vol. 3, No. 1, 1996, pp. 5 – 22.

Fowler, M. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997.

Gamma, E., Helm, R., Johnson, R., y Vlissides, J. Design Patterns. Addison Wesley. 1995

Hammer M., Champy J.: Reengineering the Corporation: A Manifesto for Business Revolution. N. Brealey, London, 1996.

Harris, K. The Re-emergence of Business Process Design, Gartner Research Note, Strategic Planning, SPA-21-1352. 2003

Hayward, S. BPM: A Key Ingredient in Business Process Fusion, Gartner Research Note, Markets, M-19-8201.2003.

ISO/IEC 9126. Information Technology-Software Product Evaluation-Quality Characteristics and Guideline for Use.2001

ISO/IEC 9126-1, Software Engineering-Product Quality. Part 1: Quality Model, 2001.

ISO/IEC: FCD 9126-1.2: Information Technology - Software Product Quality. Part 1: Quality Model, 1998.

ISO/IEC14598-3. Information Technology - Software Product Evaluation - Part 3: Process for Developers. Software Engineering, June 1999.

Jacobson, I., Griss, M., y Jonsson, P. Software Reuse. Architecture, Process and Organization for Business Success. Addison-Wesley. 1997.

Kazman R., y Klein, M. Attribute-Based Architectural Styles. [Documento en línea]. Disponible en: http://www.sei.cmu.edu/publications/documents/99.reports/99tr022/99tr022abstract.html. 2004.

102

Larsen, G. Designing component-based frameworks using patterns in the UML. Communications of the ACM, 42(10):38-45. 1999.

Losavio F., Chirinos L., Matteo A., Lévy Nicole y Ramdane A. 2004. Designing Quality Architecture: Incorporate ISO Standards into the Unified Process. Information Systems Management, Winter 2004, pág.: 27-44.

MacDonald, S. Information for Innovation. New York, Oxford University Press. 1998.

Magnus, R. Developing a Methodology for the Evaluation Cooperative Systems. Computing Department Lancaster University. 1997.

Moore T.C., Whinston A.B.: A Model of Decision Making with Sequential Information Acquisition. Decision Support Systems, Vol. 2, No. 4, 1986, pp. 289 – 308.

Navasa, A., Pérez, M., Murillo, J., y Hernández, J. Aspect oriented software architecture: A structural perspective. Reporte del proyecto CICYT, TIC 99-1083-C2-02. 1999.

Paredes, L. Gestión Tecnológica y reconversión industrial. Revista Espacios, Vol 12. Num. 3. p. 59-77. 2004

Pressman, R. (1997) Managing Change for Rapid Development. IEEE Software. p. 120-122 1997.

Ridao, M. Uso de Patrones en el Proceso de Construcción de Escenarios. Tesis Maestría en Ingeniería de Software, 2001.

Schmidt, D.Fayad, M y Jonson, R. Software Patterns. Communications of the ACM, 39(10):37–39, 1996.

Shael, T. Workflow Management System for Process Organizations. Springer-Verlag Berlin Heidelberg. New York. 1999.

Strassmann, P. Getting a glimpse, through numbers, of who’s using technology well. Baseline 500. 2007

Szyperski, C. Component Software – Beyond Object-Oriented Programming. Addison-Wesley, 1997 (reimpreso en 1998). ISBN: 0-201-17888-5

Tamayo, M. El Proceso de Investigación Científica. Limusa Noriega Editores. México. 2000.

Tapscott, D. (1998) La Economía Digital, McGraw-Hill S.A., Bogotá. p 4.

Tepfenhart W. y Cusick J. A Unfied Object Topology. IEEE Software, páginas 31–35, May/June 1997.

Vestal, S. A cursory overview and comparison of four Architecture Description Languages. Technical Report, Honeywell Technology Center. 1996.

Vollmer, K. Market Overview: Business Process Management, Giga Research, Planning Assumption, RPA-022004-00001. 2004.

White, T. New Tools for New Times: The Workflow Paradigm. Future Strategies Inc. Alameda California. 1996.

Win Van Grembergen. Published in Information Technology Evaluation Methods and Management. Idea Group Publishing, pp. 185-197. 2002

103

Anexo 1 Descripción Taxonomía de Patrones A continuación, en este anexo se explican con mayor detalle cada uno de los patrones que integran la taxonomía propuesta: análisis, arquitectural, diseño e interacción. Al final, se presentan los patrones de flujo de trabajo como escenarios de los patrones de análisis, por lo que no se incluyen los mismos dentro de la taxonomía. De igual forma no se incluye el tema particular de los idioms, dado que son específicos por tecnología, sin embargo es conveniente mencionar que para la mayoría de los BPMS, el idiom es JAVA.

A1.1 Patrón de Análisis.

Según Alexander, “Cada patrón describe un problema que ocurre una y otra vez, y describe la solución a ese problema, de tal manera que dicha solución pueda ser usada un millón de veces más, sin hacerlo necesariamente dos veces del mismo modo” (Alexander et al., 1997) La idea central de la construcción de escenarios utilizando patrones consiste en estudiar las situaciones desde un punto de vista diferente al utilizado por otras técnicas de elaboración de escenarios. Se pretende tener una visión más conceptual y estructural de las situaciones, con el fin de identificar la naturaleza intrínseca de las mismas. Con esa visión, será posible determinar el tipo de escenario correspondiente a cada situación y así, elegir un patrón de un catálogo, rehusando su estructura con el fin de derivar el escenario más fácil y directamente. Los patrones son presentados como escenarios descritos a los que se ha agregado un reducido número de reglas de conformación como meta componentes del escenario. Cada componente del escenario, según la estructura definida en (Leite et al., 2000), ha sido completado con un texto nominal que se espera sea reemplazado en el escenario real generado al usar el patrón pero que a su vez guíe en la redacción del componente. (Ridao, 2001). En la figura A1.1 se presenta el patrón de Producción y en la figura A1.2 el escenario DISEÑAR LA AGENDA DE REUNIONES correspondiente al caso de estudio Sistema de Agenda de Reuniones.

Figura A1.1: Descripción del Patrón Producción. (Ridao, 2001)

104

Figura A1.2: Ejemplo de un Escenario de Tipo Producción. (Ridao, 2001) En cada uno de los ejemplos se puede observar que todos los componentes, además de los episodios, se ajustan a la descripción de los mismos en el patrón correspondiente. Analizando los episodios del escenario de la Figura A1.2 puede verse que se trata de producciones. Los episodios 2, 4 y 8 corresponden a sub-escenarios, que fueron analizados en forma independiente y resultaron ser también casos de producción. Por ello es posible determinar que se trata de un ejemplo puro de Producción. A continuación un listado de los patrones de Análisis:

1. Producción 2. Servicio 3. Colaboración 4. Negociación Inconclusa 5. Negociación Inconclusa con Disparador de Escenarios 6. Fin de Negociación 7. Etapa de Negociación 8. Etapa de Negociación con Disparador de Escenarios 9. Negociación Terminada 10. Producción + Servicio + Colaboración 11. Negociación inconclusa con producción o servicio o colaboración 12. Fin de Negociación con producción o servicio o colaboración 13. Etapa de Negociación con producción o servicio o colaboración 14. Negociación terminada con producción o servicio o colaboración

105

15. Negociación inconclusa con Disparador de Escenarios y producción o servicio o colaboración

16. Etapa de Negociación con Disparador de Escenarios y producción o servicio o colaboración

17. A Simple Pinboard 18. Structured Pinboard 19. Virtual Library 20. Virtual Library with Active Agents 21. Administrador de sub. Tarea 22. Asignación Automática Secuencial con Escalación 23. Asignación Automática Secuencial 24. Asignación con Escalación 25. Asignación Paralela Revisión Final con Escalación 26. Asignación Paralela 27. Asignación sin Notificación 28. Asignación 29. Basic Control Patterns 30. Sequence 31. Parallel Split 32. Synchronization 33. Exclusive Choice 34. Simple Merge 35. Advanced Branching and Synchronization Patterns 36. Multiple Choice 37. Synchronizing Merge 38. Multiple Merge 39. Discriminator 40. N-out-of-M Join 41. Structural Patterns 42. Arbitrary Cycles 43. Implicit Termination 44. Cancellation Patterns 45. Cancel Activity 46. Cancel Case 47. Patterns Involving Multiple Instances 48. MI with a priori known design time knowledge 49. MI with a priori known runtime knowledge 50. MI with no a priori runtime knowledge 51. MI without synchronization 52. State-based patterns 53. Deferred Choice 54. Interleaved Parallel Routing

A1.2 Patrón Arquitectural

Es frecuente que se confundan los términos: estilo y patrón arquitectural; a continuación se profundizara en el término patrón arquitectural, a fin de establecer las diferencias (Tabla A1.1). Patrón arquitectural. Buschmann et al. (1996) lo define como una regla que consta de tres partes, la cual expresa una relación entre un contexto, un problema y una solución: - Contexto. Es una situación de diseño en la que aparece un problema de diseño. - Problema. Es un conjunto de fuerzas que aparecen repetidamente en el contexto. - Solución. Es una configuración que equilibra estas fuerzas.

106

Estilo Arquitectónico Patrón Arquitectónico

Sólo describe el esqueleto estructural y general para aplicaciones

Existen en varios rangos de escala, comenzando con patrones que definen la estructura básica de una aplicación

Son independientes del contexto al que puedan ser aplicados

Partiendo de la definición de patrón, requieren de la especificación de un contexto del problema

Cada estilo es independiente de los otros Depende de patrones más pequeños que contiene, patrones con los que interactúa, o de patrones que lo contengan

Expresan técnicas de diseño desde una perspectiva que es independiente de la situación actual de diseño

Expresa un problema recurrente de diseño muy específico, y presenta una solución para él, desde el punto de vista del contexto en el que se presenta

Son una categorización de sistemas Son soluciones generales a problemas comunes

Tabla A1.1 Diferencias entre estilo y patrón arquitectónico Para Buschmann et al. (1996) son plantillas para arquitecturas de software concretas, que especifican las propiedades estructurales de una aplicación y tienen un impacto en la arquitectura de subsistemas. La selección de un patrón arquitectónico es, por tanto, una decisión fundamental de diseño en el desarrollo de un sistema de software. Algunos patrones arquitecturales se muestran en la Tabla A1.2. Patrón Arquitectónico Descripción

Layers Consiste en estructurar aplicaciones, las cuales pueden ser descompuestas en grupos o sub-tareas y se clasifican de acuerdo con un nivel particular de abstracción.

Pipes and Filters Provee una estructura para los sistemas que procesan un flujo de datos. Cada paso de procesamiento está encapsulado en un componente filtro (filter). El dato pasa a través de conexiones (pipes), entre filtros adyacentes.

Blackboard Aplica para problemas cuya solución utiliza estrategias no determinísticas. Varios subsistemas ensamblan su conocimiento para construir una posible solución parcial ó aproximada.

Broker Puede ser usado para estructurar sistemas de software distribuido con componentes desacoplados que interactúan por invocaciones a servicios remotos. Un componente broker es responsable de coordinar la comunicación, el reenvío de solicitudes y la transmisión de resultados y excepciones.

Model-View-Controler Divide una aplicación interactiva en tres componentes. El modelo (model) contiene la información central y los datos. Las vistas (view) despliegan información al usuario. Los controladores (controlers) capturan la entrada del usuario. Las vistas y los controladores constituyen la interfaz del usuario.

Presentation-Abstraction-Control

Define una estructura para sistemas de software interactivos de agentes de cooperación, organizados de forma jerárquica. Cada agente es responsable de un aspecto específico de la funcionalidad de la aplicación y consiste en tres componentes: presentación, abstracción y control.

107

Microkernel Aplica para sistemas de software que deben estar en capacidad de adaptar los requerimientos de cambio del sistema. Separa un núcleo funcional mínimo del resto de la funcionalidad y de partes específicas pertenecientes al cliente.

Reflection Provee un mecanismo para sistemas cuya estructura y comportamiento cambia dinámicamente. Soporta la modificación de aspectos fundamentales como estructuras, tipos y mecanismos de llamadas a funciones.

Tabla A1.2 Patrones Arquitecturales A continuación un listado de los estilos arquitecturales: 1. Estilos de Flujo de Datos 2. Tubería y filtros 3. Estilos Centrados en Datos 4. Arquitecturas de Pizarra o Repositorio 5. Estilos de Llamada y Retorno 6. Model-View-Controller (MVC) 7. Arquitecturas en Capas 8. Arquitecturas Orientadas a Objetos 9. Arquitecturas Basadas en Componentes 10. Estilos de Código Móvil 11. Arquitectura de Máquinas Virtuales 12. Estilos heterogéneos 13. Sistemas de control de procesos 14. Arquitecturas Basadas en Atributos 15. Estilos Peer-to-Peer 16. Arquitecturas Basadas en Eventos 17. Arquitecturas Orientadas a Servicios 18. Arquitecturas Basadas en Recursos Seguidamente un listado de los patrones arquitecturales: 1. Capas 2. Tubería-filtros 3. Pizarra 4. Broker 5. Model-View-Controller 6. Presentation-Abstraction-Control 7. Reflection (metanivel que hace al software consciente de sí mismo) 8. Microkernel (núcleo de funcionalidad mínima)

A1.3 Patrones de Diseño

Los patrones de diseño, se ubican en el nivel de diseño detallado, estos describen un problema a ser resuelto, una solución y el contexto en el cual la solución trabaja. Nominan una técnica y describen su costo y su beneficio. Según Gamma et al. (1995) un patrón de diseño tiene cuatro elementos esenciales: - El nombre: a cada patrón, se le ha asignado una denominación que permite que los entendidos en el

tema, puedan conversar usando un diccionario común. Permite un mayor grado de abstracción y permite la comunicación entre colegas, construyendo un lenguaje compartido. Según GoF, uno de los problemas que tuvieron, fue encontrar un nombre apropiado para cada patrón que catalogaron.

108

- El problema: se explica el problema original, y su contexto. Puede describir desde detalles específicos, como algoritmos, o clases y estructuras que se han encontrado inflexibles a la hora de implementarse. Todo patrón nace de un problema a solucionar.

- La solución: cada patrón puede tener una solución a un problema. Un mismo problema real, puede tener dos soluciones parecidas, correspondientes a dos patrones (muchas veces pasa esto con el Abstract Factory, versus el Factory Method, por ejemplo). Pero la elección seguramente recaerá en el patrón que mejor se adapte al contexto particular del problema que se tenga. La solución que un patrón describe, no necesariamente es detallada al nivel de implementación, sino que provee una descripción abstracta, una enumeración de elementos y sus relaciones, para solucionar el problema planteado.

- Las consecuencias: son los resultados de aplicar el patrón, los trade-off, compromisos, que se tienen que aceptar al adoptar el mismo.

Las Propiedades de los patrones de diseño son: (Buschmann et al., 1996) - Tratan los problemas del diseño que se presentan en situaciones específicas y se repite de manera

recurrente, mostrando una solución. - Documentan la experiencia de soluciones probadas a problemas existentes. - Identifican y especifican las abstracciones sobre el nivel, separándolos en objetos, casos o

componentes. - Proveen un vocabulario común y la comprensión de los principios del diseño. - Son los medios para documentar arquitecturas de software. - Apoya la creación de software con propiedades definidas. - Ayudan en la construcción de arquitecturas complejas y heterogéneas. - Ayudan en el manejo de software complejo. Gamma y otros (Gamma et al., 1995), consideran que para describir patrones se debe especificar: - Nombre del patrón y clasificación. Cada patrón tiene un nombre, y una categoría a la que pertenece. El

GoF los clasifica en creacionales, estructurales y de conducta. Más adelante se profundizará sobre esta clasificación.

- Intención. Depende del contexto. Cada patrón tiene una intención, una razón, una justificación. - Otros nombres. Los patrones habían surgido en distintos proyectos y tecnologías. Los primeros autores

les dieron un nombre que no siempre coincidía. Estos otros nombres pueden ser enumerados en la descripción del patrón.

- Motivación. Más que la intención, esta parte describe un escenario, un problema en particular que aparece, y que ayuda a entender la descripción algo más abstracta del patrón genérico.

- Aplicación. En qué situaciones puede ser aplicado un patrón. Pueden darse ejemplos de malos diseños, que pueden beneficiarse de la aplicación de este patrón en particular.

- Estructura. La parte más conocida, luego del nombre. Se adopta un diagrama casi siempre basado en UML.

- Participantes. La lista de las clases y objetos que participan del patrón de diseño, y las responsabilidades que tienen.

- Colaboraciones. Descripción de cómo los participantes colaboran para llevar a cabo sus responsabilidades en el patrón

- Consecuencias. Explica cómo el patrón cumple con sus objetivos, y que compromisos se asumen. - Implementación. Esta es la parte que más puede variar, porque para cada patrón puede haber varias

posibles implementaciones, incluso, diferentes implementaciones según la tecnología adoptada. - Código de ejemplo. Es recomendable dar código de ejemplo de cada patrón, por ejemplo, en Smalltalk

o en C++. - Usos conocidos. Un patrón no es tal, si no ha sido ya empleado en algún caso real. Se debe incluir por

lo menos dos ejemplos conocidos de diferentes ámbitos. - Patrones relacionados. Puede que haya problemas parecidos, que tengan más de una solución. De ahí

que muchos patrones estén relacionados entre sí: como el caso del Proxy y del Adapter. Se trata de explicar cuáles son las similitudes y (no menos importante) las diferencias, entre patrones relacionados.

109

Gamma et al. (1995), clasifican los patrones de diseño en tres categorías: patrones creacionales, estructurales y de conducta: - Patrones Creacionales (Creational Patterns). Abstraen el proceso de instanciación. En general, tratan

de ocultar las clases y métodos concretos de creación, de tal forma que al variar su implementación, no se vea afectado el resto del sistema. Es común encontrar "competencia" entre estos patrones: hay más de un patrón a adoptar ante una situación: Abstract Factory, Builder, Factory Method, Prototype, Singleton.

- Estructurales (Structural Patterns). Se ocupan de cómo se agrupan las clases y los objetos para formar estructuras más grandes. Aquí se puede nombrar al patrón Composite, que permite agrupar varios objetos como si fueran uno solo, y tratar al objeto compuesto de una forma similar al simple: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.

- De Conducta (Behavioral Patterns). Centrados en la comunicación entre objetos y clases. Frecuentemente, describen las colaboraciones entre distintos elementos, para conseguir un objetivo: Chain of Responsability, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.

- Por otro lado, Buschmann et al. (1996), clasifican los patrones de diseño como: descomposición de estructura, organización de trabajo, control de acceso, gerencia y comunicación:

- Descomposición de la estructura (Structure Decomposition). Descomposición de los subsistemas y componentes complejos en piezas interrelacionadas: Whole-Part.

- Organización de trabajo (Organization of Work). Los componentes colaboran para solucionar problemas complejos: Master-Slave.

- Control de acceso (Access Control). Guarda y controla el acceso a los servicios y a los componentes: Proxy.

- Gerencia (Management). Maneja la totalidad de las colecciones homogéneas de objetos, servicios y componentes: Command Processor, View Handler.

- Comunicación (Communication). Organiza la comunicación entre componentes: Forward-Receive, Client-Dispatcher-Server, Publisher-Subscriber.

En la Tabla A1.3 que se muestra a continuación, se resumen algunos patrones (de arquitectura, diseño e idiom) propuestos por Buschmann et al. (1996) y su relación con los patrones de Gamma et al. (1995). En negrillas, se muestra la clasificación de Gamma et al. (1995).

Patrón arquitectural Patrón de diseño Idioms Del fango a la estructura

Layers Pipes and Filters Blackboard

Interpreter

Sistemas distribuidos

Broker Pipes-and-Filters Microkernel

Sistemas interactivos

MVC PAC

Sistemas adaptativos

Microkernel Reflection

Creación Abstract Factory Prototype Builder

Singleton Factory Method

Descomposición estructural

Whole-Part Composite

Organización de trabajo

Master-Slave Chain-of-Responsibility Command Mediator

Control de acceso Proxy Facade Iterator

Variación de servicio

Bridge Strategy State

Template Method

Extensión de servicio

Decorator Visitor

Gerencia CommandProcessor ViewHandler Memento

Adaptación Adapter Comunicación Publisher-Subscriber

Forward-Reciever Client-Dispatcher-Server Observer

Manejo de recursos Flyweight Counted Pointer

Tabla A1.3 Resumen de patrones

110

La Tabla A1.4, muestra algunos patrones de diseño acompañados de sus autores y su propósito. A manera de conclusión se tiene que existe una estrecha relación entre los estilos arquitectónicos y los patrones arquitecturales y de diseño.

N Patrón de diseño Autores Propósito 1

Abstract Factory

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Proporcionar interfaces para crear objetos de alguna familia, sin especificar una clase en particular.

2 Adapter Class Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Convertir interfaces de una clase, en otra, que es la esperada por algún cliente.

3 Bridge Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Desacoplar una abstracción de su implementación en concreto. Luego, podemos cambiar la implementación, o la abstracción, sin cambiar la otra.

4 Builder Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Separa la construcción de un objeto complejo, de su representación. De esa manera, el mismo proceso de construcción puede crear diferentes resultados.

5 Chain of Responsability Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Desacoplar el mensaje enviado de su receptor, permitiendo que haya varios objetos que tengan la oportunidad de manejar el requerimiento. Eso se consigue pasando el requerimiento por la cadena de objetos hasta llegar al encargado de atenderlo.

6 Client-Dispatcher-Server

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal

Un despachador actúa como capa intermedia entre los clientes y el servidor.

7 Command Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Encapsular el requerimiento a un objeto, permitiendo incluso el "undo" de la operación

8 Command-Processor Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal

Extiende el patrón command de Gamma, y añade un procesador del comando explícito

9 Composite Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Componer objetos en una estructura de árbol, donde los objetos compuestos se tratan de forma similar a los objetos simples.

10 Decorador Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Agregar responsabilidad a un objeto dinámicamente, dándonos una alternativa a la extensión de una clase, en lugar de usar subclases.

11 Facade Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Proveer una interface unificada a un conjunto de funciones de un subsistema. Es una interface de alto nivel, para facilitar el uso del subsistema.

12 Factory Method Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Definir interfaces para crear objetos, como en el Abstract Factory, pero se delega a las subclases implementar la creación en concreto.

13 Flyweight Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Compartir objetos eficientemente, sin repetirlos en el sistema.

14 Forward-Receiver Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal

Contiene toda la funcionalidad de comunicación especificada en el sistema, separada en pares de componentes que pueden comunicarse sin afectar la portabilidad.

15 Interpreter Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Construir una representación de la gramática de un lenguaje, junto con su intérprete.

16 Iterator Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Acceder a los elementos de un objeto colección o similar, sin exponer su estructura interna

111

17 Master-Slave Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal

El master divide una tarea entre los slave idénticos (pero independientes), la combinación de los resultados parciales de cada slave, resulta ser la solución

18 Mediator Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Permitir la interacción de varios objetos, sin generar acoples fuertes en esas relaciones.

19 Memento Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Permite capturar el estado de un objeto sin entrar en su estructura interna, para, por ejemplo, restaurarlo más adelante.

20 Observer Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Definir una relación uno a muchos, entre un objetos y otros que están interesados en sus cambios, sin realizar el acople entre los mismos.

21 Prototype Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Conseguir otras instancias del objeto, mediante una instancia prototípica.

22 Proxy Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Proveer un subrogado a otro objeto, para controlar el acceso al mismo.

23 Publisher-Subscriber Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal

Es similar al patrón Observer de Gamma.

24 Singleton Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Consigue dar un solo objeto de la clase, en cualquier momento de la aplicación

25 State Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Permite a un objeto cambiar su conducta cuando cambia su estado interno, simulando que cambia de clase.

26 Strategy Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Definir una familia de algoritmos, y los hace intercambiables.

27 Template-Method Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Definir la estructura de una operación, cuyas operaciones más básicas, quedan delegadas en subclases.

28 View-Handler Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal

Separar el manejo de opiniones de los códigos requeridos para presentar o para controlar vistas específicas. Es similar a los patrones Abstract Factor y Mediator de Gamma et al

29 Visitor Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Recorrer una estructura (un árbol, por ejemplo), aplicando una operación

30 Whole-Part Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal

Definir un componente que encapsule objetos pequeños. Evita que los clientes tengan acceso directo al contenedor de objetos, pero proporciona una interfaz para la agregación.

Tabla A1.4 Algunos patrones de diseño La Tabla A1.5 muestra que los patrones de diseño pueden aplicarse al nivel de marco de trabajo, dentro de las clases de diseño al nivel de arquitectura y también dentro del diseño detallado [Bra2003]. Arquitectura (Garlan y Shaw) Categoría Sub-categoría Patrones de diseño más aplicados Flujo de datos Secuencial por lote Puede aplicarse decorador Componentes independientes

Pipes and filter Procesos de comunicación paralela Sistema Cliente-Servidor Sistema de eventos

Observer Facade State Observer

112

Máquinas virtuales Intérpretes Sistemas basados en reglas

Interpreter

Arquitecturas de almacenamiento

Bases de datos Sistemas de hipertextos Pizarrones

Observer, iterator Decorator Blackboard

Arquitecturas por capas

Muchos patrones de diseño consisten en capas abstractas y no abstractas.

Tabla A1.5 Arquitecturas alternativas (Braude, 2003) A continuación un listado de los patrones de Diseño: 1. Abstract Factory 2. Adapter - Class 3. Adapter - Object 4. Blackboard 5. Bridge 6. Broker 7. Builder 8. Chain Of Responsibility 9. Client-Dispatcher-Server 10. Command 11. Command Processor 12. Composite 13. Decorator 14. Facade 15. Factory Method 16. Flyweight 17. Forwarder-Receiver 18. Interpreter 19. Iterator 20. Layers 21. Master-Slave 22. Mediator 23. Memento 24. Microkernel 25. Model-View-Controller 26. Observer 27. Pipes and Filtres

28. Presentation-Abstraction-Control 29. Prototype 30. Proxy 31. Publisher-Subscriber 32. Reflection 33. Singleton 34. State 35. Strategy 36. Template Method 37. View Handler 38. Visitor 39. Whole-Part 40. Administración de Caché 41. Caja de Objetos (Object Pool) 42. Delegación (Delegation) 43. Ejecución de un único Thread 44. El patrón Controlador 45. El patrón Creador 46. El patrón Experto 47. Enlace Dinámico (Dynamic Linkage) 48. Fotografía (Snapshot) 49. Inicialización de capas (Layered Initialization) 50. Inmutable (Immutable) 51. Interfaz (Interface) 52. Marker Interface 53. Pequeño Lenguaje (Little Language) 54. Proxy Virtual (Virtual Proxy) 55. Término en dos fases (Two-Phase Termination)

A1.4 Patrón de Interacción

Un patrón de diseño de interfaces, o de interacción, modela un aspecto referente a la interfaz de una aplicación. Estos patrones sirven para describir un problema, su contexto y la solución; para generalizar una solución; para facilitar la comunicación entre disciplinas; para registrar el conocimiento y la experiencia y facilitar las metodologías de diseño de interfaces. Los patrones de interacción deben ser legibles y entendibles por todos los integrantes del equipo de desarrollo de un proyecto, incluyendo a los expertos en el dominio de la aplicación y los usuarios del sistema. Para lograr alcanzar esas características, estos patrones deben estar expresados haciendo uso de una notación clara, sencilla y bien definida; adicionalmente, los patrones deben estar organizados de tal forma que se facilite su utilización. Entonces, la estructura de los patrones debe facilitar la comunicación. A fin de cumplir su objetivo, existe aceptación en que un patrón tenga, como mínimo, cinco componentes principales: (Acosta et al., 2001). - Nombre de patrón, el cual debe ser mnemotécnico con respecto al problema de diseño que resuelve.

Un nombre de patrón nuevo incrementa el vocabulario de diseño. Este vocabulario permite diseñar a

113

un alto nivel de abstracción y facilita la comunicación entre colegas y dentro de la documentación del diseño.

- Problema, describe una situación en la cual se debe aplicar el patrón; éste explica el problema en sí y su contexto. Algunas veces, el problema puede incluir condiciones que deben ser satisfechas antes de que tenga sentido aplicar el patrón.

- Solución, describe los elementos que conforman el diseño. Provee una descripción abstracta de un ordenamiento general de los elementos que resuelven un problema particular en un contexto dado.

- Contexto, condición(es) en la(s) cual(es) se puede usar el patrón. - Fuerzas, complementan la definición del problema, debido a que son aspectos del contexto de diseño

que deben ser optimizados; en general, estos aspectos son contradictorios y es necesario establecer un equilibrio entre estos.

Uno de los resultados del workshop ChiliPLoP’99 fue el establecimiento de una taxonomía, propuesta inicialmente por Borchers, que agrupa a los patrones con base en tres dimensiones: nivel de abstracción, funcionalidad y dimensión física. Dentro de cada dimensión, se clasifican los patrones de la siguiente manera: - Según el nivel de abstracción, se puede tener patrones de muy alto nivel que describen una tarea

completa que realiza el usuario; luego, en un segundo nivel de abstracción se tienen patrones más concretos que describen el estilo de cierta parte de la interacción, y, por último, patrones que describen objetos de la interfaz de usuarios.

- En lo que respecta a la funcionalidad de los patrones, estos se agrupan en las siguientes categorías: aquellos orientados a describir la percepción (auditiva, visual, etc.) de los usuarios; los patrones que expresan la manipulación de los datos de entrada o salida y aquellos dirigidos a mostrar la navegación a través de la aplicación.

- Por último, se tiene la dimensión física de la interfaz, esto es, en primer lugar se encuentran los patrones orientados a la distribución de los elementos en el espacio o plano físico, posteriormente, los patrones que representan secuencias o series discretas de eventos, de diálogos, etc., y aquellos patrones que muestran continuidad en el tiempo, tales como el diseño de buenas técnicas de animación en la interfaz de usuarios.

Mahemoff y Johnston (1998) proponen un enfoque de diseño de Interacción Humano Computador, basado en patrones orientados a la usabilidad. Estos autores definen cuatro clases de patrones IHC, a saber: Patrones del Sistema, Patrones de Tareas, Patrones de Elementos de la Interfaz, Patrones de Usuarios. Los patrones del sistema capturan aspectos concernientes al desarrollo del mismo, por ejemplo los atributos de usabilidad que se deben garantizar, el propósito del sistema, etc. Los patrones de tareas describen las funcionalidades de la aplicación y cómo se deben llevar a cabo. Los patrones de elementos de interfaz describen elementos tales como los conocidos “widgets” o composiciones de éstos. Los patrones de usuarios describen los perfiles de los usuarios potenciales de la aplicación.

A1.5 Patrón de Flujo de Trabajo

Los patrones de flujo de trabajo o “workflow”, se corresponden con un conjunto de actividades básicas que permiten el control de un proceso de negocio, y son escenarios de los patrones de análisis descritos en el Anexo 1.1 (por lo que no se mencionan en la taxonomía), estos patrones de “workflow” son: aprobación simple, aprobación simple con escalación automática, aprobación simple con renovación automática, flujo de trabajo secuencial, flujo de trabajo secuencial con escalación automática, flujo de trabajo paralelo, flujo de trabajo paralelo con revisión final, asignación manual y notificación. Todos estos patrones de flujo de trabajo, permiten separar la lógica de negocio y la de presentación, garantizando la meta configuración de las aplicaciones asociadas a los procesos de negocio, a continuación se presentan cada uno de estos patrones de flujo de trabajo.

Tabla A1.6 Patrón Asignación Nombre Asignación

114

Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema Debe ser ejecutada una tarea por un usuario o grupo de acuerdo a ciertas reglas de

asignación y manejando una lista de tareas (Work List). Solución a. Asignación de valores a los atributos de la tarea desde procesos

externos. b. Asignación de atributos relacionados a acuerdos de servicio mediante la

invocación de una Administrador de Acuerdos de Servicio (Administrador Acuerdos Servicios)

c. Asignación de atributos de sistema mediante la invocación de un Servicio Administrador de Sistema (Administrador sistema),

d. Invocación de un servicio administrador de tareas (Servicio Administración Tarea), el cual utilizara los atributos de la tarea, para determinar la agregación de dicha tarea a la lista de trabajo de un usuario o grupo de usuarios, además de realizar otras actividades como verificar la permisología, estado de transición, documentación, acuerdos de servicios, calcular tiempo, asignar auditoria, verificar modificaciones, encuestas y soluciones sobre la tarea.

e. Posteriormente, los resultados o eventos son manejados por un Servicio Administrador de Eventos de Tarea (ServicioAdministracionEventosTarea) a fin de verificar la expiración, la renovación y los errores asociados.

Contexto Cualquier proceso donde se requiera asignar una tarea a un usuario o grupo. Fuerzas Todos los workflow que incluyen interacción humano computador requieren administración

de las tareas a ser asignadas a los usuarios, además de manejar una lista de tareas Usabilidad Permite administrar la asignación de tareas de acuerdo a ciertos atributos asignados a las

mismas. Consecuencias Asignación de tareas a usuarios o grupos de usuarios tomando en cuenta las

características de la tarea para la asignación y manejando una lista de trabajos(work list) Ejemplo Un empleado, a través de un portal de empleados suministra una solicitud de vacaciones.

El portal inicia un proceso de negocios que incluye una tarea de usuario modelada usando un simple workflow, la tarea es asignada al supervisor del empleado. Cuando el supervisor aprueba o rechaza la solicitud de vacaciones, el empleado es notificado con la decisión del supervisor por e-mail.

Patrones Relacionados

f. Administrador de Acuerdos de Servicios g. Administrador de Sistema h. Administrador de Tarea i. Administrador de Eventos sobre la Tarea

Tabla A1.7 Patrón Asignación con Escalación Nombre Asignación con Escalación Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema Debe escalarse una tarea asignada de un usuario a otro, tomando en cuenta

acuerdos de servicios preestablecidos (Service Level Agreement) Solución Utilización del Patrón de Asignación y adicionalmente invocación de una operación

denominada “verificarEscalacion”, que determina de acuerdo a las condiciones del SLA, si la tarea asignada debe ser escalada, cuando debe ser escalada una tarea a otro usuario, quien es el usuario a ser notificado de la escalación y escala la tarea de ser necesario.

Contexto Cualquier proceso donde se requiera escalar una tarea en caso de no ser cumplidas las políticas de SLA.

Fuerzas Es necesario manejar escalación de tareas en caso de no ser cumplidos acuerdos de SLA como por ejemplo la expiración de la tarea ya que esto evita retrasos en el proceso y asignación de las tareas a usuarios o grupos que si puedan manejar dichos acuerdos

115

Usabilidad Todos los procesos donde sea necesario escalar tareas en base a un conjunto de acuerdos de SLA.

Consecuencias Asignación de tareas a usuarios o grupos de usuarios tomando en cuenta las características de la tarea para la asignación y manejando una lista de trabajos(work list), además de manejar información sobre acuerdos de servicios para realizar escalación de tareas a otros usuarios o grupos

Ejemplo El proceso de HelpDesk da a usuarios la capacidad de archivar tickets de petición del servicio. Si la persona que recibe el boleto no actúa dentro de un período especificado, el boleto se escala automáticamente a su encargado. El boleto se escala automáticamente tres veces si nadie ha actuado en él dentro de un tiempo predefinido, hasta que consigue al gerente de la compañía. Si el gerente tampoco actúa, el ticket expira.

Patrones Relacionados

- Asignación - AdministradorEventosTarea

Tabla A1.8 Patrón Asignación con Renovación

Nombre Asignación con Renovación Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema Se debe renovar la asignación de una tarea a un usuario una cantidad definida de

veces, cada ves que esta expire. Este tiempo de expiración viene especificado en los acuerdos de SLA(Service Level Agreement)

Solución Utilización del patrón de asignación y adicionalmente invocación de una operación denominada “verificarRenovacion”, que además de realizar las mismas funciones de la operación “verificarEscalacion” (determinar según los acuerdos de SLA si una tarea debe ser escalada, cuando, a quien y escalar la tarea de ser necesario) también esta en la capacidad de renovar la tarea – asignarla al mismo usuario o grupo – una cantidad definida de veces.

Contexto Cualquier proceso donde se requiera renovar la asignación de tareas a un usuario o grupo conforme a los acuerdos de SLA.

Fuerzas Puede darse el caso en que se flexibilicen los acuerdos de servicios, para dar oportunidad a un usuario o grupo de usuarios de completar una tarea

Usabilidad Todos los procesos donde sea necesario escalar tareas en base a un conjunto de acuerdos de SLA.

Consecuencias Asignación de tareas a usuarios o grupos de usuarios permitiendo la renovación de la misma al mismo usuario, un número definido de veces antes de ser escalada.

Ejemplo El proceso de HelpDesk da a usuarios la capacidad de archivar tickets de petición del servicio. Si la persona que recibe el boleto no actúa dentro de un período especificado, el boleto se escala automáticamente a su encargado. El boleto se escala automáticamente tres veces si nadie ha actuado en él dentro de un tiempo predefinido, hasta que consigue a la última persona con capacidad de atender la petición de servicio, si esta persona tampoco actúa, el ticket expira. En este caso puede ser renovada la asignación a la misma persona cierta cantidad de veces, con el fin de no truncar la posibilidad de prestar el servicio.

Patrones Relacionados

- Asignación - Administrador de Eventos de Tarea

Tabla A1.9 Patrón Asignación Automática Secuencial

Nombre Asignación Automática Secuencial Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema Una tarea debe ser realizada o procesada por un usuario o grupo de usuarios en forma

116

secuencial. Solución Creación de una secuencia de usuarios que procesaran la tarea mediante un servicio

Administrador de Secuencia, La tarea será asignada a cada usuario en la secuencia utilizando el patrón de asignación hasta llegar al último usuario.

Contexto Un proceso que contiene una lista de usuarios asociados a una tarea a realizar. La tarea tiene un conjunto de acuerdos de SLA asociados.

Fuerzas Es frecuente el caso en que existe un orden definido en el cual más de un usuario o grupo de usuario requieren procesar una misma tarea.

Usabilidad Cualquier proceso donde se haga necesario el procesamiento de una tarea por varios o grupo de usuarios en forma secuencial.

Consecuencias El procesamiento de una tarea por múltiples usuarios en forma secuencial Ejemplo En un sistema aprobador de órdenes de compras, un usuario perteneciente a un grupo

supervisor evalúa inicialmente la orden de compra. Después que el usuario inicial aprueba la orden, el gerente del departamento debe aprobarla también.

Patrones Relacionados

- Asignación - Administrador de Secuencia

Tabla A1.10 Patrón Asignación Automática Secuencial con Escalación

Nombre Asignación Automática Secuencial con Escalación Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema Una tarea debe ser realizada o procesada por un usuario o grupo de usuarios en forma

secuencial, si alguno de los usuarios no cumple los acuerdos de SLA, la tarea es escalada a otro usuario.

Solución Creación de una secuencia de usuarios que procesaran la tarea mediante un servicio AdministradorDeSecuencia, La tarea será asignada a cada usuario en la secuencia utilizando el patrón de asignaciónConEscalacion hasta llegar al último usuario. En este caso, la tarea puede ser escalada en caso de no ser cumplidos los acuerdos de SLA por alguno de los usuarios en la lista.

Contexto Un proceso que contiene una lista de usuarios asociados a una tarea a realizar y los cuales deben cumplir con un conjunto de acuerdos de SLA.

Fuerzas Es frecuente el caso en que existe un orden definido en el cual mas de un usuario o grupo de usuario requieren procesar una misma tarea, a esto se la agrega la necesidad de escalar la dicha tarea si uno mas de dichos usuarios no cumplen con los acuerdos de SLA.

Usabilidad Cualquier proceso donde se haga necesario el procesamiento de una tatarea por varios o grupo de usuarios en forma secuencial y los cuales deban cumplir con acuerdos de SLA.

Consecuencias El procesamiento de una tarea por múltiples usuarios en forma secuencial y escalación de dichas tareas en caso de no haber sido ejecutadas según los acuerdos de SLA.

Ejemplo Un empleado solicita una nueva computadora portátil urgentemente. El workflow secuencial primero encamina la tarea a su jefe para la aprobación y después a una persona en el departamento encargado de adquirir la computadora portátil. Si el SLA indica que la tarea debe escalarse después de dos días, entonces la petición primero va al jefe para la aprobación y si no se aprueba en dos días, la tarea se puede encaminar automáticamente a la persona siguiente en la jerarquía de gerencia. Un escalamiento similar se puede también hacer para el departamento encargado de adquirir la computadora portátil. Esto permite al workflow terminar sin largos retrasos en el proceso de aprobación.

Patrones Relacionados

- Asignación con Escalación - Administrador de Secuencia

Tabla A1.11 Patrón Asignación Manual Nombre Asignación Manual

117

Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema Se presenta cuando a un usuario o un grupo de usuarios no han aprobado la

tarea, y no se ha remitido la tarea al usuario original que creo la tarea, para su aprobación final.

Solución Se puede solucionar, cambiando los atributos iníciales y validando con el administrador de acuerdos de servicios, para determinar cuales son los grupos de usuarios que van a recibir la tarea para su revisión y validación, una vez creado el grupo al cual se le va a enrutar la tarea se invoca al administrador de Tarea, que en este caso va hacer el encargado de enrutar la tarea cuando cada usuario haya revisado la tarea y la envié a su revisor original.

Contexto Cualquier proceso donde se requiera tener más de una revisión no automática, para su aprobación final.

Fuerzas Cuando se requiere que exista una aprobación sin un criterio específico de asignación automática este patrón permite la asignación manual.

Usabilidad Permite enrutar tareas a un usuario o grupo de usuarios de forma manual, para su posterior aprobación

Consecuencias La tarea es asignada a una persona o grupo que fue seleccionada por un criterio manual

Ejemplo Un representante de una Compañía “HR”, escribe un nuevo documento, y lo tiene repasado por su encargo. El encargado puede decidir que otra persona debe también repasarlo antes de que se acepte. Esta persona puede alternadamente remitir la tarea a otras antes de aprobarla. Por lo tanto la tarea se puede enrutar a múltiples usuarios, antes de volverse al revisor original, que entonces la aprueba basado en comentarios de otros.

Patrones Relacionados

Proceso Externo, Asignación

Tabla A1.12 Patrón Asignación Paralela Nombre Asignación Paralela Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema El problema que resuelve este patrón, es que se lleva un control de la tarea desde su

inicio hasta su estado de completitud, ya que el dueño de la tarea le puede hacer un seguimiento al proceso permitiendo la aprobación en paralelo de varios usuarios a través de sub tareas

Solución Cuando se completan las subtareas el administrador de eventos tarea, prepara un mensaje de completitud de subtarea, que se le es enviado al administrador de tarea para indicarle al dueño de proceso que ya la tarea padre puede ser retirada, esto ocurre cuando se ha logrado el 75% de completitud de subtarea.

Contexto Se utiliza Asignación Paralela cuando una tarea se debe aprobar por múltiples usuarios o simultáneamente por grupos de usuarios, cuando se crea una tarea cada usuario tiene una copia de la tarea, los usuarios podrán agregar información, agregar comentarios independiente de otros usuarios, como premisa los usuarios que repasan las tareas en paralelo no pueden ver las tareas de los otros usuarios (incluyendo comentarios, resultados, etc.). El dueño de la tarea puede ver todas las subtareas en ejecución. Cuando el creador de la tarea retira a la tarea “Padre”, todas las subtareas se retiran.

Fuerzas El administrador de Tareas, se puede saturar a la hora de atender cada petición de subtarea, ya que una tarea se puede dividir en muchas partes. En ese momento el administrador de eventos de tarea prepara un mensaje de completitud de subtarea, que es enviado al administrador de tarea, para si retirar la tarea padre y finalizar el proceso.

Usabilidad La usabilidad de este patrón viene dada, con la rapidez con que se desea agilizar una

118

tarea principal, para que sea divida en subtareas, para que varios usuarios puedan resolver un problema de manera rápida.

Consecuencias Ejemplo Un ejemplo concreto es el de emplear a un nuevo aspirante para optar a un cargo

dentro de una organización. Cada entrevistador da su voto para emplear o no al candidato, si en el resultado de la votación el candidato obtiene un promedio de 75%, obviamente será aceptado, caso contrario será rechazado, se hace regencia en este ejemplo porque cada entrevistador puede votar independientemente de los otros entrevistadores.

Patrones Relacionados

Proceso Externo, Administrador Sub Tarea, Administrador Tarea, Asignación

Tabla A1.13 Patrón Asignación Paralela con Escalación Nombre Asignación Paralela con Escalación Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema El problema que resuelve este patrón, es que se lleva un control de la tarea desde su

inicio hasta su estado de completitud, ya que el dueño de la tarea le puede hacer un seguimiento al proceso. Permite también realizar escalaciones cuando no se ha completado una tarea o subtarea

Solución Cuando se completan las subtareas el administrador de eventos tarea, prepara un mensaje de completitud de subtarea, que se le es enviado al administrador de tarea para indicarle al dueño de proceso que ya la tarea padre puede ser retirada, esto ocurre cuando se ha logrado el 75% de completitud de subtarea.

Contexto Se utiliza Asignación Paralela con Escalación cuando una tarea se debe aprobar por múltiples usuarios o simultáneamente por grupos de usuarios, Si la Tarea no se ha completado se realiza la escalación automática. Cuando se crea una tarea cada usuario tiene una copia de la tarea, los usuarios podrán agregar información, agregar comentarios independientes de otros usuarios, como premisa los usuarios que repasan las tareas en paralelo no pueden ver las tareas de los otros usuarios (incluyendo comentarios, resultados, etc.). El dueño de la tarea puede ver todas las subtareas en ejecución. Cuando el creador de la tarea retira a la tarea “Padre”, todas las subtareas se retiran.

Fuerzas El administrador de Tareas, se puede saturar a la hora de atender cada petición de subtarea, ya que una tarea se puede dividir en muchas partes. En ese momento el administrador de eventos de tarea prepara un mensaje de completitud de subtarea, que es enviado al administrador de tarea, para si retirar la tarea padre y finalizar el proceso.

Usabilidad La usabilidad de este patrón viene dada, con la rapidez con que se desea agilizar una tarea principal, para que sea divida en subtareas, para que varios usuarios puedan resolver un problema de manera rápida. Permite además llevar un control de notificaciones a los supervisores por medio de escalaciones, cuando la tarea ha expirado o no ha sido completada.

Consecuencias Ejemplo Una Persona Dueña de un proceso, crea una tarea, y la imparte a los usuarios o

grupos de usuarios para que revisen y le agreguen información adicional a las subtareas de manera que sean procesadas en forma independiente de cada usuario, que esta procesando la subtarea, cada usuario aprobara la subtarea en porcentajes de completación. Si las subtareas no son completadas en un lapso de tiempo la subtarea escala un nivel hacia los supervisores de los usuarios que son responsables de procesar las subtareas.

Patrones Relacionados

Asignación Paralela, Asignación con Escalación, Administrador Sub Tareas, Administrador Tarea, Proceso Externo

119

Tabla A1.14 Patrón Asignación Paralela con Revisión Final Nombre Asignación Paralela con Revisión Final Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema El problema que resuelve este patrón, es que se lleva un control de la tarea desde su

inicio hasta su estado de completitud, ya que el dueño de la tarea le puede hacer un seguimiento al proceso y a su vez es apoyado por un usuario que revisa la tarea para su aprobación final, es decir la tarea pasa por una doble validación.

Solución Cuando se completan las subtareas el administrador de eventos de tarea, prepara un mensaje de completitud de subtarea, que se le es enviado al administrador de tarea para indicarle al revisor final que ya la tarea padre puede ser retirada, esto ocurre cuando se ha logrado el 75% de completitud de subtarea.

Contexto Asignación Paralela con un Revisión Final es una extensión del patrón Asignación Paralela, en el cual después de la revisión de la tarea en paralelo por parte de los usuarios, la tarea se asigna a un revisor final. El revisor final puede ser un usuario o un grupo. Cuando hay más de un revisor final o si la tarea se asigna a un grupo, uno de los usuarios tiene que adquirir la tarea antes de repasarla, el revisor final puede ver todas las subtareas.

Fuerzas El administrador de Tareas, se puede saturar a la hora de atender cada petición de subtarea, así como también si se selecciona a un grupo para que actué como revisor final, se puede perder tiempo en escoger al usuario que va a tomar la tarea para el cambio de estatus de las subtareas para que sea retirada por el dueño del proceso.

Usabilidad La usabilidad de este patrón viene dada, con la rapidez con que se desea agilizar la tarea principal, la cual se les envía a los múltiples usuarios en paralelo y en seguida se le envía a un revisor final para que el dueño del proceso pueda tomar una decisión.

Consecuencias Ejemplo En un proceso de revisión de documentos, el creador del documento inicia el proceso

especificando el documento y a los revisores del documento. Cada revisor puede repasar el documento simultáneamente e independientemente de los otros revisores, después de que todos los revisores hayan hecho el repaso del documento, el creador del documento consigue repasar los comentarios de los revisores.

Patrones Relacionados

Asignación Paralela, Asignación, Proceso Externo, Administrador Tarea, Administrador Sub Tarea.

Tabla A1.15 Patrón Asignación Paralela Revisión Final con Escalación Nombre Asignación Paralela Revisión Final con Escalación Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema El problema que resuelve este patrón, es que se lleva un control de la tarea desde su

inicio hasta su estado de completitud, ya que el dueño de la tarea le puede hacer un seguimiento al proceso y a su vez es apoyado por un usuario que revisa la tarea para su aprobación final, es decir la tarea pasa por una doble validación. Si la tarea no es completada se escala a otra instancia, para la toma de decisiones.

Solución Cuando se completan las subtareas el administrador de eventos de tarea, prepara un mensaje de completitud de subtarea, que se le es enviado al administrador de tarea para indicarle al revisor final que ya la tarea padre puede ser retirada, esto ocurre cuando se ha logrado el 75% de completitud de subtarea.

Contexto Asignación Paralela con un Revisión Final es una extensión del patrón Asignación Paralela, en el cual después de la revisión de la tarea en paralelo por parte de los usuarios, la tarea se asigna a un revisor final. El revisor final puede ser un usuario o un grupo. Cuando hay más de un revisor final o si la tarea se asigna a un grupo, uno

120

de los usuarios tiene que adquirir la tarea antes de repasarla, el revisor final puede ver todas las subtareas.

Fuerzas El administrador de Tareas, se puede saturar a la hora de atender cada petición de subtarea, así como también si se selecciona a un grupo para que actué como revisor final, se puede perder tiempo en escoger al usuario que va a tomar la tarea para el cambio de estatus de las subtareas para que sea retirada por el dueño del proceso.

Usabilidad La usabilidad de este patrón viene dada, con la rapidez con que se desea agilizar la tarea principal, la cual se les envía a los múltiples usuarios en paralelo y en seguida se le envía a un revisor final para que el dueño del proceso pueda tomar una decisión.

Consecuencias Ejemplo En un proceso de revisión de documentos, el creador del documento inicia el proceso

especificando el documento y a los revisores del documento. Cada revisor puede repasar el documento simultáneamente e independientemente de los otros revisores, después de que todos los revisores hayan hecho el repaso del documento, el creador del documento consigue repasar los comentarios de los revisores, en caso contrario si el creador de la tarea no logra cerrar el proceso, se realiza una notificación de que una tarea no ha sido completada.

Patrones Relacionados

Asignación Paralela, Asignación Paralela con Escalación, Asignación con Escalación Asignación Paralela con Revisión Final, Administrador Sub Tarea, Administrador Tarea, Proceso Externo.

Tabla A1.16 Patrón Administrador de Sub Tarea Nombre Administrador de Sub Tarea Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema Se requiere que varias personas a través de subtareas como copia de la tarea

principal realicen una aprobación en paralelo Solución Creación de subtareas copia de la tarea de la tarea original permitiendo a través del

administrador de subtareas la aprobación en paralelo Contexto Recibe las solicitudes de Asignación Paralela, Asignación Paralela con Escalación,

Asignación Paralela con Revisión Final, Asignación Paralela Revisión Final con Escalación, a través del servicio de administración de sub tarea, procesa las sub tareas y envía respuesta.

Fuerzas Ayuda al administrador de tarea en el procesamiento de las subtareas de manera paralela cuando se ha colocado una tarea principal y necesita ser gestionada por múltiples usuarios.

Usabilidad Se utiliza como una funcionalidad que apoya el procesamiento y gestión de las subtareas.

Consecuencias Cuando se crea la tarea principal la Asignación Paralela en cualquiera de sus modalidades, realiza una invocación al Administrador de Subtarea, el cual es el encargado de recibir procesar (crear, modificar, consultar, eliminar) las subtareas. Permitiendo llevar un control de la gestión de la subtarea, permite monitorear el porcentaje de completitud de subtarea, realiza validaciones de grupos y usuarios a los cuales se les distribuye las subtareas para su revisión, trabaja en paralelo con el administrador de tareas.

Ejemplo El Administrador es una funcionalidad que permite procesar las tareas en subtareas, en donde todo comienza cuando una tarea se esta procesando en paralelo, esta tarea se ejecuta de manera independiente de cada usuario, cada uno de los usuarios desconoce la información que le agregan al momento de la completación de la tarea, el administrador de tarea recibe los atributos necesarios para poder distribuir la tarea al usuario o al grupo de usuarios para su gestión.

Patrones Relacionados

Asignación Paralela, Asignación, Administrador Tarea

121

Tabla A1.17 Patrón Asignación sin Notificación Nombre Asignación sin Notificación Clasificación Workflow Autor MSc. Pedro Bonillo Confiabilidad 100 % Problema Cuando se crea una tarea, no se espera una respuesta del usuario, ya que no

interviene un administrador de acuerdos de servicios Solución Para tener una respuesta satisfactoria, se utiliza el administrador de acuerdos de

servicio, el cual permite notificar al supervisor, cuando un usuario ha recibido una tarea, cuando fue aprobada y ejecutada por el usuario final.

Contexto El FYI es una Tarea que no se bloquea y se enumera como tareas asignadas a un usuario, esta tarea se aloja en el worklist para su aprobación, El proceso que crea la tarea no espera una respuesta del usuario.

Fuerzas Si el administrador de acuerdo de servicio no puede determinar la ubicación del usuario o grupos de usuario, no se podrá realizar la notificación de que la tarea ha sido entregada, ni aprobada, esto generaría un error, el cual es lanzado por el administrador de tareas.

Usabilidad Viene dada, para llevar un control del flujo de la tarea, hasta el momento de su aprobación por el usuario.

Consecuencias Ejemplo Un ejemplo práctico es cuando se utiliza un proceso de sistema de órdenes de

compra. Cuando el sistema procesa aprobaciones sobre cierta cantidad como por ejemplo: $100, un supervisor tiene que ser notificado, pero sin parar el proceso, esta información es vital para el supervisor ya que le permite monitorear el sistema.

Patrones Relacionados

Asignación Simple

122

Anexo 2 Formato de Solicitud de Requerimiento En este anexo se presenta el formato a través del cual se solicita un requerimiento de creación o mejora de un proceso de negocio.

Número de Solicitud

Fecha: Nombre Solicitante: Teléfonos Solicitante: E-Mail del Solicitante: Gerencia: Unidad: Objetivos: (Indique cada uno de los objetivos que deben ser cubiertos) Descripción del Problema: (Situación Actual, Diagramas de Procesos, etc.)

Alcance: (Indique cuál será el alcance del desarrollo, qué aspectos deben contemplarse y cuáles no)

Beneficios: (Indique los beneficios que traerá el desarrollo e implementación del proyecto en base a procesos, uso de recursos, etc.)

123

Elementos de Entrada: (Indique cuáles son los datos o elementos de entrada que deberá recibir el sistema. Ej. Datos, archivos logs, etc.) Elementos de Salida: (Indique cuáles son los datos o elementos que debe mostrar el sistema como resultado de su procesamiento. Ej. Automatización de configuración, reportes, etc.)

Áreas Involucradas (Indique las áreas y/o personas que estarán relacionadas con el desarrollo solicitado) Área Alias Área Supervisor Persona Contacto Teléfono Persona Contacto. Usuarios: (Indique quiénes serán los usuarios finales, nombres, teléfonos, e-mail, ubicación administrativa y ubicación física. En caso de ser un grupo colocar los datos del grupo del supervisor) Nombre/ Grupo

Teléfonos E-mail (personal y del alias de la unidad a la que pertenece)

Ubicación Administrativa

Ubicación Física

Anexos. (Anexe a este formato toda aquella información que considere sea necesaria, así como información que pueda ayudar al desarrollo de este proyecto) Solo Para ser Llenado por la Unidad de Recepción de la Solicitud: Responsable: Factibilidad: Fecha Reunión Inicial:

124

Anexo 3 Cartelera de Actividades Propuestas A continuación se presentan las actividades que conforman la metodología y una duración en días promedio para un proceso medianamente complejo (entre 20 y 60 pasos):

Tiempo para la creación de un proceso Nombre de Tarea Duración (días) Process Mangement (Gerencia de Procesos sustentada en Patrones) 186 1. Crear Procesos 130 1.1 Analizar 28 1.1.1 Identificar Requerimientos 8 1.1.1.1 Describir Requerimiento 5 1.1.1.2 Definir Prioridad 1 1.1.1.3 Evaluar Cartelera de Actividades 2 1.1.2 Levantar Información 20 1.1.2.1 Mapear al Marco Referencial del Proceso 5 1.1.2.2 Levantar Situación Actual 15 1.2 Diseñar 24 1.2.1 Estandarizar Proceso 2 1.2.2 Evaluar Riesgos 2 1.2.3 Realizar Modelo Propuesto 15 1.2.4 Efectuar el Setup del Laboratorio 5 1.3 Modelar 8 1.3.1 Diagramar 5 1.3.2 Simular Prueba Funcional 1 1.3.3 Integrar Arquitectura 1 1.3.4 Simular Prueba Integral 1 1.4 Configurar 50 1.4.1 Completar UML 5 1.4.2 Construir Lógica de Negocios 10 1.4.3 Construir Interfaz 10 1.4.4 Construir Reportes 10 1.4.5 Configurar el BPEL 10 1.4.6 Realizar Pruebas Unitarias 5 2. Administrar Procesos 56 2.1 Mantener Configuraciones 16 2.1.1 Mantenimiento de Aplicaciones 6 2.1.1.1 Analizar y validar el tipo de requerimiento 2 2.1.1.2 Diseñar 3 2.1.1.3 Aplicar Pruebas 1 2.1.2 Mantener Variables del Proceso 5 2.1.3 Mantener Plataforma 5 2.2 Monitorear 40 2.2.1 Monitorear Funciones 20 2.2.2 Monitorear Plataforma 20

125

Anexo 4 Escenario Proceso de Gestión de Versiones ITIL en base al Patrón de Análisis de Producción

A través de este anexo se expresa el Proceso de Gestión de Versiones de ITIL como un escenario del Patrón de Análisis de Producción. Tabla A4.1: Escenario Gestión de Versiones, del Patrón de Análisis Producción

TITULO Gestión de Versiones OBJETIVO La Gestión de Versiones es la encargada de la implementación y control de calidad de todo el

software y hardware instalado en el entorno de producción. La Gestión de Versiones debe colaborar estrechamente con la Gestión de Cambios y de Configuraciones para asegurar que toda la información relativa a las nuevas versiones se integra adecuadamente en la CMDB de forma que ésta se halle correctamente actualizada y ofrezca una imagen real de la configuración de la infraestructura TI. La Gestión de Versiones también debe mantener actualizada la Biblioteca de Software Definitivo (DSL), donde se guardan copias de todo el software en producción, y el Depósito de Hardware Definitivo (DHS), donde se almacenan piezas de repuesto y documentación para la rápida reparación de problemas de hardware en el entorno de producción. Las interacciones y funcionalidades de la Gestión de Versiones se resumen a través de la siguiente figura:

CONTEXTO Gerencia de TI ACTORES Usuario, Consultor Service Desk, Supervisor Service Desk, Soporte de Campo, Supervisor

Soporte de Campo, Gestor de Cambio, Comité de Cambio. RECURSOS CMDB, Infraestructura de TI: Hardware y Software EPISODIOS 1.

126

2.

3.

4.

5.

6.

7.

8.

EXCEPCIONES Conflictos en el uso de la CMDB, DSL y DHL, Conflicto en el uso de los RFC Conflictos entre los horarios de RollOut, Desarrollo y Producción, Conflictos entre los horarios del CAB, Conflictos con el uso de la Infraestructura de TI.

127

Anexo 5 Artículos Arbitrados Publicados En este anexo se presentan las dos publicaciones en revistas internacionales, todas relacionadas con su tema de tesis, a saber: [1] Bonillo P. Evaluation System Model for Remote Control Software. Rev. Téc. Ing. Univ. Zulia, Aug. 2004, Vol. 27, No.2, p.123-134. ISSN 0254-0770. (Aceptado el 15 de Marzo de 2004). [2] Bonillo P., Zambrano N., Acosta E. Methodological Proposal for Business Process Management sustained in the use of Patterns.Journal of Object Technology, Vol. 7, No. 6, 2008, ISSN 1660-1769. (Aceptado el 14 de Noviembre de 2007) La publicación [1] propone un modelo sistémico de evaluación de herramientas de software, fundamentado en el estudio de la Tecnología de la Información y la Comunicación (TIC) y la representación de la Gerencia de las TIC como un sistema, con su respectivo sub-sistema de control. La publicación [2] propone una metodología para la gerencia de los procesos de negocio sustentada en el uso de patrones, estudia los procesos de desarrollo de software UP, XP y FDD, la construcción de software basada en componentes, relacionando los conceptos de patrones, componentes, aplicaciones, procesos, metodología y calidad, estableciendo una taxonomía de patrones de software y proponiendo la representación de estos conceptos a través de un ADL, que incluye la utilización de ABAS para la medición de la calidad y la formulación de un meta-patrón. La revista Técnica de Ingeniería de la Universidad del Zulia esta indexada en el Ulrich's International Periodicals Directory e Engineering Information Inc. La revista Journal of Information Systems and Technology Management esta indexada en Latindex. La revista Journal of Object Technology es publicada por el Chair of Software Engineering de ETH Swiss Federal Institute of Technology.

128

129

MODELO SISTÉMICO DE EVALUACIÓN DE SOFTWARE DE CONTROL REMOTO

Pedro N. Bonillo Centro ISYS, Facultad de Ciencias, UCV, Apdo. 48097

Apdo. 48097, Los Chaguaramos 1041-A, Caracas, Venezuela pbonillo@kuaimare.ciens.ucv.ve

RESUMEN

El objetivo de este artículo es presentar y describir un Modelo Sistémico para la Evaluación de Herramientas de Software. Al hablar de evaluación de software, lo más sencillo y fácilmente manejable que viene a la cabeza es una lista de cotejo en la que se verifica la existencia o ausencia de determinadas características o procesos involucrados en su uso. Es también fácilmente justificable que no se puede hablar de una evaluación aislada del contexto y los procesos por los que transita el software antes de llegar a las manos del usuario, o bien, divorciada de los objetivos que tiene quien conduce la evaluación. En este proceso de evaluación, se evidencian la existencia de entidades, atributos, y relaciones que afectan en gran medida a la organización, y que sugieren la utilización del enfoque sistémico, a través del cual la evaluación pueda ser modelada como un sistema abierto. Esta investigación busca establecer las relaciones y condiciones necesarias entre el pensamiento sistémico y la perspectiva de evaluación, dentro de un modelo diferenciador que permita obtener una buena estimación y un conjunto de criterios para evaluar exitosamente el uso del software en el marco de los intereses del negocio, tomando como caso de estudio la herramienta de software de control remoto en la organización de soporte interno de la empresa venezolana CANTV.

PALABRAS CLAVES

Modelo Sistémico de Evaluación, Gerencia TI.

1. INTRODUCCIÓN

La tecnología de la información (TI) está continuamente en rápida evolución, al mismo tiempo que lo está el ambiente de los negocios, lo cual coloca presión sobre las Organizaciones que están seguras de que pueden soportar los cambios fundamentales que en ellas ocurren. La tecnología de la información soporta las Organizaciones sobre el tiempo y el espacio, sin embargo las Organizaciones “no tienen aún la cantidad de soluciones suficientes y coherentes para desarrollar la dimensión de la estructura organizacional, la estrategia, los recursos humanos, la tecnología y los procesos del negocio”. Los cambios producidos en las Ciencias de la Computación han sido para encontrar una manera de atacar este problema mediante acciones continuas y rápidas a través del desarrollo de nuevas interrelaciones entre la tecnología de la información y la de la comunicación, alineándolas tanto con las necesidades sociales del grupo de usuarios cooperativos, como con la administración de los requerimientos de las Organizaciones formales. Paul Strassmann, conocido consultor norteamericano que ha estudiado con profundidad el impacto de las tecnologías de la información en las organizaciones, señala que no hay una relación directa entre la inversión de las empresas en TI y el retorno que consiguen de esa inversión [1].

En general, los criterios que se utilizan para evaluar software en las organizaciones, son más bien cualitativos, sin presentar una estandarización que permita a los especialistas valorar aspectos y evidenciar criterios mínimos de confiabilidad [2]. Cabe señalar que, aunque este es un problema ampliamente reconocido, existen escasas instancias de evaluación de software que permitan determinar su influencia positiva sobre la Organización. [3].

En muchas áreas de aplicaciones de software, a menudo, es más económico adquirirlo que realizar su desarrollo. Los Gerentes de sistemas se enfrentan a una decisión, de hacer-o-comprar, que se puede complicar con varias opciones de adquisición: (1) Se pueden adquirir programas (o una licencia de uso); (2) Se pueden

130

comprar programas y modificarlos luego para que se ajuste a las necesidades específicas y (3) Se puede encargar a una tercera parte la construcción de un programa que se ajuste a las especificaciones del comprador.

En los países subdesarrollados, se requiere de esfuerzos tecnológicos orientados a obtener un equilibrio adecuado entre la adquisición de la tecnología del exterior, el desarrollo y utilización de la capacidad tecnológica de la propia empresa y la selección, adaptación y generación de la tecnología que demanda para producir; ya que, en estos países, las empresas no poseen capacidad ni tradición suficientes en el desarrollo de tecnologías, siendo la principal opción el recurrir a la transferencia de tecnología, provenientes éstas de países desarrollados. [4].

Asimismo, la Gerencia de Tecnología de la Información se enfrenta al reto de prestar soporte a un número mayor de usuarios, con computadoras personales cada vez más complejas y con una movilidad en aumento, sin acrecentar los costos o incluso reduciéndolos. Esto representa un reto enorme [5]. Como apoyo a la Gerencia de Tecnología de la Información, en este enorme reto, las Organizaciones normalmente cuentan con una Mesa de Ayuda o Helpdesk. Esta Mesa de Ayuda constituye la primera línea de defensa en la mayoría de las organizaciones de soporte y tiene a su cargo la detección y resolución de problemas a través del teléfono con el fin de reducir la necesidad de que un técnico se desplace hasta el usuario o que el usuario tenga que llevar su computadora a un centro de soporte. En estas dos alternativas, la productividad se ve afectada y los costos del soporte aumentan drásticamente. Según una encuesta realizada por la compañía Forrester Research, el 60 por ciento de los encuestados reportaron que sus técnicos tuvieron que visitar los sistemas de los usuarios para resolver problemas (el 43 por ciento varias veces al día y el 17 por ciento varias veces a la semana) [5].

Dentro de las nuevas tecnologías que apoyan al personal del centro de soporte a sopesar este tipo de inconveniente tenemos las herramientas de atención remota de fallas (Remote Control), las cuales permiten a los técnicos tomar el control de la Computadora Personal (PC) del usuario a través de la red y trabajar con ella como si fuera una computadora local. De esta forma, los problemas se resuelven rápida y sencillamente, sin necesidad de que el técnico abandone el centro de soporte, disminuyendo el tiempo de atención, y enseñando al cliente mediante el enfoque de aprender haciendo [6]. El Grupo Gartner estima que, en un periodo de 3 años, las herramientas de control remoto pueden reducir los costos anuales de los centros de soporte entre un 6% y un 13%. Se estima que los costos anuales de los centros de soporte se encuentran en un rango de los 158 a los 1.447 dólares por PC. Esto significa un ahorro anual de 21 a 77 dólares por PC, o de 153.800 a 576.900 dólares en un entorno con 2.500 computadoras personales [5].Sin embargo, estas herramientas de “ayuda” normalmente son implementadas en la Organización sin una medición previa de su impacto sobre la operación. Las Organizaciones en general fallan en los procesos de evaluación de software, por no contar con mecanismos para medir el desempeño de los mismos. Es así como se ha pensado estudiar modelos que permitan subsanar esta debilidad. Un elemento crítico para el éxito y la supervivencia de las organizaciones, es la administración efectiva de la información y de la Tecnología de Información relacionada. Las empresas en Venezuela toman decisiones referentes a la tecnología que utilizan, pero sin tener mucha conciencia de ello; se utilizan enfoques que tienden a subestimar o ignorar aspectos importantes de la selección y uso de la tecnología que compran. Esto, obviamente repercute de manera sensible sobre el rendimiento económico de las empresas y sus posibilidades de desarrollo futuro. Comúnmente la tecnología de información en las organizaciones venezolanas se adquiere por moda, sin previo estudio, sin un análisis o evaluación y sólo después de que se compra el producto y se exige una métrica de la gestión del mismo, o una justificación de los costos asociados, es que se comienza a evaluar tanto el producto, como su efecto sobre los procesos del negocio. La carencia de un enfoque de evaluación de software en estas organizaciones ha generado problemas en la productividad y la calidad, así como en la evaluación, cada vez que una nueva tecnología y metodología es aplicada a la organización. La pregunta normal, de las organizaciones, al enfrentarse al término de evaluación es: ¿Por qué no tenemos mediciones adecuadas actualmente? Las respuestas: (1) Se requiere tiempo y esfuerzo; (2) La evaluación responde a la cultura existente en la organización: (2.1) históricamente no se ha medido la calidad de las funciones de servicios y las administrativas; (2.2) históricamente las mediciones se han usado para castigar, no para recompensar; (2.3) las expectativas y necesidades tendrán que ser definidas más claramente. Para mejorar debemos saber dónde nos encontramos, y para saber dónde nos encontramos debemos evaluar, medir y estimar [8].

La pretensión de ofrecer un Modelo Sistémico de Evaluación de Herramientas de Software de Control Remoto, como reza el título de este articulo, pasa entonces por la definición de los tres elementos esenciales: evaluación: (para qué evaluamos) qué se pretende hacer con los resultados de la evaluación y quién está

131

interesado en hacerlo; comparación: qué base de comparación se utiliza para juzgar el valor, es decir, cuáles son los criterios valorativos que servirán de patrón para contrastar con ellos la situación conocida; conceptualización: qué es necesario conocer de las herramientas a evaluar, lo cual supone claridad conceptual sobre las dimensiones que encierra la situación a la que se le da nombre, y desglosar esas dimensiones en aspectos concretos, que sirven para definir un conjunto de indicadores que se puedan observar, describir o medir. La garantía para la validez de ese conocimiento sobre lo que se pretende evaluar incluye definir cómo se obtiene, es decir, qué modelos, metodologías, métodos y técnicas se utilizarán, con una fundamentación teórica que garantice esa validez.

Todos estos elementos de comparación dentro de un modelo sistémico y orientado a la evaluación de herramientas de control remoto permitirán desglosar esas dimensiones en aspectos concretos, que sirvan para definir un conjunto de indicadores que se puedan observar, describir o medir. Esta investigación busca establecer las relaciones y condiciones necesarias entre el pensamiento sistémico y la perspectiva de evaluación, dentro de un modelo diferenciador que permita obtener una buena estimación y un conjunto de criterios para evaluar exitosamente el uso del software en el marco de los intereses del negocio, utilizando como caso de estudio las herramientas de software de control remoto. En la próxima sección se estudia en detalle la metodología aplicada para llevar a cabo esta investigación y el desarrollo y aplicación del modelo.

2. CUERPO DEL ARTICULO

2.1 Metodología

La metodología propuesta para la elaboración de esta investigación, es una instanciación

de la metodología Systemic Evaluation for Stakeholder Learning (SESL) propuesta por

Magnus Ramage en 1997, para los sistemas de trabajo cooperativo (Cooperative Work):

“La combinación de la tecnología, personas y la organización que facilita la

comunicación y coordinación necesaria para que un grupo trabaje efectivamente con la

finalidad de alcanzar un objetivo común” [9]. Teniendo en cuenta que los escritorios de

ayuda (helpdesk) y las herramientas de control remoto de fallas junto con la

Organización constituyen un sistema de trabajo cooperativo, y tomando como referencia

la metodología SESL, se propone una instanciación de esta metodología a través de los

siguientes pasos: (1) Determinar la naturaleza del sistema para conformar el marco

teórico referencial; (2) Determinar el tipo de evaluación; (3) Identificar individuos que

afectan al sistema; (4) Estudiar y analizar las preguntas claves; (5) Diseñar el Modelo

Sistémico de Evaluación de Herramientas de Software de Control Remoto; (6) Aplicar el

modelo y (7) Retroalimentación de los resultados. Como se muestra en la Figura N° 1.

132

Figura N°1 Instanciación de la Metodología SESL Para MOSEHSARF.

Fuente: Adaptado de [9]

2.2 Resultados

El modelo sistémico de evaluación MOSEHSARF puede describirse en términos de la

Teoría General de Sistemas (TGS) como un conjunto de ENTIDADES caracterizadas

por poseer ciertos ATRIBUTOS, los cuales mantienen RELACIONES entre sí y están

localizados en un determinado AMBIENTE de acuerdo a un cierto OBJETIVO [10]. La

representación del sistema de estudio utilizando la teoría general de sistemas, presenta

una utilidad práctica, ligada a la sencillez, proponiendo un enfoque top-down en su

descripción. (Ver Figura N° 2).

Figura N°2 Organización de Soporte Interno en términos de Sistemas.

La metodología SESL, sugiere la existencia de cuatro tipos de evaluación, el modelo

sistémico propuesto, asume sólo dos de estos cinco tipos de evaluación en forma

integrada: evaluación de los efectos del sistema y para la compra de nuevos productos.

133

De acuerdo al estudio del sistema a evaluar (primer paso de la metodología) los

individuos afectados (stakeholders) pueden ser definidos a través de las entidades. Se

estudian además los intereses de cada uno de ellos. De acuerdo a los intereses

establecidos para los stakeholders, a continuación es necesario establecer las preguntas

claves y aplicar algún instrumento para obtener los resultados (sugerido: cuestionarios).

La arquitectura del modelo propuesto (Ver Figura N° 3), contempla seis etapas: (1)

Complejidad: cuantificación de la complejidad de la organización de soporte interno;

(2) Costo de Soporte: costos de la organización de soporte interno sin herramientas de

control remoto de fallas; (3) Impacto Control Remoto: impacto de las herramientas de

control remoto de fallas sobre los costos de la organización de soporte interno.

Disminución en tiempos de atención y número de llamadas; (4) Costo Control Remoto:

cuantificación del costo total (planificación, procura, implementación, operación,

adquisición y reemplazo) de la herramienta de control remoto; (5) Efecto Económico:

cuantificación final del beneficio económico; (6) Retroalimentación: comunicación de

los resultados de la evaluación, el proceso de decisión asociado y de aprendizaje

organizacional (ya sea para la evaluación de los efectos o de la compra).

134

Figura N°3 Arquitectura MOSEHSARF Inicialmente en el modelo se realiza el cálculo de la complejidad según la Tabla N° 1.

TABLA N°1 Factores que determinan la Complejidad de la Gerencia de TI. Adaptado [11] % Factor Factor Medición

0.225 (1)

Complejidad de la

Estructura

Altamente Centralizada

0.20

Centralizada

0.40

Dispersa

0.60

Descentralizada

0.80

Altamente Descentralizada

1

0.375 (1)

Madurez de los Procesos

Tiene, usa, documenta, administra y optimiza los

procesos de TI 0.20

Tiene, usa, documenta,

administra los procesos de TI

0.40

Tiene, usa, documenta los proceso de TI

0.60

Tiene y usa los procesos de TI

0.80

Tiene proceso de TI

1

0.051 (1)

Dispersión de los Usuarios

Altamente Centralizados

0.20

Centralizados

0.40

Dispersos

0.60

Descentralizados

0.80

Altamente Descentralizados

1

0.0495 (1)

Disponibilidad de los Servicios de TI

5x8 díasxhora

0.20

6x9 díasxhora

0.40

7x12 díasxhora

0.60

7x15 díasxhora

0.80

7x24 díasxhora

1

0.0495 (1) Niveles de Acuerdo de

Servicio

Próximo día o mejor esfuerzo

0.20

Próximo día garantizado

0.40

Mismo día garantizado

0.60

4 horas

0.80

Inmediato o menor a 30 minutos

1

0.067 (2) % de Aplicaciones que son Cliente /

servidor

20 o menos 0.20

40 0.40

60 0.60

80 0.80

100 1

0.0335 (2)

Numero de Plataformas de

Sistemas Operativos Diferentes

1

0.20

2

0.40

4

0.60

6

0.80

Mayor a 6

1

0.02512 (2)

Tiempo promedio de reemplazo de

Aplicaciones Cliente / servidor

3 meses

0.20

6 meses

0.40

12 meses

0.60

24 meses

0.80

Mayor a 30 meses

1

0.02512 (2) % Aplicaciones

Criticas 20 o menos

0.20 40

0.40 60

0.60 80

0.80 100

1

0.01675 (2) % Aplicaciones de

Productividad Personal

100

0.20

80

0.40

60

0.60

40

0.80

Menor a 20

1

0.04125 (3) # de Arquitecturas

Distintas de Hardware

1 0.20

2 0.40

4 0.60

6 0.80

Mayor a 6 1

0.02475 (3)

Porcentaje Anual de Reposición de

PC

10% o menos

0.20

20%

0.40

50%

0.60

70%

0.80

100%

1

0.00825 (3)

Redundancia (% de Servidores, ubs, router con redundancia)

100%

0.20

70%

0.40

50%

0.60

20%

0.80

10% o menos

1

0.00825 (3) % de Dispositivos

Móviles o Portátiles

10% o menos 0.20

20% 0.40

50% 0.60

70% 0.80

100% 1

Donde el primer factor (1) representa el 75% asociado a la complejidad de la gerencia de

TI como tal, el segundo (2) y el tercer factor (3) correspondientes al impacto del 67%

software y el 33% hardware que respectivamente unidos conforman el 25% asociado al

impacto de la infraestructura de TI.

A partir del cálculo del porcentaje de Complejidad se puede utilizar una escala

135

(0-9) con la finalidad de establecer un nivel de complejidad de la gerencia de TI en la

organización.

( )dComplejidaejidadNivelCompl %81 ×+= (ec. 1)

El estudio predictivo toma los cambios en los factores de complejidad y los aplica a

todos los cálculos de costos a fin de predecir los nuevos valores.

Una vez establecido el porcentaje y el nivel de complejidad de la Gerencia de TI, se

procede a realizar el cálculo del costo de soporte, para lo cual es necesario calcular el

número total de llamadas en el periodo de evaluación, de acuerdo a la siguiente

ecuación:

[ ] ( ) ( )[ ]tllampromAcActApliActSOPullampromusmesesPCllamadas ×++××= (ec.2)

Donde, el símbolo PC representa el número de computadoras personales, meses el

número de meses del periodo de evaluación, llampromusu las llamadas mensuales

promedio por usuario, ActSOP la cantidad de actualizaciones de sistema operativo,

ActApli las actualizaciones de aplicaciones y llampromAct el número promedio de

llamadas por actualización.

Gartner Group sugiere que en un periodo de dos a tres años, el número de llamadas

promedio de un usuario por mes en el peor caso es de 3.5 llamadas y en el mejor caso es

de 1. Además, que el número de actualizaciones de sistema operativo es de 1 en el peor

caso y 0 en el mejor caso, y que el número de actualizaciones de aplicaciones es de 6 en

el peor caso y 5 en el mejor caso. El usuario efectúa en promedio por actualizaciones de

sistema operativo y aplicaciones 2 llamadas extras en el peor caso y 1 en el mejor caso.

Tomando en cuenta estas sugerencias del Gartner Group, se puede estimar un cálculo

136

para el número total de llamadas en el periodo para un mejor y peor caso en forma

predictiva a través de las siguientes ecuaciones:

( )5)( +×= mesesPCmejorcasollamadas (ec. 3)

( )[ ]145.3)( +××= mesesPCpeorcasollamadas (ec. 4)

Gartner Group, nuevamente sugiere una distribución para los tipos de llamadas y sus

tiempos de atención en el primero y segundo nivel en un mejor y peor caso. A

continuación se tiene que:

toopatentiempopromllamadasOperaciónCosto cos_ ××= (ec. 5)

tohelpdesktllamadasdllamadaHelpDeskCosto iii cos__ 11 ×××= (ec. 6)

Donde 0 < i < 9 representa el tipo de llamada, i=1 requerimiento de servicio, i=2 mantenimiento, i=3 mudanza, i=4 instalación, i=5 consulta, i=6 reparación, i=7 cambio de clave, i=8 interrupción. La variable llamadas representa el número total de llamadas en el periodo de evaluación, tiempopromaten es el tiempo promedio de atención, costop es el costo de operación en dólares por hora y costohelpdesk es el costo en dólares por hora del helpdesk. Finalmente el costo original de soporte (COS) se determina a partir de:

( )∑∑= =

− ××××=n

j

m

ijjijij ostotddllamadasCOS

1 11 c

(ec. 7)

Donde j representa los diferentes niveles de soporte de la organización. Por ejemplo j=1 Helpdesk, j=2 Servicio de Campo, j=3 Proveedor Nacional, j=4 Proveedor Regional, j=5 Proveedor Internacional. Los dji son el porcentaje de llamadas tipo i del nivel de soporte j-1 que pasan al nivel de soporte j. Con d0i=1

tji representa el tiempo promedio de resolución para el tipo de llamada i por el nivel de soporte j. costoj es el costo en horas asociado al nivel de soporte j.

Es importante aclarar que las llamadas atendidas en el nivel j son un porcentaje de las atendidas en el nivel j-1 es por esto que existe la multiplicación de los factores d(j-1)i x dj Una vez establecido el costo original de soporte es necesario calcular el mismo costo pero aplicando el impacto de implementar las herramientas de control remoto, para esto se pueden tomar mediciones en el caso de que el software haya sido implementado antes del estudio o se pueden utilizar las siguientes mediciones sugeridas por el Gartner Group. De tal forma que el Costo de soporte con RC o Costo Reducido de Soporte (CRS), se expresa de la siguiente manera:

( ) ( ) ( )[ ]∑∑= =

− −×−×××××=n

j

m

ijijijjijij dtdctddllamadasCRS

1 111 11

(ec. 8)

Donde j representa los diferentes niveles de soporte de la organización. Por ejemplo j=1 Helpdesk, j=2 Servicio de Campo, j=3 Proveedor Nacional, j=4 Proveedor Regional, j=5 Proveedor Internacional. Los dji son el porcentaje de llamadas tipo i del nivel de soporte j-1 que pasan al nivel de soporte j. Con d0i=1

dlji es el porcentaje de disminución por uso de la herramienta en el número de llamadas del tipo i del total de llamadas asociadas al nivel de soporte j. Con i y j como en los casos anteriores. Con d0i=1

dtji es el porcentaje de disminución por uso de la herramienta en el tiempo promedio atención del tipo de llamada i del total de llamadas asociadas al nivel de soporte j. Con i y j como en los casos anteriores. Con d0i=1

tji representa el tiempo promedio de resolución para el tipo de llamada i por el nivel de soporte j. cj es el costo en horas asociado al nivel de soporte j.

137

Una vez calculado el costo de soporte con la reducción introducida por la herramienta, a continuación es necesario calcular el costo de la herramienta H, tomando en cuenta las características discutidas referentes a los costos asociados al ciclo de vida del producto, el cual puede calcularse de acuerdo a la siguiente ecuación:

[ ]{ } ReIm ++++×+×+×+××= SopMantLicenOpHoppleHimpleNegHnegPlanHplanPCH

(ec. 9)

Donde H representa el costo de la Herramienta, PC es el numero de computadoras personales, Hplan corresponde a las horas de planeación, Plan al costo de planeación, Hneg las horas de negociación o procura, Neg el costo de negociación, Himple las horas de implementación, Imple el costo de implementación, Hop las horas de operación, Op el costo de operación, Licen el costo de licenciamiento, Mant el costo de mantenimiento, Sop el costo de soporte y Re el costo de reemplazo. Finalmente generalizando la ecuación 9 a partir de la ecuación 8 para diferentes niveles de soporte y tipos de llamadas, se obtiene la ecuación 10 Costo Real (CR):

HCRSCR +=

(ec. 10)

A continuación es necesario calcular el efecto económico (EEC) que no es más que tomar el costo normal y restar el costo reducido y el costo de la herramienta tal como se muestra en la siguiente ecuación: CRCOSECC −= (ec. 11) Esta ecuación debe ser mayor que cero para obtener un efecto económico positivo, lo que indica que lo que pagaba antes la empresa por mantener la operación debe ser mayor de lo que se pagará al reducir los costos a consecuencia de implementar la herramienta, además del costo en el que la organización incurre al ejecutar el proyecto. Donde el Costo Original de Soporte - Costo Reducido de Soporte es el Ahorro que se obtiene al implementar la herramienta sin incluir el costo del proyecto (H). De la ecuaciones 11 y 12 con un ECC positivo se deriva la siguiente desigualdad: CRHCOS >− (ec. 12) Esta ecuación (ec. 12), indica que si se conoce la situación actual y se aproxima con certeza el costo del proyecto de implantación de la herramienta, se obtiene una meta mínima del nuevo costo reducido. Si el Costo Reducido es igual al Costo Anterior, la empresa se encuentra en la situación inicial, es decir no mejoro al implantar la herramienta. Si el Costo Reducido es cero, quiere decir que la herramienta elimina todas las llamadas o llevó todos los tiempos a cero y ésto es una situación utópica. Resumiendo, el Efecto Económico está en función de la reducción en número de llamadas y tiempo de atención que se obtiene en los niveles de soporte como consecuencia de las herramientas de control remoto de fallas, en comparación con el costo total. Finalmente el modelo establece la realización de una fase de retroalimentación donde se comuniquen los resultados. Luego de obtener los datos finales de la relación de la evaluación, éstos son analizados con el objetivo de obtener resultados que conduzcan a conclusiones relevantes en cuanto al comportamiento del modelo de evaluación y de las herramientas de control remoto en la organización de soporte interno. Si se conducen ambos estudios, el estudio predictivo con las tablas de Gartner por que se desea comprar la aplicación y el estudio evaluativo ya que la aplicación está en funcionamiento, se puede realizar un tercer análisis correspondiente a un estudio comparativo entre los dos resultados utilizando la arquitectura del modelo.Para la aplicación del modelo de evaluación, se tomó la empresa venezolana CANTV, en la cual se contemplaron cada una de las seis etapas propuestas en la arquitectura del modelo. Con la finalidad de validar el modelo en su totalidad, se realizaron dos estudios de evaluación separados: un estudio predictivo y un estudio evaluativo en base a los dos años de utilización de la herramienta de software Remote Control de IBM-Tivoli implementada en CANTV a partir del 1 de enero del 2000.

3. CONCLUSION

Comparando este modelo con los propuestos por Flagg 1990, Strovink 1998 y Garner Group 2000 y algunos otros autores asociados a la calidad del producto de software (Booch 1994, Segovia 1996, Fenton 1997, Hopkins 1997, Rumbaugh 1998 y Patrick 2000) se evidencia que sus bondades fundamentales se encuentran en la utilización de la teoría general de sistemas en la representación del sistema objeto y la organización de soporte como un sistema abierto, así como el subsistema de control que lo sustenta,

138

permitiendo establecer una abstracción del mismo que garantice su aplicación no sólo en el ámbito de otras organizaciones de soporte y otras herramientas de control remoto, sino en especial en la evaluación de otro tipo de software, igualmente se destaca en este estudio la relación entre la complejidad de la gerencia de tecnología de la información y el retorno de inversión asociado a las inversiones de software en el marco de los intereses del negocio.

El Modelo, permite obtener una visión clara de la organización de soporte interno y de su entorno en cuanto a la capacidad, necesidad y voluntariedad para adoptar y usar una herramienta de control remoto, así como su participación en el logro de los objetivos, de manera que se reduzcan los riesgos asociados a su implantación y uso. El Modelo determina como influye la complejidad de la Organización en el componente económico, en la efectividad del soporte y en la efectividad del proyecto, teniendo en cuenta factores de costos que normalmente no son utilizados al medir el impacto del software en la organización (costo de negociación, planeación, implementación, reemplazo, etc.). Así como también, permite determinar tendencias, detectar debilidades y factores de mejora asociados a la obtención de un efecto económico positivo.

A través de este estudio se puede determinar que la complejidad de la organización, el tiempo promedio de atención, el factor de disminución y el costo del proyecto son los factores claves en la organización de soporte interno. Los costos por hora en el modelo predictivo, dan una cota de hasta cuanto debe pagar la organización para mantener el proyecto, es decir ellos influyen directamente en el ahorro y éste último acota el presupuesto asociado a la herramienta. Cuando se aumentan los costos por hora de los diferentes niveles de soporte se disminuye el potencial de efecto económico positivo. Además los costos de atención están en función de la disminución en los tiempos de atención y llamadas evitadas. El hecho de que los costos de soporte disminuyan notablemente no implica que se obtendrá un efecto económico positivo, si se siguen manteniendo igual los porcentajes de disminución asociados al impacto de la herramienta.

En cuanto a las limitaciones se tiene que el modelo aplica. Sin embargo, existen otras variaciones de la organización de soporte interno que pueden involucrar que los costos disminuyan y se calculen de una forma diferente al modelo. Cabe destacar que los resultados finales obtenidos se ajustan al caso de estudio en particular. Es decir, al cambiar las condiciones del caso, los resultados obtenidos en la aplicación del Modelo podrían ser diferentes. Las limitaciones confrontadas en cuanto a la veracidad de las respuestas de los cuestionarios, impiden asegurar con total certeza la representatividad de la muestra. Esta situación restringe la validez estadísticas de las generalizaciones a las poblaciones de las muestras. Pero los trabajos que brindan información sobre el comportamiento de usuarios reales son necesarios y deseables para el progreso y el desarrollo de sistemas de control aún cuando el comportamiento sea observado en muestras pequeñas no controladas.

Se puede generalizar el modelo, como una forma de estudiar el impacto de una TI, determinando el costo antes de la TI, el costo de reducción, el resto de los costos asociados y verificando el efecto económico tanto en forma predictiva como en forma evaluativa, destacando la influencia de la complejidad de la gerencia de TI en la determinación predictiva de los costos.Otros estudios futuros podrían orientarse en la evaluación del método desde la perspectiva de la investigación de operaciones con la finalidad de obtener valores exactos de la forma como las variables pueden combinarse para garantizar la eficacia de la organización. Además de concluir / desarrollar estudios topológicos.

REFERENCIAS

[3] Campos F., Campos G. & Rocher, A. “Dez etapas o desenvolvimiento de software”. 3er congreso iberoamericano de informática, Barranquilla Colombia (1996)

[8] Evans J. “Administración y control de la calidad”. International Thomson Editorial. S.A. México 5ta Edición (2001)

[2] Flagg. B. “Software Evaluation”. Hillsdale, New Jersey. Lawrence Erlbaum Associates, Publishers (1990).

[5] Garner Group Inc. “Hiring for the 21st Century”. The Public Workshops (2000) [10] Johansen B. “Introducción a la teoría general de sistemas”. Editorial Limusa, Mexico DF. (1997) [9] Manus R. “Developing a Methodology for the Evaluation Cooperative Systems”. (1997) [4] Paredes L. “Gestión Tecnológica y reconversión industrial”. Revista Espacios, Vol 12. Num. 3.

139

pp. 59-77. (1991) [1] Strassmann, P. “Getting better value from information management”

Information Economics Journal, (2003). [11] Strovink K., Paquet R., Keyworth B., Ardito Smith. “Lowering Support Costs UIT LAN

Management Tools. Strategic Analysis Report Garner Group” (1998) [6] Symantec Latin America Headquarters. “Enterprise remote control” (2001)

140

Methodological Proposal for Business Process Management sustained in the use of Patterns

Pedro Bonillo, Nancy Zambrano and Eleonora Acosta, Central University of Venezuela, Caracas, Venezuela

Abstract At the moment, enterprises require complex business models with an organizational structures, processes and systems that must be explicitly designed. The work designed by these business models is clearly interdisciplinary, since it requires business development knowledge, different processes enterprises, management of these processes, and technological applications. In the scope of the software engineering would be desirable to obtain a system of methods, tools and techniques that allows the reuse of the best practices during the process of software development according to each one of the processes that are implemented in each domain. This work describes a theoretical methodology proposal framework. The methodology includes from the analysis of the requirements to the monitoring of the processes, supporting the analysis stages, design, model and configuration, through the use of patterns. The methodological proposal is conformed by two macro-processes: one related to the creation of the process itself and other that corresponds to the administration, and it includes: the maintenance, administration of the process in production and the monitoring through management indicators.

1 INTRODUCTION

The main purpose of this work is to propose a methodology that allows the Management of the Business Processes (BPM), based in the use of patterns [Alexander et. Al.77] [Gamma et al.95] [Buschmann et. Al 96]. This Work propose a taxonomy of patterns and its representation through an Architecture Definition Laguages (ADL) into an architecture of processes, services, and canon objects in the BPM domain. In addition, it opens out the pattern especifications[Acosta, Zambrano04], in order to be able to measure its quality through Attribute-Based into Architectural Styles (ABAS) [Kazman. Klein04]. ISO14-598 and ISO-9126 are used as a quality models of procesess and as the product. Considering this combination of methods, tools and techniques, it proposes a group of steps that in the BPM scope, allows to identify the key processes, to model them and to analyze them, to simulate them, to implant them in an assisted way (Such as new processes as their versions); to evaluate them, monitore them and improve them. Construction of Software Based on Components In literature, exists several definitions for “component” In [D’ Souza, Wills99] it is understood by “component” as a coherent package of code that: (i) can be developed and

141

distributed independently, (ii) has explicit and right specified interfaces to the service that it offers, (iii) has explicit and right specified interfaces to the services that are reliable from other components; and (iv) can be formed by other components, maybe opens out some of its properties, but without modifying the component itself [D’Souza, Wills99]. A more general definition is given by Jacobson, Griss and Jonsson[Jacobson et.al97] who defined it as an device that has been developed specifically to be reuse (this definition will be the one which this article will adopt). In this case a component could be as much as a case of use as any other reusable element that will rise during the development processes and it will be used in any activity, whenever it does not require knowledge of the software that uses it. In the Objects Oriented (OO) approach, the objects can be seen as components, unless they satisfy additional guides directed to make auto-contents for them, the use of another components by means of aggregation and generally they interact with other components through the events.

The component used in the development process of software has three main targets: the reusability, the adaptation and the extension (the reusability can imply the adaptation and extension), understanding that:

- A component is reusable since its services can be used by another application. - A component is adaptable if its supplier has anticipated the possible changes that can

suffer this component, and can make it compatible with other hardware and software platforms.

- A component is extending whether its supplier gives the mechanism to modify or extend the services that the component offers.

Last year, we studied among others, two ways of the processes for software

development: the agile and heavy methods. The fundamental difference between both of them is that while heavy methods try to obtain the common objective by means of order and documentation, the agile methods do it improving the direct and immediate communication processes between the people who are within. The development processes to consider in this proposal are: Unified Process (UP) as a method of heavy development, XP (eXtreme Programming Project) and FDD (Feature Driven Development) in representation of the agile methods.

If the project is sufficiently large to suggest the adaptation of components from previous developments, it is possible to say that UP is appropriate for the process of software development because it allows to obtain a better structure and discipline. A good possibility of reducing the work is with the reusability of models and processes already defined in a previous implementations of UP in different scopes. Referring to the architecture, XP with the system metaphors tries to determine an optimal architecture in the early stages of its development.Even though FDD is centered in the quality, it leaves all the weight of the architectural decisions to the main architect, but it does not specify how these decisions are related with the quality of the developing system.

On the other hand there is a generalized problem for the development processes UP, XP and FDD: the selection of the suitable architecture or combination of different

142

architectural styles for a software system, is a problem that has not been solved yet and that it has been treated widely in literature. In relation to this problem, the use of components in these software development processes allows:

- In relation to obtain requirements: (i) the vertical analysis, focus in a domain or in a specific area of business; which its objective is that the resulting components can later become standards for any developed application in that domain and points out towards its reusability; (ii) the horizontal analysis, made in a generic way to give service to an ample rank of applications, without restricting itself to a domain of a given business; and (iii) specific analysis, made in a concrete domain, to obtain components “ad hoc” where the emphasis does not make so much in the reusability but in the extension.

- In relation to Design: during the gathering of requirements all the functions that had been identified and must be supported, but the distribution of these functions can occur immediately or can be constructed adapting the existing components. The following aspect corresponds to the partition of components, which can be made through: the use of cases, the patterns of design, the organizations of the domain, the anticipated evolution of the system, and the already existing components.

- Regarding the interaction of components: it is said it is direct (simple interaction) when the offered service adjusts to the forms and necessities of the required service. If the forms are not the suitable ones, it is necessary to previously make a packing process (“wrapper”). The growth of the systems complexity, usually constructed through the integration

of components, increases the necessity to obtain more rigorous approaches than lead this process of decision. UP, XP and FDD have absence of a clear relation between the components (between these, the patterns), the architecture and the characteristics of the quality associated to the architecture. UP on the other hand, doesn’t have an association of the nonfunctional requirements with the use of cases; a bad selection of the main use cases affects the architecture of the system; the model used test to evaluate the architecture doesn’t have guides precise to determine this relation. In the next section, there will be a presentation of a new form to relate these concepts, to solve this deficiency.

Establishing the relationship between Patterns, Components, Applications, Processes, Methodology and Quality

In the Fowler book[Fowler97] there is an interesting generic definition: “a pattern is an idea that has been used in a practical context and probably it will be useful in others”. The main idea expresses that a pattern can be any “thing”. The expression in the practical context reflects the fact that it is developed (some authors prefer: discover) due to the practical experience of real projects. Considering this general definition of patterns, it is possible to affirmed that such can be expressed through components and these, as well as functions that are implemented in different applications (Figure 1).

143

Fig 1: Relation Patterns, Components, Applications, Processes, Methodology and Quality.

In figure 1, the notches represents a “through” expression, which means that the patterns express themselves through components, the applications through components and patterns, the processes through applications and patterns, all of these within the framework of a methodology (a system that joins the concepts) and where each element must have associated with quality.

The concept of patterns in software engineering [Gamma et al.95], was introduced with the design patterns. At the moment, the software patterns constitute a more general concept, representing applicable conceptual structures in the diverse phases of the development process. In the following section, a new taxonomy of software patterns are set out.

Taxonomy of Patterns

A pattern is a solution to a problem, accepted as correct, which has been received a name and that can be applied in other contexts [Fowler97]. A pattern captures the experience and knowledge of experts, who have produced successful solutions to problems, giving the disposition of a soclution to those with less experience; nevertheless, the patterns do not always provide the definitive solutions, sometimes, the users of patterns must have creativity to use or implement a pattern [Acosta, Zambrano04].

In todays the Software engineering, the patterns can be applied at the level of: analysis of requirements, architecture designs, detailed designs, the interaction with the users and codes. With these the following classification or taxonomy can be set out, according to the abstraction level:

- Patterns Analysis: They are groups of concepts that represent a common construction of the conceptual model in the world. Can be relevant to a domain or adapted to many domains. The main idea is the construction of scenes using patterns. It is essential to try to have one more conceptual and structural vision of the situations, with the purpose of identify the intrinsic nature of the same ones. With that vision, it is possible to determine the type of scene corresponding to each situation and choose a pattern of a catalogue, reusing his structure with the purpose of deriving the easiest and directly scene. They consist in a text guide which for each scene component it includes guidelines about the content that must have the same one. They are presented as described scenes which a reduced number of conformation rules has been added as

144

scene meta-components. Each component of the scene, according to the structure defined in [Leite00], has been completed with a nominal text that is expected to be replaced in the real scene generated when the pattern is used, but it as well guides the writing of the component [Ridao01]. For example, the analysis pattern to make a productive activity is applied to the scene to design a meeting agenda such as a form to reuse the characteristics of a productive activity to the specific domain of a meetings agenda.

- Patterns Architecture: They are fundamental organization schemes in a software system. They specify a series of subsystems and its respective responsibilities. It includes the rules and criteria’s to organize the existing relations among them [Klein, Kazman99]. Some examples are: layers, filters and connections; models, views and controls (MVC). The architectonic styles are a generalization of the architecture patterns because they express the components and the relations of the structural and general skeleton of an independent application of the context and other styles; they are the categorization systems [Klein, Kazman99]. Some typical styles are the architectures based on data flow, those of implicit invocation, hierarchic and centered in data or those of virtual interpreter-machine.

- Patterns design: They are patterns of a level of abstraction smaller than the architecture patterns. They are therefore, next to which would be the final source code. For example: “abstract factory”, “constructor” and “chain responsibility” [Buschmann et al.96].

- Patterns Interaction: also known as Patterns Interface describes a successful solution to a recurrent problem concerning the user’s interface in a given context. A Pattern of Interaction is a way communication that is expressed in a simple annotation, in order to be understood by the people of the interactive design team that is generally multidisciplinary [Mahemoff, Johnston98]. Some examples are: Data formats of dates, hierarchic visual representations of the systems state [Van00].

- Patterns Implementation: They talk about the form to program or to implement a solution in a specific language, it is associated with the term kit or idiom.

From this hierarchical structuring, it is precise to notice the differences that exists between the types of patterns themselves and from the architectural styles, it is related to its level of abstraction (isolated patterns versus families - languages or catalogues - of patterns).

In general, the patterns have a limitation: they are difficult to specify and to evaluate from a model of a particular quality. For the specifying problem and the taxonomic relation, the use of ADL (Architecture Definition Language), according to the suggested hierarchic proposed and as far as the evaluation of the quality, proposes to use one of the first initiatives of quality measurement in the patterns: ABAS (Atribute-Based Architecture Styles) [Kazman, Klein04], as structures that extend the representation of the patterns, with the purpose to specify the information on themselves and the relative characteristics of quality. These subjects are considered in the next section.

Representation of Patterns and its Taxonomy, through a Language of Definition of Architectures

ADL (Architecture Definition Language) is a descriptive language that concentrates in the structure of high level application before the details of implementation of its concrete

145

modules [Cod, May99]. A consensual definition of ADL doesn’t exist until today, but commonly it is accepted that an ADL must provide an explicit model of components, connectors and their respective configurations. It is considered desirable, in addition, that an ADL provides the support of tools for the development of solutions based on architecture and its later evolution.

A Shaw study [Shaw,Clements96] analyzes the complex influence of the theory and the practice of the patterns on the ADL. This author considers that the ADL have been own of the software architects community, while the patterns and their respective languages have prospered between the software designers, particularly among the groups joined to objects oriented in designs. Naturally, both communities overcome themselves. Concerning to the relation between architecture and design, the maintained discussions have reached a consensus in that these designers operate at abstraction levels lower than the architects, but over the programmers levels[Shaw, Clements96]. On the other hand, Buschmann has documented patterns that are used as architectonic styles governed by ADL [Buschmann et al.96]. Shaw and Clements concluded their analysis alleging that the ADL can benefit incorporating analogous type of elements to the patterns in the sections that refer about styles, groups and rules of design [Shaw, Clements96].

The representation of an architecture of processes, canonical services and objects for its subsequent administration, implies the use of a ADL or a modeled generic language as it could be UML, this would allow to make the association that is explained in figure 1: relating the taxonomy of patterns before described, with the components and the applications, through the process, according to a methodology. In this association, it is necessary to establish measures that allow studying the quality and the audit process of the software construction and its product obtained through it, which is the reason why the next section is the ABAS subject [Kazman, Klein04].

Evaluation of the Quality in the Patterns of Software

An Attribute-Based Architecture Styles, (ABAS) is an information structure, a group that contemplates the pattern descriptions with the quality attributes; it was propose by Kazman, Klein, Barbacci, Longstaff, Lipson and Carriere [Kazman et al.98]. It is defined with a three elements base : (1) the topology of the types of components, and a description of the patterns of data and control, forthe interaction between the components (as in the standard definition); (2) a specific attribute of quality in a quality model, and; (3) the reasoning resulting after applying the attributes of an specific model of quality in the interaction of the types of components.

With the purpose of incorporating the concept of ABAS in the taxonomy of patterns exposed previously on this article and taking as a reference the patterns representations from interaction on the base of meta-pattern proposed by Acosta and Zambrano [Acosta, Zambrano04], the following extended representation is obtained:

Name (title), author classification, domain (well-known uses)

Name: Central idea by which the pattern is identified. Author: Name of the person who created the pattern. Classification: Type of pattern according to the taxonomy before

146

and rank. mentioned. Dominion: Indicates the domain or the domains in which the pattern has been implemented. Rank: it is the degree of trustworthiness of this pattern with respect to the domain in which it has been implemented.

Problem Describes the problem that will be solved, from the point of view of the user.

Solution Describes, in a narrative and graphical way, the solution to the problem. With a base in: Objective, Intention, Motivation, Actors or Participants, Resources, Structures, Episodes, Collaborations and Implementations.

Attributes of Quality Attributes of quality of interest, the context of use, contrasts and relevant attributes (specific requirements).

Measures of attributes of Quality

A summary about what is discussed in the description of the problem, using specific terms related to measurable aspects of the attributes in the quality model. This includes a discussion of events that could cause that the architecture responds or changes.

Parameters of attributes of Quality

A summary about what it will be discussed in the solution section, but specifying relevant terms to the parameters of the specified attributes in the quality model.

Analysis of the Model of Quality

A description of how the attributes of the quality model will formally be related to the elements of the pattern and the conclusions on the architectural behavior that it is obtained with the model.

Context Presents the conditions under the used pattern.

Force Conflicts that could restrict the solution. Including the exceptions.

Consequences Describes the result to apply the pattern.

Examples/Against-Examples

Shows examples and against-examples of the proposed solution.

Related Pattern

Other patterns that are related to the pattern described.

Table 1 Meta-pattern adapted from [Acosta, Zambrano04] and [Kazman, Klein04] It is important to mention that the usability of the pattern indicated in the

representation of Acosta and Zambrano [Acosta, Zambrano04] is, in this case, a quality

147

attribute. In addition, a pattern does not require, generally, all the elements mentioned before. In order to fulfill its objective, a pattern must have as a minimum the following elements: Name, Problem, Solution and Context.

Business Process Management (BPM)

Business Process Management is an ancient problem. This article tries to study it according to the new technologies, being considered to the potentialities of a model that includes re-usable components.

In the scope of the business processes, the technological solution by excellence talks about the term “workflow”, which is the process through the individual tasks that is coordinated to complete a transaction (using the defined processes of the business) within an organization. Workflow is a set of mechanisms that automate the work processes. These mechanisms, related to each other aspects of the administration, establishes priorities between the diverse tasks of each employee and optimize the communications between the different operative units. To obtain this, it is necessary to define which are the different tasks that are built in an organization; who participate in their execution; who are responsible for the same ones; which is the sequence of tasks of each processes and which are the actions that initiate each process. Although the contribution of the traditional workflow (modeled by the WFMC Workflow Management Coalition), it is still remarkable that there is a new generation which perhaps a hybrid that reunites the better things of all the “workflow” systems and other technologies: Business Process Management Systems (BPMS).

The BMPS incorporates ample capacities of integration with modern Java architectures, Net and XML. Additionally, they add other technologies such as Web Services, Business Rules Motors, Business Activity Monitoring (BAM) and Business Process Optimization (BPO). In agreement with Howard Smith and Peter Fingar [Bell03], guaranteed by BPMI (Business Process Management Initiative) and the WFMC, nowadays it can be affirmed that “the BPMS allows the companies to model, implement and manage the business processes, including enterprise applications, departments, and suppliers (“partners”), but without a referential frame integrated” [Bell03].

The BPMS have evolved since the integration of business architectures, where it is contemplated to the transformation and routings of data, administration of events, automatization of processes and the use of adapters in the 90’s; to the integration in the 2000 of the business processes through the basic model of the processes, the management of the suppliers, connectivity between companies through the ecommerce and formation of certain groups of processes for vertical industries; until arriving at the actual concept (since 2004) involved: applications of workflow, sophisticated model of processes, monitoring of the activities associated to the business processes (BAM), exhibition of the functions of the applications through web services, use of business rules management, support to multiple devices of access to the information in any place and from any position (“aware-contex”) through the use of portals, use of management tools of the life cycle of the software application development that supports the processes, mobile support of the processes and the interfaces, extraction, transformation and load (ETL) of data that are used by the

148

processes and the capacity of simulation on the processes and versioning of them (Bussines Process Optimization BPO).

In spite of all the characteristics before mentioned, the BPMS lacks from a global and integral framework that establishes a methodology for its implementation and use. According to its implementation, most of the software patterns are not supported in a precise form. The market of the BPM architectures tends to concentrate in system flows to system and it is emerging slowly as far as the human-human flow attended by the computer [Bell03]. Based on this, BPMI is the organization which assumes the elaboration of standards (BPA, BPMN and BPMS; analysis, notation and semantics respectively) that sustains the BPM concept focusing on the business process such as the start point between the environment of it and putting it in practice through the technology. At the moment Workflow Management Coalition is being unified with the BPMI and with OMG (Object Management Group).

All the aspects discussed and the deficiencies shown above,lead to the elaboration of the methodological proposal.

2 METHODOLOGICAL PROPOSAL

In this section, there will be a description of the methodological proposal for business process management sustained in the use of patterns, as a form to solve the problems before they appear. Initially, appears an integral theoretical framework; following it with the appearance of the methodological proposal making aspecial emphasis in the aspects of the generation of applications, through the software engineering.

Integral Theoretical Framework

In this integral theoretical framework is outlined a possible solution to the problems shown in this investigation.

As shown in the taxonomy of patterns in figure 2, there is a relation between the abstraction level, the type of patterns, and the standard suggestions by BPMI, which obtains a direct relation of taxonomy of patterns with the domain where the methodology sets out (BPM). In addition, the taxonomy of patterns is also associated with its formal definition through an ADL establishing the relation between patterns, components, applications and processes through a methodology. Finally, this taxonomy of patterns is associated with the necessity to measure the quality of each pattern and to establish a mechanism of auditing in the use of the patterns, providing them of specifications of quality with the ABAS use, within the framework of a quality model (ISO9126 for the quality of the product and ISO14598 for the quality of the process).

149

Fig 2: Integral theoretical framework of the Methodological proposal

The specification, through an ADL, of the levels of abstraction of the BPM

architecture that sustains the propose methodology, allows the representation in four layers of the same one: layer of processes where the orchestation is made of itself, layer of services (represent the canonical objects and the services as functions of the applications), application layer (applications, components and software) and layer of technology (hardware). These layers allow the identification of three specific architectures: services, components and applications architecture.

In special, the architecture of services contains the services of: infrastructure management, administration of suppliers or associate, own business applications, applications of legacy, interaction, processes of business, information and connectivity (which allow the communication between all the services mentioned). In a level of abstraction superior to these services, there are services of management indicators and software development, which had the rolls such as business analyst (modeler of the process), architect, specialist of integration, developer and analyst of tests.

The process associated to the software development services has a direct relationship with the process since it manages other one; this process, as well, is defined in the services of process and is the conductor that will allow to administer of integral form the BPMS and that defines a cycle for the management of the business processes that consist of the identification of the key tasks, the model and analysis of the tasks, the simulation and implantation of new processes, and their evaluation and monitoring.

Description of the Methodological Proposal

150

The methodological proposal for the business processes management sustained in the use of patterns is conformed by two macro-processes: (1) Creation of the business processes; and (2) Administration of the business processes in execution.

The first macro-process includes the following sub-processes: 1.1. Analysis and evaluation of the requirements considering the type of priority

and the base of the elicitation practices requirements of the software engineering. In this sub-process, the user asks for a requirement on an existing process or a new one, the analyst of the business identifies the requirement according to the practices of elicitation of requirements of the software engineering (it describes the requirement in terms of the functional requirements and nonfunctional, it assigns a priority for it and evaluates a billboard of the possible activities to make in the time). Next the analyst of the business consults the patterns of analysis available in domain and relates them to the requirement. Finally, for any other necessary information that it rises, it invokes a process of change management in order to introduce the new requirement in the existing architecture of processes;

1.2. Design of a standardized model of the process according to the patterns of analysis in the domain (better practices). In this sub-process, the analyst of the business compares it according to the requirements of the user, with the analysis patterns (better practices domain), in order to identify the existing breaches and the organizational risks to assume. Later, it negotiates the risks with the client; the analyst of the business makes a design of the process model according to the architectural styles and the architectural patterns that are associated to the selected patterns analysis or the specific requirements of the user. In order to finalize this sub-process, the analyst of the business defines a definitive list of activities in the time and invokes to the process of software development, which the architect selects a development process (UP, XP or FDD) and configures a development environment (hardware and software).

1.3. Modeled, diagram and simulation. In this sub-process, the analyst of the business makes a diagram of the process designed in a BPA tool (selecting the already existing diagrams for the patterns of analysis, architectural styles and chosen architectural patterns in the sub-process of design). Next, the analyst of the business makes a simulation in the BPA tool in order to detect tendencies (necks of bottles, cycles, etc.) and asks the user for the approval of the process simulation. Then, the analyst of the business joins the actual diagram process with the existing general diagram for the architecture of all the processes (relating the present process to the existing processes) and makes a simulation again in order to verify the tendencies with respect to the general architecture of processes, asks to the user for the approval, makes a closing report of the design and the modeled one of the process, and indicates the architect whom exports the BPEL (Language of Execution of Processes proposed by the BPMI) from the BPA tool and the UML (Unified Language of Modeling) who will be input for the software development process.

1.4. Configuration and implementation of the logic of integration, businesses and presentation of the process through the orchestration of services, objects and the use of patterns of design and interface with base in the modeled phase. In this

151

sub-process, the architect takes the UML diagrams created by BPA tool, and the functional and nonfunctional requirements from the analysis of process requirements, and it completes the UML diagrams according to the process of the selected development (UP, XP or FDD). Later, from the UML diagrams, the BPEL and the patterns of design related to the analysis patterns, architectural styles and selected architectural patterns in the previous sub-processes, the architect asks for the developer that it constructs the logic of business of the application that will sustain to the process (the developer besides to select the patterns design, also selects the idiom in which it made the development of the business logic); similarly according to the patterns interaction related to the analysis patterns, the architectural styles and selected patterns architectural in the previous sub-processes, the BPEL and the associate interfaces automatically with the BPEL through the BPA tools the architect asks for the developer that constructs the interface of the tool that supported the process (the developer besides to select the patterns interaction also selected idiom in which it made the development of the interface). Then, the architect asks for the integration of a specialist who makes integrations between the BPEL, the interface and the logic of business. Having the BPEL, the logic of business and the interface integrated, the architect proceeds to place in the BPEL the indicators management that will be measure the process, for this it selects of a set previously defined according to the analysis pattern, the necessary indicators and it as well asks for the developer that constructs the reports necessary to show the indicators (the BPMS contains a modulate of BAM which store these indicators in the time according to structures of business intelligence). Finally the architect asks for the tests analyst the software certification product that sustains the process, soon to finalize the process of change management of the architecture of processes and to solicit collocates it to production of the process (it is precise to mention that different versions from a same process can be handled).

The other macro-process corresponds to the administration of the processes in execution and includes: the maintenance, administration of the process in production; and the monitoring, validation of the technical-functional data of the processes implemented through indicators management.

3 CONCLUSION

It can be concluded that at the moment it doesn’t exist a treatment sufficiently exhaustive and consolidated of the subjects of business process management sustained in the use of patterns, according to the audit and the quality of the process and the product of the software. By means of this investigation these deficiencies are attacked, and propose the construction of:

- A language of patterns for the methodology of business process management with a base in the construction sustained in software components: a study of the existing alternatives for the selection, application and verification of patterns and the composition of components of software from the point of view of the conditioners

152

raised here (audit, verification static, automatic and reasonable) contemplating to the model object and the architecture of services for the processes;

- An attended modeled method of applications of software that allows the audit in diverse stages of the software life cycle. This method of modeled and verification have in addition special characteristic: (a) it can be used by a development organization, without knowledge on formal methods; (b) it foments the collection and uses a knowledge that is habitually lost; (c) it allows to manage this knowledge with the necessity to integrate it in the source code of the developed programs, and (d) it is not joined to any language of specific development nor any specific intention.

- A system of practical viable verification of components: (a) the tools can be developed with base in network technologies and (b) the necessary basic knowledge fits in the typical profile of the professional software development.

The future pieces will orient the construction of one wikipedia for the administration of taxonomy of patterns and its quality in the BPM domain, along with the specification of the ADL and a prototype of low level that supports the implementation of the methodological proposal through a case of study in the BPM domain.

REFERENCES

[Acosta, Zambrano04] Acosta, E. y Zambrano N.: Patterns and Objects for User Interface Construction, in Journal of Object Technology, vol. 3 no. 3 March-April 2004 pp. 75-90

[Alexander et al.77] Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fidsdahl-King, I., Angel, Sh.: A Pattern Language. Oxford University Press, New York, 1977.

[Bell03] Bell, T.: A BPM Taxonomy: Creating Clarity in a Confusing Market. Gartner Research Note, Technology, T-18-9669. 2003.

[Buschmann et al.96] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., y Stal, M.: Pattern-Oriented Software Architecture: A System of Patterns. Wiley & Sons. 1996.

[Cod, May99] Coad, P., May, M.: JAVA Design: Building Better Apps and Applets. 2nd Edition. Yourdon Press, Upper Saddle River, 1999.

[D’Souza,Wills99] D’Souza, D., y Wills, A.: Objects, Components and Frameworks with UML. The Catalysis approach. Addison-Wesley. 1999.

[Fowler97] Fowler, M.: Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997.

[Gamma et al.95] Gamma, E., Helm, R., Johnson, R., y Vlissides, J.: Design Patterns. Addison Wesley. 1995.

[Jacobson et al.97] Jacobson, I., Griss, M., y Jonsson, P.: Software Reuse. Architecture, Process and Organization for Business Success. Addison-Wesley. 1997.

[Kazman, Klein04] Kazman R., y Klein, M.: Attribute-Based Architectural Styles. Carnegie Mellon Software Engineering Institute Technical

153

Report CMU/SEI-99-TR-022, 2004. [Kazman et al.98] Kazman R., Klein M., Barbacci M., Longstaff T., Lipson H.,

Carriere J.:The Architecture Tradeoff Analysis Method. CMU/SEI-98-TR-008, ESC-TR-98-008. 1998.

[Klein, Kazman99] Klein M. y Kazman R.: Attribute-Based Architectural Styles, CMU/SEI-99-TR-022, ESC-TR-99-022: 1-69. 1999.

[Leite00] Leite, J., Hadad, G., Doorn, J., Kaplan, G.: A Scenario Construction Process, Requirements Engineering Journal,Vol.5, N° 1 2000 pp. 38-61.

[Mahemoff, Johnston98]

Mahemoff, M. y Johnston, L.: Pattern Language for Usability : An Investigation of Alternative Approaches. Asia-Pacific Conference on Human-Computer Interaction (APCHI’98) Proceedings, 25-31. Tanaka, 1998.

[Ridao01] Ridao, M.: Uso de Patrones en el Proceso de Construcción de Escenarios. Tesis Maestría en Ingeniería de Software, Univ. Nacional de La Plata, Noviembre 2001.

[Shaw, Clements96] Shaw M., Clements P.: How Should Patterns Influence Architectural Description Languages? A Call for Discussion. Computer Science Department and Software Engineering Institute Carnegie Mellon University. 1996.

[Van00] Van Welie, M. y Troetteberg, H. Interaction Patterns in User Interfaces. 7th Pattern Language of Programs Conference, August 2000, Illinois, USA, 2000. URL: http://www.cs.vu.nl/~martijn/patterns/index.html

About the author(s) Pedro Bonillo Ramos is a teacher and researcher at the Central University of Venezuela. He obtained his Master in Computer Sciences at the Simon Bolivar University in Venezuela in 2002 and his Master in Business Administration at the Yacambú University in Venezuela in 2004. Currently, he is working on his PhD in Computing Sciences doing research about Software Engineering mainly focusing in Business Process Management. He is also working on his other PhD in Management Sciences doing research about Value Data Maps. He can

be reached at pbonillo@cantv.net Nancy Zambrano Rivas is a teacher and researcher at the Central University in Venezuela. She obtained her Master in Computer Sciences at the Central University of Venezuela in 1989. She obtained her PhD. in Computing Sciences, Informatique at the Laboratoire de Recherche en Informatique (LRI), Université Paris-Sud XI, in 1995. She is researching about Software Engineering (light methods, heavy methods, object-

154

oriented methods, Unified Process, software development methods based on transformations) and Human-Computer Interaction (interaction patterns, tendencies in interface). She can be reached at nzambran@ciens.ucv.ve Alecia Eleonora Acosta is a teacher and researcher at the Central

University of Venezuela. She did a D.E.A d’Informatique at the Université Paris-Sud XI, France, in September 1992. Later, she obtained her Master in Computer Sciences at the Central University of Venezuela in 1993. She obtained her PhD. in Computing Sciences at the Central University of Venezuela in 2004. She is researching about user interface

designs, patterns, usability and socialization of the computation. She can be reached at eacosta@ciens.ucv.ve