Facultad de Ingeniería
Ingeniería de Sistemas e Informática
Programa Especial de Titulación:
“DISEÑO E IMPLEMENTACIÓN DE UNA
APLICACIÓN MÓVIL PARA MEJORAR EL
PROCESO DE VENTA DE LÍNEAS
PREPAGO EN UNA EMPRESA DE
TELECOMUNICACIONES”
Autor: Iván Gaona Arredondo
Para optar el Título Profesional de
Ingeniero de Sistemas e Informática
Lima – Perú
2020
1
DEDICATORIA:
Este trabajo se lo dedico completamente a mi
familia, por haber apoyado siempre cada una
de mis decisiones y por haber cultivado en mis
valores que ayudaron en mi crecimiento, tanto
como profesional y como persona.
2
INDICE DE CONTENIDO
INDICE DE FIGURAS..............................................................................................................4
INDICE DE TABLAS ...............................................................................................................5
INTRODUCCIÓN ...................................................................................................................9
CAPITULO 1 - ASPECTOS GENERALES .................................................................................. 10
1.1.
Definición del problema .............................................................................................. 10
1.1.1.
Descripción del problema ................................................................................... 10
1.1.2.
Formulación del problema .................................................................................. 11
1.2.
Definición de objetivos................................................................................................ 12
1.2.1.
Objetivo general .................................................................................................. 12
1.2.2.
Objetivos específicos ........................................................................................... 13
1.3.
Alcances y limitaciones ............................................................................................... 14
1.3.1.
Alcances............................................................................................................... 14
1.3.2.
Limitaciones......................................................................................................... 15
1.4.
Justificación ................................................................................................................. 15
CAPITULO 2 - FUNDAMENTO TEÓRICO ............................................................................... 17
2.1.
Antecedentes .............................................................................................................. 17
2.1.1.
Nacional .............................................................................................................. 17
2.1.2.
Internacional ...................................................................................................... 18
2.2.
Marco teórico .............................................................................................................. 18
2.3
Marco metodológico .................................................................................................. 21
2.4.
Marco conceptual ....................................................................................................... 23
CAPITULO 3 – DESARROLLO DE LA SOLUCIÓN ..................................................................... 25
3.1. FASE DE INICIACIÓN .................................................................................................... 25
3.1.1.
Visión del proyecto ................................................................................................. 25
3.1.2.
Creación del equipo SCRUM ................................................................................... 25
3.1.3.
Product Backlog Priorizado .................................................................................... 27
3.1.4.
Cronograma de Actividades del Proyecto .............................................................. 29
3.1.5.
Identificación y Evaluación de Riesgos ................................................................... 32
3.2. FASE DE PLANIFICACIÓN Y ESTIMACIÓN....................................................................... 34
3.2.1.
Sprint Backlog ........................................................................................................... 34
3.2.2.
Elaboración de historias de usuario ........................................................................ 36
3.2.3.
Estimación de historias de usuario .......................................................................... 47
3
3.3. FASE DE IMPLEMENTACIÓN ......................................................................................... 50
3.3.1.
Desarrollo de la Aplicación ....................................................................................... 50
3.3.2.
Diseño de tablas involucradas.................................................................................. 55
3.4. FASE DE REVISIÓN Y RETROSPECTIVA .......................................................................... 25
3.4.1
Arquitectura de la Aplicación .................................................................................. 58
3.4.2
Pruebas con SoapUI ................................................................................................. 59
3.5. FASE DE LANZAMIENTO ............................................................................................... 25
3.5.1.
Product Increment .................................................................................................. 60
CAPITULO 4 - RESULTADOS ............................................................................................... 62
4.1. Resultados........................................................................................................................ 62
4.2. Costos y Presupuesto....................................................................................................... 67
CONCLUSIONES ................................................................................................................. 69
REFERENCIA BIBLIOGRÁFICA .............................................................................................. 70
ANEXOS............................................................................................................................. 72
4
INDICE DE FIGURAS
Figura N° 01 – Distribución de mercado de telefonía móvil 2018 ....................................................10
Figura N° 02 – Flujo de atención presencial en un CAC ....................................................................11
Figura N° 03 – Escenario Objetivo 01 ................................................................................................13
Figura N° 04 – Escenario Objetivo 02 ................................................................................................13
Figura N° 05 – Escenario Objetivo 03 ................................................................................................14
Figura N° 06 - Esquema de trabajo SCRUM.......................................................................................20
Figura N° 07 – Lista de requerimientos para el desarrollo de la aplicación Móvil ............................25
Figura N° 08 – Elaboración de equipo SCRUM ..................................................................................26
Figura N° 09 – Login de la Aplicación ................................................................................................50
Figura N° 10 – Login de la Aplicación_PopUP ...................................................................................50
Figura N° 11 – Login de la Aplicación_BM .........................................................................................51
Figura N° 12 – Login de la Aplicación_ERROR ...................................................................................52
Figura N° 13 – Proceso de Venta_DatosDelCliente ...........................................................................52
Figura N° 14 – Proceso de Venta_Modalidad ...................................................................................53
Figura N° 15 – Proceso de Venta_TipoVenta ....................................................................................53
Figura N° 16 – Tabla de stock de equipos prepago ...........................................................................53
Figura N° 17 - Configuración de cobertura........................................................................................54
Figura N° 18 – Aceptar contratos ......................................................................................................54
Figura N° 19 – Confirmación de alta Nueva ......................................................................................55
Figura N° 20 – Lista de distribuidores autorizados............................................................................55
Figura N° 21 – Lista de números disponibles para venta ..................................................................56
Figura N° 22 – Lista de números utilizados para venta .....................................................................56
Figura N° 23 – Lista de Altas Prepago por Chip .................................................................................57
Figura N° 24 – Lista de Altas Prepago por Pack.................................................................................57
Figura N° 25 – Lista de equipos Prepago ...........................................................................................58
Figura N° 26 – Lista de ciudades Prepago .........................................................................................58
Figura N° 27 – Arquitectura de la aplicación de ventas ....................................................................59
Figura N° 28 - Petición de request con SoapUI .................................................................................60
Figura N° 29 - Petición de response con SoapUI ...............................................................................61
Figura N° 30 – Vista resumen de la Aplicación móvil de ventas .......................................................62
Figura N° 31 – Cantidad diaria de clientes atendidos .......................................................................64
Figura N° 32 – Ingresos en ventas según el tipo de canal de atención .............................................65
Figura N° 33 – Cantidad mensual de clientes atendidos por canal de venta ....................................67
5
INDICE DE TABLAS
Tabla N° 1 – Tabla de causa/efecto ............................................................................................. 12
Tabla N° 2 – Tabla comparativa SCRUM vs KANBAN .................................................................. 21
Tabla N° 3 - Desarrollo de fases de SCRUM ................................................................................ 22
Tabla N° 4 – Definición de roles del equipo SCRUM ................................................................... 27
Tabla N° 5 – Elaboración de épicas del proyecto ........................................................................ 27
Tabla N° 6 – Listado general de historias de usuario .................................................................. 28
Tabla N° 7 – Cronograma de actividades .................................................................................... 29
Tabla N° 8 – Elaboración de riesgos en el proyecto .................................................................... 32
Tabla N° 9 – Tabla de riesgos ...................................................................................................... 33
Tabla N° 10 – Tabla de probabilidades ........................................................................................ 33
Tabla N° 11 – Estimación de Sprint 1 .......................................................................................... 34
Tabla N° 12 – Estimación de Sprint 2 .......................................................................................... 34
Tabla N° 13 – Estimación de Sprint 3 .......................................................................................... 35
Tabla N° 14 – Estimación de Sprint 4 .......................................................................................... 35
Tabla N° 15 – Estimación de Sprint 5 .......................................................................................... 35
Tabla N° 16 – Estimación de Sprint 6 .......................................................................................... 36
Tabla N° 17 - Historia de usuario HU01....................................................................................... 36
Tabla N° 18 - Historia de usuario HU02....................................................................................... 37
Tabla N° 19 - Historia de usuario HU03....................................................................................... 37
Tabla N° 20 - Historia de usuario HU04....................................................................................... 38
Tabla N° 21 - Historia de usuario HU05....................................................................................... 38
Tabla N° 22 - Historia de usuario HU06....................................................................................... 39
Tabla N° 23 - Historia de usuario HU07....................................................................................... 39
Tabla N° 24 - Historia de usuario HU08....................................................................................... 40
Tabla N° 25 - Historia de usuario HU09....................................................................................... 40
Tabla N° 26 - Historia de usuario HU10....................................................................................... 41
Tabla N° 27 - Historia de usuario HU11....................................................................................... 41
Tabla N° 28 - Historia de usuario HU12....................................................................................... 42
Tabla N° 29 - Historia de usuario HU13....................................................................................... 42
Tabla N° 30 – Historia de usuario HU14 ...................................................................................... 43
Tabla N° 31 – Historia de usuario HU15 ...................................................................................... 43
Tabla N° 32 – Historia de usuario HU16 ...................................................................................... 43
Tabla N° 33 – Historia de usuario HU17 ...................................................................................... 44
6
Tabla N° 34 – Historia de usuario HU18 ...................................................................................... 44
Tabla N° 35 – Historia de usuario HU19 ...................................................................................... 45
Tabla N° 36 – Historia de usuario HU20 ...................................................................................... 45
Tabla N° 37 – Historia de usuario HU21 ...................................................................................... 45
Tabla N° 38 – Historia de usuario HU22 ...................................................................................... 46
Tabla N° 39 – Historia de usuario HU23 ...................................................................................... 46
Tabla N° 40 – Priorización de historias de usuario ...................................................................... 47
Tabla N° 41 – Asignación de puntos de historias de usuario ...................................................... 48
Tabla N° 42 – Tabla de puntos totales por épicas ....................................................................... 49
Tabla N° 43 – Tabla de product backlog priorizado .................................................................... 49
Tabla N° 44 - Cuadro Comparativo del Resultado N° 1 ............................................................... 63
Tabla N° 45 – Resumen del Resultado N° 1................................................................................. 63
Tabla N° 46 - Cuadro Comparativo del Resultado N° 2 ............................................................... 64
Tabla N° 47 – Resumen del Resultado N° 2................................................................................. 65
Tabla N° 48 - Cuadro Comparativo del Resultado N° 3 ............................................................... 66
Tabla N° 49 – Resumen del Resultado N° 3................................................................................. 67
Tabla N° 50 – Costo de Personal del Proyecto ............................................................................ 68
Tabla N° 51 – Costo de Hardware ............................................................................................... 68
Tabla N° 52 – Costo de Tecnología .............................................................................................. 69
Tabla N° 53 – Costo total del proyecto ....................................................................................... 69
7
RESUMEN
El contenido del presente trabajo de investigación tiene como finalidad ofrecer una alternativa de
mejora al proceso de venta de líneas móviles Prepago aplicada a una empresa del sector de
telecomunicaciones, esta alternativa de mejora consiste en la implementación de una aplicación
móvil de ventas. Para el desarrollo de este proyecto se ha utilizado el marco de trabajo SCRUM,
dando como resultado 20 procesos definidos que nos permitirán desarrollar una aplicación que
cumpla con todos los estándares de calidad y operatividad que una solución tecnológica de este
tipo deba tener.
En el Capítulo I, se definen los objetivos y los problemas que pretenden ser resueltos con la
implementación de esta aplicación móvil. Además de ello, se define cual será el alcance del
proyecto y las limitaciones que este tendrá.
En el Capítulo II, se describe toda la información y conocimientos necesarios que deben tenerse
para desarrollar un proyecto de este tipo. Esto quiere decir, los antecedentes que sirven como base
para el desarrollo del proyecto, el marco teórico que nos permite conocer el desarrollo de esta
tecnología a lo largo de la historia y la metodología que emplearemos para la gestión y desarrollo
de la aplicación móvil.
En el Capítulo III, se detallan todos los procesos que intervinieron para el desarrollo del proyecto,
se detalla la arquitectura que tendrá la aplicación y las tablas que fueron necesarias para su
funcionamiento, todo ello en base al cronograma de actividades que también se encuentra definido
en este capítulo.
En el Capítulo IV, se muestran los resultados obtenidos luego de realizar la implementación de la
aplicación móvil, con el apoyo de cuadros estadísticos y gráficos se pone en evidencia el impacto
que tiene el uso de una aplicación móvil dentro del proceso de ventas.
Finalmente, se mencionan las conclusiones y recomendaciones a las que se llegan luego de concluir
el desarrollo de este informe.
8
INTRODUCCIÓN
El presente proyecto propone la implementación de un aplicativo móvil para la mejora del proceso
de ventas de líneas móviles Prepago de una empresa de telecomunicaciones, dicha empresa
necesitaba con urgencia una nueva forma de realizar las ventas de sus productos debido a que hoy
en día las grandes empresas desarrollan aplicaciones para realizar operaciones que hasta hace
algunos años se realizaban de manera presencial.
El producto principal que venden estos operadores son las líneas móviles, el cual representa un 60%
del total de ventas. El proceso de ventas actual requiere la atención presencial y el promedio por
cada atención es de 15 minutos. Esta demora tiene como consecuencia que en la mayoría de casos
el cliente desista de adquirir un nuevo producto o mejorar el que ya tiene.
Con esta implementación no solo se mejorará el proceso de venta, sino que además se reducirán
los tiempos de evaluación para adquirir una nueva línea móvil. También habrá una reducción
significativa en los tiempos de atención por cliente y se espera que de igual manera haya un
incremento en las ventas por este canal.
Para lograr esto, se ha diseñado una arquitectura que nos permita utilizar los mismos servicios web
y las mismas tablas que intervienen en una Alta Prepago que es realizada en un centro de atención
al cliente. Por otra parte, al tratarse de un proyecto de desarrollo se ha optado por utilizar el marco
de trabajo SCRUM.
Con el fin de determinar si se lograron los objetivos planteados, al final de este proyecto se
realizará una medición de los tiempos de atención del proceso de venta actual y del nuevo
proceso de venta.
9
CAPITULO I
ASPECTOS GENERALES
1.1. Definición del Problema
1.1.1. Descripción del Problema:
Durante el 2018, las empresas operadoras de telefonía móvil han realizado diversas campañas de
marketing para impulsar las ventas de sus productos o servicios, pero no han prestado demasiado
interés en la forma en cómo realizan sus ventas. Si nos situamos en el control del mercado actual
que tiene cada operador respecto a líneas móviles obtenemos la siguiente distribución:
Figura N° 1 – Distribución de mercado de telefonía móvil 2018
Fuente: Boletín Osiptel 2018
De la figura N° 1, podemos observar que la empresa de telecomunicaciones, objeto de este
proyecto, ocupa el segundo lugar en la distribución de líneas móviles. Ante esto, se ha observado
una oportunidad de mejora que puede ayudar a tener un mayor control dentro del mercado y
aumentar los ingresos de dicha empresa.
A diario miles de usuarios se acercan a los Centros de Atención al Cliente para adquirir una nueva
línea movil, sabemos que el proceso actual para realizar estas ventas no es el más óptimo, la
venta es presencial, se utilizan hasta 3 aplicativos web para concretar una venta y se sigue el
siguiente flujo:
1. Cliente ingresa al centro de atención y espera en la fila de atención.
2. Cliente llega al primer módulo de atención y entrega su DNI.
3. Asesor de servicios valida datos del cliente y le entrega un ticket con número de atención.
4. Cliente espera ser llamado por su número de atención.
10
5. Un segundo Asesor de servicios llama al cliente por su número de atención.
6. Cliente realiza su consulta al Asesor de servicios.
7. Asesor de servicios valida estado actual del cliente en su sistema y obtiene información para
responder consulta al cliente.
8. Cliente recibe información sobre su consulta y decide adquirir una nueva línea Prepago.
9. Asesor utiliza un segundo aplicativo web para obtener un SIMCARD disponible y un equipo.
10. Asesor procede a asociar el SIMCARD con el equipo y realiza la activación de la línea Prepago.
11. Asesor utiliza un tercer aplicativo y le indica al cliente el monto que debe pagar por adquirir
nueva línea Prepago.
12. Cliente realiza el pago y firma contrato de su nueva línea Prepago.
13. Cliente se retira del Centro de Atención al Cliente.
Figura N° 2 – Flujo de atención presencial en un CAC
Elaboración Propia
El tiempo promedio de atención para cada cliente es de 15 minutos, lo cual es demasiado tiempo utilizado
en un solo cliente cuando la demanda diaria es alta. Por otra parte, se ha observado que los Distribuidores
Autorizados no tienen demasiada venta en Altas de líneas Prepago, a pesar de que cuentan con el mismo
flujo que se realiza en un CAC. Es debido a esto que surge la necesidad de implementar una aplicación
móvil que mejore el proceso de ventas actual. El presente proyecto pone a disposición de los clientes un
nuevo canal de venta, reduciendo la afluencia en los Centros de Atención al Cliente y aumento los ingresos
de ventas de los Distribuidores Autorizados.
11
De lo mencionado anteriormente podemos desprender las causas y efectos que existen dentro de esta
situación:
POCAS VENTAS EN LÍNEAS MÓVILES DEBIDO A TIEMPOS
ELEVADOS EN ATENCIÓN AL CLIENTE
CAUSAS
EFECTOS
 Tiempos elevados de  Perdida de ventas por las
atención al realizar una
demoras en la atención.
operación de venta.
 Tiempos
muertos  Reducción de ingresos en
generados
en
las
ventas respecto a las Altas
atenciones debido al flujo
Prepago.
de venta actual.
 Mala organización para la  Afluencia innecesaria de
atención de clientes.
clientes en los Centros de
Atención.
Tabla N°1 – Tabla de Causa/Efecto
Elaboración Propio
1.1.2. Formulación del Problema
¿En qué medida la implementación de una aplicación móvil mejorará los tiempos de atención al
cliente y los ingresos en ventas?
1.2. Definición de objetivos
1.2.1. Objetivo general
El objetivo general de este proyecto es aumentar los ingresos en ventas a través de la
implementación de una aplicación móvil.
12
1.2.2. Objetivos específicos
 Reducir en un 20% el tiempo de evaluación de una venta realizada en un Centro de Atención
al Cliente: Dentro de los Centros de Atención al Cliente se tienen alrededor de 30 asesores de
servicios atendiendo cada uno a un cliente por aproximadamente 15 minutos, se espera que con
el uso de la App móvil dentro de un DAC un solo vendedor pueda atender entre 4 o 5 clientes
dentro de los primeros 15 minutos.
Figura N° 3 – Escenario Objetivo 1
Elaboración Propia
 Aumentar en un 5% mensual y constante los ingresos a través de este nuevo canal de ventas:
Mejorar los tiempos de atención traerá como resultado que los vendedores sean mucho más
productivos y esto hará que los clientes prefieran este flujo de venta por encima de otros.
Figura N° 4 – Escenario Objetivo 2
Elaboración Propia
13

Disminuir en un 20% la afluencia innecesaria de clientes en los centros de atención:
Un cliente desiste de adquirir un producto por la afluencia que observa en los centros
de atención al cliente y se lleva una sensación de mala atención. Como ya hemos
indicado el uso de la App móvil de ventas mejorará los tiempos de atención para los
productos de altas nuevas Prepago, dejando que la atención presencial sea para casos
exclusivos de soporte a equipos móviles u otras consultas que requieran del apoyo de
un asesor.
Figura N° 5 – Escenario Objetivo 3
Elaboración Propia
1.3. Alcances y limitaciones
1.3.1. Alcance
Este proyecto busca mejorar el proceso de ventas de líneas móviles Prepago que existe actualmente
a través de la implementación de una aplicación móvil que será de uso exclusivo para los
distribuidores autorizados de la empresa Operadora y que tendrá como alcance de uso todos los
departamentos del Perú. Además de ello, trabajará bajo sistema operativo Android y tendrá como
lenguaje de programación JAVA.
La arquitectura estará conformada por servidores Linux que interactuaran con Servicios Web
internos y externos (RENIEC). Finalmente, la aplicación móvil podrá intercambiar datos con otras
aplicaciones web propias de la empresa Operadora y como resultado final generará registros en
una base de datos, desde donde podremos evaluar los resultados de esta implementación.
Esta aplicación móvil realizará operaciones de venta para adquirir líneas Prepago. Además de todo
lo mencionado anteriormente deberá cumplir con los siguientes requisitos:

Garantizar la total seguridad de la información proporcionada por cada cliente.
14

Cada venta hecha a través de la aplicación móvil deberá finalizar con un registro en Base
de datos que nos permita controlar las transacciones que se realizan a través de este canal.

Solo aquellos vendedores que hayan sido registrados previamente por cada Distribuidor
Autorizado en sus sistemas podrán realizar las operaciones de venta a través de la
aplicación móvil.

El proceso de venta deberá realizarse en máximo 4 pasos (Esto se debe reflejar en la
Interfaz).

Este proyecto no deberá superar el monto de S/. 100,000.00 de inversión.

La venta se cancela si al realizar la validación biométrica se obtiene como respuesta del
servicio de RENIEC que el cliente no se encuentra apto para adquirir una nueva línea.
1.3.2. Limitaciones

Carencia de antecedentes sobre investigaciones referentes al desarrollo de aplicaciones
móviles como herramienta para mejorar el proceso de venta.

Falta de acceso al código fuente de la App Móvil y JAR's involucrados en el desarrollo.

Falta de ambiente de pruebas para realizar operaciones por la App Móvil

La aplicación no contará con la opción de pago a través de tarjetas de débito o crédito, el
único medio de pago será el efectivo.

Los sistemas operativos móviles como iOs y Windows Phone no podrán utilizar esta
aplicación, de momento solo es para Android versión 4.4 KitKat y superiores.

Para poder realizar operaciones a través de la aplicación se deberá contar con una conexión
a internet.

El consumo de la batería por usar esta aplicación será del 50% por cada 4 horas.
1.4. Justificación
Mejorar el proceso de venta es el objetivo principal de esta investigación, es por ello que, es
necesario implementar una aplicación móvil que rediseñe complemente el flujo de ventas actual.
Esta solución tecnológica además de mejorar el proceso de ventas disminuye las fallas que podrían
existir en las validaciones de datos personales entre aplicaciones web y reduce los tiempos de
evaluación que ahora serian ejecutadas directamente por una sola aplicación. Existe una
justificación práctica a causa del uso de la aplicación móvil y se da principalmente en la interacción
entre el cliente y el vendedor del DAC que utiliza la aplicación. Las principales ventajas son:

El proceso de venta a través de la aplicación es mucho más rápido en comparación a una
venta presencial que se realiza en un CAC, esto debido al uso interno de servicios web
sincronizados que realizan las validaciones en cuestión de segundos.

La aplicación movil interconectará 3 aplicativos: Un aplicativo de consulta de clientes,
un aplicativo de activaciones y una plataforma de provisiones (SIAC, SISACT, SIXPEL).
15

La empresa operadora para quien se desarrolla esta aplicación móvil viene trabajando
con el uso de comandos SOAP (Simple Object Access Protocool) y debido a eso la
aplicación movil en desarrollo trabajará bajo los mismos comandos.

El proceso generaría ahorros significativos en cuanto a recursos, puesto que no sería
necesario tener un equipo de asesores como en un centro de atención al cliente sino
una cantidad mínima de vendedores puestos en cada distribuidor autorizado.

El proceso garantiza transparencia ya que el cliente podrá ver al mismo tiempo que el
vendedor las validaciones que se realizan al efectuar su alta Prepago.
16
CAPITULO II
FUNDAMENTO TEÓRICO
2.1.
Antecedentes
2.1.1. Nacionales
Tanaka, Ricardo (2016): Ingeniero de Software de la Universidad Nacional Mayor de
San Marcos en su tesis “Sistema de gestión de fuerza de ventas web y móvil, utilizando
estilo arquitectónico REST, Metodología SCRUM y Geolocalización” nos indica que, en
base a la alta competitividad que existe actualmente entre las empresas, la reducción
de “tiempos vacíos” dentro del flujo de ventas aumenta enormemente la productividad
del vendedor y lo que se percibe como ingresos.
Este fragmento nos describe que el uso de las aplicaciones móviles dentro de los flujos
de ventas ayuda significativamente tanto al vendedor como a quienes supervisan las
ventas. Para nuestra propuesta esta información ha sido valiosa debido a que uno de
nuestros objetivos es reducir la afluencia en los centros de atención al cliente y esta
tesis nos indica de que no solo fue de gran en la reducción de tiempos sino que además
mejoró la productividad del equipo de venta. Por otro lado, este informe también ha
sido de gran ayuda si lo vemos desde un punto de vista metodológico, debido a que
también se ha empleado SCRUM como marco de trabajo.
Casaverde, Joel y Loayza, Manuel (2005): Ingenieros de Sistemas de la Universidad
Nacional de Ingeniería de Perú, autores de la tesis “Solución móvil de pagos en línea
para un sistema de ventas por Delivery usando Smartphones y JAVA” hacen especial
énfasis sobre la importancia que tiene el uso de las tecnologías móviles dentro del
mundo de ventas indicando con justa razón que esta es una ventaja competitiva para
todas las empresas actuales y que además genera una respuesta positiva por parte de
los clientes.
Uno de los objetivos de nuestro proyecto es hacer que los clientes que usualmente se
acercan a un centro de atención al cliente opten por este nuevo flujo de venta a través
de los distribuidores autorizados que son mucho más cercanos al público, si esto resulta
se pueden abrir nuevas oportunidades de negocio, replicando lo conseguido con otros
productos y servicios que se irán desarrollando e implementando en el tiempo. Este
proyecto fue un gran aporte a toda la comunidad para el tiempo en que fue
desarrollado. Al día de hoy, la gran mayoría de empresas tienen el servicio de pago con
tarjeta.
17
2.1.2. Internacionales
Reyes Mora, Iliana (2002): Alumna del Instituto Superior Tecnológico de Monterrey en
su tesis “Las aplicaciones móviles y su impacto en la creación de procesos de valor para
una empresa mexicana” señala que, el conocimiento y la experiencia que adquiere un
tomador de decisiones sobre factores que influyen en la eficiencia de un flujo de venta
es resultado directo de la introducción de una aplicación móvil.
Esto quiere decir que una la implementación de una aplicación móvil ayudaría a
identificar aquellas actividades que deben potenciarse y que generan valor a la
empresa. El uso de una aplicación móvil de ventas nos lleva a descubrir nuevas
posibilidades de mejora, nos da una mayor visibilidad acerca de lo que el cliente
realmente desea y esto nos permite mejorar la toma de decisiones, evaluando la salida
de nuevos productos antes de ser lanzados a producción.
2.2.
Marco Teórico
SCRUM
Según “La Guía Definitiva de SCRUM”, Scrum es un marco de trabajo de procesos que ha sido usado
para gestionar el desarrollo de productos complejos desde principios de los años 90. Scrum no es
un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro
del cual se pueden emplear varios procesos y técnicas. Scrum muestra la eficacia relativa de las
prácticas de gestión de producto y las prácticas de desarrollo de modo que podamos mejorar. El
marco de trabajo Scrum consiste en los Equipos Scrum y sus roles, eventos, artefactos y reglas
asociadas. Cada componente dentro del marco de trabajo sirve a un propósito específico y es
esencial para el éxito de Scrum y para su uso. Las reglas de Scrum relacionan los eventos, roles y
artefactos, gobernando las relaciones e interacciones entre ellos. (Scrumguides.org, 2013).
El Equipo Scrum
Este equipo se encuentra conformado por un Product Owner (Dueño de Producto), un
Development Team (Equipo de Desarrollo) y un Scrum Master (Facilitador). Estos equipos siempre
son autoorganizados y con capacidad de realizar varias tareas a la vez. Cada uno elige la forma en
como desea llevar a cabo su trabajo y no son dirigidos por personas externas al equipo. El modelo
de equipo en Scrum está enfocado en optimizar la productividad, flexibilidad y creatividad.
Scrum Master
Es el responsable de asegurar que el marco de trabajo SCRUM se entienda y respete. Cada Scrum
Master se asegura de que su equipo trabaje de acuerdo a la teoría Scrum. El Scrum Master es un
líder que está al servicio constante del equipo Scrum. El Scrum Master ayuda a las personas externas
a entender qué interacciones con el equipo pueden ser útiles y cuáles no.
18
Product Owner
Dentro del marco SCRUM, el Product Owner es la persona responsable de incrementar el valor del
producto en el que trabaja el Development Team. Es fundamental su participación si se quiere
asegurar que el resultado del producto sea exitoso.
Development Team
Básicamente es el conjunto de personas con conocimientos y habilidades particulares que en
conjunto trabajan para el desarrollo del producto del proyecto.
Eventos de Scrum
También llamados bloques de tiempo o “time-boxes” sirven para minimizar la necesidad de
reuniones no definidas.
El Sprint
Es un bloque de tiempo definido de mínimo una semana y máximo un mes de duración, en donde
se produce el incremento del producto. Una vez que un Sprint empieza su tiempo no puede ser
modificado.
Planificación de Sprint (Sprint Planning)
Son todas aquellas actividades que se realizaran durante cada Sprint. Se desarrolla mediante el
trabajo en conjunto de todo el equipo.
Scrum Diario (Daily Scrum)
Consiste en una breve reunión de 15 minutos para que el equipo de Desarrollo corrija los errores
presentados y crea un plan para las siguientes 24 horas. Se realiza a la misma hora y en el mismo
lugar todos los días para reducir la complejidad.
Revisión de Sprint (Sprint Review)
Al final del Sprint se lleva a cabo una reunión informal para evaluar el Incremento del producto y
adaptar la lista de producto si fuese necesario.
Retrospectiva de Sprint (Sprint Retrospective)
Es una oportunidad para el equipo de corregir los errores encontrados y de crear un plan de mejoras
para el siguiente Sprint. La Retrospectiva de Sprint tiene lugar después de la Revisión de Sprint y
antes de la siguiente Planificación de Sprint. Se trata de una reunión restringida a un bloque de
tiempo de tres horas para Sprint de un mes.
Increment Product
Es la suma de elementos de la lista del producto que son terminados durante un sprint y el valor de
los incrementos de todos los sprints antecesores. Al final de un sprint el nuevo Incremento debe
estar “Terminado”, esto significa que se encuentra en condiciones de ser utilizado y que cumple
totalmente la definición de “Terminado” del equipo.
19
Figura N° 6 - Esquema de trabajo SCRUM
Elaboración Propia
Método de Estimación Moscow
Se le denomina así a la técnica de priorización de requerimientos que tiene como principio que,
aunque todos los requisitos de un proyecto se consideren importantes es fundamental destacar
aquellos que permiten darle un mayor valor al proyecto y enfocar los trabajos de manera más
eficiente.
Lo que diferencia este método de otras técnicas tradicionales que califican los requisitos como
prioridad alta, media o baja es que, en este caso el impacto y la escala de valores utilizados tiene
un significado que solo el usuario responsable conoce. Es así que tenemos la siguiente escala:
M (Must /Debe estar): Requisito que tiene que estar implementado en la versión final del producto
para que la misma pueda ser considerada un éxito.
S (Should / Debería estar): Requisito de alta prioridad que en la medida de lo posible debería ser
incluido en la solución final, pero que llegado el momento y si fuera necesario, podría ser
prescindible si hubiera alguna causa que lo justificara.
C (Could / Podría estar): Requisito deseable pero no necesario, se implementaría si hubiera
posibilidades presupuestarias y temporales.
W (Won’t / No necesario): Hace referencia a requisitos que están descartados de momento pero
que en un futuro podrían ser tenidos de nuevo en cuenta y ser reclasificados en una de las
categorías anteriores.
Esta clasificación puede ser modificada durante el proceso de desarrollo y definirse, en el caso de
desarrollos iterativos incrementales, prioridades a nivel de iteración.
20
Identificación Biométrica
Este proceso consiste en utilizar un lector electrónico que escanea la huella digital del cliente y
busca dicha huella dentro de la base de datos de la RENIEC y la compara, logrando así que la misma
persona que puso la huella sea la misma persona que está realizando la adquisición de la línea.
2.3. Marco metodológico:
El marco de trabajo con el que se va a desarrollar este proyecto es SCRUM. Sin embargo, antes de
haber elegido este marco de trabajo comparamos y evaluamos otras opciones, una de estas fue el
modelo KANBAN. A continuación, mostraremos las similitudes y diferencias que fueron
fundamentales para tomar la decisión y elegir SCRUM como marco de trabajo para este proyecto:
SCRUM
KANBAN
Define roles concretos para cada
miembro.
Se pueden definir roles para
cada miembro o no.
Limpia su tablero
DIFERENCIAS iteración durante el desarrollo
del proyecto.
Utiliza un único tablero
durante el desarrollo de todo
el proyecto.
Promueve el compromiso dentro
del equipo por lo que es
altamente recomendado en
proyectos de desarrollo.
Ayuda a eliminar los cuellos de
botella, por ello es mejor
aplicado a proyectos de
mantenimiento.
en cada
Ambos son modelos agiles.
SIMILITUDES
Se ajustan al objetivo y proponen escenarios de mejora continua durante
el desarrollo del proyecto.
Ambos modelos son visuales y por ello facilitan la transparencia y
permiten detectar errores de forma rápida.
Fomentan el trabajo en equipo y la organización.
Tabla N° 2 – Tabla Comparativa SCRUM vs KANBAN
Elaboración Propia
21
Fase de Iniciación
Actividades
SCRUM
Realizar la visión
del proyecto:
Aplicación Móvil
para mejorar el
proceso de venta
Definir roles y
formar el equipo
Scrum
Elaborar el
listado de
requerimientos y
cronograma de
actividades
Duración del Proyecto: 99 Días
Fase de
Fase de
Fase de Revisión
Planificación y
Implementación
y Retrospectiva
Estimación
Actividades
Actividades
Actividades
SCRUM
SCRUM
SCRUM
Sprint Planning
Elaboración de
historias de
usuario
Estimación
Moscow
Elaborar el
Product Backlog
Elaborar Matriz
de Riesgos
Definir Alcance
del Proyecto
Definir los
criterios de
aceptación para
la fase de
Lanzamiento
Entregables
Visión del
Proyecto
Listado de
Requerimientos y
creación del
equipo SCRUM
Product Backlog
Diseño de tablas y
BD’s
Desarrollo de la
Aplicación
Pruebas de
Funcionalidad
Priorización de
historias de
usuario
Daily Scrum
(15 min.)
Entregables
Entregables
Sprint Backlog
Diagrama de
Arquitectura de
la Aplicación
Listado de
Historias de
Usuario
Fase de
Lanzamiento
Actividades
SCRUM
Sprint Review
Sprint
Retrospective
Pruebas QA
Registrar las
buenas practicas
Demostración del
Funcionamiento
de la Aplicación
antes de salir a
Producción
Elaboración de
Documento para
Pase a
Producción
Registrar las
lecciones
aprendidas
Registrar las
oportunidades de
mejora
Actualizar
Product Backlog
Refinamiento del
Sprint
Entregables
Entregables
Prototipo
Aplicación Móvil
Product
Increment
Principales tablas
que intervienen
en el
funcionamiento
de la Aplicación
Cronograma de
Actividades del
Proyecto
Tabla N° 3 - Desarrollo de Fases de SCRUM
Elaboración Propia
22
2.4. Marco conceptual
Aplicación Móvil
Una aplicación móvil, aplicación o simplemente app, es una aplicación informática diseñada para
ser ejecutada en smartphones, tablets u otros dispositivos móviles. Estas aplicaciones permiten al
usuario efectuar un conjunto de tareas de cualquier tipo (profesional, educativas, de acceso a
servicios, etc.), facilitando las gestiones o actividades a desarrollar.
Servicio Web
Un Servicio Web o Web Service es una tecnología que utiliza un conjunto de protocolos y
estándares que sirven para intercambiar datos entre aplicaciones (HTTP).
Android
Es un sistema operativo móvil desarrollado por Google, basado en Kernel de Linux y otros software
de código abierto.
Servidor
Un servidor es una aplicación en ejecución capaz de atender las peticiones de un cliente y
devolverle una respuesta en concordancia.
Base de Datos
En informática, se denomina Base de datos al conjunto de datos pertenecientes a un mismo
contexto y almacenados sistemáticamente para su posterior uso. Actualmente, existen programas
denominados sistemas gestores de bases de datos, abreviado SGBD (del inglés Database
Management System o DBMS), que permiten almacenar y posteriormente acceder a los datos de
forma rápida y estructurada.
Alta Prepago
Venta nueva de un plan comercial de telefonía móvil que ofrece una empresa de
Telecomunicaciones.
Centro de Atención al Cliente
Son establecimientos proporcionados por la empresa operadora con el fin de relacionarse con los
clientes y anticiparse a la satisfacción de sus necesidades.
Distribuidor Autorizado
Un Distribuidor Autorizado es quien está autorizado a vender grandes cantidades de productos a
clientes comerciales en línea o en tiendas minoristas; esto es opuesto a un vendedor privado que
venderá solo algunos artículos a sus clientes.
ICCID
Identificador de la tarjeta del circuito integrado. Este número se encuentra grabado dentro del
SIMCARD y se utiliza para identificar a la misma por parte del operador.
IMSI
Identidad Internacional de Abonado Móvil, es el identificador de la línea o servicio. Este número
sirve para enrutar las llamadas. En otras palabras, los operadores miran este número y de ahí
pueden obtener el país o la red a la que pertenece.
IMEI
Identidad Internacional del Equipamiento Móvil, este valor identifica al equipo celular físicamente.
23
MSISDN
Con este número nos pueden identificar y es el número que nos asigna nuestro operador movil
para recordarnos.
Telecomunicaciones
Intercambio de información tratada a distancias considerables por medios electrónicos, pueden
ser de voz, datos o video.
SIMCARD
Chip desmontable que identifica un dispositivo movil dentro de una red celular.
CAC
Centro de Atención al Cliente de la empresa Operadora, establecimiento que se encuentra
principalmente en centros comerciales. Se dedica a la comercialización de equipos y líneas móviles,
además de brindar soporte técnico a los equipos que vende
DAC
Distribuidor Autorizado de la empresa Operadora, establecimiento que se encuentra
principalmente en avenidas concurridas. Se dedica a la comercialización de equipos y líneas
móviles.
CAD
Cadena de Valor, stand que se encuentra dentro de las tiendas por departamento. Se dedica a la
comercialización de equipos y líneas móviles.
JAR
Es un tipo de archivo que permite ejecutar aplicaciones y herramientas escritas en JAVA.
REST
Es una interfaz capaz de conectar varios sistemas basados en el protocolo HTTP, sirve para obtener,
generar y realizar operaciones con datos que son devueltos en formatos como XML o JSON.
IDE
Entorno de Desarrollo Integrado, es una aplicación que proporciona herramientas y servicios
integrales para facilitar al programador el desarrollo de software.
API
Es un conjunto de reglas y especificaciones que las aplicaciones pueden seguir para comunicarse
entre ellas, sirve como interfaz.
KANBAN
Es un método de administración de tareas y flujos de trabajo que se utiliza principalmente en
proyectos de desarrollo de software.
QA
Aseguramiento de la calidad, conjunto de actividades que se encuentran dentro de la etapa de
desarrollo de software para garantizar la calidad del producto final.
SoapUI
Herramienta web que se utiliza para la prueba de aplicaciones orientadas al uso de servicios web.
24
CAPITULO III
DESARROLLO DE LA SOLUCIÓN
3.1. FASE DE INICIACIÓN
3.1.1. Visión del Proyecto
Desarrollar un sistema que ofrezca a los clientes la posibilidad de adquirir líneas Prepago con la
misma transparencia y seguridad con la que se adquiere una línea de manera presencial. Esta
Aplicación Móvil será desarrollada bajo la metodología SCRUM, y será de uso exclusivo para los
vendedores de los distribuidores autorizados que la utilizaran como un nuevo flujo de ventas.
Listado de Requerimientos
Se define cuáles son los requerimientos bajo los cuales se debe empezar a desarrollar la aplicación.
Figura N° 7 – Lista de Requerimientos para el Desarrollo de la App Móvil
Elaboración Propia
3.1.2. Creación del equipo SCRUM y definición de roles
Una vez elegido el marco de referencia, se realiza una reunión donde se define el equipo de trabajo
para el desarrollo del proyecto. Para este proyecto se tiene la siguiente distribución:
25
Figura N° 8 – Elaboración de equipo SCRUM
Elaboración Propia
Asignación de Actividades – Equipo SCRUM
Rol
Función
Scrum Master




Arquitecto de
Aplicaciones
Móviles

Backend
Frontend
QA













Guiar al equipo en el marco SCRUM
Facilitar las reuniones SCRUM
Seguimiento del proyecto
Reportar avances del proyecto al negocio y
TI
Diseño de la arquitectura Lógica que tendrá
la aplicación móvil
Diseño de la arquitectura Física que tendrá
la aplicación móvil
Apoyo como analista de Solución.
Análisis Técnico
Ejecución del desarrollo
Atención de observaciones
Elaboración de documentos
Análisis Técnico
Ejecución del desarrollo
Atención de observaciones
Elaboración de documentos
Elaboración de documentos
Ejecución de pruebas
Gestión de pases a Producción
26
 Certificación de la solución
UX Designer
Programador
Android
Especialista en
Flujo Prepago




Diseño de experiencia de usuario
Diseño de interfaces para la APP
Desarrollo de interfaces del APP
Ejecución de pruebas funcionales
 Atención de consultas sobre flujo de
Activación Prepago
 Ejecución de Pruebas en Producción
Especialista en
Flujo de Ventas
 Atención de consultas sobre flujo de Ventas
Prepago
 Ejecución de Pruebas en Producción
Tabla N° 4 – Definición de roles del equipo SCRUM
Elaboración Propia
3.1.3. Product Backlog
Una vez que se definen los requerimientos y se arma el equipo SCRUM se realizan las entrevistas
con los usuarios interesados y se pasa a definir las épicas del proyecto. En este caso, nuestras épicas
de proyecto son 6 que a su vez están conformadas por 23 historias de usuarios y distribuidas de la
siguiente manera:
Modulo
ID Épica
Funcionalidad
Módulo de acceso a
los vendedores
E-01
Como usuario del sistema se debe validar que los
vendedores que utilicen la aplicación pertenezcan a
la empresa de telecomunicaciones.
Módulo de
seguridad de la
información
E-02
Como usuario del sistema quiero validar que los
clientes cuenten con registro en RENIEC.
Módulo del proceso
de venta
Módulo del proceso
de activación
Prepago
Módulo de
Transparencia de la
Aplicación
Módulo de diseño
de la aplicación
E-03
E-04
E-05
E-06
Como usuario del sistema quiero validar que el
SIMCARD que va a utilizarse este disponible para la
venta.
Como usuario del sistema quiero validar que la
aplicación realice correctamente la activación de la
línea.
Como usuario del sistema quiero ver en todo
momento los datos de la venta y activación de la
línea.
Como usuario del sistema quiero ver las interfaces
que tendrá la aplicación mientras se realiza cada
paso de la venta y activación de la línea.
Tabla N° 5 – Elaboración de Épicas del Proyecto
Elaboración Propia
27
Módulo
ID Historia de Usuario
Funcionalidad
ID Épica
HU-01
Identificar DNI
Vendedor
Identificar DAC
Vendedor
Verificar Versión
E-01
HU-02
Módulo de acceso a los
vendedores
HU-03
HU-04
HU-05
HU-06
HU-07
Módulo de seguridad de
HU-08
la información
Módulo del proceso de
venta
Módulo del proceso de
Verificar Huella
Vendedor
Aprobar Vendedor
Identificar Vendedor No
Encontrado
Identificar DNI Cliente
Verificar Cantidad de
HU-09
Verificar Tipo Producto
HU-10
Validar SIMCARD
HU-11
Validar IMEI
HU-12
Obtener Línea Prepago
HU-13
Asociar Línea Prepago
HU-14
Elegir Distrito
HU-15
Elegir Centro Poblado
HU-16
E-02
Líneas
E-03
Ingresar Correo
Electrónico
E-04
activación Prepago
HU-17
Módulo de
transparencia de la
aplicación
HU-18
Entregar Bono Prepago
HU-19
Mostrar Datos de Venta
HU-20
Mostrar Datos de
Activación Prepago
HU-21
Módulo de diseño de la
aplicación
Activar Línea Prepago
HU-22
HU-23
Diseñar Interfaz de
Venta
Diseñar Interfaz de
Activación de Línea
Diseñar Interfaz de
Acceso a la Aplicación
E-05
E-06
Tabla N° 6 – Listado General de Historias de Usuario
Elaboración Propia
28
3.1.4. Cronograma de Actividades del Proyecto:
Actividades
Aplicación Móvil de
Ventas
Fase de Iniciación
Duración
99 días
Inicio
02/01/2018
Fin
03/04/2018
05 días
02/01/2018
06/01/2018
Realizar la visión del
proyecto: App Móvil
para mejorar proceso
de venta
Definir roles y formar el
equipo SCRUM
Definición de la
arquitectura de
producto
Desarrollo de las épicas
del proyecto
Identificación y
evaluación de riesgos
Priorización y
Estimación de historias
de usuario
Definir el backlog
priorizado del producto
Sprint 1 – Módulo de
acceso a los
vendedores
FASE DE
PLANIFICACION Y
ESTIMACION
Sprint Planning
Creación de historias
de usuario
Estimación de historias
de usuario
FASE DE
IMPLEMENTACIÓN
Análisis y diseño de
base de datos
Desarrollo del producto
02 días
01/01/2018
03/01/2018
01 día
01/01/2018
02/01/2018
02 días
03/01/2018
05/01/2018
02 días
03/01/2018
05/01/2018
02 días
03/01/2018
05/01/2018
02 días
03/01/2018
05/01/2018
02 días
03/01/2018
05/01/2018
15 días
06/01/2018
16/01/2018
04 días
06/01/2018
10/01/2018
01 día
06/01/2018
07/01/2018
03 días
08/01/2018
10/01/2018
03 días
08/01/2018
10/01/2018
05 días
10/01/2018
16/01/2018
05 días
10/01/2018
15/01/2018
05 días
10/01/2018
15/01/2018
05 días
10/01/2018
15/01/2018
02 días
14/01/2018
16/01/2018
02 días
14/01/2018
16/01/2018
01 día
01 día
15/01/2018
15/01/2018
16/01/2018
16/01/2018
Daily Scrum
Pruebas de
funcionalidad
FASE DE REVISIÓN Y
RETROSPECTIVA
Sprint Review
Sprint Retrospective
29
Sprint 2 – Módulo de
seguridad de la
información
FASE DE
PLANIFICACION Y
ESTIMACION
Sprint Planning
Creación de historias
de usuario
Estimación de historias
de usuario
FASE DE
IMPLEMENTACION
Análisis y diseño de
base de datos
Desarrollo del producto
Daily Scrum
Pruebas de
funcionalidad
FASE DE REVISION Y
RETROSPECTIVA
Sprint Review
Sprint Retrospective
Sprint 3 – Módulo del
proceso de venta
FASE DE
PLANIFICACION Y
ESTIMACION
Sprint Planning
Creación de historias
de usuario
Estimación de historias
de usuario
FASE DE
IMPLEMENTACION
Análisis y diseño de
base de datos
Desarrollo del producto
Daily Scrum
Pruebas de
funcionalidad
FASE DE REVISION Y
RETROSPECTIVA
Sprint Review
Sprint Retrospective
Sprint 4 – Módulo del
proceso de activación
Prepago
15 días
16/01/2018
30/01/2018
04 días
16/01/2018
20/01/2018
01 día
16/01/2018
17/01/2018
03 días
17/01/2018
20/01/2018
03 días
17/01/2018
20/01/2018
05 días
20/01/2018
26/01/2018
05 días
20/01/2018
25/01/2018
05 días
05 días
20/01/2018
20/01/2018
25/01/2018
25/01/2018
02 días
24/01/2018
26/01/2018
02 días
28/01/2018
30/01/2018
01 día
01 día
15 días
28/01/2018
29/01/2018
01/02/2018
29/01/2018
30/01/2018
16/02/2018
04 días
01/02/2018
05/02/2018
01 día
01/02/2018
02/02/2018
03 días
02/02/2018
05/02/2018
03 días
02/02/2018
05/02/2018
05 días
05/02/2018
10/02/2018
05 días
05/02/2018
10/02/2018
05 días
05 días
05/02/2018
05/02/2018
10/02/2018
10/02/2018
02 días
08/02/2018
10/02/2018
02 días
10/02/2018
12/02/2018
01 día
01 día
15 días
10/02/2018
11/02/2018
16/02/2018
11/02/2018
12/02/2018
29/02/2018
30
FASE DE
PLANIFICACION Y
ESTIMACION
Sprint Planning
Creación de historias
de usuario
Estimación de historias
de usuario
FASE DE
IMPLEMENTACION
Análisis y diseño de
base de datos
Desarrollo del producto
Daily Scrum
Pruebas de
funcionalidad
FASE DE REVISION Y
RETROSPECTIVA
Sprint Review
Sprint Retrospective
Sprint 5 - Módulo de
transparencia de la
aplicación
FASE DE
PLANIFICACION Y
ESTIMACION
Sprint Planning
Creación de historias
de usuario
Estimación de historias
de usuario
FASE DE
IMPLEMENTACION
Análisis y diseño de
base de datos
Desarrollo del producto
Daily Scrum
Pruebas de
funcionalidad
FASE DE REVISION Y
RETROSPECTIVA
Sprint Review
Sprint Retrospective
Sprint 6 - Módulo de
diseño de la aplicación
FASE DE
PLANIFICACION Y
ESTIMACION
Sprint Planning
04 días
16/02/2018
20/02/2018
01 día
16/02/2018
17/02/2018
03 días
17/02/2018
20/02/2018
03 días
17/02/2018
20/02/2018
05 días
20/02/2018
26/02/2018
05 días
20/02/2018
26/02/2018
05 días
05 días
20/02/2018
20/02/2018
26/02/2018
26/02/2018
02 días
24/02/2018
26/02/2018
02 días
27/02/2018
29/02/2018
01 día
01 día
15 días
27/02/2018
28/02/2018
01/03/2018
28/02/2018
29/02/2018
15/03/2018
04 días
01/03/2018
04/03/2018
01 día
01/03/2018
02/03/2018
03 días
02/03/2018
04/03/2018
03 días
02/03/2018
04/03/2018
05 días
05/03/2018
11/03/2018
05 días
05/03/2018
11/03/2018
05 días
05 días
05/03/2018
05/03/2018
11/03/2018
11/03/2018
02 días
09/03/2018
11/03/2018
02 días
12/03/2018
15/03/2018
01 día
01 día
15 días
12/03/2018
14/03/2018
16/03/2018
13/03/2018
15/03/2018
30/03/2019
04 días
16/03/2018
21/03/2018
01 día
16/03/2018
17/03/2018
31
Creación de historias
de usuario
Estimación de historias
de usuario
FASE DE
IMPLEMENTACION
Análisis y diseño de
base de datos
Desarrollo del producto
Daily Scrum
Pruebas de
funcionalidad
FASE DE REVISION Y
RETROSPECTIVA
Sprint Review
Sprint Retrospective
Fase de Lanzamiento
Registrar las buenas
practicas
Refinamiento del Sprint
03 días
18/03/2018
21/03/2018
03 días
18/03/2018
21/03/2018
05 días
21/03/2018
26/03/2018
05 días
21/03/2018
26/03/2018
05 días
05 días
21/03/2018
21/03/2018
26/03/2018
26/03/2018
02 días
24/03/2018
26/03/2018
02 días
26/03/2018
28/03/2018
01 día
01 día
04 días
02 dias
26/03/2018
27/03/2018
30/03/2018
30/03/2018
27/03/2018
28/03/2018
02/04/2018
01/04/2018
02 dias
01/04/2018
02/04/2018
Tabla N° 7 – Cronograma de Actividades
Elaboración Propia
3.1.5. Identificación y evaluación de riesgos.
ID
Riesgo
Riesgo
Categoría
R-01
Tamaño del producto
Subestimación del time boxing para los sprint
R-02
Tamaño del producto
Número de usuarios mayor a lo esperado
R-03
Tamaño del producto
R-04
Impacto en el negocio
El presupuesto establecido será superado
R-05
Impacto en el negocio
Retraso en el desarrollo del proyecto
R-06
Equipo
Rotación de personal, salida de un miembro del equipo
R-07
Equipo
Integrantes del equipo con un desempeño ineficiente
R-08
Equipo
R-09
Entorno de desarrollo
R-10
Tecnología
Cambios en los requerimientos, modificaciones del flujo
ya establecido de un proceso
El número del equipo no es suficiente para cumplir con
el proyecto
Carencias en el uso de las herramientas
La tecnología utilizada no alcanzará las expectativas
Tabla N° 8 – Elaboración de riesgos en el proyecto
Elaboración Propia
32
Probabilidad
Riesgo = Probabilidad x Impacto
0.90
0.05
0.09
0.18
0.36
0.72
0.70
0.04
0.07
0.14
0.28
0.56
0.50
0.03
0.05
0.10
0.20
0.40
0.30
0.02
0.03
0.06
0.12
0.24
0.10
0.01
0.01
0.02
0.04
0.08
0.05
0.10
0.20
0.40
0.80
Impacto
Tabla N° 9 – Tabla de Riesgos
Elaboración Propia
ID
Riesgo
R-01
R-02
Descripción del riesgo
Subestimación del time
boxing para los sprint
Número de usuario mayor a lo
esperado
Probabilidad
Impact
o
Valor
Clasificación
del riesgo
0.30
0.40
0.12
MODERADO
0.20
0.10
0.02
BAJO
0.80
0.60
0.48
ALTO
0.10
0.80
0.08
MODERADO
0.30
0.40
0.12
MODERADO
0.10
0.40
0.04
BAJO
0.10
0.40
0.04
BAJO
0.30
0.40
0.12
MODERADO
Cambios en los
R-03
requerimientos,
modificaciones del flujo ya
establecido de un proceso
R-04
R-05
R-06
R-07
El presupuesto establecido
será superado
Retraso en el desarrollo del
proyecto
Rotación de personal, salida
de un miembro del equipo
Integrantes del equipo con un
desempeño ineficiente
El número del equipo no es
R-08
suficiente para cumplir con el
proyecto
33
R-09
R-10
Carencias en el uso de las
herramientas
La tecnología utilizada no
alcanzará las expectativas
0.10
0.40
0.04
BAJO
0.05
0.70
0.035
BAJO
Tabla N° 10 – Tabla de Probabilidades
Elaboración Propia
3.2. FASE DE PLANIFICACIÓN Y ESTIMACIÓN
3.2.1. Sprint Backlog
Sprint Backlog 1: Cada sprint tiene una duración de 15 días. Durante el primer sprint del proyecto
se ha creído conveniente elaborar las historias de usuario que desarrollen el primer módulo de la
aplicación que compone las actividades relacionadas al acceso de la aplicación y la validación de
datos del vendedor.
ID Historia de Usuario
Funcionalidad
HU-01
Identificar DNI Vendedor
Puntos de Historia (PH)
5
HU-02
Identificar DAC Vendedor
5
HU-03
Verificar Versión
5
HU-04
Verificar Huella Vendedor
5
HU-05
Aprobar Vendedor
5
HU-06
Identificar Vendedor No
Encontrado
Tabla N° 11 – Estimación de Sprint 1
Elaboración Propia
5
Sprint Backlog 2: Durante el segundo sprint del proyecto y habiendo aprendido de los posibles
errores encontrados durante el primer sprint, se realizan todas las historias de usuario que ayuden
a la validación de datos del cliente que desea adquirir la nueva línea prepago. Entre estos la cantidad
de líneas que como máximo puede poseer un titular, esta es una validación sujeta a una normativa
de OSIPTEL.
ID Historia de Usuario
Funcionalidad
Puntos de Historia (PH)
HU-07
Identificar DNI Cliente
4
Verificar Cantidad de
4
HU-08
HU-09
Líneas
Verificar Tipo Producto
4
Tabla N° 12 – Estimación de Sprint 2
Elaboración Propia
34
Sprint Backlog 3: Nuestro tercer sprint hace referencia directa al proceso de venta de una línea
Prepago. Este sprint fue el más complejo de elaborar debido a que las historias de usuario
involucraban la intervención de distintos servicios web y bases de datos. Se tuvo que trabajar en
conjunto con un analista especialista en el proceso de venta Prepago.
ID Historia de Usuario
Funcionalidad
HU-10
Validar SIMCARD
Puntos de Historia (PH)
4
HU-11
Validar IMEI
4
HU-12
Obtener Línea Prepago
4
HU-13
Asociar Línea Prepago
4
Tabla N° 13 – Estimación de Sprint 3
Elaboración Propia
Sprint Backlog 4: Una vez concluido el proceso de venta, se da inicio a la activación de líneas
Prepago. Debido a ello, el cuarto sprint comprende todas las actividades relacionadas a la activación
de la línea Prepago y otros datos del titular. Asimismo, se solicita el correo electrónico del titular a
donde serán enviados los documentos correspondientes a la adquisición de una nueva línea
Prepago. Para este sprint se tuvo que trabajar directamente con un analista especialista en el flujo
de activación de líneas Prepago.
ID Historia de Usuario
Funcionalidad
HU-14
Elegir Distrito
Puntos de Historia (PH)
3
HU-15
Elegir Centro Poblado
3
HU-16
Ingresar Correo Electrónico
3
HU-17
Activar Línea Prepago
3
HU-18
Entregar Bono Prepago
3
Tabla N° 14 – Estimación de Sprint 4
Elaboración Propia
Sprint Backlog 5: El quinto sprint estará enfocado en la forma en cómo va a mostrarse la
información de la venta y activación de la línea. Teniendo en cuenta que al tratarse de una
aplicación móvil la información mostrada será la misma tanto para el vendedor como para el
cliente.
ID Historia de Usuario
Funcionalidad
HU-19
Mostrar datos de venta
Puntos de Historia
(PH)
2
HU-20
Mostrar datos de activación
2
Tabla N° 15 – Estimación de Sprint 5
Elaboración Propia
35
Sprint Backlog 6: Finalmante, el último sprint comprende todas las actividades relacionadas con el
diseño de la App en cuanto a dimensiones, imágenes, tipos de letra y colores que tendrán que
intervenir durante el paso a paso del uso de la aplicación.
ID Historia de Usuario
Funcionalidad
Puntos de Historia (PH)
HU-21
HU-22
HU-23
Diseñar interfaz de venta
Diseñar interfaz de activación
Diseñar interfaz de acceso a la
aplicación
2
2
2
Tabla N° 16 – Estimación de Sprint 6
Elaboración Propia
3.2.2. Elaboración de Historias de Usuario
Durante esta segunda fase, realizamos la creación de las 23 historias de usuario que van a
conformar los 6 módulos del Product Backlog.
Historia de usuario
Numero: HU-01
Usuario: Vendedor
Nombre de la historia: Identificar DNI vendedor
Prioridad en el negocio: M
Riesgo en desarrollo: Alto
Puntos estimados: 5
Dependencia: No
Descripción:
*El usuario abre la aplicación e inmediatamente debe ingresar su DNI.
*Este número de DNI es validado internamente sobre la tabla de vendedores registrados
para realizar este tipo de operaciones.
CRITERIOS DE ACEPTACION
1. Debe haber un recuadro que permita digitar los 8 números del DNI.
2. La validación del DNI se realizará automáticamente después de que se ingrese el
número.
3. No procede el ingreso a la aplicación si el vendedor no se encuentra registrado con
anterioridad en el listado de vendedores autorizados.
4. Considerar internamente la consulta a la tabla “PROV_OFICINAS” de la base de
datos SIXPROV DB.
Tabla N° 17 - Historia de Usuario HU01
Elaboración Propia
36
Historia de usuario
Numero: HU-02
Usuario: Vendedor
Nombre de la historia: Identificar DAC Vendedor
Prioridad en el negocio: M
Riesgo en desarrollo: Alto
Puntos estimados: 5
Dependencia: HU-01
Descripción:
*Al ingresar el DNI del vendedor, en paralelo se valida que el PDV al que pertenece se
encuentre activo.
CRITERIOS DE ACEPTACION
1. Esta validación debe ser transparente para el vendedor.
2. La validación del estado del PDV se realizará automáticamente después de que se
ingrese el número de DNI
3. No procede el ingreso a la aplicación si el DAC se encuentra en estado INOPERATIVO
(Esto quiere decir que no tiene permitido realizar ventas)
4. Considerar internamente la consulta a la tabla “Prov_Oficinas” de la base de datos
SIXPROVDB
Tabla N° 18 - Historia de Usuario HU02
Elaboración Propia
Historia de usuario
Numero: HU-03
Usuario: Vendedor
Nombre de la historia: Verificar Versión
Prioridad en el negocio: M
Riesgo en desarrollo: Alto
Puntos estimados: 5
Dependencia: HU-01, HU-02
Descripción:
* Aparecerá un mensaje PUSH en la interfaz de la aplicación indicando que para continuar es
necesario que el vendedor inserte la huella digital.
CRITERIOS DE ACEPTACION
1. En caso de que el vendedor seleccione la opción “NO” será retornado a la interfaz
inicial de la Aplicación Móvil.
2. En caso de que el vendedor seleccione la opción “SI” continuará con el proceso de
venta de la Aplicación Móvil.
Tabla N° 19 - Historia de Usuario HU03
Elaboración Propia
37
Historia de usuario
Numero: HU-04
Usuario: Vendedor
Nombre de la historia: Verificar huella vendedor
Prioridad en el negocio: M
Riesgo en desarrollo: Alto
Puntos estimados: 5
Dependencia: HU-01, HU-02 y HU-03
Descripción:
*Una vez que el DNI es validado se activa automáticamente el recuadro de validación
biométrica
* Introducimos el dedo índice derecho y se realiza la validación con RENIEC
CRITERIOS DE ACEPTACION
1. La validación debe ser transparente, sin mostrar información personal del vendedor.
2. Solo podrá ser reconocido el dedo índice derecho o izquierdo.
3. Al tercer intento fallido se cerrará la aplicación automáticamente.
Tabla N° 20 - Historia de Usuario HU04
Elaboración Propia
Historia de usuario
Numero: HU-05
Usuario: Operador
Nombre de la historia: Aprobar vendedor
Prioridad en el negocio: M
Riesgo en desarrollo: Alto
Puntos estimados: 5
Dependencia: HU-04
Descripción:
*Una vez que la huella es encontrada en la base de datos de RENIEC se da la conformidad de
que el vendedor es apto para realizar activaciones de líneas Prepago.
*La conformidad de la huella dará acceso al siguiente paso de inicio de venta Prepago.
CRITERIOS DE ACEPTACION
1. La conformidad debe ser transparente, sin mostrar información personal del vendedor.
Tabla N° 21 - Historia de Usuario HU05
Elaboración Propia
38
Historia de usuario
Numero: HU-06
Usuario: Operador
Nombre de la historia: Identificar Vendedor No Encontrado
Prioridad en el negocio: M
Riesgo en desarrollo: Alto
Puntos estimados: 5
Dependencia: HU-05
Descripción:
*En caso de que la huella del vendedor no sea encontrada en la base de datos de RENIEC o se
tenga alguna observación se denegará el acceso al vendedor y retornará hasta la interfaz
inicial.
CRITERIOS DE ACEPTACION
1. En caso de error, se mostrará el mensaje: “Al parecer el DNI ingresado no cuenta con
acceso”.
Tabla N° 22 - Historia de Usuario HU06
Elaboración Propia
Historia de usuario
Numero: HU-07
Usuario: Vendedor
Nombre de la historia: Identificar DNI Cliente
Prioridad en el negocio: M
Riesgo en desarrollo: Alto
Puntos estimados: 4
Dependencia: HU-06
Descripción:
*La aplicación solicitará que se ingrese DNI del cliente.
*Este número de DNI es validado internamente sobre la base de datos de RENIEC.
CRITERIOS DE ACEPTACION
1. Debe haber un recuadro que permita digitar los 8 números del DNI.
2. Si el cliente se encuentra observado por RENIEC se cancela la operación de venta.
3. Si el cliente se encuentra apto para venta se habilitará el “Check verde”.
Tabla N° 23 - Historia de Usuario HU07
Elaboración Propia
39
Historia de usuario
Numero: HU-08
Usuario: Vendedor
Nombre de la historia: Verificar Cantidad Líneas
Prioridad en el negocio: M
Riesgo en desarrollo: Alto
Puntos estimados: 4
Dependencia: HU-07
Descripción:
*La aplicación validará la cantidad de líneas que posee el cliente.
CRITERIOS DE ACEPTACION
1. Esta validación debe ser transparente para el vendedor.
2. De superar la cantidad de 10 líneas se cancelará el proceso de venta.
Tabla N° 24 - Historia de Usuario HU08
Elaboración Propia
Historia de usuario
Numero: HU-09
Usuario: Vendedor
Nombre de la historia: Verificar Tipo Producto
Prioridad en el negocio: M
Riesgo en desarrollo: Alto
Puntos estimados: 4
Dependencia: HU-08
Descripción:
*La aplicación dará al vendedor la opción de elegir el tipo de venta entre “CHIP” o “PACK”
CRITERIOS DE ACEPTACION
1. Esta validación debe ser transparente para el vendedor.
2. Si el cliente se encuentra observado por RENIEC se cancela la operación de venta.
Tabla N° 25 - Historia de Usuario HU09
Elaboración Propia
40
Historia de usuario
Numero: HU-10
Usuario: Vendedor
Nombre de la historia: Validar SIMCARD
Prioridad en el negocio: M
Riesgo en desarrollo: Medio
Puntos estimados: 4
Dependencia: HU-09
Descripción:
*El vendedor ingresa los 18 dígitos del SIMCARD que va a ser vendido.
*La aplicación móvil valida la disponibilidad del SIMCARD elegido para la venta.
CRITERIOS DE ACEPTACION
1. El SIMCARD debe visualizarse durante la interfaz de venta.
2. El SIMCARD debe consultar internamente las tablas de venta con el fin de garantizar
la disponibilidad de este.
Tabla N° 26 - Historia de Usuario HU10
Elaboración Propia
Historia de usuario
Numero: HU-11
Usuario: Vendedor
Nombre de la historia: Validar IMEI
Prioridad en el negocio: M
Riesgo en desarrollo: Medio
Puntos estimados: 4
Dependencia: HU-10
Descripción:
*El vendedor ingresa los 15 dígitos del IMEI que va a ser vendido.
*La aplicación móvil valida la disponibilidad del IMEI elegido para la venta.
CRITERIOS DE ACEPTACION
1.
El IMEI debe visualizarse durante la interfaz de venta.
2.
El IMEI es consultado internamente en las tablas de venta con el fin de garantizar la
disponibilidad de este.
Tabla N° 27 - Historia de Usuario HU11
Elaboración Propia
41
Historia de usuario
Numero: HU-12
Usuario: Vendedor
Nombre de la historia: Obtener línea Prepago
Prioridad en el negocio: M
Riesgo en desarrollo: Medio
Puntos estimados: 4
Dependencia: HU-11
Descripción:
*Una vez ingresado el SIMCARD y haber corroborado la disponibilidad, la aplicación
deberá obtener un número Prepago disponible.
CRITERIOS DE ACEPTACION
1. La obtención del número deberá ser transparente para la aplicación.
2. El número obtenido no debe contar con contrato activo de otro cliente.
Tabla N° 28 - Historia de Usuario HU12
Elaboración Propia
Historia de usuario
Numero: HU-13
Usuario: Vendedor
Nombre de la historia: Asociar línea Prepago
Prioridad en el negocio: M
Riesgo en desarrollo: Medio
Puntos estimados: 4
Dependencia: HU-12
Descripción:
*La aplicación deberá asociar el SIMCARD con la línea Prepago obtenida.
*Se realiza la creación de la línea y el SIMCARD en la plataforma UDB.
*Esta creación sirve para que la línea pueda realizar llamadas, recibir llamadas, enviar
SMS, etc.
CRITERIOS DE ACEPTACION
1. La asociación debe ser transparente para la aplicación, los datos no se muestran.
2. Tanto línea como SIMCARD no deben existir en UDB.
3. La línea es creada en estado PREACTIVO en UDB.
4. Posterior a la asociación la aplicación deberá continuar de manera automática con
el siguiente paso.
Tabla N° 29 - Historia de Usuario HU13
Elaboración Propia
42
Historia de usuario
Numero: HU-14
Usuario: Vendedor
Nombre de la historia: Elegir Distrito
Prioridad en el negocio: M
Riesgo en desarrollo: Medio
Puntos estimados: 3
Dependencia: HU-13
Descripción:
*La aplicación carga un formulario y se debe seleccionar el distrito del cliente.
CRITERIOS DE ACEPTACION
1. El campo distrito debe autocompletarse.
Tabla N° 30 - Historia de Usuario HU14
Elaboración Propia
Historia de usuario
Numero: HU-15
Usuario: Operador
Nombre de la historia: Elegir Centro Poblado
Prioridad en el negocio: M
Riesgo en desarrollo: Medio
Puntos estimados: 3
Dependencia: HU-14
Descripción:
*La aplicación carga un formulario y se debe seleccionar el centro poblado del cliente.
CRITERIOS DE ACEPTACION
1. El campo centro poblado debe autocompletarse.
Tabla N° 31 - Historia de Usuario HU15
Elaboración Propia
Historia de usuario
Numero: HU-16
Usuario: Operador
Nombre de la historia: Ingresar correo electrónico
Prioridad en el negocio: M
Riesgo en desarrollo: Medio
Puntos estimados: 3
Dependencia: HU-15
Descripción:
*La aplicación solicitará que se ingrese una dirección de correo electrónico donde se enviará
el contrato y la documentación correspondiente a la adquisición de una nueva línea Prepago.
CRITERIOS DE ACEPTACION
1. Este campo será obligatorio.
2. Este campo no podrá ser modificable.
Tabla N° 32 - Historia de Usuario HU16
Elaboración Propia
43
Historia de usuario
Numero: HU-17
Usuario: Vendedor
Nombre de la historia: Activar línea Prepago
Prioridad en el negocio: M
Riesgo en desarrollo: Medio
Puntos estimados: 3
Dependencia: HU-16
Descripción:
*Se realiza la creación de la línea en la plataforma IN Prepago, se crea en estado
PREACTIVO.
*Se realiza la configuración de la bolsa principal y bolsas promocionales (bonos).
CRITERIOS DE ACEPTACION
1. La activación de la línea se realizará de forma automática.
Tabla N° 33 - Historia de Usuario HU17
Elaboración Propia
Historia de usuario
Numero: HU-18
Usuario: Vendedor
Nombre de la historia: Entregar bono Prepago
Prioridad en el negocio: M
Riesgo en desarrollo: Medio
Puntos estimados: 3
Dependencia: HU-17
Descripción:
*Se realiza la entrega de saldo cero a la línea Prepago para completar la activación.
*Se realiza la entrega del bono inicial por alta nueva Prepago.
CRITERIOS DE ACEPTACION
1. La línea pasará de estado PREACTIVO a ACTIVO de manera interna.
2. La entrega de bono deberá realizarse inmediatamente después de realizar la
activación.
Tabla N° 34 - Historia de Usuario HU18
Elaboración Propia
44
Historia de usuario
Numero: HU-19
Usuario: Vendedor
Nombre de la historia: Mostrar datos de venta
Prioridad en el negocio: C
Riesgo en desarrollo: Media
Puntos estimados: 2
Dependencia: HU-18
Descripción:
Durante el proceso de venta, la aplicación deberá mostrar los datos propios de la venta.
CRITERIOS DE ACEPTACION
1. El número de SIMCARD deberá mostrarse durante el proceso de venta.
2. El número del DNI del vendedor debe mostrarse.
3. El número del DNI del cliente debe mostrarse.
4. El número de la línea del cliente debe mostrarse al final del proceso de venta.
Tabla N° 35 - Historia de Usuario HU19
Elaboración Propia
Historia de usuario
Numero: HU-20
Usuario: Vendedor
Nombre de la historia: Mostrar datos de Activación Prepago
Prioridad en el negocio: C
Riesgo en desarrollo: Media
Puntos estimados: 2
Dependencia: HU-19
Descripción:
*Durante el proceso de activación, la aplicación deberá mostrar los datos propios de la
activación Prepago.
CRITERIOS DE ACEPTACION
1. El número Prepago deberá mostrarse durante el proceso de activación.
2. El número de la línea del cliente debe mostrarse al final del proceso de activación.
Tabla N° 36 - Historia de Usuario HU20
Elaboración Propia
Historia de usuario
Numero: HU-21
Usuario: Vendedor
Nombre de la historia: Diseñar interfaz de venta
Prioridad en el negocio: C
Riesgo en desarrollo: Media
Puntos estimados: 2
Dependencia: NO
Descripción:
Elaborar el diseño y dimensiones que tendrá la aplicación móvil durante el proceso de venta.
CRITERIOS DE ACEPTACION
1. Los colores que deben predominar son: rojo, blanco y negro.
Tabla N° 37 - Historia de Usuario HU21
Elaboración Propia
45
Historia de usuario
Numero: HU-22
Usuario: Vendedor
Nombre de la historia: Diseñar interfaz de activación de línea.
Prioridad en el negocio: C
Riesgo en desarrollo: Media
Puntos estimados: 2
Dependencia: NO
Descripción:
*Elaborar el diseño y dimensiones que tendrá la aplicación móvil durante el proceso de
activación.
CRITERIOS DE ACEPTACION
1. Los colores que deben predominar son: rojo, blanco y negro.
Tabla N° 38 - Historia de Usuario HU22
Elaboración Propia
Historia de usuario
Numero: HU-23
Usuario: Vendedor
Nombre de la historia: Diseñar interfaz de acceso a la aplicación.
Prioridad en el negocio: C
Riesgo en desarrollo: Media
Puntos estimados: 21
Dependencia: NO
Descripción:
*Elaborar el diseño y dimensiones que tendrá la aplicación móvil durante el acceso a la
aplicación.
CRITERIOS DE ACEPTACION
1. Los colores que deben predominar son: rojo, blanco y negro.
Tabla N° 39 - Historia de Usuario HU23
Elaboración Propia
46
3.2.3. Estimación de historias de usuario
Nos apoyamos en el método de estimación Moscow para decidir cuáles son las historias de
usuario que deben ser priorizadas.
MoSCoW
Must have
Could have
Should have
Wont have
HU-01
HU-02
HU-03
HU-23
HU-04
HU-05
HU-06
Historias de usuario
HU-07
HU-19
HU-08
HU-09
HU-10
HU-21
HU-11
HU-12
HU-13
HU-14
HU-15
HU-16
HU-20
HU-22
HU-17
HU-18
Tabla N° 40 – Priorización de Historias de Usuario
Elaboración Propia
47
Asignamos puntos de historia a cada uno de nuestros 23 procesos, estos valores van del 01 al 05 y
están definidos de la siguiente manera:
ID Historia de Usuario
Funcionalidad
Puntos de Historia (PH)
HU-01
Identificar DNI Vendedor
5
HU-02
Identificar DAC Vendedor
5
HU-03
Verificar Versión
5
HU-04
Verificar Huella Vendedor
5
HU-05
Aprobar Vendedor
5
HU-06
Identificar Vendedor No
Encontrado
Identificar DNI Cliente
5
Verificar Cantidad de
4
HU-07
HU-08
4
Líneas
HU-09
Verificar Tipo Producto
4
HU-10
Validar SIMCARD
4
HU-11
Validar IMEI
4
HU-12
Obtener Línea Prepago
4
HU-13
Asociar Línea Prepago
4
HU-14
Elegir Distrito
3
HU-15
Elegir Centro Poblado
3
Ingresar Correo
3
HU-16
HU-17
Electrónico
3
Activar Línea Prepago
HU-18
Entregar Bono Prepago
3
HU-19
Mostrar Datos de Venta
2
HU-20
Mostrar Datos de
Activación Prepago
Diseñar Interfaz de Venta
2
HU-21
Diseñar Interfaz de
Activación de Línea
Diseñar Interfaz de
HU-23
Acceso a la Aplicación
Tabla N° 41 – Asignación de puntos de Historias de Usuario
Elaboración Propia
HU-22
2
2
2
48
Realizamos la suma de cada historia de usuario y obtenemos el resultado para las épicas del
proyecto.
ID Épica
E-01
E-02
E-03
E-04
E-05
E-06
Puntos de
historia (PH)
Funcionalidad
Como usuario del sistema se debe validar que los vendedores que
utilicen la aplicación pertenezcan a la empresa de telecomunicaciones.
Como usuario del sistema quiero validar que los clientes cuenten con
registro en RENIEC.
Como usuario del sistema quiero validar que el SIMCARD que va a
utilizarse este disponible para la venta.
Como usuario del sistema quiero validar que la aplicación realice
correctamente la activación de la línea.
Como usuario del sistema quiero ver en todo momento los datos de la
venta y activación de la línea.
Como usuario del sistema quiero ver las interfaces que tendrá la
aplicación mientras se realiza cada paso de la venta y activación de la
línea.
30
12
16
15
4
6
Tabla N° 42 – Tabla de puntos totales por épicas
Elaboración Propia
En base a los resultados obtenidos, definimos la prioridad de cada épica del proyecto y obtenemos
el Product Backlog Priorizado.
Modulo
Módulo de acceso a
los vendedores
Módulo de seguridad
de la información
Módulo del proceso
de venta
ID
Épica
E-01
E-02
E-03
Módulo del proceso
de activación Prepago
E-04
Módulo de
Transparencia de la
Aplicación
E-05
Módulo de diseño de
la aplicación
E-06
Funcionalidad
Como usuario del sistema se debe validar que los
vendedores que utilicen la aplicación
pertenezcan a la empresa de
telecomunicaciones.
Como usuario del sistema quiero validar que los
clientes cuenten con registro en RENIEC.
Como usuario del sistema quiero validar que el
SIMCARD que va a utilizarse este disponible para
la venta.
Como usuario del sistema quiero validar que la
aplicación realice correctamente la activación de
la línea.
Como usuario del sistema quiero ver en todo
momento los datos de la venta y activación de la
línea.
Como usuario del sistema quiero ver las
interfaces que tendrá la aplicación mientras se
realiza cada paso de la venta y activación de la
línea.
Tabla N° 43 – Tabla de Product Backlog Priorizado
Elaboración Propia
Estimación
(PH)
Prioridad
30
M
12
M
16
M
15
M
4
C
6
C
49
3.3. FASE DE IMPLEMENTACIÓN
3.3.1. Desarrollo de la Aplicación
La aplicación móvil de venta ha sido desarrollada para que la activación de la línea Prepago se
realice en solo 4 pasos luego de la identificación del vendedor. Estos pasos están conformados de
la siguiente manera:
PASO 0: LOGIN DE LA APLICACIÓN:
Para acceder a la aplicación móvil y realizar operaciones de venta, el
vendedor deberá digitar el número de su DNI y colocar su índice
izquierdo o derecho en el validador biométrico. Previamente el
Distribuidor Autorizado debe haber creado la cuenta de este vendedor.
 En esta pantalla se invoca de manera automática al siguiente
método PRS_DolMovil_v2.verificaVersionApp
(https://aplicacionmovildeventas.com.pe/PRS_DolMovil_v2/SRV_
DolMovil/Service/DolMovil_v2?wsdl)
 Digitamos el DNI del vendedor el cual debe estar empadronado
para iniciar sesión (DNI Ejemplo: 45512823), el cual realiza la
invocación a PRS_DolMovil_v2.consultarVendedor
(https://aplicacionmovildeventas.com.pe/PRS_DolMovil_v2/SRV_
DolMovil/Service/DolMovil_v2?wsdl)
Figura N° 9 – Login de la Aplicación
Elaboración Propia
En esta pantalla se invoca de manera automática al siguiente mensaje,
el cual nos indica por cual Login debe proseguir el vendedor.
Este mensaje es invocado en el Servicio de verificaVersion que fue
llamado al iniciar el APK y explicado en la imagen anterior.
En caso el vendedor seleccione “SI”, se deberá de realizar la validación
con huella, tal y como se indicó al inicio de este proyecto.
En caso el vendedor seleccione “NO”, se deberá mostrar la pantalla
inicial de la App Móvil.
Figura N° 10 – Login de la Aplicación_PopUP
Elaboración Propia
50
En caso el vendedor seleccione “SI”, saldría esta pantalla el cual
se invoca el siguiente método:
PRS_Identidad_v2.validarIdentidad
(https://aplicacionmovildeventas.com.pe/PRS_Identidad_2/SR
V_Identidad/Service/Exposition/PRS_Identidad_v2?wsdl)
Figura N° 11 – Login de la Aplicación_BM
Elaboración Propia
Este es el mensaje que aparecerá en la aplicación si el vendedor
no se encuentra registrado. Como consecuencia luego de dar
click en “OK” se regresará al inicio de la aplicación.
*Tener en cuenta que para que el vendedor pueda realizar las
operaciones de ventas, deberá ser registrado a través de otra
aplicación que no está considerada dentro del alcance del
proyecto
Figura N° 12 – Login de la Aplicación_ERROR
Elaboración Propia
51
PASO 1: INGRESAR DATOS DEL CLIENTE:
En esta pantalla, iniciamos el proceso de venta. Se ingresa el
número de DNI del cliente. Si el cliente es apto para realizarle una
venta aparecerá un “check verde” indicando la conformidad, caso
contrario aparecerá una “X”.
Al ingresar el DNI del Cliente, El aplicativo móvil realizará 3
validaciones:
1. Si el número de DNI ingresado es conforme y existe en RENIEC.
(https://aplicacionmovildeventas.com.pe/PRS_Identidad_2/SRV
_Identidad/Service/Exposition/PRS_Identidad_v2?wsdl)
2. Si el número de DNI tiene asociadas más de 10 líneas, para
este caso nos apoyaremos en el método
PRS_DolMovil_v2.cantidadLinea.(https://aplicacionmovildevent
as.com.pe/PRS_DolMovil_v2/SRV_DolMovil/Service/DolMovil_v
2?wsdl)
3. La longitud del DNI (8 números)
Figura N° 13 – Proceso de Venta_DatosDelCliente
Elaboración Propia
El siguiente recuadro nos permite elegir la modalidad de la
Venta, en este caso elegiremos “PREPAGO” y luego “Continuar”.
Figura N° 14 – Proceso de Venta_Modalidad
Elaboración Propia
52
PASO 2: ELEGIR TIPO DE PRODUCTO E INGRESAR NÚMEROS DE SERIE (ICCID/IMEI):
El siguiente paso en el proceso de venta es elegir el tipo de producto. Si es
CHIP o PACK, para este caso elegiremos CHIP e ingresaremos el número de
serie del CHIP (18 dígitos).
Este paso internamente realiza ciertas validaciones, como la disponibilidad
del CHIP, la configuración del CHIP en la RED del Operador Móvil, el uso de
la Tecnología 4G, etc.
Opción CHIP
Al ingresar el ICCID se invocará al PRS_BioMovilPrePost.validarICCID
(https://aplicacionmovildeventas.com.pe/PRS_BioMovilPrePost/SRV_BioM
ovilPrePost/Service/BioMovilPrePost?wsdl) indicando que el tipo de venta
es chip y que SÍ se debe reservar el material y si se quiere obtener el precio
de venta.
Al completar el ICCID se habilitara el botón “Continuar” para seguir con el
flujo.
Figura N° 15 – Proceso de Venta_TipoVenta
Elaboración Propia
Opción PACK
Al ingresar el ICCID se invocará al PRS_BioMovilPrePost.validarICCID
(https://aplicacionmovildeventas.com.pe/PRS_BioMovilPrePost/SRV_BioMovilPrePost/Service/BioMovilPrePost?wsdl)
indicando que el tipo de venta es chip y que SÍ se debe reservar el material y si se quiere obtener el precio de venta.
Al ingresar el IMEI se invocará al PRS_BioMovil_v2.validarIMEI
(https://aplicacionmovildeventas.com.pe/PRS_BioMovil_v2/SRV_BioMovil_v2/Service/Exposition/EXP_BioMovil_v2?wsdl)
indicando que el tipo de venta es chip y que SÍ se debe reservar el material y si se quiere obtener el precio de venta.
Al completar el PACK se habilitara el botón “Continuar” para seguir con el flujo.
Al ejecutar el botón “Continuar”, se ejecuta el PRS_DOLMovil.EjecutarPreactivacion
(https://aplicacionmovildeventas.com.pe/PRS_DolMovil_v2/SRV_DolMovil/Service/DolMovil_v2?wsdl) y prosigue con la
siguiente pantalla
Con esto, estaremos realizando la preactivación del CHIP en la plataforma de RED y asignando un número móvil Prepago.
Figura N° 16 – Tabla de Stock de Equipos Prepago
Elaboración Propia
53
PASO 3: CARGAR FORMULARIO
En la carga del formulario, se preseleccionan los campos
Distrito y Centro Poblado a partir de la información del
ubigeo obtenido en el login (Distrito y Centro Poblado)
El centro poblado es dependiente del Distrito, no se puede
elegir Centro Poblado sin elegir Distrito.
Se habilitara el botón continuar para proseguir con el flujo
de la Alta Prepago Móvil
Al habilitar el botón “Continuar”, se invoca al
PRS_Identidad.consultarMejorHuella.
(https://aplicacionmovildeventas.com.pe/PRS_Identidad/
SRV_Identidad/Service/Exposition/PRS_Identidad?wsdl) y
prosigue con la siguiente pantalla
Figura N° 17 - Configuración de Cobertura
Elaboración Propia
PASO 4: ACEPTAR CONTRATO DE ALTA NUEVA Y CONFIRMAR ACTIVACIÓN
El último paso para completar la venta Prepago requiere que el cliente
acepte los contratos establecidos por el Operador Móvil.
 Ingresa email del cliente y selecciona las casillas de aceptación de
contratos y validación de identidad.
 Al dar clic en el check se activa el lector de huellas.
 Al poner la huella digital se invoca a:

PRS_DOLMovil_v2.validarCliente.
(https://aplicacionmovildeventas.com.pe/PRS_DolMovil_v2
/SRV_DolMovil/Service/DolMovil_v2?wsdl)

PRS_DOLMovil_v2.procesaDOL.
(https://aplicacionmovildeventas.com.pe/PRS_DolMovil_v2
/SRV_DolMovil/Service/DolMovil_v2?wsdl)
 Iniciará el MDB
Con esto eso completará la activación y entrega del bono que le
corresponda a la línea móvil Prepago.
Figura N° 18 – Aceptar contratos
Elaboración Propia
54
PASO 5: CONFIRMACIÓN DE ALTA NUEVA PREPAGO
Esta pantalla solo nos muestra el resultado final de la
venta, que conlleva la activación de la línea y los datos
del cliente nuevo.
*El botón “VOLVER AL INICIO” nos permite volver a
realizar otra operación de venta (PASO 1).
Figura N° 19 – Confirmación de Alta Nueva
Elaboración Propia
3.3.2. Análisis y Diseño de Bases de Datos:
Las tablas que van a intervenir en el desarrollo de la aplicación son las siguientes:
PROV_OFICINAS: Esta tabla contiene todos los Distribuidores Autorizados para venta.
Figura N° 20 – Lista de Distribuidores Autorizados
Elaboración Propia
55
APP_LINEAS_DISPONIBLES: Esta tabla contiene todas las líneas disponibles para venta de Alta
Prepago.
DISPONIBLES:
ESTADO L (Antes de realizar la venta)
Figura N° 21 – Lista de números disponibles para venta
Elaboración Propia
UTILIZADOS:
ESTADO A (Después de realizar la venta)
Figura N° 22 – Lista de números utilizados para venta
Elaboración Propia
56
APP_PROVISION_TRANSACCIONES: Esta tabla contiene todas las provisiones por Alta Prepago.
PARA CHIP:
Figura N° 23 – Lista de Altas Prepago por Chip
Elaboración Propia
PARA PACK:
Figura N° 24 – Lista de Altas Prepago por Pack
Elaboración Propia
57
TABLA: EQUIPOS_DISPONIBLES
Esta tabla contiene todos los equipos disponibles para ventas Prepago
Figura N° 25 – Lista de equipos Prepago
Elaboración Propia
TABLA: APP_CENTROPOBLADO
Esta tabla contiene todas las ciudades del Perú dentro de sus 3 regiones y 24 departamentos.
Figura N° 26 – Lista de ciudades Prepago
Elaboración Propia
58
3.4. FASE DE REVISIÓN Y RETROSPECTIVA
3.4.1. Arquitectura de la Aplicación:
Como ya se ha indicado anteriormente la aplicación móvil será de uso exclusivo para los vendedores
autorizados de la empresa Operadora y el único producto que podrá ofrecer de momento es el alta
nueva de líneas Prepago.
Figura N° 27 – Arquitectura de la Aplicación de Ventas
Elaboración Propia
59
3.4.2. Pruebas con SoapUI
En esta fase del proyecto se realizaron pruebas con ayuda de la herramienta SoapUI a cada uno
de los servicios web que aparecen en la Figura N°6.
Ejemplo.
Petición de Request: Se envían los parámetros de entrada al Web Service para la prueba.
Figura N° 28 – Petición de request con SoapUI
Elaboración Propia
60
Petición de Response: El servicio web devuelve la información solicitada.
Figura N° 29 – Petición de response con SoapUI
Elaboración Propia
61
3.5. FASE DE LANZAMIENTO
3.5.1. Product Increment
Finalmente se envía el resultado de la aplicación a Producción, lo siguiente es una vista
resumen de la misma.
Figura N° 30 – Vista Resumida de la Aplicación Móvil de Ventas
Elaboración Propia
62
CAPITULO IV
RESULTADOS
En este capítulo se muestran los resultados obtenidos antes y después de que la aplicación móvil
de ventas entrará en funcionamiento. Además de ello se debe evidenciar que los objetivos
planteados en el primer capítulo han sido logrados y que la solución tecnológica funciona
correctamente. Para obtener esta información se han realizado consultas a base de datos y
elaborado cuadros estadísticos para un mejor entendimiento:
RESULTADO N° 1:
REDUCCIÓN DE TIEMPO EN LAS OPERACIONES DE VENTA DE LINEAS MÓVILES
DE 15 MINUTOS A 5 MINUTOS EN PROMEDIO.
ANTES
AHORA
El tiempo de venta presencial en un CAC
es de 15 minutos en promedio
(Considerando que los asesores de
servicios estén disponibles, de lo contrario
el tiempo aumenta).
El tiempo de venta de una línea móvil Prepago
a través de la Aplicación es de 5 minutos en
promedio. Se observa una reducción de
tiempo de atención de más del 30%.
El cliente al ingresar al CAC, antes de Con la Aplicación móvil no es necesario que el
solicitar una línea nueva debe presentar cliente generé un ticket de atención, lo que
su DNI y luego solicitar su ticket de reduce considerablemente el tiempo de
atención.
atención.
Una vez que el cliente es atendido por el
asesor este recibe información de manera
verbal acerca de la adquisición de su
nueva línea (Se le entregan documentos
que tiene que firmar).
Con la ayuda del validador biométrico y el
Servicio Web de RENIEC, el cliente solo ingresa
su huella digital y se genera un contrato virtual
con sus datos (No hay necesidad de firmar
documentos o imprimirlos).
Tabla N° 44 - Cuadro Comparativo del Resultado N° 1
Elaboración Propia
63
Cantidad de
clientes
atendidos por
hora
(10AM – 8PM)
Centro de
Atención al
Cliente (CAC
Mall Del Sur)
Aplicación Móvil
de Ventas (DAC )
10:00AM
(1 Hora)
4
…
…
07:00PM
(10 Horas)
Reducción de
tiempo (%)
40
>33%
12
…
120
Comentario
Con esto,
evidenciamos
que el primer
objetivo
específico de
reducir en un
20% el tiempo
de atención
fue superado
Tabla N° 45 – Resumen del Resultado N° 1
Elaboración Propia
Figura N° 31 – Cantidad diaria de clientes atendidos por hora
Elaboración Propia
64
RESULTADO N° 2:
AUMENTO DE INGRESOS A TRAVÉS DE LA APP MÓVIL POR ENCIMA DE OTROS CANALES
DE VENTA
ANTES
AHORA
Hasta hace unos meses solo había 3
canales de venta en donde un cliente podía
adquirir una nueva línea móvil:
- A través de un Centro de Atención
al Cliente
- A través de un Call Center
- A través de un Distribuidor
Autorizado
Con la implementación de la App Móvil de
ventas se observa que los clientes prefieren
esta opción por encima de las otras opciones
que existen para adquirir una nueva línea
Prepago.
El
cliente
tiene
que
acercarse
necesariamente
a
una
de
los
establecimientos que se mencionan líneas
arriba.
No es necesario que el cliente se acerqué,
siempre hay un vendedor que cuenta con la
App de ventas cerca de las avenidas más
concurridas de la capital.
Tabla N° 46 - Cuadro Comparativo del Resultado N° 2
Elaboración Propia
Monto mensual en soles (S/.) según canal de venta Junio 2018 a Noviembre 2018
45,000
40,000
35,000
30,000
25,000
20,000
15,000
10,000
5,000
0
jul-18
ago-18
sep-18
oct-18
nov-18
Centro de Atención al Cliente
Cadenas
Distribuidor Autorizado
App Móvil de Ventas
dic-18
Figura N° 32 – Ingresos en ventas según el tipo de canal de atención
Elaboración Propia
65
Canal de Venta
06/2018
07/2018
08/2018
09/2018
10/2018
11/2018
Monto
Total S/.
Centro de
Atención al
Cliente
Cadenas
22,000
24,200
(10%)
26,400
(10%)
29,040
(10%)
27,588
(-5%)
30,346
(10%)
159,574
Distribuidor
Autorizado
App Móvil de
Ventas
23,000
18,000
(20%)
31,000
(35%)
22,000
(10%)
25,000
(39%)
35,650
(15%)
24,200
(10%)
32,000
(30%)
32,000
(-10%)
26,620
(10%)
33,000
(4%)
33,000
(4%)
31,944
(20%)
34,000
(3%)
34,000
(4%)
39,930
(25%)
15,000
20,000
157,000
188,650
164,694
Comentario
Se muestra
un
incremento
de ingresos
constante
para el
nuevo flujo
de ventas
por App
Móvil
Tabla N° 48 – Resumen del Resultado N° 2
Elaboración Propia
RESULTADO N° 3:
SE REDUCE LA AFLUENCIA EN LOS CENTROS DE ATENCIÓN AL CLIENTE
ANTES
AHORA
Debido al tiempo que demora adquirir
una nueva línea en forma presencial, los
clientes preferían no acercarse a un
centro de atención al cliente, que
generalmente se encuentra en los centros
comerciales de todo el Perú.
Se
he
evidenciado
que
desde
la
implementación de la App Móvil los clientes
prefieren este nuevo flujo de venta que el flujo
convencional en donde deben acercarse
necesariamente a un centro de atención al
cliente.
El cliente al ingresar al CAC, antes de Con la Aplicación móvil no es necesario que el
solicitar una línea nueva debe presentar cliente generé un ticket de atención, lo que
su DNI y luego solicitar su ticket de reduce considerablemente el tiempo de
atención.
atención.
Tabla N° 47 - Cuadro Comparativo del Resultado N° 3
Elaboración Propia
66
Cantidad de clientes atendidos CAC Vs. App Móvil
Junio 2018 - Diciembre 2018
9000
8500
8000
8000
7000
7000
6000
6000
6000
5000
7000
6500
4500
4000
5500
5000
4000
3000
2000
1000
1000
0
jun-18
jul-18
ago-18
sep-18
Centro de Atención al Cliente
oct-18
nov-18
App Móvil de Ventas
Figura N° 33 – Cantidad mensual de clientes atendidos por canal de venta
Elaboración Propia
Canal de Venta
Junio
2018
Julio
2018
Agosto
2018
Septiembre
2018
Octubre
2018
Noviembre
2018
Centro de
Atención al Cliente
(CAC)
8000
6000
7000
6000
6500
5500
Distribuidor
Autorizado
(DAC)
1000
4000
4500
5000
7000
8500
Comentario
Se puede observar y
concluir que existe
un crecimiento del
20% respecto a la
adquisición de líneas
Prepago móviles a
través de la App
Móvil.
Tabla N° 48 – Resumen del Resultado N° 3
Elaboración Propia
67
COSTOS Y PRESUPUESTO
a) Costo de Personal:
Para el desarrollo de este proyecto ha sido necesaria la participación de diferentes perfiles
profesionales del área de TI. Por lo cual, detallaremos la cantidad de recursos y la cantidad de horas
laboradas durante todo el desarrollo del proyecto. Cabe mencionar que la duración total del
proyecto fue de 960 horas y la jornada de 8 horas diarias.
Cargo
Cantidad
Meses
3
3
Costo Mensual
(S/.)
3,500.00
3,000.00
Costo Total
(S/.)
10,500.00
9,000.00
Scrum Master
Arquitecto de Aplicaciones
Móviles
Backend
Frontend
QA
UX Designer
Programador Android
1
1
1
1
1
1
1
3
3
3
3
3
2,400.00
2,400.00
1,800.00
2,000.00
2,400.00
7,200.00
7,200.00
5,400.00
6,000.00
7,200.00
Especialista en Flujo Prepago
Especialista en Flujo de Ventas
Costo total:
1
1
3
3
2,500.00
2,500.00
7,500.00
7,500.00
67,500.00
Tabla N° 49 – Costo de Personal del Proyecto
Elaboración Propia
b) Costo en tecnología:
Los costos en tecnología son básicamente con respecto a servidores y bases de datos. Por un lado,
fue necesario utilizar en la arquitectura servidores Linux y Oracle Database 11g. Al igual que otras
tecnologías como WebLogic y SOAP
Recursos de Hardware:
Para la definición de los costos de hardware, se realiza la tabla mostrada a continuación, la cual se
basa en el uso de un costo anual del mercado.
Equipo
Cantidad
Meses
Costo Mensual (S/.)
Costo Total (S/.)
Laptop
9
No Aplicable
1,400.00
12,600.00
Dispositivo Movil
1
No Aplicable
600.00
600.00
Dispositivo Biometrico
TOTAL
1
No Aplicable
100.00
100.00
13,300.00
Tabla N° 52 – Costo de Hardware
Elaboración Propia
68
Recursos de Software:
En la tabla presentada a continuación se indican los costos anuales de software para implementar
el sistema de gestión de lecciones aprendidas.
Herramienta
Cantidad
Uso de Tecnología Linux
Base de datos Oracle 11g
Lenguaje de Programación
Java
Android Studio
Costo Total
Meses
1
1
1
3
3
3
Costo Mensual
(S/.)
0.00 (Gratuito)
3,000.00
0.00 (Gratuito)
1
3
0.00 (Gratuito)
Costo Total (S/.)
0.00
9,000.00
0.00
9,000.00
0.00
Tabla N° 53 – Costo de Tecnología
Elaboración Propia
C) Costos Total de la Implementación:
En la tabla que se muestra a continuación se detalla el costo para la implementación del sistema
de gestión de lecciones aprendidas. La tabla resume los costos totales de hardware, software y
recursos humanos calculados anteriormente.
TIPO DE COSTO
Costo de RR.HH.
Costo de Hardware
Costo de Software
TOTAL
COSTO TOTAL (S/.)
67,500.00
13,300.00
9,000.00
80,800.00
Tabla N° 54 – Costo Total de Implementación
Elaboración Propia
Por lo tanto, el costo total invertido en el proyecto es de S/. 80,800.00
69
CONCLUSIONES
Luego del desarrollo e implementación de la aplicación móvil de ventas, y la obtención de
resultados mostrados anteriormente, se han llegado a las siguientes conclusiones:
-
Utilizar como marco de trabajo SCRUM ha sido fundamental para que la aplicación
cumpla con las expectativas esperadas, se han ido perfeccionando y corrigiendo errores
durante el desarrollo del proyecto.
-
Se debe tener en cuenta el tiempo que se emplea en cada operación de venta cada vez
que se tenga planeado agregar una nueva funcionalidad a la App de venta.
-
La aplicación está desarrollada para facilitar la adquisición de nuevas líneas Prepago,
pero podría agregarse como nuevo proceso que contemple las Portabilidades Prepago.
-
Es de vital importancia que la interfaz de la aplicación móvil sea lo más amigable posible,
de modo que la información proporciona por el vendedor y la información recibida por
el cliente sean lo más claras posible.
-
Definir el alcance de cada operación que quiera trasladarse a la App de venta ayudará a
que el resultado sea óptimo.
-
A medida que pasa el tiempo la aplicación móvil debe ir evolucionando, corrigiendo
aquellos eventos que no fueron considerados en un inicio.
70
REFERENCIAS BIBLIOGRÁFICAS
Artículos Electrónicos:

Scrumguides.org, (Julio 2013). La Guía Definitiva de Scrum (31/10/2019). Disponible en:
https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-es.pdf

Sutori.com, (2019). Evolución del desarrollo de aplicaciones móviles (05/11/2019).
Disponible en:
https://www.sutori.com/story/evolucion-del-desarrollo-de-aplicaciones-moviles-xCaoSVEipdxZfQFenWwi97Z2

Infomarketing.pe, (2019). Tendencias en aplicaciones móviles para el 2019
(19/11/2019). Disponible en:
http://www.infomarketing.pe/marketing/articulos/tendencias-en-aplicacionesmoviles-para-el-2019/
Tesis:

Tanaka, Ricardo. (2016) “Sistema de gestión de fuerza de ventas web y móvil, utilizando
estilo arquitectónico REST, metodología Scrum y geolocalización”, UNMSM, Facultad de
Ingeniería de Software, Perú.

Casaverde, Joel & Loayza, Manuel. (2005) “Solución móvil de pagos en línea para un
sistema de ventas por delivery usando Smartphones y JAVA”, UNI, Facultad de Ingenieria
de Sistemas, Perú.

Reyes Mora, Iliana (2002).“Mobile Applications and their Impact in the Value Creation
Process for a Mexican Enterprise”, Instituto Tecnológico y de estudios Superiores de
Monterrey, Post-Graduate Programs of Electronics, Computing, Informatics, and
Communications, México.
71
ANEXOS
ANEXO 01: LECTOR DE HUELLAS ELECTRONICO AUTORIZADO POR EL OPERADOR
Este dispositivo se debe conectar al celular antes de realizar la operación de venta.
Vista Frontal
72
Vista Posterior
73
ANEXO 02: EJEMPLO DE PRUEBA DE SERVICIOS WEB A TRAVES DE SoapUI
PRUEBA DE UNA PETICIÓN DE REQUEST
PRUEBA DE UNA PETICION DE RESPONSE
74
ANEXO 03: ESPECIFICACIONES TÉCNICAS BÁSICAS PARA EL USO DEL APP
Ventas Móvil App
Sistema Operativo Requerido
Android 4.3 o superiores
RAM Mínima Requerida
4GB de RAM
Memoria Mínima Requerida
32GB
Tamaño
30MB
Consumo de batería
15% - 20% de batería por hora
LOGO
75
76
77
78
79
80
81
82
83
84
85
86