Documento - Maestría en Tecnologías de Información

Documento - Maestría en Tecnologías de Información

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. 1 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 2 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. 1 Publicación Autor 1998 IEEE 2 Título IEEE Recommended Practice for Software Requirements Specifications, Std. 830-­‐1998 Programa de Crédito Automotriz en Arrendamiento 3 4 A Credit Scoring Decision Support System El Lenguaje de Modelado Unificado 2011 2005 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 2010 -­‐ -­‐ -­‐ -­‐ ABC Leasing Dukic Booch, Jacobson -­‐ -­‐ -­‐ -­‐ 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 3 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 4 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 5 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 6 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 7 base de datos, sistemas operativos, entre otros; y aquellas aplicaciones que interactuaran en el funcionamiento del producto. Nombre Nemónico Versión Servicio de consulta de historial crediticio vía VPN INTL 11 Servicio de autenticación de personas físicas ID S/N PROVIDER Microsoft Visual Studio 2008 VS2008 2008 Windows Server 2008 R2 WS2008 2008 R2 Microsoft Office con Access S/N 2010 Aplicación de gestión de grabaciones S/N S/N Visual Paradigm for UML Profesional Edition VPUML 10.0 Tabla 1. Productos de software requeridos Fuente Buró de Crédito Buró de Crédito Microsoft Microsoft Microsoft Radio Shack Microsoft 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. 8 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. 9 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. 10 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. 11 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 12 RFSAC13 RFSAC14 RFSAC15 RFSAC16 RFSAC17 RFSAC18 RFSAC19 RFSAC20 RFSAC21 RFSAC22 RFSAC23 donde se reportan las operaciones consultadas. 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. 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. El sistema debe permitir dar de alta las claves vigentes para consulta en las bases de buró de crédito. El sistema debe informar al usuario sino se logra la autenticación en la base de datos de ABC Leasing. El sistema debe informar al usuario si la clave con que intenta ingresar al sistema ha expirado. El sistema debe informar al usuario si se ha conectado o no con las bases de datos de buró de crédito. 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. 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. El sistema debe informar al usuario cuando el cliente a consultar no presenta historial crediticio y arrojar el registro que se enviado como evidencia. El sistema debe permitir almacenar cualquiera de los reportes generados en la ubicación deseada por el usuario. 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. 13 ID SUBSISTEMA RNF01 2 TIPO 2 RNF02 2 4 RNF03 2 1 RNF04 2 1 RNF05 2 1 RNF06 1 1 RNF07 1 1 RNF08 1 1 RNF09 2 1 REQUERIMIENTO Se comunica con buró de crédito a través de los puertos y protocolos designados por esta entidad. Debe funcionar de manera óptima. El sistema debe estar documentado. JUSTIFICACIÓN El servicio de buró de crédito es el utilizado por la empresa para consultar historial crediticio de una persona física. El sistema debe soportar cualquier posible falla. Es necesario tener documentación clara que permita hacer el sistema escalable y entendible para futuros desarrolladores del proyecto. El sistema debe Es un sistema innovador en implementarse bajo la donde una de las infraestructura con que factibilidades por la cuales se cuenta ABC Leasing. realiza el proyecto, es el costo menor al actual, por lo tanto este requerimiento es esencial. Debe ser accesible por La operación del sistema cualquier máquina cliente debe ser realizada por desde la intranet de ABC cualquier analista de riesgo, Leasing. dentro de ABC Leasing. Debe soportar grabación de El formato mp3, es solicitado llamadas en formato mp3. por buró de crédito para las grabaciones realizadas. Debe soportar por lo Por ser un producto abierto menos tres llamadas al público se requiere concurrentes. soportar este tipo de llamadas, para atender a los clientes. Debe soportar Esto para asegurar que una almacenamiento de por lo llamada puede extenderse y menos 30 minutos. ser grabada sin problema Debe tener seguridad, sólo Sólo los analistas de riesgo puede ingresar el personal pueden consultar el historial de riesgo que cuente con crediticio de los prospectos a las claves de autenticación clientes de ABC Leasing. válidas. 14 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 15 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 Nombre Valor Gestionar solicitud de crédito Categoría Primario Actores Analista de Riesgo 16 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 17 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 18 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 19 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 5. if Solicitante sea apto para PROCAAR 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 20 DIAGRAMA E-­‐R Fig. 9.x. Extracto del diagrama E-­‐R 21 DIAGRAMAS DE SECUENCIA SISTEMA DE ANÁLISIS CREDITICIO Fig. 10.x. Diagrama de Secuencia Gestionar solicitud de crédito 22 Fig. 11.x. Diagrama de Secuencia Consultar información de clientes 23 Fig. 12.x. Diagrama de Secuencia Procesar información de clientes 24 SISTEMA DE GRABACIÓN TELEFÓNICA Fig. 12.x.y Diagrama de Secuencia Gestionar llamada telefónica 25 DIAGRAMAS DE ACTIVIDADES SISTEMA DE ANÁLISIS CREDITICIO Fig. 13.x. Diagrama de Actividades con Calles del Sistema de Análisis Crediticio para PROCAAR 26 SISTEMA DE GRABACIÓN TELEFÓNICA Fig. 13.x.y Diagrama de Actividades del Sistema de Grabación Telefónica 27 DIAGRAMA DE COMPONENTES Fig. 14.x. Diagrama de Componentes del Sistema de Análisis Crediticio para PROCAAR 28 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 1 1 2 1 3 1 Descripción Condiciones de prueba Verificar que las Se comprobará Ingresar con claves de que el sistema un usuario autenticación son sólo permite inexistente, válidas. ingresar a través ingresar con de las claves un usuario vigentes de buró y/o de crédito. contraseña no válidos, ingresar con una clave y contraseña no vigentes. Verificar que los Se debe Se deben datos ingresados comprobar que el probar los en la solicitud son dominio de los campos válidos. datos ingresados ingresando cumple con los tipos de requisitos datos no establecidos. permitidos, incorrectos, los cuales no pueden ser capturados desde inicio. Verificar que Comprobación Se deberán todos los datos referente a cubrir ingresar obligatorios se todos los datos todos los han completado. obligatorios al datos llenar una obligatorios solicitud de de la crédito. solicitud; así mismo en otra Resultado esperado Sólo ingresa el usuario y contraseña vigentes, si se proporciona uno inexistente o no vigente, enviar mensaje de error. No permitir el ingreso de datos no permitidos al momento de la captura de datos en la solicitud de crédito. Si se ingresan todos los datos obligatorios guardar correctamente el registro, sino enviar mensaje 29 4 1 5 1 6 1 7 1 8 1 instancia omitir alguno de los valores obligatorios. Probar la Para obtener la Hacer conexión a las información de pruebas bases de datos de buró de crédito externas al buró de crédito. se debe crear una sistema conexión a través para validar de sockets. la conexión a través de la IP y puerto designado por buró de crédito. Probar la Verificar que los Enviar una autenticación en parámetros cadena con las bases de buró enviados en la los datos de de crédito. cadena de autenticació
conexión son n a la base correctos. de pruebas. Verificar el envío y El paso de Enviar respuesta de información es a diferentes datos a buró de través de cadenas cadenas de crédito. de texto, por lo prueba. tanto se debe probar el envío y recepción. Verificar el Revisar que una Procesar la almacenamiento vez que se ha cadena de datos en las obtenido recibida e bases de ABC información por interpretarl
Leasing. parte de buró de a crédito, el correctame
sistema procesa nte para ser los datos almacenada correctamente. en la base de datos de ABC Leasing. Validar el análisis Revisar que los En base a un crediticio. parámetros con registro los que se realiza obtenido, explícito de error. Recibir un mensaje de conexión aceptada por parte de las bases de buró de crédito. Obtener una cadena con los datos del registro que se ha consultado. Recibir cadenas de respuesta válidas. Tener un registro almacenado correctamente en la base de datos de ABC Leasing. Tener un análisis crediticio 30 el análisis hayan sido aplicados correctamente. generar un análisis crediticio de forma manual y compararlo con el obtenido por el sistema. Verificar la El reporte Emitir un emisión del paramétrico debe reporte análisis generarse por el paramétrico paramétrico. sistema con de un opción a ser registro guardado en determinad
cualquier o. ubicación. Validar la emisión El reporte de Emitir un correcta del buró de crédito reporte de reporte de buró debe generarse buró de de crédito. por el sistema crédito de con opción a ser un registro guardado en determinad
cualquier o. ubicación. Validar mensajes Cuando un cliente Ingresar una de error por falta no cuenta con solicitud de de historial historial crediticio un cliente crediticio. emitir un mensaje sin historial informativo. crediticio. 9 1 10 1 11 1 12 1 Validar mensajes de error por inexistencia de la información enviada. 13 2 Verificar la grabación de llamada Cuando se consulta información de un registro inexistente no se procesa la consulta. Se debe realizar una grabación telefónica de la correcto del registro de prueba. Obtener un reporte paramétrico válido. Obtener un reporte de buró de crédito válido. Mensaje de información de error, por falta de historial crediticio del registro consultado. Ingresar Mensaje de datos error por inexistentes registro en una consultado solicitud. inexistente. Realizar una Tener una llamada y grabación de simular la la llamada 31 telefónica. 14 2 15 2 16 2 llamada recibida Validar el proceso Se debe poder de llamadas recibir llamadas concurrentes. simultáneas por lo menos de tres prospectos a clientes. Validar el paso de Se debe información del almacenar las sistema de llamadas grabación a otro telefónicas en dispositivo de otro dispositivo almacenamiento. de almacenamiento para usos posteriores. Validar la calidad de la grabación. La grabación debe ser de calidad para ser escuchada e interpretada en cualquier momento. grabación de la llamada. Realizar llamadas concurrente
s al centro de atención telefónica. Obtener llamada telefónica del equipo de grabación y guardarla en otro dispositivo de almacenami
ento. Reproducirl
a grabación y ser interpretada realizada. Tener tres llamadas a la vez y procesarlas correctamente Tener una grabación alterna de la grabación realizada. Tener una grabación de calidad. 32 Í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 33 Diagrama de Secuencia...............................................................................................22 Diagramas de Estado...................................................................................................26 Diagrama de Actividades.............................................................................................26 Diagrama de Componentes.........................................................................................28 Plan de Pruebas...........................................................................................................29 34