USO DE MOTORES DE REGLAS DE NEGOCIO

Transcripción

1 USO DE MOTORES DE REGLAS DE NEGOCIO Carlos Alberto Mejía Castelo U n i v e r s i d a d S a n B u e n a v e n t u r a C a l i A v e n i d a 1 0 d e M a y o, L a U m b r í a, V í a a P a n c e A g o s t o d e

2 TABLA DE CONTENIDO RESUMEN... 2 INTRODUCCIÓN RESUMEN DE REGLAS DE NEGOCIO... 4 RESUMEN DE MOTORES DE REGLAS DE NEGOCIO... 5 CUÁL ES LA MOTIVACIÓN PARA LAS REGLAS DE NEGOCIO?... 6 CONSIDERACIONES PARA LA APLICACIÓN DE LOS MOTORES DE REGLAS DE NEGOCIO SELECCIÓN DE UN MOTOR DE REGLAS DE NEGOCIO METODOLOGÍAS AGILES METODOLOGÍAS AGILES Y MOTORES DE REGLAS DE NEGOCIO METODOLOGÍA ABRD (Agile Business Rule Development) APROXIMACION BASADA EN CICLOS: CONSIDERACIONES ADICIONALES: REFERENCIA... 20

3 RESUMEN Este documento pretende introducir a empresas y estudiantes interesados en la implementación de Motores de Reglas de Negocio, para esto, se presentan algunas recomendaciones sobre cómo implementar proyectos utilizando estas tecnologías, por ejemplo mediante la aplicación de un modo ágil distribuido. Aunque el documento abarca los fundamentos de la metodología ágil y técnicas de los diferentes Motores de Regla de Negocio, no tiene como objetivo dar una introducción detallada a cualquiera de estos

4 INTRODUCCIÓN. Las condiciones de participación de las empresas, en las diferentes actividades que ejercen, están en constante cambio, las normas y las funciones cambian a lo largo del ciclo de vida de un sistema de información empresarial, a veces estos cambios ocurren varias veces en un día, es por esto, que el negocio debe adaptarse a estos cambios en tiempo real, y por supuesto debe adaptarse también su software, este proceso de adaptabilidad, se ve severamente optimizado al implementar la tecnología de los motores de reglas de negocio. En la actualidad existen varios motores de reglas, que brindan un servicio a las necesidades del negocio, estos deben ser capaces de adaptar la lógica de las aplicaciones del negocio a los constantes cambios para permitir flexibilidad a las organizaciones y así tener un mayor aprovechamiento de las oportunidades. Existen diferentes consideraciones, técnicas, consejos y metodologías que soportan el proceso de implementación de los motores de reglas de negocio en un proyecto de software; tanto estudiantes como desarrolladores y empresarios que deseen involucrar a los motores de reglas en sus desarrollos, pueden beneficiarse de estas técnicas y metodologías, desarrollando así planes de trabajo y adaptando su forma de pensar al nuevo paradigma que estas tecnologías presentan.

5 RESUMEN DE REGLAS DE NEGOCIO Desde el punto de vista del negocio, las reglas de negocio involucran el comportamiento de la gente en el sistema del negocio, una regla de negocio es un indicador que existe una obligación concerniendo a la conducta, acción, práctica o procedimiento dentro de una actividad particular o escenario. Visto de una forma más sencilla, una regla de negocio es cualquier conocimiento que puede ser expresado en el siguiente formato: Cuando algo es verdad, Entonces haga esto. Todas las compañías y organizaciones tienen reglas de negocio, estas están detalladas en reglamentos, procedimientos, en la mente del experto del negocio e incluso en código de aplicaciones existentes. El termino reglas de negocio se utiliza para denotar que no son técnicas, también podrían ser llamadas reglas medicas, reglas financieras, reglas de seguros, etc. Esto depende de la organización en la que se crearán y utilizaran las reglas. [4] Desde el punto de vista de los sistemas de información, una regla de negocio pertenece a los hechos del sistema (que son guardados como datos) y a las restricciones en los cambios de los valores de estos. Las reglas de negocio deberían ser escritas de la forma más clara posible, en cualquier lenguaje humano que sea elegido, esto no solo simplifica el proceso de la escritura de reglas, también facilita que personas que no escribieron las reglas, puedan analizarlas y evaluarlas. Ya que las reglas de negocio son una expresión de conocimiento, deben ser escritas por quien tiene ese conocimiento, ya sea el gerente, el administrador, o el director de cartera, de esta forma se reducen a gran medida la posibilidad de errores y fallos en la definición de reglas. [4]

6 RESUMEN DE MOTORES DE REGLAS DE NEGOCIO Un motor de reglas de negocio es un sistema de información, que ejecuta reglas de negocio o monitorea actividades de negocio en términos del cumplimiento de las reglas en tiempo de ejecución. Los motores de reglas de negocio generalmente incluyen características para el desarrollo de reglas de negocio que permiten una definición conveniente y la verificación de las reglas. Partes de un motor de reglas. [4] Figura 1: Partes de un motor de reglas

7 CUÁL ES LA MOTIVACIÓN PARA LAS REGLAS DE NEGOCIO? En Las compañías se encuentran todo tipo de reglas de negocio. Que satisfacen requerimientos a los cuales se les debe dar cumplimiento y son emitidas por Instituciones reguladoras, unidades de negocio, compradores, competidores y en general las condiciones de mercado, todos generan reglas de negocio en cambio constante. El traducir el conocimiento en reglas de negocio, significa el no depender de la presencia del experto para poder realizar las operaciones de la organización, también significa que los procesos dispendiosos de estas operaciones pueden automatizarse y así el experto dispondrá de más tiempo para realizar actividades diferentes como estudiar mejoras al proceso. Las reglas de negocio influencian y guían el comportamiento de la gente (perspectiva de negocio) e influencia la información que se almacena en un sistema de información, así como restringe la modificación de esta información (perspectiva de sistemas de información). [26] La motivación del negocio de mejorar la administración de las reglas de negocio es la de incrementar el control y el conocimiento en la organización, acerca del cómo, porque, cuando, donde y por quien, las reglas son forzadas. El tener mayor conocimiento, entendimiento y control sobre las reglas de negocio puede responder preguntas de los stakeholders como por ejemplo el cumplimiento de la organización con regulaciones, el riesgo que la compañía enfrenta cuando los empleados dejan la compañía, la habilidad de rápidamente cambiar las políticas de negocio o implementar nuevas regulaciones, entre otras.

8 CONSIDERACIONES PARA LA APLICACIÓN DE LOS MOTORES DE REGLAS DE NEGOCIO. Como primera consideración al momento de implementar un motor de reglas de negocio a un proyecto de software, es evaluar en primer lugar si esta tecnología es la apropiada para el alcance del proyecto, y si es justificable el esfuerzo, recursos y tiempo invertidos para lo que realmente se desea desarrollar. Para determinar si el proyecto a desarrollar puede beneficiarse o no de las reglas de negocio, se recomienda tomar en consideración los siguientes puntos: 1. Si se espera que algoritmos a usar en el software tengan gran capacidad de toma de decisiones, se puede considerar la aplicación del motor de reglas. 2. Las decisiones son suficientemente complejas? Si el alcance del proyecto implica la toma de un número significativo de decisiones, se deben evaluar cuan complejas pueden ser las mismas, si las decisiones o reglas son demasiado complejas, y esto dificulta la escritura de reglas, es posible que se deba considerar alguna otra opción; adicionalmente si solo se proveen 2 o menos condiciones en las decisiones, el esfuerzo de implementar un motor de reglas no se justifica por la simplicidad de estos temas, sin embargo, si los métodos tienen una complejidad considerable y 3 o más decisiones, se puede considerar implementar un motor de reglas. 3. Cuán variables serán las condiciones lógicas del sistema? Si las reglas o lógica son estáticas y no se provee que cambien o que cambien de una forma regular, no se debe implementar un motor de reglas, así mismo, si la naturaleza del negocio o las reglas, implica que estas van a cambiar constantemente, se puede considerar el uso de un motor de reglas. 4. El desempeño del sistema de software es un tema crítico para el cliente? Si se necesita que el software tenga un tiempo de respuesta muy reducido, lo que implique incluso escribir algoritmos optimizados para garantizar dicho tiempo de respuesta, o si por otro lado existe una restricción considerable en cuanta memoria está disponible para el sistema, es posible que un motor de reglas no sea la solución correcta, la implementación de estas tecnologías, debido a la forma en la que estas trabajan, suelen tener un alto consumo de memoria, además, la integración con estos productos involucra pasos adicionales que pueden demorar el tiempo de respuesta de la aplicación.

9 5. El proyecto tiene los recursos suficientes para cubrir los costos que involucran el implementar un motor de reglas de negocio? Los costos asociados a la implementación de un motor de reglas son los siguientes: Si el motor de reglas a usar tiene licencia, el costo de la misma. Entrenamiento a desarrolladores y a usuarios finales. Retorno de la inversión, se estima que el retorno de la inversión de implementar un motor de reglas empieza después de un año de desarrollo. Si los costos de implementar un motor de reglas cubren el presupuesto en tiempo y recursos, y las condiciones anteriores se cumplen, se puede considerar la implementación de un motor de reglas.

10 Administración de reglas vía Web Administración gráfica de reglas Compatibilidad nativa multiplataforma Disponibilidad de Soporte Manejo de DSL Control de versiones de reglas Login Usuarios Paquete de reglas vía HTTP Entorno de pruebas de reglas Open Source SELECCIÓN DE UN MOTOR DE REGLAS DE NEGOCIO. Cuando ya se evaluó el alcance del proyecto, así como los recursos disponibles para el mismo, y se decide implementar un motor de reglas de negocio, el siguiente paso es determinar que motor de reglas es el más apropiado para el tipo de proyecto a implementar, la escogencia de un motor u otro debe ser basada en diferentes condiciones, como lo son el tipo de lenguajes con los que pueden trabajar, características, herramientas disponibles, y muy importante, esquema de licenciamiento. JBoss Rules Oracle Business Rules X X X X X X X X X X X X X X X X X X OpenRules X X X X X NxBRE X X X X Blaze Advisor BizTalk Server X X X X X X X X X X X X X IBM ILOG X X X X X X X X X Tabla 1: Resumen de las características disponibles en cada motor de reglas estudiado

11 Se tabla presenta varios motores de reglas de negocio con sus diferentes características, se recomienda hacer un estudio de que motores cumplen con los requisitos necesarios para la implementación que se desea realizar, escoger el que más se acomode a las necesidades del proyecto, y realizar el proceso de implementación. Al haber tomado la decisión de que motor de reglas de negocio será utilizado, el paso restante es realizar el proceso de construcción de software; la implementación de un motor de reglas de negocio a un proyecto de software tiene consideraciones técnicas, los procesos de planeación, diseño y construcción deben adaptarse a la necesidad de implementar la nueva tecnología. En base a esto se han creado diferentes técnicas y metodologías para facilitar la implementación de un motor de reglas de negocio a un proyecto de software, entre estas metodologías, se destacan las metodologías agiles, las cuales por su naturaleza, se adaptan a los proyectos de software con motores de reglas de negocio de forma natural, ya que comparten características y necesidades. Para presentar una metodología ágil para la implementación de los motores de reglas de negocio, primero se presenta el concepto de metodologías agiles.

12 METODOLOGÍAS AGILES Las metodologías agiles pretenden minimizar riesgos en el desarrollo de software, desarrollando el software en periodos cortos de tiempo llamados iteraciones, que típicamente duran de una a 4 semanas. Cada iteración por sí misma, similar a un proyecto de software independiente, e incluye todas las tareas necesarias para liberar el incremento de la nueva funcionalidad: Planeación, análisis de requerimientos, diseño, codificación, pruebas y documentación. Aunque una iteración no adicione suficientes funcionalidades para justificar la liberación del producto, un proyecto de software que usa metodologías agiles pretende ser capaz de liberar una versión de software funcional al final de cada iteración; al final de cada iteración, el equipo de trabajo debe reevaluar (de ser necesario) las prioridades del proyecto. La mayoría de equipos de trabajo que están bajo una metodología ágil, están ubicados en un área de trabajo común, e incluyen a todas las personas necesarias para terminar el software. Como mínimo, esto incluye a los programadores y sus clientes, los clientes son finalmente las personas que definen el producto, pueden ser administradores de producto, analistas de negocio, etc. Existen varios métodos agiles, los más populares son: 1. extreme Programming (XP): Se enfoca en un diseño simple, trabajo en pares, desarrollo dirigido por pruebas e integración continua. 2. SCRUM: Proceso ágil que busca administrar y controlar el trabajo de desarrollo. La metodología XP pone bastante énfasis en el desarrollo dirigido por pruebas y la automatización, por lo tanto es más propio para proyectos donde los recursos tienen la experiencia y el conocimiento requerido en estas áreas. Por otro lado, SCRUM, es una aproximación orientada a la administración del proyecto. Los requerimientos y otras especificaciones son capturados de una forma ágil usando diferentes herramientas, sin embargo, no sigue una aproximación dirigida por pruebas. El administrador del proyecto es el encargado de manejar el balance entre los recursos disponibles y las funcionalidades solicitadas por el cliente para cada iteración particular.

13 METODOLOGÍAS AGILES Y MOTORES DE REGLAS DE NEGOCIO. Las metodologías agiles en colaboración con la implementación de los motores de reglas de negocio, pueden trabajar en conjunto y de hecho tener beneficios de una a otra, algunas razones por las que las metodologías agiles pueden trabajar en conjunto con los motores de reglas de negocio se presentan a continuación: 1. Involucran a los usuarios y dueños del negocio: Un tema clave en la implementación de motores de reglas de negocio en un proyecto y por otro lado en la aplicación de una metodología de desarrollo ágil, es el nivel en que los dueños del negocio se involucran con el proceso de desarrollo. El proceso de desarrollo fallará, si los usuarios del negocio no están involucrados en definir y validar las reglas. Desde una perspectiva ágil, es necesario que los usuarios del negocio diriman el proyecto. Por lo tanto una implementación de un motor de reglas se verá afectada positivamente por un método de desarrollo ágil. 2. Empiezan desde lo pequeño: Las reglas de negocio son el corazón de la organización, sin embargo, cuando se desarrolla un proyecto de gran escala, el riesgo es grande y las posibilidades de fracaso aumentan. Se recomienda que al implementar la tecnología de motores de reglas de negocio en este tipo de proyectos, se escoja un conjunto de reglas de negocio, que no tengan mucho impacto en el core de la aplicación ni del negocio, e implementarlas usando un motor de reglas. Las lecciones aprendidas en esta implementación pueden ser aplicadas después a conjuntos de reglas más importantes; este proceso es similar y puede ser implementado en las iteraciones de desarrollo de las metodologías agiles. 3. Aproximación basada en pruebas: La metodología XP por ejemplo, pone mucho énfasis en el desarrollo basado en herramientas y en un desarrollo dirigido por pruebas. Esto permite a los desarrolladores entender la funcionalidad completamente antes de desarrollar el código. Una implementación de un motor de reglas de negocio, se beneficia de la automatización y enfoque en pruebas en la etapa del desarrollo, el proceso de pruebas continuo no solo permite verificar el funcionamiento de la aplicación, sino también la verificación continua de las reglas de negocio implementadas en cada iteración.

14 METODOLOGÍA ABRD (Agile Business Rule Development). Ya relacionadas las metodologías agiles y los motores de reglas de negocio, se creó una metodología en el 2003 llamada metodología del desarrollo ágil de reglas de negocio o ABRD por sus siglas en inglés, esta metodología define un proceso de desarrollo de software incremental e iterativo, que toma en consideración los nuevos conceptos requeridos para desplegar BRMS, BPMS, entre otros. La metodología ABRD define constantes que deben ser administradas en la implementación de un proyecto, y que buscan atacar los problemas anteriormente mencionados, algunas constantes como por ejemplo: Individuos e interacciones sobre procesos y herramientas: El proceso de descubrimiento de reglas y las actividades de análisis y validación, requieren comunicación activa y eficiente entre el desarrollador del proyecto y los expertos del negocio, estos procesos se definen tan ligeros como sea posible. Software funcional sobre documentación extensiva: Cada iteración produce un conjunto funcional y probado de reglas que pueden ser ejecutadas, y esto agrega más valor al negocio que un manual de descripción de reglas, esto permite demostrar a los usuarios del negocio que las reglas están verificadas y entender que se despliega en el sistema. Colaboración con el cliente sobre negociación de contratos: En el proceso de desarrollo de una metodología agil, los dueños del negocio y los desarrolladores trabajan en un ecosistema compartido, esto permite que los dueños se involucren más internamente con el proceso de desarrollo. Responder más rápido al cambio que seguir un plan: Las reglas de negocio evolucionan más rápido que otros componentes de software, la metodología incluye actividades apropiadas, procesos y buenas practicas. La metodología ABRD define las siguientes metas particulares: Reglas administrables como artefactos usando actividades de análisis, descubrimiento y construcción, así como sus productos relacionados. Trazabilidad de reglas durante todo su ciclo de vida desde requerimiento, hasta despliegue y mantenimiento. Vincular a las reglas en el contexto y la motivación del negocio. Desarrollo de descripción de reglas usando términos de negocio y lenguaje de reglas de alto nivel. Preparar el modelo lógico de datos para el motor de reglas usando análisis y diseño orientado a objetos. Validar el conjunto de reglas usando una aproximación dirigida por pruebas con integración continua.

15 APROXIMACION BASADA EN CICLOS: La metodología ABRD agrupa actividades en ciclos, lo que permite un desarrollo iterativo, las actividades ABRD incluyen: Descubrimiento de reglas Análisis de reglas Diseño de reglas Construcción de reglas Validación de reglas. Despliegue de reglas Figura 2: Aproximación Basada en Ciclos Trabajar en ciclos permite asegurar que los resultados de estas iteraciones cumplan con las expectativas de negocio a medida que el conjunto de reglas crece. El primer ciclo se repite entre las actividades de descubrimiento y análisis de reglas para obtener las políticas y las reglas de negocio. El segundo ciclo es prototipar las reglas ejecutables repitiendo las actividades de descubrimiento, análisis, diseño y construcción. El tercer ciclo llamado construcción, incluye múltiples posibles repeticiones adaptadas para lo que se necesita hacer, un enfoque puro en la implementación de reglas y entre escritura y validación, sin embargo también puede regresar a las actividades de análisis y descubrimiento.[29] La descripción de cada ciclo se define a continuación:

16 CICLO 1: COSECHA (HARVESTING) Figura 3: Ciclo 1 Cosecha El objetivo de este primer ciclo es entender las entidades del negocio, y documentar justo las reglas que sean necesarias para comenzar una implementación. Durante este primer ciclo, el equipo del proyecto desempeña actividades de modelado del negocio, que buscan describir los procesos del negocio y las desiciones aplicadas dentro del alcance de la aplicación. Esta fase ayuda a identificar y evaluar patrones de reglas potenciales. Para comenzar, el equipo de desarrollo divide el dia en 2 partes, en la mañana se realiza una sesión de 2 o 3 horas de obtener reglas de distintas fuentes de información, estas pueden ser descripciones de proceso, entrevistas con los expertos del negocio, descripción de casos de uso, etc. El resto del día se invierte realizando análisis y documentación de las reglas obtenidas, dependiendo del número y complejidad de las reglas, el equipo itera en este ciclo de 2 a 5 días. Uno de los documentos producidos durante esta fase de modelado es la tabla de puntos de decisión, que describe los puntos en el proceso donde se involucran un gran número de decisiones de negocio, estos puntos de decisión representan posibles candidatos a convertirse en un conjunto de reglas.[29] CICLO 2: PROTOTIPADO El ciclo de prototipado involucra preparar la estructura del proyecto, y demarcar como las reglas serán agrupadas en conjuntos. Una vez que se termina con un cierto nivel de descubrimiento de reglas, el equipo de desarrollo puede empezar a implementar la estructura de un conjunto de reglas y puede empezar la escritura de estas mientras que las actividades de descubrimiento y análisis continúan. Figura 4: Ciclo 2 Prototipado

17 Comenzar la escritura de reglas usando herramientas (típicamente un IDE) lo más pronto posible, permite descubrir posibles problemas de diseño y análisis en etapas tempranas del proceso de desarrollo, tal como la construcción de código clásico, aunque las reglas se vean bien en papel, los verdaderos problemas empezaran a surgir durante el proceso de implementación y pruebas. Problemas encontrados durante el prototipado se comunican al equipo de negocio y este ciclo de retroalimentación provee un mecanismo efectivo para construir un conjunto de reglas adecuado y relevante al negocio. Para facilitar que el equipo de desarrollo entiende el conjunto de reglas, pueden trabajar desde la tabla de puntos de decisión producida durante el ciclo de cosecha, cada punto de decisión se mapea a un conjunto de reglas. El arquitecto debe considerar el modelo de datos, el flujo de ejecución de reglas, como se reportaran errores y excepciones, entrada y salida de parámetros usados por el motor para cada conjunto de reglas, y como los resultados de decisión serán reportados al cliente. [29] CICLO 3: CONSTRUCCIÓN En harmonía con el desarrollo basado en pruebas, el objetivo de la fase de construcción es implementar un conjunto de pruebas unitarias con datos reales o realísticos, escribir las reglas que van ser probadas, y probarlas dentro de sus respectivos conjuntos de reglas y su contexto de ejecución objetivo. Figura 5: Ciclo 3 Construcción Construir actividades: Este ciclo de 3 a 4 semanas incluye escritura de actividades diarias, que se pueden ver como un conjunto de pasos involucrando la implementación de los casos de prueba, escritura e implementación de reglas, así como procesos de validación por miembros del equipo. Los ciclos diarios incluyen: Ciclo en escritura y validación al desarrollar reglas y casos de prueba. Ciclo e análisis, diseño, escritura y validación de reglas ejecutables, completar el análisis, realizar pruebas, identificar problemas y resolverlos. Cada 2 días, un ciclo de descubrimiento, análisis, escritura y validación; el descubrimiento será usado para completar el alcance del conjunto de reglas y para identificar diferentes problemas durante implementación.

18 Al final de este ciclo, el modelo de datos usado por las reglas en contexto del conjunto de reglas debería estar por lo menos un 90% completo, la estructura del proyecto debería estar finalizada, y un conjunto de reglas debería ser desplegado para pruebas. El conjunto de reglas puede que solo esté completado en un 40% o 60%, pero los usuarios del negocio o los desarrolladores de reglas pueden elaborar y completar el conjunto en el ciclo 5 (Mejora). Si el conjunto de reglas es muy grande para estar completado en un 40% para un transcurso de 3 semanas, este ciclo puede ser ejecutado múltiples veces, sin embargo, se recomienda mantener este ciclo a 3 semanas, para que se pueda entregar una versión al equipo de pruebas para revisión y ejecución antes de comenzar el siguiente ciclo. [29] CICLO 4: INTEGRACIÓN. El objetivo de este ciclo es desplegar un conjunto de reglas bajo construcción, a un servidor de ejecución para ser probado. La integración de un servicio de decisión y el modelo de dominio de datos, es una tarea importante. Los datos que vienen de una fuente de datos real se envían al motor de reglas de negocio para disparar reglas e inferir decisiones. Durante las fases previas de desarrollo, el equipo de trabajo construye un conjunto de escenarios con datos realísticos, o datos que disparen la ejecución de reglas, estos escenarios de pruebas se ejecutan durante la fase de integración para soportar pruebas de extremo a extremo. [29] Figura 6: Ciclo 4 Integración

19 CICLO 5 MEJORA. El ciclo 5 puede ser visto como la fase de maduración, donde el objetivo es completar y mantener el conjunto de reglas. Este ciclo incluye escritura, validación y despliegue, pero aun podría requerir algunas actividades de descubrimiento con los expertos del negocio para discutir y solucionar algunos problemas o dudas finales. Figura 7: Ciclo 5 Mejora Los actores responsables por completar el conjunto de reglas podrían ser diferentes de aquellos involucrados en los ciclos iniciales. Los miembros de este equipo están más orientados al negocio y son los dueños de los conjuntos de reglas y de las políticas de negocio. Una vez la infraestructura del sistema es implementada por el equipo de desarrollo, ellos pueden completar el conjunto final de reglas a su propio ritmo, inclusive durante una fase de desarrollo, los usuarios de negocio pueden empezar a trabajar en completar sus conjuntos de reglas. Es posible que también se requieran mejoras para el modelo de objetos o el modelo de datos, ya sea añadir nuevos hechos, atributos o entidades. Estas modificaciones pueden seguir el proceso estándar de administración de construcción de software de la aplicación de negocio. No se espera que el equipo de negocio descubra e implemente el 100% de las reglas durante el desarrollo del conjunto de reglas. El alcance de una decisión evoluciona a través del tiempo, el propósito del ciclo 5 es mejorar la calidad y completitud del conjunto de reglas. Sin embargo, el arquitecto de reglas debe diseñar un conjunto de reglas para que cuando no se pueda obtener ninguna decisión a partir de los datos recibidos, se implemente una solución por defecto y permita a los datos ser identificados para futuro análisis. [29]

20 CONSIDERACIONES ADICIONALES: La implementación de un motor de reglas de negocio, cuando va a ser realizada a nivel empresarial, se recomienda personal suficientemente capacitado y con experiencia en el tema, adicionalmente si es la primera vez que se implementará esta tecnología en la empresa, se recomienda no implementarla en el software core del negocio, se recomienda empezar por proyectos pequeños y que no afecten a la actividad principal de la compañía, de esta forma tanto desarrolladores como usuarios finales adquieren conocimiento y experiencia en el uso de estas herramientas, que permitirán una implementación más limpia y completa en proyectos a mayor escala. La implementación de motores de reglas implica costos adicionales en tiempo y recursos, costos que serán retornados en beneficio del software a largo plazo, el uso de estas tecnologías no solo facilita el mantenimiento de la lógica de negocio, sino que facilita el mantenimiento de la aplicación y alarga la vida útil de la misma. Aunque existe documentación acerca de técnicas y metodologías, se recomienda que al implementar estas tecnologías, especialmente a nivel empresarial, los desarrolladores y dueños del negocio busquen asistencia o asesoría de expertos del tema, o por lo menos individuos con dominio del tema a nivel conceptual y técnico, que permitan acelerar el proceso de aprendizaje, y la identificación y solución rápida de posibles errores y problemas al momento del desarrollo.

21 REFERENCIA [1]. BALI, Michal: Drools Jboss Rules 5.0 Developer's guide. Julio [2]. SMITH Howard, FINGAR Peter: Business Process Management: The Third Wave. Abril [3]. DEBEVOISE Tom: Business Process Management with a Business Rules Approach. Mayo 2007 [4]. BROWNE, Paul. Jboss Drools Business Rules. April [5]. MARTÍNEZ FERNÁNDEZ, José Luis: Introduciendo semántica en un proceso de desarrollo de software a través de reglas de negocio. España, h. Tesis Doctoral (Ingeniero de Telecomunicación). Escuela Técnica Superior de Ingenieros de Telecomunicación. Disponible en: < [6]. ALIANTE ZAMBRANO, Cristian Rolando. IBÁÑEZ ORTIZ, Edgardo Alejandro: Desarrollo e implementación de un prototipo de Sistema de administración de reglas de negocio Para telefónica del sur. Chile, h. Trabajo de grado (Ingeniero Civil en Informática). Universidad Austral de Chile. Facultad de Ciencias de la Ingeniería. Disponible en: < [7]. Business rules group (2007), Semantics of Business Vocabulary and Business Rules (SBVR). Disponible en: [8]. Oracle Business Rules, Disponible en: [9]. Open Rules, Business Rules Management System. Disponible en: [10]. AgilePartner S.A. (2004), NxBre.NET Business Rule Engine. Disponible en: [11]. Jboss, Drools. Disponible en: [12]. Metodologia Scrum. Disponible en:

22 [13]. IBM ILog. Disponible en: mid=523. [14]. Fair Isaac, Blaze Advisor. Disponible en: [15]. Microsoft, Microsoft BizTalk Server. Disponible en: [16]. GlassFish. Disponible en: [17]. Apache Software Foundation, The Apache Tomcat Connector. Disponible en: [18]. Delt-R Plataformas de Decisión, BRMS Motores de Reglas de Negocio. Disponible en: [19]. IBM. Disponible en: [20]. Definiciones de Reglas de Negocio. Disponible en: [21]. Reglas de Negocio. Disponible en: [22]. Rules engines, Disponible en: [23]. An introduction to rules engines, Disponible en: [24]. IBM Disponible en: 00/en_US/HTML/ecodmst02.htm#ToC_79 [25]. Rules engines and Declarative Programming Come to Java. Disponible en: [26]. Oracle Business Rules, Disponible en: [27]. Proven practices for enhancing performance: A Q&A for IBM WebSphere ILOG JRules 7.0.x. Disponible en: _vp..sl_redpapers.sl_pdfs.sl_redp4632.pdf

23 [28]. ILOG JRules: Leading the Way in Business Rule Management Systems, Disponible en: JRules50Strengths.pdf [29]. Jérôme Boyer, Hafedh Mili Agile Business Rule Development: Process, Architecture, and JRules Examples. Enero 2011.