71.0653.IS
71.0653.IS
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.
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.
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.
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.
DICTAMEN APROBATORIO
DEDICATORIA
AGRADECIMIENTO
RESUMEN
ABSTRACT
INTRODUCCIÓN
4. CAPITULO 4: VALIDACIÓN......................................................................... 91
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.
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
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)
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.
TOTAL: 15,250
5
1.3.2 Justificación aplicativa
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.
7
1.3.2.2 Beneficios
1.3.2.3 Localización
1.4 Propósito
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.
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
9
1.6.3 Preguntas de investigació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.
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.
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
12
2. CAPITULO 2: MARCO TEORICO
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.
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.
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.
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.
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.
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.
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)
• 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.
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):
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
• El equipo de desarrollo: Trigás (2012) las define como los participantes del
equipo SCRUM:
• 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
22
Figura 4 - Ejemplo de Historia de usuario (Pressman, 2010)
En esta sección se van a detallar, todas las fases que se implementaron para el desarrollo
del proyecto utilizando la metodología SCRUM.
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)
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:
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.
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.2 Arquitectura
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).
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:
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.
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
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”.
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:
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:
De esta manera se valida la mejora entre medias demostrando que se logró optimizar o
no lo planteado en este trabajo.
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.
35
3.2.2 Diagrama de clases
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.
37
38
Figura 11 - Diagramas de Secuencia de administrador (Elaboración propia)
39
3.2.3.2 Diagrama de Secuencia de Vendedor
40
3.2.4 Diagrama de Procesos
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.
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)
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).
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
VENTA
LLAVE NOMBRE CAMPO TIPO TAMAÑO DESCRIPCIÓN
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
LLAVE NOMBRE CAMPO TIPO TAMAÑO DESCRIPCIÓ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
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
LLAVE NOMBRE CAMPO TIPO TAMAÑO DESCRIPCIÓN
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
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
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.
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.
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
• 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
49
HISTORIA DE USUARIO HISTORIA DE USUARIO
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
Numero: GV-03 Numero: GV-04
• Ingresar al sistema con rol de administrador. • Ingresar al sistema con rol de administrador.
• 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
• Ingresar al sistema con rol de administrador. • Ingresar al sistema con rol de administrador.
• 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
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 los VCC (vehículos, clases y categorías) de los vehículos de los precios de los vehículos sin excepciones
Numero: GV-07 Numero: GV-08
• Ingresar al sistema con rol de administrador. • Ingresar al sistema con rol de administrador.
• 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
• Ingresar al sistema con rol de administrador. • Ingresar al sistema con rol de administrador.
• 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
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 certificados de Pólizas SOAT, uno por uno. de certificados de Pólizas SOAT, masivo
Numero: GV-11 Numero: GV-12
• Ingresar al sistema con rol de administrador. • Ingresar al sistema con rol de administrador.
• 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
• Ingresar al sistema con rol de administrador. • Ingresar al sistema con rol de administrador.
• 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
HISTORIA DE USUARIO HISTORIA DE USUARIO
Nombre de la Historia: Revisión y eliminar de los Estados de Nombre de la Historia: Revisión de Ventas terminadas
venta en proceso
Numero: GV-15 Numero: GV-16
• 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
• 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
HISTORIA DE USUARIO HISTORIA DE USUARIO
Nombre de la Historia: Registrar datos del vehículo, Nombre de la Historia: Imprimir el certificado o reasignar la
contratante y pagos póliza
Numero: GV-19 Numero: GV-20
• 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:
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:
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:
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.
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
PRODUCT BACKLOG
57
GV-17 Observar y Anular pólizas SOAT vendidas EV
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
vehículos Desarrollo
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
59
SPRINT 2 Inicio: 25/09/2017 Culminació 14/10/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 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
vehículos Desarrollo
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
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
Alta Registrar datos del vehículo, contratante y pagos Equipo de Desarrollo 4 Terminado
Tabla 27 - SPRINT 4
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.
63
Figura 25 - Diseño de interfaz de administración de Figura 26 - Diseño de interfaz de administración de
Clases de vehículos (Elaboración propia) VCC (Elaboración propia)
64
Figura 32 - Diseño de interfaz de administración de Figura 31 - Diseño de interfaz de administración de
estados (Elaboración propia) cotizador (Elaboración propia)
65
Figura 37 - Diseño de interfaz de administración de Reportes del sistema (Elaboración propia)
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:
66
Figura 38 - Interfaz de TRELLO con las actividades del SPRINT 1 y sus procesos(Elaboración propia)
67
3.5.3.1 Entregables del SPRINT 1:
Figura 40 - Vista responsiva móvil (Elaboración propia)
68
Figura 42 - Interfaz de administración de usuarios (Elaboración propia)
69
c) Entregable de Registro, actualización y eliminación de Oficinas: Este
entregable contiene las siguientes funcionalidades:
• Entidades utilizadas: Oficina.
• Interfaces creadas: Se desarrolló una sola vista
o La primera: vista para registrar, actualizar y eliminar oficinas.
70
Figura 45 - Interfaz de administración de tipos de uso (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.
• Interfaces creadas: Se desarrolló una sola vista
o La primera: Vista para registrar, actualizar y eliminar Clases de
vehículos.
72
Figura 48 - Interfaz de administración de VCC de vehículos (Elaboración propia)
73
b) Entregable de Registro, actualización y eliminación de Pólizas: Este
entregable contiene las siguientes funcionalidades:
• Entidades utilizadas: Certificados de Pólizas
• Interfaces creadas: Se desarrolló una sola vista
o La primera: Vista para registrar pólizas masivas.
74
Figura 51 - Interfaz de administración de re-asignaciones o eliminaciones de pólizas (Elaboración propia)
75
3.5.4.2 Entregables del SPRINT 4:
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.
77
Figura 57 - Reporte de ventas por compañía (Elaboración propia)
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.
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
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
Pólizas:
79
o Masivamente muestra el mensaje de
alerta
Pólizas:
80
3.6.4 Pruebas del SPRINT 4:
81
3.6.4.2 Pruebas de entregables de Reportes:
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
𝑌𝑡 = −( 𝛿 𝑑 𝑌𝑡 − 𝑌𝑡 + ∅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,
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.
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
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:
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)),
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.
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)
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)
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.
89
2019-02-21 36.0 2019-03-20 34.554548
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
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?
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?
92
4.1.1.1 USABILIDAD
P1. ¿Hace uso del sistema para administrar la empresa?
Siempre 3 50 %
Casi 1 16.67 %
Siempre
A veces 1 16.67 %
Nunca 0 0%
TOTAL: 6 100 %
Tabla 42 - Tabla de la Pregunta P1 del PRE-TEST
4.1.1.2 DISPONIBILIDAD
Casi Siempre 0 0%
A veces 2 33,33 %
Nunca 2 33,33 %
TOTAL: 6 100 %
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 %
Tabla 45 - Tabla de la Pregunta P4 del PRE-TEST
P5.- ¿En el sistema encuentras las opciones necesarias para administrar la empresa?
Casi 1 16,67
Siempre %
A veces 4 66,67 %
Nunca 0 0%
TOTAL: 6 100 %
4.1.1.3 INTERACCIÓN
Siempre 5 83,34 %
0 0%
A veces
0 0%
Casi Nunca
0 0%
Nunca
6 100 %
TOTAL:
94
P7.- ¿Es fácil usar el sistema?
A veces 2 33,33 %
Nunca 0 0%
TOTAL: 6 100 %
4.1.1.4 ADAPTABILIDAD
Casi Siempre 0 0%
A veces 0 0%
Casi Nunca 0 0%
Nunca 6 100 %
TOTAL: 6 100 %
4.1.1.5 ESTABILIDAD
Siempre 0 0%
Casi Siempre 3 50 %
A veces 3 50 %
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
95
P10.- ¿Utiliza los reportes que le ofrece el sistema?
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?
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?
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
para administrar el negocio?
P14.- ¿Considera usted que en el sistema se puede
ingresar toda
la información necesaria para administrar el negocio?
Respuesta Cantida Porcenta
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 %
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?
Cantidad Porcentaje
Respuesta
Siempre 0 0%
Casi Siempre 0 0%
A veces 0 0%
Nunca 5 83,34 %
TOTAL: 6 100 %
Siempre 0 0%
Casi Siempre 0 0%
A veces 3 50 %
Nunca 1 16,67 %
TOTAL: 6 100 %
98
4.1.2.1 USABILIDAD
Casi 2 33,33 %
Siempre
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
Tabla 59 - Tabla de la Pregunta P1 del POST-TEST
Casi 1 33,33 %
Siempre
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
Tabla 60 - Tabla de la Pregunta P2 del POST-TEST
4.1.2.2 DISPONIBILIDAD
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
99
P4.- ¿Se encuentra disponible la información para
administrar
la empresa en todo momento?
Respuesta Cantida Porcenta
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?
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
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
Casi Siempre 0 0%
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
4.1.2.5 ESTABILIDAD
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
Tabla 67 - Tabla de la Pregunta P9 del POST-TEST
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?
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?
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
para administrar el negocio?
Siempre 5 83,34 %
A veces 0 0%
Casi Nunca 0 0%
Nunca 0 0%
TOTAL: 6 100 %
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?
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 %
105
Comparación de resultados de la P5: En
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.
Tabla 80 - Comparación de la Pregunta(P5)
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.
Tabla 83 - Comparación de la Pregunta(P8)
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.
Tabla 86 - Comparación de la Pregunta(P11)
109
4.2 Resultados
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.
USABILIDAD
Decisión estadística
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
Decisión estadística
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
Decisión estadística
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
113
Figura 71 - Resultado de significancia de ADAPTABILIDAD (Elaboración propia)
Decisión estadística
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 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
114
Decisión estadística
P(Sig.)= 0.010 < α = 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 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.
Decisión estadística
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 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
Decisión estadística
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 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
116
Figura 79 - Resultado de significancia de EFICACIA: FUNCIONALIDAD (Elaboración propia)
Decisión estadística
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 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
117
Decisión estadística
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 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
SIGNIFICANCIA CLASIFICACIÓN
0,76 - 1 NO MEJORO
Tabla 93 - Rangos de Valoración
118
5. CAPITULO 5: CONCLUSIONES
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.
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.
121
5.2 Discusión
6. Bibliografía
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.
Cavone (2015) How to align the project goals to the business strategy.
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.
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.
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, 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.
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.
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.
Pressman (2010) Ingeniería del software un enfoque práctico, séptima edición ed.
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.
Semana Económica (2019) Semana Económica (Accedido por última vez, enero
,2019). http://semanaeconomica.com/.
Somerville, I. (2005). Ingeniería de software. 7ma edición, (PP: 30-620). Trigás G.,
M. (2012). Metodología SCRUM.
126
7. Anexos
127
7.1 Certificado del curso SCRUM
128
7.2 Carta de autorización de uso de software
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