71.0653.IS

Universidad Católica de Santa María
Facultad de Ciencias e Ingenierías Físicas y

Formales
Escuela Profesional de Ingeniería de Sistemas
DESARROLLO DE UN SISTEMA DE GESTIÓN DE CERTIFICADOS SOAT,

APLICANDO METODOLOGÍA ÁGIL SCRUM
Tesis presentada por la Bachiller:

Arbieto Batallanos, Carlos
Eduardo
para optar el Título Profesional de
Ingeniero de Sistemas
Asesor:
Dr. Fernández del Carpio, Alvaro
Arequipa- Perú
2020
Dedicatorias
A mis compañeros y amigos, los Maestros en Ciencias Informáticas, Ricardo
Coronado, Oscar Quispe, Julio Vera, Edison Paria, Gustavo Suero, Jhon Monroy,
Alexander Ocsa y Reynaldo Alfonte, quienes me apoyaron en todo el proceso
dedesarrollo de este proyecto.
Agradecimientos
El presente trabajo va
dirigido con una expresión de gratitud, para mi madre
Carmen Batallanos, para mi padre Luis Arbieto, para mi
hermana Carolina Arbieto, asesores y amigos, que, con
nobleza y entusiasmo, influyeron con su conocimiento y
ejemplo en mí, asimismo, agradecer al centro de
investigación CiTeSoft de la Universidad Nacional de
San Agustín y a la Universidad Católica Santa María,
casa de estudios que guio e inspiro mi camino
profesional con conocimiento, experiencia y
valores.
Resumen
Los sistemas o tecnologías de información basados en tecnologías WEB han cambiado
los paradigmas de operar de las organizaciones o empresas actuales, dado que se logran
considerables mejoras a comparación de los sistemas de escritorio, pues optimizan los
procesos informáticos que operan las empresas, y a su vez proporcionan información de
apoyo, para el proceso de toma de decisiones en el preciso momento, motivando el
alcance de obtener ventajas competitivas.
El creciente mercado de venta SOAT vehiculares ha ido evolucionado con el tiempo,
desde finales del año 2017, diferentes empresas aseguradoras han implantado diversas
aplicaciones móviles y WEB, orientadas a la venta de SOAT en el Perú, lo que ha
generado un mercado más competitivo y dinámico, bajo esta preocupación las empresas
corredoras de seguros deben actualizarse rápida y efectivamente.
En este trabajo se presenta la implementación de un sistema basado en tecnologías WEB,
basado en la metodología SCRUM para dar solución al proceso de gestión de SOAT de
una empresa corredora de seguros, una propuesta que ya estaban implementando sus
competidores, por lo que era necesario, implementar una solución ágil, robusta y
económica.
Por este motivo, solo se utilizaron tecnologías libres novedosas que están siendo
constantemente usadas en la actualidad, las herramientas que se seleccionaron son,
SPRING FRAMEWORK, MYSQL, VUE.JS y BOOSTRAP v4.0 para trabajar a través
de servicios REST que permitan la integración con diferentes plataformas, y utilizar las
potentes funcionalidades de la programación de componentes WEB, para ahorrar tiempo
y código, buscando acelerar el desarrollo, por último se utilizaron las librerías de
BOOSTRAP para brindar un estilo profesional, así mismo, el sistema se encuentra
alojado en la nube en el servidor DIGITAL OCEAN, brindando soporte en tiempo real,
esto con el objetivo de cumplir los objetivos de implementar una herramienta para
aceleración de la gestión de SOAT ágil, robusta y económica.
Palabras clave: Ingeniería de Sistemas, Metodologías ágiles, SCRUM, sistema de

gestión SOAT, Servicios REST, API, Sistemas en la Nube, sistemas administrables
Abstract
Information systems or technologies based on WEB technologies have changed the

paradigms of operating of current organizations or companies, since considerable
improvements are achieved compared to desktop systems, since they optimize the
computer processes that companies operate, and in turn They provide support
information, in real time to decision making, motivating the scope of obtaining
competitive advantages.
The growing vehicle SOAT sales market has evolved over time, since the end of 2017,
different insurance companies have implemented various mobile and WEB applications,
aimed at the sale of SOAT in Peru, which has generated a more competitive market and
dynamic, under this concern insurance brokerage firms must update quickly and
effectively.
This work presents the implementation of a system based on WEB technologies, based
on the SCRUM methodology to provide a solution to the SOAT management process of
an insurance brokerage company, a proposal that was already being implemented by its
competitors, so it was necessary, implement an agile, robust and economic solution.
For this reason, only novel free technologies were used that are constantly being used at
present, the tools that were selected are, SPRING FRAMEWORK, MYSQL, VUE.JS and
BOOSTRAP v4.0 to work through REST services that allow integration with different
platforms, and use the powerful functionalities of programming WEB components, to
save time and code, seeking to speed up development, lastly the BOOSTRAP libraries
were used to provide a professional style, likewise, the system is hosted in the cloud on
the DIGITAL OCEAN server, providing real-time support, this in order to meet the
objectives of implementing a tool for acceleration of SOAT management that is agile,
robust and economical.
Keywords: Systems Engineering, Agile Methodologies, SCRUM, SOAT management

system, REST Services, API, Cloud Systems, administrable systems
INTRODUCCIÓN
Los sistemas basados en tecnologías WEB han logrado cambiar la manera de trabajar de
las organizaciones y empresas actuales, por medio de su uso han logrado importantes
mejoras, en comparación a sistemas de escritorio, pues optimizan los procesos operativos
de las empresas, y a su vez brindan información de soporte en tiempo real al proceso de
toma de decisiones, facilitando el alcance de ventajas competitivas.
Sería de gran beneficio que en la mediana y pequeña empresa se adopten procesos de

transformación digital ágiles, como respuestas a las nuevas tendencias y retos que está
presentando el nuevo mercado que es mucho más competitivo, ya que la mayoría de las
empresas en los últimos años están adoptando modelos de trabajo basados en
metodologías ágiles, dado a su optimización de la razón tiempo/esfuerzo de un proyecto.
Uno de los campos donde más se está promoviendo utilizar SCRUM, es en el desarrollo
de software donde la metodología SCRUM ha demostrado su eficiencia, gracias a sus tres
pilares de trabajo que son, la transparencia que implicada dar visibilidad de todo lo que
está sucediendo, a todos los actores involucrados, desde la entidad contratante hasta los
el equipo que trabajo en el desarrollo, la inspección que promueve que el equipo
identifique, evalué y corrija los avances durante diferentes tipos de reuniones de
planificación, y la adaptación que implica realizar los ajustes y cambios de los procesos
para garantizar una reducción de la desviación de los objetivos durante todo el desarrollo
del proyecto, una práctica muy efectiva cuando se trata de agregar modificaciones de
requisitos en el proceso de implementación.
En este trabajo se expone un desarrollo(implementación), de un sistema implementado

en tecnológicas WEB y basada en la metodología SCRUM para dar solución al proceso
de gestión de certificados SOAT que solicitó una empresa corredora de seguros, que por
seguridad, entre los requisitos presentados, ha pedido que no se revele información de su
organización, por lo que demandó mejorar su sistema de gestión, dado que la organización
había empezado a expandirse y empezaba a operar en otras ciudades, lo que presentaba
inconvenientes dado que se contaba con un sistema de escritorio que no trabajaba en línea
y los obligaba a tener que ingresar las ventas de las sucursales de forma manual, un
proceso tedioso que estaba generando gastos adicionales de personal.
Con el riesgo de continuar generando pérdidas, ya que la competencia contaba con

sistemas dedicados en producción, la empresa presentó su latente preocupación por un
desarrollo ágil, dinámico y seguro para adaptarse al mercado.
En respuesta a esta problemática se propuso la implementación de un software(sistema),

que consistía en mejorar el trabajo referente a la gestión de SOAT, mediante un sistema
administrable alojado en un servidor WEB(en la nube), el cual proporcione integración
entre plataformas que trabajan con diferentes lenguajes de programación, por medio de
servicios API(interfaz de programación de aplicaciones), REST(transferencia de estado
representacional), que permitan comunicación, velocidad y seguridad entre el servidor y
los terminales, brindando reportes en tiempo real, lo que se presenta como ventajoso, si
se cuenta con varias sucursales.
Para esto se propuso también la implementación de privilegios de usuarios, dado a que

era necesario, que cada sucursal solo acceda a sus métricas de trabajo, y no pueda observar
la información de otras, y a su vez brindar acceso completo a la oficina principal, la cual
se encargaría de dar mantenimiento al sistema y generar reportes para la toma de
decisiones de la organización, todo esto basado en una metodología de trabajo SCRUM,
que agiliza el proceso de desarrollo, ya que era preocupación del cliente era de la de
modernizar sus herramientas de trabajo para reinsertarse en el mercado competitivo.
ÍNDICE
DICTAMEN APROBATORIO
DEDICATORIA
AGRADECIMIENTO
RESUMEN
ABSTRACT
INTRODUCCIÓN
1. CAPITULO 1: CONSIDERACIONES GENERALES........................................ 1
1.1 Definición del problema.................................................................................. 1

1.2 Antecedentes del problema ............................................................................. 1
1.3 Justificación .................................................................................................... 3
1.3.1 Justificación Teórica ................................................................................ 3

1.3.2 Justificación aplicativa ............................................................................. 6
1.4 Propósito ........................................................................................................ 8

1.5 Alcances y limitaciones ................................................................................. 8
1.5.1 Delimitación de la Investigación .............................................................. 9
1.6 Objetivos ........................................................................................................ 9
1.6.1 Objetivo general ...................................................................................... 9

1.6.2 Objetivos específicos ............................................................................... 9
1.6.3 Preguntas de investigación ..................................................................... 10
1.7 Población y muestra ...................................................................................... 10

1.8 Tipo de Investigación .................................................................................... 11
1.9 Nivel de Investigación .................................................................................. 11
1.10 Estructura de la Tesis .................................................................................... 11
2. CAPITULO 2: MARCO TEORICO ................................................................. 13
2.1 Estado del Arte ............................................................................................. 13

2.2 Gestión de Proyectos..................................................................................... 17
2.2.1 Desarrollo Ágil ...................................................................................... 18

2.2.2 Factores Humanos ................................................................................. 19
2.3 Metodología SCRUM ................................................................................. 19
2.3.1 Componentes de SCRUM ...................................................................... 20

2.3.2 Desarrollo de las fases de un proyecto en SCRUM. ................................ 23
2.3.3 Modelado de Requerimientos ................................................................. 25
2.4 Bases teóricas respecto al problema .............................................................. 27

2.5 Bases teóricas de las tecnologías para el desarrollo ....................................... 28
2.6 Capa de presentación o visual (FRONT END): ............................................. 29
3. CAPITULO 3: DESARROLLO ....................................................................... 32
3.1 Método de investigación ............................................................................... 32

3.2 Documentación del proyecto ......................................................................... 34
3.2.1 Diagrama de Casos de Uso..................................................................... 35

3.2.2 Diagrama de clases ................................................................................ 36
3.2.3 Diagramas de Secuencia ........................................................................ 36
3.2.4 Diagrama de Procesos ............................................................................ 41
3.2.5 Diagrama de Componentes .................................................................... 41
3.2.6 Arquitectura del Sistema ........................................................................ 42
3.2.7 Herramientas de desarrollo..................................................................... 43
3.2.8 Diagrama de base de datos ..................................................................... 43
3.2.9 Conformación del equipo de trabajo....................................................... 47
3.2.10 Capacitación y soporte ........................................................................... 48
3.3 Análisis e interpretación ................................................................................ 48
3.3.1 Estructura de negocio de las empresas Corredoras de seguros ................ 48

3.3.2 Recopilación de las Historias de Usuario Para el Sistema ....................... 49
3.4 Desarrollo de SPRINTS ................................................................................ 55
3.4.1 Planificación del PRODUCT BACKLOG .............................................. 55

3.4.2 Elaboración de los SPRINTS ................................................................. 58
3.5 Requerimientos Funcionales y no Funcionales .............................................. 61
3.5.1 Diseño de Interfaces (MOCKUPS) ........................................................ 63

3.5.2 Planificación de los SPRINTS en TRELLO ........................................... 66
3.5.3 Implementación de los SPRINTS ........................................................... 67
3.5.4 Entregables del SPRINT 2: .................................................................... 73
3.6 Pruebas de Entregables ................................................................................. 78
3.6.1 Pruebas del SPRINT 1: .......................................................................... 78

3.6.2 Pruebas del SPRINT 2: ........................................................................ 79
3.7 Análisis de datos ........................................................................................... 82
3.7.1 ARIMA ................................................................................................. 83

3.7.2 Tendencias de ventas ............................................................................. 84
3.7.3 Predicción Mensual................................................................................ 84
3.7.4 Predicción Diaria ................................................................................... 89
4. CAPITULO 4: VALIDACIÓN......................................................................... 91
4.1 Evaluación del Sistema ................................................................................. 91
4.1.1 Resultados de la evaluación (PRE-TEST) .............................................. 92

4.1.2 Resultados de la evaluación (POST-TEST) ............................................ 98
4.1.3 Comparación de los resultados ............................................................. 104
4.2 Resultados .................................................................................................. 110
5. CAPITULO 5: CONCLUSIONES ................................................................. 119
5.1 Principales Contribuciones .......................................................................... 121

5.2 Discusión .................................................................................................... 122
5.3 Trabajos Futuros ......................................................................................... 122
6. Bibliografía .................................................................................................... 123

7. Anexos .......................................................................................................... 127
7.1 Certificado del curso SCRUM .................................................................... 128

7.2 Carta de autorización de uso de software ..................................................... 129
7.3 Encuesta de calidad de software para el PRE-TEST y el POST-TEST ....... 129
7.4 Tabla de precios SOAT, de la aseguradora LA POSITIVA .......................... 131
7.5 Actas de Reunión de planificación de SPRINTS ........................................ 132
7.6 Manual de Usuario ...................................................................................... 137
Índice de Figuras
Figura 1- Privilegios del sistema (Elaboración propia) .................................................. 6

Figura 2 - Estructura de la tesis (Elaboración propia) .................................................. 12
Figura 3 - Triángulo de la Gestión de Proyectos (Pressman, 2010) .............................. 18
Figura 4 - Ejemplo de Historia de usuario (Pressman, 2010) ....................................... 23
Figura 5 - Ejemplo de estimación (Trigás, 2012) ......................................................... 24
Figura 6 - Vista del sistema desde la perspectiva del cliente y el equipo de desarrollo
(Kniberg, 2010)........................................................................................................... 25
Figura 7 - Requerimientos de Software (Kniberg, 2010) .............................................. 26
Figura 8 - Modelo Vista Controlador (Pressman, 2010). .............................................. 26
Figura 9 - Diagrama de Casos de Uso (Elaboración propia)......................................... 35
Figura 10 - Diagrama de Clases (Elaboración propia).................................................. 36
Figura 11 - Diagrama de Secuencia de administrador Vendedor (Elaboración propia) . 39
Figura 12 - Diagrama de Secuencia de Vendedor (Elaboración propia) ....................... 40
Figura 13 - Diagrama de procesos (Elaboración propia) .............................................. 41
Figura 14 - Diagrama de Componentes (Elaboración propia) ...................................... 42
Figura 15 - Arquitectura del sistema de ventas (Elaboración propia) ........................... 43
Figura 16 - Diagrama de Base de datos Vendedor (Elaboración propia). ..................... 44
Figura 17 - Estructura de negocio de una empresa corredora de seguros (Elaboración
propia) ........................................................................................................................ 49
Figura 18 - Importancia para la estimación (Elaboración propia) ................................. 56
Figura 19 - Diseño de interfaz inicio de sesión (Elaboración propia) ........................... 63
Figura 20 - Diseño de interfaz de administración de Aseguradoras (Elaboración propia)
................................................................................................................................... 63
Figura 21 - Diseño de interfaz de administración de Usuarios (Elaboración propia)..... 63
Figura 22 - Diseño de interfaz de administración de Oficinas (Elaboración propia) ..... 63
Figura 23 - Diseño de interfaz de administración de Categorías de vehículos (Elaboración
propia) ........................................................................................................................ 63
Figura 24 - Diseño de interfaz de administración de Tipos de uso de vehículos
(Elaboración propia) ................................................................................................... 63
Figura 25 - Diseño de interfaz de administración de Clases de vehículos (Elaboración
propia) ........................................................................................................................ 64
Figura 26 - Diseño de interfaz de administración de VCC (Elaboración propia) .......... 64
Figura 27 - Diseño de interfaz de administración de pólizas por unidad (Elaboración
propia) ........................................................................................................................ 64
Figura 28 - Diseño de interfaz de administración de Precios (Elaboración propia) ....... 64
Figura 29 - Diseño de interfaz de administración de pólizas masivas (Elaboración propia)
................................................................................................................................... 64
Figura 30 - Diseño de interfaz de administración de asignación de pólizas (Elaboración
propia) ........................................................................................................................ 64
Figura 31 - Diseño de interfaz de administración de cotizador (Elaboración propia) .... 65
Figura 32 - Diseño de interfaz de administración de estados (Elaboración propia) ....... 65
Figura 33 - Diseño de interfaz de administración de cotizador - ingreso datos del vehículo
Figura 34 - Diseño de interfaz de administración de cotizador - ingreso datos del
contratante (Elaboración propia) ................................................................................ 65
Figura 35 - Diseño de interfaz de administración de cotizador - impresión de la póliza
Figura 36 - Diseño de interfaz de administración de cotizador - ingreso datos del pago
Figura 37 - Diseño de interfaz de administración de Reportes del sistema (Elaboración
propia) ........................................................................................................................ 66
Figura 38 - Interfaz de TRELLO con las actividades del SPRINT 1 y sus
procesos(Elaboración propia) ...................................................................................... 67
Figura 39 - Interfaz de TRELLO con el detalle de una actividad (Elaboración propia). 67
Figura 40 - Vista responsiva móvil (Elaboración propia) ............................................. 68
Figura 41 - Interfaz de inicio de sesión de usuarios (Elaboración propia)..................... 68
Figura 42 - Interfaz de administración de usuarios (Elaboración propia) ...................... 69
Figura 43 - Interfaz de administración de aseguradoras (Elaboración propia) .............. 69
Figura 44 - Interfaz de administración de oficinas (Elaboración propia) ...................... 70
Figura 45 - Interfaz de administración de tipos de uso (Elaboración propia) ................ 71
Figura 46 - Interfaz de administración de Categorías (Elaboración propia) .................. 71
Figura 47 - Interfaz de administración de clases de vehículos (Elaboración propia) ..... 72
Figura 48 - Interfaz de administración de VCC de vehículos (Elaboración propia) ...... 73
Figura 49 - Interfaz de administración de la tabla de precios (Elaboración propia)....... 73
Figura 50 - Interfaz de administración de pólizas masivas (Elaboración propia) .......... 74
Figura 51 - Interfaz de administración de re-asignaciones o eliminaciones de pólizas
Figura 52 - Interfaz de administración para anular ventas (Elaboración propia) ........... 75
Figura 53 - Interfaz de Cotizador (Elaboración propia) ................................................ 76
Figura 54 - Interfaz de ingresar los datos del contratante (Elaboración propia) ............ 76
Figura 55 - Interfaz para imprimir los certificados SOAT o re-asignar otra póliza
Figura 56 - Interfaz para generar reportes del sistema (Elaboración propia) ................. 77
Figura 57 - Reporte de ventas por compañía (Elaboración propia) ............................... 78
Figura 58 - Pagina web para tendencias de ventas (Elaboración propia) ...................... 84
Figura 59 - Data de entrenamiento y Predicción de ventas hasta julio 2020 del sistema
propuesto (Elaboración propia) ................................................................................... 85
Figura 60 - Predicción de ventas del año 2018 para el anterior sistema (Elaboración
propia) ........................................................................................................................ 88
Figura 61 - Tabla de datos extraídos para comparación (Elaboración propia) .............. 89
Figura 62 - Comparación de ventas del sistema anterior con el sistema propuesto
Figura 63 - Predicción del 17 de marzo al 17 de abril del 2019 del sistema propuest.
Figura 64 -Diferencia de medias de USABILIDAD (Elaboración propia).................. 111
Figura 65 - Resultado de significancia de USABILIDAD (Elaboración propia) ......... 111
Figura 66 - Resultado de significancia de DISPONIBILIDAD (Elaboración propia) . 112
Figura 67 - Diferencia de medias de DISPONIBILIDAD (Elaboración propia) ......... 112
Figura 68 - Diferencia de medias de INTERACCIÓN (Elaboración propia) .............. 113
Figura 69 - Resultado de significancia de INTERACCIÓN (Elaboración propia) ...... 113
Figura 70 - Diferencia de medias de ADAPTABILIDAD (Elaboración propia) ......... 113
Figura 71 - Resultado de significancia de ADAPTABILIDAD (Elaboración propia) . 114
Figura 72 - Diferencia de medias de ESTABILIDAD (Elaboración propia) ............... 114
Figura 73 - Resultado de significancia de ESTABILIDAD (Elaboración propia) ....... 114
Figura 74 - Resultado de significancia de EFECTIVIDAD: DE LA INFORMACIÓN
DEL SISTEMA (Elaboración propia)........................................................................ 115
Figura 75 - Diferencia de medias de EFECTIVIDAD: DE LA INFORMACIÓN DEL
SISTEMA (Elaboración propia) ................................................................................ 115
Figura 76 - Resultado de significancia de EFICACIA: CALIDAD DE LA
INFORMACIÓN DEL SISTEMA (Elaboración propia) ........................................... 116
Figura 77 - Diferencia de medias de EFICACIA: CALIDAD DE LA INFORMACIÓN
DEL SISTEMA (Elaboración propia)........................................................................ 116
Figura 78 - Diferencia de medias de EFICACIA: FUNCIONALIDAD (Elaboración
propia) ...................................................................................................................... 116
Figura 79 - Resultado de significancia de EFICACIA: FUNCIONALIDAD (Elaboración
propia) ...................................................................................................................... 117
Figura 80 - Resultado de significancia de PROMEDIO GENERAL (Elaboración propia)
................................................................................................................................. 117
Figura 81 - Diferencia de medias de PROMEDIO GENERAL (Elaboración propia) . 117
Índice de Tablas
Tabla 1 - Resumen de costes de desarrollo .................................................................... 5

Tabla 2 - Ejemplo de un PRODUCT BACKLOG........................................................ 22
Tabla 3 - Tabla de comparación de Herramientas ........................................................ 43
Tabla 4 - Diccionario de los datos de la tabla Usuario ................................................. 45
Tabla 5 - Diccionario de los datos de la tabla venta ..................................................... 45
Tabla 6 - Diccionario de los datos de la tabla cotización .............................................. 46
Tabla 7 - Diccionario de los datos de la tabla de vehículos .......................................... 46
Tabla 8 - Diccionario de los datos de las tablas de apoyo del sistema .......................... 47
Tabla 9 - Equipo de trabajo ......................................................................................... 48
Tabla 10 - Historia de Usuario 1 y 2 ............................................................................ 49
Tabla 14 - Historia de Usuario 9 y 10 .......................................................................... 51
Tabla 15 - Historia de Usuario 11 y 12 ........................................................................ 52
Tabla 20 - Historia de Usuario 21................................................................................ 54
Tabla 21 - Modelo de PRODUCT BACKLOG............................................................ 55
Tabla 22 - Estimaciones del PRODUCT BACKLOG .................................................. 57
Tabla 23 - PRODUCT BACKLOG ............................................................................. 58
Tabla 24 - SPRINT 1 .................................................................................................. 59
Tabla 25 - SPRINT 2 .................................................................................................. 60
Tabla 26 - SPRINT 3 .................................................................................................. 60
Tabla 27 - SPRINT 4 .................................................................................................. 61
Tabla 28 - Requerimientos Funcionales y no Funcionales ........................................... 62
Tabla 29 - Pruebas de entregable registro, actualización y eliminación de usuario ....... 78
Tabla 30 - Pruebas de entregables de Asegurados, oficinas, tipos de uso, categorías, clases
de vehículos y VCC .................................................................................................... 79
Tabla 31 - Pruebas de entregables de tablas y calendarios de Precios........................... 79
Tabla 32 - Pruebas del sprint 3 .................................................................................... 80
Tabla 33 - Pruebas de entregables de Asignación, Re-Asignación y eliminación de Pólizas
................................................................................................................................... 80
Tabla 34 - Pruebas de entregables de Revisión de estados ........................................... 80
Tabla 35 - Pruebas de entregables del Cotizador.......................................................... 81
Tabla 36 - Pruebas de entregables de Reportes ............................................................ 82
Tabla 37 - Comparación de datos Reales y prueba del sistema propuesto .................... 85
Tabla 38 - Predicción del sistema propuesto ................................................................ 86
Tabla 39 - Predicción del sistema anterior 2018-19 ..................................................... 88
Tabla 40 - Predicción del sistema anterior 2018-19 ..................................................... 90
Tabla 41 - Tabla de Preguntas de las encuestas PRE-TEST y POST-TEST ................. 92
Tabla 42 - Tabla de la Pregunta P1 del PRE-TEST ...................................................... 93
Tabla 46 - Tabla de la Pregunta P5 del PRE-TEST ..................................................... 94
Tabla 50 - Tabla de la Pregunta P9 del POST-TEST ................................................... 95
Tabla 51 - Tabla de la Pregunta P10 del POST-TEST ................................................. 96
Tabla 53 - Tabla de la Pregunta P12 del PRE-TEST .................................................... 96
Tabla 62 -Tabla de la Pregunta P4 del POST-TEST .................................................. 100
Tabla 65 -Tabla de la Pregunta P7 del POST-TEST .................................................. 101
Tabla 68 - Tabla de la Pregunta P10 del POST-TEST ............................................... 102
Tabla 73 -Tabla de la Pregunta P15 del POST-TEST ................................................ 103
Tabla 76 - Comparación de la Pregunta(P1) .............................................................. 104
Tabla 85 - Comparación de la Pregunta(P10) ............................................................ 107
Tabla 93 - Rangos de Valoración .............................................................................. 118
Tabla 94 - Resultados de las Pruebas ......................................................................... 118
1. CAPITULO 1: CONSIDERACIONES GENERALES
1.1 Definición del problema
El creciente mercado de venta de SOAT vehiculares, ha ido evolucionado con el tiempo,

desde finales del año 2017, diferentes empresas aseguradoras, han implantado diversas
aplicaciones móviles y WEB, orientadas a la gestión de sus ventas de SOAT en el país,
lo que ha generado un mercado más competitivo y dinámico, bajo esta preocupación las
empresas corredoras de seguros deben actualizarse rápida y efectivamente.
Por este motivo la empresa corredora de seguros solicitó la implementación un sistema

de gestión de SOAT, una propuesta que ya estaban implementando sus competidores, que
consistía en mejorar su sistema de ventas y administración de SOAT, dado que la
organización había empezado a tener crecimiento y comenzaba a operar en otras ciudades,
lo que presentaba inconvenientes dado que se contaba con un sistema de escritorio que
no trabajaba en línea y los obligaba a tener que ingresar las ventas de las sucursales de
forma manual, un proceso tedioso que estaba generando grandes gastos adicionales de
personal. (APESEG, 2019) (Semana Económica, 2019).
Es así que identificamos como principal problema, el tiempo de demora en el proceso de

administración y gestión de todas las acciones involucradas para la venta de SOAT, por
parte de sus usuarios, ya que esto se daba gracias a que no se había identificado una
manera óptima de hacer una cotización de precios de varias aseguradoras, recordando
que, al ser una empresa corredora de seguros, estos se desempeñaban como un
intermediario entre el cliente y las diversas empresas que brindan seguros en el país, cada
una de estas cuenta con precios distintos para los SOAT, y estos precios eran brindados a
través de hojas impresas porque aunque ya se contaba con un sistema de escritorio
dedicado, este ya tenía más de 15 años de uso, no contaba con actualizaciones, que
forzaban a que organización modele su trabajo en base al sistema, una estrategia que con
el pasar de los años, solo reducía sus tiempos de respuesta y complicaba el proceso de
venta.
1.2 Antecedentes del problema
Se exponen en este apartado un grupo de trabajos relacionados a la problemática de esta

investigación.
1
Patiño (2013) en su trabajo “Implementación de métodos ágiles para la simulación de
casos de uso y prototipado en el proceso de desarrollo de software” exponen desde la
etapa de maquetación hasta la etapa de desarrollo, prototipos, creación de escenarios y
simulación de casos de uso, como un ciclo de vida que se dará durante el desarrollo de
proyectos de software, aplicando concepto de diseñar de modo ágil, obteniendo
alentadores resultados, por lo que afirma que si se puede llegar a una cercana proximidad
de una dinámica de los negocios proporcionando una temprana interacción con el cliente.
Este articulo nos dice que la simulación de un sistema empieza con la generación de casos
de uso, y nos indica que debemos ser cuidadosos y evitar caer en la situación de realizar
una descomposición demasiado detallada de la realidad, una vez abstraída la realidad
mediante los casos de uso se prosigue con el modelado a prototipos que deben enfocarse
en las características visibles del software del cliente, es imprescindible la aceptación por
parte del cliente, esto nos garantizará una confiabilidad y la calidad para el desarrollo de
las siguientes etapas.
Se propone en esta investigación la visión del “sistema a través de las interfaces

elaboradas en etapas tempranas”, para reducir la cantidad de riesgos que puedan
aparecer en el momento de implementar sin considerar el objetivo de lo que el cliente está
buscando, y de esta manera posibilitar al usuario final desde las primeras etapas de
implementación, buscando alcanzar “sinergia” entre el equipo y los clientes.
Molina (2014) en su trabajo “metodologías ágiles enfocadas al modelado de

requerimientos” sostiene que la industria del desarrollo de software es cambiante y que
hace realmente necesario repensar sus bases, un trabajo realizado por (Boehm, 2006),
sobre las tendencias, muestra la minimización de la vida y la rapidez determinan el
mercado del software. Ante esta situación, indica que los procesos deben ser adaptables,
y concluye “que la mayoría de los estudios coinciden en que el carácter normativo y la
fuerte dependencia de planificaciones previas al desarrollo que definen a las
metodologías convencionales”, esto resulta que sean pesadas, largas, costosas y
complicadas para responder a los requerimientos de la mayoría del mercado de
tecnología.
2
El presente trabajo define algunos términos necesarios para iniciar nuestra investigación,
expone a una metodología como una manera de estructurar y planear el proceso de
implementación, define también el termino método como las actividades necesarias para
construir técnicamente el software, actividades como: análisis, diseño, codificación y
pruebas, esto nos ayuda a reconocer lo diferente que es referirse a una metodología con
respecto a un modelo, método o técnica.
Hace una descripción concisa de las metodologías ágiles, exponiendo de forma práctica
cómo se desarrolla la etapa del modelado de requerimientos para cada uno de los casos
en la metodología SCRUM para finalmente llegar a la conclusión de que las
metodologías ágiles se pueden asociar entre las modernas y las convencionales, con el
objetivo de involucrar al cliente en la tarea de plantación de desarrollo y así mejorar los
procesos internos que buscan satisfacer con el software.
1.3 Justificación
1.3.1 Justificación Teórica
El desarrollo de este sistema comprende una serie de actividades de análisis de requisitos

presentadas por la empresa corredora de seguros, dichas actividades serán automatizadas
con el uso de dos FRAMEWORKS y una librería de diseño, los mismos que permitirán
la optimización de la razón tiempo/esfuerzo de las actividades además de dar un enfoque
organizado donde será más rápido identificar errores(BUGS), hacer cambios en el código
y reutilizar el mismo reduciendo gastos en la productividad de implementación y ahorro
de recursos.
El FRAMEWORK para el BACK-END, que comprende que la fuente de información y

los servicios de integración y conectividad, será SPRING, un FRAMEWORK para el
implementación de aplicaciones WEB que nos permite tener control sobre la
configuración y administración de objetos a través de internet, este es de código abierto
y se encuentra disponible para la plataforma JAVAEE, además de sus diversos módulos
proveedores de servicios, soporta la “arquitectura Modelo vista controlador" que brinda
herramientas para la personalización de aplicaciones y servicios WEB REST, basados en
HTTP. (Johnson, 2004)
3
El FRAMEWORK para la parte del FRONT-END, que comprenden las interfaces(vistas),
y las conexiones con el BACK-END, se usará VUE.JS, el cual es un FRAMEWORK de
código libre, basado en JAVASCRIPT, para construir interfaces de usuario, al igual que
los otros FRAMEWORKS populares para el desarrollo de interfaces que son Angular y
REACTJS, que utilizan el paradigma de programación orientada a componentes, VUE.JS
adopta características de ambos, optimizando su funcionalidad y simplificando su uso,
posee una gran velocidad de rendimiento sin olvidar que es adaptable (vue.js, 2018), en
los últimos años ha generado una gran cantidad de usuarios, y según (Programacion.net,
2018), asegura que este es un FRAMEWORK que se los programadores del 2018 deben
aprender.
Por otro lado, se seleccionó la librería BOOSTRAP v4.0 para el diseño de las interfaces,
“debido a que contiene plantillas de diseño con tipografía, formularios, botones,
cuadros, menús de navegación y otros elementos de diseño basado en HTML y CSS, así
como, extensiones JAVASCRIPT", La cual adapta la interfaz visual de la plataforma WEB
al tamaño del dispositivo del que se acceda. BOOSTRAP cuenta con la capacidad de
integrar tecnologías HTML5 y CSS3 característica que lo vuelvo muy útil y por lo tanto
más ligero para los navegadores mediante los cuales se accede al sistema (Escobar, 2017)
1.3.1.1 Aspectos Técnicos
Para este trabajo se utilizará la metodología SCRUM, y para la implementación del

sistema solo se utilizaron tecnologías de SOTFWARE LIBRES dado a las limitaciones
de la empresa de adquirir licencias:
• Para la capa lógica o de acceso de datos (BACK-END)

o SPRING FRAMEWORK: basado en el lenguaje JAVA, es una
herramienta de SOTFWARE Libre que provee servicios WEB REST
basados en HTTP.
o MYSQL: propiedad de ORACLE, es una herramienta gestora de bases de
datos relacional de SOTFWARE libre, que no requiere licencia de uso.
• Para la capa de presentación o visual (FRONT-END)
o VUE.JS FRAMEWORK: Herramienta de SOTFWARE Libre, basado
en JAVASCRIPT, para desarrollar interfaces de usuario.
4
o BOOTSRAPS v4. 0: es una galería de estilo basado en HTML y CSS,
bastante ligero, que también es una herramienta de SOTFWARE
Libre.
1.3.1.2 Aspectos Económicos
El Sistema de información en sí, fue solicitado para su desarrollo, con el fin de, reducir
los altos costes que requería continuar funcionando con el sistema anterior, ya que al no
contar con un sistema que trabaje con interconectividad, necesitaban enviar sus
BACKUPS(información de respaldo) de manera manual por cada oficina, contratar un
administrador de sistemas para cada oficina, pagos de mantenimiento, etc. además de
contar con más vendedores, que reducían las ganancias e incrementaban el tiempo para
conseguir los reportes financieros, por este motivo en el resumen de costos se indicaran
los costes del desarrollo del sistema de información.
CRITERIO PERSONAL COSTO/MES MESES TOTAL
SCRUM MASTER 1 1500 3 4,500
Desarrollo de BACK-END 1 1500 3 4,500
Desarrollo de FRONT-END 2 1000 3 6,000
Costes de mantenimiento 1 250 0 250
TOTAL: 15,250
Tabla 1 - Resumen de costes de desarrollo
1.3.1.3 Aspectos comerciales
El proyecto es atractivo comercialmente para la empresa, dado a que la arquitectura y

herramientas utilizadas permiten la flexibilidad de escalabilidad, refiriéndose a su
capacidad de en el futuro para agregar funcionalidades que sean compatibles con la
información almacenada, es decir según su funcionamiento se podrán mejorar y adicionar
módulos, con esto la empresa podrá mejorar su servicio y podrá ahorrar costes para el
desarrollo de otros sistemas de información, estas mejoras podrán brindarle a la entidad
oportunidades para transformar digitalmente su negocio, que generen mayores ingresos a
la empresa, No obstante otro atractivo del proyecto de software es la posibilidad de
adjudicación y/o venta del sistema de información a otras compañías del mismo rubro
5
1.3.2 Justificación aplicativa
Como solución al problema planteado se propone implementar un herramienta o sistema

basado en tecnologías WEB que permita automatizar los procesos de gestión de seguros
SOAT, de la empresa corredora de seguros, a través de un sistema en línea, por lo que se
propone implementar privilegios de usuarios, que restrinjan el acceso de información
según la posición en la que el empleado se encuentra en la empresa, y la ciudad en donde
desempeñan su labor, además de agregar privilegios especiales, a los “puntos de venta"
que son establecimientos de venta de SOAT asociados a la corredora, que además de sus
actividades principales ofrecen la venta de SOAT a sus usuarios, dado a que en su
mayoría, son establecimientos donde frecuentan clientes que buscan seguros vehiculares,
en su mayoría son, tiendas por departamentos, grifos, boticas, farmacias y tiendas, los
privilegios que otorgara el sistema, se podrán observar en la siguiente figura.
Figura 1- Privilegios del sistema (Elaboración propia)
El sistema ayudará a mejorar la productividad en la atención y cotización de seguros para

los administradores de la empresa y los puntos de venta, además de incluir una plataforma
WEB de cotización para el personal de la empresa.
El sistema a desarrollar cubrirá necesidades y requerimientos enfocados en los siguientes

procesos, entendiendo como procesos a “un conjunto de actividades mutuamente
relacionadas” que, al relacionarse e interactuar se convierten en resultados. (Escobar,
2017)
• Gestión de creación de usuarios.

• Gestión y control de tablas de tablas de mantenimiento (vehículos, clases y sus
categorías. Gestión y control de precios.
6
• Gestión y control de pólizas SOAT en STOCK (almacenados)
• Gestión y control de estados de ventas
• Gestión y cotización de SOAT para la atención de clientes
• Emisión de reportes
Todos los datos se almacenarán en un servidor DIGITAL OCEAN (Digital Ocean, 2017)
que es un servidor privado en la nube de alquiler mensual, que por 20 dólares nos ofrece,
4 GB de memoria RAM, 2 CPUs virtuales, 80 de disco SSD(estado sólido), y 4TB de
transferencia de ancho de banda, que nos asegura una gran capacidad para soportar
usuarios conectados en el mismo momento, además de esto entre sus ventajas presenta la
alta disponibilidad, la seguridad (firewall integrado) y la capacidad de adicionar
certificados de seguridad SSL, y su uso para múltiples plataformas. Dentro los beneficios
que el sistema brindará están los incrementos tanto en productividad como usabilidad que
proporciona la automatización de lo antes mencionado.
La realización de este sistema mejorará el proceso de gestión de SOAT a través de un

sistema en línea, con lo que se espera incrementar la velocidad y asertividad de los
administradores en el proceso de proporcionar una correcta cotización del seguro para los
clientes, incrementando el flujo de clientes, como brindar un mejor servicio, esto a su vez
generará reportes valiosos para que en ese preciso momento se puedan tomar decisiones.
1.3.2.1 Usuarios del Proyecto
• Equipo que participo en el desarrollo:

o Equipo de desarrollo y mantenimiento del sistema
o Gerente General
o 5 administradores de la oficina principal
• Equipo que utilizar á el sistema:
o Gerentes de las Oficinas de la empresa
o Trabajadores entre vendedores y administradores (entre 5 a 10 aprox. por
oficina)
o Negocios asociados
7
1.3.2.2 Beneficios
• Implementar un sistema basado en herramientas WEB que permita y aproveche

la múltiple conexión con el uso de internet posibilidad de registrar diferentes tipos
de usuarios con privilegios (administradores, vendedores) posibilidad de controlar
la actividad de los usuarios (habilitarlos y deshabilitarlos)
• Posibilidad de gestionar y controlar los precios de los vehículos según las normas
del MTC (ministerio de transportes y comunicaciones) para tener un cotizador en
línea para los vendedores
• Controlar el estado de las ventas de la empresa
• Generación automática de reportes de ventas
1.3.2.3 Localización
• Oficina principal en Arequipa

• Oficina sucursal en Cusco Oficina
• Sucursal en Moquegua Oficina
• Sucursal en Tacna Oficina sucursal en Lima
1.4 Propósito
El propósito de este trabajo es mejorar el proceso de gestión de SOAT por medio de

un sistema en línea, basado en el uso de metodología SCRUM y las herramientas de
SOFTWARE LIBRE para desarrollar proyectos de manera rápida, sin perder
eficiencia, seguridad y adaptabilidad.
1.5 Alcances y limitaciones
El alcance del presente, cuenta como finalidad presentar un sistema que mejore el
proceso de gestión de SOAT, nos referimos a gestión como toda actividad
relacionada en la venta de SOAT(Seguro Obligatorio de Accidentes de Tránsito),
entre estos se puede apreciar, la configuración de precios, creación de usuarios,
privilegios, y la posibilidad de trabajar en internet, lo que permitirá conectividad entre
las diferentes oficinas de la empresa que se encuentran ubicadas en diferentes
ciudades del Perú, además de proponer un sistema de gestión de SOAT administrable
basado en metodología SCRUM, acorde a la realidad de nuestra localidad, basada en
8
experiencias propias, con esto se espera poder proporcionar material didáctico a
desarrolladores de software, para que lo usen como referencia para que puedan
realizar trabajos similares, y así poder competir en un ambiente laboral real.
Las limitaciones del presente trabajo, para no sobredimensionar y permitir el énfasis

en el proceso de gestión de SOAT se excluyó la investigación sobre las
implementaciones del cotizador móvil y el cotizador WEB para clientes realizados,
y este junto a su fase de validación, evaluación y pruebas, dado que aún se encuentra
en desarrollo, para futuras investigaciones experimentales, además de no contar con
acceso al código del sistema con que el que ya se encontraban trabajando, que no
permitía realizar pruebas de desempeño de software.
1.5.1 Delimitación de la Investigación
El sector de seguros vehiculares es un rubro muy competitivo, donde la empresa que tenga
una ventaja tecnológica, conseguirá lograr la mayoría de ventas, ya sea en si vendiendo a
través de agencias o por internet, por lo que dada a la extensa gama de tecnologías esta
investigación solo se centrara en la herramienta de gestión por oficinas dado que se tiene
dentro del plan de desarrollo una aplicación móvil para entrar al mercado competitivo.
1.6 Objetivos
1.6.1 Objetivo general
Proponer un sistema de información para mejorar el proceso de gestión de certificados de

seguros vehiculares (SOAT)
1.6.2 Objetivos específicos
1. Analizar los requerimientos e implementar un plan de trabajo, basado en

metodología ágil SCRUM.
2. Desarrollar la propuesta en la implementación de un sistema de gestión de SOAT.
3. Realizar un análisis de datos con la información histórica del sistema
4. Validar la propuesta.
9
1.6.3 Preguntas de investigación
A continuación, se lograron plantear las siguientes preguntas relacionadas directamente

con los objetivos específicos de este trabajo.
• ¿El desarrollo de este sistema, beneficia al negocio?

• ¿Desarrollar el sistema propuesto, mejora el proceso de gestión de SOAT?
• ¿Reducir costos de desarrollo utilizando tecnologías libres, favorece la
implementación?
1.7 Población y muestra
En el presente estudio se utilizó como muestra, a los administradores de la empresa,

durante los procesos de capacitación y uso del sistema propuesto de gestión de SOAT,
esta fue tomada como caso de estudio ya que se contaba con acceso a la información y
disponibilidad de sus integrantes, siendo oportuno para el presente estudio, el cual no
pretende realizar una generalización los resultados conseguidos en la muestra a una
población. Es por este motivo y dada la conveniencia se decidió utilizar un proceso de
muestreo no-probabilístico que según (Scharager, 2001) en este clase de muestreos, que
también pueden ser llamadas “muestras dirigidas o intencionales”, la elección de los
participante no es dependiente de la probabilidad sino de las diferentes o diversas
condiciones que nos permitirán realizar el muestreo (pueda ser por dificultad de acceso,
disponibilidad o conveniencia, etc.), por eso mismo son seleccionadas con métodos
informales y por lo tanto no garantizarían la completa representación de la población.
Esto implicaría que no sería posible estimar con precisión el error estándar de la
estimación, por lo que no se podría afirmar el nivel de confianza con la que estimación
fue realizada, en otras palabras, se puede explicar porque no todos los participantes
cuentan con la misma probabilidad de ser elegidos, por lo que es estimada la no
representatividad de todos los miembros de la población.
Este tipo de muestro es no probabilístico, es bastante frecuente, incluso hay situaciones

en que es más adecuado utilizarlo, por ejemplo, según (Scharager, 2001), cuando vamos
a realizar estudios de casos, de poblaciones heterogéneas, o estudios que son encaminados
a poblaciones, grupos o clases muy específicos, muy reducidos, o que requieren el
dominio de habilidades específicas, o que se tiene que contar con una meticulosa
10
selección de participantes, resalta un tipo de muestreo que se conoce como intencional,
que es el MUESTREO POR CUOTAS, en que el encargado de conseguir la información
enlaza las unidades de análisis en una cantidad que sea proporcional al de las condiciones
que presenta la población, y de éstos, según sea la conveniencia se pueda seleccionar.
Es por estos motivos que estos muestreos no probabilísticos intencionales, han sido
seleccionados un grupo de 6 administradores como cuotas, y pretende que sea
representativa a la población, por lo tanto, esta representatividad depende de la intención,
opinión y tiempo de uso, precisando que esta representatividad evaluada es subjetiva.
1.8 Tipo de Investigación
Para el presente trabajo se reunieron las condiciones de ser una investigación aplicativa,
dado que se utilizaron conocimientos adquiridos del rubro por la empresa que se propuso
mejorar su anterior experiencia utilizando herramientas de software, con el fin de obtener
de reducir los altos costes adicionales que le exigía su anterior método además de tener
una herramienta que les permita ser competitivos en la industria.
1.9 Nivel de Investigación
Según las características presentadas se trataría de un estudio descriptivo, dado que al

aplicarla se buscará deducir que el sistema propuesto mejora su proceso de gestión a
comparación de su anterior sistema dado a que el trabajo se centrará en recolectar datos
que describan esta mejora.
1.10 Estructura de la Tesis
El presente documento se divide en cinco capítulos lo que van hacer explicados a

continuación:
1. PRIMER CAPITULO: trata de las Consideraciones generales, de la

investigación que se tomó para el desarrollo del sistema, así también como la
problemática y los objetivos que se plantearon.
2. SEGUNDO CAPITULO: se especifica el Marco Teórico donde se da una
revisión histórica, al estado del arte y los conceptos más importantes acerca de las
herramientas a utilizar en el desarrollo del sistema.
3. TERCER CAPITULO: se va contemplar el Desarrollo del sistema de acuerdo
a la cada uno de los conceptos de la metodología SCRUM, además del análisis de
los datos.
11
4. CUARTO CAPITULO: En este se expone la Validación donde se va a recopilar
los resultados y análisis de los mismos.
5. QUINTO CAPITULO: Se detallan las Conclusiones, principales
contribuciones, las discusiones y los trabajos futuros
Figura 2 - Estructura de la tesis (Elaboración propia)
12
2. CAPITULO 2: MARCO TEORICO
2.1 Estado del Arte
Escobar (2017) en su trabajo “Desarrollo del sistema de control y gestión del seguro
de accidentes de la compañía de transporte interprovincial EXPRESS ATENAS,
utilizando los FRAMEWORKS CODEIGNITER y BOOSTRAP”. desarrolla un
sistema diseñado para que se realicen de manera automática los procesos que en el pasado
se realizaban de manera manual en la administración de seguros de la compañía, que
consta en ayudar de manera económica o reponiendo repuesto a vehículos que han sufrido
daños por accidentes mediante solicitudes, las cuales deben ser aprobadas por un
supervisor.
Para la implementación de este trabajo “se utilizó la metodología ágil SCRUM” que
facilitó la comunicación entre los involucrados (equipo de desarrollo y cliente) que
requirieron del sistema, se utilizó la herramienta KUNAGI para la administración del
proyecto, con la finalidad de mantener organizada y planificada cada una de las fases de
SCRUM, el FRAMEWORK BOOSTRAP porque permite acoplar su diseño a cualquier
dispositivo, también fue utilizado así como el gestor de base de datos MYSQ, luego
evaluaron el mismo, donde se obtuvo como resultado un sistema eficiente, donde lograron
85% de aceptación del sistema, así como una reducción de tiempos considerable del
75,61% al 24,39 % en la productividad del sistema, donde concluyen que el sistema
implementado facilitó cada uno de los procesos que se realizan dentro de la compañía y
sobre todo agilizo el trabajo del equipo de desarrollo y permitió una comunicación
constante, ya que se trata de un trabajo reciente del año 2017, se utilizó como guía, en el
desarrollo de este proyecto, dado que se confirma que las metodologías ágiles tanto como
el FRAMEWORK BOOTSTRAP, son un camino para optimizar el desarrollo de un
sistema de manera rápida, y con amplia comunicación.
Rodríguez (2017) en su trabajo “Sistema de control y monitoreo de bebés basados en

Open Source”, recalca que el nacimiento de un familiar, necesita una especial atención,
donde los avances tecnológicos sirven de apoyo, buscando crear entornos supervisados
en el ambiente donde se encuentra el bebé, y que garanticen su bienestar, pero las
herramientas presentes en el mercado, poseen muchas limitaciones, lo que le ha posible
13
a esta investigación, plantearse como objetivo, desarrollar un herramienta, basado en
SOFTWARE LIBRE, que pueda supervisar la habitación de un bebé.
Los métodos que los autores emplearon, consideran una línea base, a partir de los
mecanismos tradicionales, además, se pusieron en contexto conocimientos en los campos
de mecatrónica y computación. Para su evaluación se sometió a un “Juicio de Expertos”,
donde se logró realizar la implementación de un sistema basado en “HARDWARE Y
SOFTWARE LIBRE”, donde aplicaron la “metodología de desarrollo ágil EXTREME
PROGRAMMING (XP)”, para construir las interfaces de supervisión, que permitan el
monitoreo de la habitación del bebé, donde concluyen que haber diseñado un sistema
basado en tecnologías libres, permite crear aplicaciones livianas, como para ser instalados
y utilizados en placas integradas ARDUINO, siendo opciones económicas, y confiables,
además afirman que al usar la metodología XP, EXTREME PROGRAMMING,
mejoraron considerablemente el tiempo de desarrollo, ya que requerían desarrollar el
software de manera ágil, un trabajo más que promociona el uso y desarrollo de
metodologías ágiles para realizar proyectos medianos.
Espinosa (2018) en su trabajo “Sistema de gestión de venta para la tienda de estímulo

de la empresa agropecuaria la cuba”, con el objetivo de facilitarles a los trabajadores
de la empresa “LA CUBA DE CIEGO DE ÁVILA” un mecanismo de estimulación,
proponen una iniciativa donde según su productividad, se les permita realizar compras de
artículos a precios accesibles mediante sus bonificaciones.
Esta empresa ha adquirido equipos que están interconectados en una red, pero no se
benefician de las utilidades, por lo que vieron la necesidad de desarrollar una aplicación
WEB centralizada que les permita el acceso multi-usuario buscando que los
especialistas que interactúen en el “proceso de administración y gestión de las ventas”
puedan ingresar, además de brindar mayor fiabilidad y seguridad a la hora de asignar
bonos a los trabajadores y realizar ventas. El proceso de gestión de la tienda, últimamente
se había visto afectado por lentitud, ineficiencia y desorganización de la información,
dado que muchos departamentos estaban involucrados, por lo que donde concluyen que
haber diseñado el sistema basado en tecnologías WEB, para suplantar un sistema de
ventas de escritorio, agilizo y corroboro que su desarrollo supero dificultades tales como
14
la comunicación entre diferentes oficina, además de resaltar que este desarrollo resulto
como adecuado para gestión de ventas, lo que nos demuestra que es más frecuente que
los sistemas están migrando a tecnologías WEB, y las empresas están comenzando a
pensar en soluciones WEB multiusuarios como alternativas para solucionar gestiones de
ventas.
Quezada-Sarmiento (2017) en su trabajo “Implementación de una solución WEB y

móvil para la gestión vehicular basada en arquitectura de aspectos y metodologías
ágiles: un enfoque educativo de la teoría a la práctica" automatiza y controla el
movimiento vehicular en la “Universidad Técnica Particular de Loja (UTPL)”, utilizando
“metodologías ágiles, y tecnologías de SOFTWARE LIBRE” en la implementación de
una solución móvil y WEB. Dentro de las funcionalidades de la aplicación está la gestión
y administración del parque automotor que contempla: los registros de pedidos de
combustible y mantenimientos, facturas y proveedores. El sistema web contempla las
mismas funciones que la aplicación móvil.
En este trabajo se concluye que la aplicación WEB y móvil se implementó utilizando “la
metodología ICONIX y programación orientada a aspectos”, y se logró una acertada
integración, aplicando un trabajo colaborativo entre los diversos grupos profesionales.
Cedeño (2017) en su trabajo “Propuesta tecnológica de sistema de asignación de

cargas horarias de la carrera ingeniería en sistemas administrativos computarizados
de la facultad de ciencias administrativas de la universidad de Guayaquil " tienen
como objetivo, la asignación de los horarios de la carrera “Ingeniería de Sistemas de la
Universidad de Guayaquil”, mediante una aplicación, por lo que realizaron la
planificación e implementación, que permita al personal o profesores encargados, realizar
la creación de horarios de manera rápida y eficiente, para este cometido se utilizó una
herramienta dedicada, que le permita al “encargado de administrar el sistema”, realizar
ajustes el sistema de acuerdo a las carreras y sus necesidades, donde el FRAMEWORK
que se utilizo fue VUE.JS una herramienta de programación basado en componentes
WEB, y que realmente aceleró su proceso de desarrollo, pero presentó considerables
retos, en la iniciación de su aprendizaje, en el trabajo anterior hemos podido apreciar, que
se afirma que la complejidad de retos que se presentan en el uso de tecnologías libres es
15
considerable, a comparación a tecnologías pagas, ya que el soporte no será personalizado
y se tendrá que tener habilidades de abstracción más preparadas, ya que aprender una
herramienta requerirá su estudio a través de bastante documentación y tutórales en línea,
pero que en el momento de desarrollo brindara ventajas económicas , ya que en su
mayoría, las tecnologías libres cuentan con lo necesario para tener un sistema completo,
y si fuera necesario también cuentan con herramientas para integración por si se requiera
de funcionalidades más complejas.
Cruz (2017) en su trabajo “Desarrollo de un sistema para la creación de horarios para

la universidad central del ecuador " presentan el desarrollo de un sistema que facilita
la creación de horarios de clases para las diferentes facultades de la “Universidad Central
del Ecuador”, mediante el uso de tecnologías y herramientas actualmente se encuentran
en auge, de código abierto, permitiendo a las diversas facultades, contar con una
plataforma que contribuye en la reducción de tiempo, optimización de recursos y
minimización de errores, donde implementan una API con servicios REST desarrollados
en SPRING FRAMEWORK y afirman que la herramienta facilito considerablemente el
desarrollo de la aplicación acelerando el desarrollo y economizando también en
programación pero requiere de un experto en su uso ya que de esta habilidad dependerá
la velocidad con la que se cree un API REST para el proyecto, este trabajo sirvió como
un ejemplo de implementación de servicios REST, una tecnología, muy útil para cuando
se cuentan con diversos terminales, como sistemas de múltiples usuarios, y utilizaron
SRING FRAMEWORK, que es la misma herramienta de código abierto que estamos
implementando.
Garcia (2017) en su trabajo presenta un estudio sobre el proceso de realizar cotizaciones

de los asesores de seguros para clientes, donde se argumentan diversos contratiempos
debido a la difícil tarea de implementarlo, por las múltiples herramientas que se
utilizaron, creando dificultades de tiempo y dinero, y estableciendo considerables retrasos
para encontrar soluciones a las necesidades de los clientes, el 94% de los encuestados
coinciden que es una problemática, realizar una cotización y hacerle seguimiento, por que
plantean la implementación de un software que cuente con una interfaz amigable y fácil
de entender para el usuario, y que principalmente acelere el proceso de cotización, y que
permita contar en una misma herramienta, la “información de los clientes y las
16
cotizaciones realizadas”, las cuales se encuentran “disponibles para acceder a ellas”,
enviarlas o imprimirlas, este trabajo fue muy interesante, y nos sirvió de modelo, en el
desarrollo de nuestra planificación, porque lograron enfrentarse a problemáticas similares
a las que este trabajo se enfrenta.
2.2 Gestión de Proyectos
Trata sobre la ejecución del “conocimiento, habilidades, herramientas y técnicas en las

actividades” requeridas para cumplir con las funcionalidades requeridas de un proyecto.
“La gestión de proyectos se lleva a cabo mediante el uso de procesos tales como:
iniciación, planificación, ejecución, control y término” (Mitaritonna, 2010), y que
normalmente implica:
• Diferentes requerimientos de “alcance, tiempo, costo, riesgo y calidad”.

• Clientes con diferentes necesidades expectativa
• Requerimientos identificados
Por su naturaleza los contenidos que son incluidos para la “gestión de proyectos son
iterativos”, ósea se repiten constantemente, dado a la necesidad de que sea progresiva la
planificación y ejecución durante lo que dure la vida del proyecto, por lo que
(Mitaritonna, 2010) resalta que la capacidad de gestionar el proyecto, va a estar
directamente relacionado a la cantidad de conocimiento que se tenga del proyecto, por lo
que define un triángulo de restricciones basada en alcance, tiempo y costo, donde cada
lado no puede ser modificado sin estar impactando a los otros, haciendo de la calidad una
cuarta restricción resultante de estas tres.
17
(Mitaritonna, 2010)
Figura 3 - Triángulo de la Gestión de Proyectos (Pressman, 2010)
• División del trabajo: Smith (1996) define que dividir el trabajo incrementa la
productividad por ejemplo en el proceso de fabricación de alfileres, si
comparamos, un obrero normal podría alcanzar la producción requerida
dividiendo su trabajo entre varios herreros asignándoles diferentes tareas (estirado
del alambre, cortado, afilado, etc.), así se podría decir que al obrero podría
producir 50 por día, pero dividiendo el trabajo podría producir hasta 10 veces más.
• Producción en cadena: Piñero (2004) define las bases de dividir y organizar el
trabajo de manera científica y que es la practica más usada en el mercado, hasta
que en los años 70 empieza a ser cambiada por la tendencia de TOYOTA que
algunos definen como toyotismo, presentando las siguientes mejoras:
o Amplia reducción de los costes de fabricación.
o Producción de flujo constante.
o Ingeniería de procesos: la calidad de los procesos de producción definirá
los productos resultantes.
2.2.1 Desarrollo Ágil
Delgado (2008) y renombrados desarrolladores de software, escritores y consultores

(grupo llamado “Alianza Ágil”) firmaron el “Manifiesto por el desarrollo ágil de
software” en él que se establecían los siguientes valores:
• Cada trabajador y sus intervenciones sobre los procesos.

• El software operante, sobre una extensa documentación.
• La contribución del cliente sobre la negociación de los contratos.
• Realizar cambios rápidos, sobre estar apegado a un plan (Pressman, 2010).
18
2.2.2 Factores Humanos
Los factores personales definen el desarrollo ágil, según Cockburn y Highsmith en

(Pressman, 2010) “El desarrollo ágil se centra en los talentos y habilidades de los
individuos, y adapta el proceso a personas y equipos específicos.”, los factores son:
• Competencia: competiré requiere de experiencia y características específicas del

software y un amplio conocimiento d ellos procesos.
• Enfoque común: Todos enfocados en la meta y la fecha pactada.
• Colaboración: los miembros del equipo deben colaborar entre sí, compartiendo
información relevante y transmitiendo experiencia.
• Habilidad para tomar decisiones: el equipo debe de operar con autonomía, tener
la autoridad necesaria para tomar decisiones de tipo técnico
• Confianza y respeto mutuos: Se debe trabajar el respeto y la confianza dentro
del equipo.
• Organización propia: El equipo de desarrollo debe organizarse solo, el equipo
toma decisiones para que adapte de la mejor manera al ambiente. El equipo debe
organizar los procesos de programación a fin de cumplir con la fecha de entrega.
2.3 Metodología SCRUM
En el libro de Metodología SCRUM de (Trigás, 2012) explica claramente cómo se define

su origen, en 1986 Takeuchi y Nonaka lograron publicar “THE NEW PRODUCT
DEVELOPMENT GAME” en donde dan a conocer un nuevo paradigma de administración
de proyectos donde las prioridades son ser Agiles y flexibles. Además, citaron diversas
empresas del ámbito tecnológico que desarrollaban software rápido, de alta calidad y con
costos bajos.
Por lo tanto, SCRUM se define como un marco de trabajo para los procesos de desarrollo
de SOFTWARE de forma ágil, y esto se da a conocer cuando Jeff Sutherland lo implanto
en EASE/CORPORATION donde obtuvieron alentadores resultados, y lo publicaron
como un proceso formal para el desarrollo, siendo así consideras para incluirse en la lista
de la alianza de las metodologías agiles (Agile Alliance), donde definen que estos se
deben de caracterizar por tener (Trigás, 2012):
19
• Incertidumbre: Se plantea el objetivo sin tener en claro un plan muy detallado
para alcanzar al producto.
• Auto-organización: Los equipos son capaces de organizarse por si mismos, dado
que no requieren roles de gestión, pero si de reuniones que les permitan autonomía
y auto-superación.
• Control moderado: se debe de construir un “escenario de auto-control entre
iguales” ósea no se de impedir que los miembros expresen su creatividad y su
forma espontánea de actuar.
• Transmisión del conocimiento: los miembros del equipo deben compartir su
información y experiencia, con los objetivos de afianzar sus propios
conocimientos y colaborar con los demás.
SCRUM al ser un paradigma de desarrollo basado en ágil, tiene como principios crear
iteraciones o ciclos cortos, que son llamados “SPRINTS”, y que requieren de 5 fases
(Trigás, 2012):
• Concepto: Se nombra al equipo y las funcionalidades del desarrollo(producto).

• Especulación: Se van a establecer las características como los límites de del
desarrollo como los costos y los tiempos, esta fase se va a repetir en cada SPRINT
y comprende:
o Dar una revisión a las características del SPRINT
o Lista de espera de funcionalidades
o Cronograma de entrega.
• Revisión: el equipo evalúa todo lo desarrollado y lo verifica según el plan.
• Cierre: Se entrega el producto según las fechas pactadas, estos no indican que el
desarrollo ha concluido, sino que seguirán realizando los cambios, llamados
“mantenimiento”, que hará que el producto final sea el más adecuado a sus
necesidades.
2.3.1 Componentes de SCRUM
SCRUM esta divido en 3 aspectos importantes, que podemos llamar “reuniones”, estas
en conjunto con los elementos y los roles, conforman las fases de la metodología.
20
2.3.1.1 Las Reuniones
• Planificación del BACKLOG: Trigás (2012) la plantea como un documento en

donde se anotarán las prioridades por medio de requisitos, en esta fase se van a
definir la planificación por ejemplo el SPRINT 0, donde se va a decidir cuáles
serán los objetivos y las funciones, además se definirá el “SPRINT BACKLOG”,
que es una lista de actividades a desarrollar en la iteración
• Seguimiento del SPRINT: En esta fase se realizarán diversas reuniones de
manera diaria donde se plantean 3 preguntas para definir los avances
o ¿Cuál fue el trabajo realizado en la reunión previa?
o ¿Cuál será el siguiente trabajo?
o ¿Cuáles fueron los inconvenientes?
• Revisión del SPRINT: al finalizada la iteración, se hace una evaluación de los
logros alcanzado y luego una retroalimentación de parte del cliente.
2.3.1.2 Los Roles
• El equipo de desarrollo: Trigás (2012) las define como los participantes del
equipo SCRUM:
1. PRODUCT OWNER: quien tiene la responsabilidad de la toma de

decisiones, y que conoce el negocio, es el encargado de describir el objetivo
del cliente y priorizarlas.
2. SCRUM MASTER: Miembro que comprueba los paradigmas a emplear y
que sean los adecuados, y también se encargara de deshacerse los problemas
que se presenten que no permitan avanzar al proyecto.
3. Equipo De Desarrollo: Normalmente el equipo se comprende entre 4 a 9
miembros y que cuentan con la autonomía suficiente para organizarse y
planificarse.
• Los actores externos: realmente no son miembros SCRUM pero si son definidos
para brindar opiniones y experiencias dentro de cada iteración.
1. Usuarios: Son los que utilizarán el desarrollo.
2. STAKEHOLDERS: miembros que participan en las revisiones y que el
desarrollo les ha de producir algún beneficio
21
3. MANAGERS: Son los miembros que gestionan y toman decisiones, como la
definición de objetivos y requerimientos
2.3.1.3 PRODUCT BACKLOG
Es la lista de las funcionalidades que se hayan solicitado en los requisitos de forma

priorizada (Trigás, 2012), estos requerimientos son los objetivos a cumplir por el equipo
y deben ser gestionadas por el SCRUM MASTER y el cliente quienes indicaran las
estimaciones de tiempo/esfuerzo para finalizar los procesos, por eso mismo se definirán:
• Los objetivos, manifestadas en las historias de los usuarios.

• Se presentan los costes y valores y la priorización basadas en el ROI por cada
objetivo.
• Los entregables que serán presentados.
• La estimación de riesgos y problemas para solucionarlos.
ID Prioridad Descripción Estimación
1 Alta Desarrollo de MOCKUPS para el desarrollo de la 30

página WEB
2 Alta Interfaz de la página WEB 40
3 Media Formularios de registro de usuarios 60
4 Baja Formulario de contacto (para emisión de correos) 20
Tabla 2 - Ejemplo de un PRODUCT BACKLOG
2.3.1.4 Las historias de Usuario
Se presentan las características detalladas de los requerimientos y funciones que se van a

desarrollar en el proyecto, están incluidas las historias de usuario, que serán el resultado
del trabajo colaborativo entre el equipo SCRUM y el cliente, este consiste en tres:
• Carta (CARD): que comprende las descripciones detalladas, como evidencias.

• Conversatorios (CONVERSATION): con el objetivo de que todos los objetivos
hayan sido comprendidos por el equipo.
• Confirmación (CONFIRMATION): evaluaciones de las funciones que fijan
que serán relevantes.
22
Figura 4 - Ejemplo de Historia de usuario (Pressman, 2010)
En la imagen se presenta el formato de las historias y contienen: el ID (identificación de

la historia), el título, la descripción, la estimación, la prioridad y las dependencias (cada
historia es independiente y no esperar o depender de otras).
2.3.2 Desarrollo de las fases de un proyecto en SCRUM.
En esta sección se van a detallar, todas las fases que se implementaron para el desarrollo
del proyecto utilizando la metodología SCRUM.
2.3.2.1 Preparación del proyecto
Trigás (2012) y Pressman (2010), lo definen como la iteración inicial o “SPRINT 0” y es

donde se comprenden las necesidades del negocio, esta fase presenta muchas
estimaciones erróneas pero que se entienden que es mejor invertir el tiempo en
desarrollar, comprendiendo así las tareas que irán en el “PRODUCT BACKLOG” como,
definición el proyecto (propósito), Definición del BACKLOG inicial (priorizando
funcionalidades y Definición de los entregables(para la obtención de la opinión del
cliente).
2.3.2.2 La Estimación del BACKLOG
Trigás (2012) y Pressman (2010), lo detallan especificando que durante las primeras
reuniones se debe de conocer los tiempos de dedicación para definir la velocidad y así
estimar, por lo que ya se deben tener definidas las historias, calculándose los recurso y el
valor de días disponibles para determinar un valor.
23
Figura 5 - Ejemplo de estimación (Trigás Gallego, 2012)
2.3.2.3 Planificar un SPRINT
La planificación de SPRINTS o también denominado “SPRINT PLANNING

MEETING”, realiza una reunión de formar diaria, donde se encuentran todos los
miembros SCRUM, con la finalidad de definir el “PRODUCT BACKLOG” y así dividen
en:
1. Primera parte de la reunión: Se priorizan los requerimientos para realizar los

entregable, el equipo opina, y se toman decisiones para implementar las
actividades del SPRINT.
2. Segunda parte de la reunión: Se realizarán las evaluaciones necesarias sobre las
funcionalidades y el equipo tendrá la responsabilidad de presentar soluciones y
así determinar la más adecuada.
2.3.2.4 El desarrollo del SPRINT
Durante cada iteración, el equipo se esfuerza en desarrollar el producto, esto será de gran
utilidad para los miembros SCRUM, más o menos se estima que debe durar un mes
consecutivo como máximo, este tiempo se considera es adecuado para lo que
“STAKEHOLDERS” no pierdan interés, para eso se planifican reuniones (Kniberg,
2007) (Trigás, 2012) como:
1. Reunión de Planificación (SPRINT PLANNING MEETING)

2. Reunión diaria (SPRINT DAILY MEETING) de 15 minutos.
3. Reunión de revisión del SPRINT (SPRINT REVIEW MEETING)
4. Reunión de Retroalimentación (SPRINT RETROSPECTIVE MEETING)
máximo 3 horas.
24
2.3.3 Modelado de Requerimientos
Pressman (2010), resalta que, de forma técnica, “la ingeniería de software comienza con
una serie de tareas de modelado que conducen a la especificación de los requerimientos
y a la representación de un diseño del software que se va a elaborar “, llegando así a un
modelo de requerimientos, por lo que debe de utilizar un conjunto de textos y diagramas
para una sencilla comprensión.
1. Identificación de requisitos: Un grave problema cuando se utiliza un desarrollo

ágil es la importancia que adquieren todas las necesidades de la funcionalidad del
sistema, realmente que la funcionalidad guíe el desarrollo, no presenta un
problema, hasta que se desarrolla dejando de lado a aquellos requisitos que
también tienen gran importancia, pero se apartan de la funcionalidad, aquellos
requisitos son llamados “no funcionales”.
Figura 6 - Vista del sistema desde la perspectiva del cliente y el equipo de

desarrollo (Kniberg, 2010)
2. Requerimientos funcionales: Somerville (2005) los define como servicios que

debe proporcionar el sistema, deben declarar de forma detallada, lo que el
producto debería y no debería de realizar, se describen de forma abstracta y bien
declara explícitamente las funcionalidades.
3. Requerimientos no funcionales: Somerville (2005) los presenta como,
restricciones o limitaciones del sistema, incluyendo límites de tiempo, por lo que
son requerimientos que no son directamente funcionalidades, sino como
propiedades (fiabilidad, tiempo de respuesta o capacidad).
4. Casos de uso: Los casos describen las condiciones en las que el sistema se debe
comportar para responder a los usuarios, en otras palabras, narra las historias de
25
los usuarios con las funcionalidades del sistema, los casos de uso deben
representar al SOFTWARE desde la visión del usuario final (Pressman, 2010).
2.3.3.1 Análisis de los Requerimientos
El análisis permite al equipo de desarrollo implementar el plan según los requerimientos,

este análisis se da por medio de un diseño de interfaces, componentes y arquitectura, para
que brinde a los desarrolladores y a los clientes, los resultados que indicarán la interfaz,
los elementos y las restricciones (Pressman, 2010).
Figura 7 - Requerimientos de Software (Kniberg., 2010)
2.3.3.2 Arquitectura
El modelo, vista controlador (MVC) es un modelo sugerido para implementaciones WEB,

como arquitectura, dado que dividen las interfaces de sus funcionalidades y la
información. Esta, denominada “objeto de modelo”, contiende la parte lógica y visual de
la aplicación, la parte “vista” presenta las funciones de la interfaz, y la parte “lógica”
presenta el acceso a las bases de datos y las funcionalidades de procesamiento que
necesita el usuario, la parte “controlador” gestión el acceso a la parte “vista y modelo” y
coordina el flujo de información (Pressman, 2010),
Figura 8 - Modelo Vista Controlador (Pressman, 2010).

26
2.4 Bases teóricas respecto al problema
a) Abstracción: Es el proceso por donde una clase se divide de su contexto,

presentando con interfaces la representación de su comportamiento futuro (Silva,
2018), estas interfaces son conjuntos de funciones y métodos de las clases y la
mantiene aislada de otras.
b) Alcance: se refiere que el desarrollo debe de llegar a ser exactamente lo que se
detalló y debe de hacer lo que se espera, siendo su principal característica “la
calidad”, teniendo en cuenta que el especto “calidad” incluye directamente a los
costos y los tiempos (Mitaritonna, 2010).
c) Nominación Automática (Auto-nominación): Término utilizado para indicar no
solo el trabajo de la máquina, sino también las relaciones e interdependencias
existentes entre hombres y máquinas, es una síntesis de automatización e
inteligencia (Cavone, 2015).
d) Ciclo de vida: es la identificación de los “problemas, situaciones y
oportunidades” que va a tener el software en un periodo de tiempo, pudiendo ser
estimable e indicado, para que sea relativo con la inversión. (Cavone, 2015).
e) Costo: para estimar los costes, se debe de tener en cuenta que tiene que considerar
muchas variables, estas son “mano de obra, materiales, riesgos e infraestructura”,
cuando se va a realizar un contrato por ejemplo de un “consultor independiente”,
su precio sería estimado por la “tarifa de la empresa consultora”. (Mitaritonna,
2010).
f) MOCKUP: se refiere a una maqueta que es “un modelo a escala o tamaño real de
un diseño”, que se va a visualizar en algún dispositivo digital, que se usa
típicamente para realizar una “muestra o demostración, evaluación, promoción, y
desarrollo”, estos “MOCKUPS” son usados típicamente por sus gestores los
diseñadores gráficos o diseñadores “UI/UX” y “capturan la ingeniería popular”
(Cavone, 2015).
g) Modelo: es “una representación simple de una realidad” (Cavone, 2015), que
“modelamos” para entender de manera sencilla el plan que estamos ejecutando, y
que este se da cuando los desarrollos se presentan complejos, es importante ya
que sin este no sería posible una visión completa del reto.
27
h) Requerimiento: es un servicio explicado de manera abstracta que debe contar el
sistema o una limitación de este, se pueden clasificar por niveles de detalle.
(Somerville, 2005).
i) Retorno sobre la inversión: (del inglés, RSI o ROI) es una formula estadística,
que va a ser la razón entre las utilidades o beneficios obtenidos respecto a la
cantidad de inversión destinada, analiza el rendimiento de implementación de la
empresa.
j) Técnica: es un grupo de características, que se deben de cumplir para realizar un
proceso, no debe de contar con muchas ya que es más pequeña que una
metodología (Molina, 2014).
k) Tiempo: se puede traducir como la cantidad de minutos, horas o días, que requiere
un proceso para ser ejecutado, se debe dividir lo suficiente como para entender
cuándo debe de durar cada tarea que contribuirá a la realización del proyecto
(Mitaritonna, 2010).
2.5 Bases teóricas de las tecnologías para el desarrollo
En esta sección se detallarán las bases teóricas de las tecnologías empleadas para las
diferentes partes del sistema y serán divididas en 3 capas:
1. Capa lógica o acceso de datos (BACK-END):

• Bases de datos Relacionales: (Codd, 1970) propone en 1970 que sistema de
bases de datos debe presentar al usuario una vista de datos organizadas por
tablas llamadas “Relaciones”, pero detrás de estas debe funcionar una
compleja estructura de datos que permita respuestas rápidas a una variedad de
consultas, estas búsquedas deben ser expresadas en un lenguaje de alto nivel
muy parecido al lenguaje natural del usuario, que incrementaría la eficiencia
de los programadores de bases de datos reduciendo la complejidad. “SQL
(STRUCTURED QUERY LANGUAGE)” es el lenguaje de búsquedas más
importante basado en modelos relacionales.
• MYSQL: es un “gestor o administrador de base de datos relacionales”, bajo
licencia publica, y comercializada por ORACLE, es considera como la
plataforma de código abierto más usada en el mundo, sobre todo la más usada
para aplicaciones WEB (MySQL, 2001).
28
• SPRING FRAMEWORK: va a poner al alcance de los desarrolladores un
entorno de programación integral, para aplicaciones de tipo empresarial
basado en el lenguaje JAVA, una de sus características es un soporte que
brinda a las infraestructuras en el nivel lógico. (Johnson, 2009) (Johnson,
2004).
• Servicios REST: REST (de las siglas en inglés REPRESENTATIONAL
STATE TRANSFER), (Johnson, 2009) es definida como una arquitectura
basada en el estándar HTTP, para aplicaciones WEB, y nos alcanza la
capacidad de crear servicios y aplicaciones, que puedan comunicarse con
cualquier dispositivo digital, es mucho más simple que otras herramientas de
los últimos 10 años y poco a poco se va estableciendo como un estándar.
• API: Johnson (2009) y Amini (2013), la definen como una “interfaz de
programación de aplicaciones (API)”, y se puede entender como la
comunicación establecida entre las diversas partes del sistema, como el
conjunto de peticiones a bibliotecas que brindan “acceso a servicios”, siendo
su propósito el de proporcionar funcionalidad, por ejemplo peticiones de bases
de datos, coordenadas, accesos, tokens, etc.
2.6 Capa de presentación o visual (FRONT END):
• Programación por componentes: Moreno (2017) la define como una

programación que en sus fundamentos son componentes que han sido
desarrollados en el pasado, existen plataformas que permiten la
implementación de proyectos web basados en componentes por ejemplo J2EE
y .NET, aunque aún sea una tecnología emergente y continua mejorando,
presenta considerables ventajes ante paradigmas de programación
convencionales, ya que permite manejar complejidad de requisitos debido a la
reutilización de código por medio de los componentes.
o Principios de Componentes: Según Moreno (2017), el principio de esta
programación es basada en “divide y vencerás” dado que su principal
diferenciador ante técnicas estructuradas es que el análisis y diseño se ha
de realizar como una solución lógica, previa a su codificación, al principio
29
fue utilizado dentro del paradigma “orientado a objetos”, dado que aquí es
donde se implementó “la reutilización de código o reusó”.
o Los componentes WEB: son un conjunto de APIs de la plataforma
WEB que permiten crear y utilizar elementos HTML personalizados,
reutilizables y encapsulados, los mismos que se pueden usar en
aplicaciones y sitios WEB. Cada WEB COMPONENT tiene
semántica, funcionalidad y lógica en cuanto a su presentación. Esta
especificación para el desarrollo WEB, se describe en algunos
estándares WEB, a través de los cuales los desarrolladores consiguen
extender a nuevos elementos HTML encapsulados y personalizados
(Moreno, 2017).
• VUE.JS: es un FRAMEWORK basado en código fundamentado en
programación de componentes WEB, para desarrollar interfaces gráficas, su
principal diferencia frente a otros es que fue desarrollado para ser adaptable
según el proyecto lo requiere ósea de manera incremental, sus librerías están
enfocadas a las de visualización de información, siendo totalmente suficiente
de maneras complejidad de aplicaciones en una misma página, además de
brindar facilidades para combinarla con otras herramientas del mercado
(Romero, 2017).
• BOOSTRAP: BOOSTRAP es un FRAMEWORK WEB, de código abierto,
que presenta herramientas y librerías para diseñar páginas web responsivas,
contiene diversas plantillas con facilidades para tipografías, formatos,
botones, etc., así como dependencias en JAVASCRIPT, cuenta con soporte
para HTML5 y CSS3, y fue desarrollado para trabajar en conjunto con la
mayoría de navegadores disponibles.
• DIGITAL OCEAN: DIGITAL OCEAN es una plataforma de los estados
unidos, que alquila servicios de servidores, disponibles en todo el mundo, por
lo que garantiza la alta disponibilidad de su servicio, ya que la información es
replicada en EE. UU. CANADA, PAISES BAJOS, INGLATERRA Y
SINGAPUR.
30
2. Capa de administración del Proyecto:
• TRELLO: es una herramienta disponible en la web gratuita y de código libre,
que brinda la posibilidad de administrar proyectos colaborativos de manera
sencilla y práctica, presenta una “pizarra o BOARD digital” que contienen
listas de procesos, que se agrandaran de manera horizontal para mostrar
información más detallada, y donde se le pueden agregar “cartas o CARDS”,
utilizando las tecnologías de “DRAG AND DROP”, estas cartas presentas las
listas de tareas, ejemplos visuales, archivos, tiempos de entrega, etiquetas y
comentarios necesarios para que se pueda dar la comunicación en el equipo,
es posible configurarlo como para trabajar con metodologías agiles como
SCRUM, KAMBAN o XP y fue desarrollada por la empresa GIZMODO.
31
3. CAPITULO 3: DESARROLLO
3.1 Método de investigación
Muestreo no probabilístico: Scharager (2001) lo define como un proceso, que presenta

muestras direccionadas de manera intencional, a un grupo específico, la elección de los
participantes no dependerá de un porcentaje del total sino de las diversas situaciones o
condiciones que nos permitirán realizar la evaluación del muestro por ejemplo, acceso a
la información, disponibilidad, conveniencia, etc., por sus características no puede
pretender que los resultados aseguren una representación total de la población, por lo que
no es posible calcular con exactitud el error estándar de la estimación, dado que no todos
los sujetos no cuentan con la misma posibilidad de ser seleccionados. Estas muestras son
numerosamente frecuentes, incluso se pueden citar situaciones en que es más
conveniente, por ejemplo, cuando se realizan estudios de casos de poblaciones
heterogéneas o en investigaciones que son direccionadas a grupos muy específicos donde
es necesaria una controlada y meticulosa selección de participantes con ciertas
características. Uno de los tipos de esta evaluación es el “muestreo intencional o
muestreo por cuotas”, en el que el encargado de evaluar define los análisis a un “numero
proporcional” al de las condiciones del grupo, y se podría seleccionar por conveniencia.
Población: la población de la empresa no se puede estimar de manera exacta, ya que,

dado a la naturaleza del negocio, estos cuentan con sucursales, y además de estos puntos
de venta externos a la empresa, y cada uno de estos puede contar con varios vendedores,
de los cuales se desconoce, lo que no permite conocer la cantidad de usuarios que harán
uso del sistema de ventas.
Muestra: es por estos motivos que estos muestreos no probabilísticos intencionales han
sido seleccionados un grupo de 6 administradores como cuota, y esta pretende que sea
“representativa”, por lo tanto, “la representatividad depende de la intención, opinión y
tiempo de uso”, precisando que esta “evaluación de la representatividad es subjetiva”.
Materia Experimental: consiste en un sistema gestión de certificados SOAT para el

apoyo en la administración y ventas de una corredora de seguros, este se encuentra alojado
en la nube, y fue desarrollada con tecnologías libres, además de contar con novedosas
32
herramientas que son relativamente nuevas en el mercado, que son tendencias de
desarrollo y están ayudando a crear robustos sistemas en el mundo.
Técnicas e instrumentos para recolectar información: para este estudio las técnicas
que se utilizaron fueron dos, estas fueron recolectadas durante el periodo de capacitación:
• Observación directa: mientras se realizó la ejecución del experimento, se

contó con una lista de cotejo. El que nos permitió valorar los progresos en el
uso del sistema.
• La encuesta: Se realizó al número de muestra a uno por uno sin tomar los
datos personales.
Técnicas e instrumentos para recolectar información: la información recolectada, fue

organizada y tabulada en hojas de cálculo, y para su visualización se utilizarán gráficos
estadísticos tales como barras, para el tratamiento de datos se utilizaron lo siguiente:
• Tablas con respuestas a las encuestas

• Gráficos Circulares.
• Gráfico de barras.
Técnicas e instrumentos para recolectar información: el plan del procedimiento del

estudio fue realizado con los siguientes pasos:
• Primero: se recolectaron las historias de usuario.

• Segundo: se desarrollaron todas las planificaciones de los SPRINTS
• Tercero: se estableció el diseño de las interfaces de usuario
• Cuarto: se definió la arquitectura de los datos, así como la implementación de los
SPRINT
• Quinto: se evaluaron a los empleados en la etapa de pruebas de los entregables y
finalmente se entrega la iteración de los SPRINTS.
Plan de tratamiento de datos:
• Al culminar el desarrollo e implementación de la gestión de SOAT se ha realizado

una encuesta llamada POST-TEST.
• Se ha realizado historia de usuario para poder mejorar el proceso de ventas.
• Se midieron los resultados de la encuesta aplicada al número de muestra.
33
Diseño estadístico para las pruebas: se realizado la prueba estadística T -STUDENT,
para analizar e interpretar los resultados (Levin, 1996), para lo que se realizó los
siguientes cinco pasos:
• Paso 1: Se plantean las Hipótesis Nula (Ho) e Hipótesis Alternativa (Hi), la

segunda indica lo que se quiere demostrar y la primera lo contrario.
• Paso 2: Se define el Nivel de Significancia, donde se estable un rango que indicara
cuan aceptable es la hipótesis alternativa.
o α = 0.01 Optimista
o α = 0.05 Confiable
o α = 0.10 Pesimista
• Paso 3: se ha de calcular la media y la desviación estándar.
• Paso 4: se ha de rechazar o aceptar la hipótesis alternativa.
o Si la “probabilidad de error(P)” es mayor sobre el “nivel de significancia”
entonces se rechaza
o Si la “probabilidad de error(P)” es menor que el “nivel de significancia”
entonces se acepta.
De esta manera se valida la mejora entre medias demostrando que se logró optimizar o
no lo planteado en este trabajo.
3.2 Documentación del proyecto
En esta sección, se detallará la documentación realizada para este proyecto, esta

información fue desarrollada con el objetivo de comprender detalladamente, los aspectos
a desarrollar, como también, mantener un histórico de todos los procesos que forman la
base del sistema.
34
3.2.1 Diagrama de Casos de Uso
Se usa la técnica de diagrama de casos de uso para identificar los actores que estarán
involucrados en el uso del sistema.
Figura 9 - Diagrama de Casos de Uso (Elaboración propia)
35
3.2.2 Diagrama de clases
Los diagramas de clases identifican las principales características o atributos que

contempla el sistema, deben de agregar también las funciones, en este proyecto, el
diagrama representa los 3 tipos de usuarios que contempla: Comprador, Administrador y
vendedor, dado que las ventas dependen de un vendedor que asiste personalmente,
registra la venta y registra al vendedor que recibirá un correo con los documentos de
SOAT.
Figura 10 - Diagrama de Clases (Elaboración propia)
3.2.3 Diagramas de Secuencia
Se desarrolla esta clase de diagramas para los casos de uso de Administrador y vendedor,
estos deben de incluir los objetos y sus clases, debido a la cantidad considerable de
36
procesos que realiza el sistema, se han considera los más importantes para representar su
funcionalidad, dado que se quiere representar de manera gráfica el comportamiento del
sistema, presentadas en escenarios de uso para el Administrador, vendedor y del sistema.
3.2.3.1 Diagrama de Secuencia de Administrador
El Administrador registra la información necesaria para el cotizador además de evaluar

los estados de ventas.
37
38
Figura 11 - Diagramas de Secuencia de administrador (Elaboración propia)
39
3.2.3.2 Diagrama de Secuencia de Vendedor
El usuario solicita cotización de un vehículo y luego realizar la venta del mismo.
Figura 12 - Diagrama de Secuencia de Vendedor (Elaboración propia)
40
3.2.4 Diagrama de Procesos
El sistema debe de definir su alcance y límites para organizar y acelerar la

implementación, para estructurar los alcances se, analizan los procesos a continuación:
• Proceso – Registro de Información: El administrador registra las compañías de

seguros, los vehículos, precios, oficinas, usuarios en si generar toda la
información que necesita el cotizador para funcionar.
• Proceso – Solicitud de Cotización y venta: En este Proceso se puede observar
los pasos que necesita un vendedor o punto de venta para lograr realizar la venta
de los seguros vehiculares.
• Proceso – Generación de Cotizaciones y Reportes: El proceso donde el sistema
genera, los precios de las diferentes compañías aseguradoras, para que le cliente
pueda seleccionar y luego el proceso que le toma generar los reportes.
Figura 13 - Diagrama de procesos (Elaboración propia)
3.2.5 Diagrama de Componentes
En este apartado se definirá el diagrama de componentes, que observa las tres capas del
modelo vista controlar y nos muestra los paquetes que lo conforman, en la parte vista,
41
muestra el control de accesos, el sistema cotizador, las actividades de registro y los
reportes, en la parte del controlador, vemos el sistema gestor, su administrador de base de
datos y los servicios API REST, y por último en el modelo va la base de datos y el gestor
de bases de datos.
Figura 14 - Diagrama de Componentes (Elaboración propia)
3.2.6 Arquitectura del Sistema
Vamos a definir la arquitectura del sistema dividida en tres capas: la capa de interfaz al
cliente, la capa de negocio y la capa de datos. La capa de interfaz al cliente, provee el
acceso al usuario mediante una interfaz en el navegador, la capa de negocio siguiendo el
patrón MVC de ASP.NET permite la lógica de negocio y el acceso a datos, y por último
tenemos la capa de datos que es la persistencia y almacenamiento de datos.
42
Figura 15 - Arquitectura del sistema de ventas (Elaboración propia)
3.2.7 Herramientas de desarrollo
Para la elección de la herramienta de desarrollo se utilizó un cuadro de donde se muestran

sus principales ventajas.
MYSQL SPRING VUE.JS BOOSTRAP V.4

FRAMEWORK
Licencia Libre SI SI SI SI
Facilidad de Media Alta Alta Media
Aprendizaje
Compatibilidad Alta Alta Alta Alta
Navegadores Mayoría Mayoría Mayoría Mayoría
Principio de Desarrollo basado en Desarrollo basado en Desarrollo basado en Desarrollo basado en
Desarrollo Pruebas Pruebas Pruebas Pruebas
Memoria
recomendada 128 MB 512 MB 128 MB 128 MB
Lenguaje de
programación SQL Java JAVASCRIPT CSS, JAVASCRIPT
Sistema operativo Multi-plataforma Multi-plataforma Multi-plataforma Multi-plataforma
Tabla 3 - Tabla de comparación de Herramientas
3.2.8 Diagrama de base de datos
Este diagrama debe permitirnos visualizar, la arquitectura que tendrá la base de datos y
que serán implementados en los siguientes SPRINTS, este modelo será la guía para
implementar el modelo.
43
Figura 16 - Diagrama de Base de datos Vendedor (Elaboración propia).
3.2.8.1 Diccionario de datos
Este presenta la lista de los componentes detallados de la base de datos que conformaran
el sistema, por ejemplo: Clave (Nombre), Descripción, Tipo de dato y tamaño de archivos,
a continuación, se presenta los datos del diagrama entidad – relación del proyecto.
44
1. USUARIO: Esta tabla describe todos los datos del usuario
USUARIO
LLAVE NOMBRE CAMPO TIPO TAMAÑO DESCRIPCIÓN
PK Código de Usuario Cod_Usuario INT 11 Código único de Usuario
Nombres Nombres VARCHAR 45 Nombres del Usuario
Apellidos Apellidos VARCHAR 45 Apellidos del Usuario
E-mail Email VARCHAR 45 E-mail del Usuario
Contraseña Contraseña VARCHAR 45 Contraseña del Usuario
Teléfono Telefono INT 11 Teléfono del Usuario
Habilitado Habilitado TINYINT 1 Habilitado para usar el sistema
Ciudad Ciudad VARCHAR 45 Ciudad del Usuario
Provincia Provincia VARCHAR 45 Provincia del Usuario
Región Region VARCHAR 45 Región del Usuario
DNI DNI INT 8 DNI del Usuario
Dirección Direccion VARCHAR 45 Dirección del Usuario
Fecha de Nacimiento Fecha_Nacimiento DATE Fecha de Nacimiento del Usuario
Fecha de Creacion Fecha_Creacion DATE Fecha de Creación del Usuario
FK Código de Sesión Cod_Sesion INT 11 Cuantas sesiones y cuando ingreso
FK Código de Rol Cod_Rol INT 11 Rol en el sistema
FK Código de Oficina Cod_Oficina INT 11 A qué oficina Pertenece
Tabla 4 - Diccionario de los datos de la tabla Usuario
2. VENTA: Esta tabla describe todos los datos de una venta.
VENTA
PK Código de Venta Cod_Venta INT 11 Código de venta
FK Código de Usuario Cod_Usuario INT 11 Código único de Usuario
FK Código de Comprador Cod_Usuario INT 11 Código del comprador
FK Código de Póliza Cod_Poliza INT 11 Código de Póliza
FK Código de Cotización Cod_Cotizacion INT 11 Código de la cotización
Fecha de Venta Fecha_Nacimiento DATE Fecha que se realizó la venta
Fecha de Inicio Fecha_Creacion DATE Inicio de vigencia de SOAT
Fecha de Fin Fecha_Nacimiento DATE Fin de vigencia de SOAT
Tabla 5 - Diccionario de los datos de la tabla venta
45
3. COTIZACIÓN: Esta tabla describe todos los datos de una Cotización
COTIZACIÓN
PK Código de Cotización Cod_Cotizacion INT 11 Código de la Cotización
FK Código del Vehículo Cod_Vehiculo INT 11 Código único del Vehículo
Ciudad Ciudad VARCHAR 45 Ciudad de la cotización
Precio Precio INT 10 Precio de la cotización
Calendario Calendario INT 11 A que calendario de precios pertenece
Fecha de Cotización Fecha DATE Fecha que se realizó la venta
Tabla 6 - Diccionario de los datos de la tabla cotización
4. VEHÍCULOS: Esta tabla describe todos los datos de los vehículos.

VEHÍCULOS
PK Código de Vehículo Cod_vehiculo INT 11 Código de la Cotización
Marca Marca VARCHAR 45 Marca del vehículo
Modelo Modelo VARCHAR 45 Modelo del vehículo
Clase Clase VARCHAR 45 Clase del vehículo
Tipo Tipo VARCHAR 45 Tipo del vehículo
Categoría Categoría VARCHAR 45 Categoría del vehículo
Asientos Asientos INT 10 Asientos del vehículo
Excepcionado Excepcionado TINYINT 1 Si el vehículo es Excepcionado
Tabla 7 - Diccionario de los datos de la tabla de vehículos
46
5. TABLAS DE PÓLIZAS, COMPAÑÍAS ASEGURADORAS, OFICINA,
ROLES DE USUARIO, SESIÓN DE USUARIO Y NUMERO DE SESIÓN:
Esta tabla describe todos los datos de las tablas de apoyo del sistema
PÓLIZAS
PK Código de Póliza Cod_Poliza INT 11 Código de la Póliza
FK Código de Compañía Cod_Compania INT 11 Compañía Aseguradora a cuál pertenece
Póliza Poliza VARCHAR 45 Numero de Póliza
COMPAÑÍAS ASEGURADORAS
PK Código de Compañía Cod_Compania INT 11 Código único de Compañía
Descripción Descripcion VARCHAR 45 Descripción o Nombre de la Compañía
Dirección Direccion VARCHAR 45 Dirección de la compañía
Teléfono Telefono INT 10 Teléfono de la compañía
OFICINA
PK Código de la Oficina Cod_Oficina INT 11 Código único de la Oficina
Descripción Descripcion VARCHAR 45 Descripción o Nombre de la Oficina
Ciudad Ciudad VARCHAR 45 Descripción o Nombre de la Oficina
Dirección Direccion VARCHAR 45 Dirección de la Oficina
Teléfono Telefono INT 10 Teléfono de la Oficina
ROLES DE USUARIO
PK Código del Rol Cod_Rol INT 11 Código único del Rol de usuario
Descripción Descripcion VARCHAR 45 Descripción o Nombre del Rol de usuario
SESION DE USUARIO
PK Código de Sesión Cod_Sesion INT 11 Código único de la sesión
FK Código del numero Cod_num INT 11 Código del número de sesión
NUMERO DE SESIÓN
PK Código de Sesión Cod_Sesion INT 11 Código único de la sesión
Fecha de sesión Fecha DATE Fecha de la sesión
Token Token VARCHAR 45 Token único de sesión
Expiración Expiracion VARCHAR 45 Fecha de expiración del token
Tabla 8 - Diccionario de los datos de las tablas de apoyo del sistema
3.2.9 Conformación del equipo de trabajo
En este apartado, se presenta los recursos humanos con lo que cuenta el proyecto, este
equipo de trabajo estará encargado de desarrollar como revisar el “PRODUCT
BACKLOG”
47
Equipo de trabajo
área de Labor Rol Persona Grado
Análisis y Planificación PRODUCT OWNER 1 Gerente General
Análisis y Planificación STAKEHOLDERS 5 Administradores
Carlos Eduardo Arbieto Batallanos
Análisis y Planificación SCRUM MASTER Certificado por curso Bachiller en Ingeniería de
SCRUM(Anexo1) Sistema
Capa Lógica BACK-END Desarrollador Full- Oscar Edmit Quispe Poccohuanca Maestro en Ciencias
Stack Informáticas
Capa de Presentación FRONT- Desarrollador Full- Ricardo Rildo Coronado Perez Maestro en Ciencias
END Stack Informáticas
Capa de Presentación FRONT- Desarrollador UX/UI Carlos Eduardo Arbieto Batallanos Bachiller en Ingeniería de
END Sistema
Tabla 9 - Equipo de trabajo
3.2.10 Capacitación y soporte
Es necesario recalcar, que luego del desarrollo del sistema, la implantación requiere
capacitación al personal, por lo que dentro del plan se contempló, una estrategia de
capacitación que consistía en reuniones de 2 horas durante una semana solo para los
administradores y otra semana para capacitación a los vendedores, además se brindó
asistencia remota, por medio de una mesa de ayuda (HELP DESK), para que todo el
personal conozca las funciones del sistema, con el fin de cumplir el principio de usuario
experto planteado en el proceso de transformación digital, el soporte consiste en una
revisión mensual de las tablas de mantenimiento, observando la cantidad de información
que se ingresa y midiendo los tiempo de respuesta del sistema, no obstante parte del
soporte consiste en la asistencia remota para solución de errores, que el gerente general
reporta.
3.3 Análisis e interpretación
3.3.1 Estructura de negocio de las empresas Corredoras de seguros
Una empresa corredora de seguros, se encarga de captar clientes, vender seguros y

asesorarlos durante el tiempo que la póliza es vigente, su atractivo principal es la
comunicación directa con el cliente, dado que los clientes prefieren muchas veces adquirir
seguros a través de corredoras, ya que su atención es personal y directa en vez de contactar
directamente con las compañías asegurados, que por lo general son muy grandes, y no
otorgan asesoramiento suficiente.
48
Figura 17 - C
Por su naturaleza de negocio, una empresa corredora de seguros requiere el uso de sus
propias herramientas dado a que no solo representan a una aseguradora, sino pueden
representar a varios y muchas veces, estos buscan generar clientes ofreciendo los precios
más bajos, dado a esta modalidad, su negocio consiste en cotizar los precios de todas las
aseguradoras, como medio de captar clientes.
3.3.2 Recopilación de las Historias de Usuario Para el Sistema
Las historias detallan los requisitos del cliente, y bajo estas se basan los SPRINTS
HISTORIA DE USUARIO HISTORIA DE USUARIO
Nombre de la Historia: Registro, actualización y eliminación Nombre de la Historia: Registro, actualización y eliminación
de usuarios de las compañías asegurados.
Numero: GV-01 Numero: GV-02
Usuario: Administrador Usuario: Administrador
Prioridad: Alta Prioridad: Media

Descripción: Como el sistema va a tener acceso mediante Descripción: En esta tabla se ingresas todas las aseguradoras
privilegios y usuarios, se requiere de una contraseña, se necesita de las que vamos a vender certificados SOAT
registrar usuarios y asignar privilegios estos, con la finalidad
de otorgar permisos para realizar distintos procesos en el
sistema.
Como probarlo: Como probarlo:
• Ingresar al sistema con rol de administrador. • Ingresar al sistema con rol de administrador.
• Registrar datos personales del usuario, así como el • Registrar los datos de las compañías asegurados
usuario de acceso y su respectiva contraseña. • Guardar los datos registrados, actualizados o
• Guardar los datos registrados, actualizados o eliminados
eliminados
Tabla 10 - Historia de Usuario 1 y 2
49
Nombre de la Historia: actualización y eliminación de Nombre de la Historia: Registro, actualización y eliminación
Oficinas de Tipos de uso de vehículos

Descripción: Como el sistema va a tener acceso mediante Descripción: Es necesario contar con tablas de mantenimiento
privilegios y usuarios, se requiere la creación de oficinas, para de los datos necesarios para hacer una cotización, esta tabla se
identificar qué puntos de venta pertenecen a las empresas y llena con datos del MTC
cuales son externos.
• Registrar los datos de la oficina • Registrar los datos de Tipos de uso
• Guardar los datos registrados, actualizados o • Guardar los datos registrados, actualizados o
eliminados. eliminados

de categorías de vehículos. de las clases de vehículos
Prioridad: Media Prioridad: Media

Descripción: Es necesario contar con tablas de mantenimiento Descripción: : Es necesario contar con tablas de mantenimiento
de los datos necesarios para hacer una cotización, esta tabla se de los datos necesarios para hacer una cotización, esta tabla se
llena con datos del MTC llena con datos del MTC
• Registrar los datos de las categorías de los vehículos • Registrar los datos de las categorías de las clases de
• Guardar los datos registrados, actualizados o los vehículos a cotizar
eliminados • Guardar los datos registrados, actualizados o
eliminados
50
de los VCC (vehículos, clases y categorías) de los vehículos de los precios de los vehículos sin excepciones
Prioridad: Media Prioridad: Alta

Descripción: En esta tabla nosotros integraremos los datos de Descripción: Para colocar un precio correctamente a un
mantenimiento anteriores para crear una tabla única, donde vehículo lo que se debe observar, es a que grupo pertenece, si
podremos hacer una inserción directa e integración, de este vehículo por ejemplo pertenece a la categoría M1, a un tipo
vehículos, y los agruparemos en grupos por números de de uso particular y a la clase Automóvil, podría tratarse de un
asientos, para luego asignarles los precios por ejemplo Volkswagen gol que tiene menos accidente como
otros vehículos con las mismas características como un Tico, es
por eso que las aseguradoras otorgan precios diferentes para
poder cubrir la cantidad de accidentes que estos automóviles
puedan estar afectados.
• Registrar los datos de los VCC • Registrar los datos de los precios de vehículos sin
• Guardar los datos registrados, actualizados o excepciones
eliminados • Guardar los datos registrados, actualizados o
eliminados

de los precios de los vehículos excepcionados de los calendarios de Precios de vehículos

Descripción: En esta historia debemos insertar precios de los Descripción: Los precios de los vehículos, cambian
vehículos excepcionados. regularmente, por cada compañía, y cuando suceden estos
cambios, los retrasos en el entendimiento de estos, generan
grandes pérdidas, por eso, al recibir un nuevo calendario de
precios, estos ya pueden estar listos para activación
• Registrar los datos de los precios de vehículos • Registrar los datos de calendarios de precios
excepcionados • Guardar los datos registrados, actualizados o
• Guardar los datos registrados, actualizados o eliminados
eliminados
51
Nombre de la Historia: : Registro, actualización y eliminación Nombre de la Historia: Registro, actualización y eliminación
de certificados de Pólizas SOAT, uno por uno. de certificados de Pólizas SOAT, masivo

Descripción: Los certificados SOAT, se ingresan antes de su Descripción: Los certificados SOAT, se ingresan antes de su
venta, para ser asignados a los vendedores, en esta vista se debe venta, para ser asignados a los vendedores, en esta vista se debe
ingresar las pólizas, sus compañías el tipo de póliza y a que usuario ingresar las pólizas, sus compañías el tipo de póliza y a que
se asignará usuario se asignara de manera múltiple, para esto se necesita
identificar el prefijo, desde que numero, hasta que numero, el
post-fijo de la cantidad de pólizas a ingresar
• Registrar los datos póliza unitario • Registrar los datos de calendarios de precios
• Guardar los datos registrados, actualizados o • Guardar los datos registrados, actualizados o
eliminados eliminados

Nombre de la Historia: Asignación y eliminación de Nombre de la Historia: Re-Asignación de certificados de
certificados de Pólizas SOAT a usuarios. Pólizas SOAT a otros usuarios.

Descripción: Los certificados SOAT, se ingresan previamente Descripción: Cuando se requiere hacer una re-asignación de
para luego asignarlos a los puntos de venta, estos también podrían los certificados a otros usuarios, por diversos motivos, estos
ser eliminados deben poder cambiar de un usuario a otro, pero solos los NO
VENDIDOS
• Asignar los certificados a puntos de venta o usuarios • Re-Asignar los certificados de usuarios
• Guardar los datos, actualizados o eliminados • Guardar los datos y actualizarlos
52
Nombre de la Historia: Revisión y eliminar de los Estados de Nombre de la Historia: Revisión de Ventas terminadas
venta en proceso
Usuario: Administrador y vendedor Usuario: Administrador y vendedor

Descripción: Para contar con un control continuo de las ventas Descripción: Para contar con un control continuo de las ventas
que se realizan en la empresa, se requiere hacer una revisión en que se realizan en la empresa, se requiere hacer una revisión en
tiempo real de todos los estados de venta de los usuarios, y los tiempo real de las ventas realizadas para el administrador de
puntos de venta también deben observar sus propios estados todos los usuarios y para los puntos de venta, sus propias ventas
• Ingresar al sistema con rol de administrador o • Ingresar al sistema con rol de administrador o
vendedor vendedor
• Observar y eliminar las ventas en proceso con • Observar las ventas terminadas
pólizas asignadas
• Observar y eliminar las ventas en proceso que no
registraron pagos
• Guardar los datos y actualizarlos

Nombre de la Historia: Observar y Anular pólizas SOAT Nombre de la Historia: Cotización de precios de Vehículos
vendidas Revisión y eliminar de los Estados de venta en
proceso
Usuario: : Administrador y vendedor Usuario: Administrador y vendedor
Prioridad: Media Prioridad: Alta

Descripción: Para contar con un control continuo de las ventas Descripción: los criterios de cotización son las de seleccionar
que se realizan en la empresa, se requiere hacer una revisión en Marca, Modelo, Ciudad, y Tipos de Usos
tiempo real de todos los estados de venta de los usuarios, y los
puntos de venta también deben observar sus propios estados
• Ingresar al sistema con rol de administrador y • Ingresar al sistema con rol de administrador o
vendedor vendedor
• Observar las ventas terminadas y solicitar la • Cotizar un vehículo
anulación • Elegir y guardar el precio y aseguradora
• Guardar y actualizar el sistema seleccionado
53
Nombre de la Historia: Registrar datos del vehículo, Nombre de la Historia: Imprimir el certificado o reasignar la
contratante y pagos póliza
Usuario: : Administrador y vendedor Usuario: Administrador y vendedor
Prioridad: Alta Prioridad: Alta

Descripción: para realizar una venta, se debe registrar una póliza, Descripción: El sistema debe imprimir los datos de la venta,
los datos de vehículos, los datos del contratante, los datos del pago, sobre el formato de certificado de las aseguradoras y poder
la fecha de iniciación de validez de póliza. y guardarlos para que reasignar una nueva póliza, por si hubo problemas en la
cuando se realice una venta, pueda consultar el DNI y el correo del impresión
cliente, y no volverlo a llenar
• Ingresar al sistema con rol de administrador o • Ingresar al sistema con rol de administrador o
vendedor vendedor
• Registrar datos del vehículo, contratante y pagos • Imprimir el certificado o reasignar la póliza
• Guardar y actualizar en el sistema • Guardar y actualizar en el sistema
HISTORIA DE USUARIO
Nombre de la Historia: Generar Reportes del Sistema
Numero: GV-21
Usuario: : Administrador y vendedor
Prioridad: Alta
Descripción: El sistema debe Generar distintos reportes de
mantenimiento para saber, cuanto se ha generado en el día, cuanto
se ha ganado por aseguradora por usuarios y en general
Como probarlo:
• Ingresar al sistema con rol de administrador o

vendedor
• Generar reportes del sistema en formato Excel
Tabla 20 - Historia de Usuario 21
54
3.4 Desarrollo de SPRINTS
De acuerdo a la metodología SCRUM lo primero que se tiene que crear para planificar el
desarrollo del sistema es el “PRODUCT BACKLOG”, esta tabla permite conocer las
tareas que se tienen que realizar, estas deben de estar categorizadas por prioridades. Es
necesario recalcar que todas las actas de reunión de planificación de los SPRINTS están
documentadas en los anexos de este trabajo, además de incluir los manuales de usuario,
la tabla de precios de los vehículos y las encuestas de aceptación, el modelo que se va a
utilizar es el que se muestra a continuación:
N de Historia de Estimación/Esfuerzo Modulo Iteración Prioridad

Historia Usuario (días)
Tabla 21 - Modelo de PRODUCT BACKLOG
Este presentara la cantidad de tareas a realizar, así como los módulos que pertenecen a
cada una, cada SPRINT debe presentar, a quien pertenece, como su descripción, su
estimación en tiempo, y cuál será su priorización, a continuación:
• AU: Administración de Usuarios

• MAN: Administración de tablas de mantenimiento
• PR: Administración De Precios de Vehículos
• PA: Administración de Pólizas y asignación
• EV: Administración de Estados de ventas
• CO: Cotizador
• RE: Generador de reportes
3.4.1 Planificación del PRODUCT BACKLOG
Para el presente proyecto se ha elaborado la planificación o más conocida como el

SPRINT 0, en primera instancia se dará la estimación del PRODUCT BACKLOG, por
lo que fue necesaria estimar de manera aproximada el tiempo que tomara desarrollar, es
importante realizar la estimación de acuerdo a las prioridades del PRODCT OWNER y
55
el equipo de desarrollo, cada uno estimará con números enteros entre 0 y 500, los tiempos
fueron sugeridos por el equipos de desarrollo para cada iteración según su experiencia
desarrollando sistemas de este tipo.
Figura 18 - Importancia para la estimación (Elaboración propia)
Estimación del PRODUCT BACKLOG

Estimación Estimación
Numero Historia Días PRODUCT EQUIPO TOTAL VALOR
OWNER DEV.
"SEGURIDAD E INTERFAZ RESPONSIVA" 1 100 100 200 BAJA
GV-01 Registro, actualización y eliminación de usuarios 2 300 400 700 ALTA
GV-02 Registro, actualización y eliminación de las compañías 2 200 300 500 MEDIA
asegurados
GV-03 Registro, actualización y eliminación de Oficinas 2 200 300 500 MEDIA
GV-04 Registro, actualización y eliminación de Tipos de uso de 2 200 300 500 MEDIA
vehículos
GV-05 Registro, actualización y eliminación de categorías de 2 300 300 600 MEDIA
vehículos
GV-06 Registro, actualización y eliminación de las clases de 2 300 300 600 MEDIA
vehículos
GV-07 Registro, actualización y eliminación de los VCC de los 3 300 300 600 MEDIA
Vehículos
Registro, actualización y eliminación de los precios de
GV-08 los vehículos 5 300 400 700 ALTA
sin excepciones
Registro, actualización y eliminación de los precios de
GV-09 los vehículos 3 300 400 700 ALTA
excepcionados
Registro, actualización y eliminación de los calendarios
GV-10 de Precios 2 200 400 600 MEDIA
de vehículos
Registro, actualización y eliminación de certificados de
GV-11 Pólizas 2 200 300 500 MEDIA
SOAT, uno por uno
Registro, actualización y eliminación de certificados de
GV-12 Pólizas 3 200 300 500 MEDIA
SOAT, masivo
Asignación y eliminación de certificados de Pólizas
GV-13 SOAT a usuarios 3 300 300 600 MEDIA
Re-Asignación de certificados de Pólizas SOAT
GV-14 a otros usuarios 3 100 200 300 MEDIA
GV-15 Revisión y eliminar de los Estados de venta en proceso 3 100 200 300 MEDIA
56
GV-16 Revisión de Ventas terminadas 2 200 200 400 MEDIA
GV-17 Observar y Anular pólizas SOAT vendidas 2 200 200 400 MEDIA
GV-18 Cotización de precios de Vehículos. 5 400 500 900 ALTA
GV-19 Registrar datos del vehículo, contratante y pagos 4 400 500 900 ALTA
GV-20 Imprimir el certificado o reasignar la póliza 3 500 400 900 ALTA
GV-21 Generar Reportes del Sistema 6 500 500 1000 ALTA
Tabla 22 - Estimaciones del PRODUCT BACKLOG
A continuación, el resumen de las historias de usuario con la estimación en días que se

ha determinado para cada módulo establecido para el desarrollo, el tiempo total estimado
es el de 62 días, teniendo en cuenta que durante la planificación se estimó 3 meses que
son aproximadamente 66 días laborables, se encuentra en el rango estimado:
PRODUCT BACKLOG
Numero Historia Modulo SPRINT Días Prioridad

"SEGURIDAD E INTERFAZ RESPONSIVA" 0 1 BAJA
GV-01 Registro, actualización y eliminación de usuarios AU ALTA
GV-02 Registro, actualización y eliminación de las compañías asegurados MAN

GV-03 Registro, actualización y eliminación de Oficinas MAN
GV-04 Registro, actualización y eliminación de Tipos de uso de vehículos MAN
SPRINT 1 15
GV-05 Registro, actualización y eliminación de categorías de vehículos MAN
GV-06 Registro, actualización y eliminación de las clases de vehículos MAN
MEDIA
GV-07 Registro, actualización y eliminación de los VCC de los Vehículos MAN
Registro, actualización y eliminación de los precios de los vehículos

GV-08 sin excepciones PR
ALTA
Registro, actualización y eliminación de los precios de los vehículos
GV-09 excepcionados PR
Registro, actualización y eliminación de los calendarios de Precios

GV-10 de vehículos PR
SPRINT 2 15
Registro, actualización y eliminación de certificados de Pólizas
GV-11 SOAT, uno por uno PA MEDIA
Registro, actualización y eliminación de certificados de Pólizas

GV-12 SOAT, masivo PA
Asignación y eliminación de certificados de Pólizas

GV-13 SOAT a usuarios PA
Re-Asignación de certificados de Pólizas SOAT

GV-14 a otros usuarios PA
GV-15 Revisión y eliminar de los Estados de venta en proceso EV

SPRINT 3 13 MEDIA
GV-16 Revisión de Ventas terminadas EV
57
GV-17 Observar y Anular pólizas SOAT vendidas EV
GV-18 Cotización de precios de Vehículos. CO
GV-19 Registrar datos del vehículo, contratante y pagos CO

SPRINT 4 18 ALTA
GV-20 Imprimir el certificado o reasignar la póliza CO
GV-21 Generar Reportes del Sistema CO
Tabla 23 - PRODUCT BACKLOG
3.4.2 Elaboración de los SPRINTS
La implementación de cada SPRINT requiere que se desarrollen tablas donde se permitan

dar a conocer, los diversos procesos o tareas que le corresponde a cada iteración y los
tiempos de trabajo.
1. SPRINT 0: En el SPRINT 0 se realizaron las tareas de planificación y estimación

de los SPRINTS siguientes, además de asegurar que el sistema tenga seguridad de
comunicación por lo que se optó por adquirir un certificado SSL de seguridad,
además de que el sistema cuente con una interfaz responsiva, ósea que se adapte
a todos los tamaños de los diferentes dispositivos
• Priorización: Las tareas elegidas para este SPRINT fueron priorizadas en
consideración al proceso del sistema, es por eso que las primeras
actividades a realizar son la planificación y estimación y se dejaron para
el final las actividades de seguridad e interfaz responsiva.
2. SPRINT 1: En el primer SPRINT se realizó las tareas de mantenimiento
necesarias para el funcionamiento del sistema. Indica cuando empieza y
contempla la administración de usuarios, tablas de que son necesarias para crear
vehículos y privilegios.
• Priorización: Las tareas elegidas para este SPRINT fueron priorizadas en
consideración al proceso del sistema, es por eso que las primeras
actividades a realizar son la creación del inicio de sesión, administración
de usuarios. De esta manera tenemos terminadas estas tareas que son
dependientes para el funcionamiento del sistema.
58
SPRINT 1 Inicio: 01/09/2017 Culminació 22/09/2017
n:
Tareas 0 Días Pendientes: 0
Pendientes:
Prioridad Historia de Usuario Responsables Duración Estado
de Días
Alta Registro, actualización y eliminación de usuarios Equipo de 2 Terminado
Desarrollo
Media Registro, actualización y eliminación de las compañías Equipo de 2 Terminado
asegurados Desarrollo
Media Registro, actualización y eliminación de Oficinas Equipo de 2 Terminado
Desarrollo
Media Registro, actualización y eliminación de Tipos de uso de Equipo de 2 Terminado
vehículos Desarrollo
Media Registro, actualización y eliminación de categorías de Equipo de 2 Terminado
Media Registro, actualización y eliminación de las clases de vehículos Equipo de 2 Terminado
Desarrollo
Media Registro, actualización y eliminación de los VCC ( vehículos, Equipo de 2 Terminado
clases y categorías) de los Vehículos Desarrollo
Tabla 24 - SPRINT 1
3. SPRINT 2: En el segundo SPRINT se realizaron las actividades de

mantenimiento de los precios de los vehículos y los calendarios de precios. ste
SPRINT se definirá después de la etapa inicial, y es necesaria antes de la
cotización. así mismo en este SPRINT se consideró también, la inclusión de la
creación de las pólizas menos la asignación ya que ese proceso necesitara más
tiempo de desarrollo.
• Priorización: Las tareas elegidas para este SPRINT fueron priorizadas
en consideración al proceso del sistema, es por eso que las primeras
actividades a realizar son las de creación de precios y luego crear los
calendarios, y luego la creación de certificados pólizas SOAT. De esta
manera tenemos terminadas estas tareas que son dependientes para el
funcionamiento del sistema.
59
SPRINT 2 Inicio: 25/09/2017 Culminació 14/10/2017
n:
Pendientes:
Prioridad Historia de Usuario Responsables Duración Estado
de Días
Alta Registro, actualización y eliminación de los precios de los vehículos Equipo de 5 Terminado
sin excepciones Desarrollo
Alta Registro, actualización y eliminación de los precios de los vehículos Equipo de 3 Terminado
excepcionados Desarrollo
Media Registro, actualización y eliminación de los calendarios de Precios de Equipo de 2 Terminado
Media Registro, actualización y eliminación de certificados de Pólizas Equipo de 2 Terminado
SOAT, uno por uno. Desarrollo
Media Registro, actualización y eliminación de certificados de Pólizas Equipo de 3 Terminado
SOAT, masivo Desarrollo
Tabla 25 - SPRINT 2
4. SPRINT 3: En el tercer SPRINT se realizaron las tareas que corresponden a todas

las asignaciones y re-asignaciones de pólizas además de incluir las revisiones de
ventas por proceso y terminadas.
• Priorización: Las tareas elegidas para este SPRINT son de prioridad
Media, pero eran necesarias de desarrollar antes del cotizador, ya que
era el medio de verificación para ver si nuestro cotizador está
funcionando correctamente
SPRINT 3 Inicio: 20/10/2017 Culminación: 9/11/2017

Pendientes:
Prioridad Historia de Usuario Responsables Duración de Días Estado
Media Asignación y eliminación de certificados de Pólizas SOAT a Equipo de 3 Terminado

usuarios. Desarrollo
Media Re-Asignación de certificados de Pólizas SOAT a otros Equipo de 3 Terminado
usuarios Desarrollo
Media Revisión y eliminar de los Estados de venta en proceso Equipo de 3 Terminado
Desarrollo
Media Revisión de Ventas terminadas Equipo de 2 Terminado
Desarrollo
Media Observar y Anular pólizas SOAT vendidas Equipo de 2 Terminado
Desarrollo
Tabla 26 - SPRINT 3
60
5. SPRINT 4: En el cuarto SPRINT se realizaron los procesos correspondientes al
cotizador y a los reportes de ventas
• Priorización: En el cuarto SPRINT se realizaron los procesos
correspondientes al cotizador y a los reportes de ventas
SPRINT 4 Inicio: 13/11/2017 Culminación: 9/12/2017
Tareas Pendientes: 0 Días Pendientes: 0
Prioridad Historia de Usuario Responsables Duración de Días Estado
Alta Cotización de precios de Vehículos. Equipo de Desarrollo 5 Terminado
Alta Registrar datos del vehículo, contratante y pagos Equipo de Desarrollo 4 Terminado
Alta Imprimir el certificado o reasignar la póliza Equipo de Desarrollo 3 Terminado
Alta Generar Reportes del Sistema Equipo de Desarrollo 6 Terminado
Tabla 27 - SPRINT 4
3.5 Requerimientos Funcionales y no Funcionales
En esta sección se detalla el apartado de los requerimientos definidos en la planificación

del “PRODUCT BACKLOG”, analizando las funciones y procesos, que van a ser
desarrollados:
Requerimientos Funcionales y no Funcionales

Numero Historia Requisito Funcional Requisito No Funcional
El sistema de información brindará
seguridad para ser utilizado por
usuarios registrados en el sistema,
con diferentes niveles de acceso.
SPRINT 0 "SEGURIDAD E INTERFAZ RESPONSIVA" El sistema de información debe
poseer
un sistema responsivo.
El sistema debe incluir
Registro, actualización y eliminación de usuarios El sistema permite gestionar recuperación de contraseña
usuarios
Registro, actualización y eliminación de las El sistema permite gestionar
Compañías asegurados compañías
SPRINT 1 Registro, actualización y eliminación de Oficinas El sistema permite gestionar
oficinas
Registro, actualización y eliminación de Tipos de El sistema permite gestionar tipos
uso de vehículos
Registro, actualización y eliminación de categorías El sistema permite gestionar
de vehículos vehículos
Registro, actualización y eliminación de las clases de El sistema permite gestionar clases
vehículos
61
El sistema permite gestionar la
Registro, actualización y eliminación de los VCC de relación entre vehículos, clases y
los Vehículos categorías
Registro, actualización y eliminación de los precios El sistema permite gestionar
de los vehículos sin excepciones precios de vehículos sin
excepciones
Registro, actualización y eliminación de los precios El sistema permite gestionar
SPRINT 2 de los vehículos excepcionados precios de vehículos
excepcionados
Registro, actualización y eliminación de los El sistema permite gestionar El sistema debe permitir
calendarios de precios de vehículos administrar calendarios por fechas
Precios de vehículos excepcionados
Registro, actualización y eliminación de certificados El sistema permite gestionar
de pólizas
Pólizas SOAT, uno por uno
Registro, actualización y eliminación de certificados El sistema permite gestionar
de Pólizas masivas
Pólizas SOAT, masivo
Asignación y eliminación de certificados de El sistema debe permitir asignar
Pólizas SOAT a usuarios pólizas
Re-Asignación de certificados de Pólizas SOAT a El sistema debe permitir re-asignar
otros usuarios pólizas
SPRINT 3 El sistema debe permitir revisar
Revisión y eliminar de los Estados de venta en estados de venta
proceso
El sistema debe permitir revisar el
Revisión de Ventas terminadas detalle de la venta terminada
El sistema debe permitir anular El sistema debe permitir observar
Observar y Anular pólizas SOAT vendidas pólizas de SOAT pólizas de SOAT
El sistema debe permitir cotizar El sistema debe permitir re-cotizar
Cotización de precios de Vehículos. vehículos vehículos
El sistema debe permitir ingresar El sistema debe permitir regresar a
SPRINT 4 Registrar datos del vehículo, contratante y pagos datos de contratante y pagos ingresar datos
El sistema debe permitir imprimir El sistema debe permitir re-asignar
Imprimir el certificado o reasignar la póliza pólizas pólizas para impresión
El sistema debe generar reportes El sistema debe generar reportes
Generar Reportes del Sistema por fechas históricos
Tabla 28 - Requerimientos Funcionales y no Funcionales
62
3.5.1 Diseño de Interfaces (MOCKUPS)
Para este apartado, se reúne como necesario exponer el diseño de las interfaces que la
empresa valido antes del desarrollo del sistema, cuya fuente es la elaboración propia.
Figura 19 - Diseño de interfaz inicio de sesión (Elaboración

propia)
Figura 20 - Diseño de interfaz de administración de
Aseguradoras (Elaboración propia)
Figura 22 - Diseño de interfaz de administración de Figura 21 - Diseño de interfaz de administración de

Oficinas (Elaboración propia) Usuarios (Elaboración propia)

Tipos de uso de vehículos (Elaboración propia) Categorías de vehículos (Elaboración propia)
63
Clases de vehículos (Elaboración propia) VCC (Elaboración propia)

Precios (Elaboración propia) pólizas por unidad (Elaboración propia)

pólizas masivas (Elaboración propia) asignación de pólizas (Elaboración propia)
64
estados (Elaboración propia) cotizador (Elaboración propia)

cotizador - ingreso datos del vehículo (Elaboración cotizador - ingreso datos del contratante (Elaboración
propia) propia)

cotizador - ingreso datos del pago (Elaboración cotizador - impresión de la póliza (Elaboración
propia) propia)
65
Figura 37 - Diseño de interfaz de administración de Reportes del sistema (Elaboración propia)
3.5.2 Planificación de los SPRINTS en TRELLO
En TRELLO se han detallado lo que será necesario para implementar SPRINTS, consiste
en compartir todas las labores de los SPRINTS, del PRODUCT BACKLOG con el equipo
de desarrollo:
• Entidades utilizadas: Actividades por SPRINT

• Interfaces creadas: Se muestra como ejemplo las actividades del SPRINT 1
o La primera: Actividades del SPRINT y su estado
o ¿Cuáles fueron los inconvenientes?
o La segunda: Muestra el detalle de una actividad del SPRINT 1
66
Figura 38 - Interfaz de TRELLO con las actividades del SPRINT 1 y sus procesos(Elaboración propia)
Figura 39 - Interfaz de TRELLO con el detalle de una actividad (Elaboración propia)
3.5.3 Implementación de los SPRINTS
En esta sección se presentarán todas las tareas realizadas durante, el desarrollo de la

aplicación se realizó con el FRAMEWORK en VUE.JS y BOOSTRAP V.4 para el
FRONT-END expresadas en interfaces, para el acceso a datos se usó SPRING
FRAMEWORK, como base de datos se usó MySQL y como servidor WEB se utilizó
DIGITAL OCEAN.
Entregables del SPRINT 0:
• Entregable de seguridad y vista responsiva: Este entregable contiene

las siguientes funcionalidades, La seguridad fue implementada a través de
la adquisición de un certificado SSL, y la imagen responsiva engloba todos
los módulos
67
3.5.3.1 Entregables del SPRINT 1:
Figura 40 - Vista responsiva móvil (Elaboración propia)
a) Entregable de Registro, actualización y eliminación de usuarios: Este

entregable contiene las siguientes funcionalidades:
• Entidades utilizadas: Usuarios y Roles.
• Interfaces creadas: Se desarrollaron dos vistas
o La primera: Inicio de Sesión
o La segunda: Muestra la lista general de usuario, a través del
cual se puede ir hacia las vistas de registro, actualización y
eliminación de usuario, se puede observar cómo se pueden
editar los usuarios en la siguiente figura.
Figura 41 - Interfaz de inicio de sesión de usuarios (Elaboración propia)
68
Figura 42 - Interfaz de administración de usuarios (Elaboración propia)
b) Entregable de Registro, actualización y eliminación de las compañías

asegurados: Este entregable contiene las siguientes funcionalidades:
• Entidades utilizadas: Aseguradoras.
• Interfaces creadas: Se desarrolló una sola vista
o La primera: Es la vista para registrar, actualizar y eliminar
aseguradoras además de agregar imágenes a las aseguradoras
o La segunda: Muestra la lista general de usuario, a través del
cual se puede ir hacia las vistas de registro, actualización y
eliminación de usuario, se puede observar cómo se pueden
editar los usuarios en la siguiente figura:
Figura 43 - Interfaz de administración de aseguradoras (Elaboración propia)
69
c) Entregable de Registro, actualización y eliminación de Oficinas: Este
• Entidades utilizadas: Oficina.
o La primera: vista para registrar, actualizar y eliminar oficinas.
Figura 44 - Interfaz de administración de oficinas (Elaboración propia)
d) Entregable de Registro, actualización y eliminación de Oficinas: Este

• Entidades utilizadas: Tipos de uso de vehículos
70
Figura 45 - Interfaz de administración de tipos de uso (Elaboración propia)
o La primera: vista para registrar, actualizar y eliminar tipos de uso

de vehículos.
e) Entregable de Registro, actualización y eliminación de categorías de
vehículos: Este entregable contiene las siguientes funcionalidades:
• Entidades utilizadas: Categorías de vehículos.
o La primera: vista para registrar, actualizar y eliminar Categorías
de vehículos.
Figura 46 - Interfaz de administración de Categorías (Elaboración propia)
71
f) Entregable de Registro, actualización y eliminación de las clases de
vehículos: Este entregable contiene las siguientes funcionalidades:
• Entidades utilizadas: Clases de vehículos.
o La primera: Vista para registrar, actualizar y eliminar Clases de
vehículos.
Figura 47 - Interfaz de administración de clases de vehículos (Elaboración propia)
g) Registro, actualización y eliminación de los VCC (vehículos, clases y

categorías) de los Vehículos: Este entregable contiene las siguientes
funcionalidades:
• Entidades utilizadas: Clases de vehículos.
o La primera: vista para registrar, actualizar y eliminar VCC de
vehículos.
72
Figura 48 - Interfaz de administración de VCC de vehículos (Elaboración propia)
3.5.4 Entregables del SPRINT 2:
a) Entregable de Registro, actualización y eliminación de los precios de los

vehículos y calendarios: Este entregable contiene las siguientes funcionalidades:
• Entidades utilizadas: Precios de vehículos
o La primera: Vista la tabla de precios de vehículos con
excepciones.
Figura 49 - Interfaz de administración de la tabla de precios (Elaboración propia)
73
b) Entregable de Registro, actualización y eliminación de Pólizas: Este
• Entidades utilizadas: Certificados de Pólizas
o La primera: Vista para registrar pólizas masivas.
Figura 50 - Interfaz de administración de pólizas masivas (Elaboración propia)
a) Entregable de Asignación, Re-asignación y eliminación de Certificados

SOAT: Este entregable contiene las siguientes funcionalidades
• Entidades utilizadas: Certificados de Pólizas
o La primera: Vista para asignar, reasignar y eliminar pólizas
74
Figura 51 - Interfaz de administración de re-asignaciones o eliminaciones de pólizas (Elaboración propia)
b) Entregable de Registro, actualización y eliminación de los precios de los

vehículos y calendarios: Este entregable contiene las siguientes funcionalidades:
• Entidades utilizadas: Precios de vehículos
o La primera: Vista la tabla de precios de vehículos con
excepciones.
Figura 52 - Interfaz de administración para anular ventas (Elaboración propia)
75
a) Entregable de Cotización de precios de Vehículos(Cotizador): Este entregable

contiene las siguientes funcionalidades:
• Entidades utilizadas: Cotizador
o La primera: vista para cotizar precios de aseguradoras por
vehículo
o La segunda: vista para ingresar datos del contratante
o La tercera: vista para imprimir el certificado de póliza SOAT
Figura 53 - Interfaz de Cotizador (Elaboración propia)
Figura 54 - Interfaz de ingresar los datos del contratante (Elaboración propia)
76
Figura 55 - Interfaz para imprimir los certificados SOAT o re-asignar otra póliza (Elaboración propia)
b) Entregable para Generar Reportes del Sistema: Este entregable contiene las
siguientes funcionalidades:
• Entidades utilizadas: Reportes
• Interfaces creadas: se desarrollaron una sola vista, donde se pueden
seleccionar diferentes tipos de reportes
o La primera: vista para generar los diferentes tipos de reportes en
formato Excel.
o La segunda: Reporte de ventas por compañía.
Figura 56 - Interfaz para generar reportes del sistema (Elaboración propia)
77
Figura 57 - Reporte de ventas por compañía (Elaboración propia)
3.6 Pruebas de Entregables
En esta sección se van a detallar las pruebas para las 4 SPRINT planificados para la
completar la implementación del sistema, en cada una se van a especificar, el escenario,
lo que “se espera” que el sistema responda, y lo “se obtuvo” que se refiere a la información
obtenida consecuente del software.
3.6.1 Pruebas del SPRINT 1:
3.6.1.1 Prueba registro, actualización y eliminación de usuarios:
ESCENARIO SE ESPERA SE OBTUVO

Ingresar datos del usuario Los datos se guardan Los datos ingresados si se
(nombres, e-mail, teléfono, correctamente, y se muestra guardaron, y el sistema
privilegio(rol) y el mensaje confirmando muestra el mensaje
oficina la acción realizada. confirmando la acción.
Tabla 29 - Pruebas de entregable registro, actualización y eliminación de usuario
3.6.1.2 Pruebas de entregables de Asegurados, oficinas, tipos de uso,
categorías, clases de vehículos y VCC:
78
Ingresar, actualizar y eliminar los Los datos se guardan, Los datos actualizados si
datos a las tablas de mantenimiento actualizan y eliminan se guardaron, y el sistema
de: Aseguradoras, Oficinas, Tipos correctamente, y se muestra el mensaje
de USO, Categorías, Clases de muestra el mensaje de confirmando la acción.
vehículos, VCC alerta
Tabla 30 - Pruebas de entregables de Asegurados, oficinas, tipos de uso, categorías, clases de vehículos y VCC
3.6.2.1 Pruebas de entregables de tablas y calendarios de Precios:

Ingresar, actualizar y eliminar los Los datos se guardan, Los datos actualizados si se
datos a las tablas de mantenimiento actualizan y eliminan guardaron, y el sistema
de: correctamente, y se muestra el mensaje
muestra el mensaje de confirmando la acción.
o Aseguradoras
alerta
o Oficinas
o Tipos de USO
o Categorías
o Clases de vehículos
Ingresar y eliminar los calendarios de Los datos se guardan y Los datos actualizados si se
precios de vehículos eliminan correctamente, guardaron, y el sistema
y se muestra el mensaje muestra el mensaje
de alerta confirmando la acción.
Tabla 31 - Pruebas de entregables de tablas y calendarios de Precios
3.6.3.1 Pruebas de entregables de inserción, actualización y eliminación de
Pólizas:

Ingresar, actualizar y eliminar Los datos se guardan, Los datos actualizados si se
Pólizas por: actualizan y eliminan guardaron, y el sistema
correctamente, y se muestra el mensaje
o Unidad
confirmando la acción.
79
o Masivamente muestra el mensaje de
alerta
Tabla 32 - Pruebas del sprint 3
3.6.3.2 Pruebas de entregables de Asignación, Re-Asignación y eliminación de
Pólizas:

Asigna y Re-Asigna Pólizas a Los datos se guardan, Los datos actualizados si se
usuarios tipo: Administrador, actualizan y eliminan guardaron, y el sistema
vendedor, Selecciona y correctamente, y se muestra muestra el mensaje
de-selecciona pólizas el mensaje de alerta. confirmando la acción.
Los datos se eliminan Los datos actualizados si se
Elimina Pólizas no vendidas. correctamente, y se muestra guardaron, y el sistema
el mensaje de alerta. muestra el mensaje
Tabla 33 - Pruebas de entregables de Asignación, Re-Asignación y eliminación de Pólizas
3.6.3.3 Pruebas de entregables de Revisión de estados:

Revisión de estados de Los datos buscan los estados las pólizas filtradas
pólizas: correctamente, y se muestra
el mensaje de alerta
o Ventas en proceso
o Ventas terminadas
o Ventas Anuladas
Anular pólizas Las pólizas se anularon Los datos actualizados si se

correctamente, y se muestra guardaron, y el sistema
el mensaje de alerta muestra el mensaje
Tabla 34 - Pruebas de entregables de Revisión de estados
80
3.6.4.1 Pruebas de entregables del Cotizador:

Cotizar los precios de Los filtros buscan los precios Los precios de las pólizas
pólizas de las correctamente, y se muestran de las aseguradoras
Asegurados: mensajes con los precios
Insertar datos del Las pólizas se anularon Los datos actualizados si
vehículo y selección de correctamente, y se muestra se guardaron, y el sistema
numero de póliza el mensaje de alerta muestra el mensaje
Insertar datos del Las pólizas se Actualizan Los datos actualizados si
Contratante correctamente, y se muestra se guardaron, y el sistema
el mensaje de siguiente muestra el mensaje
Insertar datos de inicio de Los datos se Actualizan Los datos actualizados si
póliza correctamente, y se muestra se guardaron, y el sistema
el mensaje de siguiente muestra el mensaje
Impresión de póliza Las pólizas se imprimen Los datos actualizados si
correctamente, y se muestra se guardaron,
el mensaje de finalizar y el sistema muestra el
mensaje confirmando la
acción.
Re-asignación de póliza Las pólizas se re-asignan Los datos actualizados si
correctamente, y se muestra se guardaron,
el mensaje de finalizar y el sistema muestra el
mensaje confirmando la
acción.
Tabla 35 - Pruebas de entregables del Cotizador
81
3.6.4.2 Pruebas de entregables de Reportes:

Genera Reportes de: los reportes se generan Los reportes se generaron y
ventas diarias por correctamente y exporta un se obtuvo documentos en
usuario documento en formato formato EXCEL
Producción de puntos de EXCEL
venta
ventas por Aseguradora
Tabla 36 - Pruebas de entregables de Reportes
3.7 Análisis de datos
El Análisis de información está cambiando la forma de operar de las organizaciones

actuales, dado que al interpretar los datos almacenados podemos realizar diferentes tipos
de métodos estadísticos para obtener información para la inteligencia del negocio, por
este motivo, se propone en esta sección, analizar la información del sistema con fines de
investigación, para conocer las tendencias futuras de las ventas usando el sistema que
pueden ser de utilidad para la empresa, para mejorar la toma de decisiones.
Dado a que el sistema propuesto se encuentra en funcionamiento desde febrero del 2018,
solo se podrá evaluar, la información recolectada hasta marzo del 2019, por motivos de
seguridad y dado que es solo se quiere demostrar de manera experimental el análisis, se
utilizara solo la información de una sola oficina, para este análisis, se recurrirá a las
pruebas de predicción, pero dado a no contar con numerosa información, los resultados
no lograrán contar con una alta precisión, más bien representaran una tendencia en la
información. Para este análisis se determinó utilizar el método estadístico ARIMA, que
es el modelo de series temporales más popular en la comunidad científica de datos
(gizmodo, 2019), e incluso es utilizada para comparar sus resultados con técnicas de
inteligencia artificial (IA) y aprendizaje profundo de maquina (DEEP LEARNING), las
tecnologías que se utilizaron para este análisis fueron PYTHON junto con su librería de
procesamiento de data y series temporales PANDAS para el análisis de datos.
82
3.7.1 ARIMA
El modelo “auto-regresivo integrado de promedio móvil o ARIMA” es un método de

estadística que con el objetivo de reconocer patrones frecuentes para predecir lo que va a
pasar, usa regresiones y variaciones, este se presenta como un método dinámico que
trabaja con series de tiempo, es decir, la estimación será basada en los datos anteriores(del
pasado) y no por variables independientes, para esto se requiere reconocer los coeficientes
y el número de regresiones que se necesitaran, por eso se expone sensible a la precisión
con que se detallen sus coeficientes, en la siguiente formula se aprecia el cálculo de la
auto-regresión (Brockwell, 2002).
𝑝 𝑝
𝑌𝑡 = −( 𝛿 𝑑 𝑌𝑡 − 𝑌𝑡 + ∅0 + ∑ ∅0 𝛿 𝑑 𝑌𝑡−𝑖 − ∑ ∅𝑖 ∈ 𝑡−𝑖 + ∈𝑡
𝑖=1 𝑖=1
donde la variable “d” pertenece a las “d diferencias” que son requeridas para transformar
la serie original en una serie estacionaria, 𝜑0 y , 𝜑𝑝 que presenta el modelo de la parte
“auto-regresiva” son parámetros y , θ1 , θ𝑞 pertenecen a la de parte "medias móviles" del
modelo, δ0 es una constante, y S𝑡 es la innovación, perturbación o el termino de error
(Brockwell, 2002).
83
3.7.2 Tendencias de ventas
Para la presentación de los análisis de datos se desarrolló una plataforma WEB, que recibe
la información del servidor por medio de un servicio en formato CSV, y donde se ejecuta
un SCRIPT en PYTHON de la técnica estadística ARIMA que procesa la información,
Figura 58 - Pagina web para tendencias de ventas (Elaboración propia)
dada la necesaria información para comparación de este trabajo, se añadieron cuadros

comparativos y análisis de predicción de la información del anterior sistema.
3.7.3 Predicción Mensual
Para le proceso de predicción con el método ARIMA se tiene que observar, primero
observaremos una a comparación con la información real, ósea se separara la información
que se tiene del año 2018 y 2019, una porción como datos de entrenamientos y otra
pequeña porción como datos de prueba, de esta manera podremos comparar su eficiencia
según la cercanía que obtenga con los datos de entrenamiento, luego se utilizará en
totalidad la información para poder predecir un año. La segunda prueba consistirá en
hacer lo mismo, pero con la información del total de ventas del año 2017 logradas por el
anterior sistema que utilizaba la empresa, para determinar cómo les hubiese ido el año
2018 y 2019, y por último una comparación entre ambas predicciones para ver la
84
tendencia con el uso del nuevo sistema y la tendencia de como hubiese sido si seguían
utilizando con el anterior sistema
Análisis de las ventas mensuales con el nuevo sistema: se tomaron en cuenta el total
de ventas mensuales de marzo del 2018, cuando se inició el uso del sistema hasta julio
2019, como se observa en la figura 3.56. una porción es de entrenamiento y a partir de
marzo 2019 hasta julio es la data de prueba, y esta es la tabla y gráficas de la predicción
con toda la información hasta julio de 2020.
Datos de ventas del 2018-2019
Datos de Prueba Datos ARIMA
2019-03-01 1225 2019-03-01 732.779821
2019-04-01 1043 2019-04-01 725.563247
2019-05-01 942 2019-05-01 784.552282
2019-06-01 882 2019-06-01 895.181995
2019-07-01 1122 2019-07-01 997.829561

Tabla 37 - Comparación de datos Reales y prueba del sistema propuesto
Figura 59 - Data de entrenamiento y Predicción de ventas hasta julio 2020 del sistema propuesto (Elaboración
propia)
85
Predicción de ventas para el sistema propuesto 2020
2019-09-01 1586.782803 2020-03-01 2009.72639

6
2019-10-01 1770.865411 2020-04-01 2064.19473

7
2019-11-01 2039.352294 2020-05-01 2173.03666

0
2019-12-01 2004.601425 2020-06-01 2352.52173

3
2020-01-01 1759.459201 2020-07-01 2560.72815

7
2020-02-01 2013.407716 2020-08-01 2544.31254

5
Tabla 38 - Predicción del sistema propuesto
Para determinar el grado de precisión del análisis estadístico se tuvo que determinar el
valor cuadrático medio o RMS (Brockwell, 2002), que es una formula, para hallar de “una
cantidad variable” la “medida estadística de la magnitud”, esta puede ser calculada para
obtener valores de carácter discreto o para una “variable continua”, su
denominación(nombre) es basado de la situación en la de que es “la raíz cuadrad de la
media aritmética de los cuadrados de los valores”, se puede calcular con la siguiente
formula:
𝑥12 + 𝑥22 ⋯ 𝑥𝑁2 ∑𝑁 𝑥 2

𝑅𝑀𝑆 = √ = √ 𝑖=1 𝑖
𝑁 𝑁
La media cuadrática (RMS) tiene una relación interesante con la media (𝑥̅ 2 ) y la población
desviación estándar (𝑠𝑖𝑔𝑚𝑎2 ), como en la siguiente formula, obteniendo como resultado
en la primera prueba, probando la data de entrenamiento y la data real se obtuvo un
0.4041900907758552 que podría representar un 40% de precisión, esta cifra se puede
entender como a cuanto se aproximan los datos predichos con los datos reales, mostrando
que hay cierta distancia entre los valores, dado a que solo se cuenta con un año de
información, siendo la técnica estadística ARIMA, una técnica muy utilizada y eficiente,
se puede deducir que a mayor información se conseguirá un mayor grado de
aproximación.
𝑅𝑀𝑆 2 = 𝑥̅ 2 + 𝜎 2
86
import numpy as np,
import pandas as pd,
import statsmodels.api as sm,
df = pd.read_csv(¨csv/data.csv"), train=df(0:26),
test=df(26:),
df(’Timestamp’) = pd.to_datetime(df.Fecha,format=’ %Y- %m- %d’) , df.index =
df.Timestamp,
train(’Timestamp’) = pd.to_datetime(train.Fecha,format=’ %Y- %m- %d’) ,
train.index = train.Timestamp ,
test(’Timestamp’) = pd.to_datetime(test.Fecha,format=’ %Y- %m- %d’) , test.index =
test.Timestamp ,
train.nuevo_sistema.plot(figsize=(15,8), title= ’Sistema Propuesto’, fontsize=14),
test.nuevo_sistema.plot(figsize=(15,8), title= ’Sistema Propuesto’, fontsize=14),
y_hat_avg = test.copy(),
fit1 = sm.tsa.statespace.SARIMAX(train.nuevo_sistema, order=(2,1,2),
seasonal_order=(0,1,1,1)).ftt(),
y_hat_avg(’ARIMA’) = ftt1.predict(start="2019-03-01", end="2019-08-01",
dynamic=True),
plt.ftgure(figsize=(16,8)),
plt.plot( train(’nuevo_sistema’), label=’Data Real’), plt.plot(test(’nuevo_sistema’),
label=’Data de Prueba’), plt.plot(y_hat_avg(’ARIMA’), label=’ARIMA’),
plt.legend(loc=’best’),
rms = sqrt(mean_squared_error(test.nuevo_sistema, y_hat_avg.ARIMA)),
Algoritmo 1 - Proceso de análisis de datos y extracción de tasa de precisión
87
Análisis de las ventas mensuales del anterior sistema: se tomaron en cuenta el total de
ventas mensuales del año 2017, y se logró predecir su comportamiento al año 2018, para
ver como hubiese seguido la tendencia de ventas.
Predicción de ventas para el sistema anterior 2018-19
2018-02-01 501.785642 2018-09-01 495.777374
2018-03-01 424.740767 2018-10-01 524.816227
2018-04-01 409.982095 2018-11-01 580.213318
2018-05-01 524.735812 2018-12-01 541.615759
2018-06-01 553.448445 2019-01-01 539.145384
2018-07-01 541.832853
Tabla 39 - Predicción del sistema anterior 2018-19
Figura 60 - Predicción de ventas del año 2018 para el anterior sistema (Elaboración propia)
Comparación de ventas del sistema anterior con el sistema propuesto: en este

apartado, se comparan los resultados que tuvieron en predicción para el anterior sistema
y el nuevo sistema.
88
Figura 61 - Tabla de datos extraídos para comparación (Elaboración propia)
Figura 62 - Comparación de ventas del sistema anterior con el sistema propuesto (Elaboración propia)
3.7.4 Predicción Diaria
Para este análisis se tomó en cuenta el total de ventas diarias desde el 09 de febrero del
año 2018, hasta el 16 de marzo del año 2019, para poder observar cual hubiese sido su
comportamiento en el siguiente mes.
Predicción de ventas por día
Sistema Propuesto Predicción ARIMA
2019-02-18 44.0 2019-03-17 30.260295
2019-02-19 58.0 2019-03-18 39.491846
2019-02-20 44.0 2019-03-19 29.880834
89
2019-02-21 36.0 2019-03-20 34.554548
2019-02-22 33.0 2019-03-21 39.337359
2019-02-23 49.0 2019-03-22 31.842192
2019-02-24 41.0 2019-03-23 25.933604
2019-02-25 29.0 2019-03-24 28.262440
2019-02-26 43.0 2019-03-25 28.565810

Tabla 40 - Predicción del sistema anterior 2018-19
Figura 63 - Predicción del 17 de marzo al 17 de abril del 2019 del sistema propuest. (Elaboración propia)
Todos estos análisis de datos fueron desarrollados con el fin de aportar valor a la
validación de la mejora del sistema propuesto, pudiendo ser posibles funcionalidades que
se podrían agregar al sistema, para que este pueda brindar información importante para la
toma de decisiones a partir de la misma información generada por el sistema, Cabe
resaltar que los resultados mejoraran con más cantidad de información ósea más tiempo
de uso del sistema.
90
4. CAPITULO 4: VALIDACIÓN
4.1 Evaluación del Sistema
En el desarrollo de este capítulo se expondrá la evaluación del sistema de gestión de

escritorio que utilizaban y el nuevo sistema mejorado que apunta a dar respuestas de las
preguntas establecidas en el primer capítulo, mediante el uso de la herramienta de
estadística basada en evaluaciones en escala de LIKERT (Elejabarrieta, 2010), se
observan los datos exactos obtenidos luego de la utilización de un mismo cuestionario
que será aplicado primero en el PRE-TEST, según las experiencia de aceptación de los
usuarios con el primer sistema y el POST-TEST. que es la experiencia de aceptación con
el nuevo sistema, aplicada a la misma población seleccionada, que en este caso son 6
empleados de la empresa que han hecho uso del sistema de gestión en su labor diaria por
varios años, y que además han participado en la construcción de las historias para el
desarrollo del nuevo sistema como PRODUCT OWNER y STAKEHOLDERS, además
de haber sido capacitados para su uso.
En la primera etapa: se utilizó el cuestionario (PRE-TEST), para determinar la situación

problemática antes de proponer el desarrollo del sistema de gestión WEB.
En la segunda etapa: se empleó nuevamente el cuestionario (POST-TEST), a la misma

población luego del desarrollo, del nuevo sistema de gestión WEB para determinar en
qué medida la plataforma desarrollada mejoro su trabajo, según conceptos de la utilidad,
eficacia y velocidad de su trabajo para validar los aportes.
Todas estos fueron organizados bajo criterios contemplados en el estándar ISO/IEC

25000 SQUARE utilizado para certificar un producto de software desde el 2014, el cual
organiza en detalle los requisitos necesarios de calidad del software y evaluación de la
aceptación del software (Rodríguez and Piattini, 2015), con la finalidad de reflejar la
correcta evaluación del trabajo para el desarrollo del sistema de gestión, luego se realizó
la comprobación de la hipótesis, por medio de la prueba T-STUDENT para muestras
relacionadas dado a que nuestras pruebas son dependientes y para mostrar las mejoras en
los criterios establecidos de calidad de software.
91
Tabla de Preguntas de las encuestas PRE-TEST
y POST-TEST
Criterios ID Pregunta
P1. ¿Hace uso del sistema para administrar la empresa?
USABILIDAD
P2. ¿Le es fácil acceder a las opciones del sistema?
P3. ¿Encuentra la información necesaria para la gestión de la empresa en el sistema?
DISPONIBILIDAD
P4. ¿Se encuentra disponible la información para administrar la empresa en todo
momento?
P5. ¿En el sistema encuentras las opciones necesarias para administrar la empresa?
P6. ¿Configurar las opciones del sistema es tedioso?
INTERACCIÓN
P7. ¿Es fácil usar el sistema?
ADAPTABILIDAD P8. ¿El sistema se adapta a cualquier dispositivo y lugar en el que es utilizada?
ESTABILIDAD P9. ¿El sistema se encuentra disponible en todo momento?

P10. ¿Utiliza los reportes que le ofrece el, sistema?
EFECTIVIDAD:
DE LA P11. ¿Los reportes del sistema cubren sus, expectativas para administrar el negocio?
P12. ¿El sistema se encuentra distribuido por, privilegios?

INFORMACIÓN
P13. ¿Considera usted que privilegios del sistema se encuentran correctamente
DEL SISTEMA
asignados?
P14. ¿Considera usted que en el sistema se puede ingresar toda la información necesaria
para administrar el negocio?
EFICACIA:
P15. ¿Considera usted que en el sistema debería observar en que estados se encuentran
CALIDAD DE LA las ventas?
INFORMACIÓN
DEL SISTEMA
EFICACIA: 16. ¿Considera, necesario que a través del sistema se deban ingresar los precios de los,
FUNCIONALIDAD seguros?
P17. ¿Considera, que el uso del sistema acelera su trabajo?

Tabla 41 - Tabla de Preguntas de las encuestas PRE-TEST y POST-TEST
4.1.1 Resultados de la evaluación (PRE-TEST)
En la primera etapa se aplicó el cuestionario PRE-TEST a 6 empleados de la empresa, la

problemática existente en la administración de su sistema de gestión. Las preguntas del
cuestionario han sido agrupadas según cada indicador. A continuación, se detallan los
resultados del cuestionario PRE-TEST realizado en cuadros y gráficos estadísticos a
modo de resumen por cada pregunta. Posteriormente se realizará el tratamiento de datos
y análisis estadístico a través de la Prueba T-STUDENT.
92
4.1.1.1 USABILIDAD
P1. ¿Hace uso del sistema para administrar la

empresa?
Respuest Cantida Porcenta
a d je
Siempre 3 50 %
Casi 1 16.67 %
Siempre
A veces 1 16.67 %
Casi Nunca 1 16.67 %
Nunca 0 0%
TOTAL: 6 100 %
Tabla 42 - Tabla de la Pregunta P1 del PRE-TEST
P2. ¿Le es fácil acceder a las opciones del

sistema?
Respuest Cantid Porcent
a ad aje
Siempre 0 0%
Casi 1 16,67 %
Siempre
A veces 2 33,33 %
Casi 3 50 %
Nunca
Nunca 0 0%
TOTAL: 6 100 %
4.1.1.2 DISPONIBILIDAD
P3. ¿Encuentra la información necesaria para la gestión

de la empresa
en el sistema?
Respuesta Cantida Porcentaj
d e
Siempre 0 0%
Casi Siempre 0 0%
A veces 2 33,33 %
Casi Nunca 2 33,33 %
Nunca 2 33,33 %
TOTAL: 6 100 %
P4.- ¿Se encuentra disponible la información para administrar la empresa en todo

momento?
93
P4.- ¿Se encuentra disponible la información para
administrar la
empresa en todo momento?
Respuesta Cantida Porcenta
d je
Siempre 0 0%
Casi 0 0%
Siempre
A veces 1 16,67 %
Nunca 0 0%
TOTAL: 6 100 %
P5.- ¿En el sistema encuentras las opciones necesarias para administrar la empresa?
P5.- ¿En el sistema encuentras las opciones necesarias

para administrar
la empresa?
d je
Siempre 0 0%
Casi 1 16,67
Siempre %
A veces 4 66,67 %
Nunca 0 0%
TOTAL: 6 100 %
4.1.1.3 INTERACCIÓN
P6.- ¿Configurar las opciones del sistema es tedioso?

Cantidad Porcentaje
Respuesta
Siempre 5 83,34 %
Casi Siempre 1 16,67 %
0 0%
A veces
0 0%
Casi Nunca
0 0%
Nunca
6 100 %
TOTAL:
94
P7.- ¿Es fácil usar el sistema?
P7.-¿Es fácil usar el sistema?

d e
Siempre 0 0%
A veces 2 33,33 %
Nunca 0 0%
TOTAL: 6 100 %
4.1.1.4 ADAPTABILIDAD
P8.- ¿El sistema se adapta a cualquier dispositivo y lugar en el que es utilizada?
P8.- ¿El sistema se adapta a cualquier dispositivo y lugar

en el que es
utilizada?
d e
Siempre 0 0 %
Casi Siempre 0 0%
A veces 0 0%
Casi Nunca 0 0%
Nunca 6 100 %
TOTAL: 6 100 %
4.1.1.5 ESTABILIDAD
P9.- ¿El sistema se encuentra disponible en todo momento?
P9.-,¿El sistema se encuentra disponible en todo momento?
Respuesta Cantidad Porcentaje
Siempre 0 0%
Casi Siempre 3 50 %
A veces 3 50 %
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
Tabla 50 - Tabla de la Pregunta P9 del POST-TEST
4.1.1.6 EFECTIVIDAD: DE LA INFORMACIÓN DEL SISTEMA
P10.- ¿Utiliza los reportes que le ofrece el sistema?
95
Siempre 0 0%
Casi Siempre 0 0%
A veces 3 50 %
Nunca 1 16,67 %
TOTAL: 6 100 %
P11.- ¿Los reportes del sistema cubren sus expectativas para administrar el negocio?
P11.- ¿Los reportes del sistema cubren sus expectativas para administrar
el negocio?

0 0%
Siempre
0 0%
Casi Siempre
0 0%
A veces
1 16,67 %
Casi Nunca
5 83,34 %
Nunca
6 100 %
TOTAL:
P12.- ¿El sistema se encuentra distribuido por privilegios?
Siempre 0 0%
Casi Siempre 0 0%
A veces 0 0%
Casi Nunca 0 0%
Nunca 6 100 %
TOTAL: 6 100 %
96
P13.- ¿Considera usted que privilegios del sistema se encuentran correctamente
asignados?
P13.-¿Considera usted que privilegios del sistema se

encuentran
correctamente asignados?
d je
Siempre 0 0%
Casi 0 0%
Siempre
A veces 0 0%
Casi Nunca 0 0%
Nunca 6 100 %
TOTAL: 6 100 %
P14.- ¿Considera usted que en el sistema se puede ingresar toda la información necesaria
P14.- ¿Considera usted que en el sistema se puede
ingresar toda
la información necesaria para administrar el negocio?
d je
Siempre 0 0 %
Casi 0 0%
Siempre
A veces 2 33,33 %
Casi Nunca 3 50 %
Nunca 1 16,67 %
TOTAL: 6 100 %
4.1.1.7 EFICACIA: CALIDAD DE LA INFORMACIÓN DEL SISTEMA
P15.- ¿Considera usted que en el sistema debería observar en que estados se encuentran
las ventas?
P15.- ¿Considera usted que en el sistema debería observar en que

estados se encuentran las ventas?
Siempre 0 0%
Casi Siempre 0 0%
A veces 3 50 %
Nunca 1 16,67 %
TOTAL: 6 100 %
97
4.1.1.8 EFICACIA: FUNCIONALIDAD
P16.- ¿El sistema contempla el ingreso de los precios de los seguros para una cotización
automatizada?
P16.- ¿El sistema contempla el ingreso de los precios de los seguros

para una cotización automatizada?
Cantidad Porcentaje
Respuesta
Siempre 0 0%
Casi Siempre 0 0%
A veces 0 0%
Nunca 5 83,34 %
TOTAL: 6 100 %
P17.- ¿Considera que el uso del sistema acelera su trabajo?
P17.-¿Considera que el uso del sistema acelera su trabajo?
Siempre 0 0%
Casi Siempre 0 0%
A veces 3 50 %
Nunca 1 16,67 %
TOTAL: 6 100 %
4.1.2 Resultados de la evaluación (POST-TEST)
En la primera etapa se aplicó el cuestionario (POST-TEST) a 6 empleados de la empresa,

para obtener de esta manera la apreciación de cada uno sobre la mejora existente en el
uso de su sistema de gestión. Las preguntas del cuestionario han sido agrupadas según
cada indicador, y se presentan los resultados de la segunda etapa de la aplicación del
cuestionario (POST-TEST) a los empleados que realizan su trabajo con el sistema en
cuadros y gráficos estadísticos a modo de resumen por cada pregunta, posteriormente se
realizará el tratamiento de datos y análisis estadístico a través de la Prueba T-STUDENT.
98
4.1.2.1 USABILIDAD
P1. ¿Hace uso del sistema para administrar la

empresa?
d e
Siempre 4 66,67 %
Casi 2 33,33 %
Siempre
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %

d e
Siempre 5 83,34 %
Casi 1 33,33 %
Siempre
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
4.1.2.2 DISPONIBILIDAD
P3. ¿Encuentra la información necesaria para la gestión

de la
empresa en el sistema?
d e
Siempre 4 66,67 %
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
P4.- ¿Se encuentra disponible la información para administrar la empresa en todo

momento?
99
P4.- ¿Se encuentra disponible la información para
administrar
la empresa en todo momento?
d je
Siempre 2 33,33 %
Casi 4 66,67 %
Siempre
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
Tabla 62 -Tabla de la Pregunta P4 del POST-TEST
P5.- ¿En el sistema encuentras las opciones necesarias para administrar la empresa?
P5.- ¿En el sistema encuentras las opciones necesarias

para
administrar la empresa?
d e
Siempre 2 33,33 %
Casi Siempre 3 50 %
A veces 1 16,67 %
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
4.1.2.3 INTERACCIÓN

d e
Siempre 2 33,33 %
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
Siempre 1 29 %
Casi Siempre 5 71 %
A veces 0 0%
100
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
4.1.2.4 ADAPTABILIDAD
P8.- ¿El sistema se adapta a cualquier dispositivo y lugar en el que es utilizada?
P8.- ¿El sistema se adapta a cualquier dispositivo y lugar

en el que es utilizada?

d e
Siempre 6 100 %
Casi Siempre 0 0%
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
4.1.2.5 ESTABILIDAD
P9.- ¿El sistema se encuentra disponible en todo momento?
P9.-,¿El sistema se encuentra disponible en todo

momento?
Respuesta Cantida Porcentaje
d
Siempre 5 83,34 %
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
4.1.2.6 EFECTIVIDAD: DE LA INFORMACIÓN DEL SISTEMA
101
Siempre 6 100 %
Casi Siempre 0 0%
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
P11.- ¿Los reportes del sistema cubren sus expectativas para administrar el negocio?
P11.- ¿Los reportes del sistema cubren sus expectativas para

administrar el negocio?
Siempre 6 100 %
Casi Siempre 0 0%
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %

Siempre 6 100 %
Casi Siempre 0 0%
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
102
P13.- ¿Considera usted que privilegios del sistema se encuentran correctamente asignados?
P13.-¿Considera usted que privilegios del sistema se encuentran

correctamente asignados?
Siempre 5 83,34 %
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
P14.- ¿Considera usted que en el sistema se puede ingresar toda la información necesaria
P14.- ¿Considera usted que en el sistema se puede ingresar toda

la información necesaria para administrar el negocio?
Siempre 5 83,34 %
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
4.1.2.7 EFICACIA: CALIDAD DE LA INFORMACIÓN DEL SISTEMA
P15.- ¿Considera usted que en el sistema debería observar en que estados se encuentran
las ventas?
P15.- ¿Considera usted que en el sistema debería observar en que

estados se encuentran las ventas?
Siempre 4 66,67 %
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
103
P16.- ¿El sistema contempla el ingreso de los precios de los seguros para una
cotización automatizada?
P16.- ¿El sistema contempla el ingreso de los precios de los seguros

para una cotización automatizada?
Cantidad Porcentaje
Respuesta
Siempre 6 100 %
Casi Siempre 0 0%
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
Siempre 6 100 %
Casi Siempre 0 0%
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
4.1.3 Comparación de los resultados
En esta sección se presentarán la comparación de todas las respuestas brindadas en las

encuestas:
Comparación de resultados de la P1: En este

gráfico se observa un crecimiento de la
población en el uso nuevo sistema WEB para
realizar su trabajo de administración de la
empresa.
Tabla 76 - Comparación de la Pregunta(P1)

104
Comparación de resultados de la P2: En
este gráfico se observa un crecimiento de la
población que en su mayoría les parece más
fácil de acceder a las opciones en nuevo
sistema a comparación del anterior sistema.

este gráfico se observa un crecimiento de la
población en la afirman que con el nuevo
sistema encuentran en su mayoría siempre
encuentran toda la información necesaria
para gestionar y administrar la empresa.

este gráfico se observa en el pasado les era
muy complicada encontrar la información
necesaria para administrar el negocio, ya que
esta no estaba disponible en todo momento,
lo que, en comparación con el nuevo sistema,
la información de gestión se encuentra en el
sistema.
105
este gráfico se pueda observar que mantenían
problemas con el anterior sistema dado a qué
no contaba con las suficientes opciones
necesarias para administrar la empresa, lo
que demuestra que con el nuevo sistema
cuenta con la mayoría de opciones necesarias
para gestionar la empresa.

este gráfico se pueda observar que en el
anterior sistema que en su mayoría era
siempre tedioso de configurar las opciones
del sistema que, aunque haya bajado a casi
siempre en el nuevo sistema, este proceso
tedioso, es necesario configurar las opciones
con toda la información que requiera, para
contar con un correcto funcionamiento del
sistema.

este gráfico se pueda observar ha mejorado
considerablemente la facilidad de uso del
sistema a comparación con el anterior
sistema.
106
Comparación de resultados de la P8: en la
siguiente figura se expone sistema solo podía
utilizarse en un tipo de dispositivo que era
una computadora de escritorio, siendo para
esto el nuevo sistema una gran solución, que
permite trabajar sobre el sistema en diversos
dispositivos, es por eso que el cuadro
muestra un contraste de 0 a 6.

este gráfico podemos observar que ha mejorado
también la percepción de disponibilidad sobre
la herramienta, que paso de no estar siempre
disponible a estar disponible en todo
momento.
Comparación de resultados de la P10:

Durante las entrevistas con los encargados
del anterior del sistema, su principal
preocupación era la generación de reportes,
dado a que los reportes que conseguían no
expresaban la realidad de la empresa, por lo
que se puso principal importancia en su
desarrollo, y los resultados de las encuentran
de satisfacción en la generación de reportes,
más precisos y completos, y sobretodo
siempre disponible
107
Comparación de resultados de la P11: La
pregunta P11 se centra en asegurarnos de que
los reportes que se cubran las expectativas de
los usuarios, obtienen un alto puntaje, dado
que los entrevistados indicaron que siempre
estos reportes eran de gran utilidad.
Comparación de resultados de la P12: La

pregunta P12 presenta otro contraste, dado a
que el anterior sistema no contaba con control
de privilegios.

este gráfico podemos observar que las
asignaciones de privilegios son acordes al
trabajo que presenta la empresa, y que serán
de utilidad dado a que mantienen control
sobre la labor de sus usuarios.

este gráfico podemos observar que el sistema
presenta considerables mejoras, donde
pueden ingresar y almacenar toda la
información que necesitan para administrar
su modelo de negocio, esto incluye un mejor
control de sus ventas, ya que se puede
ingresar tablas de precios, actualizarlos.
108
este gráfico podemos observar que el sistema
anterior no contaba con búsquedas ni estados
de sus ventas, por lo que solo podían observar
de reportes de seguros vendidos, con el nuevo
sistema que presenta diversas maneras de ver
el estado en el que se encuentran las ventas,
se puede tener una herramienta de ayuda para
las tomas de decisiones dado a que estos
estados nos permiten conocer los motivos por
la que las ventas no se concretan.

este gráfico podemos observar la principal
mejora del sistema, que contempla la
atomización del proceso de ventas, para
evitar, buscar los precios para los clientes, de
manera física, lo que muestra otro contraste
que agiliza el proceso de gestión de ventas
del sistema.

este gráfico podemos observar, la respuesta a
nuestro objetivo principal, si el nuevo sistema
agiliza el proceso de gestión de la empresa,
bajo la pregunta si considera que el sistema
acelera su trabajo, obteniendo una
contundente respuesta a comparación al
anterior sistema, por lo que se observar tal
contraste en los datos.
109
4.2 Resultados
Con el objetivo de comprobar las mejoras establecidas en el presente trabajo se empleó

la prueba Estadística “T-STUDENT” , el cual es un paradigma que tiene la posibilidad de
validad si se va a aceptar o rechazar una afirmación, por lo que se denominan los
supuestos o “hipótesis estadísticas” realizados a un valor de significancia, al realizarse
esta procedimiento en comparaciones relacionadas, en nuestros caso dos cuestionarios
denominados “PRE-TEST y POST-TEST”, se utilizó la herramienta de software “ IBM
SPSS STADISTICS " que es una herramienta estadística muy utilizada para comprobar
este tipo de pruebas, por lo que la significancia va a representar el límite máximo del error
según la distancia para los resultados obtenidos con referencia al grado de aceptación que
se ha seleccionado que es α = 0.05 que afirma que las respuestas son de carácter confiable
dado que la probabilidad del error es baja, siendo todo este proceso un instrumento muy
utilizado y fiable para validar resultados en este tipo de investigaciones.
Los resultados serán organizados según los criterios establecidos para “evaluar la calidad
de un producto o implementación de software” contemplados en el estándar ISO/IEC
25000 SQUARE (Rodríguez and Piattini, 2015), con la finalidad de resaltar las mejoras
del sistema en las diversas necesidades que se requiere en un producto de estas
características. la prueba Estadística “T-STUDENT para muestras relacionadas”, se usa
cuando “las muestras son dependientes”, ósea, cuando se ha experimentado con una
“única muestra” que ha conseguido ser utilizada dos veces (PRE-TEST y POST-TEST),
o cuando han las dos fueron pareadas, por lo que planteara las hipótesis nula y alternativa.
Una prueba o evaluación de hipótesis, normalmente usa datos de las muestras, y estas van
a indicar si es posible rechazar la “hipótesis nula”, que pretende demostrar que la media
de la prueba es igual a la segunda por lo tanto no se ha presentado ni un incremento o
decremento en su probabilidad, y se plantea con la siguiente ecuación:
𝑥𝐷 − 𝜇𝜃
̅̅̅
𝑡=
𝑆𝐷 /√𝑛
Donde “la diferencia de D entre todos los pares tiene que ser calculada”, se entiende que
“los pares” son los resultados de uno de los participantes(persona) evaluada con el “PRE
y POST TEST de significancia”, que “la media (𝑥𝐷 )” y “la desviación estándar (𝑆𝑑 )” han
sido parte de la ecuación, y siendo contrario a cero(0) la constante (µ𝑑 ) demostrando que
110
“la diferencia es significativamente diferente de (µ0 )”. Los “grados de libertad” usados
son n − 1.
• Hipótesis nula (𝑯𝟎 ): expone que el “valor obtenido” de la muestra de la

población responde a un “valor hipotético” y se puede entender que es una
“afirmación inicia” que se fundamenta en los resultados anteriores.
• Hipótesis Alternativa (𝑯𝟏 ): da a entender que el valor obtenido de la muestra de
la población es “menor, más abultado o diferente” del la “hipótesis nula”, lo que
se da a entender que es “verdadero o espera probar que es verdadero”.
El criterio para decidir será el siguiente:

• Si la probabilidad obtenida P(Significancia)≤ α, se rechaza 𝑯𝟎 y se acepta 𝑯𝟏
• Si la probabilidad obtenida P(Significancia)> α, NO se rechaza 𝑯𝟎 y se acepta 𝑯𝟎
Por lo que en los siguientes cuadros se mostrara la conclusión de los resultados
USABILIDAD
Figura 64 -Diferencia de medias de USABILIDAD (Elaboración propia)
Figura 65 - Resultado de significancia de USABILIDAD (Elaboración propia)
Decisión estadística
P(Sig.)= 0.016 < α = 0.05
111
Conclusión: Existe una diferencia notable en las medias de las respuestas del antes y
después del sistema, por lo que se concluye que la USABILIDAD en el nuevo sistema si
ha tenido mejoras significativas sobre la USABILIDAD del anterior sistema, y por lo
tanto se rechaza 𝑯𝟎 , de hecho, el promedio del nuevo sistema 9.5 es superior al
promedio del anterior 6.67.
DISPONIBILIDAD
Figura 67 - Diferencia de medias de DISPONIBILIDAD (Elaboración propia)
Figura 66 - Resultado de significancia de DISPONIBILIDAD (Elaboración propia)
P(Sig.)= 0.000 < α = 0.05
Conclusión: Existe una diferencia notable en las medias de las respuestas del
antes y después del sistema. Por lo que se concluye que la DISPONIBILIDAD en
el nuevo sistema si ha tenido mejoras significativas sobre la DISPONIBILIDAD
del anterior sistema, y por lo tanto se rechaza 𝑯𝟎 , de hecho, el promedio del
nuevo sistema 13.1667 no es muy superior al promedio del anterior 7.17
112
INTERACCIÓN
Figura 68 - Diferencia de medias de INTERACCIÓN (Elaboración propia)
Figura 69 - Resultado de significancia de INTERACCIÓN (Elaboración propia)
P(Sig.)= 0.102 < α = 0.05
Conclusión: No se obtuvo un resultado que demuestre que exista una diferencia notable
en las medias de las respuestas del antes y después del sistema. Por lo que se concluye
que la INTERACCIÓN en el nuevo sistema no ha tenido mejoras significativas sobre la
INTERACCIÓN del anterior sistema, y por lo tanto se rechaza 𝑯𝟎 , de hecho, el
promedio del nuevo sistema 8.5 no es superior al promedio del anterior 7.83
ADAPTABILIDAD
Figura 70 - Diferencia de medias de ADAPTABILIDAD (Elaboración propia)
113
Figura 71 - Resultado de significancia de ADAPTABILIDAD (Elaboración propia)
P(Sig.)= 0.000 < α = 0.05
después del sistema. Por lo que se concluye que la ADAPTABILIDAD en el nuevo
sistema si ha tenido mejoras significativas sobre la ADAPTABILIDAD del anterior
sistema, y por lo tanto se rechaza 𝑯𝟎 , de hecho, el promedio del nuevo sistema 5 es
muy superior al promedio del anterior 1.17.
Para ESTABILIDAD
Figura 72 - Diferencia de medias de ESTABILIDAD (Elaboración propia)
Figura 73 - Resultado de significancia de ESTABILIDAD (Elaboración propia)
114
P(Sig.)= 0.010 < α = 0.05
después del sistema. Por lo que se concluye que la ESTABILIDAD en el nuevo sistema
si ha tenido mejoras significativas sobre la ESTABILIDAD del anterior sistema, y por
lo tanto se rechaza 𝑯𝟎 , De hecho, el promedio del nuevo sistema 4.83 es muy superior
al promedio del anterior 3.5.
EFECTIVIDAD: DE LA INFORMACIÓN DEL SISTEMA
Figura 75 - Diferencia de medias de EFECTIVIDAD: DE LA INFORMACIÓN DEL SISTEMA (Elaboración

propia)
Figura 74 - Resultado de significancia de EFECTIVIDAD: DE LA INFORMACIÓN DEL SISTEMA (Elaboración propia)
P(Sig.)= 0.000 < α = 0.05
después del sistema. Por lo que se concluye que la EFECTIVIDAD: DE LA
INFORMACIÓN DEL SISTEMA en el nuevo sistema si ha tenido mejoras significativas
sobre la EFECTIVIDAD: DE LA INFORMACIÓN DEL SISTEMA del anterior sistema,
y por lo tanto se rechaza 𝑯𝟎 , de hecho, el promedio del nuevo sistema 24.67 es muy
superior al promedio del anterior 7.67.
115
EFICACIA: CALIDAD DE LA INFORMACIÓN DEL SISTEMA
Figura 77 - Diferencia de medias de EFICACIA: CALIDAD DE LA INFORMACIÓN DEL SISTEMA

(Elaboración propia)
Figura 76 - Resultado de significancia de EFICACIA: CALIDAD DE LA INFORMACIÓN DEL SISTEMA (Elaboración

propia)
P(Sig.)= 0.001 < α = 0.05
después del sistema. Por lo que se concluye que la EFICACIA: CALIDAD DE LA
INFORMACIÓN DEL SISTEMA en el nuevo sistema si ha tenido mejoras significativas
sobre la EFICACIA: CALIDAD DE LA INFORMACIÓN DEL SISTEMA del anterior
sistema, y por lo tanto se rechaza 𝑯𝟎 , de hecho, el promedio del nuevo sistema 4.67
es muy superior al promedio del anterior 2.33
EFICACIA: FUNCIONALIDAD
Figura 78 - Diferencia de medias de EFICACIA: FUNCIONALIDAD (Elaboración propia)
116
Figura 79 - Resultado de significancia de EFICACIA: FUNCIONALIDAD (Elaboración propia)
P(Sig.)= 0.000 < α = 0.05
después del sistema. Por lo que se concluye que la EFICACIA: FUNCIONALIDAD en
el nuevo sistema si ha tenido mejoras significativas sobre la EFICACIA:
FUNCIONALIDAD del anterior sistema, y por lo tanto se rechaza H0, de hecho, el
promedio del nuevo sistema 10 es muy superior al promedio del anterior 3.5
PROMEDIO GENERAL
Figura 81 - Diferencia de medias de PROMEDIO GENERAL (Elaboración propia)
Figura 80 - Resultado de significancia de PROMEDIO GENERAL (Elaboración propia)
117
P(Sig.)= 0.000 < α = 0.05
después del sistema. Por lo que se concluye que la PROMEDIO GENERAL en el nuevo
sistema si ha tenido mejoras significativas sobre la PROMEDIO GENERAL del
anterior sistema, y por lo tanto se rechaza H0, de hecho, el promedio del nuevo sistema
80.33 es muy superior al promedio del anterior 39.67
Interpretación: Se pueden interpretar nuestros resultados en un ranking de puntuación

en impacto de calidad para reconocer de qué manera ha mejorado nuestro sistema en
relación al anterior
SIGNIFICANCIA CLASIFICACIÓN
0 - 0,25 DEFINITIVAMENTE HA MEJORADO
0,26 - 0,50 MEJORADO BASTANTE
0,51 - 0,75 MEJORO
0,76 - 1 NO MEJORO
Tabla 93 - Rangos de Valoración
A Continuación, se presentan los criterios evaluados para cada prueba.
CRITERIO SIGNIFICANCIA CLASIFICACIÓN
USABILIDAD 0.016 DEFINITIVAMENTE HA MEJORADO
DISPONIBILIDAD 0.000 DEFINITIVAMENTE HA MEJORADO
INTERACCIÓN 0.102 NO MEJORO
ADAPTABILIDAD 0.000 DEFINITIVAMENTE HA MEJORADO
ESTABILIDAD 0.010 DEFINITIVAMENTE HA MEJORADO
EFECTIVIDAD: DE LA INFORMACIÓN DEL 0.000 DEFINITIVAMENTE HA MEJORADO

SISTEMA
EFICACIA: CALIDAD DE LA INFORMACIÓN DEL 0.001 DEFINITIVAMENTE HA MEJORADO
SISTEMA
EFICACIA: FUNCIONALIDAD 0.000 DEFINITIVAMENTE HA MEJORADO
PROMEDIO GENERAL 0.000 DEFINITIVAMENTE HA MEJORADO
Tabla 94 - Resultados de las Pruebas
118
5. CAPITULO 5: CONCLUSIONES
Dado a que nuestro objetivo general planteo “PROPONER UN SISTEMA DE

GESTIÓN PARA MEJORAR EL PROCESO DE VENTA DE SOAT” se debe tomar
en cuenta que para lograrlo, se debían observar varios criterios, que abarcaban desde la
conectividad (el uso de tecnologías WEB), herramientas (software Libre) y aspectos de
aceptación de software, que nos permitan entender la “interacción del usuario final con el
sistema”, por lo que en este trabajo se han considerado todos los criterios mencionados,
para que garanticen una “mejora del proceso de gestión del sistema para la empresa”,
dado que se evaluaron los mismo aspectos con el anterior sistema y el nuevo, “dando
como resultado una mejora en la mayoría de criterios”, que desde las etapas de análisis,
desarrollo, implementación, capacitación y evaluación se ha cumplido exitosamente con
un desarrollo ágil, se ha evaluado correctamente la aceptación del sistema, por lo que
concluimos que se ha logrado mejorar el proceso de gestión de SOAT para la empresa
solicitante, validada por los administradores y usuarios del sistema, cumpliendo con los
siguientes objetivos específicos.
• Primero: Se logró Analizar los requerimientos e implementar un plan de trabajo,

basado en ágil SCRUM, de manera exitosa, consiguiendo todo el análisis en un
lapso de un mes.
• Segundo: Se logró Desarrollar la propuesta en el desarrollo de un sistema de
gestión de SOAT, de manera eficiente y rápida, consiguiendo haber desarrollado
el sistema en un lapso de 3 meses.
• Tercero: Se logró Realizar un análisis de los datos con la información de ventas
histórica obtenida del sistema, que demuestra que el sistema cumple con la mejora
esperada por la empresa, y que los resultados mejoraran con mayor tiempo de uso.
• Cuarto: Se logró Validar la propuesta, a través de una evaluación directa con los
administradores, obteniendo una calificación general de DEFINITIVAMENTE
HA MEJORADO según los criterios de aceptación de software, consiguiendo una
valoración media del sistema propuesto de 80.33 frente a la del sistema anterior
de 39.67, logrando duplicar la aceptación.
en respuesta a las preguntas de investigación que se plantearon en el proceso de

planteamiento, si cuando al desarrollar el sistema se lograron:
119
¿El desarrollo de este sistema, beneficia al negocio?
Se puede concluir que, se ha logrado incrementar la posibilidad de venta, punto que es
demostrado en el apartado de análisis de datos, se puede observar que si se aplican
técnicas de predicción de series temporales, a que nos referimos como información
relacionada con el tiempo como fechas, se ha podido calcular con cierta aproximación la
posibilidad de incrementar las ventas con el uso del sistema, que quedó demostrada por
medio de gráficos estadísticos, pero no se puede asegurar, que se haya dado solo con el
uso del sistema, sino que también han podido influir otros factores.
Se puede concluir que, se ha logrado hacer eficaz el trabajo de los usuarios ya que dos
criterios en las evaluaciones estaban directamente relacionadas a este punto, la
EFICACIA en calidad de información del sistema y la de funcionalidad, que en ambos
criterios se respondieron con una clasificación de definitivamente se ha mejorado,
demostrando que a la vez de que el usuario considera que el sistema acelera su trabajo,
también cuenta con mayor calidad en la información, poniendo a disposición mejores
reportes en tiempo real, de esta manera se podría tener como conclusión que la
implementación de este sistema aporta beneficios al negocio.
¿Desarrollar el sistema propuesto, mejora el proceso de gestión de SOAT?

Se puede concluir que, se ha logrado mejorar el proceso de gestión de SOAT, ya que
se logra comprobar por medio de las respuestas de las preguntas de validación en los
diferentes criterios que se plantearon, en gran mayoría se ha clasificado como que
definitivamente ha mejorado.
¿Reducir costos de desarrollo utilizando tecnologías libres, favorece la

implementación?
Se ha logrado demostrar que con la metodología SCRUM, se puede acelerar la
implementación de software, dado que todo el desarrollo duro aproximadamente 3(tres)
meses, pero la empresa debido a sus recursos solicito, implementar el sistema solo con
tecnologías libres, desde la base de datos y las herramientas de programación, es lógico
recalcar que si tenían que adquirir licencias de servidores, dominios y permisos de
publicación, y dado a que se hizo de esa manera podemos concluir que usar tecnologías
libres es factible, y que se pueden llegar a resultados excelentes, dado a que existe una
120
gran comunidad mundial que les brinda soporte, pero que esto favorezca a la
implementación se puede responder resaltando que es favorable desde el aspecto
tecnológico ya que existe una gran comunidad de desarrolladores que aportan con soporte,
pero que los desarrolladores que la implementen tengan amplia experiencia y por lo tanto
no sean favorables al ser más costosos, ya que el uso de las tecnologías pagas presentan
soportes rápidos brindando soluciones efectivas , por lo que esto podría ser no favorable
en la velocidad de implementación, otro aspecto no favorable puede ser el de que se
pueden presentar costes altos de migración, debido a la no compatibilidad de las
tecnologías, o que tenga que ser nuevamente implementado, por último cabe recalcar que
aunque las tecnologías libres son seguras que es favorable, depende mucho del
programador, ya que es de amplio conocimiento, como poder vulnerarlas, que a
comparación de las tecnologías pagas, la seguridad es garantizada, por todo esto se puede
decir que aunque pueda ser favorable económicamente, estos aspectos deben ser
evaluados para una continuación del proyecto o para una migración el desarrollo a
tecnologías pagas.
5.1 Principales Contribuciones
Las principales contribuciones de este trabajo están relacionadas con:
1. Un desarrollo con herramientas modernas de software libres, para el desarrollo de

un sistema WEB, cumpliendo con estándares de calidad, por medios de pruebas
de aceptación, obteniendo resultados favorables en tiempo y esfuerzo, además de
haber utilizado metodologías ágiles, que en los últimos años se están convirtiendo
en los procesos eficientes que las empresas usan para brindar soluciones en
tecnología.
2. Una herramienta de software moderna para la empresa, que le permita competir
con el mercado nacional y con capacidad de escalabilidad.
3. Un ejemplo de validación de aceptación de software a través de opiniones de
administradores del sistema, comparando su trabajo con una herramienta anterior
y una nueva propuesta.
121
5.2 Discusión
1. Reconocemos que son efectivas las metodologías ágiles, para el desarrollo de

soluciones tecnológicas, pequeñas y medianas, pero al tratarse de
implementaciones más grandes, se reconoce que la metodología RUP brinda, más
información a los programadores venideros, ya que cuando se trata de
metodologías ágiles la documentación de software es sencilla, y esto puede afectar
a la adaptación rápida de nuevos programadores, ya que en la metodología RUP,
al ser de una documentación amplia, brinda más flexibilidad para la rotación de
equipo, por lo que no recomendamos las metodologías ágiles como una
herramienta de desarrollo para implementaciones grandes.
2. De la misma manera reconocemos que las tecnologías libres, brindan un rápido
aprendizaje como a su vez un fácil acceso a su tecnología, pero no cuentan con
una documentación muy amplia y a su vez no se cuenta con soporte personalizado,
por lo que reconocemos que para implementaciones más grandes y con
información más delicada, sea necesario por optar por tecnologías pagas ya que
el soporte y la documentación pueden jugar un papel importante para solucionar
problemas críticos
5.3 Trabajos Futuros
1. La empresa reconoce, la utilidad del nuevo sistema en su modelo de negocio, por

lo que se ha requerido, una segunda etapa, para lograr una transformación digital
de su negocio, y aprovechar las oportunidades que brindan las tecnologías WEB,
para hacer ventas de SOAT en línea, para esto solicitaron cotizadores para clientes
en línea y en aplicaciones móviles.
2. Reconocemos que SCRUM no es la única metodología ágil utilizada para
desarrollar herramientas de software, por lo que identificamos como trabajo
futuro, la investigación sobre la implementación utilizando otros modelos como
por ejemplo “EXTREME PROGRAMING" y “KAM-BAM "
3. La recolección de la información generada por el sistema brinda múltiples
posibilidades de análisis para el beneficio de toma de decisiones, por lo que se
considera un trabajo futuro, una posible estrategReia de minería de datos, donde
se descubran oportunidades para mejorar el negocio, y el funcionamiento del
122
sistema, pero para que esto se dé, se requiere de más tiempo de uso y que se
incremente la cantidad de información del funcionamiento del negocio.
6. Bibliografía
Escobar, A. (2017). Desarrollo del sistema de control y gestión del seguro de

accidentes de la compañía de transporte interprovincial “EXPRESS ATENAS”,
utilizando los FRAMEWORKs CODEIGNITER y BOOSTRAP. B.S. thesis, escuela
Superior Politécnica de Chimborazo.
Amini & Lisetti (2013) Hapfacs: An open source api/software to generate facs-based
EXPRESSions for ecas animation and for corpus generation. In Affective Computing
and Intelligent Interaction (ACII), 2013 Humaine Association Conference on, pages
270–275. IEEE.
APESEG, (2019) Accedido por última vez, enero ,2019. Asociación Peruana de
Empresas de Seguros.
Boehm (2006) A view of 20th and 21st century software engineering. In Proceedings
of the 28th international conference on Software engineering, pages 12–29. ACM.
Brockwell (2002) Introduction to time series and forecasting, volume 2. Springer.
Cavone (2015) How to align the project goals to the business strategy.
Cedeño (2017) Propuesta tecnológica de sistema de asignación de cargas horarias

de la carrera ingeniería en sistemas administrativos computarizados de la facultad
de ciencias administrativas de la universidad de guayaquil. B.S. thesis, Universidad
de Guayaquil.
Cochran (2012) Twitter BOOSTRAP WEB development how-to. Packt Publishing Ltd.
Cochran (1970). Access control principles for security and privacy in integrated data
banks. IBM Internal Memo, pages 211–220.
Codd (1990) The relational model for database management: version 2. Addison-
Wesley Longman Publishing Co., inc.
123
Cruz & Alexander (2017) Desarrollo de un sistema para la creación de horarios para
la universidad central del ecuador. B.S. thesis, Quito: UCE.
Delgado E. (2008) Metodologías de desarrollo de software. ¿cuál es el camino?

Revista de Arquitectura e Ingeniería, 2(3).
Digital Ocean (2017) https://www.digitalocean.com/. (Accedido por última vez,

diciembre, 2019).
Elejabarrieta & Iñiguez (2010) Construcción de escalas de actitud, tipo thurstone y

likert. La Sociología en sus escenarios, (4).
Espinosa & Bernabé (2018) Sistema de gestión de venta para la tienda de estímulo
de la empresa agropecuaria la cuba. Universidad & Ciencia, 5(2):213–227.
García & Zarama (2017) Propuesta tecnológica para acelerar el proceso de

cotización de los asesores de seguros a través del desarrollo de un software ,
Universidad de Guayaquil Facultad de Ciencias Administrativas.
Gizmodo (2019) gizmodo methods to perform time series forecasting. (Accedido por
última vez, enero 2019)
Johnson, R., Hoeller, J., Arendsen, a., & Thomas, R (2009) Professional Java
development with the SPRING FRAMEWORK. John Wiley & Sons.
Johnson R., Hoeller, J., Donald, K., Sampaleanu, C., Harrop, R., Risberg, T.,
Arendsen, A., Davison, D., Kopylenko, D., Pollack, M., (2004) The SPRING
FRAMEWORK–reference documentation. Interface, 21:27.
Kniberg (2007) Scrum y XP desde las trincheras. C4Media Inc. InfoQ.
Kniberg, H., Skarin, M., de Mary Poppendieck, P., and Anderson, D. (2010) Kan- ban
y scrum obteniendo lo mejor de ambos. Prólogo de Mary Poppendieck & David
Anderson.
Levin, R. I., Rubin, D. S., and Samaniego, a. H. F. (1996). Estadística para

administradores. Number 519.5 L47Y 1994. Prentice-Hall Hispanoamericana.
124
Mitaritonna, A. D. (2010). Una innovadora metodología para el desarrollo de
software en ambientes de trabajo virtuales. Ciudad Autónoma de Buenos Aires, page
12.
Molina, S. G. R. (2014). Metodologías ágiles enfocadas al modelado de

requerimientos. Informes Científicos-Técnicos UNPA, 5(1):1–29.
Moreno O., M. A. (2017). Análisis comparativo de herramientas orientadas a

componentes WEB validado con un caso de estudio. B.S. thesis, universidad de las
Fuerzas Armadas ESPE. Carrera de Ingeniería en Sistemas e Informática.
MySQL (2001). MySQL, https://www.mysql.com (Accedido por última vez, enero,

2019).
Patiño C., M., M., L., & P., C. (2013). Implementación de métodos ágiles para la
simulación de casos de uso y prototipado en el proceso de desarrollo de software.
Revista Cubana de Ciencias Informáticas, 7(3):85–95.
Piñero, F. (2004). El modo de desarrollo industrial fordista-keynesiano:

características, crisis y reestructuración del capitalismo. Contribuciones a la
economía. Obtenido de http://www. eumed. net/ce/2004/fjp-ford. pdf (Accedido por
última vez, julio, 2019).
Pressman (2010) Ingeniería del software un enfoque práctico, séptima edición ed.
Programacion.net (2019) http://programacion.net/articulo/agiles (Accedido por

última vez, febrero, 2019).
Quezada-Sarmiento, P. A. & Mengual A., S. (2017). Implementación de una solución

WEB y móvil para la gestión vehicular basada en arquitectura de aspectos y
metodologías ágiles: Un enfoque educativo de la teoría a la práctica. RISTI-Revista
Ibérica de Sistemas e Tecnologías de Informação, (25):98–111.
Rodríguez, A. A. G., Zambrano-Santana, J. L., & Castro-Limones, A. N. (2017).

Sistema de control y monitoreo de bebés basados en open source. Revista Publicando,
4(13 (1)):40–54.
125
Rodríguez, M. & Piattini, M. (2015). Experiencias en la industria del software:
Certificación del producto con iso/iec 25000. In XVIII Congreso Iberoamericano en
Ingeniería de Software CIbSE 2015.
Romero, J. L. N., García, L. A. M., Cardozo, J. C. G., & Piñeres, M. F. C. (2017).

Construcción colaborativa de lineamientos de informática para el desarrollo de
software que permita la realización modular del sistema de acreditación y el registro
calificado liderar. Acta ScientiÆ InformaticÆ, 1(1).
Scharager, J. & Reyes, P. (2001). Muestreo no probabilístico. Metodología de la

investigación para las ciencias sociales. Pontificia Universidad Católica de Chile.
Santiago de Chile.
Semana Económica (2019) Semana Económica (Accedido por última vez, enero
,2019). http://semanaeconomica.com/.
Silva, e. C. (2019) Metodologías ágiles y DESIGN THINKING: Gestión efectiva

basada en las necesidades e intereses de los clientes. InnovaG, (1):14–16.
Smith, A., Quintana, R. F., & Blas, L. P. (1996). Investigación de la naturaleza y

causas de la riqueza de las naciones. Junta de Castilla y León, Consejería de
Educación y Cultura Valladolid.
Somerville, I. (2005). Ingeniería de software. 7ma edición, (PP: 30-620). Trigás G.,
M. (2012). Metodología SCRUM.
Vue.js, (2018) https://vuejs.org/. (Accedido por última vez, febrero 2019).
126
7. Anexos
1. Certificado del curso SCRUM

2. Carta de autorización de uso de software
3. Encuesta de calidad de software para el PRE-TEST y el POST-TEST
4. Tabla de precios SOAT, de la aseguradora LA POSITIVA
5. Actas de Reunión de planificación de SPRINTS
6. Manual de Usuario
127
7.1 Certificado del curso SCRUM
128
7.2 Carta de autorización de uso de software
7.3 Encuesta de calidad de software para el PRE-TEST y el POST-TEST
129
130
7.4 Tabla de precios SOAT, de la aseguradora LA POSITIVA
131
7.5 Actas de Reunión de planificación de SPRINTS
132
133
134
135
136
7.6 Manual de Usuario
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152

71.0653.IS

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

71.0653.IS

Cargado por

Copyright:

Formatos disponibles

Universidad Católica de Santa María

Facultad de Ciencias e Ingenierías Físicas y

DESARROLLO DE UN SISTEMA DE GESTIÓN DE CERTIFICADOS SOAT,

Tesis presentada por la Bachiller:

Palabras clave: Ingeniería de Sistemas, Metodologías ágiles, SCRUM, sistema de

Information systems or technologies based on WEB technologies have changed the

Keywords: Systems Engineering, Agile Methodologies, SCRUM, SOAT management

Sería de gran beneficio que en la mediana y pequeña empresa se adopten procesos de

En este trabajo se expone un desarrollo(implementación), de un sistema implementado

Con el riesgo de continuar generando pérdidas, ya que la competencia contaba con

En respuesta a esta problemática se propuso la implementación de un software(sistema),

Para esto se propuso también la implementación de privilegios de usuarios, dado a que

1. CAPITULO 1: CONSIDERACIONES GENERALES........................................ 1

1.1 Definición del problema.................................................................................. 1

1.3.1 Justificación Teórica ................................................................................ 3

1.4 Propósito ........................................................................................................ 8

1.5.1 Delimitación de la Investigación .............................................................. 9

1.6 Objetivos ........................................................................................................ 9

1.6.1 Objetivo general ...................................................................................... 9

1.7 Población y muestra ...................................................................................... 10

2. CAPITULO 2: MARCO TEORICO ................................................................. 13

2.1 Estado del Arte ............................................................................................. 13

2.2.1 Desarrollo Ágil ...................................................................................... 18

2.3 Metodología SCRUM ................................................................................. 19

2.3.1 Componentes de SCRUM ...................................................................... 20

2.4 Bases teóricas respecto al problema .............................................................. 27

3. CAPITULO 3: DESARROLLO ....................................................................... 32

3.1 Método de investigación ............................................................................... 32

3.2.1 Diagrama de Casos de Uso..................................................................... 35

3.3 Análisis e interpretación ................................................................................ 48

3.3.1 Estructura de negocio de las empresas Corredoras de seguros ................ 48

3.4 Desarrollo de SPRINTS ................................................................................ 55

3.4.1 Planificación del PRODUCT BACKLOG .............................................. 55

3.5 Requerimientos Funcionales y no Funcionales .............................................. 61

3.5.1 Diseño de Interfaces (MOCKUPS) ........................................................ 63

3.6 Pruebas de Entregables ................................................................................. 78

3.6.1 Pruebas del SPRINT 1: .......................................................................... 78

3.7 Análisis de datos ........................................................................................... 82

3.7.1 ARIMA ................................................................................................. 83

4.1 Evaluación del Sistema ................................................................................. 91

4.1.1 Resultados de la evaluación (PRE-TEST) .............................................. 92

4.2 Resultados .................................................................................................. 110

5. CAPITULO 5: CONCLUSIONES ................................................................. 119

5.1 Principales Contribuciones .......................................................................... 121

6. Bibliografía .................................................................................................... 123

7.1 Certificado del curso SCRUM .................................................................... 128

Figura 1- Privilegios del sistema (Elaboración propia) .................................................. 6

Tabla 1 - Resumen de costes de desarrollo .................................................................... 5

1.1 Definición del problema

El creciente mercado de venta de SOAT vehiculares, ha ido evolucionado con el tiempo,

Por este motivo la empresa corredora de seguros solicitó la implementación un sistema

Es así que identificamos como principal problema, el tiempo de demora en el proceso de

1.2 Antecedentes del problema

Se exponen en este apartado un grupo de trabajos relacionados a la problemática de esta

Se propone en esta investigación la visión del “sistema a través de las interfaces

Molina (2014) en su trabajo “metodologías ágiles enfocadas al modelado de

1.3.1 Justificación Teórica

El desarrollo de este sistema comprende una serie de actividades de análisis de requisitos

El FRAMEWORK para el BACK-END, que comprende que la fuente de información y

1.3.1.1 Aspectos Técnicos

Para este trabajo se utilizará la metodología SCRUM, y para la implementación del

• Para la capa lógica o de acceso de datos (BACK-END)