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. >




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




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




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.”




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




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.




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.




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.




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.




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.




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.




13

2.2. OBJETOS DEL SISTEMA

Solicitud

AdjudicaciónResolución

Giro por

Beneficiario

Crédito

Obligación

Cartera

Renovación

Transacción




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




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.




16


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.




17


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.




18


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.




19


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.




20


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.




21


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.




22


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.




23


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.




24


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




25


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.




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.




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.




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.




29

2.4. DIAGRAMA GENERAL DE ESTADOS.

ICETEX




31




32




33




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.




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




37

En Estudio

A

Elegible



comité

En Estudio

A

Anulada



comité

En Estudio

A

Aprobada



comité

Elegible a Aprobada OTO-SIS- 014 Generar las evaluaciones de las solicitudes


comité

Elegible a No Aprobada OTO-SIS- 014 Generar las evaluaciones de las solicitudes


comité

Elegible a Desistida




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




39

2.4.2. TRANSICIÓN DE ESTADOS DE LA RESOLUCIÓN.


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


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




40

2.4.4. TRANSICIÓN DE ESTADOS DE LA OPERACIÓN DE CRÉDITO


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




Activo con bloqueo

Aplazado a sin




Activo con bloqueo a sin

reembolsos pendientes.



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




41

2.4.5. TRANSICIÓN DE ESTADOS DE LA RENOVACIÓN


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



A Desistida REN-SIS-001 Realizar la actualización de datos e impresión del



A Aprobada REN-SIS-001 Realizar la actualización de datos e impresión del






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


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




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.



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.




44

O

A CEE atrasado en cuota.

De:

CEA al día o

CEA en mora.

CEE al día


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




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


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




46

2.5. SUBESTADOS DE CARTERA


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.




47

2.6. DIAGRAMA DE ESTADOS PARA FONDOS CERRADOS (P.E. COOPERATIVAS)




48

ICETEX




50




51




52




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


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.




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.




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




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




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




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.




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




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.


• 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




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




63

• Relacionar campos dinámicos con las reglas de las condiciones de los créditos


• 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




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




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




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.




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




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


• 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)




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




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




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.

software de gestiÓn de crÉdito y cartera … · arquitectura de negocio, aunque técnicamente...

Documents