UNIVERSIDAD DE GUAYAQUIL -...

UNIVERSIDAD DE GUAYAQUIL

Facultad de Ciencias Matemáticas y Físicas

Carrera de Ingeniería en Sistemas

Computacionales

“Desarrollo de una Aplicación Móvil para las Inspecciones de

Créditos de Nuestros Clientes que Permita Minimizar el Tiempo

de Respuesta para las Aprobaciones”.

TESIS DE GRADO

Previo a la Obtención del Título de:

INGENIERO EN SISTEMAS COMPUTACIONALES

Autor(es):

Jorge Johan García Mendoza.

Natalie Priscila Rivera Ríos.

Jean Xavier Calvache.

GUAYAQUIL-ECUADOR

Año: 2007

AGRADECIMIENTO

A Dios, a nuestros Padres y a todas las

personas que han sido parte de nuestra

formación profesional.

DEDICATORIA

Dedicamos este trabajo a nuestros compañeros

de Carrera que actualmente se están forjando

para mejorar sus condiciones de vida y poder

ser un gran complemento en nuestra sociedad.

TRIBUNAL DE GRADUACIÓN

DECLARACIÓN EXPRESA

“La autoría de la tesis de grado corresponde exclusivamente al suscrito(s),

perteneciendo a la Universidad de Guayaquil los derechos que generen la

aplicación de la misma”

(Reglamento de Graduación de la Carrera de Ingeniería en sistemas

Computacionales, Art. 26)

RESUMEN

Esta Aplicación surge como producto de un mal servicio y la pérdida de

clientes por parte de la empresa, a causa de que los préstamos no se dan en

el tiempo en que se los ofrece. Actualmente se cuenta con un ingreso de 500

solicitudes diarias a nivel nacional por lo que las inspecciones o validaciones

de los datos no se dan en el tiempo ofrecido, estimamos que con la

herramienta de Inspección podremos mejorar la calidad, rapidez y una mejor

organización ya que al no contar con un buen manejo de Créditos en donde

se existen problemas con los tiempos, la Aplicación Móvil de Inspección es

desarrollada para mejorar los tiempos de respuestas de nuestros créditos y

para poder tener un apoyo de decisiones más eficiente. Esta aplicación fue

desarrollada en Pocket Builder, esta orientada a Eventos la misma que se

ejecuta en equipos Pocket HP, la aplicación conjuntamente trabaja con SQL

Anywhere ASA (Adaptive Server Anywhere) como el gestor de la base de

datos. Para el desarrollo hemos considerado los reportes que serán

revisados por los supervisores de créditos como también los ingresos de

datos que validarán la información que se encuentra en la Pocket contra la

información que el Inspector ingresa.

INSPECCIÓN MOVIL CREDITO FÁCIL

INDICE GENERAL AGRADECIMIENTO II

DEDICATORIA III

TRIBUNAL DE GRADUACIÓN IV

DECLARACIÓN EXPRESA V

RESUMEN VI

INDICE GENERAL VII

CAPITULO 1

INTRODUCCIÓN 12

1.1 INTRODUCCIÓN……………………………………………………….15

1.2 ANTECEDENTE. ................................................................................. 16

1.3 PROCESOS INVOLUCRADOS. .............................................................. 17

1.4 PLANTEAMIENTO DE PROBLEMA. ........................................................ 19

1.5 FORMULACIÓN Y SISTEMATIZACIÓN DEL PROBLEMA. ............................. 19

1.5.1 FORMULACIÓN DEL PROBLEMA. .............................................. 19

1.6 CONTROL A PRONÓSTICO. ................................................................. 20

1.7 SISTEMATIZACIÓN DEL PROBLEMA. ...................................................... 21

1.8 OBJETIVO GENERAL .......................................................................... 21

1.9 OBJETIVOS ESPECÍFICOS ................................................................... 21

1.10 ALCANCES ........................................................................................ 22

1.11 APORTES ......................................................................................... 27

1.12 LIMITES ............................................................................................ 28

1.13 JUSTIFICACIÓN DEL PROYECTO ........................................................... 28

1.14 FACTIBILIDADES DEL PROYECTO. ....................................................... 29

1.14.1 OPERACIONAL ................................................................... 29

1.14.2 TÉCNICA. .......................................................................... 30

1.14.3 ECONÓMICA ...................................................................... 31

CAPITULO 2

ANÁLISIS DE SISTEMAS ................................................................................ 32

2.1 ANÁLISIS DE REQUERIMIENTOS .............................................................. 33

2.2 SOLUCIONES. ....................................................................................... 33

2.3 SEGURIDAD ............................................................................................ 34

2.4 INGRESO DE SOLICITUDES ...................................................................... 34

2.5 MANEJO DE VISITAS. .............................................................................. 34

2.6 GESTIÓN DE RUTAS. ............................................................................... 35

2.7 MODELO DE INSPECCIÓN........................................................................ 35

2.8 ANÁLISIS DEL ÁREA OPERACIONAL. ........................................................ 36

2. 9 ANÁLISIS ORGANIZACIONAL. ................................................................... 37

2.10 GENERACIÓN DE REPORTES ................................................................. 37

2.11 IDENTIFICACIÓN DE LOS ACTORES. ........................................................ 38

2.12 DESCRIPCIÓN DE LOS ACTORES. ........................................................... 38

2.12.1 ADMINISTRADOR DEL SISTEMA. ................................................. 38

2.12.2 USUARIO EJECUTIVO DE CRÉDITO. ............................................ 38

2.12.3 SUPERVISOR DEPARTAMENTO DE INSPECCIONES ...................... 39

2.12.4 INSPECTORES ........................................................................... 39

2.13 IDENTIFICACIÓN DE CASOS DE USO. ...................................................... 39

2.14 DIAGRAMA GENERAL DE CASOS DE USO. ............................................... 40

CAPITULO 3

DISEÑO DE SISTEMAS ............................................................................... 43

3.1 DISEÑO DE DATOS ................................................................................. 44

3.2 DISEÑO ARQUITECTÓNICO...................................................................... 50

CAPITULO 4

PRUEBAS DEL SISTEMA ................................................................................... 49

4.1 MODELO PARA LA GENERACIÓN DE PRUEBAS.......................................... 52

4.2 PRUEBAS DE UNIDAD ............................................................................. 53

4.3 VERIFICACIÓN Y VALIDACIÓN .................................................................. 54

4.4 PRUEBAS ALFA Y BETA ........................................................................... 54

4.5 PRUEBAS DE PROCESOS Y FUNCIONAMIENTO CRITICO ............................ 55

4.5.1 MÓDULO DE SEGURIDAD…………………………………….…………54

4.5.2 MÓDULO DE INSPECCIÓN……………………………….……………...57

4.6 CALIDAD DEL SISTEMA…………………………………….……………….….60

INDICE DE GRÁFICOS

Pág.

Gráfico 1 Formulario de solicitud de crédito 21

Gráfico 2 Clientes asignados 22

Gráfico 3 Reporte de visitas 22

Gráfico 4 Datos personales 23

Gráfico 5 Bienes 23

Gráfico 6 Gastos 23

Gráfico 7 Ruta de clientes 24

Gráfico 8 Ingreso al sistema 25

Gráfico 9 Clientes inspeccionados 25

Gráfico 10 Caso de uso de usuario solicitante 39

Gráfico 11 Caso de uso de supervisor 40

Gráfico 12 Caso de uso de inspector 41

Gráfico 13 Diagrama de flujo de datos 46

Gráfico 14 D.F.D. nivel 0 46




Gráfico 18 Flujo de transformación 50

Gráfico 19 Generación de pruebas 52

Gráfico 20 Información de usuario 56

Gráfico 21 Usuario correcto 56

Gráfico 22 Menú principal 57

Gráfico 23 Sin autorización 57

Gráfico 24 Clientes a inspeccionar 58

Gráfico 25 Inspección – Datos personales 59

Gráfico 26 Inspección – Bienes 59

Gráfico 27 Inspección – Gastos 60

Gráfico 28 Error – Faltan datos requeridos 60

Gráfico 29 Cliente inspeccionado 61

CAPITULO 1 INTRODUCCIÓN

1.1 Introducción

Los Créditos Rápidos o Créditos en 24 horas se han convertido hoy en día en

uno de los productos financieros de más auge y a los que está recurriendo

cada vez un mayor número de personas.

Por regla general, estos créditos rápidos son vistos por los clientes como una

salida rápida a problemas de "aprietos de dinero" o de falta de efectivo en

determinados momentos del año: hipotecas que empieza a asfixiar, tarjetas

de créditos que han llegado a su límite, letras de automóviles que se pagan

con dificultad, problemas para salir de vacaciones en verano o algún

imprevisto como averías irreparables de un electrodoméstico con los

principales motivos que llevan a los clientes de los establecimientos

financieros y ahora incluso de las entidades bancarias a solicitar estos

créditos rápidos o créditos en 24 horas. La finalidad, hacer frente a un

imprevisto económico y necesidad de obtener el dinero rápidamente.

El perfil habitual del cliente que solicita un crédito en 24 horas o un crédito

rápido suele ser el de una persona entre 24 y 40 años con unos ingresos

familiares entre 300 a 1500 dólares mensuales, seguramente es este sector

de la población el que más recurre a los créditos en 24 horas por encontrarse

en el sector de edad en el que más se ha notado la disminución del poder

adquisitivo en nuestro país.

Este proceso administración de crédito busca en toda y cada una de sus

etapas cuantificar el riesgo que involucra una operación financiera y, a la vez,

determinar la viabilidad que representa esta colocación para la empresa

prestamista.

1.2 Antecedente.

Es importante mencionar que actualmente los empleados dedican más

tiempos a los desplazamientos, por lo que las soluciones móviles se

convierten en herramientas comerciales fundamentales, es por eso que

hemos visto como eje fundamental un Sistema Móvil de Inspecciones para

incrementar la productividad del empleado y racionalizar los procesos

comerciales.

El proyecto que estamos presentando en un Sistema Móvil de Inspección

Genérico, ya que en nuestro proyecto no contamos con un modelo de

procesos específicos para una empresa base, hemos realizado

investigaciones a empresas que se dedican al negocio de los créditos, las

misma nos han solicitado que no se mencione los nombres por políticas

internas que manejan, llamaremos para nuestro proyecto a la Empresa de

Créditos como “Su Crédito”.

Su Crédito esta elaborando un estudio para mejorar los tiempos de

respuestas en la aprobación de créditos para sus prestamistas, la actividad

consistió en identificar los cuellos de botellas que se tienen en el proceso.

Los datos y la documentación que son ingresados son administrados a

nuestra base de datos una vez que se realiza una precalificación se procede

a enviar al departamento de inspección en donde hemos validado que esta

actividad, toma mayor tiempo a la inspección promedio normal de de 48

horas hábiles.

El área de proyectos ha pensado en crear centros de recopilación de

información para que se pueda centralizar los datos hacia la sucursal

principal, también se ha pensado en contratar a más recursos humanos para

que las inspecciones sean en menor, esto va de la mano con personal con

cargos de supervisores que realizaran la organización de rutas para el

personal de inspección.

El levantamiento de información nos indica que actualmente existen 10

personas que trabajan directamente en las inspecciones de información y 5

personas de forma indirecta que manejan el procesamiento de información,

digitación, guías de rutas,

1.3 Procesos Involucrados.

Una vez que el cliente tiene el interés en aplicar créditos con nosotros se

procede a asesorar al cliente, para realizar un levantamiento previo de

información para detectar posibles fallos de pagos en el futuro, ya que la

recuperación de la cartera dependerá mucho del trabajo que se realice en la

asesoría y en la parte operativa de la misma, el cliente procede a llenar la

solicitud con sus datos personales y con información necesaria para

gestionar el crédito, una vez que se realice el ingreso de la solicitud se

procede a realizar las validaciones previas telefónica, la información que se

valida a través de los inspectores es la siguiente:

Dirección Exacta, Verificación de la Condición de Vida del Prestamista,

Confirmación de Propiedad etc. Es importante mencionar que los datos o las

personas que son contactadas por seguridad se les comunica

telefónicamente, el inspector debe confirmar la información proporcionada en

la solicitud, con una persona en el domicilio o residencia del prestamista

confirmando su nombre a través de una identificación, si se presentara

alguna duda con respecto a información critica se tomaran como

observaciones valiosas para determinar el crédito. Ya terminada con la

inspección se procede a realizar el reporte el mismo que tendrá que

entregarse al finalizar el día. El proceso termina cuando se realizan las

evaluaciones tanto de inspección en sitio como la telefónica. El departamento

de Aprobación Final determinará el monto aprobado.

1.4 Planteamiento de Problema.

Situación Actual: Causas y Síntomas.

La empresa de Créditos (Su Crédito) en el Análisis de sus Operaciones,

presenta un descenso en el volumen de clientes que ingresan solicitud para

acceder a un Crédito como consecuencia de que el Producto de Créditos

Rápidos de 24 0 48 horas, ha tenido retrasos y los clientes han obtenido el

crédito bastante insatisfechos ya que el tiempo ofrecido no es el que

proponen. Adicional a esto en la parte operativo mucho de estos procesos no

están documentados y se cuenta con problemas ya que la desorganización

causa de que el personal de inspección no cuente con una gestión de ruta

que permita minimizar el tiempo de las visitas y de la toma de información.

Por otro lado en el mercado aparecen empresas competidoras que ofrecen

productos similares.

1.5 Formulación y Sistematización del Problema.

1.5.1 Formulación del Problema.

¿De que forma los aspectos de organización interna y del entorno han

afectado los rendimientos y utilidades en la operación de la empresa de

Créditos?

Pronósticos

Las Circunstancias anteriormente descrita pueden llevar a la empresa a

desaprovechar las oportunidades que brinda el análisis de patrones de

comportamiento y manejo de datos estadísticos, así como también impide

desarrollar una estrategia que permita desarrollar una solución que organice,

administre y tenga una automatización de proceso en la parte operativa, este

proceso se debe instituir como un ambiente en el cual el manejo del

conocimiento sea parte del diario vivir de los miembros de la organización

creando estrategias basadas en análisis de información. La falta de dicha

estrategias pudiera llevar a que las decisiones se tomen sobre datos

estimados e inclusive información incorrecta debido a la complejidad del

proceso actual.

1.6 Control a Pronóstico.

Esta situación hace necesaria la implementación de un sistema que permita

organizar y planificar como permitir que la operación se realice de manera

objetiva, mediante el establecimiento de un sistema automatizado por el cual

se muestre la información requerida en el tiempo oportuno y veraz.

1.7 Sistematización del problema.

1 ¿Qué impacto tiene la complejidad de los reportes en la demanda de

trabajo en el personal?

2. ¿Cómo afecta la falta de documentación para la generación de reportes?

3. ¿Cómo impacta en el proceso de generación de informes el que los datos

no esté en el tiempo propuesto y que mantengan veracidad?

4. Cuán importante es que no se tenga el control del personal ya que no se

les puede realizar un control de trabajo.

1.8 Objetivo General

Es la creación de un sistema Móvil de Inspección para realizar la

organización, recolección de información y manejo de visitas para mejorar la

productividad de nuestros empleados como los procesos operativos de los

Créditos disminuyendo el tiempo de respuesta.

1.9 Objetivos Específicos

1. Obtener información con mayor rapidez.

2. Inspecciones de mayor calidad.

3. Mejorar la gestión y planificación de las visitas.

4. Reducción de formularios en papel.

5. Minimizar los tiempos de Respuestas en la verificación de datos.

6. Minimizar costos de mano de obra ya que la información de las

inspecciones no será digitada.

1.10 Alcances

1.- El sistema contara con un formulario que permita el ingreso de todas las

solicitudes que contenga información correspondiente al Cliente para la

aprobación del crédito.

Gráfico 1. Formulario de Solicitud de Crédito

2.- El sistema nos proporcionará un reporte de la gestión de ruta de nuestros

inspectores.

Gráfico 2. Clientes asignados

3.- El sistema contara con un formulario que permita al inspector manejo de

visitas realizadas.

Gráfico 3. Reporte de visitas

4.- El sistema contará con un formulario en la aplicación móvil que permita el

ingreso de información correspondiente a la verificación de las inspecciones.

Gráfico 4. Datos personales Gráfico 5. Bienes

Gráfico 5. Gastos

5.- El sistema organizara las Rutas de visitas para los inspectores en base

información relacionada con las distancias de los recorridos o prioridades que

se manejen.

Gráfico 6. Rutas de cliente

6.- El sistema contara con claves de acceso que permitirá verificar que la

información que se envié es proporcionada por las personas que recolecta o

verifican la información.

Gráfico 7. Ingreso al sistema

7.- El sistema manejara un reporte de las visitas realizadas por los

inspectores.

Gráfico 8. Clientes Inspeccionados

1.11 Aportes

Sin duda que las nuevas tecnologías de comunicación evolucionan a gran

velocidad con un gran impacto en la vida de las personas, generando un

cambio radical en cortos plazos y en casi todos los casos dejando obsoletos

y con muy poca información al respecto. Es por esto que es obligatorio

introducir muchos conceptos previos al desarrollo, conociendo su estado

actual y futuro en el área. Gracias a esto se conceptualiza un marco de

trabajo mucho más objetivo a la hora de diseñas y implementar proyectos de

éste tipo.

En la investigación previa y posterior construcción de software que contempla

éste proyecto se adquieren implícitamente grandes conocimientos y se

generan grandes niveles de experiencia para futuros desarrollos de

proyectos, dejando los cimientos sólidos en éste campo.

Por último, y no menos importante, este proyecto aporta una solución que

ofrece una mayor libertad y comodidad de interacción con el equipo Pocket.

1.12 Limites

Uno de los mayores Limitantes que tenemos con nuestros sistemas podría

presentarse con la adaptabilidad del equipo Pocket, con nuestro software ya

que dependiendo de las características del equipo podríamos sacar el mejor

provecho a nuestra herramienta, es importante mencionar que la plataforma

por el hecho de ser propietaria puede tener problemas de compatibilidad con

otras plataformas del mercado.

1.13 Justificación del proyecto

Los principales pilares que justifican la realización de este proyecto son:

Innovación: Desarrollar un software que implementa y explota al

máximo nuevas tecnologías, aplicando una integración con

usuarios finales que no necesariamente deban tener conocimientos

básicos de manejos de computadoras o sistemas. Es por esto que

se presenta una propuesta totalmente innovadora.

Evolución.- Los constantes descubrimientos de nuevas

tecnologías hacen evolucionar inevitablemente la mentalidad de las

personas, es por esto que basándose en las nuevas tecnologías

que se imponen en el mercado se ha optado por desarrollar esta

aplicación que explota las tecnologías de equipos Pocket

Economía Basada en Equipos Móviles, el ahorro de cables y

energía es crucial para obtener dispositivos realmente económicos

y esto apoyado por la implementación utilizando sistemas que

permitan obtener herramientas que contengan información

necesaria fuera de la oficina.

Creatividad Un proyecto de estas características no ha sido

aplicada en otras empresas de la competencia.

1.14 Factibilidades del Proyecto.

1.14.1 Operacional

Se realizo una encuesta con respecto al uso de formularios en papel para la

recolección de información el cual constituye de un formato equivalente en

donde se realizará una emulación del sistema, con respecto al formulario los

inspectores no tuvieron ningún inconveniente les pareció bastante sencillo y

pudieron elaborar sus tareas sin problemas.

Con respecto a la productividad de los empleados, se ha evaluado que

muchos de ellos han tomado la plantilla prototipo como parte fundamental de

su trabajo la agilidad para la recopilación de información ha sido bastante

buena y la información se ingresa con mucha rapidez.

Según las encuestas realizadas por los mismos inspectores, los clientes han

tomado de buena forma la recopilación de información.

1.14.2 Técnica.

La información que se va cargar en los equipos pocket es filtrada por lo que

el equipo contará con suficiente memoria física para poder almacenar la

información.

La capacidad técnica con la que cuenta esta tecnología es totalmente

probada ya que hemos obtenidos las garantías de uso por nuestro

proveedor.

El enfoque de parte de software nos da la facilidad de realizar los debidos

mantenimientos de nuestro sistema, ya que el ciclo de vida utilizado en

nuestro proyecto es Espiral. El cronograma de actividades esta detallado en

el Anexo 1.

1.14.3 Económica

El costo de los equipos Pocket aproximadamente esta por los $ 350, la

implementación del sistema y de los programas para realizar el

mantenimiento del sistema se evalúa en base a comprar el sistema con

nuestros propios requerimientos a una empresa de implementaciones de

esta tecnología o contratar personal y el software para que el sistema se

realice por nuestra cuenta.

Los Beneficios que los que cuenta nuestro sistema es sustancialmente la

imagen con la que se venderá nuestro producto, ya que contaremos con

inspecciones con información en un tiempo mayor, evitaremos realizar

digitaciones después de las inspecciones, la reducción de formularios que

evitan la compra de suministros de oficinas( hojas, tonner de impresoras), se

podrá mejorar el diseño de interiores de nuestras oficinas, evitando tener

almacenada información físicamente ya que todas la información estará en

nuestra base de datos.

CAPITULO 2 ANÁLISIS DE SISTEMAS

2.1 Análisis de requerimientos

Después de haber realizado un análisis de los problemas que tiene la

empresa en el área de inspecciones de crédito en el aspecto, operacional y

tecnológico, se pone a su entera disposición la siguiente solución que está

orientada a satisfacer dichas necesidades:

2.2 Soluciones.

Desarrollo de un Sistema Inspección Móvil

El Sistema Inspección Móvil llevará un control detallado de la información de

los clientes que llevan a cabo los inspectores de crédito de la empresa. Este

sistema será desarrollado bajo un ambiente móvil en Pocket PC con una

base de datos en PL-SQL.

El sistema propuesto tendrá como objetivo mejorar y agilitar la el proceso de

inspección, el mismo que abarca la creación de rutas, manejo de visitas,

verificación de inspecciones realizadas, estado de las visitas, que se realizan,

a través de módulos que llevarán el control de sus actividades, así como

reducir el tiempo requerido en la preparación de reportes y facilitar el trabajo.

Los módulos que incluye el sistema se mencionan a continuación:

2.3 Seguridad

Su función será la de controlar el acceso de los usuarios al sistema, así como

establecer los permisos de acceso y manejar las estructuras de

almacenamiento generales.

2.4 Ingreso de Solicitudes

Permite el registro del ingreso de solicitudes, la misma que contara con los

datos del cliente, referencias familiares, referencias bancarias y otra

información relevante para la empresa.

2.5 Manejo de Visitas.

En este modulo permitirá al supervisor del área de inspecciones, seleccionar

la información relevante del cliente para definir las modalidad de visita, y

proceder a la creación de rutas.

2.6 Gestión de Rutas.

Este diseño nos permite asignar cada sector de la cuidad (Norte, Sur, Este,

Oeste) se subdivida en ruta de vista, en la que a cada ciudadela o dirección

formara parte de la misma, se debe considerar que las oficinas principales

de la empresa están ubicadas en el centro de la ciudad de Guayaquil, se

cuenta con 1 supervisor por zona 3 inspectores para la misma,

2.7 Modelo de Inspección.

Este modulo estará implementado en cada dispositivo Palm, permitirá al

inspector el maneje cada visita de inspección llevarlas de forma

automatizada y ágil.

El sistema permitirá que los inspectores sincronicen la información una vez

realizadas las inspecciones evitará:

El ingreso repetitivo de datos.

La perdida de tiempo en el ingreso de la información de la inspección

La pérdida de tiempo en las consultas de información de documentos.

2.8 Análisis del Área Operacional.

El Sistema permitirá que la información esté disponible en cualquier

momento, reduciendo el tiempo requerido para procesos de emisión de los

reportes.

Problemas

Lentitud en la actualización de datos y generación de reportes.

No cuentan con recursos de respaldo fiables para la información.

Control de consultas de la inspección a través de emisión de reportes.

El Documento para la inspección con los datos del cliente es impresos

para que el inspector la realice.

Una vez realizada la inspección se procede a digitar los datos

verificados por el inspector.

Los informes de inspección realizados para otras agencias son

enviados vía fax o valija.

Gastos operacionales innecesarios (papelería y otros).

Soluciones

Implementación del Sistema de Inspección de Clientes.

Documentación actualizada.

Ahorro en gastos de suministros.

Información confiable que brindará el Sistema de Inspección de

Clientes.

2. 9 Análisis Organizacional.

Problemas

La información entre departamentos no fluye con rapidez.

Lentitud en organización para realizar las inspecciones.

Entrega de documentos no actualizados.

Soluciones

Procesos de control automáticos.

2.10 Generación de Reportes

Reporte de Generación de Rutas

Reporte de del manejo de vistas

Reporte del estado de la inspección

2.11 Identificación de los Actores.

Administrador del sistema

Usuario Ejecutivo de crédito

Supervisor de inspecciones

Inspectores

2.12 Descripción de los Actores.

2.12.1 Administrador del Sistema.

Es el encargado de crear, asignar permisos y mantener los diferentes

usuarios. También debe registrar a los funcionarios en el sistema, y a los que

lo necesiten, otorgarles su usuario respectivo. Además deberá mantener las

estructuras generales del sistema y sacar respaldos de la base de datos.

2.12.2 Usuario ejecutivo de Crédito.

Es quien interactuará directamente con el sistema, deberá pertenecer a un

rol determinado y sólo tendrá acceso a las opciones del sistema que el rol

especifique, es el encargado del ingreso de Solicitudes de Crédito, interactúa

directamente con el Cliente.

2.12.3 Supervisor departamento de Inspecciones

Encargado de generarla información de la solicitud de crédito para elaborar,

los repotes de inspección.

2.12.4 Inspectores

Usuario que interactúa directamente con dispositivo Móvil donde se

encontrara el sistema de inspecciones.

2.13 Identificación de Casos de Uso.

1. Creación de usuarios.

2. Solicitud de cambio de contraseña.

3. Ingreso al sistema.

4. Obtener respaldos de la base de datos.

5. Generar la gestión de Rutas.

6. Realizar el manejo de visitas

7. Creación del sistema de Inspecciones

8. Verificación de Inspecciones.

2.14 Diagrama General de Casos de Uso.

MÓDULO DE INSPECCIONES

SISTEMA DE INSPECCIONES DE CREDITO

Empresa:

SU CREDITO

Diagrama General de casos de uso

Grafico 10. Caso de uso de usuario solicitante

Ingreso de solicitudes

Consulta Proceso Solicitud

Solicita Ingreso al sistema

Usuario Solicitante

Módulo de inspecciones

Sistema de inspecciones de crédito

Empresa:

SU CREDITO


Gráfico 11. Caso de uso supervisor

Manejo de Visitas

Generación de rutas de Visitas


Supervisor de Inspecciones

Generación de la Inspección

Consulta Inspección Realizada

Módulo de inspecciones

Sistema de inspecciones de crédito

Empresa:

SU CREDITO


Gráfico 12. Caso de uso de inspector

Maneja el Sistema de Inspección

Ingresa datos de la Inspección Realizada

r


Usuario Inspector

Consulta el modulo de Visitas Diarias

Sincronización de Información al Finalizar el dia

CAPITULO 3 DISEÑO DE SISTEMAS

3.1 Diseño de Datos

Para revisar el diseño de datos de nuestro sistema realizamos la encuesta

necesaria para poder encontrar los datos de nuestro sistema

¿Qué es lo primero que ocurre?

El cliente solicita asesoría como resultado de nuestra campaña

de publicidad o para cubrir sus necesidades financieras.

¿Qué es lo siguiente que ocurre?

Se procede a realizar un sondeo para validar que cumpla los

requisitos básicos para ingresar una solicitud de Crédito con

nuestra institución. Luego de esto se procede a ingresar los

datos en nuestra base de datos, la información es revisada por

central de Riesgo, se realiza confirmaciones telefónicas, para

luego realizar Inspecciones en sitio.

¿Qué es lo último que ocurre?

La decisión sobre la aprobación o negación del crédito.

¿De dónde viene él (Servicio)?

El servicio lo crea el cliente.

¿Cómo él (Servicio, Material) llega al proceso?

El servicio llega a través de la solicitud que el cliente haya

ingresado con nosotros.

¿Quién toma las decisiones (si se necesita)?

El departamento de aprobación de créditos.

Jefe de Crédito.

¿Qué pasa si la decisión es “Sí”?

Se procede a informar al cliente y se le informa sobre el monto

y plazo y días de pago.

¿Qué pasa si la decisión es “No”?

Se le procede a informar sobre las causas por lo que no fue

aprobado el crédito, sean estos por mala información, malas

referencias o información falsa.

¿Adónde va el (Producto, Servicio) de esta operación?

Hacia la disposición del cliente, siendo más ágiles y efectivos

con el tiempo y mejorando los procesos.

¿Qué revisiones/ verificaciones se realizan en el producto en

cada parte del proceso?

Que la información que proporciona sea valedera.

Que no tengas deudas pendientes en otras instituciones.

Que las propiedades o información básica pueda ser fácilmente

tangibles.

¿Qué pasa si la revisión/ verificación no cumple con los

requisitos?

Simplemente se descarta ha este cliente y se le indica que no

se puede realizar el proceso de crédito.

CLIENTESistema de

Inspección

SUPERVISOR

INSPECTOR

Solicitud de Crédito Aprobaciónb de Rutas

Creación de Rutas

Información por Validar

Información Validada

Diagrama de Flujo de Datos

Grafico 13. Diagrama de flujo de datos

Gráfico 14. D.F.D. nivel 0

3.2 Diseño Arquitectónico

Flujo de Transformación

Flujo Entrante

Información que es ingresada desde la base de Datos hacía nuestros

equipos Móviles.


La Información que fue validada por el Inspector y que realizo la

confirmación.

Flujo Saliente.

Información que Ingresa a la Base de dato desde el equipo Móvil.

Ingreso de Datos

(Solicitud)

FLUJO ENTRANTEFLUJO DE

TRANSFORMACION

Inspección de Datos

FLUJO SALIENTE

Validación de la

Inspección

Representación

Externa

Representación

Externa

Representación

Externa

Página 1


Gráfico 18. Flujo de transformación

CAPITULO 4

PRUEBAS DEL SISTEMA

4.1 Modelo para la Generación de Pruebas.

Para la realización de las pruebas las hemos realizado a través del siguiente

modelo, el cual nos ha permitido validar el uso de la información.

Gráfico 19. Generación de pruebas

Aplicando los casos de usos hemos elegidos como procesos criticos del

Sistema Movil de Inspecciones al sistema de Seguridad y al de la Inspección,

ya que estos modulos son los únicos que nos permiten ingresar información.

4.2 Pruebas de unidad

En esta prueba se analizaron los módulos de forma independiente, que

forman parte del tipo de pruebas de la caja blanca, los mismos que son

parrte del analisis de los procesos.

Módulos Analizados

Seguridades

Ingreso de la Inspección

Consultas

General

4.2.1 Estándares de definición:

En Librerías

Tablas

Campos

4.2.1.1 En Librerías

Las librerías son distinguidas por el prefijo lib no nos decidimos manejar

diferentes librerías en vistas de que los nombres y los gráficos que utiliza la

herramienta denotan claramente que objeto es el que estamos utilizando por

lo cual solo ha sido necesario utilizar como formato, los nombres de las

ventanas W_ nombre base del propósito Inspección y la generalización del

mismo. Ejemplo W_INSPECCION_CLIENTE

4.2.1.2 Tablas

Las tablas se manejan con los nombres propios de los elementos, tabla

ciudad, cliente, empleado etc.

4.2.1.3 Campos.

Los campos poseen 7 caracteres como nombres distribuidos de la siguiente

forma 3 caracteres iniciales como nombre de propósito de campo, carácter

especial “_” y los 3 restantes que pertenecen a las iniciales del campo.

4.3 Verificación y validación

Analizamos cada uno de los procesos para que el propósito de nuestras

salidas seas las recomendadas, hemos podido realizar el proceso y

validados que la data que se ha utilizado ha recibido el trato correcto de uso

y procesamiento ideal.

4.4 Pruebas alfa y beta

Son pruebas que se realizan para que el usuario final descubra el o los

errores en el sistema.

La prueba Alfa se lleva a cabo, por un cliente, en el lugar de desarrollo. Se

usa el software de forma natural con el desarrollador como observador del

usuario y registrando los errores y problemas de uso. Las pruebas alfa se

llevan a cabo en un entorno controlado. Pero estas pruebas no son

suficientes porque la perspectiva de un desarrollador no es igual que la de un

usuario final, para esto existe las pruebas Beta.

La prueba Beta se lleva a cabo por los usuarios finales del software en los

lugares de trabajo de los clientes. A diferencia de la prueba alfa, el

desarrollador no esta presente normalmente. Aquí el cliente registra todos los

problemas (reales o imaginarios) que encuentra durante esta prueba e

informa a intervalos regulares al desarrollado.

Estas pruebas realizaron con una persona que posee conocimientos básicos

de manejo de Pocket e Informática, previamente informamos el proceso a

seguir y no se tuvo problemas ya que el manejo de uso y la usabilidad que

poseen nuestro sistema se dio para que sea exitosa.

4.5 Pruebas de procesos y Funcionamiento de Procesos Críticos

4.5.1 Modulo de Seguridad.

Para el ingreso necesitaremos ingresar la data de los Inspectores o

Supervisores que tenemos ingresados en nuestra base de datos, el mismo

definirá los privilegios que tendrán en el sistema.

Gráfico 20. Información usuario

Gráfico 21. Usuario correcto

Ingresando el User ID y Password incorrecto el sistema indicará si es la

contraseña es correcta o incorrecta.

Si procedemos a ingresar con contraseña de INSPECTOR el sistema no

permite que se hagan uso de módulos de los Supervisores.

Gráfico 22. Menú principal

Si se requiere realizar la inspección de los Inspectores nos saldrá un

mensaje indicando que no se permite el acceso a no ser que el ingreso sea

de un Supervisor.

Gráfico 23. Sin autorización

4.5.2 Modulo de Inspección.

Para realizar una inspección es necesario que se proceda a escoger a unos

de los clientes que tienen orden para la revisión u orden de pendientes.

Gráfico 24. Clientes a inspeccionar

Una vez que seleccionamos al cliente a Inspeccionar procedemos a capturar

la hora de la visita del cliente, inmediatamente obtendremos de la base de

datos la información que corresponde al cliente, para mejorar la presentación

y la usabilidad del sistema las plantillas están divididas en Tab.

Gráfico 25. Inspección – Datos personales

Gráfico 26. Inspección - Bienes

Gráfico 27. Inspección - Gastos

El sistema permite asegurarnos que la información que se ingresa a través

de los Check o de las cajas de texto, este completa es decir que si

información que se considera necesaria no ha sido ingresada se procede a

enviar un mensaje <<Faltan Datos Requeridos>> al intentar ingresar los

datos.

Gráfico 28. Error – Faltan Datos Requeridos

La información que se valida en la pocket se ingresa sin problemas al realizar

la Inspección, se indica a través de un mensaje.

Gráfico 29. Cliente inspeccionado

4.6 Calidad del sistema

Podemos citar que hemos cumplido con un proceso de calidad que en la cual

hemos podido cumplir con las mejoras del proceso eliminando fallos en el

mismo que dan como solución eficiencia, control y recuperación de inversión

en un corto período

ANEXOS

Anexo1

1

1. Requerimientos del Sistema

1.1 Requerimientos de Hardware y Software

A continuación detallamos las características principales de hardware y software

mínimas tanto del equipo (Pc) como del dispositivo móvil para ejecutar nuestro

sistema de Inspecciones Móviles:

Pc

Hardware

Pentium IV 2.6 Ghz.

Ram 512 Mb.

H.D.D. de 80 Gb.

Software

Windows 2000/XP/home/professional/NT/WS.

Sybase Central.

Pocket Builder.

Dispositivo Movil

Hardware

Pocket Pc DELL AXIM.

Dimensión: 128mm x 81.1mm x 18mm.

Procesador Intel X-scale 400Mhz.

2

64 Mb SD RAM, 48 Mb Flash ROM.

Software

Windows Mobile 2002

Microsoft Pocket Aplications

Microsoft Outlook, Internet Explorer, and Microsoft MSN Messenger

capable

1.2. Instalación de Componentes

El primer paso consiste en preparar la instalación en nuestro equipo de SQL

Anywhere Studio , la figura 1.1 nos muestra el inicio de dicho proceso

Figura 1.1. Ventana de instalación de SQL Anywhere Studio

3

La figura 1.2 nos indica la ventana de bienvenida a la instalación de Anywhere

Studio, para comenzar la instalación hacemos un click en el botón Next

Figura 1.2. Ventana de Bienvenida a la instalación de SQL Anywhere Studio

Continuando con la instalación, vemos la siguiente ventana, la cual nos muestra

la región que escogemos para las licencias, en nuestro caso escogimos la

4

opción de Americas and Asia Pacific – General, y aceptamos los términos de

contrato de las licencias de Anywhere; tal como se muestra en la figura 1.3.

Figura 1.3. Ventana de aceptación de términos de licencias

A continuación registramos el serial de seguridad de instalación de Anywhere

Studio 9 para poder continuar con la instalación de la aplicación, tal como lo

observamos en la figura 1.4.

5

Si no se coloca esta clave no se podrá seguir instalando el Anywhere Studio 9,

una vez digitado, escogemos Next para seguir con el proceso de instalación

Figura 1.4. Registro del serial de instalación

La figura 1.5 nos muestra en donde se van a instalar los archivos de Anywhere

Studio, la ruta por defecto es C:Archivos de Programa\Sybase\SQL Anywhere 9,

pero nosotros podemos elegir en donde los queremos instalar, para usar una

ruta diferente escogemos el botón Browse y elegimos otra ruta.

6

Una vez escogido el destino de almacenamiento de los archivos, hacemos click

en Next para continuar la instalación.

Figura 1.5. Eligiendo ubicación de archivos de instalación

Ahora se van a instalar los componentes de SQL Anywhere 9, su proceso es

similar al de la ventana anterior mostrada en la figura 1.5., ahora la ruta por

defecto es C:Archivos de Programa\Sybase\Shared, pero también podemos

escoger otra ruta donde instalar los componentes y esto se lo puede realizar

7

haciendo click en el botón Browse, posteriormente escogemos Next para

continuar con la instalación.

Figura 1.6. Instalación de los componentes

Siguiendo con el proceso de instalación, ahora vamos a seleccionar los

componentes necesarios para complementar el proceso, seleccionamos la

opción de Mobilink, para la sincronización, la opción Ultralite que es una base

mucho más ligera, los componentes que no necesitemos no los seleccionamos,

ya que pueden hacer nuestra herramienta mucho más pesada.

8

Generalmente estas son las opciones que escogemos para configurar los

componentes de Anywhere 9, tal como lo muestra la figura 1.7

Figura 1.7. Ventana para seleccionar los componentes de instalación

En la figura 1.8. se muestra el sevicio de licencia de Anywhere Studio, consiste

en registrar el nombre y compañía a quien es otorgada, así como también el

9

número de licencias y finalmente el tipo; que este puede ser basado en un

modelo de red o en un modelo de CPU, nosotros escogimos el primero de ellos

Figura 1.8. Ventana de registro de licencias

Siguiendo con el proceso de instalación, en la figura 1.9. se indica la carpeta sde

instalación y los íconos de los programas que se adicionaran a nuestro entorno,

nosotros seleccionamos la opción SQL Anywhere 9 de la lista y hacemos un

click en Next .

10

Figura 1.9. Ventana de Selección de la Carpeta de SQL Anywhere 9

La siguiente ventana lista la información de los programas que se copiarán, una

vez verificada esta información procedemos a hacer un click en la opción Next

para continuar con la instalación de Anywhere Studio , y comenzar a copiar los

archivos , tal como lo muestra la figura 1.10.

11

Figura 1.10. Ventana de inicio de copia de archivos

En la figura 1.11. se seleccionan el formato referente a la documentación de la

instalación, hace mención a los archivos con extensión .PDF y .HTML que se

encontrarán en la ayuda de la aplicación, elegimos en este caso las 2 opciones ,

tanto la ayuda en línea, así como también los diferentes manuales de ayuda,

para hacer mas completa nuestra aplicación, hacemos click en Next para

continuar.

12

Figura 1.11. Ventana de selección de documentación de ayuda

Ahora se muestra la instalación de Anywhere Studio para Windows CE, si no

cree conveniente esta opción haga click en Skip, caso contrario escoga la

opción Install, así como lo muestra la figura 1.12.

En la figura 1.13. observamos que la documentación ha sido completada

13

Figura 1.12. Ventana de confirmación de instalación de Windows CE

Figura 1.13. Ventana de Documentación Completa

14

Una vez completada la documentación, hacemos click en Finish, y la siguiente

pantalla que se muestra es la que nos indica que la instalación de SQL

Anywhere 9 está completa, podemos escoger la opción de reiniciar el equipo

ahora o hacerlo posteriormente.

Figura 1.14 Ventana de instalación de SQL Anywhere 9 terminada

15

2. Levantamiento de las Bases

Para nuestro sistema Mobi Inspection, hemos usado la herramienta Sybase

Central, en la cual se crearon tres bases; una base consolidada que contiene

toda las tablas que usaremos en el sistema, y 2 bases remotas que trabajan con

dos usuarios de sincronización, ambas bases contienen menos información que

la base consolidada, ya que una esta en la aplicación de Pocket Builder y la otra

está en la Pocket, para esto creamos un archivo bat con el nombre de MakeDB,

Figura 2.1. Creación de bases ejecutando archivo Makedb.bat

16

en el cual se crean las bases anteriormente mencionadas, tal como lo muestra

la figura 2.1.

Luego de crear las bases inicializamos Sybase Central, para poder conectarnos

con las base consolidad y con las remotas, la base consolidada se llama pkdb, y

las bases remotas se llaman pkdb_remote y pkdb_remote1, asi como lo indica la

figura 2.2.

Figura 2.2 Conexión de las bases en Sybase Central

Una vez dentro de Sybase procedemos a conectarnos con las bases,

escogemos primero la base consolidada con el plug-in de Anywhere, luego con

17

el mismo plug-in la base primera y finalmente con el plug-in de Mobilink la

segunda base remota.

En la figura 2.3 ya están levantadas las bases de datos, con su respectiva

información, escogimos las bases que creó el archivo MakeDB.bat,

posteriormente hay que levantar el servidor de sincronización esto lo hacemos

con el archivo step1.bat,

Figura 2.3. Administración de las bases en Sybase Central

18

que contiene los pasos para levantar el servidor de Mobilink; cuando se va a

sincronizar se carga el archivo Step2 en donde constan los pasos para realizar

la sincronización

En este momento ya se encuentra levantado el servidor de MobiLink, con el cual

esta listo el servicio para cuando se quiera realizar la sincronización, así lo

indica la figura 2.4.

Figura 2.4. Llevantamiento del servidor de Mobilink

Cuando se vaya a hacer la sincronización, aparecerá una ventana mostrando

que la actualización de la información está lista, en caso de encontrarse algún

19

error, no se permite la sincronización, la figura 2.5., hace referencia al usuario

de sincronización, muestra un mensaje de sincronización completa si no hay

errores y automáticamente se minimiza.

Figura 2.5. Sincronización exitosa

Si existen errores la figura 2.6 indica que la sincronización falló.

Figura 2.6. Falla en sincronización

20

3. Entorno de la Aplicación:

Para desarrollar nuestro sistema de inspecciones Mobi Inspection hemos

utilizado la herramienta Pocket Builder versión 2.0, utilizamos la base de datos

Sybase Central.

Un inspector y un supervisor de la aplicación necesitan:

Un código de usuario

Una clave de acceso

Un dispositivo móvil (pocket)

El inspector chequeará que los datos que posee sean los correctos en el

momento que este esté realizando la inspección.

El supervisor tiene la función de corroborar que la información que el inspector

validó sea correcta, en otras palabras el supervisor se convierte en asegurador

de la inspección.

A continuación detallamos todo el proceso técnico de nuestro sistema de

inspecciones Mobi Inspection

21

3.1. Diagrama de Flujo de Datos

Aquí detallamos como fluye la información en nuestro sistema de inspecciones,

en el cual el cliente hace una solicitud de crédito, Mobi Inspection genera la

creación de rutas, y envía la información al inspector que se encarga de ir al

lugar donde se va a realizar la inspección, luego esa inspección realizada es

chequeada por el supervisor, básicamente el sistema tiene tres entidades

principales que son : el cliente, el inspector y el supervisor.

CLIENTESistema deInspección

SUPERVISOR

INSPECTOR

Solicitud de Crédito Aprobaciónb de Rutas

Creación de Rutas

Información por Validar

Información Validada

Diagrama de Flujo de Datos

Figura 3.1. Diagrama de flujo de Datos

22

3.1.1. Diagrama de Flujo de Datos (Nivel 0)

En el nivel 0, generalizamos lo que nuestro sistema realiza, el modulo de

inspecciones es el proceso central que direcciona la información hacia cada una

de las entidades relacionadas en el sistema, al inspector le permite validar los

datos del cliente, si la información es correcta será ingresada a la base de datos,

tal como lo muestra la figura 3.2.

DIAGRAMA DE FLUJO DE DATOSNIVEL 0

MODULO DE INSPECCIONES

CLIENTE INSPECTOR

SOLICITUDESAPROBADAS

GENERACIONDE RUTAS

Figura 3.2. Diagrama de flujo de datos (nivel 0)

23


En este proceso el cliente envía una solicitud, a través de un formulario el

mismo que es llenado en la empresa, una vez llenada la solicitud es entregada a

recepción para su análisis posterior, cuando esa solicitud es aprobada se emite

una orden de inspección para que el inspector la realice, tal como lo muestra la

figura 3.3.

DIAGRAMA DE FLUJO DE DATOSNIVEL 1

SOLICITUD LLENA

PROCESO RECEPCION Y APROBACION DE SOLICITUDES

CLIENTE

RECEPCION

DE

SOLICITUDES

APROBACION

DE

SOLICITUDES

EMPRESA

SOLICITUDESAPROBADAS

INSPECTOR

envia solicitud

solicitud aprobada orden de inspeccion

envia referencias


24


Este proceso realiza la verificación de las solicitudes de los clientes ha ser

inspeccionados, a los clientes que visitaron se les entregan un ticket como un

recibo de que han asistido a la inspección, finalmente el supervisor es quien se

asegura que los inspectores hayan hecho su trabajo, validando cuantas

inspecciones realizadas hicieron y cuantas quedan pendientes, figura 3.4.

D IA G R A M A D E F L U J O D E D A T O SN IV E L 2

P R O C E S O V E R IF IC A C IO N D E S O L IC IT U D E S Y O T O R G A M IE N T O D E C R E D IT O

V E R IF IC A C IO N

F IS IC A

D E

S O L IC IT U D E S

IN S P E C T O R C L IE N T ED a to s tic k e t

O T O R G A M IE N T O

D E L

C R E D IT O

in fo rm a c ió n c o rre c ta

C R E D IT OC O N C E D ID O

C L IE N T E S

e n v ia in fo rm a c io n d e ta lla d a

in fo rm a c io nc lie n te s

S U P E R V IS O R

D a to s

IN S P E C C IO N E S

in fo rm a c io n in s p e c c ió n


25

3.1.4. Diagrama de Flujo de Datos (nivel 3)

Este es el proceso de ingreso al sistema de inspecciones móviles en el cual el

inspector digita un nombre de usuario acompañado de un clave de acceso al

mismo, la cual es validada para asignarle el perfil correspondiente de acuerdo a

los clientes que podrá visitar, la información se la almacena en la tabla

seguridad, como lo indica la figura 3.5

VALIDARCONTRASEÑA

Ingreso clave

DATOSINGRESO

Ingreso clave

Informacion correcta

PERFILDE

USUARIO

SEGURIDAD

Datos

INSPECTOR

Figura 3.5. Diagrama de flujo de datos (Nivel 3)

26

4. Esquema Arquitectónico


Flujo Entrante

Información que es ingresada desde la base de Datos hacía nuestros equipos

Móviles.


La Información que fue validada por el Inspector y que realizo la confirmación.

Flujo Saliente.

Información que Ingresa a la base de datos desde el equipo Móvil.

Ingreso de Datos(Solicitud)

FLUJO ENTRANTE FLUJO DETRANSFORMACION

Inspección de Datos

FLUJO SALIENTE

Validación de laInspección

RepresentaciónExterna



Página 1


Figura 4.1. Flujo de transformación

27

4.1. Estructura Específica de la Base de Datos

4.1.1. Diagrama Entidad - Relación

La figura 4.2 muestra el diagrama entidad - relación del sistema de inspecciones

Mobi Inspection

Figura 4.2. Diagrama E-R del sistema Mobi Inspection

28

4.1.2. Script de las Base de Datos

Base Consolidada

drop table inspeccion;

drop table visitas;

drop table empleado;

drop table cliente;

drop table solicitud;

drop table ciudad;

drop table sector;

drop table rutas;

drop table usuarios;

create table "dba"."usuarios"

(

"cod_user" numeric(5) not null,

"cod_car" numeric(5) not null,

"nom_user" char(10) not null,

"pass_user" char(10) not null,

PRIMARY KEY(cod_user)

);

29

create table "dba"."ciudad"

(

"cod_ciu" numeric(5) not null,

"nom_ciu" char(15) not null,

PRIMARY KEY ("cod_ciu")

);

create table "dba"."sector"

(

"cod_sec" numeric(5) not null,

"nom_sec" char(15) not null,

PRIMARY KEY ("cod_sec")

);

create table "dba"."rutas"

(

"cod_rut" numeric(5) not null,

"nom_rut" char(25) not null,

30


PRIMARY KEY ("cod_rut")

);

create table "dba"."empleado"

(

"cod_emp" numeric(5) not null,

"nom_emp" char(20) not null,

"ced_emp" numeric(10) not null,

"dom_emp" char(20) not null,

"tel_emp" char(10) not null,

"cod_car" numeric(5) not null,

PRIMARY KEY ("cod_emp")

);

create table "dba"."cliente"

(

"cod_cli" numeric(5) not null,

"ced_cli" numeric(10) not null,

"nom_cli" char(20) not null,

31

"apel_cli" char(20) not null,

"cod_ciu" numeric(5) not null,


"cod_rut" numeric(5) not null,

"estad_cli" char(10) not null,

"depen_cli" numeric(4) null,

"npconyuj_cli" char(25) null,

"dir_cli" char(20) not null,

"vnda_cli" char(15) not null,

"Tipovnda_cli" char(15) not null,

"tiempv_cli" numeric(5) not null,

"tel1_cli" char(10) not null,

"veh_cli" char(15) null,

PRIMARY KEY ("cod_cli"));

create table "dba"."solicitud"

(

"cod_sol" numeric(5) not null,

"fec_sol" date not null,


32

"est_sol" numeric(5) not null,


PRIMARY KEY ("cod_sol"));

create table "dba"."visitas"

(

"cod_vst" numeric(5) not null,

"fec_vst" date not null,



"est_vst" char(10) not null,

PRIMARY KEY ("cod_vst")

);

create table "dba"."inspeccion"

(

"cod_ins" numeric(5) not null,

"cod_sol" numeric(5) not null,


33


"fec_ins" varchar(10) not null,

"hinicio_ins" varchar(10) not null,

"hfin_ins" varchar(10) not null,

"nomcli_ins" varchar(5) not null,

"estadcli_ins" varchar(10) not null,

"depencli_ins" varchar(4) not null,

"npconyujcli_ins" varchar(25) not null,

"nomcontact_ins" varchar(15) not null,

"dircli_ins" varchar(5) not null,

"vndacli_ins" varchar(15) not null,

"Tipovndacli_ins" varchar(15) not null,

"tiempvcli_ins" varchar(5) not null,

"cantelectrcli_ins" numeric(5) not null,

"Obser_ins" varchar(50) null,

"vehcli_ins" varchar(5) not null,

"gas_mov_ins" numeric(5) not null,

PRIMARY KEY ("cod_ins") );

34

Add foreign key definitions

ALTER TABLE "DBA"."rutas"

ADD FOREIGN KEY "rut_fk" ("cod_sec")

REFERENCES "DBA"."sector" ("cod_sec");

ALTER TABLE "DBA"."cliente"

ADD FOREIGN KEY "ciu_fk" ("cod_ciu")

REFERENCES "DBA"."ciudad" ("cod_ciu");


ADD FOREIGN KEY "sec_fk" ("cod_sec")

REFERENCES "DBA"."sector" ("cod_sec");


ADD FOREIGN KEY "rutcli_fk" ("cod_rut")

REFERENCES "DBA"."rutas" ("cod_rut");

ALTER TABLE "DBA"."solicitud"

ADD FOREIGN KEY "clisol_fk" ("cod_cli")

REFERENCES "DBA"."cliente" ("cod_cli");

ALTER TABLE "DBA"."solicitud"

ADD FOREIGN KEY "empsol_fk" ("cod_emp")

REFERENCES "DBA"."empleado" ("cod_emp");

ALTER TABLE "DBA"."visitas"

35

ADD FOREIGN KEY "viscli_fk" ("cod_cli")


ALTER TABLE "DBA"."visitas"

ADD FOREIGN KEY "visemp_fk" ("cod_emp")


ALTER TABLE "DBA"."inspeccion"

ADD FOREIGN KEY "inscli_fk" ("cod_cli")


ALTER TABLE "DBA"."inspeccion"

ADD FOREIGN KEY "insemp_fk" ("cod_emp")


//Insert usuarios

insert into usuarios (cod_user,cod_car,nom_user,pass_user)

values(1,2,'jgarcia','jgarcia');


values(2,1,'jcalvache','jcalvache');


values(3,2,'nrivera','nrivera');

36

//insert ciudad

insert into ciudad (cod_ciu,nom_ciu) values(1,'Guayaquil');

insert into ciudad (cod_ciu,nom_ciu) values(2,'Quito');

insert into ciudad (cod_ciu,nom_ciu) values(3,'Cuenca');

insert into ciudad (cod_ciu,nom_ciu) values(4,'Manta');

insert into ciudad (cod_ciu,nom_ciu) values(5,'Ambato');

//Insert sector

insert into sector (cod_sec,nom_sec) values(1,'Norte');

insert into sector (cod_sec,nom_sec) values(2,'Sur');

insert into sector (cod_sec,nom_sec) values(3,'Este');

insert into sector (cod_sec,nom_sec) values(4,'Oeste');

insert into sector (cod_sec,nom_sec) values(5,'SurEste');

insert into sector (cod_sec,nom_sec) values(6,'SurOste');

insert into sector (cod_sec,nom_sec) values(7,'NorEste');

insert into sector (cod_sec,nom_sec) values(8,'NorOeste');

insert into sector (cod_sec,nom_sec) values(9,'Centro');

//Insert rutas

insert into rutas (cod_rut,nom_rut,cod_sec) values(1,'Sauces',1);

37

insert into rutas (cod_rut,nom_rut,cod_sec) values(2,'Atarazana',1);

insert into rutas (cod_rut,nom_rut,cod_sec) values(3,'Esteros',2);

insert into rutas (cod_rut,nom_rut,cod_sec) values(4,'Guasmo',6);

insert into rutas (cod_rut,nom_rut,cod_sec) values(5,'Malecon',9);

insert into rutas (cod_rut,nom_rut,cod_sec) values(6,'Peñas',9);

insert into rutas (cod_rut,nom_rut,cod_sec) values(7,'Batallon',1);

insert into rutas (cod_rut,nom_rut,cod_sec) values(8,'suburbio',4);

insert into rutas (cod_rut,nom_rut,cod_sec) values(9,'Floresta',5);

insert into rutas (cod_rut,nom_rut,cod_sec) values(10,'Pradera',5);

insert into rutas (cod_rut,nom_rut,cod_sec) values(11,'Fragata',6);

insert into rutas (cod_rut,nom_rut,cod_sec) values(12,'Fertiza',6);

//Insert empleado

insert into empleado (cod_emp,nom_emp,ced_emp,dom_emp,tel_emp,cod_car)

values(1,'Jorge Garcia',0914452024,'Coviem','2360423',2);

38

5. Diccionario De Datos Del Sistema Mobi Inspection

TABLA TB_CIUDAD

Contiene el código y nombre de la ciudad donde se encuentra los clientes que

van a ingresar una solicitud de crédito.

CLAVE NOMBRE TIPO DATO TAMAÑO DESCRIPCIÓNPRIMARIA COD_CIU NUMERIC 5 Identificación de la ciudad

NOM_CIUDAD CHAR 15 Nombre de la ciudad

Tabla 5.1 Tabla Ciudad

TABLA TB_RUTAS

Contiene el código, sector y descripción de la ruta que se asignara a cada

inspector para realizar la verificación de los datos que llenaron los clientes en al

solicitud

CLAVE NOMBRE TIPO DATO TAMAÑO DESCRIPCIÓNPRIMARIA COD_RUT NUMERIC 5 Identificación de la rutaFORANEA COD_SEC NUMERIC 5 Identificación del sector de ruta

NOM_RUT VARCHAR 20 Descripción detallada de la ruta

Tabla 5.2. Tabla Rutas

39

TABLA TB_SECTOR

Contiene la identificación y el nombre completo del sector

CLAVE NOMBRE TIPO DATO TAMAÑO DESCRIPCIÓNPRIMARIA COD_SEC NUMERIC 5 Identificación del sector

NOM_SEC CHAR 15 Descripción o nombre del sector

Tabla 5.3. Tabla Sector

TABLA TB_CLIENTE

Contiene la información correspondiente a los clientes.

CLAVE NOMBRETIPODATO TAMAÑO DESCRIPCIÓN

PRIMARIA COD_CLI NUMERIC 5 Identificación del cliente

CED_CLI NUMERIC 10Numero de cédula delcliente

NOM_CLI CHAR 20 Nombre del cliente

APELLID_CLI CHAR 20 Apellido del cliente

FORANEA COD_CIU NUMERIC 5 Código de la ciudad

FORANEA COD_SEC NUMERIC 5Sector donde vive elcliente

FORANEA COD_RUT NUMERIC 7Código de la ruta parallegar al cliente

40

ESTAD_CLI CHAR 10 Estado civil del cliente

DEPEN_CLI NUMERIC 4 Dependencia del cliente

NPCONYUJ-CLI CHAR 25 Nombre de cónyuge

DIR_CLI CHAR 20 Dirección del cliente

VNDA_CLI CHAR 15Vivienda del cliente,rentada, propia, etc

TIPOVNDA_CLI CHAR 15Tipo de construcción dela vivienda

TIEMPV_CLI NUMERIC 5

Tiempo que hapermanecido en lavivienda

TEL1_CLI CHAR 10 Teléfono del cliente

VEH_CLI CHAR 15Información de cónyugedel cliente

Tabla 5.4. Tabla Clientes

TABLA TB_EMPLEADO

Contiene la información correspondiente a los empleados que intervienen en el

sistema


PRIMARIA COD_EMPI NUMERIC 5Identificación del códigodel empleado

NOM_EMP CHAR 20 Nombre del empleado

CED_EMP NUMERIC 10 Cédula del empleado

41

DOM_EMP CHAR 20 Dirección del cliente

TEL_EMP CHAR 10 Teléfono del empleado

COD_CAR NUMERIC 5 Código del cargo

Tabla 5.5. Tabla Empleado

TABLA TB_INSPECCION

Contiene la información relevante al proceso de la inspección y la información

de los clientes

CLAVE NOMBRE TIPO DATO TAMAÑO DESCRIPCIÓNPRIMARIA COD_INS NUMERIC 5 Código de la inspección

COD_SOL NUMERIC 2Código de solicitud de lainspección

VNDACLI_INS CHAR 14

Información de lainspección de lavivienda

VEHCLI_INS BINARY 19 Inspección de vehículos

TIEMPVCLI_INS BINARY 16Tiempo de Inspección alcliente

NPCONYUJCLI_INS CHAR 11Información acerca de el(la) cónyuge

NOMCONTACT_INS CHAR 12

Nombre de quienatiende la inspecciónsino esta el cliente

NOMCLI_INS BINARY 8Nombre del cliente ainspeccionar

42

HINICIO_INS TIME 6Hora de inicio de lainspección

HINICIO_FIN TIME 7Hora de finalización dela inspección

GAS_MOV_INS NUMERIC 20

Información acerca delos gastos/movilizaciónde los inspectores

FEC_INS DATE 5Fecha de realización dela inspección

ESTADCLI_INS CHAR 9Estado de la inspeccióndel cliente

DIRCLI_INS BINARY 13Dirección donde se va arealizar la inspección

DEPENCLI_INS NU9MERIC 10 Dependencia del cliente

CONCLI_INS CHAR 21Información si existecontacto

COD_EMP NUMERIC 3 Código del empleadoCOD_CLI NUMERIC 4 Código del cliente

CANTELECTRCLI_INS NUMERIC 17

Cantidad deelectrodomésticos queposee el cliente

TIPOVNDACLI_INS CHAR 15Tipo de vivienda delcliente

OBSER_INS CHAR 18Información adicionalacerca de la inspección

Tabla 5.6. Tabla Inspeccion

TABLA TB_SOLICITUD

Contiene la información acerca de las solicitudes que los inspectores tienen que

revisar y chequear

43


PRIMARIA COD_SOL NUMERIC 5Identificación del códigode la solicitud

COD_CLI NUMERIC 5Identificación del códigodel cliente

COD_EMP NUMERIC 5Información del códigodel empleado

EST_SOL NUMERIC 5 Estado de la solicitud

FEC_SOL DATE 10 Fecha de la solicitud

Tabla 5.7. Tabla Solicitud

TABLA TB_USUARIOS

Contiene la información acerca de los usuarios que ingresan al sistema de

inspecciones


PRIMARIA COD_USER NUMERIC 5Identificación del códigodel usuario

NOM_USER CHAR 10Identificación delnombre del cliente

PASS_USER CHAR 10Información de la clavede usuario

COD_CAR NUMERIC 5Identificación del códigode cargo

Tabla 5.8. Tabla Usuarios

44

TABLA TB_VISITAS

Contiene la información acerca de las visitas que realizan los inspectores para

corroborar la información y otorgar el crédito


PRIMARIA COD_VST NUMERIC 5Identificación del códigode la visita

FEC_VST DATE 10

Identificación de lafecha de la visita delinspector

COD_CLI NUMERIC 5Información del códigodel cliente

COD_EMP NUMERIC 5Identificación del códigodel empleado

EST_VST CHAR 10 Estado de la visita

Tabla 5.9. Tabla Visitas

45

6. Casos de Uso.

6.1. Identificación de Casos de Uso.

En nuestro sistema de inspecciones móviles se han definido los siguientes

casos de uso los cuales tienen que ver con los eventos que realizan los actores

que interactúan con el sistema, de esta manera mostramos en forma gráfica

como se produce la relación entre los usuarios y los eventos:

A. Creación de usuarios.

B. Solicitud de cambio de contraseña.

C. Ingreso al sistema.

D. Obtener respaldos de la base de datos.

E. Generar la gestión de Rutas.

F. Realizar el manejo de visitas

G. Creación del sistema de Inspecciones

H. Verificación de Inspecciones

46

6.2. Descripción de Caso de Uso

6.2.1. Ingreso de Usuarios

Módulo de Inspecciones

Ingreso de Usuarios

Empresa: Su Crédito

Actores: El Administrador del Sistema.

Descripción:Creación de nuevos usuarios de acuerdo a las

necesidades de la empresa.

Acción del actor

1. El Administrador del Sistema registra

en el sistema un nuevo de usuarios.

2. El Administrador utiliza el sistema

para determinar los permisos del

nuevo usuario.

Respuesta del sistema

1. Presenta los datos del nuevo rol.

2. Asigna los permisos

seleccionados.

3. Se presentan los permisos

asignados.

Tabla 6.1. Tabla de Caso de uso de ingreso de usuarios

47

6.2.2. Ingreso de Solicitudes


Ingreso de Solicitudes

Actores: Usuario Ejecutivo de Crédito

Descripción:Es encargado del ingreso de solicitudes al

sistema.

Acción del actor

1. El Usuario ingresa debe estar

identificado en el sistema.

2. El Ejecutivo podrá a ingresar,

modificar, campos a una solicitud

existente los datos del cliente

3. Podrá consultar el estado de la la

solicitud.

4. Al presionar la opción GUARDA se

procederá a almacenar la información

correspondiente a la base de datos.


1. Verifica que Password y

contraseña estén correctos.

2. El sistema responde presentado

las el formulario de ingreso de

solicitudes.

4. Se contara con la restricción de

campos a modificar.

5. Esta opción solo permitirá la

visualización de la información

los campos estarán restringidos.

6. No se podrá eliminar solicitudes

ya ingresadas

Tabla 6.2. Tabla de caso de uso de ingreso de solicitudes

48

6.2.3. Supervisión de Inspecciones


Supervisión de Inspecciones

Actores: Supervisor de Inspecciones

Descripción:

Es encarga de realizar todos los

procesos asociados para realizar las

inspecciones.

Acción del actor

1. El Usuario ingresa debe estar

identificado en el sistema.

2. El supervisor esta encargado de la

verificación de los datos del cliente

necesarios para la inspección

3. Si los datos están completos el

supervisor procederá a la creación

de la Gestión de Rutas.

4. En la gestión de rutas el supervisor

evaluara la prioridad de la visita,

zona, ruta, tiempo asignado a cada

visita, etc.

5. Una vez generado el sistema de

rutas el supervisor mediante un




2. El sistema responde presentado las

el formulario de inspección.


visualización de la información los

campos estarán restringidos.

4. No contara con opciones de

modificación y eliminación de datos

del cliente.

5. Este proceso será generado por el

sistema.

6. Dependerá del número de visitas

pendientes.

49

proceso, se evaluara él número de

vistas que asignara a cada inspector.

6. El supervisor se encarga de proveer

al inspector en su dispositivo Palm o

Pocket la información

correspondiente a su trabajo diario.

7. Revisión de la inspección realizada.

8. Actualización de información a la

Base de datos.

7. Este proceso es realizado por

número de visitas por rutas

asignadas a cada zona.

8. Sincronización realizada al inicio de

la jornada de trabajo.

9. Sincronización de la información

una vez terminada la jornada de

trabajo.

10. Acción que se realiza cada vez

que se Guarden los datos no se

permitirá modificaciones ni

eliminaciones.

Tabla 6.3. Tabla de caso de uso de supervisión de inspecciones

50

6.2.4. Inspección

Modulo de Inspecciones

Inspección

Actores: Inspector

Descripción:Es encarga de realizar la inspección

de los datos del cliente en el sitio.

Acción del actor

1. El Usuario ingresa al sistema, debe

estar identificado en el sistema.

2. El inspector verifica la información

dada en el modulo de manejo de

vista con los datos actualizados al

inicio de la jornada.

3. Procederá a la revisión de las rutas

de visitas, para proceder a las

inspecciones

4. Realizadas las inspecciones se

procede a la sincronización de la

información en la base al finalizar la

jornada de trabajo.




2. El Sistema responde presentado

las opciones del manejo de visitas

y modelo de Inspecciones.


visualización de la información los

campos estarán restringidos.

4. No contara con opciones de

modificación y eliminación de datos

del cliente.

5. El formulario agilitara la labor del

inspector, constara con información

relevante del cliente.

51

6. Una vez culminada la inspección se

actualiza la información, la misma

que no podrá ser modificada.

7. Actualización de información a la

Base de datos.

Tabla 6.4. Tabla de caso de uso de inspección

1

CAPITULO 2

MANUAL DE USUARIO

SISTEMA MOBI INSPECTION V 1.0

52

2.1 INTRODUCCION

Este manual ha sido preparado con el fin de brindar a los usuarios finales del

Sistema de inspecciones, una guía sobre su operación.

El Sistema ha sido desarrollado de una forma sencilla de operar,

completamente intuitivo y amigable.

El sistema hace uso de los objetos de la interfase gráfica de Ventanas, por lo

cual si el usuario está familiarizado con el uso de Windows, ya conoce algo

del manejo del Sistema de Inspección

Si el usuario por primera vez va a interactuar con una PC, bastará con una

explicación muy breve para que inmediatamente opere el Sistema.

Este manual da una explicación de las funciones que pueden ser realizadas

dentro de cada modulo y pautas para obtener el mayor provecho del

sistema.

53

2.2 DESCRIPCION DEL SISTEMA

Al ingresar al sistema Inmediatamente aparecerá la pantalla de inicio de la

sesión. El sistema consta con 2 tipos de usuarios Supervisor e Inspectores.

Se debe ingresar el usuario asignado y clave, presione a continuación el

botón

Figura 1.

Presentara la confirmación de ingreso del Usuario, aparecerá el menú

principal del sistema (figura 3)

Figura 2.

54

A continuación el sistema mostrara el menú principal, que consta de:

2.2.1 Menú Cliente

2.2.2 Menú guía

2.2.3 Menú de Reportes

2.2.4 Menú Help

Iremos revisando a detalle cada uno de estos módulos

Figura 3.

55

2.2.1 Descripción Menú Inspección, detalla las opciones,

2.2.1.1 Cliente

2.2.1.2 Supervisores

2.2.1.3 Syncusr

2.2.1.4 Sync

2.2.1.5 Salir

Figura 4.

56

2.2.1.1 Submenú Cliente

Muestra el listado de los clientes a inspeccionar, ya sea un cliente

nuevo o aquel que tiene Pendiente la inspección, muestra el Nombre

del Cliente, la dirección, y el nombre del inspector.

Figura 5.

Al presionar el botón BUSCAR, muestra el cliente a

inspeccionar.

Salir de la inspección.

57

Y se procede a cargar en una nueva plantilla de la inspección con

toda la información que se necesita para verificar dicha inspección,

Figura 6.

la misma consta con los datos personales del cliente, cada item tiene a

la derecha una CASILLA DE VERIFICACIÓN, la cual sensa si la

información otorgada por el cliente al momento que el inspector realiza

la visita es correcto o no, se debe ingresar el NOMBRE DEL

CONTACTO, que es la persona que otorga dicha la información

58

Una vez verificados los Datos Personales procedemos a verificar los

BIENES que posee el cliente dando CLIC en el siguiente TAB

Figura 7.

En la siguiente plantilla de la inspección se procede a verificar los bienes

que posee el cliente, adicional a esto se debe ingresa el NUMERO DE

ELECTRODOMESTICOS.

59

Una vez validad la información del cliente es decir concluida la inspección

se procede a validar el GASTO DE MOVILIZACIO que se genero en dicha

inspección.

Figura 8.

Presiona el Botón Ingreso

El mismo que me permite validar la inspección a la base de datos, a

continuación muestra un mensaje que indica que la inspección fue

realizada.

Figura 9.

60

2.2.1.3 Submenu Syncusr

La sincronización permite mantener actualizada su base de datos

enviando y recibiendo la información correspondiente este menú

presenta una sincronizacion Paso a paso.

Al iniciar el proceso, Ud. enviará y recibirá todos los cambios que se

realizaron en la inspección desde su última actualización. De este

modo toda la red de créditos estará al día con los datos.

Figura 10.

61

Acciones:

Para iniciar el proceso de actualización, simplemente deberá acceder

a la sección de Sincronización en el menú INSPECCION y presionar el

botón "OK".

Al cabo de un momento, el proceso finaliza y su base de datos se

encuentra actualizada y sus datos habrán sido enviados a nuestros

servidores, para que el resto de los clientes bajes la información.

Figura 11. Figura 12.

El tiempo que tarda un proceso de actualización puede variar entre

unos pocos segundos y algunos minutos. Esta variación se debe a la

62

cantidad de información que se debe descargar y enviar en cada

sincronización.

Si Ud. sincroniza su sistema en periodos cortos, entonces habrá

menos datos para descargar.

Al finaliza la sincronización estarán los datos actualizados en su Base

de Datos Remota.

Figura 13.

63

2.2.1.4 Submenu Sys

La sincronización permite mantener actualizada su base de datos

enviando y recibiendo la información correspondiente este menú

presenta una sincronización automática.

Figura 14

.

64

2.2.1.2 Submenú Supervisores

Esta opción esta activa cuando se el supervisor ingresa con su usuario

al sistema, el podrá ver toda la información que ha generado el

inspector, en cada una de las vistas realizadas.

Figura 15

2.2.1.5 Submenú Salir

Permite salir del sistema Inspecciones

65

2.2.2 Descripción Menú Guía, detalla las opciones,

2.2.2.1 RUTAS

Esta opción muestra la ruta de visita que cada inspector tiene

asignada.

Figura 16.

Figura 16.

66

Esta es una guía para el inspector, ya que presenta la dirección del

cliente el sector al que esta asignado, ya sea este norte, Sur, Este, etc.,

Figura 17.

Seleccionar el cliente que se desea inspeccionar presionando el botón

BUSCAR

Para salir de la aplicación presione el botón EXIT

67

El siguiente mensaje describe la ruta donde se encuentra almacenado el

croquis de la dirección del cliente, dar clic en ACEPTAR

Figura 18.

Y verifica la dirección exacta en el grafico.

Figura 19.

68

2.2.3 Descripción Menú Reporte, detalla las opciones,

2.2.3.1 Gastos

2.2.3.2 Visitas

2.2.3.3 CheckTime

Figura 20.

69

2.2.3.1 Submenú Gastos

Este modulo muestra la suma de los gastos generales, realizados en

cada una de las inspecciones de cada inspector, permite al

departamento de Créditos llevar un control de los gastos exactos que

se genero en las inspecciones

Figura 21.

70

2.2.3.2 Submenú Vistas

En este reporte se muestra las visitas realizadas y las Vistas

Pendientes generadas en el día, esto permitirá al Departamento de

Inspecciones programar una nueva visita para el cliente especificado.

Figura 22.

71

2.2.3.3 Submenú CHECKTIME

Muestra la el reporte de las horas generadas en Cada una de las

inspecciones, permite llevar un control de cada uno de los inspectores

Figura 23.

72

2.2.4 Descripción Menú Help

Detalla la versión del sistema, el propietario del mismo y el nombre de los

integrantes de proyecto, desarrolladores del sistema

Figura 24.

Figura 25

UNIVERSIDAD DE GUAYAQUIL -...

Documents

Transcript of UNIVERSIDAD DE GUAYAQUIL -...