PROTOTIPO DE INTEGRACIÓN ENTRE APLICACIONES DE...
55
PROTOTIPO DE INTEGRACIÓN ENTRE APLICACIONES DE SOFTWARE Y LA METODOLOGÍA BPM. CAMILO ANDRES PEREZ VALDERRAMA UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD TECNOLOGICA INGENIERIA EN TELEMÁTICA BOGOTA D.C. 2016
Transcript of PROTOTIPO DE INTEGRACIÓN ENTRE APLICACIONES DE...
PROTOTIPO DE INTEGRACIÓN ENTRE APLICACIONES DE SOFTWARE Y
LA METODOLOGÍA BPM.
CAMILO ANDRES PEREZ VALDERRAMA
UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS
FACULTAD TECNOLOGICA
INGENIERIA EN TELEMÁTICA
BOGOTA D.C.
2016
PROTOTIPO DE INTEGRACIÓN ENTRE APLICACIONES DE SOFTWARE Y
LA METODOLOGÍA BPM.
CAMILO ANDRES PEREZ VALDERRAMA
CODIGO: 20131378004
TRABAJO DE GRADO PARA OPTAR AL TITULO DE
INGENIERO EN TELEMÁTICA
TUTOR: ING. GERARDO CASTANG MONTIEL
UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS
FACULTAD TECNOLOGICA
INGENIERIA EN TELEMÁTICA
BOGOTA D.C.
2016
Nota de Aceptación
__________________________________
__________________________________
__________________________________
__________________________________
__________________________________
__________________________________
_________________________
Firma del Tutor
_________________________
Firma del Jurado
Bogotá D.C. Septiembre de 2016
TABLA DE CONTENIDO
Contenido
1.1 Titulo del trabajo. ...................................................................................................................... 7
1.2 Planteamiento del problema .................................................................................................... 7
1.3 Alcances. .................................................................................................................................... 7
1.4 Objetivos ................................................................................................................................... 8
1.4.1 General ................................................................................................................................... 8
1.4.2 Específicos .............................................................................................................................. 8
1.5 Justificación ............................................................................................................................... 9
1.6 Marco de Referencia ............................................................................................................... 10
1.6.1 Marco teórico. .................................................................................................................. 10
1.6.2 Marco Conceptual ............................................................................................................ 24
1.7 Factibilidad .............................................................................................................................. 28
1.7.1 Técnica ............................................................................................................................. 28
1.7.2 Económica ........................................................................................................................ 29
1.7.3 Operativa .......................................................................................................................... 30
1.8 Cronograma de actividades. .................................................................................................... 31
2 Fase de análisis ........................................................................................................................... 32
2.1 Análisis de Requerimientos ................................................................................................. 32
3 Fase de diseño: ........................................................................................................................... 33
3.1 Diagrama de actividades. .................................................................................................... 33
3.2 Diagrama de Clases. ............................................................................................................ 35
3.3 Diagrama de Estados Tarea. ................................................................................................ 35
3.4 Diagrama de comunicación. ................................................................................................ 36
3.5 Diagrama de secuencia: ....................................................................................................... 37
3.6 Diagrama de componentes: ................................................................................................. 40
3.7 Diagrama de Despliegue: .................................................................................................... 40
4. Fase de Implementación. .......................................................................................................... 41
5. Sistema BPM: Implementación mecanismo de integración procesos BPM api HTTP del BPMS
Bonitasoft ...................................................................................................................................... 43
6. Modelo de abstracción de la gestión de la metodología BPM: ................................................ 46
7. Implementación de microservicios. .......................................................................................... 48
8. Implementar un mecanismo de verificación de la gestión de los procesos BPM: .................... 50
9. Método de integración:............................................................................................................. 50
9. Conclusiones.............................................................................................................................. 52
Referencias: ................................................................................................................................... 53
Resumen: Actualmente es notable encontrar en las organizaciones deficiencias a nivel funcional en
la infraestructura tecnológica que tienen implementada, siendo considerable aún más el que no estén
integradas a la estructura organizacional y a la generación de valor, tanto de la productividad como
del sistema de información; reflejando un nivel de desempeño bajo de los procesos y de las
capacidades operativas, y por lo tanto, no constituye el soporte eficaz del cumplimiento de la misión
empresarial y de sus lineamientos estratégicos. Es por esto que han surgido metodologías que se
enfocan en optimizar procesos de la mano de la gestión tecnológica como lo es la metodología
BPM, la cual ha establecido un marco de trabajo para poder optimizar dichos procesos y alinear la
gestión tecnológica con la misión de la organización, creando un entendimiento mutuo entre todos
los procesos y actores de la organización, estableciendo pautas de monitoreo y mejora continua.
Palabras clave: BPM, Organización, BPMS, Integración, servicios, Procesos
Abstract: Currently is notable deficiencies found in organizations at the functional level at the
technological infrastructure that have implemented, with substantial further that are not integrated
into the organizational structure and value creation, both productivity and information system;
reflecting a low level of process performance and operational capabilities, and therefore, is not the
efficient support of compliance with the corporate mission and strategic guidelines. That is why we
have come methodologies that focus on process optimization of the hand of technology
management as is the BPM methodology, which has established a framework to optimize these
processes and align technology management with the mission organization, creating mutual
understanding among all actors and processes of the organization, establishing guidelines for
monitoring and continuous improvement. This article will show general concepts of BPM and how
it enables integration with technology services organization.
1.1 Titulo del trabajo.
Prototipo de integración entre aplicaciones de software y la metodología BPM.
1.2 Planteamiento del problema
Las organizaciones han entrado en la dinámica de automatizar funciones de su gestión diaria, lo
que ha generado el boom de los “sistemas de información” que son una solución apropiada para lo
que se planteó en el momento o lo que comúnmente se dice “ad hoc” solución para un determinado
fin. Pero qué pasa cuando la tecnología avanza tan rápido y los mercados crecen en ritmo
exponencial, lo que lleva a las organizaciones a entrar en nuevos mercados y enmarcar sus
herramientas de gestión tecnológica en estándares de calidad y repuesta a dichos mercado. En este
escenario las mencionadas soluciones “ad hoc” empiezan a verse obsoletas y se identifican
problemas como lo son: las limitaciones de los sistemas en la adaptación a los nuevos casos de
mercado o peor aún la obsolescencia de los sistemas ya que estos no reflejan en si la totalidad de la
misión de la organización. Esto deja en evidencia un mal levantamiento de los requerimientos de la
aplicación, y por lo tanto evidencia que en la actualidad muchos de los procesos de automatización
de las funciones de las organizaciones hacen parte de un determinado conjunto de tareas y no de la
totalidad de los procesos de la misma.
En el panorama anterior es importante enmarcar Tal como dice [1] “como los modelos actuales no
son suficientes ya que se orientan a tratar temas transaccionales que dejan aparte la integración y
orquestación de los procesos de toda la organización”. En esencia la falta de conocimiento de la
totalidad de los procesos, y la baja automatización de los mismos. Presenta un marco donde es
necesario que las organizaciones establezca un modelo donde se documente la gestión de los
procesos y responsables de los mismos a su vez se describan las relaciones de cada proceso con los
demás lo que permitirá generar puntos de interoperabilidad para la construcción de soluciones
organizacionales y así, resolver la dinámica de los problemas aclarativos en cada etapa del software.
1.3 Alcances.
El siguiente proyecto pretende mostrar un panorama de los sistemas orientados a la gestión de los
procesos en cómo estos optimizan el entendimiento y ejecución de las diferentes tareas de una
compañía y como ayudan a construir soluciones escalables y modulares en una determinada
organización.
La demostración de este prototipo pretende dar a conocer como la integración de las aplicaciones se
puede realizar mediante api expuestas por los proveedores de sistemas BPM que en esta caso es
BonitaBPM, permitiendo a los desarrolladores generar mecanismos de intercambio de datos y así
establecer sistemas de integración y funcionamiento conjunto en pro de la ejecución de un proceso.
Para la demostración de dicho prototipo se pretende la integración de una plataforma BPM, la cual
esta soportada y desarrollada en la herramienta BonitaBPM, con la integración de una aplicación
desarrollada sobre el estándar JEE en su versión 1.7 y a su vez integrada sobre aplicaciones móviles
desarrolladas sobre lenguaje Android bajo la interoperabilidad de la definición de microservicios
expuestos en el ESB Mule. Las limitaciones del sistema residen en la variabilidad y definición de
los procesos que se puedan tomar de base para demostrar los procesos de integración.
1.4 Objetivos
1.4.1 General
Diseñar e implementar un Sistema Telemático bajo el marco de la metodología BPM.
1.4.2 Específicos
Implementar un mecanismo de integración que permita manejar procesos BPM utilizando
el api HTTP del BPMS Bonitasoft.
Planear un modelo de abstracción de la gestión de la metodología BPM en un sistema
telemático.
Implementar un mecanismo de verificación de la gestión de los procesos BPM.
Implementar un conjunto de microservicios que ofrezca la posibilidad de escalar la gestión
BPM a un modelo de integración empresarial.
1.5 Justificación
“El modelo de gestión que comenzó con los grandes comerciantes artesanos (en los años 1700),
que se publicó con Adam Smith, y se formalizó con las teorías administrativas de Frederick Taylor,
Henry Fayol y la práctica de Henry Ford. Fue exitoso, en la era industrial, cuando los monopolios
y oligopolios dominaban los mercados, cuando las comunicaciones eran lentas, cuando las
tecnologías no eran de fácil acceso y cuando las personas (consumidores y clientes) no eran tan
conocedoras de los productos y servicios que los mercados les ofrecían. Fue exitoso, y quizá la
mejor alternativa, pero hoy no lo es.” [3].
Las organizaciones han visto en el modelamiento y gestión de procesos una gran alternativa para
poder minimizar los riesgos y alinear sus planes corporativos con los procesos y la tecnología; esto
lleva a replantear enfoques en el desarrollo de software que en la mayoría fallan porque se enfrenta
a modelos operativos, alejados de la estrategia del negocio. Por ello uno de los principales
objetivos del diseño de sistema orientado a procesos es integrar la administración de procesos con
las herramientas tecnológicas de la organización que permita adaptarse a la industria cambiante.
BPM se define como una metodología que integra herramientas, técnicas y análisis para la gestión
de procesos de negocio y mejora continua. En donde dichos procesos son descritos de forma gráfica
en un ambiente de colaboración entre el campo técnico y la gestión organizacional, en el que se
tiene como meta llegar a la representación de un modelo que permita mostrar algún proceso y como
este se relaciona con los demás, dejando en claro sus responsables y restricciones, y así automatizar
y monitorear el flujo de proceso con el fin de poder establecer pautas de mejora continua [4].
En la mayoría de las organizaciones que han empezado procesos de automatización se evidencia un
conjunto de aplicaciones que trabajan de forma independiente y gestionan diferentes procesos de la
organización, un modelo no muy rentable en términos de efectividad a la hora de evaluar la
interacción usuario-aplicación, ya que en muchos casos los miembros de una organización tienen
que interactuar con más de cinco aplicaciones que le permitan mantener la gestión de la
organización día a día, lo que en muchos escenarios genera factores de error en el paso de una
aplicación a otra y en el peor de los casos trae incongruencia en la integridad total de los datos entre
las distintas aplicaciones para una determinada tarea. Esto se evidencia mucho en las organizaciones
actuales donde es entendible ya que por temas gerenciales, contractuales y de gestión no se
construye una única plataforma para la compañía, sino aplicaciones que van dando solución de
manera independiente, fraccionada y que en su resultado final no interactúan entre sí. Por esto
surge la necesidad de poder establecer un medio de comunicación entre todas ellas. Por ello BPM
busca aplicar el concepto de muchas piezas de software trabajando independientemente
encaminadas a la mejora continua de los procesos de una organización. El cual tiene como pilar
fundamental la optimización de procesos con base a pautas de buena definición de los elementos
que enmarcan la visión de una determinada organización y su escalabilidad e interoperabilidad en
un futuro, lo que permitirá un bajo costo y alto rendimiento en la gestión del objetivo de negocio,
apoyada en su infraestructura tecnológica. Por otro lado se debe ser consciente que en mucho casos
no se debe desarrollar la llamada “automatización de la automatización” todo debe partir de la
documentación y entendimiento de la totalidad de los procesos en donde la implementación
tecnológica debe estar enfocada en definir y crear sistemas flexibles y escalables que comprendan la
idea de negocio y tengan una mejora continua, con reutilización de código adecuado y servicios
bien definidos.
A nivel gerencial se debe representar de forma explícita la estructura de los procesos
organizacionales donde se define actores, roles y la integración de los mismos ya no en un ámbito
de unas cuantas dependencias si no en un proceso trasversal para la organización el cual involucra a
todas las dependencias de la misma, permitiendo que al implementar BPM se establezca
mecanismos de monitoreo, análisis y mejoras en los procesos [2].
1.6 Marco de Referencia
1.6.1 Marco teórico.
BPM:
Business Process Management (BPM) es un conjunto de métodos, herramientas y tecnologías
utilizados para diseñar, representar, analizar y controlar procesos de negocio operacionales. BPM es
un enfoque centrado en los procesos para mejorar el rendimiento que combina las tecnologías de la
información con metodologías de proceso y gobierno. BPM es una colaboración entre personas de
negocio y tecnólogos para fomentar procesos de negocio efectivos, ágiles y transparentes. BPM
abarca personas, sistemas, funciones, negocios, clientes, proveedores y socios. BPM combina
métodos ya probados y establecidos de gestión de procesos con una nueva clase de herramientas de
software empresarial. Ha posibilitado adelantos muy importantes en cuanto a la velocidad y agilidad
con que las organizaciones mejoran el rendimiento de negocio. Con BPM: _ Los directores de
negocio pueden, de forma más directa, medir, controlar y responder a todos los aspectos y
elementos de sus procesos operacionales. _ Los directores de tecnologías de la información pueden
aplicar sus habilidades y recursos de forma más directa en las operaciones de negocio. _ La
dirección y los empleados de la organización pueden alinear mejor sus esfuerzos y mejorar la
productividad y el rendimiento personal. _ La empresa, como un todo, puede responder de forma
más rápida a cambios y desafíos a la hora de cumplir sus fines y objetivos.
La dimensión de negocio es la dimensión de valor y de la creación de valor tanto para los clientes
como para los “stakeholders” (personas interesadas en la buena marcha de la empresa como
empleados, accionistas, proveedores, etcétera). BPM facilita directamente los fines y objetivos de
negocio de la compañía: crecimiento sostenido de los ingresos brutos y mejora del rendimiento
mínimo; aumento de la innovación; mejora de la productividad; incremento de la fidelidad y
satisfacción del cliente y niveles elevados de eficiencia del personal. BPM incorpora más capacidad
que nunca para alinear actividades operacionales con objetivos y estrategias. Concentra los recursos
y esfuerzos de la empresa en la creación de valor para el cliente. BPM también permite una
respuesta mucho más rápida al cambio, fomentando la agilidad necesaria para la adaptación
continua.
El proceso: la dimensión de transformación La dimensión de proceso crea valor a través de
actividades estructuradas llamadas procesos. Los procesos operacionales transforman los recursos y
materiales en productos o servicios para clientes y consumidores finales. Esta “transformación” es
el modo en que funciona un negocio; el elixir mágico de la empresa. Mientras más efectiva sea esta
transformación, con mayor éxito se crea valor. La ciencia aplicada de procesos y transformación
abarca la historia de la gestión industrial moderna. BPM incorpora estas metodologías de forma
completa y las acelera con sistemas de definición, medida, análisis y control mejorados de forma
espectacular. Mediante BPM, los procesos de negocio son más efectivos, más transparentes y más
ágiles. Los problemas se resuelven antes de que se conviertan en asuntos más delicados. Los
procesos producen menos errores y estos se detectan más rápido y se resuelven antes.
La gestión: la dimensión de capacitación La gestión es la dimensión de capacitación. La gestión
pone a las personas y a los sistemas en movimiento y empuja a los procesos a la acción en pos de
los fines y objetivos del negocio. Para la gestión, los procesos son las herramientas con las que se
forja el éxito empresarial. Antes de BPM, construir y aplicar estas herramientas engendraba una
mezcla poco manejable de automatización de clase empresarial, muchas herramientas de escritorio
aisladas, métodos y técnicas manuales y fuerza bruta. Con BPM, puede aunar todos los sistemas,
métodos, herramientas y técnicas de desarrollo de procesos y la gestión de procesos en un sistema
estructurado, completo, con la visibilidad y los controles necesarios para dirigirlo y afinarlo [8].
Ciclo PHVA
El ciclo PHVA o ciclo de Deming fue dado a conocer por Edwards Deming en la década del 50,
basado en los conceptos del estadounidense Walter Shewhart. PHVA significa: Planificar, hacer,
verificar y actuar. En inglés se conoce como PDCA: Plan, Do, Check, Act.
Este ciclo constituye una de las principales herramientas de mejoramiento continuo en las
organizaciones, utilizada ampliamente por los sistemas de gestión de la calidad (SGC) con el
propósito de permitirle a las empresas una mejora integral de la competitividad, de los productos
ofrecidos, mejorado permanentemente la calidad, también le facilita tener una mayor participación
en el mercado, una optimización en los costos y por supuesto una mejor rentabilidad.
Por su dinamismo puede ser utilizado en todos los procesos de la organización y por su simple
aplicación, que si se hace de una forma adecuada, aporta en la realización de actividades de forma
organizada y eficaz.
A través de cada uno de los pasos del ciclo PHVA las empresas pueden:
Planificar: En esta etapa se definen los objetivos y cómo lograrlos, esto de acuerdo a políticas
organizacionales y necesidades de los clientes. Puede ser de gran utilidad realizar grupos de trabajo,
escuchar opiniones de los trabajadores y utilizar herramientas de planificación como por ejemplo:
5W2H en la cual se responden 7 preguntas claves cuyas palabras en inglés inician con W y H :
¿Qué (What), ¿Por qué (Why), ¿Cuándo (When) ¿Dónde (Where) ¿Quién (Who), ¿Cómo (How) y
¿Cuánto (How much).
Hay que recordar que esta etapa es muy importante y es la que permite el desarrollo de las otras, lo
que indica que si no planeamos bien los resultados en las otras 3 etapas no serán confiables.
Hacer: Es ejecutar lo planeado, en esta etapa es recomendable hacer pruebas pilotos antes de
implantar los procesos definidos. En su desarrollo se puede evidenciar los problemas que se tienen
en la implementación, se identifican las oportunidades de mejora y su implementación.
Verificar: En esta etapa comprobamos que se hayan ejecutado los objetivos previstos mediante el
seguimiento y medición de los procesos, confirmando que estos estén acorde con las políticas y a
toda la planeación inicial.
Actuar: Mediante este paso se realizan las acciones para el mejoramiento del desempeño de los
procesos, se corrigen las desviaciones, se estandarizan los cambios, se realiza la formación y
capacitación requerida y se define como monitorearlo.
En conclusión la adopción del ciclo PHVA es de gran ayuda para actuar sobre los procesos y no
sobre las personas, pues es frecuente que en las organizaciones se culpen a los trabajadores por los
malos resultados cuando en realidad lo que falla es el proceso, de ahí la gran importancia que tiene
el compromiso gerencial, pues es en este nivel en donde se deben buscar las estrategias que le
permita a las empresas liderar el mercado, ser auto-sostenibles y rentables.
Requisitos de la mejora continúa
Para su adecuado desarrollo, la mejora continua requiere que se cumplan algunos aspectos en el
ambiente de trabajo, como los que se mencionan seguidamente:
Apoyo en la gestión.
Retroalimentación (Feedback) y revisión de los pasos en cada proceso.
Claridad en la responsabilidad.
Poder de decisión para el trabajador.
Forma tangible de realizar las mediciones de los resultados de cada proceso.
La mejora continua como una actividad sostenible en el tiempo y regular y no como un
arreglo rápido frente a un problema puntual.
Proceso original bien definido y documentado.
Participación de los responsables del proceso.
Transparencia en la gestión.
Cualquier proceso debe ser acordado, documentado, comunicado y medido en un marco
temporal que asegure su éxito.
Proceso Unificado de Desarrollo.
[17] Metodología de desarrollo de software que está basado en componentes e interfaces bien
definidas, y junto con el Lenguaje Unificado de Modelado (UML), constituye la metodología
estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a
objetos.
Es un proceso que puede especializarse para una gran variedad de sistemas de software, en
diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y
diferentes tamaños de proyecto. UP no es un sistema con pasos firmemente establecidos, sino un
conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Principales Elementos
Como UP es un proceso, en su modelación define como sus principales elementos:
Trabajadores (“quién”): Define el comportamiento y responsabilidades (rol) de un
individuo, grupo de individuos, sistema automatizado o máquina, que trabajan en conjunto
como un equipo. Ellos realizan las actividades y son propietarios de elementos.
Actividades (“cómo”): Es una tarea que tiene un propósito claro, es realizada por un
trabajador y manipula elementos.
Artefactos (“qué”): Productos tangibles del proyecto que son producidos, modificados y
usados por las actividades. Pueden ser modelos, elementos dentro del modelo, código
fuente y ejecutables.
Flujo de actividades (“cuándo”): Secuencia de actividades realizadas por trabajadores y que
produce un resultado de valor observable.
Características Principales
Unifica los mejores elementos de metodologías anteriores.
Preparado para desarrollar grandes y complejos proyectos.
Orientado a Objetos.
Utiliza el UML como lenguaje de representación visual.
Principales ventajas
Coste del riesgo a un solo incremento.
Reduce el riesgo de no sacar el producto en el calendario previsto.
Acelera el ritmo de desarrollo.
Se adapta mejor a las necesidades del cliente.
Ciclo de vida:
Dirigido por casos de uso: Los casos de uso reflejan lo que los usuarios futuros necesitan y
desean, lo cual se capta cuando se modela el negocio y se representa a través de los
requerimientos. A partir de aquí los casos de uso guían el proceso de desarrollo ya que los
modelos que se obtienen, como resultado de los diferentes flujos de trabajo, representan la
realización de los casos de uso (cómo se llevan a cabo).
Centrado en la arquitectura: La arquitectura muestra la visión común del sistema completo
en la que el equipo de proyecto y los usuarios deben estar de acuerdo, por lo que describe
los elementos del modelo que son más importantes para su construcción, los cimientos del
sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo
económicamente. UP se desarrolla mediante iteraciones, comenzando por los CU relevantes
desde el punto de vista de la arquitectura. El modelo de arquitectura se representa a través
de vistas en las que se incluyen los diagramas de UML.
Iterativo e Incremental: Una iteración involucra actividades de todos los flujos de trabajo,
aunque desarrolla fundamentalmente algunos más que otros.
Flujo de Trabajo
Se han agrupado las actividades en grupos lógicos definiéndose 9 flujos de trabajo
principales, los 6 primeros son conocidos como flujos de ingeniería y los tres últimos como
flujos de apoyo.
Modelo del Negocio: Describe los procesos de negocio, identificando quiénes participan y
las actividades que requieren automatización.
Requerimiento: Define qué es lo que el sistema debe hacer, para lo cual se identifican las
funcionalidades requeridas y las restricciones que se imponen.
Análisis y Diseño: Describe cómo el sistema será realizado a partir de la funcionalidad
prevista y las restricciones impuestas (requerimientos), por lo que indica con precisión lo
que se debe programar.
Implementación: Define cómo se organizan las clases y objetos en componentes, cuáles
nodos se utilizarán y la ubicación en ellos de los componentes y la estructura de capas de la
aplicación.
Prueba (Testeo): Busca los defectos a los largo del ciclo de vida.
Instalación o despliegue: Produce release del producto y realiza actividades (empaque,
instalación, asistencia a usuarios, etc.) para entregar el software a los usuarios finales.
Administración del proyecto: Involucra actividades con las que se busca producir un
producto que satisfaga las necesidades de los clientes.
Administración de configuración y cambios: Describe cómo controlar los elementos
producidos por todos los integrantes del equipo de proyecto en cuanto a:
utilización/actualización concurrente de elementos, control de versiones, etc.
Ambiente: Contiene actividades que describen los procesos y herramientas que soportarán
el equipo de trabajo del proyecto; así como el procedimiento para implementar el proceso
en una organización.
Fases
Cada fase representa un ciclo de desarrollo en la vida de un producto de software:
La fase de concepción o inicio: tiene por finalidad definir la visión, los objetivos y el
alcance del proyecto, tanto desde el punto de vista funcional como del técnico,
obteniéndose como uno de los principales resultados una lista de los casos de uso y una
lista de los factores de riesgo del proyecto. El principal esfuerzo está radicado en el
Modelamiento del Negocio y el Análisis de Requerimientos. Es la única fase que no
necesariamente culmina con una versión ejecutable.
La fase de elaboración tiene como principal finalidad completar el análisis de los casos de
uso y definir la arquitectura del sistema, además se obtiene una aplicación ejecutable que
responde a los casos de uso que la comprometen. A pesar de que se desarrolla a
profundidad una parte del sistema, las decisiones sobre la arquitectura se hacen sobre la
base de la comprensión del sistema completo y los requerimientos (funcionales y no
funcionales) identificados de acuerdo al alcance definido.
La fase de construcción está compuesta por un ciclo de varias iteraciones, en las cuales se
van incorporando sucesivamente los casos de uso, de acuerdo a los factores de riesgo del
proyecto. Este enfoque permite por ejemplo contar en forma temprana con versiones el
sistema que satisfacen los principales casos de uso. Los cambios en los requerimientos no
se incorporan hasta el inicio de la próxima iteración.
La fase de transición se inicia con una versión “beta” del sistema y culmina con el sistema
en fase de producción.
Android:
Android es un sistema operativo inicialmente pensado para teléfonos móviles, al igual que iOS,
Symbian y Blackberry OS. Lo que lo hace diferente es que está basado en Linux, un núcleo de
sistema operativo libre, gratuito y multiplataforma.
El sistema permite programar aplicaciones en una variación de Java llamada Dalvik. El sistema
operativo proporciona todas las interfaces necesarias para desarrollar aplicaciones que accedan a las
funciones del teléfono (como el GPS, las llamadas, la agenda, etc.) de una forma muy sencilla en un
lenguaje de programación muy conocido como es Java.
Los componentes principales del sistema operativo de Android:
Aplicaciones: las aplicaciones base incluyen un cliente de correo electrónico, programa de
SMS, calendario, mapas, navegador, contactos y otros. Todas las aplicaciones están escritas
en lenguaje de programación Java.
Marco de trabajo de aplicaciones: los desarrolladores tienen acceso completo a los mismos
APIs del framework usados por las aplicaciones base. La arquitectura está diseñada para
simplificar la reutilización de componentes; cualquier aplicación puede publicar sus
capacidades y cualquier otra aplicación puede luego hacer uso de esas capacidades (sujeto a
reglas de seguridad del framework). Este mismo mecanismo permite que los componentes
sean reemplazados por el usuario.
Bibliotecas: Android incluye un conjunto de bibliotecas de C/C++ usadas por varios
componentes del sistema. Estas características se exponen a los desarrolladores a través del
marco de trabajo de aplicaciones de Android; algunas son: System C library
(implementación biblioteca C estándar), bibliotecas de medios, bibliotecas de gráficos, 3D
y SQLite, entre otras.
Runtime de Android: Android incluye un set de bibliotecas base que proporcionan la mayor
parte de las funciones disponibles en las bibliotecas base del lenguaje Java. Cada aplicación
Android corre su propio proceso, con su propia instancia de la máquina virtual Dalvik.
Dalvik ha sido escrito de forma que un dispositivo puede correr múltiples máquinas
virtuales de forma eficiente. Dalvik ejecuta archivos en el formato Dalvik Executable
(.dex), el cual está optimizado para memoria mínima. La Máquina Virtual está basada en
registros y corre clases compiladas por el compilador de Java que han sido transformadas al
formato.dex por la herramienta incluida "dx".
Núcleo Linux: Android depende de Linux para los servicios base del sistema como
seguridad, gestión de memoria, gestión de procesos, pila de red y modelo de controladores.
El núcleo también actúa como una capa de abstracción entre el hardware y el resto de la pila
de software.
JEE:
Java Platform, Enterprise Edition (Java EE) es el estándar en software empresarial impulsado por la
comunidad. Java EE se desarrolla utilizando la Java Community Process, con las aportaciones de
expertos de la industria, organizaciones comerciales y de código abierto, Java User Group, y un
sinnúmero de personas. Cada versión integra nuevas características que se alinean con las
necesidades de la industria, mejora la portabilidad de las aplicaciones y aumenta la productividad
del desarrollador.
El modelo de aplicación Java EE comienza con el lenguaje de programación Java y la
Máquina virtual de Java. La portabilidad, seguridad y productividad de los desarrollos demostrado
que JEE proporcionar formar la base de la aplicación de un modelo robusto. Java EE está diseñado
para soportar aplicaciones que implementan servicios de la empresa para los clientes, empleados,
proveedores, socios y otras personas que hacen demandas sobre o contribuciones a la empresa.
El modelo de aplicación Java EE define una arquitectura para la implementación de servicios como,
aplicaciones de múltiples niveles que ofrecen la escalabilidad, accesibilidad y capacidad de
administración.
La plataforma Java EE utiliza un modelo de aplicación de varios niveles distribuido por la empresa
Componentes de cliente de nivel se ejecutan en la máquina cliente.
Componentes de nivel Web se ejecutan en el servidor Java EE.
Componentes de la capa de negocio se ejecutan en el servidor Java EE.
Figura 1: Arquitectura JEE.
Fuente: https://docs.oracle.com/javaee/7/tutorial/overview003.htm
Microservicios Java
El término "Arquitectura de Microservicio” ha surgido en los últimos años para describir una forma
particular de diseñar aplicaciones de software suites, como de los servicios de forma independiente
desplegables. Si bien no existe una definición precisa de este estilo arquitectónico, hay cierta
característica común en torno a la organización en torno a la capacidad del negocio, el despliegue
automatizado, la inteligencia en los puntos finales, y el control descentralizado de Los lenguajes y
bases de datos.[14]
Una aplicación Java EE monolítica se define normalmente en un archivo .war o .ear. Toda la
funcionalidad de la aplicación se concentra y empaqueta en una sola unidad.. Todas las páginas web
están la raíz de la aplicación, todas las clases Java se encuentran dentro de WEB-INF/classes y los
recursos dentro de /META-INF, algunas de las reglas en común para poder empezar a tratar temas
de división de aplicación es entender reglas en común como lo son:
Separación de los aspectos de funcionalidad, por ejemplo utilizando MVC.
Alta cohesión y bajo acoplamiento utilizando APIs bien definidas.
No repetirse así mismo (DRY - Don't Repeat Yourself)
API de Interfaces e implementaciones por separados y aplicando la Ley de Deméter, Las
clases no llaman a otras clases directamente, ya que se encuentran en el mismo archivo.
El uso de Diseño Guiado por Dominio para mantener objetos relacionados entre dominio y
componente.
YAGNI o: No hacer algo que no se necesita ahora.
En resumen, la arquitectura de microservicios es una aproximación al desarrollo de una sola
aplicación como un conjunto de servicios pequeños, cada uno que se ejecuta en su propio proceso y
la comunicación con los mecanismos de peso ligero, a menudo una API recurso HTTP. Estos
servicios se basan en el negocio de las capacidades de despliegue totalmente automatizados y
maquinaria de forma independiente de despliegue. Hay un mínimo de una gestión centralizada de
los hilos de servicios, que puede estar escrito en diferentes lenguajes de programación y el uso de
diferentes tecnologías de almacenamiento de datos.
Microservicios es útil compararlo con el estilo monolítico en el desarrollo de software: una
aplicación monolítica construida como una sola unidad. Las aplicaciones empresariales se
construyen a menudo en tres partes principales: una interfaz de usuario del lado del cliente
(Consiste de páginas HTML y JavaScript que se ejecuta en un navegador en el ordenador del
usuario), una base de datos (que consta de muchos cuadros insertados en una, gestión de base de
datos común, y por lo general relacional sistema), y una aplicación del lado del servidor. La
aplicación del lado del servidor se encargará de las peticiones HTTP, ejecutar la lógica de dominio,
recuperar y actualizar datos de la base de datos y seleccionar y rellenar los puntos de vista de
HTML que se envía al navegador. Esta aplicación del lado del servidor es un monolito - un único
ejecutable lógico. Cualquier cambio en el sistema consiste en la construcción y despliegue de una
nueva versión de la aplicación del lado del servidor.
Un servidor monolítico es una forma natural de acercarse a la construcción de la mayoría de
sistemas de software. Toda la lógica para manejar una petición se ejecuta en un solo proceso,
permitiendo que el que utilice las funciones básicas de la aplicación para dividir el proceso en
clases, funciones y espacios de nombres. Con un poco de cuidado, puede ejecutar y probar la
aplicación en la computadora portátil de un desarrollador, y el uso de una tubería de
implementación para asegurar que los cambios que se están debidamente probados y desplegados
en la producción. Puede escalar horizontalmente el monolito ejecutando muchos casos detrás de un
equilibrador de carga. Aplicaciones monolíticas pueden tener éxito, pero cada vez más personas
están sintiendo frustración con ellos - especialmente a medida que más aplicaciones se están
desplegando a la nube. En muchos casos un cambio realizado en una pequeña parte de la
aplicación, requiere todo el monolito que ser reconstruida y desplegado. Con el tiempo, a menudo
es difícil mantener una buena estructura modular, por lo que es más difícil mantener los cambios
que deberían afectar a un solo módulo dentro de ese módulo. Escalamiento requiere descamación de
toda la aplicación en lugar de partes que requieren gran recurso [15]:
Ventajas de una arquitectura basada en microservicios [16]:
Combinar los servicios como nos interesen. Incluso, reutilizarlos para distintos uso dentro
de la empresa. Como piezas de puzzle podemos crear aplicaciones que usen una misma
lógica de negocio sin estar cautiva en una aplicación monolítica.
Escalar a nivel de microservicios. Cada uno de ellos expone una funcionalidad, así
podemos distribuirlo según nuestras necesidad pensando en la demanda y el balanceo de
carga de cada aplicación. Esto contrapone la idea poco eficiente de replicar aplicaciones
enteras cargadas de funcionalidad por unas pocas que represente la mayor carga.
Simplificamos el mantenimiento. Cumplen a la perfección el principio SOLID. Podemos
desechar componentes que no reutilizando o extenderlos en otros para engancharlo en
nuestra aplicación. Es más fácil tirar algo que no usemos a la basura que mantenerlo como
código legacy dentro de una aplicación monolítica.
Su fallo no arrastra a todo el sistema. Si un componente no funciona correctamente no
afecta al resto. Se puede aislar y manejar el error, desplegando por separado.
El despliegue puede ser progresivo sin parar todo de golpe. Empezamos a ver más luz a la
integración continua alcanzando mayores cifras de disponibilidad. Aunque recuerda que
esto implica que ya no tienes un único contenedor, sino que hay que estar pendiente de n
contenedores de aplicaciones.
Bus De Servicios:
Cuando se habla de arquitecturas orientadas a servicios, se habla intrínsicamente de los
componentes necesarios para tener una arquitectura SOA. Sin duda alguna, uno de los componentes
más importantes de una arquitectura orientada a servicios es el Enterprise Service Bus - ESB.
Conforme las organizaciones van moviéndose hacia las arquitecturas orientadas a servicios, se dan
cuenta que están trabajando con un “mix” entre lo nuevo y lo viejo. Un ESB es básicamente la
integración de lo nuevo y lo viejo, brindándo un lugar central para los servicios, las aplicaciones, y
recursos de TI en general que se desean conectar. En otras palabras, lo que se busca es una
infraestructura y un sistema de eventos que me permitan conectar cualquier recurso de TI sin
importar la tecnología que utiliza el recurso. Esta infraestructura debería permitir administrar los
cambios en los requerimientos sin causar problemas a los servicios ya instalados. Esta
infraestructura debe de ser confiable y robusta. Aquí es donde entra el concepto de ESB.
Un ESB no solamente permite combinar y re ensamblar servicios, sino que también debe permitir
conectar nuevas aplicaciones, servicios web y cualquier otro tipo de aplicaciones tales como
aplicaciones LOB ( Line of Business ), archivos batch, legacy middleware a través de adaptadores;
todo esto manteniendo la abstracción del manejo de mensajes a través del patrón publicar-suscribir.
Funcionalidades ESB.:
Transparencia de Ubicación: El ESB ayuda a desligar el consumidor del servicio de la
ubicación del proveedor del servicio. El ESB provee una plataforma central para
comunicarse con cualquier aplicación requerida sin ligar el recibidor del mensaje con el que
envía el mensaje.
Conversión de Protocolo de Transporte: Un ESB debe de tener la capacidad de integrar de
forma transparente a través de diferentes protocolos de transporte tales como HTTP(s),
JMS, FTP, SMTP, TCP, etc.
Transformación de Mensaje: El ESB brinda funcionalidad para transformar mensajes desde
un formato hasta otro formato basado en estándares tales como XSLT y XPath.
Ruteo de Mensajes: El ESB determina el destino de los mensajes entrantes.
Mejora del Mensaje: El ESB puede brindar funcionalidad para agregar información faltante
basada en los datos del mensaje de entrada.
Seguridad: Autenticación, autorización, y funcionalidad de encriptación se proveen a través
del ESB para asegurar los mensajes entrantes. Igualmente estas funcionalidades se aplican a
mensajes salientes para satisfacer requerimientos de seguridad del proveedor del servicio a
consumir.
Monitoreo y Administración: Un ambiente de monitoreo y administración del ESB es
fundamental para configurar el ESB para que sea confiable y tenga un alto desempeño; al
mismo tiempo, nos permite monitorear la ejecución de los mensajes y su flujo dentro del
ESB.
Mule y otros ESBS ofrecen un valor real en escenarios en los que hay al menos unos pocos puntos
de integración o, al menos, 3 aplicaciones para integrar. También son muy adecuadas para
escenarios donde se requiere la articulación flexible, escalabilidad y robustez.
A continuación se muestra una lista de selección rápida ESB, donde se enumeran factores a
considerar en una integración ESB:
1. ¿se integrara tres o más aplicaciones / servicios?
2. ¿Será necesario que conecte más aplicaciones en el futuro?
3. ¿Es necesario utilizar más de un tipo de protocolo de comunicación?
4. ¿Necesita capacidades de enrutamiento de mensajes, como se bifurcan y de agregar los flujos de
mensajes, o encaminamiento basado en el contenido?
5. ¿Necesita publicar servicios para el consumo por otras aplicaciones?
1.6.2 Marco Conceptual
BonitaBPM:
Para el desarrollo de este modelo de integración se ha seleccionado la herramienta de diseño BPM
llamada BonitaBPM en su versión comunity y para el desarrollo de la aplicación se ha seleccionado
el lenguaje JAVA en su edición JEE.
BonitaBPM es una suite ofimática para la Gestión de procesos de negocio (BPM) y realización de
Workflows, creada en 2001. Es código abierto y puede ser descargado bajo GPL v2. Su desarrollo
comenzó en el National Institute for Research in Computer Science, y entonces ha estado en
proceso de incubación varios años dentro de la compañía científica francesa Bull. Desde 2009, el
desarrollo de Bonita está soportado por una empresa dedicada a esta actividad: Bonitasoft.
Bonitasoft se ha expandido más allá de su base en el mercado de EMEA para satisfacer mejor la
creciente demanda global. En octubre de 2010 abrió su primera oficina en América del Norte (San
Francisco).
Características:
Diseño:
Tiene todo lo que se necesita para construir potentes aplicaciones basadas en procesos, desde el
modelado del proceso en BPMN 2.0 al igual que un editor de interfaces.el cual permite adaptar la
plaicacion a las necesidades de las organizaciones.
Modelamiento de la mano del cliente:
Modelar procesos con el sencillo editor gráfico
Asignar actores y mapearlos con la organización para gestionar asignaciones
Gestionar los datos complejos de manera sencilla con el sistema de gestión de datos de
negocio
Colabora usando el repositorio compartido de procesos
Conectar y personalizar:
Simplificar la integración con sistemas externos. Al permitir conectarse con prácticamente
cualquier sistema empresarial directamente - CRMs, ECMs, ERPs, bases de datos y más, Creacion
de conectores con un framework extensible y las herramientas de integración fácilitan a través de
las APIs disponibles y extensibles mediante Java o REST.
Apache Córdova:
Apache Córdova es un marco de desarrollo móvil de código abierto. El cual Permite utilizar las
tecnologías estándar web como HTML5, CSS3 y JavaScript para desarrollo multiplataforma,
evitando el lenguaje de desarrollo nativo cada plataforma móvil. Las Aplicaciones se ejecutan
dentro de envolturas para cada plataforma y dependen de enlaces estándares (API) para acceder a
cada dispositivo sensores, datos y estado de la red.
Apache Córdova se graduó en octubre de 2012 como un proyecto de nivel superior dentro de la
Apache Software Foundation (ASF). A través del ASF, el futuro desarrollo por Cordova asegurará
administración abierta del proyecto ya que Siempre permanecerá libre y de código abierto bajo la
licencia Apache, versión 2.0. Usar Apache Cordova permite:
establecer una aplicación móvil desarrollada y extender la misma a varias plataformas, sin
tener que re implementarse para cada una.
un desarrollo enfocado a lenguaje web el cual brinda un estándar en el desarrollo de las
aplicaciones móviles.
Un desarrollo enfocado a la apariencia visual enriquecida gracias a su interacion con css y
jquery mobile
En la siguiente imagen se muestra la arquitectura de Apache Córdova, en cual se muestra el
proceso de renderizacion de un lenguaje web, a una plataforma movil
Figura 2: arquitectura Cordova
Fuente: http://cordova.apache.org/docs/en/latest/guide/overview/index.html
Componentes básicos
Apache Cordova se basan en un archivo común config.xml archivo que proporciona información
acerca de la aplicación y especifica los parámetros que afectan a cómo funciona, como si responde a
la orientación en cada plataforma. Este archivo se adhiere a la especificación de Empaquetado de la
aplicación Web, widget, o de la W3C.
La misma aplicación se implementa como una página web, un archivo local llamado index.html,
que hace referencia a cualquier CSS, JavaScript, imágenes, archivos multimedia u otros recursos
son necesarios para que se ejecute de forma predeterminada. La aplicación se ejecuta como
un WebView dentro de la envoltura de la aplicación nativa, que distribuye a tiendas de aplicaciones.
El WebView Cordova-habilitado puede proporcionar la aplicación con su interfaz de usuario
completa. En algunas plataformas, también puede ser un componente dentro de una aplicación
híbrida más grande, que mezcla la vista Web con componentes de la aplicación nativa.
Una interfaz plugin está disponible para Cordova y componentes nativos para comunicarse con los
demás. Esto te permite invocar un código de JavaScript. Idealmente, las API de JavaScript para ese
código nativo son consistentes a través de múltiples plataformas de dispositivos. A partir de la
versión 3.0, las extensiones proporcionan enlaces a APIs estándar. Plugins de terceros proporcionan
enlaces adicionales a funciones no necesariamente disponibles en todas las plataformas. En apache
cordova existen dos formas de desarrollar una aplicación móvil:
Flujo de trabajo multiplataforma (CLI): este flujo de trabajo se utiliza para ejecutar en los
sistemas operativos móviles como sea posible, con poco necesidad específica de la
plataforma nativa de desarrollo. Este flujo de trabajo se centra en la cordova utilidad,
también conocido como el CLI, que fue introducido con 3.0 Cordova Cordova. El CLI es
una herramienta de alto nivel que permite construir proyectos para muchas plataformas a la
vez, muy lejos de la funcionalidad de scripts de shell de bajo nivel de abstracción. La CLI
copia un conjunto común de web activos en subdirectorios para cada plataforma móvil,
hace que cualquier cambio de configuración necesarias para cada uno, construir secuencias
de comandos para generar los binarios de la aplicación ejecuta. La CLI también
proporciona una interfaz común para aplicar plugins para su aplicación.
Flujo de trabajo centrado en plataforma: este flujo de trabajo se utiliza en la construcción de
una aplicación para una sola plataforma y necesitan poder modificarlo en un nivel inferior..
Como regla general, se utiliza este flujo de trabajo si se modifica el proyecto dentro del
SDK. Este flujo de trabajo se basa en un conjunto de scripts de shell de nivel inferior que se
adaptan para cada plataforma soportada y una utilidad de Plugman separada que le permite
aplicar plugins. Mientras este flujo de trabajo puede utilizar para crear aplicaciones
multiplataforma, es generalmente más difícil porque la falta de una herramienta de alto
nivel significa construir diferentes ciclos y modificaciones de plugin para cada plataforma.
Aún así, este flujo de trabajo permite un mayor acceso a opciones de desarrollo
proporcionadas por cada SDK.
ESB Mule.
[20] Mula, es un motor en tiempo de ejecución de la plataforma AnyPoint, es un ligero bus de
servicio empresarial basada en Java (ESB) en donde se brinda una plataforma de integración que
permite a los desarrolladores de aplicaciones conectarse de forma rápida y fácil, lo que les permite
intercambiar datos. Es de fácil integración con los sistemas existentes, independientemente de las
tecnologías que las diferentes aplicaciones de usuario manejen, incluyendo JMS, Servicios Web,
JDBC, HTTP, y mucho más. La ESB puede ser desplegada en cualquier lugar, se puede integrar y
orquestar los eventos en tiempo real o por lotes, y tiene conectividad universal.
La principal ventaja de un ESB es que se han encontrado diferentes integraciones para comunicarse
entre sí, actuando como un sistema de transporte de datos entre las aplicaciones dentro de la
empresa o a través de Internet. Mule tiene capacidades de gran alcance que incluyen:
Creación de servicios y hosting : exponer servicios reutilizables, utilizando el ESB como un
contenedor de servicio ligero
La mediación de servicios: servicios de blindaje de formatos y protocolos de mensajes, la
lógica de negocio separada de mensajería, y permitir que las llamadas de servicio
independientes de la ubicación
Transformación de datos - el intercambio de datos a través de diferentes formatos y
protocolos de transporte
Enrutar mensajes, filtrar, agregar, y re-secuencia basada en contenido y las reglas - el
enrutamiento de mensajes
Mule es ligero y altamente escalable, permitiendo que el que empezar poco a poco y se conecta más
aplicaciones a través del tiempo. La ESB gestiona todas las interacciones entre las aplicaciones y
los componentes de forma transparente, independientemente de si existen en la misma máquina
virtual o a través de Internet, y con independencia del protocolo de transporte subyacente utilizado.
Existen varias implementaciones comerciales ESB actualmente en el mercado. Sin embargo,
muchos proveen la funcionalidad limitada de la misma los cuales se construyen en la parte
superior de un servidor de aplicaciones o de mensajería existente, lo encadenan a un vendedor
específico. Mula es independiente del proveedor, por lo que diferentes implementaciones de otros
proveedores pueden conectar a ella. Nunca estamos encerrados en un proveedor específico cuando
se utiliza Mule.
Primefaces:
PrimeFaces es una librería de componentes visuales open source desarrollada y mantenida por
Prime Technology, una compañía Turca de IT especializada en consultoría ágil, JSF, Java EE y
Outsourcing. Las principales características de Primefaces son:
soporte nativo de Ajax, incluyendo Push/Comet.
kit para crear aplicaciones web para móviles.
es compatible con otras librerías de componentes, como JBoss RichFaces.
uso de javascript no intrusivo (no aparece en línea dentro de los elementos, sino dentro de
un bloque <script>).
es un proyecto open source, activo y bastante estable entre versiones.
1.7 Factibilidad
1.7.1 Técnica
El diseño de este prototipo permitirá integrar metodologías de desarrollo e integración optimas al
permitir a los clientes y desarrolladores de software entender las necesidades de los proyecto y
elaborar aplicaciones encaminadas a la visión de la compañía que estén acordes a las tecnologías
disponibles y en tiempos razonables de implementacion.
Para el desarrollo de la aplicación se utilizaran las siguientes herramientas y lenguajes de
programación los cuales están disponibles en internet de forma gratuita además cuenta con bastate
documentación oficial para su uso y manejo:
Java versión "1.7.0_75".
Android 5.1 lollipop.
BonitaBPM 6.5
Jboss 7.1
Mule versión community
Apache Cordova
1.7.2 Económica
Costo de personal: el porcentaje de trabajo diario en jornada de 8 horas 5 días a la semana.
Costo Hora de trabajo Ingeniero: 16.000
Costo día de trabajo Ingeniero: 128.000
Costo mes ingeniero: 3.072.000
Costo equipos:
Equipo desarrollo
Procesador COREI 5
Almacenamiento Disco Duro 1 TB
Memoria Memoria 4 GB
Monitor Monitor 19.5''
Total $1.520.000
Costo software: las herramientas necesarias para la construcción del prototipo no requieren de
ningún costo por licencia.
Java versión "1.7.0_75". Licencia open source.
Android 5.1 lollipop. Licencia Apache 2.0 y GNU GPL 28.
Jboss AS 7.1 Licencia GNU.
Mule versión community
Apache Cordova
BonitaBPM 6.5 Licencia Community, listado de criterios elección BonitaBPM
Herramienta Oracle BPM
Suite
Bonita BPM Bizagi
Licencia Desde $115 Versión
Comunnity
Desde $311
Suite de estudio SI SI SI
Notación BPMN si si si
Comunidad de
discusión
herramienta
no si si
1.7.3 Operativa
El desarrollo prototipo permite conceptualizar la necesidad de establecer flujos organizados que
interactúen y asignen responsabilidad en cada uno de los procesos de las organizaciones. Los
sistemas integrados bajo la metodología BPM permiten gestionar y organizar flujos de procesos en
las organizaciones para así poder visualizar posibles interacciones entre los diferentes sistemas
donde la integración, control y monitoreo de muchas aplicaciones se debe de recalcar en pro de
mantener e implementar un proceso de mejora continua. Desde que se planteó la necesidad de
integrar las diferentes aplicaciones de un entorno se produjo la incursión de los servicios web y la
arquitectura orientada a servicios en donde el intercambiar información entre las diversas
aplicaciones por medio de diferentes protocolos es el principio fundamental de la interoperabilidad
y gestión conjunta de sistemas.
1.8 Cronograma de actividades.
2 Fase de análisis
2.1 Análisis de Requerimientos
El desarrollo de este prototipo está enfocado en la posibilidad de implementar características de la
metodología BPM en procesos de desarrollo de software, con el fin de poder generar aplicaciones
que estén enfocadas a los lineamientos y procesos de los entornos para los que son diseñados,
permitiendo alinear las herramientas de software con los planes corporativos de las organizaciones.
Al comprender este panorama se plantea la idea de permitir gestionar un modelo que permita
integrar una óptima gestión de procesos y aplicaciones de software es aquí donde surge la idea de
crear un mecanismos que permitiese integrar una capa de negocios, capa de presentación, capa de
datos en pro de poder alimentar un modelo de procesos ya establecido sin perder la modularidad e
integridad de las aplicaciones de software encaminadas a la mejora continua de los procesos de una
organización. Este marco permite entender la necesidad de establecer flujos organizados que
interactúen y asignen responsabilidad en cada uno de los procesos de las organizaciones. Donde se
tenga control y monitoreo de muchas aplicaciones y responsables de las mismas.
Para demostrar este modelo de datos se ha tomado como referencia un proceso del extinto
Ministerio de la protección social, dicho proceso permitía a las organizaciones y agremiaciones
colectivas afiliarse al sistema de la protección social. En dicho proceso de afiliación se ve la
necesidad de integrar un mecanismo de radicación de los datos de las entidades y envió por parte de
estas de la documentación necesaria para dicho proceso de afiliación al personal encargado de
gestionar dicho proceso.
3 Fase de diseño
Desarrollando la metodología UP en la implementación del sistema de integración BPM, se
evidencia la necesidad de implementar un modelo de abstracción y control de todos los elementos
relacionados en la gestión de los procesos, es por ello que se realiza un análisis de los actores y
elementos que conformaran el sistema para así asignar responsabilidades únicas a cada elemento e
identificar los posibles subsistemas que puedan aparecer.
3.1 Diagrama de actividades.
3.1.1 consultar Tareas.
Fuente: Elaboración Propia
3.1.2 Registrar Tarea
Fuente: Elaboración Propia
3.2 Diagrama de Clases.
Fuente: Elaboración Propia
3.3 Diagrama de Estados Tarea.
Fuente: Elaboración Propia
3.4 Diagrama de comunicación.
3.4.1 login aplicación web
Fuente: Elaboración Propia
3.4.2 consulta tareas asignadas
Fuente: Elaboración Propia
3.4.3 registro de tareas
Fuente: Elaboración Propia
3.5 Diagrama de secuencia
3.5.1 Login aplicación web
Fuente: Elaboración Propia
3.5.2 Consulta de tareas.
Fuente: Elaboración Propia
3.5.3 Registrar Tarea.
Fuente: Elaboración Propia
3.6 Diagrama de componentes
Fuente: Elaboración Propia
3.7 Diagrama de Despliegue
Fuente: Elaboración Propia
4. Fase de Implementación.
En el momento de empezar con la construcción de la aplicación de negocio con enfoque BPM, se
presentan una infinidad de posibilidades, una de ellas y la más utilizada es la utilización de
herramientas de presentación que se exponen en los BPMS, en el caso de BonitaBPM en la
codificación del proceso y despliegue del mismos en los servidores antes mencionados se generan
formularios básicos en HTML con soporte transaccional en lenguaje java, dicha solución es muy
eficiente y rápida en cuanto al desarrollo de aplicaciones que parten desde cero. Pero en la mayoría
de casos presentan limitaciones a la hora de enriquecer la presentación de la aplicación, ya que
dichos formularios tomaran los estilos y layaout definidos en él .war del BPMS desplegado en el
servidor web. Para solventar este problema muchos BPMS han implementado un API que permite
acceder al core del sistema BPM donde se ubican las reglas y funcionas propias de la gestión BPM.
Lo que genera posibilidades de integración de aplicaciones externas con la gestión BPM, dicha
integración en el caso de BonitaBPM se realiza por tres medios (EJB, HTTP, TCP).
Teniendo en cuenta eso pueden construir aplicaciones que generen conexión con el core BPM en
cualquiera de estos medios. El API proporcionado por BonitaBPM [7], muestra que son JAR los
que permiten la integración con el BPM, a través de una serie de objetos y funciones que
encapsulan las funcionalidades, este aspecto resulta algo negativo cuando la aplicación de negocio
no está desarrollada en java y dichos JAR no se puede usar; una solución rápida seria hacer
funciones que consuman los JAR y exponerlas como servicios web la cual sería muy viable, pero
pensando en esto BonitaBPM ha pensado un API permita consumir funciones del sistema BPM
desde cualquier otro cliente por un api REST, solo codificando el cliente de dichos servicios en
cualquier plataforma.
Figura 3: Diseño de componentes API bonita [7].
Fuente: http://documentation.bonitasoft.com/product-bos-sp/development
La forma de integración con dicho API permite exponer una aplicación de negocio con: JSF 2.2,
Primefaces 5.1, CSS, JQUERY. Para mostrar la posibilidad de diseñar aplicaciones ricas
visualmente y robustas bajo estándares como lo son JEE y .NET. a modo de ejemplo se puede
utilizar la arquitectura JEE, con un modelo de acceso a datos bajo JPA, apoyándose en el
ORM(Mapeo de Objetos relacionales) Hibernate, la lógica de negocio y del BPM bajo el API
EJB 3.1, en cuanto a patrones de diseño se implementa MVC(Modelo Vista Controlador) propio de
primefaces. La integración de los elementos tanto plataforma BPM, como plataforma de negocio en
distintos servidores de aplicaciones. Lo cual funciona de forma eficiente, pero en algunos casos por
temas de organización y monitoreo generaría un trabajo extra como lo son observar dos log de
proceso y verificación de los mismos. Por ello la idea de unificar todo en un servidor de
aplicaciones no está mal y se ahorraría gestión de administración de aplicaciones, en el siguiente
diagrama de componentes se muestra un posible esquema de integración entre una plataforma BPM
y algunas tecnologías.
API(EJB,TCP,HTTP)
ISS: ASP.MVC, C#,CSS
Datos BPM (postgres 9.4)
SQL SERVER 2O12
Datos Proceso de negocio (MYSQL)
.War con apliaccion de negocio (primefaces, jpa,css, jquery)
API WEB SERVICES REST
.War.EJB
Elementos de gestion de Bonita
Figura 4: Esquema de integración de diferentes plataformas con BMP
Fuente: Elaboración Propia
El panorama mencionado anteriormente se presenta en un escenario donde las aplicaciones parten
de cero, pero cuando en algunos escenarios se presentan sistemas heredados cuya eficiencia
especifica es absoluta y una construcción de ceros para integrarlo con BPM no es válida, en estos
caso se evidencia el uso de otra característica fundamental de los BPMS, lo cual son los conectores
que son piezas de software que permiten la integración con componentes específicos externos al
servicio BPM, y que contemplan: base de datos (sql server, postgres, mysql, informix, Oracle.),
gestores documentales(alfresco), web services SOAP, LDAP, herramientas de reportes
(jasperreport), calendario Google, mensajería snmp.
Teniendo en cuenta lo anterior, el modelo BPM ya no tendría como único punto de integración un
API BPM, si no que respondería a una serie de piezas que permitirían construir tareas que
efectuaran integraciones específicas, quitando esta responsabilidad a la aplicación de negocio y
asignándosela al BPM; integrando funcionalidades de toda la compañía en pro de la gestión de los
procesos sobre BPM, implementadas ya sea desde una Aplicación de negocios o desde el sistema
BPM.
Para el diseño del prototipo se ha decidido tomar como marco de referencia la teoría de
microservicios expuesta en apartados anteriores, siguiendo el principio de responsabilidades por
objetos y componentes uno de los pilares del acrónimo SOLID, se propone desarrollar un conjunto
de elementos los cuales estarán encargados de gestionar funciones particulares en el marco de la
integración de la metodología BPM con tecnologías del lado del servidor enmarcadas bajo el
estándar JEE y tecnologías móviles bajo el lenguaje Android; a continuación se describirá cada
componente utilizado en el prototipo planteado.
5. Sistema BPM: Implementación mecanismo de integración procesos BPM api
HTTP del BPMS Bonitasoft
Desarrollo Implementación sistema BPM.
Servidor de aplicaciones: JBOSS 7.1.1.
Motor BPM: BonitaSoft 6.5.3 versión community
JDK: Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)
Base de datos: postgrest 9.4
Este Sistema presenta una interfaz de administración parametrizable de los elementos de
configuración del motor de BonitaBPM, estos elementos son enmarcados en el diseño y respectivo
despliegue en este sistema de la organización, la cual se debe tener en cuenta que es una abstracción
del modelo organizacional donde se implementa la metodología BPM, en la definición de dicha
organización se identificar jerarquías, responsables en cada uno de los procesos.
El sistema BPM ofrece un marco de seguridad bajo el estándar JAAS, el cual es parametrizable en
la configuración de la organización antes mencionada. Brindado un sistema de roles y grupos de
trabajo. Lo que permite ofrecer trazabilidad de las tareas asignadas a cada usuario. Cuando se habla
del sistema BPM ofrecido por BonitaSoft en su versión community se debe tener en cuenta que la
herramienta ofrece dos modos de gestión de la plataforma uno como administrador y otro como
usuario de la aplicación. El perfil Administrador es el encargado de:
Desplegar organización
Desplegar procesos BPM
Configurar Procesos BPM
Configurar usuarios y roles
Perfil usuario es el encargado de:
Instanciar procesos
Ver información de los procesos
Ver información de los procesos y tareas de los mismos
El sistema BPM permite el despliegue y monitoreo de los procesos diseñados, dicho despliegue
siempre debe ser desde este sistema bajo el rol administrador, para mayor información. Es por ello
que es importante conocer la organización y procesos de implementación al momento de trabajar la
metodología BPM, como se dijo anteriormente los procesos de la misma deben ser orientados de
forma transversal a toda la organización así al momento de desplegar un diseño de organización y
unos procesos diseñados para la misma se evidenciara la totalidad de responsables e insumos de
valor en la terminación de dicho proceso.
En el prototipo de diseño se identifica, la necesidad de evaluar donde guardar los datos de negocio
encargados de gestionar la información propia del modelo de la organización, la herramienta
BonitaSoft ofrece un modelo de datos el cual como se mencionó anteriormente está almacenado en
una base de datos POSTGRES 9.4, lo que daría una rápida solución a la persistencia de los mismo,
pero al evaluar dicha estructura compuesta de 72 tablas se evidencia, que es de difícil interpretación
al momento de entender un modelo de negocio desde su modelo de datos, ya que estos guardan toda
la información en 3 tablas principales que crecen de forma exponencial al momento de gestionar
cada proceso haciendo en muchos casos que se repitan datos, convirtiendo el desarrollo de los
procesos de búsqueda de información en tareas de carácter exponencial al no tener un modelo de
datos propio del negocio de la organización. Es por esto que se adopta el manejo de variables de
proceso las cuales nos permiten dar un flujo de navegación al proceso a través de cada tarea,
evitando persistir toda la información al modelo BPM dándole independencia a los datos de
negocio y así lograr un entendimiento y mejora al momento de escalar la aplicación, al dividir los
datos en datos de negocio y datos de proceso se establece reportes claros y manejo de la
información de forma más independiente sin depender de la herramienta BPM y su normalización.
Una característica importante del sistema BPM es su integración hacia otras herramientas,
siguiendo otro de los principios SOLID, ahora enfocado a estar abierta para su extensión y cerrada
para su modificación, en este marco se diseña tareas que utilicen conectores propios de BonitaBPM
lo que dan un ahorro en tiempo de desarrollo y diseño de interfaces de integración: para este
prototipo se utiliza dos funciones principales de sus extensiones la primera radica en la posibilidad
de adjuntar documentos a cada proceso gestionado por BonitaBPM ofreciendo un margo de gestión
documental de la información, ahorrándonos la configuración y despliegue de gestores
documentales en servidores externos, la segunda radica en el consumo de diseño de tareas
específicas encargadas de consumir servicios web para poder monitorear estado de variables
externas y así poder dar continuidad al flujo del proceso.
Proyecto EJB (estandar EJB 3.1):
En este proyecto se involucra todo lo referente a la lógica de negocio que se retira del modelo de
datos de BonitaBPM, dando la posibilidad de poder implementar el marco de JPA y así optimizar la
construcción y ejecución de los procesos de negocio a nivel de datos, al crear en este proyecto EJB
entidades que gestionen todo el mapeo de la base de datos la cual se encuentra en una instancia de
MYSQL se logra la independencia y escalabilidad del modelo de datos alejado del modelo de datos
BPM, dichas entidades son gestionadas por EJB de tipo SessionBean – Stateless los cuales son
accedidos por medio de una interface diseñada para cada uno dando seguridad y escalabilidad al
brindar la posibilidad de que estos sean accedidos de forma remota desde cualquier servidor, para
este prototipo será desplegado en el mismo servidor que el aplicativo web. En la siguiente imagen
se puede observar el diseño del proyecto EJB que encapsula toda la lógica de negocio.
Figura 6: estructura proyecto gestión EJB.
Fuente: Elaboración propia
Proyecto Web:
El proyecto web está construido sobre primefaces 5.0, mojarra 2.1, el cual permite lograr
independencia del modelo visual implementado por la plataforma BonitaBPM, generando la
posibilidad de gestionar un modelo visual acorde a las necesidades del cliente, en este caso se
utiliza los temas proporcionados por primefaces con algunas adaptaciones de bootstrap, lo que
permite dar una apariencia de diseño responsive, Este proyecto web permite la gestión de toda la
lógica BPM y de negocio de cara al usuario, gracias a la integración por medio de Maven de los
proyectos comunes y proyectos EJB diseñados, es por esto que en los ManagedBeans se construye
controladores de vista con base a operaciones realizadas en la plataforma BPM o en el modelo de
negocio.
6. Modelo de abstracción de la gestión de la metodología BPM
Desarrollo Implementación aplicación web que se integre con el sistema BPM e Implementación
mecanismo de integración que permita gestionar procesos BPM utilizando el api HTTP del BPMS
Bonitasoft.
Servidor de aplicaciones: JBOSS 7.1.1.
Framework java: Primefaces 5.0, mojarra 2.1
JDK: Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)
Base de datos: MYSQL
En el prototipo propuesto se planteado la posibilidad de no utilizar el entorno visual de la
plataformaBPM y así lograr una personalización de las aplicación web según las necesidades del
cliente y así aplicando otro principio del acrónimo SOLID, en donde se diseña varias interfaces de
integración en lugar de una sola, esto es posible gracias al api de integración de la plataforma
BonitaBPM el cual ofrece un conjunto de librerías las cuales permiten gestionar toda la lógica del
motorBPM desde cualquier aplicación. Siguiendo esta premisa se construye un proyecto común
bajo el estándar JSE el cual estará desplegado como librería en nuestro servidor de aplicaciones
JBOSS AS 7.1 el cual esta encargado de brindar una interface de comunicación al servidor BPM,
para asi llevar la gestión de los procesos y tareas diseñadas. En la elaboración de este proyecto JSE
se realiza la abstracción del modelo BPM en estas clases:
CasosBonita: encargado de gestionar todo lo relacionado con creación y monitoreo de
instancias de proceso
TareasBonita: encargado de gestionar todo lo relacionado con asignación, monitoreo de
tareas que conforman un proceso
Usuarios Bonita: encargado de gestionar todo lo relacionado con los usuarios de la
organización diseñada
ProcesosBonita: encargado de gestionar todo lo relacionado con las versiones y procesos
desplegados, importante a la hora de validar a que instancia de proceso nos referimos. En
la siguiente imagen se observa la estructura del proyecto común de integración con el
entorno BPM y los jar suministrados por Bonitasoft, construidos con Maven.
Figura 5: estructura proyecto gestión api Bonita, jar de integración
Fuente: elaboración propia
7. Implementación de microservicios.
Proyecto web servicios:
Al desarrollar el prototipo del sistema bajo el modelo PHVA se observa la necesidad de diseñar e
implementar un conjunto de microservicios que ofrezca la posibilidad de escalar la gestión BPM a
un modelo de arquitecturas empresariales. Lo que convertirá al sistema en un modelo escalable y
de fácil integración, es por ello que se toma la decisión de adoptar la filosofía de los microservicios
para así establecer un modelo de integración con cualquier plataforma, y aplicando uno de los
principios de SOLID, el cual nos menciona que nuestras entidades deben estar abiertas para su
extensión y cerradas para su modificación, al exponer microservicios de gestión de los procesos
BPM, ofrecemos a los usuarios un sistema escalable y de rápida adaptación, al exponer servicios
web encargados de gestionar el modelo BPM desde cualquier plataforma, reflejando una política de
integración con cualquier sistema que necesite interactuar con el sistema BPM, para dar mayor
solides a este sistema se implementa un ESB, el cual nos permitiré gestionar de forma centralizada
y ordenada la escalabilidad de la aplicación ofreciendo un punto de control y monitoreo unificado al
momento de poder verificar y escalar el sistema. Esta implementación permite establecer modelos
de entendimiento y conceptualización entre todos los sistemas implementados en una organización.
Al presentar de forma ordenada todas las posibles integraciones hacia el sistema de manejo de
Procesos.
Implementación de un conjunto de micro servicios que permitan la gestión de las operaciones BPM
desde cualquier sistema. Proyecto encargado de brindar una interfaz de comunicaciones para el
modelo de Negocio y gestión de datos BPM , en este proyecto web radican las interfaces de
servicios web que serán utilizados por las aplicaciones móviles y bus de servicio, para poder
gestionar los procesos móviles y de integración con otros sistemas. Las tecnologías utilizadas están
basadas en los estándares JAX-WS y JAX-RS, lo que permite versatilidad de los clientes y
funciones a exponer por parte del sistema.
Bus de servicios [18]:
La implementación del bus de servicios se realiza mediante el ESB Mule, el cual está construido
sobre java y bajo el estardar JMS, brinda la posibilidad de crear un entorno de integración y
administración centralizada de todas las interfaces de los servicios expuestos en el modelo de
gestión BPM. Al implementar esta tecnología se crea la posibilidad de ofrecer un entorno escalable
al prototipo de integración ya que ofrece un punto administrable de integración rápida y robusta de
los diferentes módulos y servicios que necesite una aplicación en un futuro, con esto se establece un
punto importante en la modularidad y gestión de las aplicaciones, al salir de un modelo Monolitico
de software a uno de microservicios.
En el proyecto de ejemplo se utiliza la gestión de un ESB por medio de Mule, para ofrecer un punto
de integración de todos los servicios de gestión hacia las plataformas moviles desarrolladas en
Apache Cordova, como se mencionó antes el entorno de Bonita BPM también ofrece una interfaz
de servicios REST para poder gestionar dicho entono, es por esto que se toma la decisión de
centralizar toda esta gestión en el ESB, ofreciendo un marco de seguridad y monitoreo de la gestión
de estos servicios consumidos por otras aplicaciones ajenas al contenedor jboss de BonitaBPM o de
la aplicación web.
Aplicación Móvil:
La aplicación Móvil, se encuentra desarrollada en el lenguaje hibrido apache Cordova en su versión
6.0, la arquitectura de esta enfocada a ser una aplicación online que funciona como cliente de los
servicios expuestos ya sea en el proyecto web o en un intermediario que en este caso es
representado por un bus de servicios. En la implementación de este sistema se utiliza el desarrollo
hibrido proporcionado por apache Córdova el cual permite utilizar html acoplado con jquery
Mobile, para generar las vistas en la aplicación Móvil y realizar peticiones Ajax a los servicios
expuestos. En el desarrollo de esta aplicación móvil se ha implementado la comunicación y gestión
de datos por medio de petición Ajax dirigidas al bus de servicio donde será redirigidas al proyecto
de integración web Services.
8. Implementación mecanismo de verificación de la gestión de los procesos BPM
Para el proceso de verificación de la gestión de los procesos BPM, se ha decidido crear un módulo
de consulta de historial de usuario donde se llevara el registro de todos los cambios y actores
involucrados en la gestión de cada proceso, dicho desarrollo será implementado por medio del
modelo de abstracción mencionado en capítulos anteriores, y expuesto en la aplicación web por
medio de primefaces.
Por otro lado se implementa un conjunto de gráficos de control, permitiendo al usuario ver de forma
estadística controles de tareas y procesos en determinados tiempo, con la implementación de dicho
mecanismo se evidencia que la metodología BPM brinda las herramientas suficientes para
establecer un marco de retroalimentación en la implementación y análisis de proceso al momento
de integrarlas con herramientas de software. Mostrando a la organización un modelo de
trazabilidad y control al momento de tomar decisiones, encaminando la visión organizacional con
las herramientas de software implementadas.
9. Método de integración
Al momento de establecer el sistema de integración se ha implementado un proyecto común que se
integra por medio de peticiones HTTP a los Servlet expuestos por la aplicación web de
BonitaBPM permitiendo controlar todos los eventos del sistema BPM, dichos eventos serán
gestionados por Managed Beans los cuales controlaran las peticiones al proyecto común por medio
de instancias de objetos de abstracción del modelo BPM explicado anteriormente, por otra parte la
gestión de las reglas de negocio propias del proceso y almacenamiento de información propia de la
organización será controlada por los Managed Beans en función de los EJB y Entidades siguiendo
el modelo de la arquitectura de JEE dentro del contenedor de EJB jboss AS 7.1.
Al momento de analizar un modelo de escalabilidad se ha decidido la adopción de una arquitectura
SOAP en la cual se expongan servicios de gestión e integración desde la aplicación JEE diseñada y
encargada de gestionar los proceso, para dicha implementación se realiza un proyecto web
independiente encargado de exponer los servicios de gestión de los procesos BPM y posibles
integraciones a l software propio de gestión del proceso a desarrollar, esta implementación se ha
desarrollado bajo la arquitectura JEE por medio de los api JAX WS Y JAX RS. Para ofrecer un
punto de control , gestión centralizada y posibilidad de escalabilidad bajo el marco de una
arquitectura orientada a servicios se implementa un Bus De Servicios el cual mediante peticiones
HTTP se encargar de interactuar con el proyecto de servicios web y los servicios expuesto
directamente por el BMPS BonitaBPM ofreciendo una interfaz trasparente y segura para la
integración de muchas plataformas, como los servicios web externos o aplicaciones móviles, este
prototipo se enfoca a una arquitectura empresarial donde el objetivo es brindar la posibilidad de
mostrar un marco de integración estable, seguro y escalable enfocado con la misión estratégica de
cualquier organización.
9. Conclusiones.
La optimización de procesos en las compañías se ha convertido en un mecanismo para generar
características de eficiencia con base a monitoreo y mejora continua de los mismos, en dicho
proceso se evidencia la falta de articulación de los procesos con las herramientas tecnológicas
diseñadas, generando inconvenientes en la gestión de las tareas de la organización. La metodología
BPM permite optimizar los procesos y a su vez integrar la plataforma tecnológica existente para
dar un enfoque de innovación y soporte a la misión y visión de la organización.
En el momento de implementar un modelo BPM se debe tener claro un esquema de integración con
la totalidad de los servicios de la organización, dejando el sistema BPM trasversal a toda la gestión
tecnológica de la compañía y así determinar cuál de los diferentes métodos de integración es mejor
adoptar. La idea no es integrar múltiples servicios sin antes diseñar un modelo robusto y de fácil
gestión de las múltiples aplicaciones en la compañía y si es el caso cambiar el modelo de
implementación a una arquitectura orientada a servicios. La división de cada herramienta y
articulación de un elemento central de gestión como lo es el BPM no debe verse como una
dependencia del total de aplicaciones, sino como un punto de monitoreo y control que debe ser
atendido como tal, dotándolo de buenas características de hardware y software.
En la actualidad existen muchas herramientas de gestión BPM, las cuales permiten integrar la
mejora de procesos en la organización, es importante analizar cuál de estas se adapta a las
necesidades de la organización en cuanto a funcionalidad y factor de adquisición. La mejora de
procesos debe venir acompañada de un cambio de pensamiento de la organización, entendiendo
como cada proceso se relaciona con los demás generando responsabilidades e interoperabilidad en
cada área de la organización.
Referencias
[1]Lic. P. Bazán. “Un modelo de integrabilidad con SOA y BPM”. Tesis de maestría en Redes de
Datos. Facultad de Informática Universidad Nacional de La Plata. Buenos Aires. Argentina
Diciembre 2009.
[2] G. González. “Cambiando los paradigmas del mundo de la Ingeniería de Software”. 2012.
disponible en http://www.emb.cl/gerencia/articulo.mvc?xid=440. Consulta: Junio 2016
[3]J. Sepúlveda Hermes,”BPM se está posicionando en el mundo como el modelo de gestión
organizacional por excelencia”. Disponible en http://www.club-bpm.com/Noticias/art00112.htm.
Consulta: Junio 2016
[4]J. R. País Curto.”BPM”. “BPM (Business Process Management). Páginas 137-166.Editorial
BPMteca. 2013.
[5]Lic. P. Bazán, “Tecnologías para implementar un marco integrador de SOA y BPM”, LINTI
(Laboratorio de Investigación en Nuevas Tecnologías Informáticas) Facultad de Informática
Universidad Nacional de La Plata, Mayo 2010
[6]J. Hoskins, “The Dynamic Business Network”. Paginas 23-32. “Achieving Business Agility with
IBM BPM and SOA Connectivity”, editorial Maximun press. 2010
[7]Documentación oficial BonitaBPM, disponible en http://documentation.bonitasoft.com/product-
bos-sp/development, sección: Development, Consulta : Agosto 2016.
[8] Kiran Garimella, Michael Lees, Bruce Williams, BPM (GERENCIA DE PROCESOS DE
NEGOCIO) Disponible en: http://www.konradlorenz.edu.co/images/publicaciones/
suma_digital_sistemas/bpm.pdf. Consulta: Mayo 2016
[9] Alejandro Nieto Gonzalez, ¿Qué es Android? Disponible en
http://www.xatakandroid.com/sistema-operativo/que-es-android, 2011. Consulta: Junio 2016
[10] Hugo González, HERRAMIENTAS PARA LA MEJORA CONTINUA Disponible en
https://calidadgestion.wordpress.com/2012/07/11/herramientas-para-la-mejora-continua/, 2012.
Consulta: Junio 2016
[11] Yuli Paola Sanchez Moreno, CICLO PHVA Disponible en http://www.gerencie.com/ciclo-
phva.html. Consulta: Julio 2016
[12] Ivar Jacobson, Grady Booch, James Rumbaugh, “El proceso Unificado de Desarrollo de
Software “. Páginas: 1-29 . “El Proceso Unificado de Desarrollo de Software”. Editorial Addison
Wesley. 2000.
[13] Documentación oficial Apache Córdova Disponible en:
http://cordova.apache.org/docs/en/latest/guide/overview/index.html, Consulta: Julio 2016
[14] Marisol, Diego Silva, “Convirtiendo Aplicaciones Java EE monolíticos a Microservicios”,
2015, Disponible http://www.apuntesdejava.com/2015/09/convirtiendo-aplicaciones-java-ee.html,
Consulta: Julio 2016
[15] James Lewis, Martin Fowler, “Microservices”, 2014,
http://martinfowler.com/articles/microservices.html. Consulta: Julio 2016
[16] Txema Rodríguez, “Trabajar con microservicios: evitando la frustración de las (enormes)
aplicaciones monolíticas”, 2014, Disponible en: http://www.genbetadev.com/paradigmas-de-
programacion/trabajar-con-microservicios-evitando-la-frustracion-de-las-enormes-aplicaciones-
monoliticas. Consulta: Julio 2016
[17] E.V.A. UCI, I. D. S. Conferencia #1. Introducción a la Ingeniería de Software, ISW 1.,
“Proceso Unificado de Desarrollo”, 2015, Disponible en:
http://www.ecured.cu/Proceso_Unificado_de_Desarrollo. Consulta: Julio 2016
[18] Diego Rojas,” ¿Qué es un ESB – Enterprise Service Bus?”, 2014, Disponible en:
http://icomparable.blogspot.com.co/2009/04/que-es-un-esb-enterprise-service-bus.html. Consulta:
Julio 2016
[19] BonitaSoft, “Conoce Bonita BPM 7”. Disponible en:
http://www.bonitasoft.com/products#feature-block-1. Consulta: Julio 2016
[20] MuleSoft, “What is Mule ESB?”. Disponible en:
https://www.mulesoft.com/resources/esb/what-mule-esb. Consulta: Julio 2016
