SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA … · Arquitectura de Negocio, aunque técnicamente...
Transcript of SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA … · Arquitectura de Negocio, aunque técnicamente...
ICETEX
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS 22 - 12 DOCUMENTO DE ARQUITECTURA DEL NUEVO SISTEMA DE CRÉDITO Y CARTERA DEL
ICETEX
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
2
Historia de Cambios
Fecha Versión Descripción Autor
<06/Agosto/2007> <1.0> <Creación y revisión del Documento>
<Roberto Pardo, William Ciendua, Olga Alejandra Pantoja R. >
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
3
TABLA DE CONTENIDO
1. INTRODUCCION ..............................................................................................................................5
1.1. QUÉ ES ARQUITECTURA DE SOFTWARE ........................................................................................5
1.2. LO TRADICIONAL VS. NUESTRA VISION ..........................................................................................6
2. ARQUITECTURA DE NEGOCIO .........................................................................................................8
2.1. LA CLAVE DE LA ARQUITECTURA DE NEGOCIO ..............................................................................8
2.1.1. DIAGRAMA ........................................................................................................................................... 9
2.1.2. GLOSARIO.......................................................................................................................................... 10
2.1.3. CONVENCIONES UTILIZADAS EN EL DIAGRAMA ................................................................................ 12
2.2. OBJETOS DEL SISTEMA .............................................................................................................. 13
2.3. LISTA DE ESTADOS POR OBJETO ................................................................................................ 15
2.3.1. CAUSALES DE ANULACION DE LA SOLICITUD DE ADJUDICACION ..................................................... 25
2.3.2. CAUSALES DE NO APROBACION DE LA SOLICITUD DE ADJUDICACION ............................................. 26
2.3.3. CAUSALES DE ELEGIBLE DE LA SOLICITUD DE ADJUDICACION ......................................................... 26
2.3.4. CAUSALES DE APLAZAMIENTO EN LA RENOVACION ......................................................................... 26
2.3.5. CAUSALES DE BLOQUEO EN LA RENOVACION .................................................................................. 27
2.3.6. CAUSALES PARA EL PASO DEL CREDITO A ETAPA FINAL DE AMORTIZACION ................................... 27
2.4. DIAGRAMA GENERAL DE ESTADOS. ............................................................................................ 29
2.4.1. TRANSICIÓN DE ESTADOS DE LA SOLICITUD. .................................................................................... 36
2.4.2. TRANSICIÓN DE ESTADOS DE LA RESOLUCIÓN................................................................................. 39
2.4.3. TRANSICIÓN DE ESTADOS DEL GIRO DEL BENEFICIARIO .................................................................. 39
2.4.4. TRANSICIÓN DE ESTADOS DE LA OPERACIÓN DE CRÉDITO ............................................................. 40
2.4.5. TRANSICIÓN DE ESTADOS DE LA RENOVACIÓN ................................................................................ 41
2.4.6. TRANSICIÓN DE OPERACIÓN CARTERA ............................................................................................ 42
2.5. SUBESTADOS DE CARTERA ........................................................................................................ 46
2.6. DIAGRAMA DE ESTADOS PARA FONDOS CERRADOS (P.E. COOPERATIVAS) .................................. 47
2.7. TRANSICIÓN DE ESTADOS DE LA SOLICITUD ................................................................................ 54
2.8. RESUMEN DE REQUERIMIENTOS TECNICOS ................................................................................. 54
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
4
3. ARQUITECTURA LOGICA ............................................................................................................... 55
3.1. SOA Y NIVELES/CAPAS ............................................................................................................... 57
3.1.1. REQUERIMIENTOS TECNICOS ........................................................................................................... 57
3.2. BPM .......................................................................................................................................... 58
3.2.1. REQUERIMIENTOS TECNICOS ........................................................................................................... 61
3.3. INTERFASE DE USUARIO (IU) Y FORMULARIOS............................................................................. 62
3.3.1. REQUERIMIENTOS TECNICOS ............................................................................................................ 63
3.4. SERVICIOS ................................................................................................................................. 64
3.4.1. SERVICIOS DE CALCULOS ................................................................................................................... 64
3.4.2. SERVICIOS DE INTEGRACION ............................................................................................................. 66
3.4.3. SERVICIOS UTILITARIOS DE NEGOCIO ................................................................................................ 66
3.4.4. SERVICIOS UTILITARIOS DE SISTEMAS ............................................................................................... 67
3.5. OPTIMIZACION .......................................................................................................................... 67
3.5.1. CACHE APLICATIVOS .......................................................................................................................... 67
3.5.2. REQUERIMIENTOS TECNICOS ............................................................................................................ 68
3.6. BASES DE DATOS Y PERSISTENCIA ............................................................................................... 68
3.7. SEGURIDAD Y AUDITORÍA ........................................................................................................... 69
3.8. PATRONES GENERALES ............................................................................................................. 70
4. ARQUITECTURA FISICA ................................................................................................................. 70
4.1. PLATAFORMAS .......................................................................................................................... 70
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
5
1. INTRODUCCION
EL objetivo de este documento es presentar los lineamiento de la Arquitectura del nuevo Sistema de
Software de Crédito y Cartera del ICETEX (para abreviar lo llamaremos el SCC, pero se espera que más
adelante tenga un nombre más interesante). Esta es la primera versión de la misma y debe ser detallada y
afinada a lo largo de la construcción del sistema, tal como lo indican las buenas prácticas iterativas e
incrementales de la metodología RUP. Sin embargo la esencia fundamental de la arquitectura está
delineada en este documento y es la base de los requerimientos técnicos de arquitectura en los términos
de referencia para la construcción y/o adaptación final del sistema. Para realizar este documento se
analizaron los requerimientos expresados en los Casos de Uso de Sistemas del nuevo Sistema de Crédito
y Cartera. Igualmente se han tenido en cuenta las políticas de Informáticas definidas en el ICETEX en
cuanto a uso de hardware, software de infraestructura, políticas de seguridad, y realización de otros
proyectos de sistemas de información definidos en el Plan de Informática.
1.1. QUÉ ES ARQUITECTURA DE SOFTWARE
Arquitectura de Software es, a grandes rasgos, una vista de un sistema que define los principales
componentes, el comportamiento de éstos, y las formas en que los componentes interactúan y se
coordinan para alcanzar el objetivo del sistema. La vista arquitectónica es una vista abstracta, aportando el
más alto nivel de comprensión y suprimiendo detalles que no cambian las abstracciones.
Esta es una definición tal vez demasiado amplia. Un autor establece que la arquitectura de software de un
sistema constituye un puente entre el requerimiento y el código, ocupando el lugar que en los gráficos
antiguos se reservaba para el diseño. La definición más “oficial” de Arquitectura tal vez es la que se
encuentra en el documento de IEEE1471:
“La Arquitectura de Software es la organización fundamental de un sistema encarnada en
sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su
diseño y evolución.”
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
6
Aunque existen muchas definiciones de Arquitectura de un Sistema de Software, la esencia de todas es
que Arquitectura es la descripción de la estructura fundamental de un sistema. La Arquitectura permite
pensar sobre la estructura global sin caer en los detalles de algoritmos y estructuras de datos. La
Arquitectura permite visualizar y analizar cómo interactúan las partes que componen un sistema. Se
pretende identificar los mecanismos de comunicación y sincronización entre sus partes, cuáles partes
manejan las grandes divisiones funcionales de un sistema que interesan a los usuarios, y cómo deben ser
las partes que manejan las funciones clásicas del software en cuanto a presentación al usuario, a reglas
de negocio y a datos persistentes.
Mediante la Arquitectura se puede analizar un sistema a un nivel alto de abstracción mostrando las
principales decisiones de diseño. Es importante que la Arquitectura sea de alto nivel pues un sistema de
software se compone de miles de detalles que muchas veces obscurecen las decisiones de fondo, las que
a su vez determinan las principales propiedades técnicas de un sistema como rendimiento, escalabilidad,
flexibilidad, reutilización, entre otros.
En la metodología RUP, la definición de una Arquitectura de un Sistema es una actividad fundamental en
la fase de Elaboración, por cuanto determina la estructura global del sistema, y así permite definir más
claramente el esfuerzo que se hará durante la fase de Construcción. Sólo cuando se ha definido la
Arquitectura se puede definir realmente el presupuesto de construcción de un sistema. Cualquier
estimativo anterior puede estar muy desfasado de la realidad.
Es importante aclarar que arquitectura no es diseño. En Arquitectura se toman las decisiones de fondo
mientras que en el diseño se detallan las decisiones de fondo sin programar aún. En este documento se
describe así la Arquitectura del SCC, sin entrar en los detalles de diseño pero sí identificando la forma
como se debe estructurar el sistema y definiendo los principios de diseño del mismo.
1.2. LO TRADICIONAL VS. NUESTRA VISION
Tradicionalmente la Arquitectura de software de un sistema se ha trabajado como un tema muy técnico y
muy orientado al ámbito de software. Nuestra visión es diferente. Creemos que lo técnico es muy
importante, pero más importante es la estructura que se le de a la solución desde el punto de vista de
negocio. Creemos después de haber construido varios sistemas grandes que una Arquitectura de Software
refleja íntimamente una Arquitectura de Negocio y por lo tanto si la Arquitectura (léase “la estructura de la
solución”) de Negocio está mal concebida, así mismo la Arquitectura de Software reflejará una mala
Arquitectura de Negocio, aunque técnicamente puede ser muy sólida. Creemos que la escritura como tal
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
7
de Casos de Uso de Sistema refleja una concepción de Negocio y muchas veces la misma arquitectura de
negocio, que más tarde condiciona la Arquitectura Técnica de Software.
Para efectos de este trabajo Arquitectura es equivalente a estructura de la solución. Así, Arquitectura de
Negocio (o Arquitectura Conceptual) es la estructura de la solución de negocio, que no necesariamente
tiene que ver con tecnología o software. La Arquitectura de Software o de Sistema (o Arquitectura Lógica)
es la estructura de la solución de software, que refleja la Arquitectura de Negocio, debe estar alineada
con éste, y no está necesariamente atada a una plataforma de software o hardware. Finalmente la
Arquitectura de Implantación (o Arquitectura Física) es la estructura de la solución en términos de
plataforma de software y hardware.
Cada tipo de Arquitectura es como una forma de ver (una “vista”) del sistema. Las vistas son
complementarias pues se requieren todas para entender la estructura completa del sistema, pero como se
indicó anteriormente, la Vista Conceptual es la más importante por cuanto define la estructura del negocio
como tal. Resumiendo, para efectos de este trabajo se han agrupado varias Vistas en lo que llamamos
tres tipos de Arquitectura: la Conceptual, la Lógica y la Física.
Arquitectura Conceptual = Arquitectura de Negocio
Describe la estructura básica de la solución, basada en los Requerimientos y Casos de Uso de
Negocio. En esta vista se toman decisiones CONCEPTUALES importantes que definen la
estructura de la solución de software. Por ejemplo en el SCC se define que todas las líneas de
crédito del ICETEX son “similares en cuanto a su estructura” y lo que las diferencia son
parámetros expresados en forma de reglas de negocio y condiciones. Aún más importante, la
arquitectura conceptual del SCC define los objetos de negocio clave (solicitud, cartera, deudor,
etc.) y hace un modelo de estados por los que pasan estos objetos durante la vida de un crédito
en el sistema.
Arquitectura Lógica = Arquitectura Técnica del Sistema = Arquitectura de Software.
Describe los componentes lógicos del sistema, su estructura interna básica, y sus relaciones.
Incluye los componentes lógicos tanto de negocio (funcionales) como técnicos (no funcionales).
Normalmente es independiente de la Plataforma tecnológica en la que se implementará el sistema.
Incluye la llamada Vista Lógica. A veces incluye la Vista de Datos cuando se describe la
persistencia de ciertas entidades de negocios. En el SCC la Arquitectura Lógica define una
estructura basada en capas y servicios. Identifica los servicios tanto funcionales como técnicos.
Arquitectura Física = Arquitectura de Implantación.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
8
Describe las tecnologías que se deben usar de la Plataforma escogida y decisiones básicas sobre
asociación de componentes lógicos y físicos. Describe decisiones sobre la Plataforma
(frameworks, librerías, patrones), las decisiones sobre Arquitectura de Hardware (tipos de
servidores, tipos de clientes) y guías de diseño en la plataforma escogida. En el SCC la
Arquitectura Física define la Plataforma JEE5, algunos patrones y librerías, y algunas
configuraciones de hardware.
En este documento explicamos cada una de estas vistas en cierto detalle. Dado que el sistema se va a
construir externamente, el enfoque de estas vistas es detallar lo necesario para definir unos requerimientos
técnicos, tratando de no restringir a los posibles proveedores y dejando libertad al contratista para decidir
aspectos del diseño del sistema.
2. ARQUITECTURA DE NEGOCIO
En esta sección presentamos la arquitectura de negocio del SCC.
2.1. LA CLAVE DE LA ARQUITECTURA DE NEGOCIO
Existen tres principios fundamentales sobre los cuales está basada esta arquitectura, a saber:
1. Todos los productos de crédito se deben poder representar en el mismo aplicativo. Esto evita los
problemas de generar aplicaciones separadas dependiendo de las especificidades de los
productos de crédito. Un solo ejecutable que maneja todo.
2. El software debe modelarse fundamentalmente como un sistema basado en estados, donde un
“crédito” (llamado así desde el punto de vista de un usuario) viaja por una multitud de estados
(solicitud radicada, solicitud aprobada, resolución generada, giro en firme, operación de cartera al
día, etc.). Existen condiciones y acciones que hacen pasar a un crédito de un estado a otro. Cada
producto define sus propios caminos y condiciones dentro del sistema de estados.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
9
3. El sistema es altamente parametrizado, es decir, muchos valores, tablas, fórmulas y algoritmos se
deben poder cambiar fácilmente sin necesidad de recompilar o generar nuevos ejecutables.
2.1.1. DIAGRAMA
Gráficamente, la arquitectura conceptual puede dibujarse así:
En esta sección presentamos la estructura del sistema usando estados, y mostramos la relación de éstos
con los casos de uso.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
10
2.1.2. GLOSARIO
Acción
Creación de un objeto destino como consecuencia de un cambio de estado de un objeto origen.
Diagrama de Estados
Es un grafo que muestra el conjunto de estados por los cuales pasa un objeto durante su vida en una
aplicación, junto con los cambios que permiten pasar de un estado a otro.
Los Diagramas de Estado representan autómatas de estados finitos, desde el punto de vista de los
estados y las transiciones. Son útiles sólo para los objetos con un comportamiento significativo. Cada
objeto está en un estado en cierto instante. El estado está caracterizado parcialmente por los valores
de los atributos del objeto. El estado en el que se encuentra un objeto determina su comportamiento.
Cada objeto sigue el comportamiento descrito en el Diagrama de Estados asociado a su clase. Los
Diagramas de Estados y escenarios son complementarios, los Diagramas de Estados son autómatas
jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos, son grafos
dirigidos y deterministas. La transición entre estados es instantánea y se debe a la ocurrencia de un
evento.
Estado
Es la identificación durante un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está
esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
11
Evento
Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia
puede corresponder a una:
o Condición que toma el valor de verdadero o falso o Recepción de una señal de otro objeto en el modelo o Recepción de un mensaje o Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha
particular
Objeto
Es una entidad lógica dentro de la aplicación que tiene sentido para el usuario del sistema, es una
unidad atómica que encapsula estado y comportamiento. Se define a un objeto como "una entidad
tangible que muestra alguna conducta bien definida". Un objeto "es cualquier cosa, real o abstracta,
acerca de la cual almacenamos datos y los métodos que controlan dichos datos".
SubEstado
Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel
superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen
conectados a las entradas y salidas del nivel inmediatamente superior.
Transición
Es una relación entre dos estados que indica que un objeto en el primer estado puede pasar al
segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son
satisfechas. También hace referencia al cambio de un estado de un objeto destino como consecuencia
del cambio de estado de un objeto origen.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
12
2.1.3. CONVENCIONES UTILIZADAS EN EL DIAGRAMA
CONVENCION DESCRIPCION
Inicio o Creación del objeto.
Estado no final de un objeto.
... .
Estado Final de un objeto.
Transición o Acción.
Perímetro de los estados de un objeto.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
13
2.2. OBJETOS DEL SISTEMA
Solicitud
AdjudicaciónResolución
Giro por
Beneficiario
Crédito
Obligación
Cartera
Renovación
Transacción
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
14
OBJETO DESCRIPCIÓN
Solicitud de Adjudicación Entidad que contiene la información registrada por el solicitante y
que hace parte de los datos del otorgamiento del crédito. .
Resolución Entidad que representa el documento soporte a un desembolso
de dinero, bien sea en la adjudicación del crédito como en la
renovación del mismo
Giro Entidad que representa los datos del desembolso
Crédito Entidad que se crea en el momento del primer desembolso y que
constituye posteriormente una obligación
Obligación Cartera Entidad que contiene la información de los saldos de la deuda de
crédito del beneficiario y su comportamiento de pago
Renovación Entidad que determina la ejecución o no de un desembolso.
Transacción Entidad que registra la ejecución de la disponibilidad
presupuestal, operaciones sobre el presupuesto y la tesorería,
giros, pagos y novedades de cartera
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
15
2.3. LISTA DE ESTADOS POR OBJETO
OBJETO ESTADO DESCRIPCION
Solicitud de Adjudicación Radicada Parcial No hay completitud en los
datos que se registran en la
solicitud de adjudicación. Se
constituye en el primer estado
de la solicitud de crédito
Radicada Se han ingresado la totalidad
de los datos.
En Estudio La solicitud se encuentra en
proceso de evaluación por
parte del comité de crédito
No Aprobada (*) Después del proceso de
evolución acorde con las
políticas del ICETEX la
solicitud presenta causales de
no aprobación
Elegible La solicitud cumple con todos
los requisitos para que sea
aprobada la solicitud pero no
existe disponibilidad
presupuestal. Esta solicitud
queda pendiente de aprobación
o no aprobación en los
próximos comités.
Anulada (*) Es el no otorgamiento del
crédito por las causales de
anulación.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
16
OBJETO ESTADO DESCRIPCION
Aprobada La solicitud cumple con todos
los requisitos y esta lista para
continuar con la legalización.
Desistida (*) Es cuando el beneficiario
informa de su renuncia al
proceso para obtener el
crédito.
Legalizada Confirmación del cumplimiento
de los requisitos exigidos por el
ICETEX de los documentos de
carta de compromiso y pagare.
Visada Es la aprobación por parte del
ICETEX consecuencia de la
revisión final de toda la
documentación e información
ingresada de la solicitud.
Generada en resolución Es cuando la solicitud hace
parte de una resolución de giro
pero la resolución aún no ha
sido autorizada para
desembolso
Aprobada en resolución Es cuando la solicitud hace
parte de una resolución de giro
y dicha resolución tiene la
autorización para el
desembolso
Enviada en
resolución
Es cuando la solicitud es parte
de la resolución de giro en
estado enviada.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
17
OBJETO ESTADO DESCRIPCION
Girada (*) El sistema financiero le informa
al sistema de crédito y cartera
que números de cuenta
pudieron ser giradas, cuentas
que están relacionadas con
una solicitud de crédito; en ese
caso la solicitud queda en
estado girada.
No Girada (*) El sistema financiero le informa
al sistema de crédito y cartera
que números de cuenta no
pudieron ser giradas, cuentas
que están relacionadas con
una solicitud de crédito; en ese
caso la solicitud queda en
estado no girada.
Estas solicitudes quedan
disponibles en el sistema para
ser reprocesadas.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
18
OBJETO ESTADO DESCRIPCION
Resolución Generada Se establecen los parámetros
de la resolución como
documento de soporte al
desembolso de un conjunto de
solicitudes de adjudicación o
renovación visadas.
Aprobada Es la aprobación de
desembolso.
Anulada Es la no aprobación de la
resolución
Enviada Es el envío de la resolución
aprobada al sistema financiero.
Notificada Es la respuesta del sistema
financiero de la resolución
enviada.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
19
OBJETO ESTADO DESCRIPCION
Giro por Beneficiario En Proceso Hace referencia al desembolso
del beneficiario se encuentra
en la resolución generada,
aprobada o enviada.
En firme Es la realización del
desembolso al beneficiario
consecuencia de la respuesta
enviada del sistema financiero.
Anulada El giro se anuló a causa de la
anulación de la resolución que
lo contenga
Rechazado El giro no fue exitoso.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
20
OBJETO ESTADO DESCRIPCION
Crédito Activo sin bloqueo El crédito tiene desembolsos
pendientes y cumple con la
condiciones para la renovación
del crédito
Activo con bloqueo El crédito tiene desembolsos
pendientes y está inhabilitado
para realizar la renovación del
crédito
Activo Aplazado El crédito tiene desembolsos
pendientes y esta sin ninguna
restricción para ejecutar la
renovación de desembolso.
Activo sin desembolsos
pendientes
El crédito NO tiene
desembolsos pendientes.
Finalizado El crédito ya fue cancelado.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
21
OBJETO ESTADO DESCRIPCION
Obligación Cartera CEE al día El crédito se encuentra en
época de estudio al día.
CEE atrasado en cuota El crédito se encuentra en
época de estudios y atrasado
en cuota de cultura de pago
CPG al día El crédito se encuentra en
periodo de gracia al día.
CPG atrasado en cuota El crédito se encuentra en
periodo de gracias y atrasado
en cuotas
CEA al día El crédito se encuentra en
Etapa final de amortización al
día.
CEA Mora El crédito se encuentra en
Etapa final de amortización en
mora.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
22
OBJETO ESTADO DESCRIPCION
Subestados de Mora del
objeto Obligación Cartera
(Estos subastados pueden ser
parametrizables a partir de la
mora en cuotas o por la
calificación de la cartera)
Cobro preventivo El crédito se encuentra entre 1
y 30 días de mora.
Cobro correctivo El crédito se encuentra entre
31 y 60 días de mora.
Cobro pre-jurídico El crédito se encuentra con
más 60 días de mora.
Cobro Jurídico El crédito se encuentra con
más de 180 días de mora.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
23
OBJETO ESTADO DESCRIPCION
Subestados del objeto
Obligación Cartera
Normal Se tiene confianza en el pago
de la obligación.
Castigada Se entiende por cartera
vencida aquella respecto de la
cual el plazo ordinario de pago
se ha cumplido, encontrándose
el deudor en mora en el pago
de las obligaciones. A su turno,
por cartera castigada se debe
entender aquella cartera
vencida respecto de la cual se
han agotado los
procedimientos de cobro sin
ningún resultado lo que hace
temer que el derecho de
crédito no sea recuperable.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
24
OBJETO ESTADO DESCRIPCION
Subestados del objeto
Obligación Cartera
No reestructurado No hay cambios de
condiciones originales que
obedezcan a un deterioro en la
capacidad de pago por parte
del deudor.
Reestructurado Se considerará un crédito
como reestructurado siempre
que un cambio en los términos
y condiciones originalmente
pactadas sean motivadas por
un deterioro en la capacidad de
pago de los créditos por parte
del deudor
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
25
OBJETO ESTADO DESCRIPCION
Renovación Bloqueada Se presentó una causal de
bloqueo para que la renovación
de desembolso no pueda
realizar.
Aplazada Se presentó una causal de
aplazamiento para que la
renovación de desembolso no
pueda ser realizada.
Desistida Se presentó una causal de
desistimiento para que la
renovación de desembolso no
pueda ser realizada.
Aprobada Se cumplieron con todos los
requisitos para renovar la
solicitud de desembolso.
2.3.1. CAUSALES DE ANULACION DE LA SOLICITUD DE ADJUDICACION
Por vencimiento de términos.
Por solicitud del Beneficiario del crédito
Por inconsistencias en los datos (falsedad en información cuando se realiza validación de datos) en especial cuando son datos evaluables.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
26
2.3.2. CAUSALES DE NO APROBACION DE LA SOLICITUD DE ADJUDICACION
Por mérito académico,
Decisión de no aprobar la solicitud elegible
Por no cumplir con alguno de los requisitos evaluables definidos en la parametrización de cada modalidad de crédito y/o fondo.
2.3.3. CAUSALES DE ELEGIBLE DE LA SOLICITUD DE ADJUDICACION
Por la no disponibilidad presupuestal de una solicitud que cumple con todos los requisitos para ser aprobada.
2.3.4. CAUSALES DE APLAZAMIENTO EN LA RENOVACION
1. Retiro temporal del programa académico por calamidad doméstica, incapacidad certificada, fuerza mayor o caso fortuito entre otros, debidamente justificados por el beneficiario.
2. Obtención de beca u otra forma de cubrimiento de los costos académicos, otorgada por la Institución de Educación Superior u otra entidad, sin límite de períodos académicos.
3. Cierre temporal del centro docente y/o programa académico. 4. Por expresa voluntad del beneficiario 5. Por enfermedad, fuerza mayor y caso fortuito. 6. Prestación del servicio Militar 7. Por secuestro del beneficiario, debidamente certificado por la enditad competente, por el término
que dure la retención y un término de adaptación igual hasta un año, a solicitud del beneficiario.
Existen algunas causales de aplazamiento no cuentan para la configuración de la política del ICETEX
en cuanto a las condiciones de la renovación.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
27
2.3.5. CAUSALES DE BLOQUEO EN LA RENOVACION
1. Suspensión del estudiante por parte de la Institución de Educación Superior y/o Escuela Normal Superior.
2. Repetición de un período académico ya financiado. 3. Cambio de centro docente o de programa de estudios que implique nivelación hasta por dos
períodos académicos. 4. No estar al día en el cumplimiento de las obligaciones con el ICETEX. 5. Información inconsistente del núcleo familiar 6. Información inconsistente de la información académica. 7. Información inconsistente de la información de referencias personales. 8. Información inconsistente del Deudor Solidario 9. Información inconsistente de la Garantía 10. No actualización de la identificación del Beneficiario: (Tarjeta de identidad vencida). 11. Supero número de aplazamientos permitidos en el sistema. 12. Inconsistencia en el estrato reportado. 13. Convenio suspendido.
2.3.6. CAUSALES PARA EL PASO DEL CREDITO A ETAPA FINAL DE AMORTIZACION
1. Finalización del programa de estudios para el cual se concedió el crédito educativo. (No necesariamente se cumple el número de giros pactados)
2. Realización del último giro, según el número de períodos a financiar establecidos al momento del otorgamiento del crédito.
3. Expresa voluntad del beneficiario, cuando desea continuar sus estudios, pero no requiere más desembolsos.
4. Reincidencia en la suspensión por parte de la Institución Educativa Superior o Escuela Normal Superior.
5. Abandono injustificado del programa de estudios. 6. Adulteración de documentos o presentación de información falsa en cualquier momento de la vida
del crédito. 7. Comprobación por parte del ICETEX, a través de las Instituciones de Educación Superior – IES o
cualquier medio, sobre falsedad en la información suministrada, especialmente en lo referente al estrato socioeconómico y al registro en el SISBEN.
8. Utilización del crédito para fines distintos de aquellos para los cuales fue concedido. 9. Cambio de centro docente o de programa de estudios sin previa autorización por parte del ICETEX.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
28
10. No informar al ICETEX de ingresos adicionales por becas, comisión de estudios u otra clase de apoyo económico para financiar los estudios que reciba el beneficiario durante el tiempo en que disfrute del crédito educativo.
11. No presentar durante más de dos períodos académicos información sobre desempeño académico, la no actualización de la información personal y la del(los) deudor(es) solidario(s).
12. No tramitar la renovación del servicio según lo establecido en el presente Reglamento por más de dos períodos académicos.
13. Incurrir por tercera vez en la suspensión temporal de desembolsos. 14. La reincidencia en la repetición de un período académico. 15. Muerte o invalidez del beneficiario. 16. Suspensión definitiva de los estudios. 17. Incumplimiento por parte del estudiante de cualquiera de las obligaciones contractuales y
reglamentarias expedidas por el ICETEX.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
29
2.4. DIAGRAMA GENERAL DE ESTADOS.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
31
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
32
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
33
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
34
ICETEX
El diagrama general presenta todos los estados de los objetos que participan en el sistema de crédito y
cartera:
En el diagrama se describe la secuencia de estados empezando por la solicitud de adjudicación y cuando
esta inicia a formar parte de una resolución de giro que a su vez genera la creación de un giro cuando la
resolución es aprobada. Si el giro es exitoso este genera la creación de la operación de cartera en un
estado inicial de CEE al día y la creación de operación de crédito con un estado inicial de activo sin
bloqueo.
Una vez la operación de crédito se ha creado en el sistema se presentan las renovaciones que
dependiendo de su realización modifican el estado de la operación de crédito que puede ser bloqueada,
aplazada o continua activo sin bloqueo o queda activo sin desembolsos pendientes si corresponde a la
última renovación.
Cuando el crédito se ha creado también se controla el saldo y el comportamiento de pago con los estados
del objeto de operación de cartera.
Los objetos operación crédito y operación cartera también cambian de estados por la ejecución de
novedades que hacen que se cambie uno de esos estados.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
36
A continuación se describe las transiciones de estados por la ejecución de los casos de uso:
2.4.1. TRANSICIÓN DE ESTADOS DE LA SOLICITUD.
Transición de Estados Casos de Uso
Radicada Parcial OTO-SIS- 001 Registrar Solicitud de crédito de un Solicitante
De Radicada Parcial
a
Radicada
OTO-SIS- 008 Modificar la solicitud cuando falta información en
la etapa de diligenciamiento de la solicitud de crédito
De Radicada Parcial
a
Anulada
NOV-SYS-005 Anular créditos aprobados que no fueron legalizados
NOV-SIS-006- Anular créditos
De Radicada a Desistida
De Radicada
A
En Estudio
OTO-SIS- 013 Validar la información del formulario de solicitud
En Estudio
A
No Aprobada
OTO-SIS- 014 Generar las evaluaciones de las solicitudes
OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el
comité
En estudio a desistida
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
37
En Estudio
A
Elegible
OTO-SIS- 014 Generar las evaluaciones de las solicitudes
OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el
comité
En Estudio
A
Anulada
OTO-SIS- 014 Generar las evaluaciones de las solicitudes
OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el
comité
En Estudio
A
Aprobada
OTO-SIS- 014 Generar las evaluaciones de las solicitudes
OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el
comité
Elegible a Aprobada OTO-SIS- 014 Generar las evaluaciones de las solicitudes
OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el
comité
Elegible a No Aprobada OTO-SIS- 014 Generar las evaluaciones de las solicitudes
OTO-SYS- 016 Actualizar el estado de las solicitudes de crédito en el
comité
Elegible a Desistida
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
38
Aprobada a Legalizada OTO-SYS- 010 Autorizar créditos aprobados en el comité para
legalización
OTO-SYS- 017 Verificar la información de las solicitudes aprobadas
OTO-SIS-020 Revisar la garantía del crédito: carta de instrucciones y
pagare y confirmación de valores
OTO-SIS-019 Legalizar créditos aprobados
Legalizada a Aprobada NOV-SIS-009 Reversar la legalización
Legalizada a Visada OTO-SIS-021 Hacer visado del crédito por parte del ICETEX
Visada a Generada en
resolución
GIR-SIS-002 Generar Resolución relación de Giro
GIR-SIS-005 Generar Resoluciones de Giro Complementario
Generada a aprobada en
resolución
GIR-SIS-003 Aprobar resolución relación de giro
Aprobada en Resolución a
Girada
GIR-SIS-006 Cargar número de referencia del giro
Aprobada en Resolución a
No Girada
GIR-SIS-006 Cargar número de referencia del giro
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
39
2.4.2. TRANSICIÓN DE ESTADOS DE LA RESOLUCIÓN.
Transición de Estados Casos de Uso
A Generada GIR-SIS-002 Generar Resolución relación de Giro
GIR-SIS-005 Generar Resoluciones de Giro Complementario
Generara a Aprobada GIR-SIS-003 Aprobar resolución relación de giro
Generada a Anulada GIR-SIS-003 Aprobar resolución relación de giro
Aprobada a Enviada GIR-SIS-004 Cargar información de la resolución
Enviada a notificada GIR-SIS-006 Cargar número de referencia del giro
2.4.3. TRANSICIÓN DE ESTADOS DEL GIRO DEL BENEFICIARIO
Transición de Estados Casos de Uso
A En proceso GIR-SIS-003 Aprobar resolución relación de giro
Proceso a en firme GIR
-SIS-007 Confirmar giros exitosos
Proceso a Rechazado GIR-SIS-007 Confirmar giros exitosos
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
40
2.4.4. TRANSICIÓN DE ESTADOS DE LA OPERACIÓN DE CRÉDITO
Transición de Estados Casos de Uso
A activo sin bloqueo GIR-SIS-007 Confirmar giros exitosos
Activo sin bloqueo a activo
con bloqueo
NOV-SIS-011 Bloquear créditos
Activo sin bloqueo a
aplazado
CDI-SIS-001 Ejecutar Cierre Diario:
CDI-SIS-002 Actualizar estados de los créditos
Activo sin bloqueo a sin
desembolsos pendientes.
CDI-SIS-001 Ejecutar Cierre Diario:
CDI-SIS-002 Actualizar estados de los créditos
Activo con bloqueo
Aplazado a sin
desembolsos pendientes.
CDI-SIS-001 Ejecutar Cierre Diario:
CDI-SIS-002 Actualizar estados de los créditos
Activo con bloqueo a sin
reembolsos pendientes.
CDI-SIS-001 Ejecutar Cierre Diario:
CDI-SIS-002 Actualizar estados de los créditos
Sin desembolsos
pendientes a finalizado.
NOV-SIS-012 Terminación del crédito
A finalizado NCA-SIS-005 Aplicar Condonación Total
NCA-SIS-013 Eliminar saldos mayores a favor del Beneficiario
NCA-SIS-013 Eliminar Saldos menores
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
41
2.4.5. TRANSICIÓN DE ESTADOS DE LA RENOVACIÓN
Transición de Estados Casos de Uso
A Bloqueada REN-SIS-001 Realizar la actualización de datos e impresión del
soporte de la renovación
REN-SIS-002 Realizar la renovación (gestor del crédito)
A Aplazada REN-SIS-001 Realizar la actualización de datos e impresión del
soporte de la renovación
REN-SIS-002 Realizar la renovación (gestor del crédito)
A Desistida REN-SIS-001 Realizar la actualización de datos e impresión del
soporte de la renovación
REN-SIS-002 Realizar la renovación (gestor del crédito)
A Aprobada REN-SIS-001 Realizar la actualización de datos e impresión del
soporte de la renovación
REN-SIS-002 Realizar la renovación (gestor del crédito)
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
42
2.4.6. TRANSICIÓN DE OPERACIÓN CARTERA
CEE crédito época de estudios
CPG crédito periodo de gracia
CEA crédito etapa final de amortización
Transición de Estados Casos de Uso
CEE al día GIR-SIS-007 Confirmar giros exitosos
A CEA al día
De
CEE Al día o
CPG Al día o
CEE atrasado en cuota o
CPG atrasado en cuota.
CEA -SIS-001 Pasar Crédito a etapa final de amortización
CEE Al día a CEE atrasado
en cuota.
CPG Al día a
CPG atrasado en cuota
CEE-SIS-001-Aplicar Giros de Adjudicación y Renovación.
CEE atrasado en cuota. CEE-SIS-004 Aplicar Recaudos Época de Estúdio
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
43
A CEE Al día
CEE atrasado en cuota
CEE Al día
CEE atrasado en cuota.
A CEE Al día
CEE atrasado en cuota
CEE Al día
NCA-SIS-007 Reversar Giro
CEE en mora a CEE al día. CEA-SIS-004 Aplicar Recaudos etapa final de amortización.
Ver las transacciones que
se muestran en el
diagrama de estados y
casos de uso.
CDI-SIS-001 Ejecutar Cierre Diario:
CDI-SIS-002 Actualizar estados de los créditos
Ver caso de uso de cierre
de periodo académico.
CPA-SIS-001 Ejecutar Cierre Periodo Académico
A CEA al día
De
CEE Al día o
CPG Al día o
CEE atrasado en cuota o
CPG atrasado en cuota.
NCA-SIS-001 Pasar Crédito a etapa final de amortización.
A CEE al día NCA-SIS-001 Pasar Crédito a época de estudio.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
44
O
A CEE atrasado en cuota.
De:
CEA al día o
CEA en mora.
CEE al día
A CEE atrasado en cuota.
CPG al día
A CPG atrasado en cuota.
CEA al día
A CEA en mora.
NCA-SIS-002 Reversar Pago
CEE atrasado en cuota.
A CEE al día
CPG atrasado en cuota
A CPG al día.
CEA en mora
a CEA al día
NCA-SIS-004 Aplicar Pago
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
45
A finalizado NCA-SIS-005 Aplicar Condonación Total
CEA en mora
a CEA al día
NCA-SIS-006 Aplicar Condonación Parcial
CEE al día
A CEE atrasado en cuota.
NCA-SIS-009 Aplicar Giro
CEE mora
A CEE al día.
NCA-SIS-010 Refinanciar Crédito.
A finalizado NCA-SIS-013 Eliminar saldos mayores a favor del Beneficiario
A finalizado NCA-SIS-013 Eliminar Saldos menores
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
46
2.5. SUBESTADOS DE CARTERA
Transición de Estados Casos de Uso
A Reestructurada. Se cambia de estado por las novedades que cambien las condiciones
del crédito y estas estén parametrizadas como novedades de
reestructuración.
A Cobro preventivo
A Cobro correctivo
A Cobro Jurídico
A Cobro Prejurídico
Se cambian de estados por la temporalidad días de mora o se puede
cambiar de estado de manera manual.
A Castigada Se cambia a este estado por la decisión de la entidad. Este se realiza
de manera manual.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
47
2.6. DIAGRAMA DE ESTADOS PARA FONDOS CERRADOS (P.E. COOPERATIVAS)
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
48
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
50
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
51
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
52
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
53
ICETEX
La diferencia con el diagrama general de estados radica en que los fondos cerrados se caracterizan por
no tener las fases de radicación, evaluación y legalización. Debido a que estos envían el listado de
beneficiarios al ICETEX para que les sea realizado el desembolso.
2.7. TRANSICIÓN DE ESTADOS DE LA SOLICITUD
Transición de Estados Casos de Uso
A Legalizada OTO-SIS- 002 Cargar beneficiarios de fondos en el sistema de
crédito y cartera
* Los demás estados se manejan como el diagrama general.
2.8. RESUMEN DE REQUERIMIENTOS TECNICOS
RT: EL sistema debe modelar por lo menos los estados incluidos.
RT: El sistema debe poder modelar nuevos estados o suprimir estados, y cambiar las condiciones de
transición entre estados, sin necesidad de modificar el ejecutable.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
55
3. ARQUITECTURA LOGICA
En esta sección presentamos los principios de la arquitectura lógica del SCC. Recordemos que la
arquitectura lógica es la estructura de la solución en software, alineada con la arquitectura de negocio, y
sin hacer referencia explícita a la plataforma. Presentamos los temas fundamentales para definir las
decisiones de arquitectura y los requerimientos técnicos: SOA y Niveles/Capas; Características del BPM;
Formularios; Navegación, Consultas y Reportes; Servicios; Cache; Persistencia; Seguridad y Auditoría;
Patrones Generales; y Mejores Prácticas Generales de Diseño.
La arquitectura del SCC debe ser SOA (Service Oriented Architecture), es decir sus principales
componentes son un conjunto de servicios autónomos, y debe estar separada en varias capas que se
detallarán más adelante. El corazón del sistema está basado en un BPM (Business Process Modeling)
que representa una de las capas del sistema de software. El BPM invoca entre otros, servicios orientados
al negocio de crédito y cartera. En el diagrama se ilustran algunos de los servicios. La capa de
presentación incluye además un manejador de formularios, el cual permite crear dinámicamente campos y
formularios que se asocian a los productos de crédito. Como facilidades transversales en el sistema se
tiene un motor de reglas de negocio que permite dinámicamente especificar y ejecutar lógica de
formulación y condiciones que se usan en el sistema. Igualmente existen las facilidades de seguridad y
auditoría que involucran las capas (seguridad a nivel de interfase, a nivel de procesos, a nivel de servicios
y a nivel de datos). Cache es un servicio que acelera el acceso a datos muy usados. Este es un Cache
aplicativo, es decir, se explota el conocimiento que se tiene en la aplicación sobre el uso de los datos. La
capa de acceso a datos finalmente aisla el acceso a los datos. Se describen varias bases de datos
(repositorios) en el sistema.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
56
A continuación se explican en esta sección cada una de las capas, enfocándolas hacia los requerimientos
técnicos para su construcción.
Arquitectura Lógica
MO
TO
R D
E R
EG
LA
S D
E N
EG
OC
IO
SE
GU
RID
AD
/AU
DIT
OR
IA
OP
TIM
IZA
DO
RE
S (C
AC
HE
)
Servicio de Cálculos
Servicio de Cierres
Servicio de Consultas
Servicio de Impresión
ServicioAsynch
Servicio de Integración
ServiciosUtilitarosNegocio
ServiciosUtilitarosSistema
BD Operativa
(Tx), Parámetros
(XML)
BD Saldos
(Históricos)
BD BI
BD Internet
AJAX
Capa
Presentación
Capa
Servicios
Capa
Datos
IU
BPM
MANEJADOR FORMULARIOS
Capa
Procesos
PORTAL
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
57
3.1. SOA Y NIVELES/CAPAS
SOA en el contexto de este sistema quiere decir que el sistema debe construirse usando componentes
autónomos altamente desacoplados. Se deben usar dos técnicas para lograr el desacople: patrones y
mensajes. Con patrones (“programar a interfaces y no a implementaciones”) se aíslan los cambios y se
distinguen los APIs internos de los que se exponen. Con mensajes se desacopla aún más a un mayor
costo. Se espera que haya servicios implementados de varias formas para mantener el rendimiento y para
lograr un alto desacople.
Un punto fundamental que se espera con los servicios es el diseño apropiado de los APIs (según las
buenas prácticas de la industria): fáciles de aprender, difícil de usar mal, granularidad y potencia adecuada,
fáciles de extender, manejo consistente de excepciones, etc.
En el SCC se requiere una orientación clara a servicios que se puedan reutilizar desde muchos lados, que
permitan en muchos casos invocaciones asincrónicas, que algunos permitan registrarse y descubrirse
sobre la marcha, y que tengan un ambiente de pruebas independiente.
Además de los Servicios se requiere organizar el sistema en capas (o niveles) bien definidas y aisladas.
Por un lado se tienen los tres niveles tradicionales de Presentación (visualización de la información,
navegación por la interfase, y cierta lógica relacionada con presentación en el cliente mayor hoy en día con
el uso de AJAX), Negocio o Servicios (lógica del negocio), y Datos (acceso a datos persistentes). En el
SCC se ha identificado un nivel fundamental que es el del BPM, o manejo de procesos, el cual orquesta
servicios que están en una capa inferior. EL BPM tiene su propia interfase (para modelo gráfico de
procesos) y usa la capa de datos cuando persiste información. Existen facilidades y/o servicios
transversales que aplican en todas las capas.
Debe ser posible probar todos los servicios sin usar una interfase de usuario. Debe ser posible probar la
lógica de los servicios simulando una base de datos (cambiando toda la capa de persistencia). Estas (y
otras) deben ser pruebas que se pueden hacer para demostrar el asilamiento de las capas.
3.1.1. REQUERIMIENTOS TECNICOS
• RT: Sistema debe definir explícitamente servicios internos y externos
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
58
– Servicios internos no se usan desde sistemas externos y permiten optimizaciones propias de
la plataforma. Son autónomos, no necesariamente basados en mensajes. Deben aislar las
implementaciones de las interfases.
– Servicios externos son basados en mensajes y optimizados para disminuir el tráfico y manejar
errores y excepciones de acuerdo a su naturaleza.
• RT: Las capas deben estar explícitamente separadas. La separación se puede probar mediante
pruebas específicas para esto.
• RT: La capa de datos aisla el motor de base de datos o los repositorios (se puede cambiar el motor
sin tener que cambiar nada en otra capa, rediseños lógicos y físicos en la base de datos que no
añadan datos o cambien sus tipos, o inclusive cambio en el manejo de distribución de datos entre
servidores, no deben alterar el código en las otras capas).
• RT: La capa de presentación puede cambiar de librería de visualización y captura de datos sin tener
que cambiar nada en la capa de negocios o datos. Estas capas no saben si las invoca un usuario o un
software.
• RT: La capa de negocio no debe tener código que dependa de la presentación de la información o
de la forma de hacer persistencia.
• RT: La capa de procesos orquesta lógica que está en la capa de servicios. Su inteligencia consiste en
manejar los estados y transiciones de los procesos e invocar servicios de negocio, de notificaciones,
de seguridad, todos en el marco de los procesos.
3.2. BPM
La funcionalidad BPM del SCC debe permitir:
• la creación de procesos (líneas de crédito) con sus estados y condiciones
• la definición de condiciones de las transiciones con el objeto de poder parametrizar el cambio de
estados. Esto requiere que el sistema permita hacer referencia a todas las variables que
intervienen en las condiciones y a expresar las condiciones como tal de tal forma que no haya que
cambiar el ejecutable cuando hayan ciertos cambios de políticas en los productos de crédito, sino
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
59
simplemente el sistema permita que los administradores de los productos realicen en forma fácil y
ágil tales cambios. Esta facilidad puede estar brindada directamente por un paquete, o construida
con extensiones a un paquete o construida totalmente (incluyendo el sistema).
• la creación de nuevos estados en forma paramétrica. Además de las condiciones (transiciones)
anteriores, es necesario que el sistema permita en el futuro crear estados, suprimir estados,
agregar estados, desagregar estados, de tal forma que los nuevos productos de crédito se puedan
definir en forma paramétrica en el sistema.
• visualizar a través de una interfase de usuario condiciones de los procesos como tareas
pendientes por usuarios, notificaciones, etc.
• la integración con el sistema de Seguridad (control de acceso) de tal forma que se puedan definir
controles de acceso por diferentes características de los estados (v.g., sólo usuarios del Grupo G
tienen acceso al crédito cuando se encuentre en estado E).
• el monitoreo de tiempos en Estados, de tiempos de los usuarios realizando acciones, y en general
los útiles para efectivamente tener información que permita mejorar y controlar la gestión de los
procesos.
• el uso de estándares del mercado en la definición y ejecución de los procesos: BPEL, BPMN, etc.
Los tipos de condiciones están definidas en los Casos de Uso de Sistemas que cambian a un producto de
un estado a otro. A continuación citamos varios ejemplos por categorías:
• Del Formulario
– Campos obligatorios y opcionales del formulario.
– Rangos permitidos para los campos que integran los formularios como son los campos de
fechas y valores.
• De Tiempo
– Tiempo que una solicitud puede permanecer en estado radicada parcial.
– Tiempo establecido para realizar la renovación. Fecha desde y fecha hasta.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
60
– Tiempos de dias de mora o número de cuotas vencidas para establecer el cambio de los
subestados cobro preventivo, cobro correctivo, cobro prejurídico, cobro jurídico.
• Del valor de un Cálculo
– Del % de provisión de acuerdo a la calificación del crédito según modelo de temporalidad.
• De Topología (ciertas condiciones cambian el diagrama del proceso)
– Definición o no de periodo de gracia para la modalidad de crédito.
– Definición de los estados de solicitud de adjudicación que aplica para fondos cerrados.
– Definición de crédito condonable.
• Conjunción de varias condiciones EXTERNAS o datos calculados
• Condición EXTERNA hace que se pase directamente a un estado (excepciones)
La creación de un producto de crédito incluye la línea, la modalidad y el tipo de alianza. Es en la creación
donde se pueden entender más directamente cuáles son los parámetros y variables que definen un
producto de crédito. Es importante entender que los parámetros en este sistema pueden ser muy variados
y no simplemente tablas o variables. Veamos varios tipos de parámetros que están definidos en los casos
de uso:
• Tablas básicas
– Valores simples de variables, tablas de códigos, tablas que crecen continuamente (tasa
de cambio), calendarios, conjunto de tablas con valores actualizados periódicamente
(SNIES), etc.
• Condiciones de Crédito
– Modelo de Evaluación (variables y lógica de cálculo)
• Condiciones de Cartera
– Algoritmos de liquidación
– Modelos de Calificación y Provisión
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
61
• Interfases
– Dinámica de cuentas, reportes Super Intendencia Financiera
Nótese que la forma de almacenar este repositorio de parámetros puede ser muy diferente a la forma de
almacenar información transaccional por varias razones:
1. Este conjunto de parámetros no es muy voluminoso.
2. Se usa en generar para leerlo, y se actualiza poco, y cuando se actualiza el tiempo de
actualización no es crítico
3. Se usa en el sistema como insumo permanente y debe amoldarse a una computación orientada
por objetos.
3.2.1. REQUERIMIENTOS TECNICOS
• RT: EL BPM no tiene que ser necesariamente un paquete del mercado. Podría ser un software
construido por el proveedor de la solución, siempre y cuando cumpla con los requisitos funcionales
definidos en esta arquitectura.
• RT: Debe permitir definir los estados y transiciones modelados en la Arquitectura Conceptual, sin
necesidad de cambiar el ejecutable
• RT: Las condiciones modeladas por las transiciones deben poderse definir en el BPM sin
necesidad de cambiar el ejecutable
• RT: Debe tener un IU fácil de usar para un usuario experto en crédito y cartera
• RT: Debe permitir monitoreo del proceso
• RT: Debe estar integrado al sistema de seguridad
Parámetros
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
62
• RT: Debe modelar como mínimo los parámetros de la Arquitectura conceptual
• RT: Deben almacenarse en formatos que permitan optimizar la transición a un modelo de objetos
(v.g., XML, XML Serializado, etc.)
3.3. INTERFASE DE USUARIO (IU) Y FORMULARIOS
El SCC expone su funcionalidad a través de un PORTAL. El ICETEX actualmente tiene su propio sitio Web
El SCC debe proveer una interfase de usuario (IU) consistente, mínima, y con alto grado de “usabilidad”.
Por consistente queremos decir que siempre las mismas funciones se deben realizar de la misma manera
desde el punto de vista de interfase (del “look and feel”). Por consistente también queremos decir que se
deben usar los estándares de la industria (estándares de Windows).
El SCC debe proveer a nivel de IU una facilidad para definir formularios dinámicamente. Los formularios
en el sistema están compuestos por campos y secciones (una sección es un conjunto de campos). Estos
formularios son los usados en la solicitud de créditos y tienen información básica general que es fija pero
igualmente tienen información (campos) que puede ser dinámica y dependiente de los productos de
crédito. Los campos existen independientemente de los formularios con el objeto de poder reutilizarlos (el
mismo campo usado en varios formularios). Igual sucede con las secciones (la misma sección en varios
formularios). Así, el manejador de formularios debe poder:
• Definir formularios por secciones, que agrupan campos. Los campos y secciones se deben poder
reutilizar.
• Definir secciones obligatorias.
• Definir nuevos campos dinámicamente
– Con propiedades de tales como: Tipo de datos, Obligatoriedad, formato, etc.
– Con validaciones en los campos
• Que usen lógica en AJAX para lograr agilidad en el procesamiento de un
formulario
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
63
• Relacionar campos dinámicos con las reglas de las condiciones de los créditos
3.3.1. REQUERIMIENTOS TECNICOS
• RT: Debe existir un servicio de formularios que permite crear campos, asociarlos a formularios,
ejecutar un formulario (visualizarlo, navegar por sus partes, hacer validaciones), retornar
contenidos.
• RT: Los Formularios y sus campos se debe poder asociar a los productos de crédito
• RT: La Interfase de Usuario (IU) debe ofrecer funcionalidades similares a la de los paquetes de
PORTALes
– Integración con sistema de seguridad avanzados (SSO o Single Sign On)
– Integración con herramientas de colaboración (Chats)
– Integración con IU del BPM (poder ver tareas pendientes en una ventana)
– Manejo de Sesiones (poder tener varias sesiones de la aplicación en diferentes ventanas
del portal y que estén sincronizadas
• RT: La navegación debe ser mínima y consistente, es decir, las tareas más frecuentes deben
tratar de utilizar el mínimo número de “clicks” de navegación (ojalá ninguno), y siempre se debe
ofrecer la misma apariencia en la interfase para tareas similares
• RT: Las consultas deben tener filtros genéricos y suficientemente poderosos para acomodar
cualquier tipo de consulta. No deben existir múltiple interfases para consultas similares
• RT: Si los resultados de una consulta son muy grandes (cientos o miles) la interfase debe manejar
esos casos (pidiendo más filtros, alertando, etc.)
• RT: La misma consulta tiene que tener siempre la misma IU. La misma consulta generada desde
diferentes sitios en el sistema deben implementarse con el mismo código
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
64
• RT: Consultas que no requieren la respuesta inmediata deben implementarse asincrónicamente
(es decir, sin bloquear al usuario mientras aparecen las respuestas).
• RT: Se requiere de una herramienta de generación de reportes.
3.4. SERVICIOS
La lógica de negocio del SCC debe implementarse como un conjunto de servicios, que puedan reutilizarse
desde diferentes “clientes”: IU, otros servicios locales, y desde servicios externos (no necesariamente
todos los servicios se podrán invocar desde servicios externos). La “granularidad” (qué tanta lógica se
incluye) de los servicios debe justificarse en el diseño detallado de los mismos. Los servicios se usan a
través de APIs (Application Program Interfaces) que debe ser cuidadosamente definidas e implementadas.
En esta sección se mencionan varios tipos de servicios, sin que esto implique que su granularidad es la de
los ejemplos, ni que éstos son todos los servicios.
3.4.1. SERVICIOS DE CALCULOS
Son aquellos que encapsulan evaluaciones de fórmulas o algoritmos sencillos que hacen esencialmente
cálculos. Se usan para tareas como evaluación de crédito, liquidaciones, cálculo de provisiones, etc. Por
ejemplo (ver detalles en los Casos de Uso relacionados a estos ejemplos):
– Evaluación (scoring)
• Precálculos capacidad de pago, subsidio,etc….
– CONDICIONES Y DATOS DEL FORMULARIO
If TOPE DE MODALIDAD < MAX CAP PAGO then
CAPAC PAGO = TOPE MODALIDAD
else
CAPA PAGO = VALOR APROB
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
65
– Liquidaciones (cálculo de cuota –fija, variable, amortización fija-, plan de pagos basado en
cuota), en el futuro podrían ser otros.
– Provisiones (depende de calificación de cartera) en forma de tablas del estilo:
• Si A aprovisione 0%., Si B aprovisione 20%......Si D aprovisione 100%, una tabla
para cada línea
– Calificación de cartera
• RT: Las condiciones de evaluación de los créditos deben poderse definir y cambiar SIN necesidad
de cambiar el ejecutable. Ejemplos de cambios son:
– Cambio del porcentaje de la fuente de financiación del crédito.
– Cambio del porcentaje que debe provisionarse por modelo de provisión definido.
– Cambio del porcentaje de amortización de capital en etapa de estudio.
• RT: El manejo de moneda debe ser parametrizado.
– Definición de las monedas en que se pueden generar los desembolsos por modalidad de
crédito creada (el sistema gestiona el crédito en pesos).
RT: La anterior funcionalidad normalmente se ofrece mediante un motor de Reglas de Negocio que
• Debe incluir un lenguaje que permite definir la lógica de las condiciones de evaluación
– Lenguaje debe tener capacidad de expresar cálculos (asignaciones, condicionales) que
definen el método de evaluación, acceso a “variables” (parámetros), funciones built-in
(fechas, etc.)
• Debe tener una IU que permita definir en forma fácil el método de evaluación del crédito
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
66
3.4.2. SERVICIOS DE INTEGRACION
Los Servicios de Integración se refieren a la estructura que permiten conectar componentes (o servicios)
con otros componentes (o servicios) internos o externos. Internos son aquellos dentro de los sistemas del
ICETEX, sea del SCC o de otras aplicaciones, mientras que los externos son aquellos que están en otros
sistemas externos al ICETEX (ver detalles en los Casos de Uso de Integración). El objetivo es encontrar
una forma de conexión que desacople al máximo los servicios de tal forma que cambios en un lado afecten
lo mínimo otros lados.
FILE TRANSFER
Damos varios ejemplos:
• Externo: SNIES
• Internos: Contabilidad, Presupuesto
3.4.3. SERVICIOS UTILITARIOS DE NEGOCIO
Estos son los servicios del Negocio que ayudan a realizar labores periféricas pero importantes. Damos tres
ejemplos:
• Depuración de Datos. Son funciones que permiten actualizar datos en formas diferentes a las
transacciones operativas normales del sistema, pero ayudan a depurar los datos. Sólo las pueden
realizar ciertos usuarios con altos privilegios (tal vez con autenticación y rastros usando
certificados digitales).
• Servicio de Explicaciones (“Explain”). Son funciones que permiten explicar cómo se realizaron los
cálculos en el sistema.
• Servicio de Históricos. Son funciones que permiten encontrar un valor histórico.
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
67
3.4.4. SERVICIOS UTILITARIOS DE SISTEMAS
Son servicios genéricos (no del negocio) de funciones que requiere el software. Damos varios ejemplos:
• Servicios de Notificaciones. Incluye servicios para enviar mensajes a usuarios y servicios para
notificar la ocurrencia de eventos a otros servicios (patrón suscriptor-publicador)
• Servicio de Tablas Infinitas. Incluye las tablas del sistema que crecen permanentemente como la
de tasa de cambio.
• Servicio de Ejecución en Background (“Daemons”). Permite agendar la ejecución de programas en
ciertos momentos.
• Servicio de Números. Permite generar números únicos con diferentes propiedades.
• Servicios de Procesamiento Asincrónico. Permite manejar pools de threads para ejecutar tareas
asincrónicamente.
3.5. OPTIMIZACION
3.5.1. CACHE APLICATIVOS
• Área dedicada en RAM que acelerar acceso a datos y/o objetos. Se le califica como aplicativo,
porque a diferencia de los cache automáticos provistos por el sistema (cache de objetos de Java,
cache de la base de datos, cache del sistema operacional), la organización y algoritmos usados
deben explotar el conocimiento de cómo se usan los datos en la aplicación.
• Debe tratar de incluir todos los parámetros del SCC y más elementos
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
68
• Parámetros
• Volátil por Beneficiario
• Tablas Infinitas
• Procesos Batch
• Tamaño: Tan grande como se pueda
• Internamente debe usar varios esquemas de caching: sólo lectura, lectura y escritura, para
procesos especiales, etc.
• Manejo de varios servidores
3.5.2. REQUERIMIENTOS TECNICOS
• RT: Cache aplicativos (a diferencia de…)
• RT: Puede haber varios. Mínimo el de parámetros.
• RT: Deben optimizarse para el real uso en el aplicativo y mantenerse en lo posible todos en
memoria principal la mayoría del tiempo
3.6. BASES DE DATOS Y PERSISTENCIA
• Opcionalmente en uno o varios servidores (por definir)
– BD Transaccional u Operativa: Vigentes
– BD Saldos Históricos
– BD Consolidado de Cartera (DWH)
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
69
• Histórico de todos los saldos acumulados (interés, capital, seguros) a la fecha
– BD Internet
• Extracto último mes, plan de pagos vigente, información de beneficiario y
deudores
3.7. SEGURIDAD Y AUDITORÍA
• Debe seguir los lineamientos y estándares de Seguridad y Auditoría del ICETEX y las
definidas en COBIT.
• Autenticación
– Passwords usando llaves privadas (o sea los passwords tradicionales) con los estándares
ICETEX. No debe guardarse los passwords en repositorios, sino un “hash” de los
passwords.
– CD (Certificados Digitales) en ciertas transacciones definidas paramétricamente
• Autorización (control de acceso)
– Se debe poder definir grupos de usuarios con permisos de acceso a nivel de grupo
– 3 niveles de control de acceso deben existir
• IU: menús y ciertos campos visuales deben tener control de acceso por grupos de
usuarios
• Servicios deben tener su propio control de acceso dado que no siempre se van a
usar via una IU
• Bases de Datos deben tener su propio control de Acceso
– Control de Acceso por Contenido (valores), por sitio, por horas/fechas
– Control de Acceso asociado al BPM
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
70
3.8. PATRONES GENERALES
Para todo el código que se deba escribir (nuevo o adaptaciones) es necesario que se sigan principios de
diseño que reflejen las mejores prácticas de la industria. En especial nos referimos en esta sección al uso
de patrones de diseño que garantizan la flexibilidad del código escrito en ambientes orientados por objetos.
Para todo código que se diseñe se requiere que se justifique el uso (o no uso) de tres tipos de patrones
muy específicos:
• Genéricos (los 23 llamados GoF o “Gang o Four”)
• J2EE Patrones clásicos en una arquitectura basada en J2EE.
– Ajustar a JEE5
• Patrones AJAX
4. ARQUITECTURA FISICA
Es la estructura del software desde el punto de vista de uso de productos de hardware y software
específicos. A la fecha de escritura de este documento la dirección del ICETEX había definido el uso de
J2EE como el estándar de infraestructura de software y los Servidores Sun como la plataforma de
servidores y sistemas operacionales (Solaris) del SCC. Sin embargo, los temas de esta sección se
revisarán en la nueva dirección de Informática .
4.1. PLATAFORMAS
• Herramienta Base de Datos: Oracle 10g
SOFTWARE DE GESTIÓN DE CRÉDITO Y CARTERA Y ADMINISTRACIÓN DE FONDOS Versión: <1.0>
22-12 DOCUMENTO DE ARQUITECTURA Fecha: <06/Agosto /2007>
Confidencial ICETEX, 2007 Pág.
71
– No implica Herramientas de desarrollo Oracle, ni BPM de Oracle, ni PORTAL de Oracle,
etc.
• Plataforma: Solaris
• Herramientas no están predefinidas para
– Ambiente de desarrollo
– BPM, PORTAL
• Servidores. El ICETEX cuenta con dos Sun Fire V490 completamente nuevas, dos Sun
Blade1000 (que están en reparación) y dos Sun T2000.