1.introducciÓn# - maestría en tecnologías de …mti.cucea.udg.mx/sites/default/files/srs.pdf ·...
TRANSCRIPT
1
1. INTRODUCCIÓN
El presente documento describe la especificación de requerimientos de software para el proyecto titulado: Sistema de Análisis Crediticio del Programa de Crédito Automotriz en Arrendamiento (PROCAAR), propuesto por la empresa denominada ABC Leasing de MEXICO SAPI DE CV y ahora utilizado como proyecto de Tesis para la Maestría en Tecnologías de Información impartida en el Centro Universitario de Ciencias Económico Administrativas.
1.1 PROPÓSITO DEL DOCUMENTO
Especificar de forma única y completa los requerimientos con que deberá cumplir el proyecto, con la finalidad de ser una referencia para los grupos de relación involucrados en el mismo, como son: directivos, encargados del proyecto, desarrolladores, usuarios finales; tomando importancia dicho documento para la toma de decisiones relevantes dentro del seguimiento del proyecto.
1.2 ALCANCE DEL DOCUMENTO
El presente documento considera los elementos necesarios para la operación del proyecto el cual integra dos partes generales:
a) Centro de atención telefónica: se requiere un sistema de grabación para la llamada telefónica a clientes y una persona encargada de operar todo el proceso.
b) Sistema de Análisis Crediticio: sistema de información que permitirá la captura, envío y recuperación de información; así mismo realizará el análisis creditico de acuerdo al modelo de evaluación crediticio (Credit Scoring) utilizado en ABC Leasing, del cual se obtendrán reportes paramétricos donde se señalen los niveles de riesgo del evaluado.
1.3 DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS
ARRENDAMIENTO: El arrendamiento puro o leasing (alquiler con derecho de compra) es un contrato mediante el cual, el arrendador traspasa el derecho a usar un bien a cambio del pago de rentas durante un plazo determinado al término del cual el arrendatario tiene la opción de comprar el bien arrendado pagando un precio determinado, devolverlo ó renovar el contrato.
BURÓ DE CRÉDITO: Una empresa privada y los únicos que reciben información oportuna, confiable y segura de personas y empresas que han tenido o tienen algún tipo de crédito. Cuentan con certificados de calidad y un gran tamaño de base de dato.
2
INTRANET: Una intranet es una red de ordenadores privados que utiliza tecnología Internet para compartir dentro de una organización parte de sus sistemas de información y sistemas operacionales. El término intranet se utiliza en oposición a Internet, una red entre organizaciones, haciendo referencia por contra a una red comprendida en el ámbito de una organización.
IP: Una dirección IP es una etiqueta numérica que identifica, de manera lógica y jerárquica, a un interfaz (elemento de comunicación/conexión) de un dispositivo (habitualmente una computadora) dentro de una red que utilice el protocolo IP (Internet Protocol), que corresponde al nivel de red del Modelo OSI. Dicho número no se ha de confundir con la dirección MAC, que es un identificador de 48bits para identificar de forma única la tarjeta de red y no depende del protocolo de conexión utilizado ni de la red. La dirección IP puede cambiar muy a menudo por cambios en la red o porque el dispositivo encargado dentro de la red de asignar las direcciones IP decida asignar otra IP (por ejemplo, con el protocolo DHCP). A esta forma de asignación de dirección IP se denomina dirección IP dinámica (normalmente abreviado como IP dinámica).
PROCAAR: Programa de Crédito en Automotriz en Arrendamiento, es el servicio ofrecido a los clientes como una opción de arrendamiento automotriz. En términos formales Arrendamiento es un acuerdo por el que el arrendador cede al arrendatario, a cambio de percibir una suma única de dinero, o una serie de pagos o cuotas, el derecho a utilizar un activo durante un tiempo determinado. PROCAAR tiene como objetivo, establecer un modelo de negocio y evaluación de riesgo parametrizado para la realización de operaciones de arrendamiento sobre equipos de transporte, principalmente al nicho de mercado que representan aquellas personas físicas con actividad empresarial, profesionistas o dueños de pequeñas empresas que derivan de su actividad, representa un valor agregado el esquema de arrendamiento operativo, buscando minimizar el riesgo de la cartera en su conjunto.
RIESGO CREDITICIO: Es determinado por la probabilidad que un deudor será capaz para pagar el interés o capital de acuerdo a los términos de un contrato.
SOCKETS: Es un método para la comunicación entre un programa del cliente y un programa del servidor en una red. Un socket se define como el punto final en una conexión. Los sockets se crean y se utilizan con un sistema de peticiones o de llamadas de función a veces llamados interfaz de programación de aplicación de sockets (API, Application Programming Interface).
UML: Lenguaje de Modelado Unificado, es un lenguaje grafico para visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. UML
3
proporciona una forma estándar de representar los planos de un sistema, y comprende tanto elementos conceptuales, como los procesos del negocio y las funciones del sistema, cuanto elementos concretos, como las clases escritas en un lenguaje de programación específico, esquemas de base de datos y componentes de software reutilizables.
VPN: De las siglas en inglés de Virtual Private Network, es una tecnología de red que permite una extensión segura de la red local sobre una red pública o no controlada. Ejemplos comunes son la posibilidad de conectar dos o más sucursales de una empresa utilizando como vínculo Internet, permitir a los miembros del equipo de soporte técnico la conexión desde su casa al centro de cómputo, o que un usuario pueda acceder a su equipo doméstico desde un sitio remoto, como por ejemplo un hotel. Todo ello utilizando la infraestructura de Internet.
1.4 REFERENCIAS
Como referencia para este documento, se emplearon las siguientes fuentes:
No. Título Publicación Autor 1 IEEE Recommended Practice for Software Requirements
Specifications, Std. 830-‐1998 1998 IEEE
2 Programa de Crédito Automotriz en Arrendamiento 2010 ABC Leasing
3 A Credit Scoring Decision Support System 2011 Dukic 4 El Lenguaje de Modelado Unificado 2005 Booch,
Jacobson 5 http://www.masadelante.com/faqs/socket -‐ -‐ 6 http://es.wikipedia.org/wiki/Intranet -‐ -‐ 7 http://www.proyectar.com.mx/arrendamiento.htm -‐ -‐ 8 http://es.wikipedia.org/wiki/Direcci%C3%B3n_IP -‐ -‐
1.5 PANORAMA GENERAL DEL DOCUMENTO
La estructura de este documento está basada en la Especificación de Requerimientos de Software, referida en el estándar IEEE 830. En base a esto, como segundo apartado se presenta la descripción general del producto, donde se describen factores que afectan al producto y sus requerimientos de forma general, consta de seis subsecciones, entre ellas se incluyen perspectivas del producto, interfaces del sistema: interfaz de usuario, de hardware, de software y de comunicaciones; así como restricciones y algunos puntos específicos para la operación. En la tercera sección se especifican a detalle los requerimientos con la finalidad de crear un panorama claro para los involucrados en el
4
proyecto. En la cuarta y última sección se incluyen diagramas UML: diagramas de caso de uso, de clases, de secuencia, entre otros.
2. DESCRIPCIÓN GENERAL
En la presente sección se describen de forma general los factores que afectan al producto y sus requerimientos.
2.1 PERSPECTIVA DEL PRODUCTO
El Sistema de Análisis Crediticio de PROCAAR, está habilitado para la consulta del historial crediticio de un cliente dentro las bases de datos de buró de crédito, el análisis de la información recibida y la generación automática de un reportes paramétricos; con la integración de estos elementos se obtiene una pre-‐aprobación de crédito de clientes del segmento PROCAAR en ABC Leasing.
2.1.1 INTERFACES DEL SISTEMA
En la presente sección se listan, de manera general, las interfaces incluidas en el producto; entre ellas se encuentran las interfaces de usuario, de hardware, de software, de comunicación; también se describen funciones y restricciones generales del producto.
2.1.2 INTERFACES DE USUARIO
A continuación se muestran las interfaces de usuarios las requeridas en el proceso que realiza el Sistema de Análisis Crediticio de PROCAAR.
1. Menú principal, Fig. 1
Fig. 1. Menú Principal
5
2. Ventana de inicio de sesión, Fig. 2.
Fig. 2. Inicio de Sesión
3. Ventana de captura de información, Fig. 3.
Fig. 4. Captura de Información
6
4. Información de salida: a. Análisis Paramétrico, Fig. 4
Fig. 4. Extracto Análisis Paramétrico
b. Reporte de Buró, Fig. 5
Fig. 5. Extracto Reporte de Buró
c. Reporte Control ABC, Fig. 6
7
Fig. 6. Reporte Control ABC
d. Reporte Control Buró de Crédito, Fig. 7
Fig. 7. Extracto Reporte de Control Buró de Crédito
2.1.3 INTERFACES DE HARDWARE
Uno de los requerimientos del servicio ID PROVIDER perteneciente a la entidad denominada Buró de Crédito, es tener una grabación que avale la autorización de que el cliente está de acuerdo en ser consultado en buró de crédito, por lo tanto, esta aplicación requiere una grabadora de llamadas telefónicas.
Para realizar consultas a las bases de datos de buró de crédito es necesario crear un túnel VPN, para lo cual es requerido tener un equipo de comunicaciones que permita este tipo de conexiones, el cual debe estar instalado y configurado conforme a los estándares establecidos.
El esquema de comunicación del Sistema de Análisis Crediticio de PROCAAR funciona bajo el modelo cliente servidor, para lo cual es necesario contar con un servidor que permita alojar el sistema operativo correspondiente; así mismo las máquinas clientes deben tener un sistema operativo Windows y deben tener habilitado un explorador de internet.
2.1.4 INTERFACES DE SOFTWARE
Las interfaces de software se muestran en la Tabla 1, donde se especifican todos los productos de software requeridos para el desarrollo del producto como: manejadores de
8
base de datos, sistemas operativos, entre otros; y aquellas aplicaciones que interactuaran en el funcionamiento del producto.
Nombre Nemónico Versión Fuente Servicio de consulta de historial crediticio vía VPN INTL 11 Buró de Crédito Servicio de autenticación de personas físicas ID
PROVIDER S/N Buró de Crédito
Microsoft Visual Studio 2008 VS2008 2008 Microsoft Windows Server 2008 R2 WS2008 2008
R2 Microsoft
Microsoft Office con Access S/N 2010 Microsoft Aplicación de gestión de grabaciones S/N S/N Radio Shack Visual Paradigm for UML Profesional Edition VPUML 10.0 Microsoft
Tabla 1. Productos de software requeridos
2.1.5 INTERFACES DE COMUNICACIÓN
La interfaz de comunicación principal de este proyecto se muestra en la Fig.2, la cual describe de forma general las comunicaciones requeridas para la obtención de información.
Fig. 2. Interfaz de comunicación
Es importante recalcar que la operación del sistema es una intranet, con un modelo cliente-‐ servidor.
La comunicación de ABC Leasing -‐Buró de Crédito, se logra a través de una VPN.
El acceso a las bases de datos, se realiza a través del uso de sockets conectados a la IP: 128.9.55.106 y al puerto 35001.
9
2.1.6 RESTRICCIONES DE MEMORIA
Las restricciones de memoria están dadas por los recursos de los servidores, tanto internos como externos, hay requisitos mínimos que un sistema debe tener para poder soportar este tipo de comunicaciones por lo tanto están considerados estos requerimientos y los equipos están sobrados en cuanto a memoria RAM se refiere. 2.1.7 OPERACIONES
Dentro de la información requerida para el funcionamiento de este proyecto se encuentran:
a) Autenticación para el sistema de análisis creditico, usuario y clave correspondiente.
b) Aceptación del prospecto a cliente, vía grabación telefónica, de que sus datos se consultarán ante Buró de Crédito.
c) La información del candidato a cliente que se desea consultar, todos aquellos atributos requeridos para autenticar al cliente y relacionarlo con sus registros.
Adicionalmente a esto para llevar a la operación de consulta y análisis de los datos, es indispensable una conexión a internet, estar dentro de la intranet de ABC Leasing y una conexión VPN que apunte hacia las bases de Buró de Crédito.
2.1.8 REQUERIMIENTOS DE ADAPTACIÓN DEL SITIO
Derivado de la operación del proceso, se requiere un sitio de operación libre de ruido; con el objetivo de conseguir una grabación de calidad.
La instalación del sistema se debe realizar a través de un servidor con las características mencionadas en la sección de interfaces y también crear un ambiente web para la publicación del mismo.
2.2 FUNCIONES GENERALES DEL PRODUCTO
De manera general, el proyecto opera como se describe a continuación:
1. El “Sistema de Análisis Crediticio PROCAAR”, realiza la comunicación y la transferencia de información entre ABC Leasing y Buró de Crédito; entidades las cuales deben convivir para hacer posible este proyecto. En términos técnicos, ABC Leasing deberá consolidar una infraestructura para conectarse por medio de una VPN a las bases de datos de Buró de crédito y obtener la información del prospecto del cliente al cual se desea evaluar su historial crediticio.
10
2. El sistema realiza la lectura, procesamiento y presentación de la información recibida. El proceso mencionado como procesamiento de la información, considera realizar de forma paralela el almacenamiento y análisis de la información, con esto, al final del flujo del proceso, no sólo se obtendrán los datos sino información precisa y objetiva para el analista de crédito de ABC Leasing.
3. Se emite la grabación del cliente que está interesado en adquirir el producto de arrendamiento para poder consultar su historial ante Buró de Crédito, y así determinar si es sujeto a crédito del producto PROCAAR.
Los puntos redactados anteriormente son independientes al proceso de operación, sin embargo a continuación se mencionan, también en un sentido general, pero en orden de procesamiento.
El proceso inicia cuando un prospecto a cliente interesado en PROCAAR llama a ABC Leasing para determinar si es sujeto a crédito de este tipo de producto de arrendamiento o alguno de los promotores del producto, que laboran en ABC Leasing, requieren que se consulte a su cliente a través de este método con el fin de ahorrar tiempo en la operación. Cuando el cliente ya se encuentra en línea telefónica, se le notifica obligatoriamente que su llamada será grabada por fines de requerimientos de Buró de Crédito al realizar este tipo de consultas a sus bases de datos. Enseguida, se captura la información en el Sistema de Análisis Crediticio PROCAAR, misma que es grabada en la base de datos de ABC Leasing y enviada al instante a buró de crédito, vía sockets; Buró de Crédito envía el resultado por la misma vía hacia ABC Leasing; una vez que es recibida la información, el Sistema de Análisis Crediticio PROCAAR hace uso de ella para procesarla, analizarla y emitir un resultado en un archivo paramétrico, dónde a primera vista el usuario del sistema determina y notifica al cliente si es o no candidato a crédito de ABC Leasing. Adicional a esta información, también se emite un reporte detallado del buró de crédito del cliente y de forma general el sistema emite reportes de control de las operaciones realizadas, tanto para ABC Leasing como para Buró de Crédito.
2.3 CARACTERÍSTICAS DEL USUARIO
Los usuarios finales son analistas de crédito y personal operativo calificado con un nivel básico de preparación, no menor a nivel medio superior.
Para la operación del sistema no es necesario años de experiencia en algún rubro en específico; pero si necesario tener conocimientos básicos de computación, así como de la operación general del proceso que se realiza.
11
2.4 RESTRICCIONES
El proyecto debe estar sujeto a las políticas de consulta de información de buró de crédito, por que si una de éstas no se cumple el servicio prestado por esta entidad puede ser cancelado para ABC Leasing, lo cual sería un grave problema al no tener información crediticia referente a los posibles clientes.
Continuamente se deben auditar las grabaciones realizadas, para determinar la integridad y calidad de las mismas.
En cuanto a las restricciones de hardware, se puede mencionar que es necesario que los equipos de comunicaciones sean bastante robustos y soporten el tipo de comunicaciones requeridas. La robustez es importante ya que al aplicar el esquema de comunicaciones entre las entidades no se puede desproteger otro tipo de comunicaciones, considerando que es más vulnerable a posibles ataques informáticos.
2.5 SUPOSICIONES Y DEPENDENCIAS
Se supone un sistema funcional y con alta disponibilidad, que abarque al cien por ciento los requerimientos especificados en este documento; así mismo sea robusto y confiable.
Existen las siguientes dependencias para la realización del proyecto: a) La mayor parte del proyecto depende de la comunicación hacia las bases de datos
de la entidad de Buró de Crédito, por lo tanto el desarrollo del sistema depende necesariamente del conocimiento de la definición y arquitectura de sus estándares, tanto de hardware como de software.
b) El conocimiento del lenguaje de programación, bases de datos, y realización de grabaciones.
c) El conocimiento del modelo de análisis crediticio aplicado a personas físicas con actividad empresarial de PROCAAR.
d) Del tiempo, dedicación y organización de los involucrados en el proyecto. 2.6 FUTUROS REQUERIMIENTOS
En un futuro, el sistema debe incluir una relación, a nivel de registro, del cliente consultado y su grabación emitida al momento de su consulta, con el fin de tener un control de grabaciones.
Adicionalmente, se incluirá un esquema de respaldos automáticos de las grabaciones realizadas.
12
3. REQUERIMIENTOS ESPECÍFICOS
3.1 REQUERIMIENTOS FUNCIONALES
3.1.1 SISTEMA DE GRABACIÓN TELEFÓNICA
ID REQUERIMIENTO RFSGT01 El sistema debe recibir llamadas telefónicas directas, a través del número
018001231414 y a través del número 01 33 35638383 ext. 480. RFSGT02 El sistema debe estar habilitado para realizar grabaciones telefónicas con alta
fidelidad. RFSGT03 El sistema debe interactuar con la computadora para el resguardo de
grabaciones telefónicas.
3.1.2 SISTEMA DE ANÁLISIS CREDITICIO
ID REQUERIMIENTO RFSAC01 El sistema debe solicitar autenticación de usuarios, a través de un usuario y
contraseña válida se podré ingresar. RFSAC02 El sistema debe permitir la captura de los datos personales del cliente y las
respuestas a las preguntas de autenticación de las bases de buró de crédito. RFSAC03 El sistema debe almacenar la información del RFSAC02 en la base de datos de
ABC Leasing. RFSAC04 El sistema debe poder comunicarse con las bases de Buró de Crédito a través de
sockets. RFSAC05 El sistema debe enviar a buró de crédito información de autenticación de la
cuenta que se está conectando así como de las información clave del cliente a consultar su historial crediticio.
RFSAC06 El sistema debe estar habilitado para recibir respuesta por parte de buró de crédito acerca del estatus de la consulta.
RFSAC07 El sistema debe ser capaz de leer la información recibida por parte de buró de crédito.
RFSAC08 El sistema debe almacenar la información leída de las bases de buro de crédito en la base de ABC Leasing.
RFSAC09 El sistema debe procesar la información obtenida de buró de crédito desde la base de datos de ABC Leasing y emitir un análisis crediticio de acuerdo al modelo de crédito utilizado en ABC Leasing para PROCAAR.
RFSAC10 El sistema debe generar un reporte automático con el análisis paramétrico de crédito, del cliente que se ha consultado.
RFSAC11 El sistema debe generar un reporte automático completo de toda la información recibida por buró de crédito, una vez realizada la consulta.
RFSAC12 El sistema debe permitir generar un reporte de control, de acuerdo a un rango de fechas seleccionadas, tomando en cuenta, los estándares de buró de crédito
13
donde se reportan las operaciones consultadas. RFSAC13 El sistema debe permitir generar un reporte de control interno, con la
información referente a las operaciones realizadas en un rango de fechas; según lo diseñe el área de riesgo.
RFSAC14 El sistema debe permitir cambiar la ventana de observación a analizar dentro del análisis automático de crédito que realizará el sistema; entendiéndose por ventana de observación el rango de fechas en que se van a analizar las incidencias de crédito dentro del modelo de análisis.
RFSAC15 El sistema debe permitir dar de alta las claves vigentes para consulta en las bases de buró de crédito.
RFSAC16 El sistema debe informar al usuario sino se logra la autenticación en la base de datos de ABC Leasing.
RFSAC17 El sistema debe informar al usuario si la clave con que intenta ingresar al sistema ha expirado.
RFSAC18 El sistema debe informar al usuario si se ha conectado o no con las bases de datos de buró de crédito.
RFSAC19 El sistema debe informar al usuario si se logró la autenticación del cliente con respecto a los datos proporcionados en la base de autenticación de buró de crédito.
RFSAC20 El sistema debe informar al usuario si existe un error en la consulta de los registros de buró de crédito, esto, una vez autenticado.
RFSAC21 El sistema debe informar al usuario cuando el cliente a consultar no presenta historial crediticio y arrojar el registro que se enviado como evidencia.
RFSAC22 El sistema debe permitir almacenar cualquiera de los reportes generados en la ubicación deseada por el usuario.
RFSAC23 El sistema debe poder ejecutarse desde cualquier máquina dentro de la red de ABC Leasing.
3.2 REQUERIMIENTOS NO FUNCIONALES
Los requerimientos No Funcionales están clasificados por alguno de los siguientes tipos:
1. Requerimiento del producto.
2. Requerimiento organizacional.
3. Requerimiento externo.
4. Atributo de calidad.
Así mismo se distinguirá para qué subsistema aplicará.
1. Sistema de Grabación Telefónica. 2. Sistema de Análisis Crediticio.
14
ID SUBSISTEMA TIPO REQUERIMIENTO JUSTIFICACIÓN RNF01 2 2 Se comunica con buró de
crédito a través de los puertos y protocolos designados por esta entidad.
El servicio de buró de crédito es el utilizado por la empresa para consultar historial crediticio de una persona física.
RNF02 2 4 Debe funcionar de manera óptima.
El sistema debe soportar cualquier posible falla.
RNF03 2 1 El sistema debe estar documentado.
Es necesario tener documentación clara que permita hacer el sistema escalable y entendible para futuros desarrolladores del proyecto.
RNF04 2 1 El sistema debe implementarse bajo la infraestructura con que cuenta ABC Leasing.
Es un sistema innovador en donde una de las factibilidades por la cuales se realiza el proyecto, es el costo menor al actual, por lo tanto este requerimiento es esencial.
RNF05 2 1 Debe ser accesible por cualquier máquina cliente desde la intranet de ABC Leasing.
La operación del sistema debe ser realizada por cualquier analista de riesgo, dentro de ABC Leasing.
RNF06 1 1 Debe soportar grabación de llamadas en formato mp3.
El formato mp3, es solicitado por buró de crédito para las grabaciones realizadas.
RNF07 1 1 Debe soportar por lo menos tres llamadas concurrentes.
Por ser un producto abierto al público se requiere soportar este tipo de llamadas, para atender a los clientes.
RNF08 1 1 Debe soportar almacenamiento de por lo menos 30 minutos.
Esto para asegurar que una llamada puede extenderse y ser grabada sin problema
RNF09 2 1 Debe tener seguridad, sólo puede ingresar el personal de riesgo que cuente con las claves de autenticación válidas.
Sólo los analistas de riesgo pueden consultar el historial crediticio de los prospectos a clientes de ABC Leasing.
15
APÉNDICE
En este apartado se presentan una serie de diagramas realizados bajo el estándar del Lenguaje Unificado de Modelado (UML), los cuales se han utilizado como guía del presente documento.
DIAGRAMAS DE CASOS DE USO
SISTEMA DE ANÁLISIS CREDITICIO
La fig. 5.x representa de forma general el Sistema de Análisis crediticio de PROCAAR a través del diagrama de casos de uso.
Fig. 5.x. Diagrama de Casos de Uso del Sistema de Análisis Crediticio para PROCAAR
16
SISTEMA DE GRABACIÓN TELEFÓNICA
La fig. 9.x.y representa de forma general el Sistema de Grabación de Telefónica a través del diagrama de casos de uso.
Fig. 9.x.y Diagrama de Casos de Uso del Sistema de Grabación Telefónica
DOCUMENTACIÓN DE CASOS DE USO
SISTEMA DE ANÁLISIS CREDITICIO
Gestionar solicitud de crédito
Nombre Valor
Nombre Gestionar solicitud de crédito
Categoría Primario
Actores Analista de Riesgo
17
Flujo de Eventos
1.Autenticarse en el sistema
2. if Datos correctos
2.1. SYSTEM Mostrar Ventana de Aceptación de Consulta
3. else
3.1. SYSTEM Mostrar Error de Inicio de Sesión
end if
4.Aceptar la consulta a realizar
5. SYSTEM Mostrar Ventana de Solicitud de Crédito
6.Capturar los datos proporcionados por el cliente
7. if Datos obligatorios incompletos
7.1. SYSTEM Mensaje de error, proporcionar datos correctos
end if
8.Guardar datos de la solicitud
9. SYSTEM Datos almacenados correctamente
Detalles
Nombre Valor
Complejidad Media
Estado de Implementación Completa
Preconditiones Recibir una llamada de solicitud de crédito para PROCAAR
Post-‐conditiones Se tiene almacenada una solicitud de crédito para PROCAAR
Autor Alejandra Alcalá
Fig. 6.x. Documentación Caso de Uso Gestionar solicitud de crédito
18
Consultar información de clientes
Nombre Valor
Nombre Consultar información de clientes
Categoría Primario
Actores Buró de Crédito
Flujo de Eventos
1.Estar en espera de conexión
2. SYSTEM Solicitar conexión [IP, Puerto]
3.Establecer conexión
4. SYSTEM Enviar cadena de autenticación
5.Validar cadena de autenticación
6. if Datos Correctos
6.1.Procesar consulta de datos
7. else
7.1.Enviar error de autenticación
end if
8.Enviar datos de consulta
9. while No sea fin de archivo
9.1.Leer datos consultados
9.2.Almacenar datos consultados
end while
10. SYSTEM Cerrar conexión
Detalles
Nombre Valor
Complejidad Alta
Estado de Implementación Completo
Preconditiones Gestionar solicitud de crédito
19
Post-‐conditiones Se tiene información crediticia del cliente de las bases de datos de Buró de Crédito
Autor Alejandra Alcalá
Fig. 7.x. Documentación Caso de Uso Consultar información de clientes
Procesar información de clientes
Nombre Valor
Nombre Procesar información de clientes
Categoría Primario
Actores Analista de Riesgo
Flujo de Eventos
1.Solicitar análisis de crédito
2. SYSTEM Obtener información consultada
3. SYSTEM Analizar Información obtenida
4. SYSTEM Solicitar guardar análisis
5.Generar reporte de buró de crédito
6. SYSTEM Enviar reporte de buró de crédito
Detalles
Nombre Valor
Complejidad Alta
Estatus de Implementación Completa
Preconditiones Consultar información de clientes
Post-‐conditiones Se tiene un reporte de análisis paramétrico y un reporte de buró de crédito
Autor Alejandra Alcalá
Fig. 8.x. Documentación Caso de Uso Consultar información de clientes
20
SISTEMA DE GRABACIÓN TELEFÓNICA
Gestionar llamada telefónica
Nombre Valor
Nombre Gestionar llamada telefónica
Categoría Primario
Actores Analista de Crédito, Solicitante
Flujo de Eventos
1. Solicitante Realizar llamada telefónica
2. Analista de Crédito Responde la llamada
3. Solicitante Requiere un crédito automotriz
4. Analista de Crédito Valida que el Solicitante sea apto para PROCAAR
5. if Solicitante es apto para PROCAAR
5.1. Analista de Crédito Indica al Solicitante que va a ser grabado
5.2. SYSTEM Realiza grabación
5.3.Fin de grabación de llamada telefónica
end if
6.Fin de llamada telefónica
Detalles
Nombre Valor
Complejidad Baja
Estado de Implementación Completa
Preconditions Debe existir una línea telefónica para soporte de llamadas telefónicas
Author Alejandra Alcalá
Fig. 8.x.y Documentación Caso de Uso Gestionar Llamada Telefónica
21
DIAGRAMA E-‐R
Fig. 9.x. Extracto del diagrama E-‐R
22
DIAGRAMAS DE SECUENCIA
SISTEMA DE ANÁLISIS CREDITICIO
Fig. 10.x. Diagrama de Secuencia Gestionar solicitud de crédito
23
Fig. 11.x. Diagrama de Secuencia Consultar información de clientes
24
Fig. 12.x. Diagrama de Secuencia Procesar información de clientes
25
SISTEMA DE GRABACIÓN TELEFÓNICA
Fig. 12.x.y Diagrama de Secuencia Gestionar llamada telefónica
26
DIAGRAMAS DE ACTIVIDADES
SISTEMA DE ANÁLISIS CREDITICIO
Fig. 13.x. Diagrama de Actividades con Calles del Sistema de Análisis Crediticio para PROCAAR
27
SISTEMA DE GRABACIÓN TELEFÓNICA
Fig. 13.x.y Diagrama de Actividades del Sistema de Grabación Telefónica
28
DIAGRAMA DE COMPONENTES
Fig. 14.x. Diagrama de Componentes del Sistema de Análisis Crediticio para PROCAAR
29
PLAN DE PRUEBAS
En el plan de pruebas se distinguirá para qué sistema aplicarán los casos de prueba.
1. Sistema de Grabación Telefónica. 2. Sistema de Análisis Crediticio.
Número Sistema Objetivo Descripción Condiciones de prueba
Resultado esperado
1 1 Verificar que las claves de autenticación son válidas.
Se comprobará que el sistema sólo permite ingresar a través de las claves vigentes de buró de crédito.
Ingresar con un usuario inexistente, ingresar con un usuario y/o contraseña no válidos, ingresar con una clave y contraseña no vigentes.
Sólo ingresa el usuario y contraseña vigentes, si se proporciona uno inexistente o no vigente, enviar mensaje de error.
2 1 Verificar que los datos ingresados en la solicitud son válidos.
Se debe comprobar que el dominio de los datos ingresados cumple con los requisitos establecidos.
Se deben probar los campos ingresando tipos de datos no permitidos, incorrectos, los cuales no pueden ser capturados desde inicio.
No permitir el ingreso de datos no permitidos al momento de la captura de datos en la solicitud de crédito.
3 1 Verificar que todos los datos obligatorios se han completado.
Comprobación referente a cubrir todos los datos obligatorios al llenar una solicitud de crédito.
Se deberán ingresar todos los datos obligatorios de la solicitud; así mismo en otra
Si se ingresan todos los datos obligatorios guardar correctamente el registro, sino enviar mensaje
30
instancia omitir alguno de los valores obligatorios.
explícito de error.
4 1 Probar la conexión a las bases de datos de buró de crédito.
Para obtener la información de buró de crédito se debe crear una conexión a través de sockets.
Hacer pruebas externas al sistema para validar la conexión a través de la IP y puerto designado por buró de crédito.
Recibir un mensaje de conexión aceptada por parte de las bases de buró de crédito.
5 1 Probar la autenticación en las bases de buró de crédito.
Verificar que los parámetros enviados en la cadena de conexión son correctos.
Enviar una cadena con los datos de autenticación a la base de pruebas.
Obtener una cadena con los datos del registro que se ha consultado.
6 1 Verificar el envío y respuesta de datos a buró de crédito.
El paso de información es a través de cadenas de texto, por lo tanto se debe probar el envío y recepción.
Enviar diferentes cadenas de prueba.
Recibir cadenas de respuesta válidas.
7 1 Verificar el almacenamiento de datos en las bases de ABC Leasing.
Revisar que una vez que se ha obtenido información por parte de buró de crédito, el sistema procesa los datos correctamente.
Procesar la cadena recibida e interpretarla correctamente para ser almacenada en la base de datos de ABC Leasing.
Tener un registro almacenado correctamente en la base de datos de ABC Leasing.
8 1 Validar el análisis crediticio.
Revisar que los parámetros con los que se realiza
En base a un registro obtenido,
Tener un análisis crediticio
31
el análisis hayan sido aplicados correctamente.
generar un análisis crediticio de forma manual y compararlo con el obtenido por el sistema.
correcto del registro de prueba.
9 1 Verificar la emisión del análisis paramétrico.
El reporte paramétrico debe generarse por el sistema con opción a ser guardado en cualquier ubicación.
Emitir un reporte paramétrico de un registro determinado.
Obtener un reporte paramétrico válido.
10 1 Validar la emisión correcta del reporte de buró de crédito.
El reporte de buró de crédito debe generarse por el sistema con opción a ser guardado en cualquier ubicación.
Emitir un reporte de buró de crédito de un registro determinado.
Obtener un reporte de buró de crédito válido.
11 1 Validar mensajes de error por falta de historial crediticio.
Cuando un cliente no cuenta con historial crediticio emitir un mensaje informativo.
Ingresar una solicitud de un cliente sin historial crediticio.
Mensaje de información de error, por falta de historial crediticio del registro consultado.
12 1 Validar mensajes de error por inexistencia de la información enviada.
Cuando se consulta información de un registro inexistente no se procesa la consulta.
Ingresar datos inexistentes en una solicitud.
Mensaje de error por registro consultado inexistente.
13 2 Verificar la grabación de llamada
Se debe realizar una grabación telefónica de la
Realizar una llamada y simular la
Tener una grabación de la llamada
32
telefónica. llamada recibida grabación de la llamada.
realizada.
14 2 Validar el proceso de llamadas concurrentes.
Se debe poder recibir llamadas simultáneas por lo menos de tres prospectos a clientes.
Realizar llamadas concurrentes al centro de atención telefónica.
Tener tres llamadas a la vez y procesarlas correctamente
15 2 Validar el paso de información del sistema de grabación a otro dispositivo de almacenamiento.
Se debe almacenar las llamadas telefónicas en otro dispositivo de almacenamiento para usos posteriores.
Obtener llamada telefónica del equipo de grabación y guardarla en otro dispositivo de almacenamiento.
Tener una grabación alterna de la grabación realizada.
16 2 Validar la calidad de la grabación.
La grabación debe ser de calidad para ser escuchada e interpretada en cualquier momento.
Reproducirla grabación y ser interpretada
Tener una grabación de calidad.
33
ÍNDICE
Introducción..........................................................................................................................1
Propósito del documento de requerimientos……............................................................1
Alcances del documento..................................................................................................1
Definiciones, acrónimos y abreviaturas..........................................................................1
Referencias......................................................................................................................3
Panorama general del documento..................................................................................3
Descripción general..............................................................................................................4
Perspectiva del Producto.................................................................................................4
Interfaces del sistema...............................................................................................4
Interfaces de usuario................................................................................................4
Interfaces de hardware............................................................................................7
Interfaces de software.............................................................................................7
Interfaces de comunicación.....................................................................................8
Restricciones de memoria.......................................................................................9
Operaciones.............................................................................................................9
Requerimientos de adaptación del sitio..................................................................9
Funciones generales del producto......................................................................................9
Características del usuario...........................................................................................10
Restricciones................................................................................................................11
Suposiciones y dependencias.......................................................................................11
Futuros requerimientos................................................................................................11
Requerimientos específicos..............................................................................................12
Requerimientos Funcionales........................................................................................12
Requerimientos No funcionales..................................................................................13
Apéndices.........................................................................................................................15
Diagramas de Casos de Uso.........................................................................................15
Documentación de Casos de Uso................................................................................16
Diagrama de E-‐R..........................................................................................................21
34
Diagrama de Secuencia...............................................................................................22
Diagramas de Estado...................................................................................................26
Diagrama de Actividades.............................................................................................26
Diagrama de Componentes.........................................................................................28
Plan de Pruebas...........................................................................................................29