> 10 <

SISTEMA MULTIAGENTE BASADO EN WEB SERVICES APLICADO A LA ETAPA DE LEVANTAMIENTO DE INFORMACION DEL PROCESO DE EVALUACION DE CREDITO REALIZADO EN EL BANCO DE CREDITO DEL PERU
Pedro Hebert Raico Purizaca, Carlos Miguel Del Castillo Sebastiani

Resumen- Esta investigacin busc mejorar la etapa de

levantamiento de informacin involucrada en el proceso de evaluacin de crdito, por lo cual se plante que el uso de un sistema multiagente basado en web services permitira mejorar ampliamente la etapa antes mencionada, mediante la eliminacin del desfase de tiempo en que Infocorp proporciona informacin, el incremento del porcentaje de crditos otorgados correctamente, la reduccin del tiempo invertido en la etapa de levantamiento de informacin, el incremento del nmero de entidades de las cuales el banco obtenga informacin, incremento del porcentaje de informacin actualizada e incremento del nivel de satisfaccin del cliente. Por ello la investigacin se dividi en tres etapas: el diagnstico inicial, el desarrollo del sistema multiagente basado en web services utilizando la metodologa MAS-CommonKADS y la etapa de contrastacin. Como resultados de esta investigacin se present que la etapa de levantamiento de informacin, se encuentra afectada por la falta de informacin actualizada, la cual es entregada por Infocorp con dos meses de retraso, por lo cual el proceso de evaluacin de crdito demora veinte das, de los cuales doce das son utilizados para la etapa de levantamiento de informacin. Adicionalmente la falta de informacin actualizada ha ocasionado que durante los aos 2005, 2006, 2007 y 2008, el 10%, 15%, 15% y 20% respectivamente de los crditos hayan sido otorgados incorrectamente. Finalmente en base a las teoras planteadas en la discusin de esta investigacin se concluy que el sistema multiagente basado en web services permite: proporcionar en todo momento informacin actualizada, eliminando el hecho de obtener informacin con un desfase de tiempo equivalente a dos meses de retraso; reducir el riesgo de otorgar crditos inadecuadamente, incrementando de esta forma el porcentaje de crditos otorgados correctamente; reducir a un da el tiempo invertido en la etapa de levantamiento de informacin, logrando que el cliente se encuentre satisfecho con el tiempo que al Banco de Crdito del Per le toma otorgar un crdito; incrementar el nmero de entidades de las cuales el Banco de Crdito del Per obtiene informacin y que el evaluador de crdito acceda a un porcentaje de informacin actualizada equivalente al 100%, en base a lo anterior se concluy que el sistema multiagente basado en web services, logra mejorar ampliamente la etapa de levantamiento de informacin.

Palabras Clave- Agentes reactivos, etapa de levantamiento de informacin, infocorp, proceso de evaluacin de crdito, sistema multiagente, solicitud de crdito, web services, XML I. INTRODUCCION El otorgamiento de crdito, actualmente forma parte de las operaciones financieras realizadas por las entidades bancarias, una de ellas, el Banco de Crdito del Per. Para realizar esta actividad, esta entidad establece un conjunto de etapas para la

evaluacin de crditos entre las cuales se sita la etapa de levantamiento de informacin de los solicitantes de crdito, de las diversas entidades privadas y/o pblicas. Durante esta etapa se utiliza como herramienta el sistema de consultas de Infocorp para obtener informacin financiera del solicitante como deudas con entidades comerciales y/o bancarias, montos de prstamos realizados, montos de compras al crdito y/o contado, etc., informacin obtenida a partir de entidades cuyo nmero se encuentra determinado y limitado por Infocorp. Este sistema proporciona informacin financiera actualizada los meses de diciembre, marzo, junio y septiembre, meses en los cuales el proceso de evaluacin de crdito demora catorce das, de los cuales seis son utilizados para la etapa de levantamiento de informacin del solicitante. El problema surge los meses de enero, febrero, abril, mayo, julio, agosto, octubre y noviembre, meses en los cuales el porcentaje de informacin actualizada mostrada por el sistema de consultas de Infocorp equivale al 0%, esto porque la informacin es entregada por Infocorp con dos meses de retraso, por lo cual el proceso de evaluacin de crdito demora veinte das, de los cuales doce das son utilizados para la etapa de levantamiento de informacin del solicitante. Durante estos meses, el evaluador de crdito debe corroborar la informacin obtenida del sistema de consultas de Infocorp con el fin de constatar si dicha informacin del solicitante se mantiene vigente o ha cambiado, adicionalmente busca informacin financiera actualizada del solicitante y que el sistema de consultas de Infocorp no le proporciona durante esos meses, para lo cual trata de comunicarse fsica, telefnicamente o va correo con otras entidades privadas y/o pblicas. Este intento de bsqueda no siempre es satisfactorio por la disponibilidad de tiempo de las entidades consultadas y/o por las reglas de privacidad vigentes respecto a la informacin de sus clientes. Lo mencionado anteriormente ha ocasionado dos problemas adicionales, el primero que aumenta el riesgo al otorgarse un crdito, habindose registrado durante el ao 2005, 2006, 2007 y 2008 que el 10%, 15%, 15% y 20% respectivamente de los crditos han sido otorgados incorrectamente a personas que no cumplan con los requerimientos planteados por el Banco de Crdito del Per. El segundo problema ocasionado est referido a que aumenta el riesgo de negar el crdito a un cliente que si cumple con los requerimientos planteados por el Banco de Crdito del Per. Esto surge porque los meses en que Infocorp no proporciona informacin actualizada, al evaluador de crdito le resulta difcil tener conocimiento de las deudas terminadas de pagar (prstamos, compras al crdito, cuotas de pago atrasadas, etc.) durante estos meses en otras entidades privadas y/o pblicas.

> 10 < Finalmente, a partir de una encuesta aplicada, se encontr que clientes que alguna vez solicitaron crdito en uno de los meses en que Infocorp no proporciona informacin actualizada, se encuentran muy insatisfechos respecto al tiempo que le tom al Banco de Crdito del Per otorgarles el crdito solicitado, pues en su momento solicitaron el crdito por motivos de urgencia. Por los motivos antes mencionados se formul como problema de investigacin lo siguiente: En qu medida el uso de un sistema multiagente basado en web services mejorar la etapa de levantamiento de informacin involucrada en el proceso de evaluacin de crdito?, frente a lo cual se plante que la etapa de levantamiento de informacin, involucrada en el proceso de evaluacin de crdito, mejorar ampliamente tras el uso de un sistema multiagente basado en web services, planteado como producto de la investigacin. Por lo antes expuesto el objetivo de la investigacin fue mejorar la etapa de levantamiento de informacin involucrada en el proceso de evaluacin de crdito, realizado por el Banco de Crdito del Per, mediante el uso de un sistema multiagente basado en web services, para lo cual se establecieron los siguientes objetivos especficos: eliminacin del desfase de tiempo en que Infocorp proporciona al Banco de Crdito del Per la informacin de los solicitantes, incremento del porcentaje de crditos otorgados correctamente a solicitantes cuya informacin sea acorde a lo requerido por el Banco de Crdito del Per, reduccin del tiempo invertido en la etapa de levantamiento de informacin, incremento del nmero de entidades pblicas y/o privadas de las cuales el banco obtiene informacin de los solicitantes de crdito, incremento del porcentaje de informacin actualizada e incremento del nivel de satisfaccin del cliente, solicitante de crdito, en base a la reduccin del tiempo invertido en la etapa de levantamiento de informacin involucrada en el proceso de evaluacin de crdito. II. MARCO REFERENCIAL A. Agente El trmino agente viene del latn agere que significa hacer. Agente deriva del participio agens. Expresa la capacidad de accin o actuacin de una entidad (Mas 2004). El concepto de agente caracteriza a una entidad software con una arquitectura robusta y adaptable que puede funcionar en distintos entornos o plataformas computacionales y es capaz de realizar distintos objetivos intercambiando informacin con el entorno, y con otros agentes humanos o computacionales. Las caractersticas destacables del comportamiento de un agente son: funcionamiento contino, comunicacin con el entorno y con otros agentes por medio de un lenguaje, robustez, adaptabilidad como capacidad de realizar objetivos y tareas en distintos dominios de forma incremental y flexible. B. Agentes Mviles Mas (2004) sostiene que la movilidad de un agente tiene que ver con su capacidad para desplazarse por los nodos de una red para realizar una determinada tarea. Se justifica por varios motivos. En primer lugar, la eficiencia, por ejemplo,

2 bsquedas de informacin, requiere la utilizacin intensiva de recursos remotos, el agente puede desplazarse al nodo o nodos donde estn los recursos, ahorrndose mltiples y lentos procesos de comunicacin. Otro motivo es la implementacin dinmica de nuevas funciones. Mas (2004) tambin afirma que el principal reto de la movilidad es conseguir que un agente se desplace a otro nodo conservando su estado interno; por ejemplo, el agente parte de un nodo con un conjunto de tareas a resolver y de datos iniciales sobre el problema, pero debe volver con la tarea del trabajo realizado y con los resultados obtenidos. C. Tipos de Agentes segn Caractersticas Individuales Pueden distinguirse dos categoras de agentes: agentes reactivos y agentes cognitivos. Los agentes reactivos realizan tareas sencillas. Su modelo computacional esta basado en un ciclo de recepcin de eventos externos/reaccin. Los agentes cognitivos realizan tarea complejas. Utilizan algn tipo de representacin explcita (simblica) del conocimiento E: Tipos de Agentes segn el Entorno Desde este punto de vista podemos considerar dos tipos de agentes: los que requieren un entorno especial, es decir una plataforma software especfica para su funcionamiento, y los que se ejecutan en las plataformas computacionales existentes. Un ejemplo de los primeros son los agentes mviles donde cada plataforma proporciona los mecanismos para gestionar su ciclo de vida y para que se desplacen de un nodo a otro. Los agentes que no usan plataformas especficas se crean mediante los recursos del sistema operativo y siguen el ciclo de vida de cualquier aplicacin. I: Tipos de Agentes segn Modo de Interaccin La interaccin comprende la comunicacin y el intercambio de informacin entre un agente y otras entidades. Se distinguen tres tipos de interacciones: agente-agente, agente-entorno y agente-persona. O: Tipos de Agentes segn Modo de Organizacin El punto de vista de la organizacin permite considerar a los agentes como entidades individuales que tienen un rol o funcin dentro de un conjunto o SMA con una finalidad comn. En primer lugar podemos distinguir entre agentes individualistas, que no tienen capacidad de cooperacin y realizan sus tareas solos, sin requerir la colaboracin de otros agentes, y agentes cooperantes, que pueden realizar tareas solos o colaborando con otros agentes. U: Utilidad La perspectiva de la utilidad permite clasificar los agentes de acuerdo con la finalidad o el propsito con el que fueron construidos. El conflicto cesa cuando la negociacin tiene xito, es decir, cuando las partes convergen en una solucin aceptable para todos. D. Tecnologas para Interaccin en Entornos Abiertos En la actualidad existen varias tecnologas que estn convirtindose en la referencia para desarrollar sistemas multiagente: XML, Java, RMI y CORBA. XML es el lenguaje de referencia para estructurar la informacin. Por otra parte, el lenguaje de programacin JAVA es el que claramente predomina en el desarrollo de los entornos de ejecucin de agentes. RMI permite la interoperatividad entre agentes

> 10 < heterogneos implementados en Java y CORBA amplia an ms las posibilidades de conexin. E. Coordinacin en los Sistemas Multiagentes Los sistemas multiagente (SMA) se conciben como sistemas software compuestos de mltiples entidades computacionales, encapsuladas, embebidos en un entorno. Esta generalmente aceptado que la coordinacin es una caracterstica clave de los SMA y que por otro lado, la capacidad de coordinarse con los dems es una propiedad clave de cualquier agente. El inters de la informacin est determinado por la necesidad de disear unos mecanismos de coordinacin eficientes entre entidades computacionales encapsuladas. F. Servicios Web Un servicio web o denominado tambin web services es una interfaz de red de acceso a la funcionalidad de una aplicacin, construidas usando tecnologas estndares de internet. Los servicios web son basados en los mensajes XML entregados a travs de protocolos estndar de Internet. Los mensajes de los servicios web pueden contener documentos o invocacin a procedimientos. Las definiciones especficas de servicios web varan ampliamente, y van desde un servicio web como una aplicacin que existe en un entorno distribuido, tales como el Internet (Sun Microsystems FAQ) a un servicio web como una interfaz que describe una coleccin de operaciones que son accesibles a travs de la red normalizada de mensajera XML (Kreger 2001). Los servicios web proporcionan una forma de acceder a negocios o aplicaciones lgicas usando protocolos de internet compatibles como HTTP, SMTP, o FTP. Debido a la adopcin generalizada de estos protocolos y formatos como XML, se espera que los servicios web, hagan frente a muchos de los requisitos para la interoperabilidad en entornos de procesamiento independiente y dominios. Los servicios web pueden superar las diferencias en las plataformas, lenguajes de desarrollo, y arquitecturas, permitiendo a las organizaciones llevar a cabo tareas de procesamiento cooperativo (Hartman et al. 2003). Usando XML y SOAP, los sistemas de diferentes mbitos con entornos independientes, diferentes arquitecturas y plataformas diferentes pueden participar en un esfuerzo distribuido para hacer frente a las necesidades empresariales, teniendo una estructura bsica. G. Ventajas de los Servicios Web Los servicios web tienen muchas ventajas que no disfrutan los anteriores intentos de interoperabilidad entre dominios. Los servicios web tienen muchas caractersticas que los diferencian de soluciones que vinieron antes que ellos y que lo hicieron un xito. Las ventajas de los servicios web son: Los servicios web permiten al abonado y al proveedor adoptar la tecnologa que est ms adaptado a sus necesidades para hacer el procesamiento. Los servicios web utilizan mensajes basado en XML. Estos servicios usan XML para tener un modelo flexible para el intercambio de informacin la cual es independiente del ambiente computacional.

3 Participar en servicios web no exige el abandono de las inversiones existentes en software. Las aplicaciones existentes se pueden utilizar para servicios web, aadiendo una interfaz. Esto hace posible la adopcin progresiva a estos servicios. Proveedores de software estn creando herramientas para apoyar el uso de los servicios web. Las organizaciones pueden utilizar las herramientas disponibles en la actualidad de los proveedores, como IBM, Microsoft, Sun, y otros. No hay demora entre el inters en la tecnologa y la disponibilidad de herramientas para aplicar y utilizar servicios web. Hay mucho nfasis en la interoperabilidad de servicios web. Herramienta de los desarrolladores de servicios web estn trabajando para demostrar la interoperabilidad entre implementaciones. Es probable que esto dar sus frutos y permitir a los desarrolladores elegir las herramientas de un proveedor y estar seguros de que ser capaz de interoperar con otras implementaciones. Los servicios web de forma modular, se estn definiendo para permitir elegir cules son las tcnicas que se adopten. Otro que teniendo una base en XML, SOAP, UDDI, y WSDL, los bloques de construccin de los servicios web se han relacionado, pero independientemente de la capacidad no son perfectamente acoplados y no dependen unos de otros para funcionar. El uso de protocolos estndar de internet significa que la mayora de las organizaciones ya tienen gran parte del software de comunicaciones y la infraestructura necesaria para prestar apoyo a los servicios web. Pocos nuevos protocolos deben ser apoyados, los entornos de desarrollo y los idiomas se pueden utilizar. Los servicios web pueden ser construidos e interoperar independientemente de los lenguajes de programacin y sistemas operativos. En las organizaciones donde no hay una norma nica, la interoperabilidad de servicios web lo hacen posible, incluso cuando una parte de la organizacin utiliza .NET, mientras que otra parte usa Java, u otra tecnologa para construir sus servicios web. III. DESARROLLO DEL SISTEMA A. Metodologa El sistema fue desarrollado utilizando la metodologa MASCommonKADS que comprende tres etapas: Etapa de Anlisis conformada por dos fases: la fase de conceptualizacin: en la cual se realiz la descripcin del problema, se identificaron y describieron los papeles de los actores con respecto al sistema desarrollado mediante plantillas textuales, y se identificaron y describieron casos de uso utilizando el diagrama de casos de uso y la notacin MSC (Diagrama de Secuencia de Mensajes), respectivamente, y la fase de anlisis: en la cual se realiz la especificacin del sistema compuesto a travs del desarrollo de los siguientes modelos: modelo de agentes, en el cual se especifican los agentes lgicos propios del sistema desarrollado utilizando plantillas textuales; modelo de tareas, en el cual se describieron, mediante plantillas textuales, las actividades que

> 10 < realizara cada agente en el sistema desarrollado; modelo de organizacin, en el cual se especific la organizacin de los agentes dentro del sistema desarrollado, estas especificaciones se realizaron a travs de plantillas textuales y la notacin OMT (modelo de objetos); modelo de coordinacin, en el cual se especificaron las relaciones existentes entre los agentes contemplados en el sistema desarrollado, para la representacin de estas relaciones se utiliz el diagrama de flujo de eventos; modelo de comunicacin, en el cual se especificaron las interacciones entre los usuarios y el sistema desarrollado utilizando diagramas de caso de uso; y el modelo de conocimiento, en el cual se especific el conocimiento de los agentes que fue relevante para la consecucin de sus tareas, en este modelo se desarroll la categora del conocimiento de dominio, en esta categora se defini dos tipos de conocimiento que los agentes poseen respecto a su entorno de trabajo, estos conocimientos son: conocimiento de la aplicacin y conocimiento del entorno. El primero referido al conocimiento que los agentes llegan a tener de los mdulos (gestin de solicitudes de crdito y gestin de consultas de informacin de clientes) del sistema, desde los cuales se emiten mensajes a estos agentes para que inicien su funcionamiento. El segundo tipo, referido al conocimiento que los agentes llegan a tener respecto a los web services de las entidades pblicas y privadas. Para cada tipo de conocimiento se estableci un esquema de dominio y la base de dominio, el primero referido al conjunto de conceptos y relaciones que conforman el conocimiento del agente, para lo cual se utilizaron notaciones textuales basadas en el lenguaje de modelamiento conceptual y notaciones grficas; y el segundo referido a la consolidacin de conceptos y relaciones en una sola base de dominio. Etapa de Diseo durante la cual se transformaron las especificaciones de los modelos desarrollados durante la fase de anlisis, de tal forma que se puedan describir con la herramienta de desarrollo utilizada durante la fase de implementacin. Durante esta etapa se desarrollaron los siguientes modelos: el modelo de red, en el cual se proporciona una visin de la red sobre la cual se encuentran establecidos los agentes; el modelo de la plataforma, en el cual se especific el lenguaje de implementacin y el gestor de base de datos utilizado; el modelo de dominio en el cual se diseo tanto la base de datos del sistema como las bases de datos de las entidades (SUNARP, RENIEC, SUNAT, Saga Falabella, Curacao), de acuerdo a los especificado en la base de dominio del modelo de conocimiento desarrollado durante la fase de anlisis, las bases de datos de las entidades mencionadas permitieron preparar los reportes necesarios para ser publicados en sus respectivos web services; el modelo de componentes en el cual se diagram la estructura (componentes) del sistema multiagente, que fue necesaria como gua durante la implementacin del sistema y el modelo de interfaces el cual cubri la descripcin de las interfaces del sistema. Etapa de Implementacin durante la cual se implement lo plasmado en la etapa de anlisis y diseo utilizando como herramienta de desarrollo Microsoft Visual Studio .NET 2005,

4 dentro del cual se utiliz como lenguaje de desarrollo ASP.NET, y el gestor de base de datos SQL Server 2005. B. Resultados Del desarrollo de las etapas de la metodologa MASCommonKADS se mostrarn los resultados ms saltantes que ayudaron finalmente a obtener el sistema multiagente basado en web services. Actores.- Se identificaron dos tipos de actores: externos e internos. Actores Externos: Solicitante, entidades privadas, entidades pblicas. Actores Internos: Gerente del Banco de Crdito del Per, evaluador de crdito. Casos de Uso.- Se identificaron tres casos de uso: gestin de solicitudes de crdito, gestin de consultas de informacin de clientes y gestin de web services.

Fig. 1. Diagrama de Casos de Uso

Descripcin de Casos de Uso.- En este apartado se realiz una descripcin de los casos de uso, mencionados en el punto anterior, mediante diagramas de secuencia de mensajes.

Fig. 2. Diagrama de Secuencia de Mensajes: Gestin de Solicitudes de Crdito.

> 10 <

Fig. 3. Diagrama de Secuencia de Mensajes: Gestin de Solicitudes de Crdito.

Fig. 6. Diagrama de Secuencia de Mensajes: Gestin de Consultas de Informacin de Clientes.

Fig. 4. Diagrama de Secuencia de Mensajes: Gestin de Solicitudes de Crdito.

Fig. 7. Diagrama de Secuencia de Mensajes: Web Services

Fig. 5. Diagrama de Secuencia de Mensajes: Gestin de Consultas de Informacin de Clientes

Definicin de Agentes.- Se definieron dos tipos de agentes reactivos: agente recolector y un agente validador. El agente recolector acta en el mdulo de gestin de consultas de informacin de clientes y debe cumplir los siguientes objetivos: 1. Detectar entidades pblicas y privadas en las cuales la persona consultada presente informacin. 2. Clasificar las entidades detectadas en entidades encontradas y entidades omitidas. 3. Detectar por cada institucin los mtodos pblicos, que contienen informacin de la persona consultada. 4. Consumir los web services de las entidades detectadas, accediendo a los mtodos pblicos que contienen la informacin de las personas consultadas. Para cumplir el primer objetivo el agente debe ejecutar los siguientes planes: Esperar a que el evaluador de crdito indique en la interfaz de usuario, la persona de quien se va a consultar informacin (cliente o aval) e indique el inicio de la bsqueda de informacin.

> 10 < Navegar a travs de la internetwork intentando establecer conexin con entidades privadas y pblicas, teniendo como medio de accedo los web services de cada entidad. Para cumplir el segundo objetivo el agente debe ejecutar los siguientes planes: De las entidades detectadas clasificar aquellas con las cuales se logr establecer una conexin satisfactoria y aquellas con las cuales no estableci una conexin, en entidades encontradas y entidades omitidas respectivamente. Entregar esta clasificacin a la interfaz de usuario para ser listadas en controles desplegables. Para cumplir el tercer objetivo el agente debe ejecutar los siguientes planes: Navegar a travs de la internetwork accediendo a cada entidad encontrada con el fin de identificar los mtodos (reportes) publicados en los web services de cada entidad. Entregar a la interfaz de usuario los nombres de los mtodos pblicos (reportes) encontrados. Para cumplir el cuarto objetivo el agente debe ejecutar los siguientes planes: Esperar que el evaluador de crdito indique en la interfaz de usuario la entidad que desea consultar, el reporte que desea visualizar y el inicio de la consulta de informacin. Navegar a travs de la internetwork accediendo a la entidad especificada en la interfaz de usuario y consumiendo del web services de la entidad el mtodo pblico que corresponde al reporte seleccionado en la interfaz de usuario. Entregar a la interfaz de usuario los resultados de la consulta. El agente comprobador acta en el mdulo de gestin de solicitudes de crdito y debe cumplir los siguientes objetivos: 1. Verificar la validez de los datos ingresados (datos personales, datos del aval y datos de la garanta concedida) en el formato de la solicitud de crdito. 2. Entregar mensajes a la interfaz del usuario, indicando los datos que no coinciden con los registrados en las entidades a las que el agente accedi, de manera que el usuario haga las correcciones respectivas. Modelo de Red.- Expresa una representacin de la red en la que interactan los agentes.

6 Base de Dominio (Sistema Multiagente).- La base de datos aqu presentada fue diseada teniendo como base el modelo de conocimiento (conocimiento del entorno) desarrollado en la fase de anlisis. Esta base de datos fue implementada en el gestor de base de datos SQL Server 2005 y es utilizada por los tipos de agentes definidos: agentes recolectores y validadores.

Fig. 9. Base de Dominio (Sistema Multiagente)

Modelo de Componentes.- En este apartado se presenta la arquitectura del sistema multiagente (arquitectura en tres capas) conformado por interfaces, libreras, interfaces externas, libreras externas y almacn de datos.

Fig. 10. Modelo de Componentes

Modelo de Interfaces.- Se definieron cuatro interfaces: Formulario de Solicitudes de Crdito, Formulario Listado de Solicitudes de Crdito en Proceso, Formulario de Consultas de Informacin y Web Services:

Fig. 8. Modelo de Red

> 10 < 1. Formulario de Solicitudes de Crdito Este formulario fue diseado en coordinacin con el Gerente del Banco de Crdito del Per y un evaluador de crditos del mismo banco, de tal forma que pudiera ser accesible va web a personas que deseaban solicitar un crdito. Este formulario de solicitud de crdito fue estructurado en cinco partes: datos personales del solicitante, datos sobre el trabajo del solicitante, datos sobre el aval del solicitante, datos sobre la garanta ofrecida y datos sobre el producto (Figura 11 Figura 15), y ser utilizado por los solicitantes de crdito para generar una nueva solicitud de crdito. El objetivo de este formulario es contrastar los datos que el solicitante ingrese en este formulario con los datos registrados en la RENIEC, SUNARP y SUNAT, evitando de esta forma generar una solicitud de crdito con datos errneos como viene sucediendo actualmente con el formato de solicitud tradicional utilizado por el Banco de Crdito del Per, el cual al ser llenado por el solicitante, este coloca datos incorrectos, intentando y muchas veces logrando engaar al evaluador de crdito, quien al no contar con una herramienta que le pueda proporcionar informacin actualizada permanentemente con el fin de comprobar los datos colocados en el formato, termina otorgndole el crdito solicitado. El objetivo de este formulario es realizado por el agente reactivo comprobador, quien entra en funcionamiento cuando el solicitante ejecuta en el formulario el comando enviar, y que a su vez navega a travs de la red accediendo a las entidades antes mencionadas va los web services implementados en cada entidad, con el fin de verificar que los datos ingresados en este formato de solicitud sean correctos, de no ser correctos los datos aqu ingresados, el agente nunca permitir que la solicitud de crdito se genere e indicar al solicitante, mediante avisos, cuales datos no coinciden con los registrados en las entidades antes mencionadas, dando opcin a que el solicitante corrija los datos que intencionalmente o no, ingreso errneamente o simplemente decida cancelar la solicitud, saliendo del formulario. Si el agente durante el proceso de verificacin no logr establecer conexin con alguna entidad, detecta que el solicitante y/o aval es menor de edad, o que no tiene ninguna garanta que ofrecer, entonces cancela inmediatamente la solicitud de crdito que se intenta generar.

Fig. 12. Informacin sobre Trabajo del Solicitante (2)

Fig. 13. Informacin sobre Aval (3)

Fig. 14. Informacin sobre Garanta (4)

Fig. 15. Informacin sobre Producto a Solicitar (5) 2. Formulario Listado de Solicitudes de Crdito en Proceso Este formulario ser utilizado por los evaluadores de crdito durante la etapa de levantamiento de informacin involucrada en el proceso de evaluacin de crdito, con el fin de listar las solicitudes de crdito en proceso, es decir aquellas solicitudes de crdito que han sido generadas a travs del formulario de solicitud de crdito y que an no han sido atendidas por los evaluadores de crdito. La bsqueda de estas solicitudes se puede realizar de dos formas: la primera listando todas las solicitudes de crdito en proceso y la segunda listando las solicitudes de crdito en proceso por solicitante. Si el evaluador de crdito selecciona en la lista desplegable la primera forma de bsqueda (Figura 16), entonces deber ejecutar el comando Buscar para obtener resultados. En caso contrario, si el evaluador escoge la segunda forma de

Fig. 11. Datos Personales del Solicitante (1)

> 10 < bsqueda (Figura 17) deber ingresar el DNI del solicitante y ejecutar el comando Buscar para obtener resultados. Para ambas formas de bsqueda se visualizarn los siguientes datos del solicitante y de su respectiva solicitud de crdito: DNI, Cliente (Solicitante), crdito solicitado, fecha de emisin, hora de emisin, monto solicitado, plazo de pago, cuotas, Aval (DNI) y nombre del aval. Si el evaluador desea visualizar el detalle de la solicitud deber seleccionar una de las solicitudes listadas y ejecutar el comando Ver Detalle, aperturndose el formulario web llamado detalle de solicitud. Si el evaluador desea iniciar la bsqueda o levantamiento de informacin del solicitante, deber seleccionar una de las solicitudes listadas y ejecutar el comando Iniciar.

8 de obtener aquellos reportes, de cada entidad encontrada, que contienen informacin de la persona consultada. Finalmente el evaluador de crdito deber seleccionar una institucin encontrada de la lista desplegable y el reporte que desea visualizar para luego ejecutar el comando Consultar. Al realizar esta ltima accin el agente reactivo recolector entra nuevamente en funcionamiento conectndose con la entidad elegida por el evaluador y obteniendo informacin del reporte indicado. Terminada la bsqueda, el agente entrega los resultados a la interfaz de usuario para ser visualizado por el evaluador de crdito.

Fig. 18. Formulario Consulta de Informacin 4. Web Services A continuacin se muestra la interfaz de uno de los web services desarrollados, correspondiente al web services de Saga Falabella. Cabe mencionar que solo se mostrar uno, pues la interfaz para el resto de los web services es la misma, lo que los diferencia uno de otros son los mtodos publicados en cada uno de ellos, a los cuales invocarn los agentes reactivos para extraer la informacin requerida durante la etapa de levantamiento de informacin de los solicitantes de crdito. Cabe mencionar que cada mtodo pblico corresponde a un reporte requerido por el evaluador de crdito al momento de llevar a cabo la etapa de levantamiento de informacin La interfaz inicial del web services al ser ejecutado muestra inicialmente los mtodos publicados para este servicio (Figura 19). Mtodos a los cuales los agentes reactivos accedern invocando cada uno de ellos, cuando el evaluador de crdito lo solicite. Cabe mencionar que estando en funcionamiento el sistema multiagente, no es necesario mantener el navegador aperturado mostrando los mtodos pblicos, basta que el proceso producto de la ejecucin del web services se mantenga activo, medio por el cual accedern los agentes reactivos a estos servicios. Por motivos demostrativos se invoc el mtodo 14 (Figura 20), el cual corresponde al reporte denominado compras al crdito, el cual requiere un parmetro de entrada que es el DNI del solicitante del cual se est consultando informacin. Cabe mencionar que estando en funcionamiento el sistema multiagente, los agentes reactivos sern quienes se encarguen de realizar dicha invocacin. Como resultado de la invocacin del mtodo 14 se muestra un formato XML (Figura 21) despus de haber ingresado el DNI del solicitante, conocimiento que previamente adquiere el agente reactivo encargado de realizar esta funcin quien finalmente termina consumiendo el contenido XML. El

Fig. 16. Listado de Solicitudes de Crdito en Proceso

Fig. 17. Listado de Solicitudes de Crdito en Proceso por Solicitante 3. Formulario Consulta de Informacin El objetivo de este formulario (Figura 18) es permitir al evaluador de crdito encontrar informacin actualizada del solicitante, necesaria para la evaluacin del crdito solicitado. Este formulario se apertura cuando el evaluador de crdito decide iniciar el levantamiento de informacin, para lo cual ejecuta el comando Iniciar en el formulario: Solicitudes de Crdito en Proceso. Una vez aperturado el formulario, el evaluador deber decidir si obtiene informacin del solicitante (cliente) o aval. Luego deber activar mediante un check la casilla de verificacin ubicada en instituciones, una vez realizada est accin el agente reactivo recolector, comenzar a detectar aquellas instituciones (SUNARP, SUNAT, RENIEC, Saga Falabella y Curacao) con las cuales puede establecer conexin para luego clasificarlas en entidades encontradas y omitidas. Adicionalmente el agente se encargar

> 10 < contenido XML muestra datos que han sido publicados de acuerdo al reporte que le corresponde al mtodo 14.

Fig. 22. Mdulos Formularios Web Implementados

Fig. 23. Entidades Web Services Implementados

Fig. 19. Mtodos publicados para el web services

Fig. 24. Entidad Web Services - # Mtodos Pblicos

IV. DISCUSION Fig. 20. Invocacin a Mtodos Pblicos Como se ha mencionado a lo largo de la investigacin, la forma en que Infocorp proporciona informacin de personas a travs de su sistema de consultas al Banco de Crdito del Per, no resulta ser la adecuada al momento de realizar la etapa del levantamiento de informacin de los solicitantes de crdito. Y no resulta adecuada en el sentido que la informacin proporcionada por Infocorp no es actualizada es decir es entregada con dos meses de retraso, lo cual trae consigo una serie de problemas descritos en el diagnstico realizado durante esta investigacin. Problemas cuya solucin ha sido enmarcada en un conjunto de teoras que se establecieron en relacin a la solucin propuesta en esta investigacin basada en el desarrollo de un sistema multiagente basado en web services. Las teoras que se formularon fueron las siguientes: Teora 1.- El sistema multiagente basado en web services permite obtener informacin de diversa ndole, necesaria para la etapa de levantamiento de informacin de solicitantes de crdito, que le permita al evaluador de crdito determinar la situacin en la que se encuentra el solicitante con el fin de decidir si se le otorga o no el crdito solicitado. Teora 2.- El sistema multiagente basado en web services permite que todo formato de solicitud generado por un solicitante va web, sea corroborado con los datos registrados del solicitante en la RENIEC, SUNARP, y SUNAT. Teora 3.- El sistema desarrollado permite una comunicacin 1 n, pero adicionalmente, teniendo en cuenta las bondades de

Fig. 21. Invocacin a Mtodos Pblicos Mdulos, Entidades y Web Services.- En este apartado se muestra un resumen de los mdulos implementados en ASP.NET 2005 (Figura 22), mdulos implementados por cada entidad (Figura 23) y los mtodos publicados en cada web services de cada entidad (Figura 24).

> 10 < los agentes y web services desarrollados se puede lograr una comunicacin basada en la topologa en malla. Teora 4.- La funcionalidad del sistema multiagente no se ve afectada si se tienen web services implementados bajo el mismo lenguaje en el que fue desarrollado el sistema multiagente o cualquier otro tipo de lenguaje. Teora 5.- El sistema multiagente permite tener acceso en todo momento y permanentemente a informacin actualizada, publicada en los web services de cada entidad, necesaria durante la etapa de levantamiento de informacin de los solicitantes. Teora 6. El sistema multiagente basado en web services, disminuye el riesgo de otorgar crditos incorrectamente as como el riesgo de negar un crdito a un cliente (solicitante) que si cumple con los requerimientos establecidos por el Banco de Crdito del Per. Teora 7. El sistema multiagente basado en web services, permite reducir el tiempo invertido en la etapa de levantamiento de informacin involucrada en el proceso de evaluacin de crdito. Teora 8. El sistema multiagente basado en web services, permite incrementar el porcentaje de informacin actualizada, a la que tiene acceso el evaluador de crditos durante la etapa de levantamiento de informacin. Teora 9. La reduccin de tiempo para llevar a cabo la etapa de levantamiento de informacin, implica una reduccin del tiempo invertido en el proceso de evaluacin de crdito, por tanto se logra que el cliente se encuentre satisfecho respecto al tiempo que al Banco de Crdito del Per le toma otorgar un crdito. V. CONCLUSIONES Las conclusiones presentadas en este apartado se basan en las teoras formuladas en la discusin de esta investigacin, las cuales al concretarse enmarcaran la solucin de los problemas descritos en los resultados de esta investigacin, logrando por tanto mejorar la etapa de levantamiento de informacin involucrada en el proceso de evaluacin de crdito. Por tanto se concluye que el sistema multiagente permite: 1. Proporcionar en todo momento informacin actualizada requerida durante la etapa de levantamiento de informacin, eliminando el hecho de obtener informacin con un desfase de tiempo equivalente a dos meses de retraso. 2. Reducir el riesgo de otorgar crditos inadecuadamente y el riesgo de negar crditos a solicitantes cuya informacin cumple con los requerimientos establecidos por el Banco de Crdito, logrando de esta forma incrementar el porcentaje de crditos otorgados correctamente. 3. Reducir a un da el tiempo invertido en la etapa de levantamiento de informacin reduciendo a nueve das el tiempo que toma realizar todo el proceso de evaluacin de crdito, logrando que el cliente se encuentre satisfecho con el tiempo que al Banco de Crdito le toma otorgar un crdito. 4. Incrementar el nmero de entidades de las cuales el Banco de Crdito obtenga informacin de diversa ndole,

10 evitando de esta forma obtener solo informacin de entidades cuyo nmero se encuentra determinado y limitado por Infocorp. 5. El evaluador de crdito acceda a un porcentaje de informacin actualizada equivalente al 100%. 6. Los web services implementados bajo cualquier lenguaje de programacin, no afecta la funcionalidad de los agentes reactivos englobados en el sistema multiagente. 7. Finalmente el cumplimiento de las conclusiones enunciadas como beneficios que superan los problemas descritos en esta investigacin permiti establecer la siguiente conclusin general: El sistema multiagente basado en web services, logra mejorar ampliamente la etapa de levantamiento de informacin. REFERENCIAS
[1] Bret Hartman, Donald J. Flinn, Konstantin Beznosov y Shirley Kawamoto. 2003. Mastering Web Services Security. Canada. Wiley Publishing, Inc. D. Galpert y L. Orozco, 2003, Uso de Servicios Web y SOAP en Comunidades en-lnea. Universidad Central Marta Abreu de Las Villas, Santa Clara, Villa Clara, Cuba. H. Chi Wong y Katia Sycara, 2000, Adding Security and Trust to Multiagent Systems. Carnegie Mellon University, Pittsburgh, PA, U.S.A. Luis F. Castillo, J, M. Corchado y Manuel G. Bedia, 2005. Modelo y Desarrollo de W-planner: Sistema Multiagente on-line Aplicado al Turismo Electrnico. Mas Ana. 2004. Agentes Software y Sistemas Multiagentes. Conceptos, Arquitecturas y Aplicaciones. Espaa. Pearson Prentice Hall. Somchart Fugkeaw, Piyawit Manpanpanich, and Sekpon Juntapremjitt, 2007, Multi-Application Authentication based on Multi-Agent System.

[2]

[3]

[4]

[5] [6]