Propuesta metodológica para la orientación de aplicaciones informáticas hacia BPM y SOA

Proposed methodology for guidance computer applications to BPM and SOA

Dalilis Escobar-Rivera^1*, Anabel Lisbeth Aguilera-Sánchez ,Yaima de la Caridad Parra-Pompa

¹ Universidad de Holguín “Oscar Lucero Moya”, Avenida XX Aniversario Vía Guardalavaca Reparto Piedra Blanca Holguín

RESUMEN

El papel que juegan los procesos de negocio en una empresa constituye un factor de gran importancia; por lo que eficacia en estos y su agilidad para adaptarse a los cambios internos y externos; proporciona un mayor crecimiento organizacional. Como apoyo existen diversas herramientas para la gestión de procesos. Una de ellas es Gestión de Procesos de Negocio y Arquitectura Orientada a Servicios. Estas se perfilan como una nueva tendencia para aumentar la eficiencia del negocio, generar las ventajas competitivas que exige el mercado, proporcionarles a los procesos de las empresas una simulación para analizar su rendimiento antes de implementarlos, mayor agilidad y flexibilidad, un mejoramiento continuo y supervisión en tiempo real. Aunque el uso de estas tecnologías crece de manera exponencial, en la mayoría de los casos no existe una adecuada metodología para orientar aplicaciones hacia ellas. El presente artículo recoge una propuesta metodológica para la orientación de aplicaciones informáticas a la Gestión de Procesos de Negocio y una Arquitectura Orientada a Servicios.

Palabras clave: Arquitectura Orientada a Servicios, Gestión de Procesos de Negocio, herramientas de Oracle, metodología.

ABSTRACT

The role of business processes in a company is an important factor; so effectively in these and agility to adapt to the internal and external changes; provides greater organizational growth. As there are various tools to support process management. One is Business Process Management and Service Oriented Architecture. These are emerging as a new trend to increase business efficiency, generate competitive advantages that the market demands, to provide business process simulation to analyze their performance before deploying, greater agility and flexibility, continuous improvement and monitoring in real time. Although the use of these technologies is growing exponentially, in most cases there is no appropriate methodology to guide applications to them. This research proposes the development of a methodology for computing the orientation of the Business Process Management and Service Oriented Architecture applications.

Key words: Business Process Management, methodology, Oracle tools, Service Oriented Architecture

INTRODUCCIÓN

La Gestión de Procesos de Negocio (BPM, por sus siglas en inglés) constituye una de las tendencias en cuanto a la gestión por procesos (Figueredo, 2010), que permite manejar de manera sistemática, deliberada y colaborativa, todos los procesos de negocio de una empresa con el objetivo de acelerar la adopción del cambio en la forma de operar de las compañías. Un proceso de tipo BPM no es óptimo si no adopta una Arquitectura Orientada a Servicios (SOA, por sus siglas en inglés). Esta es muy factible a la hora de implementar procesos en los que estén involucradas varias administraciones. Además, es un tipo de arquitectura de software basada en la definición de servicios reutilizables, donde los proveedores y los consumidores interactúan para realizar procesos de negocio. Cuando trabajan juntas BPM proporciona el contexto, la comprensión y las estadísticas del negocio; mientras que SOA facilita una colección ordenada de los elementos básicos de información. De hecho ambas permiten optimizar inversiones, dirigir la excelencia operativa y gestionar el riesgo empresarial de manera dinámica (Weske, 2008).

Independientemente a estos beneficios es lenta la adopción de estas disciplinas debido a que requieren un cambio total en la práctica de procesos en la empresa (Lacambra-Calvet, 2011), el acceso a la bibliografía relacionada con el tema sea limitado, existen pasos para ciertas fases de BPM, pero no están integrados en una única solución (Cánovas, y otros, 2012), existe conflicto entre la visión de BPM como tecnología y la visión BPM del negocio, problema causado a menudo por las limitaciones de algunas de sus herramientas, para pasar de la definición del proceso a su implantación técnica (Gómez-Companys, 2009).

Debido a estas dificultades se propone una metodología para la orientación de productos informáticos hacia la Gestión de Procesos de Negocio y una Arquitectura Orientada a Servicios que permita abarcar el ciclo de vida de BPM, además, que contenga una fase para el diseño de SOA y que posea carácter cíclico; entre otras características.

MATERIALES Y MÉTODOS

Con la integración de BPM y SOA se tiene una arquitectura que consiste de tres niveles básicos, en el nivel más alto, se encuentra la arquitectura BPM, modelándose los procesos de negocio. Estos procesos utilizan servicios de la capa inferior, mientras que este último no tiene que preocuparse de cómo están desarrollados los procesos. Y en una tercera capa las tecnologías usadas (SOA se integra con cualquier tipo de tecnología y lenguaje de programación); formándose tres partes integradas por completo, pero a su vez, independientes entre sí (Gómez-Companys, 2009).
Para el desarrollo de la propuesta se revisaron un grupo de investigaciones (artículos, tesis, reportes y libros) alrededor de BPM y SOA, de las cuales el 65% corresponde a artículos científicos, el 21% a tesis de grado o maestría, el 8% a libros publicados alrededor de este tema y el 6% a reportes. Del análisis de esta documentación se derivan conclusiones parciales con respecto al trabajo con BPM y SOA, de acuerdo a los aspectos mostrados en la Tabla 1.

Aunque existen metodologías para BPM, solo cubren ciertas faces como diseño, modelación e implementación y no les confieren igual relevancia a otras fases, como la optimización. Además, la mayoría de las metodologías no poseen carácter cíclico y existe una gran carencia de casos de estudio que apliquen dichas propuestas. En el estudio de esta literatura se identificaron 33 etapas en las que los autores dividían las metodologías existentes hasta el momento. Para determinar el índice de repetitividad de cada etapa en estas metodologías se realizó un análisis de frecuencia, estableciéndose 3 rangos: 1 a 2 -poco significativo-, de 3 a 4 -medianamente significativo- y de 5 a 6- muy significativo-. Como resultado, se incluyeron en la propuesta metodológica las etapas de: monitoreo y optimización, diseño, implementación y diseño de SOA (en este caso se renombró la etapa) además del modelado de procesos (esta última constituyó la etapa con mayor índice de repetitividad).

Hacer que un modelo de un proceso se convierta en un proceso ejecutable requiere de varias tecnologías. Cuando estas tecnologías se proveen juntas se denominan BPMS (Business Process Management Suite, en inglés). Esta suite incluye plataformas de software que permiten el modelado, despliegue y seguimiento de los procesos de negocio de una organización por parte de desarrolladores, analistas del negocio y administradores del sistema (Díaz-Bazán, y otros, 2009). A continuación, se muestran una comparación (de acuerdo a estándares, licencia y documentación) entre algunas de las herramientas BPMS Ver Tabla 2:

A partir de estos elementos se seleccionó como herramienta para la implementación de la propuesta metodológica la Suite de Oracle 11g en su versión 11.1.1.6.0 para BPM. Esta decisión se fundamenta en base a que es una de las herramientas BPMS más completas que existe y a pesar de ser privativa, es la tecnología usada por la División Datys Holguín (empresa rectora de la investigación). Además permite integrar la colaboración entre analistas del negocio y el arquitecto a partir de herramientas especializadas de diseño y modelado, asegura que el proceso ejecutado sea siempre el proceso modelado y define Indicadores Clave del Rendimiento (KPIs, por sus siglas en inglés), lo cual permite a los propietarios del proceso ver las oportunidades de mejora.

RESULTADOS Y DISCUSIÓN

En el desarrollo de proyectos BPM y SOA, así como en cualquier tipo de proyecto, es necesario seguir una metodología para poder alcanzar los objetivos marcados, de forma alternativa se puede definir la metodología como el estudio o elección de un método pertinente para un determinado objetivo (Pérez-Campdesuñer, 2006). A la hora de utilizar la propuesta metodológica es necesario tener en cuenta una serie de premisas: (1) poseer conocimientos fundamentales en BPM y SOA, (2) contar con personal preparado en BPMN 2.0, BPEL 2.0 y ADF (Oracle Application Development Framework, por sus siglas en inglés) y (3) tener personal calificado para obtener las mejoras adecuadas de cada proceso, para la realización de la metodología de mejora Six Sigma.

La metodología que se describe a continuación tiene como objetivo desarrollar aplicaciones informáticas orientadas a la Gestión de Procesos de Negocio y a una Arquitectura Orientada a Servicios. Contiene una serie de cualidades relevantes entre las que se destaca el carácter cíclico, iterativa, abarca el ciclo de vida de BPM, posee una fase para la construcción de una arquitectura orientada a servicios y especifica el actor(es) que intervienen en cada etapa propuesta. Consta de ocho etapas, en cada una se especifica su objetivo, se describen los pasos a seguir, el momento en el que se desarrolla, el proceso en el que se enmarca y las herramientas y/o métodos a utilizar. Además, se relaciona cada etapa con los actores que intervienen en ella en la Tabla 3.

Etapa 1: Diagnóstico del proceso

El objetivo primordial de esta etapa es logar comprender los procesos de la organización mediante su mapa de procesos. Luego, diseñar el proceso de negocio mediante la identificación de todos sus elementos y fases que lo componen. Asignar tareas a sus responsables y determinar tiempos límite para realizar cada actividad en concreto. Como resultado final de esta etapa se debe obtener un flujo que responda mejor a las necesidades de la empresa, coincidiendo con la etapa de identificación de requisitos del software correspondiente al ciclo de vida del software.

Paso 1: Obtención de requerimientos

Paso 2: Diseño de las actividades

Uno de los factores más importantes para obtener un buen diagnóstico del proceso es el diseño de las actividades, ya que estas corresponden a las diferentes tareas que intervienen en la realización del proceso. Para ello es necesario identificar sus parámetros (entrada y salida), recursos a utilizar, registros generados y realizar una breve descripción de ella; basándose en la plantilla mostrada en la Tabla 5 para documentar la información adquirida.

El aspecto: Descripción (ya sea de los parámetros de entrada o de salida) es un elemento aclaratorio de estos parámetros, es decir, se realiza esta descripción si el analista cree que es necesario describir dichos parámetros para una mejor comprensión de ellos. Si una actividad puede ser catalogada como un proceso (dado que se puede descomponer en 2 o más actividades complejas), entonces se convierte en un subproceso. Este subproceso se define y se describe como una actividad a la hora de identificar las actividades que componen el proceso.

Paso 3: Identificación de Actor

Un actor define el comportamiento o responsabilidades de un individuo o grupo de individuos cuando trabajan en equipo, en el contexto de una organización (Belloso-Cicilia, 2009). Por tanto, cada trabajador de la empresa que realice actividades del proceso o que represente el rol de una o varias personas en un equipo o sistema; es un candidato a actor. Con el objetivo de describir estos actores, es necesario identificarlos, así como su relación con las actividades descritas en el paso anterior. Estos actores pueden coincidir o al menos no entran en contradicción con los actores que se definen a partir de la aplicación de una metodología de desarrollo de software.

Paso 4: Identificación de eventos

Un evento representa situaciones (“algo que sucede”) que afectan al flujo de ejecución de un proceso (Pulier y Teylor, 2006). Por lo general tienen una causa o un resultado. Puede iniciar, interrumpir o detener el proceso, por lo que se dividen en tres tipos: inicio, intermedio y fin. Todos los procesos tienen un evento de inicio y uno de fin, mientras que el intermedio es de acuerdo a las necesidades del proceso. Uno de los pasos a realizar para una posterior modelación es la identificación y descripción de los eventos que intervienen en el proceso, se debe elaborar una tabla donde se listen los eventos, el nombre, tipo, descripción y proceso a que está asociado.

Paso 5: Descripción del proceso de negocio a partir del análisis de BPM

Con el objetivo de describir en términos generales el proceso, desde el punto de vista del producto informático se documentará el nombre, la descripción de dicho proceso, de principio a fin. Además de los objetivos que se quiere alcanzar y la asociación con otros procesos.

Este tipo de diseño es una representación de lo que serán los formularios y pantallas finales de la aplicación. Ellos no representan de forma necesaria el producto final, ya que pueden estar sujetos a cambios durante todo el proyecto. Además, se pueden representar a modo de borrador con cualquier herramienta gráfica. Este paso coincide con la etapa de elaboración de prototipos en algunas metodologías de desarrollo de software basadas en el modelo de prototipos (ejemplo: Iconix) por lo cual existe la posibilidad de fusionarlas en trabajos futuros.

Etapa 2: Modelación del proceso

En esta etapa se modela cada uno de los detalles y especificaciones detectados en la etapa anterior mediante el estándar de modelado BPMN 2.0, obteniéndose como resultado un flujo de trabajo. También se definen las reglas de negocio, donde se especifican las restricciones y condiciones que rigen dicho proceso de negocio. En forma general en esta etapa se utilizará como herramientas Oracle Business Process Architect y Oracle Business Rules Editor, las cuales se enmarcan dentro de Oracle BPA Suite.

Paso 1: Identificación de las reglas de negocio

La tecnología BPM utiliza reglas de forma constante, ya que guían los procesos de negocio hacia una buena ejecución (Villasís-Reyes, 2013). Ellas están accesibles en todo momento para que los directores de negocio las pueden modificar sin cambiar la lógica empresarial. Además, rigen la ruta del flujo de trabajo y alerta a los directores de los eventos. Por ejemplo, si el volumen medio de pedidos alcanza más de dos desviaciones estándar, enviar una alerta al vicepresidente de Finanzas. Para la definición de dichas reglas se utilizará una tabla donde se incluyan nombre, descripción y referencias utilizadas donde se ubican los documentos de referencia para elaborar las reglas de negocio, así como la herramienta Oracle Business Rules Editor.

Paso 2: Elaborar Diagrama de flujo del proceso

El diagrama de flujo de un proceso es una representación gráfica que permite a los Analistas y al Arquitecto de BPM definir procesos y el flujo de información entre ellos, utilizándose para ello la nomenclatura BPMN 2.0. Así mismo, esta funcionalidad permite definir gráficamente el momento en que cada evento, compuerta o actividad debe iniciarse y cuándo debe terminar. Este diagrama se realiza en el modelador de la herramienta BPMS Oracle Business Process Architect, para una posterior implementación y ejecución del proceso de acuerdo a su modelación.

Paso 3: Modelación de las reglas de negocio

De acuerdo a lo anteriormente explicado, las reglas de negocio dirigen la ruta del flujo de trabajo, donde para ello se van a modelar como compuertas (Alonso-Fernández, García-Tosca y Martínez, 2009), (Alonso-Fernández, y otros, 2013). La otra forma de modelación de las reglas de negocio es a través de reglas de negocio, la cual solo permite establecer un parámetro de entrada y otro de salida, solución que no es la más óptima a la hora de definir varios caminos, porque lo ideal sería que en correspondencia el parámetro de entrada se escoja el parámetro de salida. Por tanto, los autores consideran utilizar para modelar estas reglas de negocio, las compuertas. No obstante, se pueden fusionar ambas variantes; cuando una regla solo posea un parámetro de entrada y uno de salida utilizar las reglas de negocio y cuando tenga 2 o más parámetros de salida utilizar las compuertas. Estas compuertas son elementos que representa un punto de decisión en el proceso, compuestas por condiciones, y que en dependencia de ellas, brinda una salida, es decir poseen un flujo único de entrada y varios flujos de salida (Noy-Viamontes, y otros, 2010). Tiene como objetivo determinar decisiones, así como la creación de nuevos caminos, la fusión de estos o la unión. Son de cuatro tipos: exclusiva, inclusiva, paralela y compleja; donde en dependencia del resultado que se quiera obtener, será la compuerta utilizada. Para la modelación de estas reglas se utiliza el modelador de la herramienta Oracle Business Process Architect y la nomenclatura BPMN 2.0.

La idea del diseño de una arquitectura SOA es identificar funcionalidades en un ámbito bien definido y hacerlo accesible de forma uniforme y completa, pero independiente a donde se use. Además, dentro de SOA los servicios incorporan reglas de negocios, información y operaciones. Antes de comenzar a crear estos servicios, es necesario contestar las siguientes 2 preguntas: (1) ¿Qué servicios se requieren? y (2) ¿Qué servicios se deben desarrollar? Para dar respuesta a la primera pregunta es necesario tener en cuenta que la mejor manera de detectar servicios es a partir de la modelación del proceso de negocio. Mientras que en la segunda pregunta hay que determinar para cada servicio detectado, si debe ser desarrollado desde cero o si es posible proveer su funcionalidad a otro servicio o actividad. Para el desarrollo de esta etapa se utilizará las herramientas Oracle Enterprise Service Bus y el Lenguaje de Ejecución de Procesos de Negocio (BPEL, por sus siglas en inglés).

Paso 1: Identificación de servicios

La idea de un servicio es identificar un ámbito bien definido de funcionalidad y hacerlo accesible de forma uniforme y completa, independiente de dónde se use. Para dar respuesta a las anteriores interrogantes planteadas se identifica la necesidad de un servicio mediante la descripción de su funcionalidad, para su posterior modelación e implementación, utilizándose la Tabla 6 En esta ficha se debe definir el nombre del servicio y su descripción, si existe posibilidad de reutilizar algún otro servicio especificar el nombre, así como su fuente (ubicación del servicio a reutilizar).

Paso 2: Modelado de servicios

Los servicios para mantener su independencia, pueden encapsular su lógica dentro de una tarea, subproceso o proceso y establecer relaciones con aquellos que quieren usarlos. Este paso es el siguiente escalón en el perfeccionamiento del modelado del proceso y se realiza en base a la descripción del servicio (paso anterior). La modelación de los servicios se efectúa dentro de la interfaz: Diagrama de flujo del proceso correspondiente a la herramienta de modelado Oracle Business Process Architect con la nomenclatura BPMN 2.0 (herramientas comprendidas dentro de Oracle BPA Suite), ya que este diagrama incluye el flujo en que se efectúan los servicios dentro del proceso.

Paso 3: Implementación de servicios

En este paso se efectúan las funciones que van a llevar a cabo las personas y sistemas dentro de los servicios, de acuerdo al modelado del proceso. Existen 2 formas de implementación de servicios, una es implementarlos como Servicios Web y la otra mediante una llamada a proceso, en la cual se debe seleccionar el proceso que se va a encapsular en el servicio. Esta implementación se realiza en las propiedades del servicio modelado en el proceso, en la opción de implementación, la cual se encuentra dentro de Oracle SOA Suite. Los Servicios Web pueden ser reutilizados mediante la interfaz composite.xml correspondiente a la aplicación en la misma herramienta.

Paso 4: Integración de servicios

Para el desarrollo de la arquitectura SOA se hace necesario conectar los servicios con los que cuenta la organización para lograr un mejor manejo de su seguridad, monitorización y una mayor calidad (en cuanto a tiempo de respuesta y disponibilidad). Para lograr este objetivo se utiliza como tecnología: Oracle Enterprise Service Bus (ESB), el cual es una solución de integración distribuida, basada en los mensajes para conectar servicios (Espinosa-Díaz., 2009). Además, ofrece el eje central de comunicación a nivel empresarial necesario para conectar las aplicaciones o sistemas, de manera fiable a través de múltiples dominios geográficos, administrativos o de seguridad. Esta herramienta se encuentra dentro de Oracle SOA Suite. Cómo último aspecto cabe destacar que la integración permite la reutilización de servicios y con ello la fusión de estos.

La simulación es de las técnicas de probabilidad para predecir la duración promedio de las actividades, de forma tal que se tenga en cuenta la utilización de recursos (Garimella,K., Lees,M., Williams., 2009). Su objetivo principal es detectar fallas de la modelación para determinar un correcto funcionamiento del proceso antes de la implementación del mismo. También se evalúan los servicios definidos en el proceso en todos los escenarios posibles. Para esto se realizan análisis hipotéticos de varias situaciones del mundo real mediante la introducción de combinaciones de variables, que permitan evaluar el comportamiento del proceso; utilizándose como herramienta Oracle Business Process Simulator, la cual se localiza dentro de Oracle BPA Suite. Esta etapa se relaciona con la etapa de diseño de casos de prueba del ciclo de vida del software.

Etapa 5: Implementación

En esta etapa se integran los procesos de negocio como un todo. Se implementa los detalles del proceso de negocio (resultado de la modelación y probado mediante la simulación) puesto a disposición del desarrollador, como asignar funciones a los eventos y definir los parámetros de cada tarea. Como último aspecto se integran al modelo todos los elementos que componen el proceso: personas, sistemas u otros procesos. Además, a través de la implementación se une el diseño con toda la modelación realizada en pasos anteriores mediante la herramienta Oracle Application Development Framework (ADF, por sus siglas en inglés); el cual es un framework utilizado para el desarrollo de aplicaciones Java Enterprise Edition con patrón de diseño Modelo-Vista-Controlador (MVC).

Paso 1: Implementación de actividades y eventos

Las actividades y eventos se implementan en la interfaz correspondiente a sus propiedades, en la pestaña implementación, las cuales se encuentran dentro de Oracle BPA Suite. Las actividades se implementan de acuerdo al tipo de actividad, donde las 3 formas principales de implementación son: si es una tarea humana se realiza mediante la definición de los parámetros de entrada y salida; si es una actividad de llamada se define el proceso que va a encapsular esta actividad y si es de tipo notificación se define a quién se le va a notificar y lo que se le va a decir, aunque existen más tipos de actividades, estas se implementan de una de estas tres formas. En el caso de los eventos, estos se implementan de seis formas principales: mediante la definición una interfaz; el uso de una interfaz ya definida; encapsular una llamada de proceso; encapsular una llamada a servicio; definir una excepción y establecer un ciclo de tiempo para que realice una alerta.

Paso 2: Implementación de las reglas de negocio

Para implementar las reglas de negocio se define la condición que rige la compuerta, donde en dependencia de los parámetros de entrada, es el camino que toma el flujo del proceso. El primer paso para esta implementación es definir en la interfaz correspondiente a las propiedades de la compuerta, en la pestaña orden de salida de flujo (Outflows Order) el camino a seguir por defecto (Nuñez-Jiménez, 2012). El segundo y último paso es definir las condiciones en los restantes caminos (obviándoe el definido por defecto). De esta forma la compuerta puede tomar una decisión lógica en dependencia de las condiciones de cada camino. Es de vital importancia aclarar que las compuertas no realizan ningún trabajo solo ejecutan la lógica. Esta implementación corresponde a Oracle BPA Suite.

Paso 3: Implementación de pantallas y formularios finales

Como último paso se implementa el aspecto visual de la aplicación, de acuerdo al diseño de pantallas y formularios finales realizados en pasos anteriores. Este paso coincide con la etapa de implementación del ciclo de vida del software, para la ejecución de los casos de uso. La implementación se realiza mediante el framework ADF de Oracle.

Una vez implementado el proceso, el mismo se ejecuta por el sistema. Este paso corre de forma total a manos de la herramienta a partir de todo el diseño realizado con anterioridad. Si hay alguna tarea que no se pueda hacer de forma automática, entonces el sistema informa al responsable de efectuarla, donde requiere de su confirmación para continuar con la tarea siguiente. Activa los flujos de trabajo de los usuarios para que cada uno realice las tareas para las cuales son responsables en el momento adecuado, y con el formato y formularios listos para realizar de manera fácil su labor. Si los usuarios llenan de forma incorrecta los formularios, el sistema deberá ser capaz de notificar el error cometido mediante mensajes. Todo esto se gestiona mediante un motor de proceso utilizándose para ello la herramienta Oracle BPEL Process Manager contenida dentro de Oracle SOA Suite, la cual regula que los inicios y finales del proceso funcionen concurrentes, a partir de las reglas del negocio. Además, a partir de esta etapa se recopila la información necesaria en tiempo real para un posterior control y seguimiento del proceso.

Etapa 7: Monitorización

El enfoque basado en BPM pone de manifiesto la importancia de llevar a cabo un seguimiento y medición de los procesos con el fin de analizar los resultados obtenidos a partir de su ejecución. No se puede considerar que un sistema de gestión tenga un enfoque basado en procesos si, a pesar de disponer de un buen diagrama de flujo y una buena implementación del proceso y de SOA, el sistema no se preocupa por conocer sus resultados. Por tanto, este seguimiento constituye la base para saber qué se obtiene, en qué medida se cumplen los resultados deseados y dónde se deben orientar las mejoras. BAM acrónimo de Business Activity Monitoring es la herramienta utilizada para esta actividad: la cual permite detectar los procesos críticos o que sufran una alteración en su funcionamiento, contenida dentro de Oracle SOA Suite.

Paso 1: Indicadores Claves de Rendimiento

Los indicadores clave de rendimiento son mediciones cuantificables utilizadas por una empresa para medir su progreso, basados en sus metas y objetivos. Cuando están siendo monitoreados en tiempo real, pasan a formar parte de la BAM de la empresa. Para realizar esta actividad se utilizará un formato de tabla donde debe reflejarse el nombre del indicador, su descripción (objetivos), la forma de cálculo y frecuencia de cálculo. Los indicadores de negocio varían en dependencia del proceso, por tanto, queda a disposición del usuario de la propuesta metodológica definir estos indicadores. Después de haber identificado estos indicadores con su respectiva descripción se definen en la paleta Request Quote Lab-Structure correspondiente al proceso BPMN. Este paso coincide con la etapa de elaboración de métricas técnicas del software para realizar mediciones del producto.

Paso 2: Monitoreo

Como paso final para cerrar la etapa de monitorización es saber cuál es el comportamiento del proceso a lo largo del tiempo, siendo necesario para ello identificar el grado de variabilidad que los resultados puedan tener; lo cual se logra mediante el monitoreo sistemático de los indicadores que a su vez permitirá tomar decisiones sobre las acciones necesarias para optimizar y mejorar dicho proceso. Para ejecutar estas operaciones se utilizará la herramienta Oracle Business Activity Monitoring, la cual se encuentra dentro de Oracle SOA Suite.

Etapa 8: Optimización

Los datos recopilados del monitoreo y el rendimiento de los procesos deben ser analizados con el fin de conocer las características y la evolución de estos procesos (Diaz-Bazán, Queiruga, Gotelli y Rodríguez, 2009). Del análisis de los datos se debe obtener la información relevante para conocer: (1) qué procesos no alcanzan los resultados esperados, (2) dónde existen oportunidades de mejora. Cuando un proceso no alcanza sus objetivos, la organización deberá establecer las acciones correctivas para asegurar que las salidas del proceso sean conformes a los resultados esperados. También puede ocurrir que, aun cuando un proceso alcance estos resultados, la organización identifique una oportunidad de mejora en dicho proceso por su importancia, relevancia o impacto a nivel global de la organización.

CONCLUSIONES

Al finalizar la investigación se puede afirmar que se realizó un estudio exhaustivo sobre el estado del arte de BPM y SOA, específicamente en metodologías para desarrollar productos informáticos con estas características. Se pudo constatar la inexistencia de una metodología o método que abarque el ciclo de vida de BPM, que contenga una fase para el diseño de SOA y que posea carácter cíclico; entre otras características necesarias. A partir de aquí se desarrolló una propuesta metodológica para la orientación de aplicaciones informáticas hacia BPM y SOA, que cumple con las características necesarias para este fin, constituyendo el objetivo a alcanzar con el desarrollo de la investigación.

REFERENCIAS BIBLIOGRÁFICAS

BELLOSO CICILIA, C.I. “Monografía sobre la Metodología de Desarrollo de Software RUP”. Tesis en opción al Título académico de Graduado en Ciencias de la Computación. Universidad de Bosco, El Salvador, 2009.

CÁNOVAS IZQUIERDO, J.L; SÁNCHEZ RAMÓN, Ó; GARCÍA MOLINA, J; CASTILLO ALARCÓN, C. “Un caso de estudio para la adopción de un BPMS”, 2012.

DIAZ BAZÁN, J; QUEIRUGA P; GOTELLI G. RODRÍGUEZ F. “Entornos para usar BPM en aplicaciones JAVA: un análisis comparativo” XI Workshop de Investigadores en Ciencias de la Computación WICC. Universidad Nacional de San Juan. Argentina, 2009.

ESPINOSA DÍAZ, E. “Propuesta de lmplantación de la Arquitectura BPM/SOA para agilizar la Gestión Comercial en la CNT”. Tesis en opción al Título académico de Máster en Administración Estratégica de Telecomunicaciones. Universidad San Francisco de Quito, Quito, 2009.

GARIMELLA, K; LEES, M; WILLIAMS, B. “Introducción a BPM para DUMMIES”. Indianápolis, Software AG, 2008. 100

GÓMEZ COMPANYS, A. “Estudio de plataformas de procesos de negocio para la tramitación”. Tesis en opción al Título académico de Máster Tecnología de la en Información. Universidad Politécnica de Catalunya, Catalunya ,2009.

GRATEROL, J; HERNÁNDEZ, F; OROZCO, Y. “Herramientas BPMS,” 2012. Disponible en web: http://kuainasi.ciens.ucv.ve/adsi2010-2/HTML_Herramientas_BPMS/BPM.htm.

LACAMBRA CALVET, L. “BPM el futuro de la empresa del siglo XXI,” 2011. Disponible en web: http://www.mkmpi.com/byte-ti/bpm-el-futuro-de-la-empresa-del-siglo-xxi/.

NOY VIAMONTES, P; PÉREZ FERNÁNDEZ, Y; FIGUEROA YONG, J. M; ERMUS BELAUNZARÁN, A; FONNSECA PERAZA, L; MARTÍNEZ. “Guía práctica para la implementación del enfoque BPM y la mejora continua en el CITI”. La Habana, 2010.

NUÑEZ JIMÉNEZ, H. “Desarrollo del proceso de negocio Gestión de no conformidades en el CITI como caso práctico de estudio, mediante Oracle BPM Suite”.  La Habana, 2012.

PÉREZ CAMPDESUÑER, R.  “Modelo y procedimiento para la gestión de la calidad del destino turístico Holguinero”. Tesis en opción al Grado Científico de Doctor en Ciencias Técnicas. Universidad de Holguín “Oscar Lucero Moya”, 2006.

PULIER, E; TAYLOS, H. Understanding Enterprise SOA. Greenwich, Manning Publications Co., 2006. 282

VILLASÍS REYES, J. A. “Metodología para el Análisis, Diseño e Implementaciónde procesos con tecnología BPM (Business Process Management) y desarrollo de un Caso Práctico”. Tesis en opción al Título académico de Máster Tecnología de la en Información. Escuela Politécnica del Ejército, Catalunya, 2013.

Recibido: 18/11/2014
Aceptado: 14/12/2015