FACULTAD DE NEGOCIOS C-IV

SEMINARIO DE TITULACIÓN

LICENCIATURA EN SISTEMAS COMPUTACIONALES

SEMINARIO DE TITULACIÓN
PROGRAMACIÓN DE APLICACIONES EMPRESARIALES

TITULO:
PROPUESTA Y PROTOTIPO DEL DISEÑO DE UN SISTEMA DE CONTROL
INTERNO PARA UNA FINANCIERA

AUTOR:
ALEXIS RONAY GARCÍA HERNÁNDEZ
JOSE GUADALUPE MENDEZ DE LA CRUZ

MTRO. RENE SERVANDO RIVERA ROBLERO

1
 DEDICATORIA DE RESPONSABILIDAD

Los conceptos, análisis, conclusiones y recomendaciones realizadas en este

trabajo son exclusiva responsabilidad de Alexis Ronay García Hernández y José
Guadalupe Méndez De La cruz.

A través de esta declaración, cedemos los derechos de propiedad intelectual

correspondiente a este trabajo a la Universidad Autónoma De Chiapas, Facultad De
Negocios C-IV, según lo establecido por la ley de propiedad intelectual, por su
reglamento y normativa institucional vigente.

Alexis Ronay García Hernández José G. Méndez De La Cruz

2
INDICE DE CONTENIDOS

Capítulo 1 ----------------------------------------------------------- ----------------6

INTRODUCCION -------------------------------------------------- -----------------6
1.1 Planteamiento del problema ------------------------------------------------6
1.2 Justificación ---------------------------------------------------- ----------------8
1.3 Objetivos --------------------------------------------------------- ---------------9
1.3.1 Objetivo General ---------------------------------------------- --------------9
1.3.2 Objetivos Específicos ------------------------------------------------------9
1.4 Preguntas de investigación ------------------------------------- ------------9
Capítulo 2 ---------------------------------------------------------------- ----------11
MARCO TEORICO ------------------------------------------------------- ---------11
2.1 Antecedentes históricos -------------------------------------------------- --11
2.2 Prestamos ------------------------------------------------------------------- --12
2.3 Elementos que conforman un préstamo ---------------------------------12
2.4 Cartera de clientes ---------------------------------------------------------- -13
2.5 Las Tics en las microfinanzas -------------------------------------------- -13
2.6 Software y herramientas para el proyecto ------------------------------14
2.6.1 Java ---------------------------------------------------------------- ----------14
2.6.2 NetBeans --------------------------------------------------------- -----------14
2.6.3 PostgreSQL ----------------------------------------------------- ------------15
Capítulo 3 ------------------------------------------------------------- -------------16
METODOLOGIA ----------------------------------------------------- --------------16
3.1 Ciclo de vida de un sistema de información ----------------------------16
3.1.1 Planificación ------------------------------------------------ ----------------16
3.1.2 Análisis ----------------------------------------------------- -----------------17
3.1.3 Diseño ----------------------------------------------------- ------------------17
3.1.4 Implementación ----------------------------------------- -------------------17
3.1.5 Pruebas -------------------------------------------------- --------------------17

3
3.1.6 Instalación o despliegue ------------------------------------------------- 17
3.1.7 Uso y mantenimiento ----------------------------------------------------- 18
3.2 Ciclo de vida clásico. Modelo en cascada ------------------------------18
Capítulo 4 -------------------------------------------------------------------------- 19
DISEÑO Y DESARROLLO DEL SISTEMA -----------------------------------19
4.1 Especificación de requerimientos ----------------------------------------- 19
4.1.2 Requerimientos funcionales --------------------------------------------- 19
4.1.2 Requisitos no funcionales ------------------------------------------------21
4.1.3 Identificación de los Actores del Sistema -----------------------------21
4.2 Descripción de los casos de uso ------------------------------------------ 22
4.2.1 Gestión de usuario ------------------------------------------- --------------22
Caso de Uso: Ingresar un nuevo usuario ------------------------------------22
Caso de Uso: Iniciar sesión de usuario ---------------------------------------23
Caso de Uso: Mostrar usuario registrado -------------------------------------24
Caso de Uso: Modificar usuario registrado -----------------------------------25
4.2.2 Gestión de cliente ---------------------------------------------------------- 26
Caso de Uso: Ingresar un nuevo cliente --------------------------------------26
Caso de Uso: Mostrar cliente registrado --------------------------------------26
Caso de Uso: Modificar cliente registrado ------------------------------------27
4.2.3 Gestión de informe --------------------------------------------------------- 28
Caso de Uso: Emitir un informe de los clientes
mediante un archivo PDF -------------------------------------------------------- 28
Caso de Uso: Emitir un informe mediante una gráfica del
estatus del cliente ------------------------------------------------ -----------------28
4.3 Modelo Entidad / Relación -------------------------------------------------- 29
4.3.1 Descripción Lógica de las Entidades -----------------------------------31
4.3.2 Modelo Relacional ------------------------------------------------- ---------31
4.4 Descripción de las pruebas realizadas -----------------------------------33

4
4.4.1 Casos de Prueba ----------------------------------------------------------- 33
Hacer Login -------------------------------------------------------------------- -----33
Ingresar Nuevo Usuario ---------------------------------------------------------- 34
Ingresar Nuevo Cliente ----------------------------------------------------------- 34
Mostrar Grafica del Estatus del Cliente ---------------------------------------35
Capítulo 5 --------------------------------------------------------------------------- 36
CONCLUSIONES Y TRABAJO A FUTURO ----------------------------------36
5.1 Conclusiones ------------------------------------------------- ------------------36
5.2 Trabajo futuro ------------------------------------------------ ------------------37
BIBLIOGRAFÍA -------------------------------------------------------------------- 38

5
Capítulo 1

INTRODUCCION

En el presente trabajo denominado “Propuesta Y Prototipo Del Diseño De Un

Sistema De Control Interno Para Una Financiera” se describe el desarrollo de una
herramienta de Software que puede ser empleada en una pyme, con objeto de servir
como apoyo tecnológico que permita automatizar procesos que dicha herramienta
provee.

Se abordan temas de interés intelectual tales como el impacto de las financieras en

la sociedad, las clasificaciones de los préstamos, las tecnologías de información,
las aplicaciones de escritorio y su grado de penetración en el mercado comercial a
nivel mundial; así como también temas de carácter técnicos que veremos en los
capítulos posteriores.

1.1 Planteamiento del problema.

Toda empresa necesita estar informada sobre su situación, para poder
determinar y evaluar la gestión realizada por todos los agentes que intervienen en
su funcionamiento, es fundamental que en cada una de estas instancias se tome en
cuenta las herramientas necesarias para su rendimiento. Es por ello que el manejo
de los datos debe ser correcto para que al final del periodo de operaciones por los
administradores nos permita realizar un análisis financiero para facilitar la toma de
decisiones de inversiones, los planes de acción y control de operaciones.

Bajo esta primicia los directivos de la empresa deben conocer los principales
métodos que se utilizan para lograr una evidente efectividad en el manejo de los
datos para optimizar la toma de decisiones. Con el estudio minucioso de los
procesos se permitirá evaluar objetivamente el trabajo de organización, determinar
las oportunidades de crecimiento y perfeccionar los servicios, métodos y estilos de
dirección.

6
 En Yo Contigo se maneja un movimiento considerable de cuentas por cobrar
debido a que aumenta el volumen de sus ventas relacionadas con los créditos;
constituyendo este un rubro de gran relevancia para la misma. Los procedimientos
administrativos no se están aplicando en su totalidad con la empresa debido a que
es un poco primitivo, el manejo de sus clientes lo hacen mediante un libro en Excel,
ahí tienen los nombres de los clientes, el nombre del asesor, el giro de negocio, el
monto del préstamo y la fecha de inicio y termino (estas se calculan de manera
manual).

Para la recuperación de los pagos se le otorga al asesor una lista de los

clientes por cobrar. Al término de la jornada se le da una papeleta de reporte y la
cantidad de clientes que tiene por cada monto del préstamo, ahí es donde el asesor
reporta lo recuperado en el día, los clientes que no realizaron su pago, los clientes
que recuperaron pagos y los clientes que adelantaron pagos.

7
1.2 Justificación

Debido a los recientes problemas que han surgido en Yo Contigo, como lo

son las inconformidades de algunos clientes con la fecha de vencimiento del crédito,
el faltante de ingreso de algunos pagos de los clientes, incluso faltante de dinero en
algunos asesores; se realizara un análisis donde recopilaremos datos de todos los
procesos de cobro, el manejo de los clientes y el ingreso de los pagos del cliente
para así poder implementar la mejora de los procesos brindando a la empresa un
mejor manejo de la misma. Se justifica la elaboración de un sistema de control
interno para la gestión de cobro y de clientes porque su aplicación sería muy
importante para el desarrollo y funcionamiento de la empresa, donde los
administrativos tendrían un control más amplio de sus funciones, conocerían la
situación en la que se encuentra cada cartera, todo esto facilitaría la toma de
decisiones hacia la productividad de Yo Contigo.

8
1.3 Objetivos

1.3.1 Objetivo General

Diseñar un sistema de control interno que permita la reestructuración del

manejo de las carteras de clientes, plantear un modelo de procedimientos aptos
para su aplicación en la gestión de los clientes; este mismo deberá permitir una
eficiente supervisión y monitoreo de los procesos para una recuperación de cartera
rápida y efectiva. Tener el conocimiento del desempeño de los asesores respecto
al número de clientes que tienen a cargo y en base a eso definir el sueldo de cada
uno de ellos.

1.3.2 Objetivos Específicos

- Desarrollar interfaces atractivas y fáciles de operar.

- Permitir que el Administrador ingrese, liste, modifique usuarios.

- Permitir el ingreso, visualización y modificación de los clientes.

- Permitir un informe de graficas del estatus del cliente.

1.4 Preguntas de investigación

1.- ¿Cuál fue su objetivo para crear su negocio o empresa?

Contar con un ingreso económico estable y contribuir con el desarrollo

económico de la región.

2.- ¿Está a gusto con su empresa?

Existen algunas inconformidades con el desempeño de la empresa, porque

a medida que crece también demanda un mejor manejo de administración

3.- ¿Utilizó algún medio de comunicación para difundir su negocio?

Mediante pequeños volantes

9
4. ¿Ud. tiene conocimiento y dominio de la computadora?

sí, cuento con estudio en computación

5.- ¿Cómo está organizada su empresa?

Contamos con una persona a cargo con la función de verificar el desempeño

de los asesores, entregar los créditos, verificar si las solicitudes nuevas son sujetas
a un crédito, así como también hacer el corte de caja al final del día, contamos con
3 asesores que se encargan de recuperar los pagos diarios de los créditos vigentes,
así como la recaudación de clientes nuevos.

6.- ¿Cómo manejan la información?

La lista de clientes se maneja en un libro de Excel con los datos personales

de cada uno, así como las fechas de inicio y finalización, el monto del crédito y el
monto del pago diario a realizar

7.- ¿Quiénes tienen acceso a la información?

Solo el encargado ya que él tiene la función de administrar los clientes como

ingresarlos o eliminarlos si han concluido.

8.- ¿Cada cuanto actualizan los registros de la información almacenada?

Diariamente

9.- ¿Cuál es la problemática que buscan solucionar a través del sistema de control?

Tener un mejor control de los clientes y sus pagos realizados ya que han
existido algunas inconformidades con el cliente de acuerdo con pagos realizados

10.- ¿Quiénes tendrán acceso al sistema de información?

El administrador y un capturista

11.- ¿Se ha implementado anteriormente un sistema parecido?

No, ninguno

10
12.- ¿Con cuanto presupuesto cuentan para invertir en la compra del sistema de

información?

El necesario para que la empresa cuente con un mejor funcionamiento

13.- ¿De qué equipos de cómputo disponen para facilitar la implementación del

sistema de información?

Un pc de escritorio (se le especifico que en el caso de abrir carteras en otros

municipios se deberá contar con un servidor para poder llevar a cabo un
funcionamiento más optimo)

Capítulo 2

MARCO TEÓRICO

2.1 Antecedentes históricos

A comienzo del año 2020 un integrante de la familia Ruiz trabajaba en una

empresa de préstamos Crefiser que por años se mantuvo en el municipio, pero
al final debido a un mal manejo de los encargados ya no pudo prosperar. Al cabo
de un tiempo y con los conocimientos previos sobre el rubro financiero, se
convenció para emprender un nuevo proyecto que con el apoyo de algunos
inversionistas dio paso a la financiera denominada Yo Contigo.

Julio Ruiz convencido de su proyecto comenzó con un pequeño estudio de

mercado en la localidad aprovechando su basto conocimiento sobre el rubro.
Después de recabar información como el monto del pago de otras financieras
respecto al crédito que ofrecían, pudo encontrar un interés sobre el crédito que
el ofrecería acorde al tiempo y las necesidades de su potencial cliente los
micronegocios.

Después de más de un año de otorgar préstamos a micronegocios de la

localidad y de la mano del constante crecimiento decidió implementar un sistema
que le ayude al control de los clientes y a la evolución misma de su empresa.
11
2.2 Prestamos

Un préstamo es una operación financiera por la cual una persona (prestamista)

otorga mediante un contrato o acuerdo entre las partes, un activo (normalmente una
cantidad de dinero) a otra persona (prestatario), a cambio de la obtención de un
interés (precio del dinero).

Los préstamos se consideran una operación financiera de prestación única

(principal) y contraprestación múltiple (abono de las cuotas). La amortización, es
decir, la devolución paulatina del préstamo se hará de acuerdo con la duración,
interés y acuerdos alcanzados que permitan devolver el principal del préstamo con
los intereses.

Los préstamos podemos dividirlos en varias clases en función de su naturaleza. Así

pues, diremos que es un préstamo simple si no se pagan periódicamente intereses,
o un préstamo con sistema americano si existe el pago periódico de intereses.
Existen varios métodos de amortización financiera. Además, en ocasiones los
préstamos son de prestación y contraprestación única, ya que se pacta la
devolución total con un interés al final de la duración de este, es decir, sin el abono
de cuotas.

2.3 Elementos que conforman un préstamo

Estas son los principales conceptos que debemos conocer a la hora de recibir o
trabajar con préstamos:

• Capital principal: Es la cantidad de dinero que se ha prestado y sobre la

cual se pagará un interés en función de la duración del préstamo y riesgo del
adquiriente del préstamo.

• Interés: Es el coste financiero del préstamo, es decir, el precio del dinero. Es

el cargo que se cobra por la utilización de dinero o capital ajeno durante un
tiempo, y viene representado en porcentaje sobre el principal.

12
 • Cuota: Cada uno de los pagos de devolución donde vengan repartidos el
principal y el interés.

• Plazo: Es el tiempo durante el cual se va a utilizar el préstamo. El plazo

contará desde que se inicia el contrato hasta que se abone la última cuota,
devolviendo así la totalidad del principal y sus intereses.

• Prestamista: Es el agente que presta el dinero, y al cual debe devolverse

junto a unos intereses.

• Prestatario: Persona que recibe el capital y debe devolverlo conforme a lo

pactado, junto a unos intereses.

Tanto el prestamista como el prestatario pueden ser personas físicas o personas

jurídicas.

2.4 Cartera de clientes

Una cartera de clientes es un grupo selecto de personas con características

comunes respecto a ingresos y comportamientos de consumo, que permite a las
empresas diseñar y ofrecerles nuevas oportunidades de negocio.

Una cartera de clientes se materializa en la sistematización y actualización de datos,

para lo cual, el agente “dueño” de esta cartera debe mantener al día un registro con
información de utilidad.

2.5 Las Tics en las microfinanzas

El empleo de las Tecnologías de Información y Comunicación (TIC) se convierte en

un elemento vital en las organizaciones; su uso ha transformado la forma de hacer
negocios y sobre todo se ha convertido en una ventaja competitiva que soporta el
desarrollo y crecimiento económico de las empresas.

13
Es necesario para las empresas contar con información precisa de las principales
actividades de sus competidores y clientes, debido a la dinámica innovadora que
marca la pauta para su crecimiento y evolución como organización.

2.6 Software y herramientas para el proyecto

2.6.1 Java

Java es un tipo de lenguaje de programación y una plataforma informática, creada

y comercializada por Sun Microsystems en el año 1995.

Se constituye como un lenguaje orientado a objetos, su intención es permitir que los

desarrolladores de aplicaciones escriban el programa una sola vez y lo ejecuten en
cualquier dispositivo.

El enfoque orientado a objetos (OO) es uno de los estilos de programación más

populares. Permite diseñar el software de forma que los distintos tipos de datos que
se usen estén unidos a sus operaciones.

El Java permite diseñar softwares que podrán ser ejecutados y distribuidos en las
diferentes plataformas (MAC, Linux, Windows, etc.), sin la necesidad de modificarlos
e incluso sin pensar en la arquitectura de la máquina.

2.6.2 NetBeans

NetBeans es un entorno de desarrollo integrado libre, orientado principalmente al

desarrollo de aplicaciones Java. La plataforma NetBeans permite el desarrollo de
aplicaciones estructuradas mediante un conjunto de componentes denominados
“módulos”. Cada uno de estos módulos sería un archivo Java conteniendo un
conjunto de clases que interactuarán con las APIs de NetBeans. El objetivo de esta
arquitectura es favorecer el desarrollo de funcionalidades de forma independiente y
la reutilización de componentes.

14
Las principales características de NetBeans son las siguientes:

• Proporciona una base modular y extensible para el desarrollo de

aplicaciones, la Plataforma NetBeans.

• Esta plataforma incluye servicios para el control del interfaz de usuario, la

configuración, el almacenamiento, las ventanas, etc. El IDE está desarrollado
con la misma metodología modular, por lo que puede extenderse incluyendo
módulos con funcionalidades determinadas.

• Aunque está ideado para el desarrollo Java, permite el desarrollo en otros

lenguajes, como PHP o Python, mediante paquetes adicionales.

2.6.3 PostgreSQL

PostgreSQL es un gestor de bases de datos relacional y orientado a objetos. Su

licencia y desarrollo es de código abierto, siendo mantenida por una comunidad de
desarrolladores, colaboradores y organizaciones comerciales de forma libre y
desinteresadamente. Esta comunidad es denominada PDGD (PostgreSQL Global
Development Group, por sus siglas en inglés).

Es reconocido actualmente como uno de los sistemas gestores de bases de datos

relacionales más potentes del mercado. Presenta fácil accesibilidad, es
multiplataforma y está disponible para su utilización en casi todos los sistemas
operativos utilizados en la actualidad sin disminuir su rendimiento.

Siendo uno de los sistemas de bases de datos más avanzados y usados del mundo,
es obvio que PostgreSQL debe tener algunas características bastante llamativas,
así que vamos a echarle un vistazo a algunas de ellas.

• Es de código abierto: una de las principales razones por la cual PostgreSQL

se ha vuelto tan popular es que se trata de un sistema de código abierto. Esto
ha permitido que una gran comunidad de desarrolladores crezca para
respaldarlo y continuar mejorándolo.

• Es gratuito: como cabe esperarse se trata de un sistema totalmente gratis,

no tenemos que pagar nada por utilizarlo.
15
 • Es multiplataforma: una característica genial que de hecho es común en
muchos grandes proyectos de código abierto es el hecho de que se trata de
software multiplataforma, es decir, es un software que puede correr bajo
distintos entornos y sistemas operativos, y es compatible con muchos de los
servidores web más populares como Apache.

• Puede manejar un gran volumen de datos: una característica

extremadamente importante de PostgreSQL es su gran capacidad para el
manejo de grandes volúmenes de datos, algo en lo que otros sistemas como
MySQL aún no hacen tan bien. Las bases de datos de gran tamaño pueden
hacer pleno uso del MVCC de PostgreSQL, resultando en un gran
rendimiento. MVCC es un método de control que nos permite realizar tareas
de escritura y lectura simultáneamente.

Capítulo 3

METODOLOGIA

3.1 Ciclo de vida de un sistema de información

Es un sistema, automatizado o manual, que engloba a personas, máquinas y/o

métodos organizados para recopilar, procesar, transmitir datos que representan
información. Un sistema de información engloba la infraestructura, la organización,
el personal y todos los componentes necesarios para la recopilación,
procesamiento, almacenamiento, transmisión, visualización, diseminación y
organización de la información.

Cualquier sistema de información va pasando por una serie de fases a lo largo de

su vida. Su ciclo de vida comprende una serie de etapas entre las que se encuentran
las siguientes:

3.1.1 Planificación

Realizar una serie de tareas previas que influirán decisivamente en la finalización

con éxito del proyecto.

16
3.1.2 Análisis

Averiguar qué es exactamente lo que tiene que hacer el sistema. La etapa de

análisis en el ciclo de vida del software corresponde al proceso mediante el cual se
intenta descubrir qué es lo que realmente se necesita y se llega a una comprensión
adecuada de los requerimientos del sistema.

3.1.3 Diseño

Se han de estudiar posibles alternativas de implementación para el sistema de

información que hemos de construir y se ha de decidir la estructura general que
tendrá el sistema (su diseño arquitectónico). El diseño de un sistema es complejo y
el proceso de diseño ha de realizarse de forma iterativa.

3.1.4 Implementación

Seleccionar las herramientas adecuadas, un entorno de desarrollo que facilite

nuestro trabajo y un lenguaje de programación apropiado para el tipo de sistema
que vayamos a construir. La elección de estas herramientas dependerá en gran
parte de las decisiones de diseño que hayamos tomado hasta el momento y del
entorno en el que nuestro sistema deberá funcionar.

3.1.5 Pruebas

Tiene como objetivo detectar los errores que se hayan podido cometer en las etapas
anteriores del proyecto (y, eventualmente, corregirlos). La búsqueda de errores que
se realiza en la etapa de pruebas puede adaptar distintas formas, en función del
contexto y de la fase del proyecto.

3.1.6 Instalación o despliegue

Debemos de planificar el entorno en el que el sistema debe funcionar, tanto

hardware como software: equipos necesarios y su configuración física, redes de
interconexión entre los equipos y de acceso a sistemas externos, sistemas
operativos y bibliotecas.

17
Estas etapas son un reflejo del proceso que se sigue a la hora de resolver cualquier
tipo de problema.

3.1.7 Uso y mantenimiento

La etapa de mantenimiento consume típicamente del 40 al 80 por ciento de los

recursos de una empresa de desarrollo de software. De hecho, con un 60% de
media, es probablemente la etapa más importante del ciclo de vida del software.

• Eliminar los defectos que se detecten durante su vida útil, lo primero que a
uno se le viene a la cabeza cuando piensa en el mantenimiento de cualquier
cosa.

• Adaptarlo a nuevas necesidades cuando el sistema ha de funcionar sobre

una nueva versión del sistema operativo o en un entorno hardware diferente.

• Añadirle nueva funcionalidad, cuando se proponen características deseables

que supondrían una mejora del sistema ya existente.

3.2 Ciclo de vida clásico. Modelo en cascada

El modelo de ciclo de vida clásico, también denominado «modelo en cascada», se

basa en intentar hacer las cosas bien desde el principio, de una vez y para siempre.
Se pasa, en orden, de una etapa a la siguiente sólo tras finalizar con éxito las tareas
de verificación y validación propias de la etapa. Si resulta necesario, únicamente se
da marcha atrás hasta la fase inmediatamente anterior.

Este modelo tradicional de ciclo de vida exige una aproximación secuencial al

proceso de desarrollo del software.

• Los proyectos reales raramente siguen el flujo secuencial de actividades que

propone este modelo.

• Normalmente, es difícil para el cliente establecer explícitamente todos los

requisitos al comienzo del proyecto (entre otras cosas, porque hasta que no
vea evolucionar el proyecto no tendrá una idea clara de qué es lo que
realmente quiere).

18
 • No habrá disponible una versión operativa del sistema hasta llegar a las
etapas finales, por lo que la rectificación de cualquier decisión tomada
erróneamente en las etapas iniciales del proyecto supondrá un coste
adicional significativo, tanto económico como temporal.

Ciclo de vida clásico de un sistema de información, modelo en cascada

Capítulo 4

DISEÑO Y DESARROLLO DEL SISTEMA

4.1 Especificación de requerimientos

4.1.2 Requerimientos funcionales

El primer reto del trabajo de los requisitos es encontrar, comunicar y registrar

lo que se necesita realmente, de manera que tenga un significado claro para los
miembros del equipo de desarrollo”. Los requerimientos se clasifican en las
siguientes categorías:

19
Evidente: Debe realizarse, y el usuario debería saber que se ha realizado.

Oculta: Debe realizarse, aunque no es visible para los usuarios. Esto se aplica a
muchos servicios técnicos subyacentes, como guardar información de un
mecanismo persistente de almacenamiento. Las funciones ocultas a menudo se
omiten (erróneamente) durante el proceso de obtención de requerimientos.

Superflua: Opcionales: su inclusión no repercute significativamente en el costo, ni

en otras funciones

Para mayor claridad, los requerimientos se han agrupado en tres áreas,

1.- Gestión de Usuario:

• Ingresar un nuevo usuario.

• Mostrar usuario registrado.
• Iniciar sesión de usuario.
• Modificar usuario registrado

2.- Gestión de Cliente:

• Ingresar un nuevo cliente

• Mostrar cliente registrado
• Modificar cliente registrado

3.- Gestión de Informe

• Emitir un informe de los clientes mediante un archivo PDF.

• Emitir un informe mediante una gráfica del estatus del cliente.

20
4.1.2 Requisitos no funcionales

Tiempo de respuesta:

• Para iniciar sesión de usuario con root - contraseña y aparezca el entorno de

trabajo, el sistema no deberá tardar más de 10 segundos.
• Para que aparezca el listado de clientes, el sistema no deberá tardar más de
20 segundos.
• Cuando se realice una consulta, el sistema no tardará más de 15 segundos.
• Cuando se realice un registro, modificación o eliminación, el sistema no
deberá tardar más de 12 segundos.

Sistema operativo:

• Windows 10

Seguridad:

• Confidencialidad: El acceso a los datos del sistema está limitado a usuarios

autorizados.
• Integridad: Los datos del sistema sólo pueden ser borrados o modificados
por usuarios autorizados.
• Disponibilidad: El acceso a los datos en un tiempo razonable está
garantizado para usuarios autorizado

4.1.3 Identificación de los Actores del Sistema

Un actor es cualquier entidad con comportamientos, incluyendo el propio

sistema que se está estudiando cuando solicita los servicios de otros sistemas. Los
actores no son solamente roles que juegan personas, sino también organizaciones,
software y máquinas.

A través del análisis de requerimientos, se definió que los actores del sistema
serán los siguientes: Administrador y capturista. A continuación, se detallan las
características de cada actor.

21
Administrador:

Este perfil corresponde al administrador del sistema, el cual cuenta con

acceso a toda la información del entorno. Podrá ingresar, modificar y eliminar datos
de la aplicación. Este actor tiene la facultad de crear cuentas de usuarios para los
capturistas y otros administradores, también generar reportes y gestionar los
clientes existentes

Capturista:

Este perfil corresponde al capturista del sistema, el cual cuenta con acceso
únicamente a la información del panel capturista en el cual podrá ingresar y
modificar únicamente los datos de los clientes, también podrá hacer el reporte en
PDF y la gráfica.

4.2 Descripción de los casos de uso

La escritura de casos de uso –historia del uso de un sistema- es una técnica

excelente para entender y describir los requisitos.”. “Informalmente entonces, un
caso de uso es una colección de escenarios con éxito y fallo relacionados, que
describe a los actores utilizando un sistema para satisfacer un objetivo

4.2.1 Gestión de usuario

Caso de Uso: Ingresar un nuevo usuario.

Actores: Administrativo.

Tipo: Primario.

Propósito: Registrar un nuevo usuario.

Resumen: El administrador debe ingresar los datos requeridos para el registro del
usuario. El sistema valida los datos ingresados, que los campos no estén vacíos,
verifica que no se encuentren registrados y los almacena.

22
CURSO NORMAL DE EVENTOS

1.- Este caso de uso comienza cuando el administrador desea ingresar un nuevo
usuario.

2.- El sistema despliega el formulario para el ingreso de usuario.

3.- El gerente ingresa los datos requeridos: id_usuario, nombre, apellidos, teléfono,
correo electrónico, username, contraseña, el tipo de usuario (administrador o
capturista) y el estatus a registrar.

4.- El sistema verifica que los datos ingresados sean válidos.

5.- El sistema verifica que el root del usuario a registrar no exista en el sistema.

6.- El sistema almacena los datos del nuevo usuario.

CURSO ALTERNATIVOS

1.- El sistema detecta un dato no válido o un campo vacío entonces el sistema

muestra un mensaje descriptivo para el usuario.

2.- El root ya existía. El sistema muestra un mensaje descriptivo para el usuario.

Caso de Uso: Iniciar sesión de usuario.

Actores: Administrador, capturista.

Tipo: Primario.

Propósito: Permitir al administrador o capturista ingresar al sistema.

Resumen: El administrador o capturista deben ingresar su root y contraseña. El

sistema verifica que el root y contraseña sean correctos, además de estar
previamente almacenados. Posteriormente el sistema muestra el entorno de trabajo
correspondiente al usuario.

23
CURSO NORMAL DE EVENTOS

1.- Este caso de uso comienza cuando el administrador o capturista desea iniciar
sesión.

2.- El administrador o capturista ingresa su root y contraseña.

4.- El sistema verifica que el root y la contraseña, sean válidos.

5.- El sistema verifica que el root exista en el sistema.

6.- El sistema muestra el entorno de trabajo correspondiente al usuario iniciado.

CURSOS ALTERNATIVOS

4.- El sistema detecta un dato no válido, entonces el sistema muestra un mensaje

descriptivo para el usuario.

5.- El root no existe o la contraseña es incorrecta. El sistema muestra un mensaje

descriptivo para el usuario.

Caso de Uso: Mostrar usuario registrado

Actores: Administrativo.

Tipo: Primario.

Propósito: Conocer los datos de un usuario registrado en el sistema.

Resumen: El administrador selecciona el botón gestionar usuarios. El sistema

muestra un formulario con los datos de los usuarios ingresados, posteriormente
selecciona un usuario y le despliega los datos del usuario seleccionado.

CURSO NORMAL DE EVENTOS

1.- Este caso de uso comienza cuando el administrador desea conocer los datos de
un usuario registrado en el sistema.

24
2.- El sistema despliega una lista con los datos de los usuarios, ordenados por el
id_usuario.

3.- El gerente selecciona el usuario que desea consultar.

4.- El sistema despliega, del usuario seleccionado, un formulario con todos los datos
de la consulta

Caso de Uso: Modificar usuario registrado

Actores: Administrativo.

Tipo: Primario.

Propósito: Modificar uno o todos los datos de un usuario registrado en el sistema.

Resumen El administrador selecciona, de una lista, el usuario a modificar. El

sistema muestra un formulario con los datos del usuario seleccionado, permitiendo
que sean modificados. El administrador ingresa los datos que desea modificar. El
sistema verifica que los datos sean válidos y los almacena.

CURSO NORMAL DE EVENTOS

1.- Este caso de uso comienza cuando el administrador desea modificar uno o todos
los datos de un usuario registrado.

2.- El sistema despliega una lista con todos los datos.

3.- El administrador selecciona el usuario que desea modificar.

4.- El sistema despliega un formulario con los datos del usuario en forma editable.

5.- El gerente cambia el o los datos que estime necesario.

6.- El sistema verifica que los nuevos datos ingresados, sean válidos.

7.- El sistema almacena los nuevos datos del usuario registrado.

CURSOS ALTERNATIVOS

6.- El sistema detecta un dato no válido, entonces el sistema muestra un mensaje

descriptivo para el usuario.

25
4.2.2 Gestión de cliente

Caso de Uso: Ingresar un nuevo cliente

Actores: Administrador, capturista.

Tipo: Primario.

Propósito: Registrar un nuevo cliente en el sistema

Resumen: El administrador o capturista ingresa los datos requeridos para el nuevo

cliente. El sistema valida los datos ingresados, verifica que no se encuentren
registrados y los almacena.

CURSO NORMAL DE EVENTOS

1.- Este caso de uso comienza cuando el administrador o capturista desean registrar
un nuevo cliente.

2.- El sistema despliega una interfaz con el formulario para el ingreso del cliente.

3.- El administrador o capturista ingresa los datos completos requeridos por el

formulario.

4.- El sistema verifica que los datos ingresados sean válidos.

5.- El sistema almacena los datos del nuevo cliente.

CURSOS ALTERNATIVOS

1.- El sistema detecta un dato no válido o un campo vacío, muestra un mensaje

descriptivo para el usuario.

Caso de Uso: Mostrar cliente registrado.

Actores: Administrador o capturista.

Tipo: Primario.

Propósito: Conocer los datos de un cliente registrado en el sistema.

26
Resumen: El administrador o capturista selecciona de una lista, el cliente a
consultar. El sistema muestra un formulario con los datos del cliente seleccionado.

CURSO NORMAL DE EVENTOS

1.- Este caso de uso comienza cuando el administrador o capturista desea conocer
los datos de un cliente registrado en el sistema.

2.- El sistema despliega una interfaz con todos los clientes registrados en el sistema.

3.- El administrador o capturista selecciona el cliente a consultar.

4.- El sistema despliega, del cliente seleccionado, un formulario con los todos los
datos correspondientes al cliente.

Caso de Uso: Modificar cliente registrado.

Actores: Administrador o capturista.

Tipo: Primario.

Propósito: Modificar uno o todos los datos de un cliente registrado en el sistema.

Resumen: El administrador o capturista selecciona de una lista el cliente a modificar.

El sistema muestra un formulario con los datos del cliente seleccionado y permite
que sean modificados. El administrador o capturista ingresan los datos que desea
modificar. El sistema verifica que los datos sean válidos y los almacena.

CURSO NORMAL DE EVENTOS

1.- Este caso de uso comienza cuando el administrador o capturista desea modificar
uno o todos los datos de un cliente registrado.

2.- El sistema despliega una lista con todos los clientes existentes en el sistema.

3.- El administrador o capturista selecciona el cliente que desea modificar.

5.- El administrador o capturista cambia el o los datos que estime necesario.

6a.- El sistema verifica que los datos ingresados sean válidos.

7.- El sistema almacena los nuevos datos del cliente registrado.

27
4.2.3 Gestión de informe

Caso de Uso: Emitir un informe de los clientes mediante un archivo PDF.

Actores: Administrador, capturista.

Tipo: Primario.

Propósito: Obtener los clientes existentes dentro del sistema en un archivo PDF
para su impresión.

Resumen: El administrador o capturista dentro del panel capturista para obtener el

informe tendrá que oprimir el botón imprimir automáticamente le generará un archivo
PDF en el escritorio con los datos de los clientes existentes en el sistema.

CURSO NORMAL DE EVENTOS

1.- Este caso de uso comienza cuando el administrador o capturista desean obtener
un informe impreso con los clientes existentes en el sistema.

2.- El sistema despliega una interfaz el administrador o capturista podrá ubicar el

botón imprimir informe dando un clic sobre el mismo.

4.- El sistema abrirá una ventana con el mensaje de generación de reporte exitoso.

5.- El sistema guarda el archivo PDF en el escritorio del ordenador.

Caso de Uso: Emitir un informe mediante una gráfica del estatus del cliente.

Actores: Administrador, capturista.

Tipo: Primario.

Propósito: Obtener una gráfica de los clientes existentes dentro del sistema de
acuerdo con el estatus que estos tengan.

Resumen: El administrador o capturista dentro del panel capturista para obtener la

gráfica tendrá que oprimir el botón grafica estatus, automáticamente le generará
una gráfica con la información de los clientes existentes en el sistema conforme el
estatus que estos tengan.

28
CURSO NORMAL DE EVENTOS

1.- Este caso de uso comienza cuando el administrador o capturista desean obtener
un informe grafico con los clientes existentes en el sistema.

2.- El sistema despliega una interfaz el administrador o capturista podrá ubicar el

botón grafica estatus dentro del panel capturista dando un clic sobre el mismo.

4.- El sistema abrirá una ventana donde se mostrará la gráfica con la información
requerida.

29
 4.3 Modelo Entidad / Relación

nom_usuar
Id_usuari
io
o

ap_usuario
usuarios
statu
ema
il
Tipo_niv
telefon el
o
passwo
userna rd
me

ap_pat
nombr ap_ma
e t
nombr id_ases id_client
or e domicili
id_ases o
ap_pa
or
t telefon
asesor
cliente o
ap_ma
t tipo_negoc
statu io
telefon id_ruta s
no_contrat
observacion o
es
monto_presta
num_cic
mo
lo
pago_diar
io

rutas

id_rut nombre_rut
30
a a
4.3.1 Descripción Lógica de las Entidades

• Tabla Cliente: La función de esta entidad es mantener un registro de los

clientes en el sistema, registrando los datos: id_cliente, id_asesor, nombre,
ape_pat, ape_mat, domicilio, teléfono, tipo_negocio, no_contrato,
monto_prestamo, pago_diario, num_ciclo y status.
• Tabla Usuarios: Esta entidad es responsable de mantener un registro de las
personas que hacen uso del sistema, ya sea, administrador o capturista.
Datos registrados: id_usuario, nom_usuario, ap_usuario, email, teléfono,
username, password, tipo_nivel, status.
• Tabla Rutas: En esta entidad se registran todas rutas, que corresponden a
cada uno de los asesores. Datos ingresados: id_ruta, nombre_ruta.
• Tabla Asesor: En esta entidad se encuentran almacenados todos los
asesores que se desempeñan dentro de la empresa. Datos registrados:
id_asesor, nom_asesor, ape_pat, ape_mat, teléfono, id_ruta.

4.3.2 Modelo Relacional

• Tabla Cliente

cliente
id_cliente int NOT NULL
nombre varchar (50) NOT NULL
ap_pat varchar (100) NOT NULL
ap_mat varchar (100) NOT NULL
domicilio varchar (200) NOT NULL
telefono varchar (10) NOT NULL
tipo_negocio varchar (100) NOT NULL
no_contrato varchar (50) NOT NULL
monto_prestamo varchar (50) NOT NULL
pago_diario varchar (50) NOT NULL
num_ciclo int NOT NULL
observaciones text
status varchar (50) NOT NULL
id_asesor int NOT NULL
PRIMARY KEY (id_cliente)
FOREIGN KEY (id_asesor) REFERENCES asesor(id_asesor)

31
 • Tabla Usuario

usuarios
id_usuario serial
nom_usuario varchar (50)
ap_usuario varchar (50)
email varchar (50)
telefono varchar (50)
username varchar (50)
password varchar (50)
tipo_nivel varchar (50)
status varchar (50)
PRIMARY KEY (id_usuario)

• Tabla Rutas

rutas

id_ruta int NOT NULL

nombre_ruta varchar (100)

PRIMARY KEY (id_ruta)

• Tabla Asesor

asesor
id_asesor serial
nombre varchar (50) NOT NULL
ap_pat varchar (100) NOT NULL
ap_mat varchar (100) NOT NULL
telefono varchar (10) NOT NULL
id_ruta int NOT NULL
PRIMARY KEY (id_asesor)
FOREIGN KEY (id_ruta) REFERENCES rutas(id_ruta)

32
4.4 Descripción de las pruebas realizadas

4.4.1 Casos de Prueba

Los casos de prueba son un conjunto de entradas de prueba, condiciones de

ejecución y resultados esperados. Su objetivo es probar algo en concreto,
basándose en los casos de uso del sistema.

• Hacer Login
Comprobar si el sistema da acceso con el usuario root y contraseña otorgada
al administrador

33
 • Ingresar Nuevo Usuario
Comprobar si el nuevo usuario es ingresado correctamente al sistema. Se
comprobó que el sistema permitió el registro del nuevo usuario en el sistema
y se envió un mensaje indicando que la operación se realizó correctamente.

• Ingresar Nuevo Cliente

Comprobar si el nuevo cliente es ingresado correctamente al sistema. Se
comprobó que el sistema permitió el registro del nuevo cliente en el sistema
y se envió un mensaje indicando que la operación se realizó correctamente.
Así también se verifico que el cliente se encuentre en el sistema.

34
 • Mostrar Grafica del Estatus del Cliente
Comprobar si comprobar si al presionar el botón grafica estatus el sistema te
muestra el panel donde se muestra la gráfica. Se comprobó que el sistema
permitió visualizar la gráfica correctamente.

35
Capítulo 5

CONCLUSIONES Y TRABAJO A FUTURO

5.1 Conclusiones

Debido al constante crecimiento que han experimentado las empresas y la

necesidad de disponer en forma rápida y oportuna de información, se hace
indispensable la construcción de sistemas para cumplir con objetivos propuestos
por las mismas. La empresa Yo contigo en su afán por estar a la vanguardia de la
tecnología solicitó la construcción de un sistema el cual le permita facilitar y
automatizar el control de sus clientes. Para hacer posible el desarrollo del sistema
se debió realizar un análisis de las tecnologías utilizadas por la empresa, a fin de
determinar la más conveniente. Se decidió que las herramientas a utilizar generaran
un ahorro para la empresa, es por este motivo que se optó por la tecnología Java
Netbeans que ofrece herramientas de primer nivel para el desarrollo de aplicaciones
móviles, de escritorio, empresariales, etc.… y un motor de base de datos
PostgreSQL los cuales son unas de las herramientas predilectas en la Web, debido
a la disminución significativa en el tiempo de programación y además al poco
rendimiento de memoria.

El diseño con la arquitectura MVC, permite a futuro agregar funcionalidades al

nuevo sistema, debido al desacoplamiento de sus capas, por lo cual es fácil cambiar
alguna de ellas, no afectando al sistema completo, además genera potenciales
clientes para esta misma. Con este sistema inicial se pretende recabar información
del estado de los clientes para poder tener una mejor toma de decisiones dentro de
la empresa y así cuidar el bienestar de esta. Aunque esto solo es un pequeño paso
hacia la culminación de un sistema mas robusto que pueda cubrir cada una de las
necesidades de la empresa.

36
5.2 Trabajo futuro

Uno de los trabajos futuros que puede llegar a tener el proyecto es agregar el
módulo de pagos. Debido a que existe una gran variedad de clientes, algunos
puntuales y otros no, se requiere agregar ese modulo para llevar un control en base
a la puntualidad de pago y compromiso de cada cliente con respecto al préstamo
otorgado. En este módulo se pretende ingresar los datos de los pagos (fecha de
pago, monto a pagar, numero de pago) y así poder generar reportes más precisos
sobre la cartera de clientes.

Otro trabajo futuro que se pretende implementar es migrar el sistema a una

aplicación web, y en base a la aplicación cada asesor podrá manipular su cartera
de clientes y gestionar los prestamos vía internet.

37
BIBLIOGRAFÍA

https://www.lugaresconhistoria.com/evolucion-de-los-prestamos

https://economipedia.com/definiciones/prestamo.html

https://www.eumed.net/cursecon/ecolat/mx/2016/microfinanzas.html

https://rockcontent.com/es/blog/que-es-java/

https://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/888

https://blog.infranetworking.com/servidor-postgresql/

https://www.gestiopolis.com/ciclo-de-vida-de-un-sistema-de-informacion/

38