mÉtodo para la extracciÓn de reglas de negocio...

1/70

MÉTODO PARA LA EXTRACCIÓN DE REGLAS DE NEGOCIO APLICADOS A CASOS DE USO EN PROCESOS EMPRESARIALES

CECILIA CONTRERAS BAEZ. 1101322 HAROLD ADRIAN BOLANOS RODRIGUEZ. 1101323

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA

ESPECIALIZACIÓN DE PROCESOS PARA EL DESARROLLO DE SOFTWARE SANTIAGO DE CALI

2011

2/70

MÉTODO PARA LA EXTRACCIÓN DE REGLAS DE NEGOCIO APLICADOS A CASOS DE USO EN PROCESOS EMPRESARIALES

Presentado por: CECILIA CONTRERAS BAEZ

HAROLD ADRIAN BOLANOS RODRIGUEZ

Trabajo de Grado presentado como requisito para optar el título de Especialista en Procesos para el Desarrollo de Software

Director: Phd LUIS MERCHÁN PAREDES

UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA

ESPECIALIZACIÓN DE PROCESOS PARA EL DESARROLLO DE SOFTWARE SANTIAGO DE CALI

2011

3/70

TABLA DE CONTENIDO

1 INTRODUCCION ....................................................................................................... 7

2 RESUMEN DEL PROYECTO ........................................................................................ 8

3 PLANTEAMIENTO DEL PROBLEMA ............................................................................ 8

4 OBJETIVOS ............................................................................................................... 9 4.1 Objetivo General ................................................................................................................................................ 9 4.2 Objetivos Específicos ....................................................................................................................................... 9

5 JUSTIFICACION ......................................................................................................... 9

6 REFERENTE TEÓRICO .............................................................................................. 10 6.1 Historia evolución de reglas de negocio ............................................................................................... 10 6.2 ASPECTOS DE REGLAS DE NEGOCIO ..................................................................................................... 12

6.2.1 Diferentes tipos de Reglas de Negocio .................................................................................................. 12 6.2.2 Las diferentes representaciones de Reglas de Negocio ................................................................. 12 6.2.3 Los diferentes actores ................................................................................................................................... 12

6.3 CONTEXTO REGLAS DE NEGOCIO ........................................................................................................... 13 6.3.1 ¿Qué es una regla de negocio? .................................................................................................................. 13 6.3.2 ¿Cómo las reglas de negocio se relacionan con los procesos de negocio? ............................ 13 6.3.3 ¿Qué son los motores de reglas? .............................................................................................................. 13 6.3.4 Cuándo utilizar un motor de reglas de negocio? ............................................................................. 15 6.3.5 ¿Cuál es la razón de las reglas de negocio y el código fuente? .................................................. 16 6.3.6 ¿Cuáles son la mejores practica para administrar las reglas de negocio? .......................... 16

6.4 METODO DE APALANCAMIENTO............................................................................................................ 17 6.4.1 TABLAS DE DECISION .................................................................................................................................. 17 6.4.2 Lectura de una Tabla de Decisión ........................................................................................................... 18

7 DISEÑO Y METODOLOGIA DEL PROYECTO .............................................................. 19 7.1 Integración de modelo propuesto ........................................................................................................... 19

7.1.1 Modelado del negocio ................................................................................................................................... 22 7.1.2 Identificación de roles del entorno del negocio ................................................................................ 23

7.2 Semántica propuesta .................................................................................................................................... 25 7.2.1 Términos lógicos ............................................................................................................................................ 30 7.2.2 Clasificación de regla de negocios según la semántica ................................................................. 31

7.3 Base Teórica del Método Propuesto ....................................................................................................... 32 7.3.1 Caso Base de Aplicación .............................................................................................................................. 32 7.3.2 ¿Como llenar una tabla de decisión? ..................................................................................................... 32 7.3.3 Construcción de la Tabla ............................................................................................................................. 33 7.3.4 Depuración de tabla de decisión ............................................................................................................. 33 7.3.5 Ordenamiento de tabla de decisión ........................................................................................................ 36 7.3.6 Entradas limitadas, ampliadas y mixtas ............................................................................................. 37 7.3.7 Transformación de Reglas .......................................................................................................................... 38

7.4 Método Propuesto .......................................................................................................................................... 41 7.5 Aplicación de método (Caso de estudio) .............................................................................................. 43

7.5.1 Caso de uso ........................................................................................................................................................ 43

4/70

7.5.2 Listado de Condiciones y Acciones .......................................................................................................... 54 7.5.3 Maduración de Tablas .................................................................................................................................. 58 7.5.4 Expresión de las Reglas de Negocio ....................................................................................................... 62

8 RECOMENDACIONES .............................................................................................. 64 8.1 Analistas de Software ................................................................................................................................... 64 8.2 Jefes de Desarrollo de Software ............................................................................................................... 65

9 CONCLUSIONES ...................................................................................................... 66

10 TRABAJOS FUTUROS ............................................................................................ 68

11 BIBLIOGRAFIA ...................................................................................................... 69

12 GLOSARIO ............................................................................................................ 70

5/70

LISTA DE FIGURAS Figura 1: Cuadrante Tablas de Decisión ............................................................... 17 Figura 2: Modelo reglas de negocio ...................................................................... 20 Figura 3: Trazabilidad entre los modelos de negocio y de requisitos. ................... 21 Figura 4: Seudocodigo .......................................................................................... 40

6/70

LISTA DE TABLAS Tabla 1: Tabla de decisión básica ......................................................................... 18 Tabla 2: Semántica de eventos, procesos e impacto ............................................ 29 Tabla 3: Construcción de tabla .............................................................................. 33 Tabla 4: Unificación de reglas por inferencia......................................................... 33 Tabla 5: Reglas independientes y dependientes ................................................... 34 Tabla 6: Tabla mixta redundante ........................................................................... 34 Tabla 7: Eliminación de redundancias ................................................................... 35 Tabla 8: Reglas independientes ............................................................................ 35 Tabla 9: Ordenamiento de tabla de decisión ......................................................... 36 Tabla 10: Tabla ordenada ..................................................................................... 36 Tabla 11: Remplazo de números a letras .............................................................. 37 Tabla 12: Tabla ampliada o mixta ......................................................................... 37 Tabla 13: Transformación de reglas ...................................................................... 38 Tabla 14: Depuración de tablas ............................................................................. 39 Tabla 15: Conversión en seudocodigo .................................................................. 39 Tabla 16: Tabla de condiciones ............................................................................. 54 Tabla 17: Tabla de acciones ................................................................................. 55 Tabla 18: Tabla resultante ..................................................................................... 56 Tabla 19: Tabla resultante 1ra iteración ................................................................ 58 Tabla 20: Tabla resultante 2da iteración ............................................................... 60 Tabla 21: Tabla resultante 3ra iteración ................................................................ 60 Tabla 22: Tabla resultante refinada ....................................................................... 61

7/70

1 INTRODUCCION

El constante cambio de las empresas, en busca de mantenerse y/o estar a la vanguardia de los negocios, hace que la “estrategia” actualmente busquen una innovación del negocio, esto implica revisar y reinventar el modelo del negocio, generar nuevas ofertas de mercados cambiantes en el corto plazo y sobre toda una plataforma tecnológica que apoye todas estas nueva ideas. El auge de temas como BPM (Business Process Management), Cloud Computing, Reglas de negocios, SOA (Arquitectura Orientada a Servicios) son fichas claves para estas innovación, si bien cada una de ellas se ha creado como entes independientes, el armar el ajedrez es la respuesta que permita con facilidad y versatilidad el liderazgo en el negocio, pero estos temas no son nuevos son la mejora de BI (Business Intelligent), reingeniería entre otras. La creación del valor agregado en tiempos de cambio, está en la generación, control y manejo de las reglas de negocio, entendiéndose como “la expresión que pueden ser usada equivalentemente entre la representación del negocio y la tecnología”. Para poder alinear los sistemas a las necesidades del negocio, hay que buscar la máxima automatización, pero sin arriesgar las posibilidades de reacción ante los imprevistos y sin que el costo económico opaque los beneficios. Herramientas como BPM (Business Process Management), permitirán que una vez construido el modelo del proceso este se mantenga. La innovación del modelo de negocio reside en la recombinación de los recursos existentes de una empresa y sus socios, y no precisa de una inversión significativa en costos, pues bien la cantidad de soluciones Open Source facilita la automatización de las mismas, es la imaginación, la capacidad de reinventar , de adoptar nuevos pensamientos acorde las nuevas tecnologías, es así como esta propuesta para generar reglas de negocio basados en tablas de decisión como un avance a los nuevos retos empresariales requiere de convicción y visión que estas herramientas permiten agilizar y afrontar los cambios permanente del negocio.

8/70

2 RESUMEN DEL PROYECTO

El proyecto busca definir el mejor método para la extracción de reglas de negocio a través de la gestión de tablas de decisión empleando la experiencia del recurso humano que conoce este conjunto de artefactos debe interactuar en un orden específico para realizar una especificación e identificación aproximada para la extracción de reglas de negocio. En el proyecto se emplearán prácticas de levantamiento de requerimientos, métodos utilizados en la gestión de tablas de decisión y buenas prácticas en la exploración de reglas de negocio El objetivo de este proyecto es recuperar el “know how” de los procesos y plasmarlo en las reglas de negocio.

3 PLANTEAMIENTO DEL PROBLEMA

Actualmente cuando una empresa enfrenta el reto de modernizar el proceso de desarrollo de software involucra temas de hardware y las mejores prácticas de generación de software; estas prácticas determinan lenguajes de programación, bases de datos, modelos de capas, multiniveles, metodologías agiles de desarrollo, aseguramientos de calidad en los procesos y sobre todo versatilidad para ajustarse en tiempos cortos a las nuevas demandas del mercado, a los casos de negocio o casos de uso. Para resolver esta problemática de manera ágil y eficaz el mercado ha creado soluciones como los “motores de reglas de negocio”, los cuales fueron creados para flexibilizar y para dejar en manos de los stakeholders la redefinición de los casos de negocios cuando considere conveniente. Ahora bien, incluir reglas de negocios en los motores resulta ser sencillo cuando se está iniciando ò desarrollando software desde cero, ò cuando es un componente nuevo, ò cuando la empresa posee una adecuada y actualizada documentación de todos sus procesos; pero la realidad es que las empresas que desean dar el salto significativo tienen las reglas de negocios en el conocimiento que posee su recurso humano, en las base de datos y embebida en los programas de sus sistemas legados, como es el caso de la empresa en la cual adelantamos el presente trabajo.

9/70

4 OBJETIVOS

4.1 Objetivo General Proponer un método para la identificación de reglas de negocio basado en la gestión de tablas de decisión aplicados a los casos de uso en procesos empresariales.

4.2 Objetivos Específicos

Aplicar el método de gestión de tablas de decisión para obtener y validar las reglas de negocio.

Identificar buenas prácticas en procesos de extracción de reglas de negocio.

Recomendar la semántica a utilizar en las declaraciones de los casos de uso.

Madurar los casos de uso de acuerdo a su cantidad de reglas de negocio

5 JUSTIFICACION

La implementación de este proyecto expondrá el “Norte” que servirá de guía para la identificación de reglas de negocio que se han adquirido con el pasar del tiempo por ejecutores de los procesos y permitirá a la empresa ganar independencia con la información obtenida y perfilar su automatización, lo cual se traduce en agilidad y respuestas oportunas. Este proyecto servirá igualmente como referente para adoptarse como método en la abstracción de reglas de negocio e iniciar proyectos que tengan este enfoque. Finalmente el proyecto se propone a corto plazo como referente para implementar una integración de desarrollo para otros framework en el ciclo de desarrollo de software.

10/70

6 REFERENTE TEÓRICO

6.1 Historia evolución de reglas de negocio

Los inicios: El motor inferencial1

1950, Allen Newell, un recién egresado de la Universidad de Princeton y trabajando en la Corporación RAND para realizar trabajos de investigación en teoría matemática y procesamiento de información fue uno de los pioneros en este campo. En una presentación del investigador Oliver Selfridge, donde exponía una introducción a su trabajo en reconocimiento de patrones, y cómo la interacción de unidades simples pueden lograr un comportamiento complejo, “le prendió el foco” a Newell, quien inmediatamente empezó a preguntarse en la posibilidad de "enseñar a las computadoras a pensar".

1955 : Newell, el programador Cliff Shaw y el profesor en economía Herbert Simón, desarrollaron la teoría e implementación de Logic Theoriste un programa que demostraría eventualmente 38 teoremas del Principia Mathematic.

1956, el también investigador del MIT John McCarthy organizó una conferencia donde Simón y Newell demostraron su creación; el evento marcó el inicio de una de las ramas de la ciencia informática más polémicas de la actualidad: la "Inteligencia Artificial" (Artificial Intelligence – AI). De hecho, McCarthy se inventó el término para el título de la conferencia, y actualmente se le reconoce su autoría.

Originalmente, Logic Theorist consistía de un conjunto de enunciados matemáticos/lógicos (también llamado base de conocimientos) y un árbol de búsquedas. Para evitar que la construcción del árbol creciese exponencialmente, los diseñadores decidieron "podar hojas" e impedir que el programa siguiera caminos que difícilmente llevarían a la solución. Newell y Simon decidieron nombrar a estas "reglas de sentido común" como Heurísticas. Así, con una base de conocimientos, un árbol de búsquedas y una serie de heurísticas, nació el primer motor inferencial y el lenguaje denominado IPL (Information Processing Language – Lenguaje para Procesamiento de Información),

1 Thortongale.com (Allen Newell and Business Rules)

11/70

Los Sistemas Expertos2

1975 : Edward Feigenbaum y otros programadores del Heuristic Programming Project (Proyecto de Programación de Heurísticas) en la Universidad de Stanford, desarrollaron el sistema Dendral, que con base en un motor inferencial permitía identificar moléculas orgánicas desconocidas. Dendral es reconocido como el primer sistema experto: un programa que mediante una serie de reglas preestablecidas, comparación de resultados y aplicación de nuevas reglas de acuerdo a dicho resultado, facilitaba la solución a problemas que requerían un gran conocimiento sobre un tema específico. A partir de Dendral se produjo una explosión de sistemas expertos, primero en el ámbito académico y posteriormente en el ámbito comercial. John McCarthy tomando como base IPL crea el lenguaje de programación LISP en 1958. Un poco más tarde, LISP se convertiría en el lenguaje de rigor para codificar motores inferenciales y sistemas expertos, incluyendo Dendral.

Deshaciéndose de LISP

Para el año de 1984, el departamento de investigación en Inteligencia Artificial de la agencia espacial norteamericana (NASA) había implementado varios prototipos de sistemas expertos como apoyo hacia otras áreas de la organización. Sin embargo, casi nadie los utilizaba precisamente porque habían sido desarrollados en LISP

1985 se crea un lenguaje propio para sistemas expertos basado en C. denominado CLIPS (C Language Integrated Production System).

Para 1987, CLIPS se había convertido en la mejor herramienta para desarrollar y ejecutar los sistemas expertos que necesitaba la NASA.

En 1991 CLIPS v5.0 introdujo y popularizó un nuevo paradigma: la Programación Orientada a Objetos.

Finalmente, el Dr. Ernest Friedman-Hill, investigador del Laboratorio Nacional Sandia, desarrolló a mediados de 1995 la herramienta JESS (Java Expert System Shell – Interfaz de Sistemas Expertos en Java), un motor inferencial basado en CLIPS y el primero programado en Java. JESS 1.0 se convirtió en la prueba de concepto que demostró la factibilidad de construir motores inferenciales y sistemas expertos en Java: actualmente existe una gran variedad de estas herramientas, e incluso las hay en modalidad opensource.

2 Everac99.wordpress.com

12/70

6.2 ASPECTOS DE REGLAS DE NEGOCIO

6.2.1 Diferentes tipos de Reglas de Negocio

Reglas de intención, alias reglas declarativas

Reglas internas o de proceso, los procesos de negocio conocidos y las normas imperativas empresariales

Normas de aplicación de otras reglas

6.2.2 Las diferentes representaciones de Reglas de Negocio

Declarativas o semánticas

Diagramas

Tablas

Modelos

Programa de código

6.2.3 Los diferentes actores

Los empresarios y administradores

Arquitectos de sistemas y diseñadores

Los programadores

Los sistemas de reglas de negocio3

3 http://hendricksandassociates.net/

13/70

6.3 CONTEXTO REGLAS DE NEGOCIO

6.3.1 ¿Qué es una regla de negocio? “Las reglas del negocio o conjunto de reglas de negocio describe las políticas, normas, operaciones, definiciones y restricciones presentes en una organización y que son de vital importancia para alcanzar los objetivos misionales. Ejemplos de reglas de negocio: "Un cliente al que facturamos más de 10.000 al año es un cliente de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a 3.000". Las organizaciones funcionan siguiendo múltiples reglas de negocio, explícitas o tácitas, que están embebidas en procesos, aplicaciones informáticas, documentos, etc. Pueden residir en la cabeza de algunas personas o en el código fuente de programas informáticos”4.

6.3.2 ¿Cómo las reglas de negocio se relacionan con los procesos de negocio?

Las reglas de negocio son consideradas las “arterias” de cada organización, en el amplio espectro empresarial estas se encuentran involucradas en cada una de las decisiones tomadas; “Las organizaciones funcionan siguiendo múltiples reglas de negocio, explícitas o tácitas, que están embebidas en procesos, aplicaciones informáticas, documentos, etc. Pueden residir en la cabeza de algunas personas o en el código fuente de programas informáticos. En los últimos años se viene observando una tendencia a gestionar de forma sistemática y centralizada las reglas de negocio, de forma que sea fácil y sencillo consultarlas, entenderlas, utilizarlas, cambiarlas, etc. Para ello se puede utilizar un motor de reglas de negocio”5

6.3.3 ¿Qué son los motores de reglas? Cualquier aplicación tiene reglas (o reglas de negocio)6. Desde los inicios de las computadoras el objetivo ha sido resolver múltiples necesidades, entre ellas las de procesar información para un ramo especifico (nomina, finanzas, recursos humanos), ramos en los que se han tenido que codificar indistintamente reglas de negocio.

4 http://es.wikipedia.org/wiki/Reglas_de_negocio

5 http://www.negocio.us/negocios/negocios/empresas/tipos-y-reglas-en-negocios/

6 http://www.comunidadjava.org/?q=node/79

14/70

Este detalle surge, cuando el usuario que ayudó en especificar el sistema, requiere cambiar dichas reglas, pese a que normalmente están como parte del código. El proceso de realizar el cambio, tiene entonces que pasar desde la fase de compilación, empaquetamiento y liberación a producción, resultando que cualquier cambio a las reglas, por mínimo que sea, no es cuestión de minutos, sino de horas o días. El objetivo del motor de reglas de negocio, es proporcionar una infraestructura desacoplada del código fuente, de tal manera, que el sistema consume servicios al motor, para evaluar cada una de las reglas. En el motor de reglas de negocio, residen las reglas que se detectan para los sistema, paralelamente se puede construir un sistema para que el usuario pueda definir sus reglas, cambiarlas y aplicarlas en el motor de reglas. Esto permite que los desarrolladores no sean los principales responsables en cambiar reglas ya hechas y no tiene la "responsabilidad" de errores que se puedan presentar, ya que la escalabilidad de alinear el negocio con las estrategias empresariales es tomada por las directivas. Básicamente un motor de reglas de negocio está compuesto de tres elementos: un conjunto de reglas, el espacio de trabajo (o el conocimiento que tiene), y el procesador de reglas. Las reglas son sentencias de la forma IF-THEN, de tal manera que si se cumplen todas las condiciones del IF se ejecutan todas las acciones del THEN. El espacio de trabajo es donde se guarda el conocimiento (objetos Java) que el motor utilizará para decidir que reglas deben activarse7. Dentro de las reglas pueden existir conflictos. Un conflicto es cuando varias reglas distintas pueden activarse para el mismo conjunto de hechos y, la aplicación de dichas reglas, pueden tener resultados contradictorios. Algunas de las estrategias para resolver conflictos son: asignarle una prioridad a cada regla, estrategias FIFO o LIFO, aplicarlas en el orden en que se declararon o aplicarlas en orden aleatorio. Los motores de reglas de negocio pueden utilizarse, por ejemplo, para desarrollar prototipos rápidos o, incluso, para implementar la lógica de la aplicación. También pueden utilizarse como parte de un sistema de workflow8.

7 http://www.planetacodigo.com/planeta/1308/drools-i-introduccion-a-los-motores-de-reglas-de-

negocios/ 8 http://www.planetacodigo.com/planeta/1308/drools-i-introduccion-a-los-motores-de-reglas-de-

negocios/

15/70

6.3.4 Cuándo utilizar un motor de reglas de negocio? Cuando quieran enunciar las reglas de un sistema, de tal manera, que se puedan reutilizar, desacoplar del código y permitir que el usuario que sabe las reglas, las pueda modificar. Parte de la tecnología que respalda a estos motores, esta fundamentada en un algoritmo utilizado por los sistemas expertos9, RETE, que optimiza el proceso de coincidencia de las reglas. La utilización del motor de reglas de negocio debe ser alimentado por medio de las reglas encontradas del sistema y diseñado para soportar el cambio. Normalmente, estos productos ofrecen sistemas para construir la aplicación de mantenimiento de las reglas.

9 http://es.wikipedia.org/wiki/Sistema_experto

16/70

6.3.5 ¿Cuál es la razón de las reglas de negocio y el código fuente?

Las reglas de negocio abundan en el código fuente de las aplicaciones actuales, aun que no es posible erradicarlas de las aplicaciones, sí se deben extraer aquellas que tienen una injerencia directa con el proceso de negocio, no es necesario extraer la mayor cantidad de reglas de negocio, es necesario identificar el proceso y extraer las reglas del propio entorno en el cual se desempeña el mismo. Las reglas han sido relegadas a puntos de decisión, sin embargo estas han madurado en ambientes BRMS (Business Rules Management System) donde la interacción es mas intuitiva y normalmente viene acompañado de entornos gráficos que le permiten al usuario tener una abstracción mejor de cada regla. Intentar extraer las reglas de negocio de un sistema legado (Sistemas actuales de la empresa u organización), es todo un reto y normalmente este tipo de proyectos son difíciles de gestionar, pues las limitaciones que suelen presentarse en codificación, obstaculizan la extracción.

6.3.6 ¿Cuáles son la mejores practica para administrar las reglas de negocio?

La implementación de un catalogo empresarial de reglas es una muy buena practica, si embargo esta debe llevarse a cabo a través de un sistema, normalmente estos sistemas vienen como herramienta de los motores de reglas y es costumbre que los motores implemente su propia administración; el planteamiento de llevar una administración manual no es una opción a la hora de iniciar un proyecto de este tipo.

17/70

6.4 METODO DE APALANCAMIENTO

6.4.1 TABLAS DE DECISION Una tabla de decisión es una herramienta que va a servir para representar de manera más fácil la lógica de un problema cuando esta es más o menos complicada. Para ello se trata de identificar en el problema las acciones que hay que ejecutar y las condiciones que se tienen que cumplir para ejecutar esas acciones. Las acciones normalmente se identifica a través de los verbos, y las condiciones van a ser las condicionales. La tabla va a tener cuatro partes, como se aprecia en la Figura 1:

Figura 1: Cuadrante Tablas de Decisión

Conjunto de condiciones: Son las condiciones que intervienen en el problema. Entrada de condiciones: Son las combinaciones posibles entre los valores de las condiciones. SI, NO, DA IGUAL. Conjunto de acciones: Abarca todas las acciones que se tienen que ejecutar cuando se cumple un conjunto dado de condiciones. Salida de ejecución: Se determina cuando se ejecuta cada acción. La regla de decisión es una combinación de un estado en la entrada de condiciones y de una o más acciones asociadas siendo N el número de condiciones y considerándolas como binarias (SI/NO) habrá un número máximo de 2 elevado a N reglas. Cada regla equivale desde el punto de vista de algoritmos a una estructura si…entonces…fin si, y en cada momento solo se puede cumplir una regla. Las

18/70

tablas de decisión las podemos usar para controlar la lógica de control de un algoritmo10. Las tablas de decisión son una herramienta que sintetiza procesos en los cuales se dan un conjunto de condiciones y un conjunto de acciones a tomar según el valor que toman las condiciones. Pueden utilizarse en los distintos momentos del proyecto: exposición de los hechos, análisis del sistema actual, diseño del nuevo Sistema y en el desarrollo. Se emplean desde mediados de la década de los cincuenta, desarrolladas por la General Electric para el análisis de funciones de la empresa11.

6.4.2 Lectura de una Tabla de Decisión Para realizar la lectura de una tabla de decisión, se inicia identificando las restricciones (Cx), las Acciones (Ax) y su aplicación en cada regla para iniciar su interpretación. De acuerdo con la Tabla 1, en la regla 1 si se cumplen las condiciones 1 y 2 y No se cumple la condición 3, deberán emprenderse las acciones 1 y 4. De igual forma en la regla 2, Si se cumple la condición 1 y No se cumple la condición 2 y se cumple la condición 3, deberán emprenderse las acciones 2 y 3.

Tabla 1: Tabla de decisión básica

10

Facultad de ingeniería universidad nacional de JUJUY 11

Trabajo de Calidad de Software, Autor Alfonzo Fernández, Universidad San Buenaventura (2011)

19/70

7 DISEÑO Y METODOLOGIA DEL PROYECTO

7.1 Integración de modelo propuesto Esta parte del trabajo presenta una estrategia para obtener de modo sistemático el modelo de casos de uso y el modelo conceptual, a partir del modelado del negocio basado en diagramas de actividades UML (Lenguaje de modelamiento unificado). Después de determinar los procesos del negocio de la organización bajo estudio, y describir sus flujos de trabajo mediante diagramas de actividad, los casos de uso son identificados y estructurados a partir de las actividades de cada proceso, mientras que los conceptos que aparecen en el modelo conceptual se obtienen a partir de los datos que fluyen entre las actividades. Además, las reglas del negocio son identificadas e incluidas en un glosario, como parte de la especificación de datos y actividades. Un aspecto destacable de la propuesta es el hecho de que el modelado conceptual y el de casos de uso se realizan en paralelo, haciendo más fácil la identificación y especificación de casos de uso adecuados. Tanto el modelado de casos de uso como el modelado conceptual forman parte de la fase de análisis de requisitos de un modelo de procesos completo en cuya definición estamos trabajando. A continuación se describen las relaciones entre los diferentes modelos de negocio: El modelo de la visión de negocio: Describe la estrategia del negocio, enfocando la atención en la meta, la estructura y los problemas que deben ser solucionados para lograr esas metas. El modelo del proceso de negocio: Describe cómo los procesos están dispuestos para lograr las metas de la empresa, es decir, describe cómo los procesos de la empresa interactúan y se aclaran en procesos de entradas y salidas. El modelo de regla de negocio: Define y mantiene explícitamente formulada de la mejor manera las reglas del negocio así como también una parte de las reglas que están implícitas en otros modelos. Los actores del negocio y modelo de recursos: Se enfoca en las estructuras de recursos y sus relaciones con actores, procesos, metas y otros componentes del modelo de la empresa. Los conceptos del modelo de negocio: Establece un vocabulario común para todos los conceptos que comprenden el ambiente de negocio (por ejemplo los

20/70

productos, los servicios, los recursos de información, etcétera.). Ayuda a evitar inconformidades e interpretaciones diferentes de términos usados en el negocio. El siguiente esquema (Ver Figura 2) presenta las interrelaciones entre los diferentes modelos que se basa este enfoque, y que representa una innovación del modelo del negocio. Posteriormente se presenta en detalle como se llega a las reglas de negocio iniciando del proceso del modelo negocio y pasando por los casos de uso.

Figura 2: Modelo reglas de negocio

Normalmente, los casos de uso son elicitados de forma intuitiva a partir de la especificación del sistema y, posteriormente, las entidades del modelo conceptual se extraen a partir de las especificaciones de los casos de uso. A continuación se presenta el estudio realizado por el Grupo de Investigación de Ingeniería de Software de la Universidad de Murcia, en el cual explican detalladamente una propuesta para obtener de forma sistemática tanto el modelo de casos de uso como el modelo conceptual, a partir de un modelo del negocio, de acuerdo con el esquema mostrado en la Figura 3 se toman apartes de la propuesta.

suppo

rts, uses, req

uires

mo

tivates, req

uires

RESOURCES AND ACTORS

MODEL

CONCEPTS MODEL

BUSINESS PROCESS MODEL

BUSINESS VISION MODEL

BUSINESS RULE MODEL

defines terms of defines, is responsible for

defines, refers to triggers, controls, refers to

uses supports

Fuentes: Enterprise model and its sub-models.

21/70

Figura 3: Trazabilidad entre los modelos de negocio y de requisitos.12

Tomando como base la Arquitectura de Tres Modelos de OOram, el modelado del negocio se realiza mediante diagramas de actividades UML. Una vez determinados los procesos de negocio de la organización, y descritos sus flujos de trabajo mediante diagramas de actividades, los casos de uso se elicitan y estructuran a partir de las actividades de cada proceso, mientras que las entidades del modelo conceptual se obtienen de los datos que fluyen entre tales actividades.

12

De los Procesos del Negocio a los Casos de Uso, Grupo de Investigación de Ingeniería del Software - Departamento de Informática y Sistemas, Facultad de Informática. Universidad de Murcia España.

22/70

Además, se identifican las reglas del negocio y se incluyen en un glosario como parte de la especificación de los datos y las actividades. Un aspecto notorio de la propuesta es que el modelado de casos de uso y el modelado conceptual se realizan al mismo tiempo, haciendo más fácil, por tanto, la identificación y especificación de los casos de uso adecuados.

7.1.1 Modelado del negocio Para conseguir sus objetivos, una empresa organiza su actividad por medio de un conjunto de procesos de negocio. Cada uno de ellos se caracteriza por una colección de datos que son producidos y manipulados mediante un conjunto de tareas, en las que ciertos agentes (por ejemplo, trabajadores o departamentos) participan de acuerdo a un flujo de trabajo determinado. Además, estos procesos se hallan sujetos a un conjunto de reglas de negocio, que determinan las políticas y la estructura de la información de la empresa. Por tanto, la finalidad del modelado del negocio es describir cada proceso del negocio, especificando sus datos, actividades (o tareas), roles (o agentes) y reglas de negocio. El primer paso del modelado del negocio consiste en capturar los procesos de negocio de la organización bajo estudio. La definición del conjunto de procesos del negocio es una tarea crucial, ya que define los límites del proceso de modelado posterior. En primer lugar, se consideran los objetivos estratégicos de la organización. Teniendo en cuenta que estos objetivos van a ser muy complejos y de un nivel de abstracción muy alto, serán descompuestos en un conjunto de subobjetivos más concretos, que deberán cumplirse para conseguir el objetivo estratégico. Estos subobjetivos pueden a su vez ser descompuestos en otros, de manera que se defina una jerarquía de objetivos. Para cada uno de estos subobjetivos de segundo nivel se debe definir un proceso de negocio que deberá dar soporte a dicho subobjetivo. Se representa cada proceso del negocio como un caso de uso del negocio, que inicialmente será descrito de forma textual.

23/70

7.1.2 Identificación de roles del entorno del negocio Una vez se han identificado los procesos de negocio, es preciso encontrar los actores involucrados en su realización. Cada uno de estos actores del negocio desempeña cierto papel (juega un rol) cuando colabora con otros para llevar a cabo las actividades que conforman dicho caso de uso del negocio. De hecho, se identifican los roles que son jugados por agentes de la propia empresa (que incluyen trabajadores, departamentos y dispositivos físicos) o agentes externos (como clientes u otros sistemas). Por el momento nos centraremos en este último tipo de roles, con los que la organización interactúa para llevar a cabo sus procesos de negocio. En la arquitectura de tres modelos de OOram se incluye un modelo del negocio representado mediante una vista proceso basada en el estándar IDEF0, en la cual se muestra el flujo de trabajo a realizar para conseguir cierto objetivo de la organización, indicando qué roles realizan cada actividad y cuáles son los datos requeridos y producidos por cada actividad. Estos diagramas son útiles para modelar casos de uso del negocio. Estos diagramas pueden adaptarse a UML (Lenguaje de modelamiento unificado) utilizando diagramas de actividades swimlanes. Para tener una visión general de los diferentes procesos de negocio de la organización, puede construirse un diagrama de casos de uso del negocio, en el cual aparece cada proceso del negocio como un caso de uso. Este diagrama permite mostrar los límites y el entorno de la organización bajo estudio. Sólo se mostrarán en este diagrama los actores del negocio correspondientes a los roles externos al sistema, de forma que los procesos de negocio en los que sólo tomen parte roles internos a la organización no estarán conectados a ningún actor. La descripción de los procesos de negocio debe permitir:

Identificar decisiones

Integrar decisión de servicios

Identificar la automatización de decisiones con reglas de negocio

Analizar las reglas

Potenciar el negocio para manejar las reglas.

Analíticamente mejorar las reglas.

Sumar entendimiento profundo

Optimizar y adaptar a nuevos cambios

Categorización y comparación son “validación-predicados“ , estas son

estrictamente falso ò verdadero

La computación y el control son cosas de predicados de transformación que

la búsqueda y la asignación de los datos.

24/70

Completar un panorama de decisión está realizado adentro colocado en regla.

Todo es modelado en un objeto de negocio o un caso de uso.

Hay tres capacidades del negocio de alto nivel en la cual cada uno tiene su propio conjunto de requisitos de negocio y según los casos de uso estimandos cuál semántica de negocio tiene aporte del cliente:

Representar y compartir las reglas comerciales por las cuales unas organizaciones son manejadas; los vocabularios de negocio surgieron para comunicarse en el transcurso del tiempo para manejar la organización y se tomaron como la base para la definición de las reglas de negocio.

Negociar la provisión de servicios de sistema de información con relación a datos y el contenido del documento y el negocio rigen implementación:

o La unidad /área - Los servicios requeridos (el cliente - comercial) - Los servicios previstos (el proveedor - las organizaciones de

sistemas de información, ambas internas y externas).

Apalancar las reglas comerciales y los vocabularios comerciales en los cuales son basados ambos para proveer mejoran apoyo de sistemas de información del negocio y para mejorar la flexibilidad, la calidad y la eficiencia de los sistemas de información

El negocio semántico es la mejor propuesta de estándares que existe para ocuparse de los requisitos de negocio y casos de uso para dos de las anteriormente citadas tres capacidades de negocio de alto nivel y proveer la creación comercial en la cual para lograr la tercera parte donde la sintaxis y lo semántico se encuentran simplificados al máximo para expresar la lógica de una aplicación de propósito concreto.

25/70

7.2 Semántica propuesta

En las empresas existen diferentes fuentes que pueden utilizarse para extraer conocimiento implícito. La utilizada para este estudio en particular y una de las más importantes son los Casos de Usos que son la base de la elicitaciòn de requisitos. El enfoque para descubrir las reglas de negocio consiste en una técnica de dominio del negocio basada en reglas explícitas que son escritas y expresadas en lenguaje claro, cercano al natural y separadas de los datos de la aplicación. Recordemos que una de las bases de los casos de uso o tener inicialmente identificado el proceso sobre el cual se va aplicar esta metodología que debe cumplir un conjunto de actividades, tareas organizadas que permitan documentar, ejecutar y evaluar de manera eficiente las acciones necesarias para dicho proceso. La sistematización ò escritura de los mismos se implementa en herramientas propias para este fin. Para iniciar su ejecución deben considerarse los siguientes pasos:

Seleccionar el proceso sobre el cual se busca extraer el conjunto de reglas de negocio.

Verificar que el proceso está alineado con la estrategia de la organización

Definir el objeto y propósito del proceso.

Identificar y definir formas y símbolos.

Descripción utilizando proposiciones.

Visualizar las proposiciones.

Identificar operadores lógicos.

En las declaraciones, combinar valores lógicos.

Identificar las definiciones tomadas por cada decisión.

Identificar y clasificar los requisitos.

Revisar nuevamente la definición y respuestas de las decisiones por cada etapa.

Definir los parámetros que se controlarán y se manejarán: o Clasificación o Cálculo o Comparación o Control

26/70

La secuencia de los pasos descritos, depende del modelado de proceso de negocio y en la especificidad del caso, así como en la herramienta sobre el método utilizado en su escritura (UML, Escenarios, Plantillas). Pare este trabajo se consideran como básicos los tres elementos enunciados. Lo anterior permite que en cada proceso se puede distinguir entre el flujo básico o normal de la interacción y los posibles flujos alternativos. Para mejorar la legibilidad, es conveniente asociar varios escenarios a un mismo caso de uso del negocio, en lugar de mostrar en una única secuencia todas las posibilidades. En una organización, tanto los procesos como los datos que estos manejan, están restringidos por las reglas del negocio. Con el fin de tener en cuenta todos los tipos de reglas que aparecen en la especificación de requisitos, se ha utilizado la clasificación descrita por James Odell,, que distingue entre reglas de restricción (reglas de estímulo-respuesta, reglas de restricción de operación y reglas estructurales) y reglas de derivación. De acuerdo con esta clasificación, se recoge de manera explícita cada tipo de regla en el modelo del negocio mediante la especificación de las actividades y objetos de información que aparecen en los diagramas de proceso. Estas especificaciones se reúnen en un glosario. Por otro lado, la especificación de la semántica de cada actividad contendrá: origen (actividades que la preceden), agente (responsable de llevar a cabo la actividad), y pre y post-condiciones (que establecen qué tiene que cumplirse antes y después de la actividad). Esta última parte se corresponde con las reglas de operación, mientras que las reglas de estímulo-respuesta quedan reflejadas mediante el origen, donde se expresa el orden entre las actividades. El glosario tendrá una estructura de hipertexto (referencias-cruzadas) con el objeto de mantener las relaciones de trazabilidad entre los procesos del negocio y las clases y los casos de uso que especifican la funcionalidad del sistema. Debemos señalar que algunos casos de uso no se obtendrán directamente a partir de los diagramas de proceso. Estos nuevos casos de uso se detectarían al describir los casos de uso identificados y adquirir un mayor conocimiento sobre los requisitos que deben ser soportados, y representarían funciones que debe llevar a cabo el sistema para lograr algún objetivo asociado con algún caso de uso ya existente. Los procesos de negocio de la organización se identifican partiendo de los objetivos propuestos por Cockburn, y se describen mediante flujos de actividades que se representan mediante diagramas de actividades UML. De este modo, los casos de uso del sistema se obtienen a partir de las actividades de los procesos del negocio y se organizan jerárquicamente, de acuerdo con lo indicado por Korson.

27/70

Las clases del modelo conceptual se obtienen a partir de los objetos de información que fluyen entre las actividades. Una característica importante en este enfoque, es que el modelado de los casos de uso del sistema y el modelado conceptual se realizan en paralelo, de acuerdo con Korson, quien establece que esto es crucial para obtener casos de uso correctos, puesto que es necesario entender bien el dominio para poder escribir casos de uso que sean realmente útiles. A la vez que se realiza el modelado del negocio y de los requisitos, la especificación de las actividades y de los casos de uso asociados, así como de los objetos de información y de las clases que los implementan, se van recogiendo en un glosario, que permitirá mantener las correspondientes relaciones de trazabilidad entre los diferentes artefactos del modelado. El Proceso Unificado de desarrollo de software (RUP) definido por Rational para UML (Lenguaje de modelamiento unificado), incluye también el modelado del negocio como un paso más dentro de las iteraciones necesarias que conforman el modelo del proceso. Jacobson et al. Presentan algunos pasos que son similares a los nuestros, pero no se considera la descomposición jerárquica de los casos de uso de nivel superior, ni tampoco se proporciona una guía clara para detectar los casos de uso del sistema. Nuestro enfoque para el modelado del negocio constituye una guía completa y detallada, a diferencia de las indicaciones generales presentadas en el UP.

Otro de los factores de éxito para extraer las reglas de negocio de los casos de usos, es la integración, colaboración y optimización en la generación de los mismos, puesto que es poco probable que un analista tenga un amplio conocimiento y la experiencia para comprender todos los procesos de negocios de inicio a fin, especialmente si el sistema tiene integraciones con otros sistemas. Es importante recorrer todo el proceso a fin de cerrar las brechas que se puedan presentar. Las declaraciones en los casos de uso tienen que ser expresadas en el nivel correcto. Demasiado detalle, se tornara más difícil para el descubrimiento de las mismas. Por el contrario poco detalle dará inicio a malas interpretaciones cuando se esté definiendo. Existen otros principios de organización que pueden usarse para obtener de regla. Estos pueden ser usados a solas o en combinación, a merced del tamaño y la naturaleza del sistema en duda. Las consideraciones más relevantes son: Análisis Estáticos, Sesiones interactivas y programación automatizada (código embebido en programas).

28/70

Análisis estático: es el mejor acercamiento cuándo la documentación pertinente está disponible. Esto implica comprobación cuidadosa de documentos origen para las reglas potenciales. Sesiones interactivas: juntan análisis y especialistas del negocio para explorar áreas dónde el conocimiento del negocio no están fácilmente disponibles en una forma documentada. Descubrimiento automatizado: Puede ser usado en casos particulares para encontrar reglas a través de análisis de la codificación de sistemas legados, con tal que los datos originales puedan convertirse en hechos disponibles. La semántica de las declaraciones efectuadas en los casos de uso debe permitir que se puedan realizar de manera casi transparente las especificaciones para la regla de negocio, entre las cuales se pueden destacar. Programación declarativa: Permitir decir qué hacer y no cómo hacerlo. La ventaja de este aspecto radica en que las reglas hacen más fácil expresar las soluciones de problemas difíciles y por tanto poder verificar esas soluciones.

Separación de los datos y la lógica: Esto se refiere a que los datos están en los objetos de dominio del negocio y la lógica está en las reglas de negocio. Siendo así, la lógica de negocio puede ser mucho más fácil de entender, mantener y enfrentar posibles cambios en el futuro, pues toda la lógica está representada en las reglas.

Simplicidad. La metodología de las reglas de negocio es simple de entender, tanto para el personal del negocio como para el personal técnico. El concepto de una regla es muy intuitivo, incluso cuando se tiene varias clasificaciones de reglas.

El personal del negocio puede no estar interesado en modelos de datos, modelos de procesos, o modelos de objetos, pero están absolutamente interesados en las políticas y reglas del negocio, ya que son las que guían el negocio.

Pequeño número de conceptos necesarios, no técnicos. Los conceptos alrededor de un caso de uso, pueden incluir, formulas, decisiones, repeticiones y no conceptos técnicos como bucles, anidaciones.

Facilita el desarrollo de la aplicación. Básicamente el experto en reglas define las reglas y estas se ejecutan en aras de satisfacer las necesidades de la aplicación, sin necesidad de modificar el código fuente u otros aspectos técnicos de la aplicación.

29/70

Reutilización de reglas. Una vez declaradas las reglas, no solo pueden ser utilizadas por la aplicación, también pueden ser reutilizadas por ejemplo, por sistema gestores de base de datos u otros tipos de software. Para lograr esto se debe utilizar un sistema de administración de reglas de negocio o se puede diseñar un sistema propio, que agrupe las reglas de forma lógica y puedan ser reutilizadas y compartidas. Finalmente todas estas declaraciones deben permitir esquematizarlas en artefactos como: tablas de consulta, términos lógicos y símbolos.

Tabla de Consulta: puede usarse para expresar lógica del negocio en una forma que es más fácil de acostumbrar a las tablas de decisión. Las implicaciones de uno o más reglas negocio están codificadas en una tabla a fin de que una aplicación simplemente pueda leer el resultado pertinente, todavía aplicando las reglas, pero en una forma indirecta. Aunque las tablas pueden ser convenientes, su empleo excesivo puede hacer el sistema difícil para sostener. Para hacer las cosas más claras, tomaremos un ejemplo simple. Asuma que se ha definido un conjunto de acontecimientos del negocio, cuándo uno de estos acontecimientos ocurre, puede afectar un proceso del negocio, causando que pueda detenerse, cambiar de dirección, o cualquier cosa. Un camino para definir un acontecimiento que le impactará. Es ahora muy simple para una para aplicación enterarse de cual acontecimiento impacta. Ver Tabla 2.

Tabla 2: Semántica de eventos, procesos e impacto

Eso es muy conveniente para un programa de aplicación que necesita una decisión rápida, pero de la Tabla 2 fácilmente no podemos contestar tal pregunta. ¿Por qué no le impacta el acontecimiento 1 proceso A sino B de proceso?, es en este punto donde entra e juego la semántica con la cual se aplique la regla.

30/70

7.2.1 Términos lógicos Enfocados principalmente a las declaraciones y comparaciones clásicas o estándar a las cuales su resultado puede identificarse con operadores lógicos y el valor de una respuesta debe ser verdadero o falso (Si o No). Si se está familiarizado con escribir código de programa, éstos son los valores que son admitidos para las variables de tipo Boolean o algo por el estilo similar. Un gran subconjunto de las reglas de negocio se han trabajado en los modelos de las matemáticas y se basa en lógica estándar. Esto tiene una gran cantidad de características atractivas. Por ejemplo, un truco a menudo aprovechado es encontrarse con que algo es cierto mostrando que no es falso o viceversa. Los méritos filosóficos de la lógica difusa están sin verificar, tal como están para otras lógicas. Lo importante de la lógica es como ha sido utilizada cuando se aplica para algunos problemas del mundo real. Para las reglas de negocio, vamos a estar especialmente interesados en lo que se llama lógica deductiva, que se preocupa por establecer una conclusión de un dado conjunto de hechos de una manera que puede estar lógicamente correcto. Otra rama, lógica inductiva es importante en tales aplicaciones como la minería de datos. En cierto sentido, estas dos ramas corren en direcciones contrarias: La deducción aplica las reglas generales para los hechos particulares a alcanzar un resultado, mientras que la conscripción usa resultados y hechos particulares para inferir reglas. La modelación orientada en estos términos es un enfoque conceptual que permite modelar procesos negocios en términos de las tareas, actividades fundamentales de interés, donde todos los hechos pueden ser verbalizados en un lenguaje fácilmente comprensible por usuarios no técnicos de un negocio. Dicho enfoque es usado en la construcción de sistemas de reglas de negocio puesto que estas son construidas tomando como base un vocabulario que está formado por las palabras y frases establecidas por la comunidad de usuarios de un negocio particular. Este vocabulario, denominado modelo de negocios, se debe establecer en la etapa inicial del ciclo de vida de la concepción de los casos de uso. El comportamiento del negocio deberá ser de fácil acceso, modificación y administración por parte de los desarrolladores así como de los usuarios del negocio. En este contexto un modelo de negocios está conformado por los conceptos básicos y sus conexiones. Cada concepto tiene una definición clara y precisa desde la perspectiva del negocio y debe ser reflejada en el Glosario de Términos que es una colección de todos los términos y sus definiciones. Esta es la base de un principio importante del enfoque de reglas de negocio donde es esencial tener un vocabulario bien definido y consistente.

31/70

Cada término debe ser básico, atómico y conocible; es decir, no se debe derivar de otros términos, es indivisible y es un conocimiento que existe acerca del negocio. Cada conexión lógica entre conceptos tiene una forma estándar; estas conexiones son conocidas como hechos. Los hechos relacionan los términos, se expresan mediante oraciones, se basan en lenguaje común y extienden el vocabulario del negocio. Según Morgan, un hecho es “una interrelación entre términos identificables en el Modelo de Hechos y puede estar limitada por otros elementos descriptivos para especificar la aplicabilidad de la regla con precisión”.

7.2.2 Clasificación de regla de negocios según la semántica Según sus propiedades semánticas se definen tipos. Los tipos de regla son agrupados en tres categorías; Estructural, conductista y administrativa . Estas categorías representan diferentes puntos de vista en el negocio.

Estructural: Las reglas de negocio se preocupan por describir aspectos estáticos de un negocio.

Conductistas: definen lo las condiciones en la ejecución de tareas en el negocio.

Administrativa: definen el más alto nivel de restricciones en el negocio.

32/70

7.3 Base Teórica del Método Propuesto

7.3.1 Caso Base de Aplicación Caso de uso: Cuando un cliente de la empresa paga dentro de los 30 días y la cantidad solicitada no supera el stock, se factura con descuento y se envía la mercaderia solicitada. Sin embargo, si el pago se hiciera después de los 30 días se facturaría sin descuento, remitiendo la mercaderia13. Las mismas acciones se emprenden si se tratara de un cliente nuevo. Hacer lo mismo cualquiera sea el plazo de pago. Si no existe cantidad suficiente en stock y se trata de un cliente de la empresa que paga dentro de los 30 días, facturar con descuento, realizando la entrega de la cantidad en stock y dejar pendiente el resto del pedido. Si el cliente fuera nuevo, no practicar descuento alguno. En caso de que el pago no se efectuara dentro de los 30 días, cualquiera sea el cliente, se procedería de esta última manera. Si un cliente que compra por primera vez, solicita mayor cantidad de producto que la de stock, cualquiera sea el plazo de pago, no se le practicará descuento alguno, remitiéndose la cantidad en stock y dejando pendiente la diferencia.

7.3.2 ¿Como llenar una tabla de decisión? A partir del caso de uso se debe:

Identificar cuáles son las condiciones y cuáles las acciones.

Extraer un listado de las condiciones y de las acciones.

Completar la tabla en las matrices de condiciones y acciones

Identificadas las condiciones y las acciones se colocan en sus respectivas matrices y se construyen después las reglas.

13

Sistemas de Información II, María Josefina Castilla – Universidad de Murcia, España.

33/70

7.3.3 Construcción de la Tabla

Tabla 3: Construcción de tabla

1 2 3 4 5 6 7 8

Cliente de la empresa S S N N S N -- N

Plazo de pago ≤ 30 días S N N -- S S N --

Cantidad solicitada ≤ cantidad en stock S S S S N N N N

Facturar con descuento X -- -- -- X -- -- --

Facturar sin descuento -- X X X -- X X X

Enviar mercaderia solicitado X X X X -- -- -- --

Enviar cantidad en stock -- -- -- -- X X X X

Dejar pendiente cantidad solicitada en stock -- -- -- -- X X X X

7.3.4 Depuración de tabla de decisión

Compactar la tabla (conjunto representativo de reglas).

Encontrar errores en las reglas (ej. enunciado contradictorio). Este proceso puede aplicarse sin hacer referencia a los contenidos del enunciado. Se realiza a través de tres leyes y un criterio

1. Primera ley: Unificación de reglas por indiferencia, se analiza por pares de reglas

Tabla 4: Unificación de reglas por inferencia

34/70

2. Criterio: Reglas independientes y dependientes

Tabla 5: Reglas independientes y dependientes

Un par de reglas dependientes son redundantes cuando las reglas tienen las mismas entradas de acciones y contradictoria cuando tienen diferentes entradas de acciones.

3. Segunda ley y tercera ley: Eliminación de redundancias Si en un par de reglas dependientes y redundantes, una es pura y la otra es mixta, la pura está contenida en la mixta y debe ser eliminada.

Tabla 6: Tabla mixta redundante

5' 7'a 7'b N N N S S N N N N Eliminación de Redundancias: Si en un par de reglas dependientes y redundantes ambas son mixtas, existe al menos una regla pura común a ambas que puede eliminarse de una de ellas.

35/70

Tabla 7: Eliminación de redundancias

Nota: En este caso, todas las reglas son independientes

Tabla 8: Reglas independientes

36/70

7.3.5 Ordenamiento de tabla de decisión

Para hacer más rápida y fácil la búsqueda de una regla cualquiera, se ordenan las reglas según los valores de las entradas de condiciones.

En nuestro ejemplo, una vez lograda la depuración, reemplazamos las S=1, N=2, - =3.

Se ordena cada regla por el total de la suma de menor a menor.

Tabla 9: Ordenamiento de tabla de decisión

Ordenar de acuerdo a la cantidad entera en forma creciente:

Tabla 10: Tabla ordenada

37/70

Remplazar los números por las letras:

Tabla 11: Remplazo de números a letras

7.3.6 Entradas limitadas, ampliadas y mixtas

Limitadas: “S”, “N”, “-”, “X”.

Ampliadas: los enunciados de las condiciones y acciones se completan en las reglas en la parte respectiva.

Mixtas: se mezclan entradas limitadas y entradas ampliadas.

Tabla 12: Tabla ampliada o mixta

38/70

7.3.7 Transformación de Reglas

Programación directa: Cada regla equivale a una sentencia condicional. Es ineficiente, pero es suficiente para el desarrollo de nuestros trabajos prácticos.

Se puede pasar la tabla de decisión a diagrama de flujo o pseudocódigo.

Tabla 13: Transformación de reglas

39/70

Se dividen en dos tablas para el caso en que la condición C1 es S y es N. No se incluye C1. Se repite el proceso.

Tabla 14: Depuración de tablas

Tabla 15: Conversión en seudocodigo

40/70

Figura 4: Seudocodigo

41/70

7.4 Método Propuesto 1. Lectura y análisis detenidamente el caso de uso. 2. Las pre condiciones y post condiciones se descartan, por que no están intrínsecas dentro del curso normal del caso de uso. 3. Las Acciones del Actor se deben descartar, ya que no necesariamente son las reglas del negocio. 3.1. Las reglas de negocio normalmente son acción o decisiones del sistema, por tanto el método se enfoca en ellas. 4. Se debe identificar los verbos utilizados dentro del curso normal del caso de uso. 4.1. Los verbos son las actividades o acciones que se deben ejecutar de acuerdo a las condiciones que acompañan el enunciado 4.2. las actividades o acciones identificadas deben estar complementadas por una o varias condiciones. 4.2.2 Las condiciones son normalmente las restricciones del caso de uso, sin embargo dentro del curso normal se identifican condiciones principales. Las condiciones son inherentes a un evento y las acciones aplican sobre los eventos que afectan las acciones. 4.2.3 1....n Condición * 1...n acción = Regla de Negocio 5. Alimentar las matrices de la tabla de decisión 5.1. Ingresar las condiciones dentro de la tabla de decisión. 5.2. Ingresar las acciones dentro de la tabla de decisión. 6. Aplicar teorema matemático

6.1 se calcula la cantidad de reglas de negocio de acuerdo al teorema de x = 2∧n donde 'n' es el numero de condiciones, '2' es una constante y 'x' es la cantidad de reglas de negocio 7. Evaluar el criterio de maduración del caso de uso, propuesto por el área. 7.1 tomar la decisión de continuar o segregar el caso de uso, de segregarse se debe iniciar nuevamente la aplicación del método para los casos de uso resultantes 8.Refinar las reglas de negocio

42/70

8.1 seleccionar la una a una cada regla 8.1.2 Alimentar la regla con 'S', 'N' o '-' por cada una de las condiciones para lograr encontrar las acciones definidas en el caso de uso 8.1.2.3 Marcar con 'X' las acciones a realizar cuando la combinación de Condiciones 'S' apliquen o arrojen como resultado esta acción o actividad. 9. Depuración de las tablas de decisión 9.1 identificar las equivalencias 9.2 Especificar las tablas 9.3 Validar integridad 9.4 Encontrar errores 9.5 aplicar leyes de las tablas de decisión 10. Expresión de la Regla de Negocio 10.1 convertir en seudo código 10.2 candidatizar semánticamente la regla

43/70

7.5 Aplicación de método (Caso de estudio)

7.5.1 Caso de uso

Caso de uso:

CUAGE006

Prioridad: Alta Fecha de solicitud:

XXXX-XX-XX

Nombre del caso de uso: Asignar cita.

Descripción: Asignación de citas a afiliados.

Solicitado por: Gerente de Prestación de Servicios.

Actor: Auxiliar administrativo.

Códigos de los documentos:

FG-07/01, PT-07/01, POE-07/01/09, POE-07/01/17.

Módulos que intervienen: Agenda de servicios.

Precondiciones: Programa médico, equipo de salud/profesional de la salud, calendario de los profesionales de la salud.

Poscondiciones: Cita asignada.

Parámetros: Afiliado, especialidad, equipo de salud/ profesional de la salud, cita disponible.

Curso normal

Acciones del actor Respuestas del sistema

Caso de uso CUGEN001_Iniciar sesión.

Ingresa el Centro de atención. Verificar que el Centro de atención existe.

Verificar que el actor tenga privilegios para Asignar cita.

Ingresa el afiliado. Verificar que afiliado existe.

Caso de uso CUGEN002_ Validar derecho de prestación de servicios.

Ingresar Si/No presenta el comprobante de nomina cuando esta suspendido.

Validar que comprobante de nomina existe.

Validar que decisión de prestación de servicios es igual a No POS.

Fin.

Buscar y mostrar los siguientes datos del afiliado: Nombres Apellidos Dirección Teléfono Dirección (actualizada)

44/70

Teléfono (actualizado) Ciudad Sexo Edad Asociado (Si/No) Tipo de contrato (si es independiente, dependiente o pensionado) Tipo de afiliado Fecha de afiliación Estado Rango Semanas de cotización Plan adicional Médico asignado I.P.S. Médico Familiar (en el campo profesional de la salud) Empresa (para la cual trabaja el afiliado) Empresa Convenio (S/N) Empresa a fidelizar (S/N) Estado de cartera de la empresa Convenio de pago Multiafiliado Si el afiliado se encuentra en estado diferente a ACTIVO, no pertenece al centro de atención, es MULTIAFILIADO, y/o el estado de cartera de la empresa es diferente a ACTIVO, el sistema debe alertar al afiliado sobre esta información.

Verificar que el afiliado no tiene citas en estado incumplida.

Ingresa tipo de cita. Verificar que el tipo de cita es Programada, No programada.

Ingresa el programa médico. Verificar que el programa médico este asignado al centro de atención.

Verificar que el programa médico sea diferente de Consulta especializada.

Verificar que el programa médico sea diferente de Consulta de P y P.

Verificar que el programa médico sea Pediatría

Validar que la edad sea menor a 14 años

Verificar que la cita es odontológica.

45/70

Verificar que el afiliado no tenga tratamientos odontológicos pendientes por terminar, entonces tiene el tratamiento terminado y a la fecha ha pasado más de 6 meses de su última cita odontológica, por lo tanto tiene el tiempo en su asignación.

Validar si la cita asignada al afiliado es la primera cita en el año y mostrar esta información en las observaciones NOTA: la validación debe hacerse al asignar citas para todos los programas médicos excepto: Consulta médica externa médica, odontológica, paramédica y de medicina alternativa aceptada.

Ingresa el procedimiento. Verificar que el procedimiento corresponda al programa médico seleccionado.

Ingresa profesional de la salud. Mostrar por defecto el nombre del médico asignado al afiliado.

Verificar que el procedimiento corresponda al servicio de presupuesto Consulta Médica General.

Ingresa tipo de cita Verificar que tipo de cita es programada

Verificar que el afiliado tiene inscripciones vigentes en al menos uno de los subgrupos de REB.

Verificar que el afiliado tiene médico asignado.

Si el afiliado tiene médico asignado y una de las inscripciones que tiene vigentes es al subgrupo de REB “Embarazo de alto riesgo”, verificar que su médico asignado atiende afiliados inscritos en el subgrupo de REB “Embarazo de alto riesgo”. Mostrar por defecto el médico asignado del afiliado.

Si el afiliado tiene médico asignado y las inscripciones que tiene vigentes ninguna es al subgrupo de REB “Embarazo de alto riesgo”, verificar que su médico asignado atiende afiliados inscritos en los subgrupos de REB. Mostrar por defecto el médico asignado del afiliado.

Si el afiliado no tiene médico asignado, verificar que profesional de la salud es un médico que atiende afiliados con REB.

46/70

Verificar que el profesional tenga un contrato de tipo interno, que esté vigente y se encuentre en estado activo.

Verificar que el procedimiento ingresado esté vinculado al portafolio de servicios del contrato.

Verificar que el procedimiento se encuentre activo en el portafolio de servicios del prestador.

Ingresa fecha y horario de la cita. Verificar que la fecha y hora de la cita es mayor o igual a la fecha y hora actual.

Ingresa fecha y horario de la cita. Verificar que la fecha y hora de la cita es mayor o igual a la fecha y hora actual.

Verificar que el profesional de la salud se encuentre disponible para la fecha y hora ingresada.

Verificar que el afiliado no tenga citas en estado Asignada, Cumplida o Atendida en los últimos ocho (8) días.

Verificar que el afiliado no tiene una cita en estado Asignado o Cumplida en el horario ingresado.

Validar que el afiliado NO tiene Historia Clínica en ninguna UBA o Punto de Atención administrado por Coomeva EPS.

Identificar consulta como Primera Vez

Ingresa consultorio. Verificar que el consultorio se encuentra en estado Activo.

Verificar que consultorio se encuentra disponible.

Ingresa observaciones.

Ingresa recordatorio de cita. Verificar que recordatorio de cita es SI o No.

Verificar que recordatorio de cita es No.

Validar que el afiliado tenga glosas sin solucionar o documentos pendientes de afiliación sin recibir

Validar que la cita es no programada y del programa médico Consulta Médica General o Consulta Odontológica.

Marcar la cita como asignada a afiliados con inconvenientes de glosas o documentos pendientes.

Cambiar el estado de la cita a ASIGNADA.

Mostrar el valor de la cita (cuota moderadora) que debe pagar el afiliado según el rango.

Validar que la cita asignada se encuentre en la misma fecha y hora de la cita cancelada.

47/70

Excepción 1 3. El Centro de atención no existe.


Mostrar el mensaje: “El centro de atención no existe”.

Volver al paso 2.

Excepción 2 4. El actor no tiene privilegios para Asignar cita.


Mostrar el mensaje: “No tiene acceso a esta opción”.

Volver al paso 1.

Excepción 3 6. El afiliado no existe.


Mostrar el mensaje: “El afiliado no existe”.

Volver al paso 5.

Excepción 4 9. El comprobante de nomina no existe.


Mostrar el mensaje: “Debe seleccionar Si / No presenta comprobante de nomina”.

Volver al paso 8.

Excepción 5 10. Decisión de prestación de servicios no es igual a No POS.


Ir al paso 8.

48/70

Excepción 6 13. El afiliado tiene citas en estado incumplida.


Buscar la validez de multas del centro de atención.

Buscar las citas incumplidas de los últimos meses según lo indique el parámetro anterior. Contarlas y totalizar sus multas sin pagar .

Mostrar el mensaje: “El afiliado tiene <cantidad de multas sin pagar> citas incumplidas en los últimos <validez de las multas> meses.”

Si el total de las multas sin pagar es mayor que cero, mostrar el mensaje: “Con multas generadas por un valor de $<total de multas sin pagar>”.

Continuar con el paso 12.

Excepción 7 15. El tipo de cita es diferente de Programada y No programa.


Mostrar mensaje: “El tipo de cita debe ser Programada o No programada”.

Volver al paso 12.

Excepción 8 17. El programa médico no se encuentra asignado al centro de atención.


Mostrar mensaje: “El programa médico no existe en el Centro de atención”.

Volver al paso 16.

Excepción 9 18. El programa médico es Consulta especializada.


Ir al caso de uso CUAGE016_Asignar cita para consulta con especialista.

Excepción 10 19. El programa médico corresponde Consulta de P y P.


Ir al caso de uso CUAGE020_Asignar cita para consulta de PyP.

49/70

Excepción 11

20. La cita no es Pediatría.



Excepción 12

21. La edad es mayor a 12 años


Mostrar mensaje “La edad del usuario no aplica para cita con pediatra”. Volver al paso 16.

Excepción 13 22. La cita no es odontológica.



Excepción 14 23. El afiliado tiene tratamientos odontológicos pendientes por terminar.


Mostrar el mensaje: “El afiliado tiene (cantidad) tratamientos odontológicos pendientes por terminar”.


Excepción No.

23. El afiliado tiene su tratamiento odontológico cerrado y tiene menos de 6 meses para completar nuevamente sus citas.


Mostrar el mensaje: “El afiliado tiene su tratamiento odontológico cerrado y tiene menos de 6 meses para completar nuevamente sus citas”.


Excepción 15 24. La cita a asignar al afiliado no es la primera cita en el año.



Excepción 16 26. El procedimiento no corresponde al programa médico ingresado.


Mostrar mensaje: “El procedimiento no corresponde al programa medico ingresado”.

Volver al paso 25.

50/70

Excepción 17 28. El procedimiento no corresponde al servicio de presupuesto consulta médica general.


Ir al paso 32.

Excepción 18 30. El tipo de cita es no programada.


Ir al paso 32.

Excepción 19 31. El afiliado no tiene inscripciones vigentes en ninguno de los subgrupos de REB.


Mostrar solo los médicos que no tienen ningún subgrupo de REB asignado.


Excepción 20 32. El afiliado no tiene médico asignado.


Mostrar mensaje: “El afiliado tiene inscripciones vigentes en al menos uno de los subgrupos de REB, por lo tanto debe tener un médico asignado”.


Excepción 21 32. El médico asignado del afiliado no atiende afiliados inscritos en el subgrupo de REB “Embarazo de alto riesgo”.


Mostrar mensaje: “El médico asignado de este afiliado se debe cambiar por un médico que atiende afiliados con REB en Embarazo de alto riesgo”.

Volver al paso 30.

Excepción 22 32. El médico asignado del afiliado no atiende afiliados inscritos en los subgrupos de REB.


Mostrar mensaje: “El médico asignado de este afiliado se debe cambiar por un médico que atiende afiliados con REB”.

Volver al paso 28.

Excepción 23 35. El profesional de la salud no es un médico que atiende afiliados con REB.

51/70


Mostrar mensaje: “El profesional de la salud debe ser un médico que atiende afiliados con REB”.

Volver al paso 30.

Excepción 24 36. El profesional de la salud no tiene contrato de tipo interno, que se encuentre vigente y en estado activo con el Centro de atención.


Mostrar mensaje: “El profesional de la salud debe tener un contrato de tipo interno, vigente y en estado activo con el Centro de atención”.

Volver al paso 30.

Excepción 25 37. El procedimiento no se encuentra vinculado al portafolio de servicios correspondiente al contrato del profesional de la salud ingresado.


Mostrar mensaje: “El profesional de la salud no tiene el procedimiento contratado”.

Volver al paso 30.

Excepción 26 37. El procedimiento no se encuentra en estado Activo.


Mostrar mensaje: “El procedimiento debe estar Activo”.

Volver al paso 30.

Excepción 27 40. La fecha y hora de la cita es menor a la fecha y hora actual.


Mostrar mensaje: “La fecha y hora de la cita debe ser mayor o igual a la fecha y hora actual”.

Volver al paso 39.

Excepción 28 41. El profesional de la salud no se encuentra disponible para la fecha y hora ingresada.


Mostrar el mensaje: “El profesional de la salud no se encuentra disponible para la fecha y hora ingresada”.

Volver al paso 39.

Excepción 29 42. El afiliado tiene citas en estado Asignada, Cumplida y/o Atendida en los últimos ocho (8) días.

52/70


Mostrar el mensaje: “El afiliado tiene citas en estado –Asignada, Cumplida y/o Atendida en los últimos ocho (8) días”.

Volver al paso 39.

Excepción 30 43. El afiliado tiene una cita en estado Asignado o Cumplida en el horario ingresado.


Mostrar el mensaje: “Existe una cita en estado Asignada o Cumplida del afiliado en la fecha y hora ingresada”.

Volver al paso 39.

Excepción 31 44. El afiliado SI tiene citas atendidas



Excepción 32 47. Consultorio no se encuentra en estado Activo.


Mostrar mensaje: “El consultorio debe estar Activo”.

Volver al paso 46.

Excepción 33 48. Consultorio no se encuentra disponible.


Mostrar mensaje: “El consultorio debe encontrarse disponible”.

Volver al paso 46.

Excepción 34 51. Recordatorio de cita es diferente de Si/No.


Mostrar mensaje: “Recordatorio de cita debe ser Si o No”.

Volver al paso 48.

53/70

Excepción 35 50. Recordatorio de cita es Si.


Mostrar la siguiente información sobre la cita: Nombre completo del afiliado Fecha de la cita (dd/mm/aaa) Hora de la cita (am/pm) Profesional de la salud Consultorio Este recordatorio se puede imprimir.


Excepción 36 53. El afiliado NO TIENE glosas sin solucionar NI documentos pendientes de afiliación sin recibir.



Excepción 37 54. La cita es programada o el programa médico no es Consulta Médica General o Consulta Odontológica.


Mostrar el mensaje: “El afiliado tiene inconvenientes de Glosas o Documentos Pendientes de afiliación, circunstancia bajo la que sólo se puede prestar el servicio de urgencias”.

Fin.

Excepción 38 56. La cita asignada se relaciona con la misma fecha y hora de la cita cancelada.


Cambiar estado de la cita a “Reasignada”.

Fin.

54/70

Inclusiones

CUGEN001_Iniciar sesión CUGEN002_Validar derechos de prestación de servicios CUAGE016_ Asignar cita para consulta con especialista CUAGE020_Asignar cita para consulta de PyP CUAFI004_Asignar médico familiar

Observaciones

El sistema debe traer por defecto “SI” si la cita del afiliado es de primera vez, en caso contrario, debe traer por defecto “NO” si la cita del afiliado no es de primera vez por programa médico. El afiliado no puede tener más de una cita asignada en la misma fecha/hora independiente del programa médico. En el momento de asignar la cita, el sistema busca y muestra la cuota moderadora que corresponde según rango del afiliado, de aquí surge una conexión con el módulo de FACTURACIÓN donde se recauda el pago de la cuota moderadora. Se requiere ordenar los profesionales de la salud por orden alfabético o por disponibilidad. En el caso en que el usuario solicite una cita medica, las agendas marcadas como PyP (Si) no deben presentarse al perfil Auxiliar Call center.

7.5.2 Listado de Condiciones y Acciones Condiciones:

Tabla 16: Tabla de condiciones

CONDICIONES

Afiliado Activo

Afiliado Multiafiliado

Citas Incumplidas

Cita Programada

Cita Odontológica

Programa Médico PyP

Programa Médico Especialista

Programa Médico Pediatría

Afiliado < 14 años

Tratamiento OD sin terminar

Ultima cita OD > 6 meses

Afiliado inscrito a REB

Prestador Activo

Prestador libre

Afiliado tiene historia

Afiliado tiene Glosas

55/70

Acciones:

Tabla 17: Tabla de acciones

ACCIONES

Calcular cita Incumplidas

Facturar citas incumplidas

Terminar tratamientos

No asignar Cita Odontológica

Cambiar medico

Asignar Medico

Asignar Cita Pediatría

Asignar Cita PYP

Negar Cita

Prestar solo Urgencias

Calculara Valor cuota Moderadora

56/70

7.5.2.1 Tabla Resultante

Tabla Inicial: de acuerdo con las condiciones y acciones listadas Numero reglas 2º13=8192

Tabla 18: Tabla resultante

CONDICIONES C2 C3 C4 C5 C6 C7 C8 C9 C10

…….

Afiliado Activo S S S S S S S S S

Cartera Activa S N N N N N S S S

Afiliado < 14 años S S N N N N N N N

Tratamientos OD Terminados S S S N N N N N N

Citas incumplidas S S S S N N N N N

Ultima cita > 6 meses S S S S S N N N N

Afiliado tiene medico asignado S S S S S S N N N

Afiliado Multiactivo S S S S S S S N N

Cita Programada S S S S S S S S N

Programa Medico Especialista S S S S S S S S S

Afiliado Glosas S S S S S S S S S

Médico Activo S S S S S S S S S

Cita Odontologica S S S S S S S S S

ACCIONES

Emitir Mensajes-Terminar X X X X X

Prestar solo X X X X X

57/70

Urgencias

Asignar Especialista

Calcular Cuota Moderadora

Cambiar Medico

Facturar Multas X X

Asignar Cita OP X X

Asignar Cita Pediatria

Asignar Cita Odontologica X X - - - - -

Calcular Multas X X X X

Negar Citas X X X X X X

58/70

7.5.3 Maduración de Tablas Se selecciona la afinidad de condiciones para generar nuevos casos de uso que harán parte de las precondiciones del caso de uso. Nota: las reglas no necesariamente deben de llenarse en este punto. Primera Iteración: Se eliminan condiciones que deben pertenecer a otro caso uso. Numero reglas 2º9=512

Tabla 19: Tabla resultante 1ra iteración

CONDICIONES C2 C3 C4 C5 C6 C7 C8 C9 C10

…….

Afiliado Activo S S S S S S S S S

Cartera Activa S N N N N N S S S

Afiliado < 14 años S S N N N N N N N

Tratamientos OD Terminados S S S N N N N N N

Citas incumplidas S S S S N N N N N


Afiliado tiene medico asignado S S S S S S N N N

Afiliado Multiactivo S S S S S S S N N

Cita Programada S S S S S S S S N

Programa Medico Especialista S S S S S S S S S

Afiliado Glosas S S S S S S S S S

Médico Activo S S S S S S S S S

59/70

Cita Odontologica S S S S S S S S S

ACCIONES

Emitir Mensajes-Terminar X X X X X

Prestar solo Urgencias X X X X X

Asignar Especialista


Cambiar Medico

Facturar Multas X X

Asignar Cita X X

Asignar Cita Pediatria

Asignar Cita Odontologica X X - - - - -



60/70

Segunda Iteración: Se extrae las condiciones constantes para todas las reglas y/o son precondiciones

Tabla 20: Tabla resultante 2da iteración

CONDICIONES 1 2 3 4 5 62 7 8 9

Afiliado < 14 años - - - - - - - - -

Tratamientos OD Terminados S N S N N N N N N

Citas incumplidas S S N S N N N N N


Cita Programada S S S S S S S S S

Afiliado Glosas S S S S S S S S N

ACCIONES

Prestar solo Urgencias X X X X X


Facturar Multas X X

Asignar Cita Odontologica - X - - - - -



Tercera Iteración: Se aplican las leyes de redundancias para la tabla de decisión.

Tabla 21: Tabla resultante 3ra iteración

CONDICIONES 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Tratamientos OD Terminados S N S S S S S S N N N N N N S N

Citas incumplidas S S N S S N N N S N S S N N S N

Ultima cita > 6 meses S S S N S N N S S N N N S S N N

Afiliado Glosas S S S S N S N N N S N S S N N N

ACCIONES

Prestar solo Urgencias X X X X X X X X X

Calcular Cuota Moderadora X X

Calcular Multas X X X X X X X

Facturar Multas X X X X X X X X

Asignar Cita X X X X

Negar Citas X X X X X X X X X X

61/70

Tabla 22: Tabla resultante refinada

CONDICIONES 1 3 7 5 8 9 11 12 13 15

Tratamientos OD Terminados -- -- -- S S N N N N S

Citas incumplidas S N N S N S S S N S

Ultima cita > 6 meses -- -- -- S S S N N S N

Afiliado Glosas S S N N N N N S S N

ACCIONES Prestar solo Urgencias X X

X X


X X Calcular Multas X

X

X

X

X

Facturar Multas X

X

X X X

X

Asignar Cita

X X

X

X

Negar Citas X X X

X

62/70

7.5.4 Expresión de las Reglas de Negocio Se realiza la expresión de las reglas de negocio en lenguaje natural o seudo codigo, se toma cada una de las condiciones con los valores permitidos y se definen las acciones a ejecutar sin importar el orden de hallazgo. Para el caso practico se realizo un hallazgo de ocho reglas de negocio.

Si afiliado tiene Glosas se debe: Negar Cita y Prestar servicio de Urgencias

Si afiliado no tiene Glosas, tiene citas incumplidas y ha terminado los tratamientos se debe:

Calcular Multas y Facturar Multas y

Calcular Cuota Moderadora y Asignar Citas

Si afiliado no tiene Glosas , ni Citas incumplidas pero última cita es mayor a seis meses y ha terminado los tratamientos Odontológicos se debe:

Calcular la Cuota Moderadora y Asignar Citas

Si afiliado no ha terminado los tratamientos odontológicos y no tiene glosas, pero tiene citas incumplidas y su última cita fue hace más de seis meses se debe:

Calcular Multas y Facturar Multas

Si Afiliado tiene citas incumplidas pero no tiene glosas ni los tratamientos odontológicos y su última cita fue menos de 6 meses se debe:

Calcular Multas y Facturar Multas y Asignar Citas

63/70

Si Afiliado tiene citas incumplidas y glosas, pero termino los tratamientos odontológicos y su última cita fue menos de 6 meses se debe:

Prestar servicio de Urgencias y

Calcular Multas y Facturar Multas

Si Afiliado tiene glosas y su última cita fue menos de 6 meses, pero no ha terminado los tratamientos odontológicos y además no tiene citas incumplidas se debe:

Prestar servicio de Urgencias

Si Afiliado tiene no glosas y su última cita fue hace menos de 6 meses, pero terminó los tratamientos odontológicos y además tiene citas incumplidas se debe:

Calcular Multas y

Facturar Multas y

Asignar Citas

64/70

8 RECOMENDACIONES

8.1 Analistas de Software

Normalmente los caso de uso no se encuentre bien escrito, esto corresponde al nivel de depuración realizada en el proceso de elicitación de requerimientos; entonces se puede encontrar que los casos de uso no cuentas con la jerarquía o el nivel optimo; normalmente esto no es fácil de lograr, pues los casos de uso casi siempre buscan esquematizar el diagrama del proceso. Esta es la mejor oportunidad para lograr un buen hallazgo de reglas de negocio por medio de este método.

Contrastar el caso de uso vs el escenario de negocio (este es condicionado por el requerimiento).

El criterio de maduración de las reglas de negocio normalmente hace parte de las habilidades cognitivas del analista de negocio.

Las precondiciones eventualmente son casos de uso que tienen embebidas sus propias reglas de casos de uso.

Las condiciones se deben agruparse de acuerdo a su afinidad y este grupo a su vez candidato a convertirse en un caso de uso nuevo.

Aun que se madure las tablas de decisión siempre se debe tener en cuenta el nicho del negocio.

Cuando una condición es igual es todas las reglas, esta se debe colocar como una precondición para el caso de uso.

La importante consecuencia práctica de esto es que sea cual sea su comportamiento, es posible e incluso aconsejable, utilizar al principio con más frecuencia las reglas Textuales y luego, con la práctica y la consolidación de los Modelos de los Procesos, ir migrando paulatinamente hacia la inclusión de más reglas Mecánicas que sustituyan a las Textuales, asegurando así una transición suave de uno a otro escenario.

Previamente tener los casos de uso definidos, evitar la práctica de realizar los casos de uso e iniciar inmediatamente con el procesos de extracción de las Reglas de Negocio.

65/70

8.2 Jefes de Desarrollo de Software

Para identificar una condición esta debe ser un hecho o circunstancia que se presenta dentro curso proceso.

De acuerdo al teorema matemático para encontrar el máximo de reglas de negocio en un caso de uso, el equipo de analistas debe definir los criterios de maduración que deben aplicar para un caso de uso, de acuerdo a la cantidad de reglas de negocio que el teorema nos de. El dilema esta en identificar la maduración de acuerdo a la cantidad de reglas, la recomendaciones es que sean máximo 10.

El criterio del nivel de maduración debe ser una regla de negocio empresarial que es transitiva al proceso de desarrollo de software de la empresa.

Los casos de uso se recomienda manejarlos como escenarios para realizar

66/70

9 CONCLUSIONES

Nos brinda una herramienta para determinar el grado de maduración del caso de uso.

Los casos de uso debe ser derivados de acuerdo a la afinidad de las condiciones

Los casos de uso ya son un estándar y es un modelo conceptual probado que sirve de base para la extracción de las reglas de negocio.

La extracción de la reglas en las nuevas necesidades de las empresas, es por ahora un naciente proceso de la ingeniería, ha de estudiarse más a fondo la necesidades generar métodos y metodologías para obtener estas reglas en sistemas legados en el código duro de los sistemas de información que al día de hoy sigue siendo una caja negra para una gran mayoría de las empresas.

La evolución de los métodos de extraer debe permitir obtener de manera mucho más ágil y clara estas condiciones de la empresas de las diversas fuentes donde se hayan escritos así como dejar en listo la generación d las mismas (reglas) en los lenguajes que evolucionan con el mismo buscando optimizar los costos y tiempos que se debe invertir actualmente para estos procesos.

En el mercado y la literatura se habla de cómo plasmar y escribir reglas de negocio, mas la forma de cómo abstraerlas desde los casos de uso falta mayor difusión y aplicación.

Este trabajo presenta una propuesta de cómo obtener reglas de negocio a partir de los casos de usos aplicando las tablas de decisión, buscando de esta manera aprovechar los modelos matemáticos y estándares de Lenguaje de Modelado (UML) como base para el enfoque operativa empresarial.

Existen varias propuestas en las cuales se identifican posibles formas de substraer reglas de negocios es decir, de buscar la mayor parte de los cambios del entorno empresarial, del funcionamiento de una empresa que por esencia son variables, las que tienen fundamentos validos desde varios aspectos, pero en este caso se busca proveer un método basado en los modelos matemáticos que permita ser consistente y confiable para las frecuentes modificaciones, para adaptarse a las necesidades siempre cambiantes, creadas por el entorno.

67/70

La propuesta incluye igualmente delineamientos para describir y escribir los casos de usos, ya sea en forma de escenarios, o desde los mismos diagramas del UML, que faciliten posteriormente escribir las reglas de negocios en los motores de reglas de negocios ò dejar en pseudocódigos para plasmarlos en los lenguajes creados para este fin, además de la definición de pasos que servirán para traducir en las tablas de decisión y su iteración hasta llegar a un nivel más atomizados y esencial que contiene le centro de cada caso de uso y/o su derivación en otros hasta conformar un modelo de reglas.

Finalmente se plantean las recomendaciones que surgen como respuesta a la aplicación de este método en casos reales de la empresa, de bajar de la parte académica o teórica a escenarios del entorno en los cuales se mueven la empresa en el ámbito regional y nacional; estas recomendaciones pueden variar de acuerdo a la madurez de la generación de los casos de uso, de la aplicación de la método y de quienes están al frente de estos nuevos retos.

Las organizaciones solo necesitan sistemas que produzcan resultados tangibles en la vida real y sobre todo se requiere aprovechar inteligentemente los recursos disponibles de toda índole si quieren sobrevivir en un entorno de intensa competencia, es asi como la diferentes innovaciones y generación de herramientas en diferentes etapas se van entrelazándose para ser parte de una solución más tangible, como el caso de este modelo.

68/70

10 TRABAJOS FUTUROS

En mención a la generación de artefactos en el ámbito de ingeniería de software desde varios periodos en la historia, estos se convierten en la base para la expresión ò creación de nuevos artefactos que den respuestas a las necesidades del momento, actualmente en las organizaciones los términos de reglas de negocio, servicios, modelo de procesos de negocio, etc. Todos buscan dar respuestas a los requerimientos de versatilidad, flexibilidad de las organizaciones, a permitir en este la carrera contra el tiempo y estar en el punto más competitivo; se contempla la realización de una herramienta que automatice este método, de cara a la ola de reutilización de tecnologías de reglas de negocio del mercado mundial y a la adopción a la región.

69/70

11 BIBLIOGRAFIA

ubr.universia.net/pdfs-web/ubr_23009108.pdf

De los Procesos del Negocio a los Casos de Uso Grupo de Investigación de Ingeniería del Software2 Departamento de Informática y Sistemas Facultad de Informática. Universidad de Murcia C.P. 30.071 Campus de Espinardo, Murcia, España

70/70

12 GLOSARIO

SBVR: Semantics of Business Vocabulary & Business Rules BPM: Business Process Management (Gestión de procesos de negocio) BPMR: MOTORES DE REGLAS DE NEGOCIO. UML: Lenguaje Unificado de Modelado AI: Artificial intelligence. SOA: Arquitectura Orientada a Servicios. BRE: Bussines Rules Engine . System to manage and execute business rules. BRMS: Sistema de Gestión de Reglas de Negocio

mÉtodo para la extracciÓn de reglas de negocio...

Documents