jarc arqsw documentoarquitecturasw v 5 0

Universidad de Los Andes

Proyecto de Mejoramiento del Proceso de Originación de Crédito del Banco de los Alpes

Documento de Arquitectura del Sistema(SAD)

Nombre del Equipo de Trabajo: .JARC

Nombre de los Integrantes:

Andrés Gonzalez e-mail:[email protected]

Julián Morales e-mail:[email protected]

Carlos Criales e-mail:[email protected]

José Daniel Garcia e-mail:[email protected]

Robinson De la hoz e-mail:[email protected]

Haiver Páez e-mail:[email protected]

Tabla de Contenido

Tabla de Contenido............................................................................................................................................................................................................................. 2Sección 1. Descripción del Documento..................................................................................................................................................................................... 4

1.1 Propósito y Audiencia.......................................................................................................................................................................................................... 41.2 Organización del Documento............................................................................................................................................................................................ 41.3 Convenciones............................................................................................................................................................................................................................ 41.4 Terminología y Definiciones.............................................................................................................................................................................................. 4

Sección 2. Generalidades del Proyecto...................................................................................................................................................................................... 62.1 Problema a Resolver............................................................................................................................................................................................................. 62.2 Descripción General del Sistema a Desarrollar......................................................................................................................................................... 62.3 Objetivos..................................................................................................................................................................................................................................... 62.4 Stakeholders............................................................................................................................................................................................................................. 7

Sección 3. Motivadores Arquitecturales................................................................................................................................................................................... 93.1 Motivadores de Negocio...................................................................................................................................................................................................... 93.2 Restricciones de Tecnología............................................................................................................................................................................................ 123.3 Atributos de Calidad........................................................................................................................................................................................................... 15

3.3.1 Árbol de Utilidad......................................................................................................................................................................................................... 153.3.2 Escenarios de Calidad............................................................................................................................................................................................... 19

Sección 5. Punto de Vista Funcional....................................................................................................................................................................................... 325.1 Diagrama Nivel 0.................................................................................................................................................................................................................. 325.2 Diagrama Nivel 1.................................................................................................................................................................................................................. 335.3 Diagrama Nivel 2 – Dinámico......................................................................................................................................................................................... 345.4 Diagrama Nivel 2 – Estático............................................................................................................................................................................................. 355.6 Diagrama Nivel 3 – Patrón Factory Method............................................................................................................................................................ 365.7 Diagrama Nivel 2 – Estático............................................................................................................................................................................................. 375.8 Diagrama Nivel 2 – Dinámico......................................................................................................................................................................................... 385.9 Diagrama Nivel 3 – Patrón Reactor.............................................................................................................................................................................. 395.9 Diagrama Nivel 3 – Patrón Reactor.............................................................................................................................................................................. 405.10 Diagrama Nivel 1............................................................................................................................................................................................................... 425.11 Diagrama Nivel 2............................................................................................................................................................................................................... 435.12 Diagrama Nivel 3............................................................................................................................................................................................................... 44

Sección 6. Punto de Vista de Información........................................................................................................................................................................... 456.1 Diagrama Estado Cliente................................................................................................................................................................................................... 456.2 Diagrama Estado Producto.............................................................................................................................................................................................. 466.3 Propiedades de los Datos................................................................................................................................................................................................. 47

Sección 1. Descripción del Documento

1.1 Propósito y AudienciaEste documento presenta la arquitectura que se utilizará para el proyecto de automatización del proceso de originación de crédito del Banco los Alpes, esto se alcanzará a través del análisis de diferentes vistas, la cual muestra un aspecto particular a tener en cuenta.

El presente documento está dirigido al equipo de trabajo que desarrollara la solución así como los usuarios funcionales del lado del Banco de Los Alpes, que puedan estar involucrados en el proyecto.

1.2 Organización del Documento

Este documento se organiza y ejecuta con base a la plantilla entregada por el curso Arquitecturas por Componentes, de la especialización Construcción de Software de ECOS, la cual se adaptó a las necesidades del proyecto de Automatización del proceso de originación de crédito en el Banco de los Alpes.

1.3 Convenciones

Todas las convenciones asociadas a este documento, serán descritas e ilustradas en los diagramas.

1.4 Terminología y Definiciones

Proveedor: Estas son las entidades externas al Banco de los Alpes, los cuales se clasifican en dos tipos: proveedoras de datos y de operación, los primeros son los encargados de entregar los datos necesarios para la selección de los clientes a los cuales se les podrá ofrecer los productos del Banco; los segundos son los encargados de realizar el producto y la entrega física a los clientes.

Clientes: Estas se clasifican en cuatro (4) tipos, los cuales son: prospecto, pre-aprobado, rechazados y reales; los prospectos, son las personas que cumplen con los criterios exigidos por el Banco los Alpes para ser cliente; los pre-aprobados, es el listado de las personas, entregadas por los proveedores de datos para el proceso de selección; los rechazados, son las personas que no cumplen con los criterios de selección exigidos por el Banco; y por último los reales, son las personas que tienen actualmente los productos ofrecidos por el banco.

Producto: Son los bienes entregados por el banco a los clientes reales, en nuestro contexto serían las Tarjetas de crédito y Créditos de libre de inversión.Áreas: Validación de riesgo, Estudio de crédito, Comercial

Sección 2. Generalidades del Proyecto

2.1 Problema a Resolver

El Banco Los Alpes se encuentra preocupado por el crecimiento que están teniendo los índices de morosidad de sus productos de crédito masivo y por el crecimiento del número de clientes que están usando el Banco para lavar dinero producto de operaciones ilícitas. Por esta razón el banco desea fortalecer todo el proceso de generación de créditos para que soporte las regulaciones internacionales en controles de riego operativo y financiero.

2.2 Descripción General del Sistema a Desarrollar

La solución propuesta comprende la Automatización del Proceso de originación de crédito del Banco Los Alpes, cuyo propósito es la integración, mejora y estandarización de los procesos involucrados: segmentación del mercado, validación del riesgo, estudio de crédito, apertura de productos, realce y activación. Se incluyen nuevas opciones para la validación de riesgo creditico apoyándose en la consulta de centrales de riesgo vía servicios, y se depura y estandariza la integración entre aplicaciones que hacen parte del proceso. Lo anterior busca apoyar la estrategia comercial del Banco Los Alpes para competir en el mercado globalizado.

2.3 Objetivos

- A través de los motivadores de negocio identificados en los documentos de arquitectura y los atributos de calidad lograr tener elementos suficientes para estudiar los modelos de arquitectura que mejor se adapta a la solución planteada

- Plantear un estilo arquitectural que permita soportar los motivadores de negocio evaluados a través de los escenarios de calidad.

2.4 Stakeholders

Tabla 1: Listado de los Stakeholders

Stakeholder Descripción

Patrocinador Corresponde al Banco los Alpes que en su deseo de mejorar los procesos de


originación de crédito ha decidido crear un proyecto que ayude a optimizar dicho proceso

Usuarios Finales Personas que se apoyan en el sistema construido para ejecutar funciones del negocio y serán los directos involucrados en su uso.

Clientes del banco Analistas de riesgo Analistas crédito Asesores comerciales

Áreas del Negocio Áreas que hacen parte del funcionamiento del banco y que su actividad impacta el objetivo del proyecto.

Área de riesgo Área de estudio de crédito Servicio al cliente Área comercial

Gerentes de Proyecto Comprende los líderes de los equipos de trabajo de ambas partes, su función es la de coordinar, divulgar, vigilar el cumplimiento de las tareas asignadas y la resolución de posibles conflictos en el proyecto

Diseñadores Miembros del proyecto encargados de la abstracción del problema, modelamiento y diseño de la arquitectura de solución.

Desarrolladores Comprende el grupo de ingenieros encargados de realizar/modificar las aplicaciones que van a resolver el problema planteado mediante funcionalidades


específicas.Área de prueba Grupo de personas encargadas de realizar

las diferentes pruebas encargadas de validar el correcto funcionamiento de la solución.

Sección 3. Motivadores Arquitecturales

3.1 Motivadores de Negocio

Nombre del Motivadorde Negocio

Descripción del Motivador de Negocio

Disminuir los índices de morosidad en los productos

Disminuir los índices de morosidad en mas de un 50% mediante la reestructuración del proceso de originación de crédito

de crédito masivoMedida del Impacto

Disminución del índice de morosidad en los productos de crédito masivo medido en porcentaje

Rangos Cota Mínima Cota MáximaNinguno 0% 5%Bajo 6% 20%Moderado 21% 40%Fuerte 41% 50%Muy Fuerte 51% 60%

Asociación del Motivador con el Negocio

Definido Por: Área de Crédito Ejecutado Por: Áreas de Crédito y RiesgoUbicación en el Portafolio del negocio Productos de crédito de consumo



Disminuir las operaciones el número de operaciones ilícitas en los procesos de vinculación de clientes

Disminuir las operaciones ilícitas en un 100% mediante la reestructuración del proceso de validación de riesgo

Medida del ImpactoDisminución de la operaciones ilícitas en los procesos de vinculación de clientes medido en porcentaje

Rangos Cota Mínima Cota MáximaNinguno 0 5%Bajo 6% 30%Moderado 31% 60%Fuerte 61% 90%Muy Fuerte 91% 100%


Definido Por: Área de RiesgoEjecutado Por: Área de RiesgoUbicación en el Portafolio del negocio

Productos de crédito de consumo



Incrementar las ventas de créditos de consumo en el segmento de personas con más futuro financiero

Incrementar las ventas en 20% mediante la implementación de canales electrónicos

Medida del ImpactoCrecimiento de las ventas en el segmento de personas con más futuro financiero medido en porcentaje

Rangos Cota Mínima Cota MáximaNinguno 0% 5%Bajo 6% 10%Moderado 11% 12%Fuerte 13% 15%Muy Fuerte 16% 20%


Definido Por: Área ComercialEjecutado Por: Área Tecnológica Ubicación en el Portafolio del negocio




Disminuir los procesos manuales en el proceso de originación de crédito

Disminuir los procesos manuales en un 100% mediante la implementación de procesos automáticos e interfaces entre las aéreas involucradas

Medida del ImpactoDisminuir los procesos manuales en el proceso de originación de crédito medido en porcentaje



Definido Por: Área ProcesosEjecutado Por: Área Tecnológica Ubicación en el Portafolio del negocio




Aumentar la calidad de la información en el proceso de originación de crédito

Aumentar la calidad de la información en un 50% mediante la eliminación de fuentes de información ambigua y/o redundante

Medida del ImpactoAumentar la calidad de la información en el proceso de originación de crédito medido en porcentaje



Definido Por: Área ProcesosEjecutado Por: Área Tecnológica Ubicación en el Portafolio del negocio


3.2 Restricciones de Tecnología

ID Restricción Tipo: Tecnología ( )Negocio ( x )

Nombre: Control de Riesgo Operativo y Financiero

Descripción: Soporte a regulaciones SOX y Basilea IIEstablecida por: Área de Riesgo y Área de Crédito

Alternativas: Ninguna

Observaciones: Dentro de las validaciones requeridas en este control se debe contemplar:

- Anti lavado de dinero- Listas negras- Datacredito- Cifin- Lista Clinton

ID Restricción Tipo: Tecnología ( )Negocio (x)

Nombre: Cero Papel

Descripción: Cero generación de reportes que impliquen la impresión en papel de información del negocio

Establecida por: Área de Procesos


Observaciones: La restricción de papel estará encaminada a no permitir la impresión de reportes y pantallas presentes en la aplicación

ID Restricción Tipo: Tecnología (x )Negocio ()

Nombre: Utilizar la plataforma y zonas de servicios actualmente configuradas

Descripción: La implementación de nuevos servicios y procesos de integración debe hacerse sobre el ambiente actualmente configurado

Establecida por: Área de Tecnología


Observaciones: Se debe garantizar que la implementación de nuevos servicios no toque o modifique en lo mas mínimo las aplicaciones que actualmente se encuentran en funcionamiento

ID Restricción Tipo: Tecnología ()Negocio (x)

Nombre: Respetar tiempos preestablecidos de entrega

Descripción: - Enero – Mayo Análisis del proceso de originación de crédito

- Junio – Agosto integrar los resultados del anterior análisis

- Septiembre – Diciembre: Implementación de la solución

Establecida por: Gerencia del Banco


Observaciones: Esta es la estrategia de trabajo que deberá respetar el consultor contratado para el mejoramiento del proceso de originación de crédito

ID Restricción Tipo: Tecnología (x)Negocio ()

Nombre: Integración con sistemas preexistentes

Descripción: Cualquier desarrollo nuevo se deberá integrar con desarrollos anteriores

Establecida por: Área de Tecnología


Observaciones: La integración debe respetar también los lineamientos de Arquitectura de TI actualmente vigentes en el Banco

3.3 Atributos de Calidad

3.3.1 Árbol de Utilidad

Atributo de Calidad: Eficiencia

Tiempo ID Descripción Prioridad

Tiempo de

procesamiento de

E0 Tiempo de respuesta en el procesamiento de

archivos de entidades externas no debe ser superior

(H,L)

archivos a 1 minuto

Validación

información con

entes externos

E1 La consulta de información que realiza el proceso

de validación de riesgo debe tener un tiempo de

respuesta inferior a 5 minutos

(H,M)

Tiempo de

respuesta consultas

E2 Tiempo de respuesta en cuanto a las consultas que

realizan los clientes a través del portal no superior a

2 segundos

(H,M)

Recursos

Zonas de

arquitectura

E3 Utilización de todas las zonas de la arquitectura

SOA existente

(M,H)

Software

disponible

E4 Utilización del software disponible y licenciado por

el banco para la implementación de la solución

(M,M)

Atributo de Calidad: Fiabilidad

Tolerancia a Fallas ID Descripción Prioridad

Manejo de errores

con sistemas

externos

F1 En caso de presentarse errores con sistemas

externos, la aplicación conservara el 99% la

operatividad de los procesos que se encuentran en

ejecución, informando claramente al usuario los

errores presentados y sin bloquear o sacar de línea

la aplicación

(H,H)

Alerta a errores F2 Cuando un cliente no pueda ejecutar exitosamente

una consulta o transacción, el sistema le alertara del

error en el 100% de los casos

(H,M)

Recuperabilidad

Consistencia de la

información

F3 Ante una falla del sistema, este garantizara un

100% la consistencia de los datos involucrados en

el momento del suceso

(H,H)

Detección a fallas F4 En el 99% de los casos en los que se presente una

falla en un servicio, el sistema estará en capacidad

de detectarlo, intentar restablecerlo y en caso de

persistir solicitar la intervención humana

(H,H)

Disponibilidad

Disponibilidad ante

fallas

F5 El sistema estará en capacidad de atender el 99% de

la carga normal de trabajo aunque se presente una

falla técnica

(H,H)

Atributo de Calidad: Mantenimiento

Modificación ID Descripción Prioridad

Modificación de

componentes

M1 El sistema estará en disposición de permitir la

modificación de sus componentes gracias a su

concepción modular

(M,H)

Reúso de

componentes

M2 El sistema favorecerá el 100% de las veces el reúso

de componentes gracias a su arquitectura basada en

componentes

(H,H)

Facilidad de

Pruebas

Sustitución de

componentes

M3 El sistema debe permitir el 100% de las veces la

sustitución de un componente que requiera ser

probado

(H,H)

Facilidad de

pruebas

M4 El 100% de los componentes del sistema deberá

contar con componentes de pruebas que permitan

en cualquier momento probar un escenario

particular para una funcionalidad deseada

(M,H)

Pruebas de

aceptación

M5 El 100% de las funcionalidades del sistema deben

tener registro de pruebas de aceptación de usuario

final

(M,M)

Estabilidad

Efectos

inesperados

M6 El sistema deberá estar en la capacidad que en el

99% de los cambios a componentes no se presente

ninguna situación que genere respuestas

inesperadas

(H,H)

Manejo de

versiones

M7 Manejo garantizado de las versiones del producto a

través del tiempo, que permita mantener estable y

actualizada una línea base

(H,M)

Flexibilidad

Integración con

sistemas legados

M8 El sistema debe garantizar la integración con otros

sistemas de tal forma de que se puedan manejar

diversos tipos de datos y protocolos

(H,H)

Escalabilidad

Incremento de

usuarios

M9 La arquitectura del sistema deberá estar lista para

soportar un incremento sostenido de 1000 usuarios

anuales

(H,H)

Atributo de Calidad: Seguridad

Integridad ID Descripción Prioridad

Autenticación de

usuarios

S1 En el 100% de los accesos al sistema debe impedir

la entrada de usuarios no autenticados

(H,M)

Autenticación de

accesos

S2 En el 100% de los accesos al sistema se deberá

utilizar un proceso de autenticación con el fin de

determinar quién es el usuario

(H,M)

Confidencialidad

Autorización de

usuarios

S3 En el 100% de los casos el acceso a la información

del sistema deberá estar autorizado mediante un

proceso de validación de perfil o rol

(H,M)

Encripción de

información

S4 En el 100% de las veces, la información desplegada

a clientes externos o hacia entidades externas

deberá estar encriptada

(H,M)

3.3.2 Escenarios de Calidad

Escenario de Calidad # E0 Stakeholder: Usuario

Atributo de Calidad Eficiencia

JustificaciónEl sistema debe garantizar el procesamiento eficiente de los archivos que entregan los proveedores de información

Fuente Proveedores de los archivos de prospectos

Estímulo Cargue del archivo en el sistema de cargue de prospectos

Artefacto Sistema de Cargue de Archivos

Ambiente Operación Normal

Respuesta

El sistema informa al usuario que el archivo ha sido procesado de acuerdo a las siguientes posibilidades:

- El archivo ha sido procesado exitosamente- El archivo ha sido procesado con errores

Medida de la Respuesta

Un archivo de 2500 registros pude ser cargado en un tiempo no superior a 5 segundos

Escenario de Calidad # E1 Stakeholder: Usuario


JustificaciónEl sistema debe garantizar la ejecución eficiente y rápido del proceso de validación de riesgo con las entidades externas y las listas negras locales

Fuente Base de datos de prospectos

Estímulo Ejecución del proceso de validación de riesgo operativo y financiero

Artefacto Modulo de validación de riesgo


RespuestaEl sistema realiza las validaciones de riesgo respectivas y guarda en una base datos el resultado de la calificación de riesgo para cada prospecto


El proceso de validación de riesgo no debe ser superior a 1 minuto por cada 1000

Escenario de Calidad # E2 Stakeholder: Cliente


JustificaciónEl sistema debe garantizar que la consultas que tiene configuradas el sistema tengan un tiempo de respuesta optimo

Fuente Cliente o usuario que realiza la consulta

Estímulo Selección de la opción de consulta

Artefacto Modulo de reportes


Respuesta

El sistema despliega al usuario la información por pantalla de acuerdo a las siguientes condiciones:

- Consulta exitosa- No se pudo realizar la consulta


El tiempo de respuesta del sistema no debe ser superior a 2 segundos

Escenario de Calidad # E3 Stakeholder: Líder de Desarrollo


JustificaciónSe debe hacer uso de la plataforma y estructura arquitectural existente en las aplicaciones actuales del banco

Fuente Documentación y ambiente de Arquitectura actual

EstímuloImplementación de las diferentes zonas SOA propuestas en la solución al proceso de mejoramiento del proceso de originación de crédito

Artefacto Arquitectura Actual

Ambiente Despliegue de la solución en el ambiente de producción

RespuestaLa solución se encuentra desplegada y en funcionamiento en el ambiente y arquitectura definida por el banco


La solución ha sido desplegada y puesta en producción el mismo dia

Escenario de Calidad # E4 Stakeholder: Líder de Soporte


JustificaciónEl banco tiene software licenciado que debe ser utilizado y adicionalmente el banco no piensa invertir en la compra de otras herramientas

Fuente Política del banco

Estímulo Configuración y despliegue de la solución en los ambientes de desarrollo, pruebas y

producción del banco

Artefacto Herramientas de software configuradas

Ambiente Despliegue de la solución en los ambientes de desarrollo, pruebas y producción

RespuestaLa solución se encuentra desplegada y en funcionamiento utilizando las herramientas licenciadas por el banco


Cantidad de herramientas utilizadas para el despliegue de la solución

Escenario de Calidad # F1 Stakeholder: Líder de Calidad

Atributo de Calidad Fiabilidad

JustificaciónEl banco requiere estar en línea con las entidades externas y mantener la una comunicación controlada

FuenteRequerimientos de información y validación con entidades externas tales como: Registraduria Nacional, CIFIN y DATACREDITO

Estímulo Consulta de información demográfica y de riesgo financiero de los prospectos

ArtefactoSistema de prospectos (PartnerFileLoaderSystem) y Sistema para la depuración y segmentación de prospectos (CustomerScoringSystem)


RespuestaAl momento de presentarse un error de cualquier índole, el sistema deberá identificarlo, manejarlo y dejar registro de este en un log


Numero de errores registrados en el log de la aplicación



JustificaciónEl sistema debe retroalimentar a sus usuarios respecto de los errores presentados en las funcionalidades utilizadas por estos

Fuente Error presentado en una funcionalidad de consulta o transaccional

Estímulo Identificación y captura de un error en la funcionalidad

Artefacto Sistema involucrado en el error


RespuestaEl sistema retroalimenta al usuario respecto de la anomalía presentada y le presenta las alternativas a tomar ante tal error


Porcentaje de funcionalidades del sistema que ofrecen retroalimentación de fallas a los usuarios



JustificaciónLa información involucrada al momento de una falla deberá conservar su consistencia a fin de evitar falta de credibilidad





Respuesta

Al momento de presentarse un error en que estén involucrados registros de información, el sistema deberá identificarlo, manejarlo y adicionalmente deberá garantizar que la información conservara el estado y consistencia que tenía antes de que sucediera el error


Cantidad de registros involucrados en el error, que retornaron a su estado anterior



JustificaciónEl sistema debe garantizar la confiabilidad de su funcionalidad no permitiendo que quede fuera de línea o bloqueando a los usuarios





Respuesta

Al momento de presentarse un error en el sistema, se deberá además de identificarlo, intentar restablecerlo realizando n intentos de solicitud de la operación que fallo en un lapso de tiempo. Si no se puede restablecerlo el sistema deberá informar al responsable del soporte lo que está sucediendo


Cantidad de errores identificados y solucionados



JustificaciónEl sistema debe garantizar la disponibilidad de su funcionalidad a todos los usuarios que lo utilizan a pesar de que se presenten fallas





Respuesta

Al momento de presentarse un error en el sistema, este deberá retroalimentar no solamente al usuario involucrado en el error, sino que deberá mantener funcional el sistema para todas las demás funcionalidades utilizadas por otros usuarios que estén en ese momento operando el sistema


Porcentaje del sistema que se encuentra funcional al momento de una falla

Escenario de Calidad # M1 Stakeholder: Líder de Desarrollo

Atributo de Calidad Mantenimiento

JustificaciónEl mantenimiento de la solución debe permitir la corrección o ajuste de sus componentes de una manera rápida y fácil. Se debe tener en mente una estrategia de bajo acoplamiento

Fuente Análisis y Diseño de la Solución

Estímulo Solicitud de cambio

Artefacto Componente a ser modificado

Ambiente Cuando se haga la modificación en ambiente de desarrollo

RespuestaEl componente es modificado rápidamente y en forma tal que no afecta el funcionamiento de ningún otro componente


El componente se encuentra en funcionamiento y se obtiene un tiempo de respuesta no superior a 2 segundos



JustificaciónLa solución deberá estar construida con el soporte de una arquitectura que permita el reúso de sus componentes y gracias a una estrategia de programación orientada a objetos


Estímulo Creación y modificación de funcionalidades

Artefacto Componente a ser creado o modificado

Ambiente Cuando se realice el componente en ambiente de desarrollo

Respuesta El componente es creado o modificado y se encuentra funcionando correctamente





JustificaciónEl mantenimiento de la solución debe permitir la sustitución de sus componentes de una manera fácil. Se debe tener en mente una estrategia de bajo acoplamiento


Estímulo Solicitud de cambio

Artefacto Componente a ser cambiado

Ambiente Cuando se haga el cambio en ambiente de desarrollo

RespuestaEl componente es cambiado rápidamente y la funcionalidad del sistema no se altero





JustificaciónCada componente de la solución deberá contar con un componente de pruebas que facilite la ejecución de casos de prueba y escenarios diversos


Estímulo Creación de un nuevo componente

Artefacto Componente a ser construido

Ambiente Cuando se haga la construcción del componente en ambiente de desarrollo

RespuestaEl componente de prueba asociado a un componente funcional arroja valores de prueba como resultado de un escenario particular


Cantidad de escenarios de prueba ejecutados en forma exitosa



JustificaciónDebe existir evidencia de la aceptación dada por el usuario respecto de las funcionalidades desarrolladas

Fuente Plan de pruebas

Estímulo Funcionalidad probada por el usuario

Artefacto Funcionalidad probada

Ambiente Cuando se hagan las pruebas de aceptación en el ambiente de pruebas

RespuestaEl componente responde correctamente y está de acuerdo a las expectativas del usuario


Numero de funcionalidades aprobadas por el usuario



JustificaciónEl sistema no debe generar situaciones sorpresivas o inesperadas como fruto de cambio a sus funcionalidades

Fuente Plan de pruebas

Estímulo Mantenimiento a una funcionalidad del sistema

Artefacto Funcionalidad modificada

Ambiente Cuando se hagan las pruebas de la funcionalidad en el ambiente de pruebas

RespuestaLa funcionalidad funciona correctamente y el sistema como un todo se encuentra operando correctamente


Cantidad de comportamientos inesperados después de modificar una funcionalidad

Escenario de Calidad # M7 Stakeholder: Líder de Calidad


JustificaciónEl sistema deberá permitir el manejo de versiones claramente identificadas y que permitan mantener un histórico de modificaciones o actualizaciones realizadas a la solución

Fuente Plan de configuración

Estímulo Modificación de una funcionalidad

Artefacto Línea base modificada

Ambiente Cuando se hagan las modificaciones en el repositorio de versiones

Respuesta La modificación ha sido realizada y los cambios se han aplicado a la línea base


Cantidad de modificaciones o ajustes realizados como resultado de la modificación a la línea base

Escenario de Calidad # M8 Stakeholder: Líder de Calidad


JustificaciónEl sistema deberá integrarse si es el caso a otros sistemas que actualmente tiene en funcionamiento el banco

Fuente Integración con el sistema de administración de clientes (CRM)

Estímulo Creación de la información básica de un cliente

Artefacto Sistema CRM


Respuesta El registro del cliente ha sido creado


Cantidad de registros de clientes creados exitosamente en el CRM



JustificaciónEl sistema deberá garantizar la escalabilidad como resultado del número creciente de clientes que tiene el banco

Fuente Arquitectura de la aplicación

Estímulo Incremento en el acceso a la aplicación del número de clientes

Artefacto Portal del banco


RespuestaEl sistema responde adecuadamente a los requerimientos transaccionales y de consulta de los clientes


El tiempo de respuesta a las solicitudes de los clientes no es superior a 2 segundos

Escenario de Calidad # S1 Stakeholder: Usuario

Atributo de Calidad Seguridad

JustificaciónEl sistema debe impedir el acceso a usuarios no autorizados para evitar perdida de confidencialidad y consulta de información confidencial

Fuente Políticas de seguridad del banco

EstímuloUsuario accede al login del sistema y se intenta autenticar digitando el usuario y el password

Artefacto Formulario de ingreso al sistema


RespuestaEl sistema valida la información de autenticación del en caso de no ser valida, informara al usuario que no ha podido ser validada su autenticidad y se rechazara su acceso al sistema


Numero de intentos de acceso fallidos



JustificaciónEl sistema debe validar la información de autenticación de los usuarios que intentan ingresar al sistema con el fin de verificar su autenticidad


EstímuloUsuario accede al login del sistema y se intenta autenticar digitando el usuario y el password

Artefacto Formulario de ingreso al sistema


RespuestaEl sistema valida la información de autenticación del usuario y retorna cualquiera de las siguientes respuestas:

- Usuario no reconocido

- Usuario autenticado y se re direcciona a la página principal de la aplicación


Numero de accesos al sistema en un rango definido de tiempo



JustificaciónEl sistema debe validar el rol de los usuarios que acceden con el fin de validar las opciones o funcionalidades a las que puede acceder de acuerdo a su nivel de responsabilidad


EstímuloEl usuario que se ha autenticado intenta acceder a cualquiera de las funcionalidades que le presenta el sistema

Artefacto Componente que valida la autorización o rol del usuario


RespuestaEl sistema valida el rol del usuario y como resultado le despliega las opciones a las que de acuerdo a mencionado rol tiene derecho


Numero de roles autorizados y funcionalidades asociadas



JustificaciónEl sistema deberá asegurar que cualquier tipo de información que se remita a una entidad externa a través de cualquier canal, se encuentre encriptada con el fin de asegurar su confidencialidad


EstímuloEl sistema envía información de los clientes a entidades externas con el fin de validar el riesgo financiero

ArtefactoServicio de consulta de información con entes externos como CIFIN y DATACREDITO


RespuestaEl sistema ha enviado la información a un ente externo a través de un canal seguro (VPN o SSL)


Cantidad de información enviada a través de un canal con una entidad externa



JustificaciónEl sistema deberá asegurar que cualquier tipo de información que se remita a una entidad externa a través de cualquier canal, se encuentre encriptada con el fin de asegurar su confidencialidad


EstímuloEl sistema envía información de los clientes a entidades externas con el fin de validar el riesgo financiero

ArtefactoServicio de consulta de información con entes externos como CIFIN y DATACREDITO


RespuestaEl sistema ha enviado la información a un ente externo a través de un canal seguro (VPN o SSL)


Cantidad de información enviada a través de un canal con una entidad externa

Sección 5. Punto de Vista Funcional

5.1 Diagrama Nivel 0 Proceso de Originación de Crédito

Familia:Module ( )C&C (X)Allocation ( )Estilo Arquitectural:

Peer to peer

Convención:

Titulo: Originación de Crédito ID: 001 Nivel de Profundidad: Nivel 0

Nomenclatura: Ad hoc

Arquitecto: .JARC Grupo: Peer to Peer Fecha: 05 de Septiembre de 2010 Versión: 1.0

5.2 Diagrama Nivel 1 Proceso de Originación de Crédito


Cliente

Servidor

Convención:

Titulo: Originación de Crédito ID: 002 Nivel de Profundidad: Nivel 1


Arquitecto: .JARC Grupo: Cliente Servidor Fecha: 05 de Septiembre de 2010 Versión: 1.0

5.3 Diagrama Nivel 2 – Dinámico Proceso de Cargue de Archivos


Pipe and Filter

Convención:

Titulo: Carga de archivos ID: 003 Nivel de Profundidad: Nivel 2


Arquitecto: .JARC Grupo: Pipe and Filter Fecha: 05 de Septiembre de 2010

Versión: 1.0

5.4 Diagrama Nivel 2 – Estático Proceso de Cargue de Archivos


Capas

Convención:

Titulo: Carga de archivos

ID: 004 Nivel de Profundidad: Nivel 2


Arquitecto: .JARC Grupo: Layered Fecha: 05 de Septiembre de 2010 Versión: 1.0

5.6 Diagrama Nivel 3 – Patrón Factory MethodProceso de Cargue de Archivos


Pipe and

Filter

Convención:

Titulo: Carga de archivos – capa de servicios



Arquitecto: .JARC Grupo: Pipe and Filter (Factory Method) Fecha: 05 de Septiembre de 2010 Versión: 1.0

5.7 Diagrama Nivel 2 – Estático Proceso de Validación de Riesgo


Capas

Convención:

Clientes de la Aplicación

Capa de presentación

Componente sw

Capa

Conectores

Repositorios y Servicios

Titulo: Validación Riesgo ID: 006 Nivel de Profundidad: Nivel 2


Arquitecto: .JARC Grupo: Layered Fecha: 05 de Septiembre Versión: 1.0

Capa de Presentación

Interfaz funcionario Interfaz administrador

Capa de Lógica de Negocio

Gestor Entes Externos

Gestor Listas Negras Locales Gestor de Parámetros

Capa de Datos

Adaptador Servicios Adaptador Base de Datos

Servicios Externos Base DatosLocal

de 2010

5.8 Diagrama Nivel 2 – Dinámico Proceso de Validación de Riesgo


Pipe and Filter

Convención:

Conector con sistemas legados

Proceso interno

Conector con servicios externos

Conector con procesos internos

Base de datos



Arquitecto: .JARC Grupo: Pipe and Filter Fecha: 05 de Septiembre de 2010

Versión: 1.0

Conector Fiscalía Conector Minhacienda

Conector CIFINConector

DATACREDITO

Leer ProspectoValidar L Neg

LocalesValidar L Neg

ExternasValidar Riesgo

Crediticio

BD ProspectosListas Neg.

Locales

5.9 Diagrama Nivel 3 – Patrón Reactor Proceso de Validación de Riesgo


Pipe and Filter

Convención:

Proceso / Evento

Flujo de información

Conector de uso

Base de datos

Componente de servicio



Leer Prospecto

ReactorInitiation

Dispatcher

Event HandlerValidar L.Neg

Locales

Event HandlerValidar CIFIN

Event HandlerValidar

DATACREDITO

Sync Event Demultiplexer

BD Prospectos

Servicios

Arquitecto: .JARC Grupo: Pipe and Filter (Reactor)

Fecha: 05 de Septiembre de 2010

Versión: 1.0

5.9 Diagrama Nivel 3 – Patrón Reactor Proceso de Validación de Riesgo


capas

Convención:

Componente sw

Flujo de información

Conector de uso

Base de datos

Bus Servicios

Interfaz

Interfaz JSF Backing Bean

ReactorInitiation DispatcherEvent

Handler

Entity BeanAdaptador Servicios

Bus Servicios BD Prospectos

Capa presentación

Capa negocio

Capa datos

Sync Event Demultiple

xer



Arquitecto: .JARC Grupo: Layered Fecha: 05 de Septiembre de 2010

Versión: 1.0

5.10 Diagrama Nivel 1 Proceso de Activación / Bloqueo de Productos

Familia:Module ( )C&C ( )Allocation ( X )Estilo Arquitectural:

Capas

Convención:

Nodo

Recurso/Proceso

Conector con servicios externos

Conector con procesos internos

Titulo: Activar/Bloquear Producto




Versión: 1.0


deployment Activ acion Producto

Capa de Presentación

Interfaz Cliente portal

Capa de Serv icios

Gestor de Serv icios

Capa de Negocio

Gestor serv icios portal

Capa de Datos

Adaptador de serv icios

Adaptador Datos

Cliente

Familia:

Module ( )C&C (X)Allocation ( )

Estilo Arquitectural:

Multicapa

Convención:

Cliente

: Capa

X ---- Y: X Usa Y

Titulo: Activar/Bloquear Producto ID: 010 Nivel de Profundidad: Nivel 2 Nomenclatura:Ad hoc


Versión: 1.0


Familia:Module ( )C&C ( X)Allocation ()Estilo Arquitectural:

Peer to peer

Convención:

Clase

Relaciones

Titulo: Activar/Bloquear Producto ID: 011 Nivel de Profundidad: Nivel 3


Arquitecto: .JARC Grupo: Peer to peer Fecha: 05 de Septiembre de 2010

Versión: 1.0

Sección 6. Punto de Vista de Información

6.1 Diagrama Estado Cliente

Familia:Module ( )C&C (X)Allocation ()Estilo Arquitectural:

Pipe and filter

Convención:

Estado

Transición

Transición

Estado inicial

Estado final

Titulo: Diagrama Estado Cliente ID: 012 Nivel de Profundidad: NA

Nomenclatura: UML

Arquitecto: .JARC Grupo: Pipe and filter Fecha: 10 de Octubre de 2010

Versión: 1.0

6.2 Diagrama Estado ProductoFamilia:Module ( )C&C (X)Allocation ()Estilo Arquitectural:

Pipe and filter

Convención:

Estado

Transición

Transición

Estado inicial

Estado final

Titulo: Diagrama Estado Producto ID: 012 Nivel de Profundidad: NA

Nomenclatura: UML


Versión: 1.0

Productoactivo

Productopreaprobado

Productoaprobado

Productoinactivo

Asignación de producto al cliente

Cliente solicita Activación

Cliente cancela el producto

Productodisponible

Estudio de crédito

6.3 Propiedades de los Datos

Responsable

Cliente / Prospecto Segmentación Tarjeta Crédito Tarjeta Debito Crédito Libre Inversión

Administrador C,M,E Funcionario Área de Riesgo C,M Funcionario Área de Crédito M

Funcionario Apertura de Productos M C,M,E C,M,E C,M,E

Creación CModificación MEliminación E

6.3 Diagramas de flujo de información


Pipe and filter

Convención:

Decisión

Inicio/fin

Proceso

Almacén de datos

ConectorTitulo: Diagrama de flujo de información del proceso de carga de datos

ID: 012 Nivel de Profundidad: NA

Nomenclatura: Diagrama de flujo de datos


Versión: 1.0

6.4 Diagrama de casos de abuso


Pipe and filter

Convención:

Caso de abuso

Caso de uso

Conector

Actor

Titulo: Diagrama caso de abuso “Robar información clientes”

ID: Nivel de Profundidad: NA

Nomenclatura: UML

Arquitecto: .JARC Grupo: .JARC Fecha: 26 de Octubre de 2010

Versión: 1.0

Nombre Robar información clientes

Autor Grupo .JARC

Fecha 26/10/2010

Actor (es) Principal (es): Ladrón

Descripción: El ataque es del tipo “Information Disclosure” (STRIDE) .Intrusión de un ladrón de información al interior de la entidad que quiere obtener información demográfica de clientes para posibles estafas.

Precondición (es): Los archivos con la información recibida de los clientes se encuentran ubicados en un servidor o PC no seguros y con recursos compartidos

Flujo básico: 1. El ladrón ingresa a su estación de trabajo2. A través de la red ubica la IP o el nombre del servidor donde se

encuentra la información 3. Una vez ubica el servidor comienza a revisar las carpetas en búsqueda

de información de clientes4. Una vez encuentra los archivos con la información los copia o los abre

para copiar la información de clientes5. Cierra la conexión con el servidor y dispone de la información a su

gusto

Peor de los casos de amenaza:

Puntos de mitigación:- En el punto 2 del flujo el ladron no puede realizar la búsqueda de otros

equipos en la red- En el punto 3 si ubica el servidor, este último no tiene recursos

compartidos- En el punto 4 el archivo que intenta abrir tiene restricción de lectura

mediante clave

Respuesta al ataque:Se cuenta con la funcionalidad de monitorear los usuarios que ingresan al servidor. Una vez se detecta un usuario que no debería tener tales privilegios, se desconecta el servidor de la red, se restringe el acceso y se deja de

compartir los recursos

Tecnología El atacante puede utilizar un comando de red para identificar la IP o el nombre del equipo, o utilizar la posibilidad de navegación a través de la red que le proporcional el sistema operativo de su maquina

Complejidad: Baja

Prioridad: Media

Requisitos especiales:


Pipe and filter

Convención:

Caso de abuso

Caso de uso

Conector

Actor

Titulo: Diagrama caso de abuso “Modificar datos del cliente”

ID: Nivel de Profundidad: NA

Nomenclatura: UML

Arquitecto: .JARC Grupo: .JARC Fecha: 26 de Octubre de 2010

Versión: 1.0

Nombre Modificar datos de clientes

Autor Grupo .JARC

Fecha 26/10/2010

Actor (es) Principal (es): Atacante

Descripción: El ataque es del tipo “Tampering” (STRIDE). Intrusión de un ladrón de información al interior de la entidad que desea modificar la información de un cliente (conocido) con el fin de facilitar por ejemplo la aprobación de un crédito a través de la modificación del estado o la calificación de riesgo crediticio.

Precondición (es): No existen ambientes de pruebas y producción aparte. El ambiente de pruebas es el mismo de producción y cualquier analista o desarrollador tiene acceso por efectos de su trabajo, a la información de los clientes

Flujo básico: 1. El atacante se conecta a la base de datos mediante un IDE o mediante un software de conexión a bases de datos como sqlplus

2. El atacante que ya conoce el modelo ER de la base de datos, ubica la tabla que contiene la información de los clientes

3. El atacante mediante una sentencia SQL realiza un update a los datos del cliente que desea favorecer

4. El atacante cierra la sesión con la base de datos


Puntos de mitigación:- Debe existir un ambiente de desarrollo y/o pruebas en donde el

atacante potencial únicamente pueda acceder- En los ambientes de pruebas no debe existir información real de

clientes, todo debe ser datos de prueba- En el punto 1 se debe exigir conexión a base de datos con un usuario

particular y no genérico para poder identificar de primera mano el usuario que ingreso

- En el punto 1, una vez el usuario se autentique debe activarse un log que permita registrar los movimientos del atacante

Respuesta al ataque:Una vez se detecte en el log de la base de datos que se realizo una operación de modificación de un registro, se debe automáticamente y mediante un trigger, disparar una alerta que sea direccionada al administrador de la base de datos, con la información del usuario que realizo la modificación

Tecnología El atacante accede a la base de datos a través de una herramienta (IDE) para conexión con bases de datos como SQLPLUS, PL/SQL Developer, TOAD, etc.

Complejidad: Media

Prioridad: Alta

Requisitos especiales:

Se toma como escenario las transacciones que puede realizar un cliente en portal de Banco de Los Alpes, y las amenazas a que está expuesto el sitio web.

Desbordar el sistema

Nombre Desbordar el sistema

Autor Grupo .JARC

Fecha 2010/10/11

Actor (es) Principal (es): Estafador/Atacante

Descripción: Consiste de un ataque para intentar realizar el ingreso masivo registros inválidos y la negación y/o degradación del servicio

Precondición (es): El sitio web dispone de un sitio web en el cual se puede realizar el registro de cliente para acceder a ciertos servicios a través del portal del Banco de Los Alpes


Se ingresan masivamente registros inválidos en el sistema, se presenta indisponibilidad del sistema

Prevención de garantía:El módulo de monitoreo del sistema detecta el intento de

inserción de registros inválidos y envía una notificación de alarma al administrador del sistema.

Tecnología El atacante puede utiliza un navegador de internet o herramientas para envío masivo de peticiones http y/o de DOS

Complejidad: Media

Prioridad: Media

Requisitos especiales:6.4 Diagrama de clases

A continuación se muestran las entidades que se utilizan a lo largo del proceso de originación de crédito del Banco de los Alpes.

5.2 Punto de Vista de Despliegue En esta sección se presenta el punto de vista de despliegue

5.2.1 Descripción

5.2.2 Modelos de Plataforma de Ejecución

Familia:Module ( )C&C ()Allocation ()Estilo Arquitectural:

Convención:

Nodo

Componente

Artefacto_____________

Conector

Titulo: Modelo de Plataforma de Ejecución

ID: 014 Nivel de Profundidad: NA

Nomenclatura: UML

Arquitecto: .JARC Grupo: Fecha: 25 de Octubre de 2010

Versión: 1.0

5.2.3 Modelos de Red

5.2.4 Modelos de Dependencia Tecnológica

Componente

Requiere

Integration Developer

ESB

MySQL RDBMS

STORAGE

WebSphere Portal

Autentication

Autorization

Browser

jarc arqsw documentoarquitecturasw v 5 0

Documents