Leer Artículo - Inicio - Universidad de los Andes

Sistema de Análisis y Validación de
Riesgo Crediticio: Una Aplicación de
Arquitectura Empresarial
Lázaro Coronado, Yony González, Andrea Medina, Nelson Montaño, Elvar Mosquera
[email protected], [email protected],
[email protected], [email protected],
[email protected]
RESUMEN
Como parte de la formación impartida por la Universidad de los Andes, en la
Especialización en Construcción de Software 2007, se desarrolló un proyecto
definido por el docente, dentro de un contexto académico, que permitiera
aplicar los contenidos de los cursos de la especialización.
El proyecto consistió en plantear e implementar una solución, para el
mejoramiento del proceso de análisis y validación de riesgo crediticio, en una
entidad bancaria ficticia.
Este artículo presenta el proceso de desarrollo y el producto resultante del
proyecto.
El proceso de desarrollo permitió terminar la construcción del producto,
cumpliendo a cabalidad con los requerimientos funcionales y no funcionales del
enunciado.
El producto está construido sobre una plataforma BPM/SOA, que permite
ilustrar la utilización del Framework TOGAF para implementar una Arquitectura
Empresarial, en el proceso de análisis y validación de riesgo crediticio.
Palabras Clave.
Arquitectura empresarial, TOGAF, SOA, aplicación de procesos de software
1. EL PROBLEMA
Se requiere proveer una solución integral (gerencia de proyectos, metodología y procesos
de desarrollo, especificación de arquitectura, construcción e implementación), para un
banco, que reporta problemas de recuperación de cartera vencida, debido a deficiencias en
el análisis del riesgo crediticio, alrededor de los diferentes productos que ofrece al
mercado (tarjetas de crédito, créditos de vivienda, créditos de vehículo, créditos de libre
consumo, entre otros).
En la actualidad la validación y calificación de riesgo son realizadas de la siguiente
manera:
1. El cliente ingresa la solicitud de uno de los productos por una página por internet.
2. Las solicitudes son luego consultadas por un empleado que tiene rol de analista de
solicitudes, quien procede a leer los datos y toma varias decisiones de manera manual
o arbitraría (es decir, se deja a criterio de una persona, no de una máquina):
a) Si la persona que hace la solicitud vive en una zona de estrato 1 o 2, es casada y
tiene 4 hijos, se rechaza la solicitud
b) Si la persona gana anualmente en salarios u otro tipo de ingresos, menos 80% del
monto que está solicitando en préstamo (ya sea como monto de tarjeta de crédito o
préstamo) procede a rechazar la solicitud.
c) Si la persona que actualmente está haciendo la solicitud es hombre, tiene entre 28
años y 34 años y es soltero y gana menos del 40% del monto solicitado, se debe
negar, ya que existe un riesgo alto que no pague.
3.
Si la solicitud no fue rechazada en el paso 2, el analista de solicitudes procede a enviar
la solicitud a una persona que tiene como rol “Validador de referencias”, quien
procede a:
a) Validar vía telefónica el historial crediticio, con empresas de calificación de riesgo
como Data Crédito. Si Data Crédito emite una recomendación o calificación
negativa sobre el cliente, se procede a rechazar la solicitud.
b) En algunos casos el help-desk de Data Crédito no contesta de manera oportuna al
teléfono, lo cual incomoda un poco al Validador de referencias, quien se cansa y no
deja de llamar a dicha central de riesgos. En contra parte, procede a llamar a alguna
de las personas que el solicitante colocó como recomendaciones personales, para
suplir así este paso de validador de referencias. De lo contrario procede a rechazar
la solicitud.
4. Si la solicitud no fue rechazada en el paso de 3, el analista de solicitudes procede a
enviar la solicitud a una persona que tiene como rol “Validador de listas negras” quien
procede a:
a) Llamar vía telefónica al DAS, para conocer si la persona que está realizando la
solicitud, tiene o ha tenido problemas con la justicia. En caso afirmativo se coloca
una marca en la solicitud, para que un superior tome la decisión, de aprobar o no la
misma.
b) Entrar a la página web del departamento de estado norteamericano, para saber si la
persona o a la empresa que está haciendo la solicitud, no está en la famosa “lista
Clinton”. En caso afirmativo se niega la solicitud.
c) Si el internet Explorer o browser del rol “Validador de listas negras” tiene
problemas que le impiden acceder a internet, este se da por vencido y omite el
paso, y para no tener el cargo de consciencia de negar la solicitud por información
no confirmada, deja seguir la solicitud hasta el siguiente paso del proceso.
5. Si la solicitud no fue rechazada en el paso 4, el analista de validación de listas negras
procede a enviar la solicitud a un supervisor de crédito, quien simplemente da un visto
bueno a partir de la información validada por los demás roles en pasos anteriores. Este
rol tiene principalmente como responsabilidad:
a) Revisar las evidencias, que llevaron a los demás roles a dejar pasar la solicitud
(Reporte de la llamada al DAS, Reporte de la pagina web de la lista Clinton,
reporte de la llamada Data Crédito, validar las reglas iníciales, etc.)
b) Colocar un visto bueno, si todas las evidencias son correctas, en caso contrario
procede a rechazar la solicitud.
c) Sin embargo, es importante anotar que si la persona que está realizando el rol de
“Supervisor de crédito” está muy ocupada o no está, simplemente se salta este paso
del proceso, y si la solicitud venia del paso anterior en estado de aprobada se
aprueba.
Las deficiencias del proceso actual del análisis del riesgo crediticio realizado por el banco,
son:
1. El proceso es ejecutado por varias personas de forma manual y por lo tanto es lento
(puede llegar a tardar más de un día), situación que le resta competitividad frente a los
otros bancos del sector que cuentan con procesos automatizados.
2. El incremento de la aprobación de productos del banco, a clientes con baja capacidad
de pago, debido a la omisión de controles y validaciones dentro del proceso como
consecuencia de la intervención humana.
3. Existe un riesgo de pérdida de confidencialidad sobre la información de los clientes, al
ser un proceso que usa medios inseguros, como el teléfono y la consulta de páginas
web por parte de los asesores.
Las directivas del banco buscan mejorar el proceso reduciendo la intervención humana,
convirtiéndolo en un sistema automático, que tendría como entrada, los datos de la
solicitud del producto crediticio y en apróximadamente 5 segundos retornaría una
respuesta, aceptando o rechazando dicha solicitud. La única intervención humana que se
desea para el proceso es la del cliente, quien seguirá empleando un interface web para
solicitar productos.
El Banco desea también, disponer de un reporte en línea, que indique todas las solicitudes
que han generado los clientes, y el estado de cada una de ellas (Aceptado a rechazado),
indicando la causa, cuando se trate de solicitudes rechazadas.
El esfuerzo invertido por el banco en este proceso, se justifica debido a que la aprobación
de productos de crédito, es su principal fuente de ingresos.
2. SOLUCIÓN
La estrategia de solución para el problema mencionado en la sección anterior, fue
recomendada desde el inicio del proyecto y consistió en el uso del framework de
Arquitectura Empresarial TOGAF [1]
Un framework de arquitectura empresarial [1], es una guía metodológica para realizar el
análisis de una empresa, con el fin de conocer el estado de sus procesos, sistemas que los
soportan y estructura organizacional.
Con este objetivo, existe “The Open Group Architecture Framework” (TOGAF), un
framework de arquitectura empresarial, que propone analizar desde diferentes puntos de
vista, los procesos de la empresa. Estos puntos de vista son:
•
•
•
Procesos de Negocio
Sistemas de Información
o Arquitectura de sistemas.
o Arquitectura de datos.
o Arquitectura de aplicaciones.
Arquitectura Tecnológica.
El análisis desde estos puntos de vista, permite plantear la tecnología que debe soportar los
procesos que posee la empresa y luego emprender planes de mejoramiento, priorizados de
acuerdo a los objetivos del negocio y competencia del mercado. Una vez priorizados los
planes, las empresas pueden crear su estrategia a corto y largo plazo, planeando sus
inversiones a través del tiempo.
Como resultado de este análisis de arquitectura empresarial, el negocio obtiene
gobernabilidad, es decir, control sobre sus procesos, documentación y conocimiento de los
mismos y la capacidad de mejorarlos.
La aplicación de la Arquitectura Empresarial al análisis y validación del riesgo crediticio,
fue pertinente porque se trata de un proceso importante para el banco, ya que es su
principal fuente de ingresos.
A continuación se describe el proceso de desarrollo, seguido para implementar el sistema
de análisis y validación de riesgo crediticio y las consideraciones técnicas del mismo.
2.1. PROCESO DE DESARROLLO
El proceso de desarrollo del proyecto, se centró en la aplicación de CMMI[2][3] y
gerencia de proyectos.
2.1.1. APLICACIÓN DE CMMI (Capability Maturity Model Integration)
El equipo de desarrollo del proyecto, siguió las prácticas establecidas en las siguientes
áreas de proceso de CMMI nivel 2:
•
•
•
•
•
Planeación del proyecto
Administración de requerimientos
Aseguramiento de calidad del proceso y del producto
Administración de configuraciones
Monitoreo y control
2.1.2. GERENCIA DE PROYECTOS
Las actividades de gerencia de proyectos siguieron la propuesta del PMI (Project
Management Institute) [4], en el que se presentan las fases de un proyecto que son:
•
•
•
•
•
Inicio
Planeación
Ejecución
Control
Cierre
2.1.2.1. Inicio
Durante la fase de Inicio del proyecto se constituyó el proyecto, a través de un
documento llamado “Carta de Constitución”, en el que se estableció el objetivo del
proyecto, el nombre del gerente del proyecto, la organización del equipo de
trabajo, presupuesto, suposiciones, restricciones y se consignó la aprobación de la
junta directiva (en este caso, el docente).
El grupo de trabajo, estuvo integrado por 5 ingenieros con habilidades
complementarias y experiencia, lo que permitió realizar una asignación de roles
adecuada al perfil de cada uno y trabajar como un equipo interdisciplinario.
Los roles establecidos fueron: gerente, líderes de desarrollo, de soporte, de
procesos y de calidad. Cada uno con responsabilidades específicas.
2.1.2.2. Planeación
La planeación fue guiada por un EDT (Estructura de desglose del trabajo) y un
cronograma asociado, elaborado al comienzo del proyecto, ajustado en las primeras
semanas de trabajo.
El EDT es un documento que refleja todas las actividades a realizar durante el
proyecto, visto desde diferentes niveles de detalle. El EDT muestra el alcance del
proyecto.
Dentro de las actividades de esta fase de gerencia del proyecto, se contempló el
plan para el aseguramiento de la calidad, en el que se usó la técnica de revisión de
pares, revisión de cumplimiento de estándares (definidos al interior del equipo) y
pruebas al producto.
Por otra parte, para la administración de riesgos, se creó un plan, que involucraba
la identificación de riesgos, estrategias de mitigación y contingencia. Cada semana
se realizó seguimiento a los riesgos.
Durante esta fase se seleccionó como ciclo de vida del producto, una adaptación de
RUP [5], por las siguientes razones:
•
•
RUP contempla labores de mitigación de riesgos.
Debido a su naturaleza iterativa, nos permite manejar una planeación a corto
plazo, detectar tempranamente las fallas y corregirlas lo antes posible.
2.1.2.3. Ejecución
Durante esta fase se llevaron a cabo las tareas establecidas para implementar el
producto.
2.1.2.4. Control
El control del proyecto se estableció por medio de reuniones a nivel de grupo y con
los docentes, que cumplian el rol de junta directiva.
Las actividades a cumplir por los integrantes se presentaban durante la reunión de
revisión y seguimiento semanal. Mensualmente se realizaban 8 reuniones.
2.1.2.5. Cierre
En esta etapa, se elaboraron los informes que acompañan el producto final, reportes
de gestión, lecciones aprendidas, presentación para la junta directiva y entrega del
producto.
2.1.3. HERRAMIENTAS
Las herramientas que apoyaron el proceso de desarrollo fueron:
EBPMN: Permite modelar los diagramas en notación BPM (Business Process
Modeling). Se usó para el modelamiento de las áreas de proceso de CMMI y
procesos de negocio del sistema de análisis y validación de riesgo crediticio.
WBSChart Pro: Herramienta para crear el EDT de forma gráfica. Se usó porque
facilita la creación de este documento y se integra con Microsoft Project, lo que fue
de gran apoyo para la creación del cronograma.
DotProject: Permite registrar las horas invertidas, en cada una de las tareas por
parte de los integrantes del equipo. Esto nos permitió presentar informes de valor
ganado y del estado del proyecto.
DocuWiki: Permite crear un sitio web, cuya actualización fue realizada por cada
uno de los integrantes del equipo. La información publicada, se referia a todos los
entregables del proyecto, metodologías seguidas, reportes individuales y toda
información relativa al proyecto. Para el sistema de análisis y validación de riesgo
crediticio que nos ocupa, dicha información se encuentra registrada en la Wiki
localizada en la dirección http://xue.uniandes.edu.co/~ecos10/
2.1.4. LECCIONES APRENDIDAS
Con respecto al proceso llevado a cabo para el desarrollo de este proyecto, se
resalta como aspecto para repetir y sugerir por haber tenido resultados positivos, el
hecho de haber realizado reuniones presenciales de avance y seguimiento,
apoyadas por agendas y actas, que permitieron recibir retroalimentación entre los
integrantes del grupo, compartir conocimientos, mantener la organización del
trabajo, seguimiento al avance del mismo, revisión de compromisos cumplidos y
pendientes y favorecer el crecimiento personal y profesional del grupo.
Dentro del proceso, también vale la pena destacar que la toma de Backups del
repositorio principal del proyecto (Wiki), ayudó a superar problemas técnicos fuera
de nuestro alcance, como fueron los periodos de tiempo en que la Wiki estuvo
fuera de servicio, y por supuesto permitió también conservar copias del trabajo
realizado.
2.2. PRODUCTO
El framework de arquitectura empresarial TOGAF, fue tomado como guía para
establecer los pasos a seguir, para la implementación del sistema de análisis y
validación de riesgo crediticio, dichos pasos fueron:
• Estudio de la cadena de valor del negocio: La cadena de valor de una empresa, es
un modelo que representa los procesos que permiten percibir ingresos a la
•
•
•
•
•
•
•
compañía, los que en conjunto, son denominados macroprocesos. El proceso de
análisis y validación de riesgo crediticio, se encuentra ubicado en el macroproceso
de productos y centros de competencia, dentro de la cadena de valor del banco.
Definición del estado actual de los procesos (AS-IS): Corresponde a la
especificación del problema presentado en la sección 1 Problema, de este artículo.
Definición del estado ideal de los procesos (TO-BE): Se refiere al proceso
mejorado al que se quiere llegar. En el sistema de análisis y riesgo crediticio,
contempló la consulta de un nuevo servicio en la Registraduria Nacional del
Estado Civil y la automatización de las actividades que componen el sistema.
Establecimiento de métricas o KPI’s [6]: Luego de la definición del estado TO –
BE del proceso, se pueden definir indicadores que permitan medir el desempeño de
las actividades que lo conforman. La recolección constante de los resultados de
estas métricas, permite ajustar el proceso con el fin de mejorarlo. Por ejemplo la
cantidad de solicitudes aceptadas respecto al total de solicitudes recibidas.
Análisis de brecha entre el estado actual de los procesos y el ideal: En este paso, se
plantearon iniciativas o acciones a llevar a cabo, para ir del estado AS-IS al TO-BE
del proceso. Estas iniciativas son calificadas con relación a criterios definidos
previamente como el nivel de riesgo, el beneficio que traerá a la empresa llevar a la
realidad esa iniciativa, entre otras. Dicha calificación permite priorizar las
inciativas y así saber qué hacer primero y a continuación, para alcanzar el objetivo.
En el sistema de análisis y validación del riesgo crediticio del banco, el análisis de
brecha dio como resultado, comenzar por la automatización del proceso de negocio
en si, para luego definir y adquirir la arquitectura tecnológica que lo soporta.
Definición de requerimientos: Se continuo con la definición de los requerimientos
funcionales y no funcionales, para el sistema de análisis y validación de riesgo
crediticio. Los requerimientos funcionales fueron: ingresar solicitud de préstamo,
validar riesgo crediticio del postulante, validar historial jurídico, validar historial
crediticio, enviar respuesta al postulante y generar reporte de solicitudes. Los
requerimientos no funcionales tratados fueron: tiempo de respuesta del periodo de
validación, persistir solicitudes de préstamo, enfoque de tecnología BPM/ SOA [7],
brindar seguridad a la informaión del postulante y permtir escalabilidad horizontal.
Definición y especificación de casos de uso y de la arquitectura a utilizar: A partir
de la definición de los requerimientos, se especifican los casos de uso del proceso,
como fueron ingresar solicitud, validar riesgo crediticio del postulante (que incluye
la aceptación o rechazo de la solicitud y las acciones asociadas), validar historial
crediticio con Data Crédito, validar antecedentes penales con DAS, validar datos
con lista Clinton en DEA, validar datos con la Registraduria Nacional del Estado
Civil y Consultar reporte de las solicitudes realizadas en un periodo de tiempo.
Definición de un dialecto agnóstico: una de las vistas de TOGAF, es la arquitectura
de datos, consiste en el estudio de la información que fluye en el proceso,
conociendo las carateristicas de los datos como son su tipo y valores posibles. Este
conocimiento permite definir un dialecto, que facilite la comunicación entre
diferentes sistemas o entidades, este dialecto es realizado en formato XSD (XML
Schema Definition), que facilita que los mismos puedan evolucionar con el tiempo
sin mayores problemas para la organización y además permite la integración de
sistemas heterogéneos y la facilidad para consumir servicios ofrecidos por distintas
entidades. Recordando que el sistema de análisis y validación de riesgo crediticio,
implica la comunicación del banco con otras entidades, este dialecto es de suma
importancia para el transporte de los datos.
• Construcción de las capas de acuerdo a la arquitectura: La Arquitectura Orientada a
Servicios SOA[7], fue la recomendación a aplicar en este proyecto. SOA permite el
intercambio de información entre proveedores y consumidores, independiente del
lenguaje de programación, sistema operacional, plataforma de hardware y dialecto
de negocio, mediante una estructura de capas. La capa consumidora se encarga de
la atención al cliente, que para el sistema de análisis y validación de riesgo
crediticio, contiene componentes que permiten que el cliente o postulante,
accediendo a una página web, realice la solicitud de alguno de los productos al
banco, siendo transparente para él, lo que ocurre entre enviar la solicitud y recibir
la respuesta. Los proveedores de servicios, corresponden a las aplicaciones o
sistemas, internos o externos a la organización, que pueden encontrarse en
diferentes plataformas y realizan funciones específicas. En el sistema que nos
ocupa, se trata de los servicios ofrecidos por el DAS, DATACRÉDITO, DEA y
Registraduria. En las capas intermedias se encuentra la lógica del negocio y los
componentes necesarios para realizar adecuadamene el transporte de la
información, independientemente del modelo de datos que utilicen los proveedores
y consumidores, de forma que llegue a cada uno de ellos el mensaje correcto. En
la sección 2.2.1. Componentes del sistema, se encuentra más información al
respecto.
• Implementación y adecuación de la interfaz gráfica: La única intervención humana
que requiere el sistema de análisis y validación de riesgo crediticio, es el ingreso
por parte del cliente, de los datos requeridos en la solicitud de un producto, por
medio de una página web. De esta forma se desarrolló una interfaz para este fin, la
que recibe información del cliente y activa el proceso automatizado de análisis de
riesgo, de acuerdo a la arquitectura definida. La página web permite además, el
ingreso a la consulta del reporte solicitado.
• Pruebas que confirmarán el correcto funcionamiento y la calidad del producto:
Finalmente se realizaron pruebas para entregar al banco, un sistema que cumpliera
con los requerimientos solicitados.
2.2.1. COMPONENTES DEL SISTEMA
En la Figura 1 se muestra la vista lógica de la arquitectura y los diferentes componentes
utilizados en el sistema y cada una de sus capas son explicadas a continuación.
Para un completo entendimiento del sistema puede referirse a la siguiente página
http://xue.uniandes.edu.co/~ecos10/wiki/doku.php?id=proyectogrado:desarrollo:desarrollo
Figura 1. Componentes del sistema
Descripción de los componentes
El sistema está compuesto por 5 capas, como son: capa de clientes o
consumidora(Aplicación Web), dos middleware (ESB Enterprise Service Bus), la capa de
negocio(BPM Business Process Modeling) y la capa de proveedores(Service providers),
las cuales aseguran la mantenibilidad, escalabilidad y robustez del sistema.
Los dos componentes ESB realizan las transformaciones y traducciones necesarias, para la
correcta comunicación entre la capa cliente y la capa de negocio y entre esta misma y los
proveedores de servicio que utilizan un dialecto propietario. De esta forma se consigue la
independencia del lenguaje de programación, sistema operacional, plataforma de hardware
y dialecto de negocio, que es la principal caraterística de SOA.
A continuación se explicará el propósito y las ventajas de cada una de las capas.
Propósito:
Ventajas:
Propósito:
Ventajas:
Tabla 1. Aplicación WEB
En esta capa se encuentran las aplicaciones que interactúan con el
usuario.
1. Al tener separada la lógica del negocio de la interfaz gráfica, esta
última puede sufrir modificaciones sin mayor impacto para el sistema
2. Los usuarios tienen acceso a esta capa sin conocer dónde y cómo se
ejecuta la lógica de negocio
3. Cada cliente puede interactuar con la capa de ESB Light, utilizando
diferentes protocolos (HTTP, SOAP, JMS, ETC.), sin afectar el
resultado.
4. Permite escalabilidad horizontal
Tabla 2. ESB Light
Conectar la capa del cliente con la capa BPM, desacoplando el llamado
de la lógica de negocio y el protocolo de transporte, este permite la
transformación del dialecto de los clientes al dialecto agnóstico del BPM
1. Único punto de control para el acceso a la lógica de negocio
2. Garantiza la gobernabilidad del acceso a la información.
3. Garantiza requerimientos no funcionales como auditoria, seguridad,
trazabilidad, etc.
4. Ofrece múltiples adaptadores para conectarse por cualquier protocolo
a la capa de BPM (HTTP, SOAP, JMS, Sockets, ETC.)
5. Realiza la transformación de datos para mantener datos agnósticos
dentro del sistema.
6. Por su manejo de MDB (Message Driven Beans), garantiza la
confiabilidad robustez y tolerancia a fallos.
7. Permite escalabilidad horizontal
8. Ofrece múltiples protocolos de entrada para los diferentes tipos de
clientes (HTTP, SOAP, JMS, ETC.)
Propósito:
Ventajas:
Propósito:
Ventajas:
Tabla 3. Proceso AVRC (BPM)
Realiza la orquestación de los procesos de negocio (AVRC: análisis y
validación de riesgo crediticio), ejecutando las funcionalidades ofrecidas
por los services providers (Providers Layer)
1. Ejecuta la orquestación de los procesos de negocio que el usuario
invoca
2. Se puede manejar en un servidor separado, en una zona de acceso
restringido.
3. Permite escalabilidad horizontal
4. Realiza procesos de compensación si alguna actividad del proceso no
se ejecuta con éxito, garantizando la integridad y confiabilidad del
proceso.
5. Maneja datos agnósticos permitiendo que los servicios ofrecidos sean
compatibles con las diferentes tecnologías.
6. Mediante la definición de KPI (Key Process Indicators), durante la
ejecución de cada proceso, se recopila información para alimentar un
dashboard con información en línea de como se está comportando el
negocio.
Tabla 4. ESB
Conectar la capa de BPM con la capa de providers layer, desacoplando el
llamado de los servicios y el protocolo de transporte, este permite la
transformación del dialecto agnóstico del BPM con el dialecto propietario
de los providers.
1. Este componente es el único punto de control, para el acceso a los
servicios ofrecidos por los proveedores, que pueden ser aplicaciones
existentes de la organización o servicios externos.
2. Garantiza la gobernabilidad del acceso a la información.
3. Garantiza requerimientos no funcionales como auditoria, seguridad,
trazabilidad, etc.
4. Ofrece múltiples adaptadores para conectarse por cualquier protocolo
a la capa de providers (HTTP, SOAP, JMS, Sockets, ETC.)
5. Realiza la transformación de datos agnósticos a los datos requeridos
por los proveedores de servicios.
6. Por su manejo de MDB(Message Driven Beans), garantiza la
confiabilidad robustez y tolerancia a fallos.
7. Permite escalabilidad horizontal
8. Ofrece múltiples protocolos de entrada por si la capa de BPM así lo
requiere (HTTP, SOAP, JMS, ETC.)
Propósito:
Ventajas:
Tabla 5. Services Providers
Ofrece servicios o funcionalidades que realizan la lógica de negocio,
pueden ser aplicaciones internas o servicios externos.
1. Se reutilizan las funcionalidades existentes.
2. Debido a que la capa de ESB no es intrusiva (no se realizan
modificaciones de código para comunicarse entre diferentes
lenguajes), cada proveedor expone su funcionalidad por el protocolo
que éste prefiera.
2.2.2. HERRAMIENTAS
A continuación se listan las herramientas que apoyaron el desarrollo del producto.
Enterprise Architect 7.0: Permitió realizar todos los diagramas de UML, como fueron los
casos de uso y vistas de arquitectura.
Eclipse 3.1: IDE de desarrollo, en el que se realizó el código fuente pertinente.
Oracle SOA Suite 10.1.3.1.0: Permite ejecutar los modelos de BPEL (Busines Process
Execution Languaje corresponde al BPM en ejecución).
JDeveloper 10.1.3.3.0: Permite desarrollar los modelos en BPEL.
JBoss-4.0.5.GA: Servidor de aplicaciones para desplegar los ESB.
Apache - Tomcat: Servidor que se utiliza como contenedor de los Web Services.
Ant: Programa para compilar, crear los Web Services, empaquetar y desplegar el producto.
2.2.3. UNA MUESTRA DEL PRODUCTO
El nuevo sistema de análisis y validación de riesgo crediticio, presenta al cliente, una
agradable e intuitiva interfaz gráfica, en la que debe diligenciar sus datos y los
correspondientes al producto solicitado. Después de enviar la información y
apróximadamente 5 segundos despues, el cliente recibe en la dirección de correo que
indicó, un mensaje de notificación en el que se le informa si fue aceptada o no su solicitud.
Lo que ocurre detrás de la vista del cliente, es el tratamiento dado a la información
enviada, para llevar a cabo la lógica del negocio, que contiene las reglas y validaciones
definidas por el banco, incluyendo consultas a entidades externas como Data Crédito,
DEA, DAS y Registraduría Nacional del Estado Civil, dependiendo de las cuales se acepta
o rechaza la solicitud del cliente o postulante.
En el demo que acompaña este artículo, se presenta el producto en funcionamiento, con
sus formularios de captura de información y la consulta estadística. Así mismo, es posible
apreciar el modelo BPEL y un ejemplo del flujo de la información que pasó a través de él.
3. CONCLUSIONES
Con relación a los procesos de desarrollo, la definición de los mismos al inicio de un
proyecto, siguiendo las prácticas de CMMI, permitió establecer la forma de trabajar desde
el principio, definiendo reglas y estándares, así como realizar mejoramiento continuo de
los procesos, mediante la evaluación de métricas determinadas, que ayudaron también a
una planeación de los recursos mas acertada, todo lo cual aporta un nivel superior de
calidad en el desarrollo del proyecto que se ve reflejado en el producto final y en el
cumplimiento de las metas establecidas.
Gracias a los procesos de desarrollo seguidos, se comprobó el cumplimiento del
cronograma planeado, a un menor costo en horas de trabajo, obteniendo un total de 786
horas trabajadas.
Por otra parte con relación al producto final del proyecto, las deficiencias del sistema de
análisis y validación de riesgo crediticio del banco, fueron superadas, al llevar el tiempo de
respuesta a una solicitud de un producto, de un día o más, a apróximadamente 5 segundos.
Otro beneficio obtenido por el banco con la implementación del sistema, es asegurar la
confidencialidad de la información del cliente, ya que las consultas a otras entidades, en
relación a sus antecedentes crediticios y penales, son realizadas automáticamente y no
conocidas por un asesor del banco. Un beneficio más, corresponde al fiel cumplimiento de
los controles y validaciones determinadas por el banco, al ser de forma automática,
controles que anteriormente al ser realizados de forma manual, en varias ocasiones eran
omitidos. Finalmente con el reporte de las solicitudes aceptadas y rechazadas, la gerencia
del banco puede tomar decisiones al respecto de sus políticas de credito.
4. REFERENCIAS
Para la culminación exitosa de este proyecto, se utilizaron como referencia principal, los
contenidos presentados por los profesores, en el transcurso de la Especialización en
Construcción de Software promoción 2007, destacando el material y conocimiento
aportado por los ingenieros Ruby Casallas, Jorge Arias y Alberto Cueto.
Se anotan a continuación otras referencias que pueden ser consultadas en relación con los
temas tratados.
[1] The Open Group. The Open Group Architecture Framework Version 8.1.1, Enterprise
Edition. [en línea]. (2006, Agosto). [Consultado 3 de mayo de 2008]. Disponible en
http://www.opengroup.org/architecture/togaf8-doc/arch/
[2]
Carnegie Mellon Software Engineering Institute: CMMI for Development Version
1.2. Pittsburgh agosto 2006.
[3] Colaboradores de Wikipedia. CMMI. En Wikipedia, La enciclopedia libre. [en línea].
(2008).
[Consultado
3
de
mayo
de
2008].
Disponible
en
http://es.wikipedia.org/w/index.php?title=CMMI&oldid=16739840.
[4]
Project Management Institute: Guía delos fundamentos de la dirección de proyectos
Guía del PMBOOK. Tercera Edición. 2004.
[5]
IBM. Rational Unified Process. [en línea]. [Consultado 3 de mayo de 2008].
Disponible en http://www-306.ibm.com/software/co/rational/rup.shtml
[6] Fred Bayles. Cómo determinar los indicadores clave de rendimiento (KPI) correctos
para su empresa. En Microsoft. [en línea]. (2008). [Consultado 3 de mayo de 2008].
Disponible
en
http://www.microsoft.com/mexico/empresas/businessvalue/businesskpis.mspx
[7] Service Oriented Architects Team. Arquitectura de referencia SOA. En: SOA Agenda.
[en línea]. (2007, Agosto) [Consultado 3 de mayo de 2008]. Disponible en
http://soaagenda.com/journal/articulos/arquitectura-de-referencia-soa/