Post on 19-May-2022
1
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
2
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.
3
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
4
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
5
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
6
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
7
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
8
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.
9
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.
10
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.
11
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.
12
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 atención al realizar una operación de venta.
Perdida de ventas por las demoras en la atención.
Tiempos muertos generados en las atenciones debido al flujo de venta actual.
Reducción de ingresos en ventas respecto a las Altas Prepago.
Mala organización para la atención de clientes.
Afluencia innecesaria de 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.
13
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
14
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.
15
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).
16
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.
17
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.
18
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.
19
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.
20
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.
21
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
DIFERENCIAS
Define roles concretos para cada miembro.
Se pueden definir roles para cada miembro o no.
Limpia su tablero en cada 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.
SIMILITUDES
Ambos son modelos agiles.
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
22
Duración del Proyecto: 99 Días
Fase de Iniciación Fase de Planificación y
Estimación
Fase de Implementación
Fase de Revisión y Retrospectiva
Fase de Lanzamiento
Actividades SCRUM
Actividades SCRUM
Actividades SCRUM
Actividades SCRUM
Actividades SCRUM
Realizar la visión del proyecto:
Aplicación Móvil para mejorar el
proceso de venta
Sprint Planning
Diseño de tablas y
BD’s
Sprint Review
Sprint
Retrospective
Definir roles y formar el equipo
Scrum
Elaboración de historias de
usuario
Desarrollo de la Aplicación
Pruebas QA
Registrar las buenas practicas
Elaborar el listado de
requerimientos y cronograma de
actividades
Estimación
Moscow
Demostración del Funcionamiento de la Aplicación antes de salir a
Producción
Registrar las
lecciones aprendidas
Elaborar el
Product Backlog
Priorización de historias de
usuario
Pruebas de
Funcionalidad
Elaboración de Documento para
Pase a Producción
Registrar las oportunidades de
mejora
Elaborar Matriz de Riesgos
Daily Scrum (15 min.)
Actualizar Product Backlog
Refinamiento del Sprint
Definir Alcance del Proyecto
Definir los criterios de
aceptación para la fase de
Lanzamiento
Entregables Entregables Entregables Entregables Entregables
Visión del Proyecto
Sprint Backlog
Diagrama de
Arquitectura de la Aplicación
Prototipo Aplicación Móvil
Product Increment
Listado de Historias de
Usuario
Listado de Requerimientos y
creación del equipo SCRUM
Principales tablas que intervienen
en el funcionamiento de la Aplicación
Product Backlog
Cronograma de Actividades del
Proyecto
Tabla N° 3 - Desarrollo de Fases de SCRUM
Elaboración Propia
23
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.
24
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.
25
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:
26
Figura N° 8 – Elaboración de equipo SCRUM
Elaboración Propia
Asignación de Actividades – Equipo SCRUM
Rol Función
Scrum Master Guiar al equipo en el marco SCRUM
Facilitar las reuniones SCRUM
Seguimiento del proyecto
Reportar avances del proyecto al negocio y TI
Arquitecto de Aplicaciones
Móviles
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.
Backend Análisis Técnico
Ejecución del desarrollo
Atención de observaciones
Elaboración de documentos
Frontend Análisis Técnico
Ejecución del desarrollo
Atención de observaciones
Elaboración de documentos
QA Elaboración de documentos
Ejecución de pruebas
Gestión de pases a Producción
27
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
E-03 Como usuario del sistema quiero validar que el
SIMCARD que va a utilizarse este disponible para la venta.
Módulo del proceso de activación
Prepago E-04
Como usuario del sistema quiero validar que la aplicación realice correctamente la activación de la
línea.
Módulo de Transparencia de la
Aplicación E-05
Como usuario del sistema quiero ver en todo momento los datos de la venta y activación de la
línea.
Módulo de diseño de la aplicación
E-06 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
Certificación de la solución
UX Designer Diseño de experiencia de usuario
Diseño de interfaces para la APP
Programador Android
Desarrollo de interfaces del APP
Ejecución de pruebas funcionales
Especialista en Flujo Prepago
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
28
Módulo ID Historia de Usuario Funcionalidad ID Épica
Módulo de acceso a los
vendedores
HU-01 Identificar DNI Vendedor
E-01
HU-02 Identificar DAC Vendedor
HU-03 Verificar Versión
HU-04 Verificar Huella Vendedor
HU-05 Aprobar Vendedor
HU-06 Identificar Vendedor No Encontrado
Módulo de seguridad de
la información
HU-07 Identificar DNI Cliente
E-02 HU-08 Verificar Cantidad de
Líneas
HU-09 Verificar Tipo Producto
Módulo del proceso de
venta
HU-10 Validar SIMCARD
E-03 HU-11 Validar IMEI
HU-12 Obtener Línea Prepago
HU-13 Asociar Línea Prepago
Módulo del proceso de
activación Prepago
HU-14 Elegir Distrito
E-04
HU-15 Elegir Centro Poblado
HU-16 Ingresar Correo
Electrónico
HU-17
Activar Línea Prepago
HU-18 Entregar Bono Prepago
Módulo de
transparencia de la aplicación
HU-19 Mostrar Datos de Venta
E-05 HU-20
Mostrar Datos de Activación Prepago
Módulo de diseño de la aplicación
HU-21 Diseñar Interfaz de Venta
E-06 HU-22 Diseñar Interfaz de Activación de Línea
HU-23 Diseñar Interfaz de Acceso a la Aplicación
Tabla N° 6 – Listado General de Historias de Usuario
Elaboración Propia
29
3.1.4. Cronograma de Actividades del Proyecto:
Actividades Duración Inicio Fin
Aplicación Móvil de Ventas
99 días 02/01/2018 03/04/2018
Fase de Iniciación
05 días 02/01/2018 06/01/2018
Realizar la visión del proyecto: App Móvil
para mejorar proceso de venta
02 días 01/01/2018 03/01/2018
Definir roles y formar el equipo SCRUM
01 día 01/01/2018 02/01/2018
Definición de la arquitectura de
producto
02 días 03/01/2018 05/01/2018
Desarrollo de las épicas del proyecto
02 días 03/01/2018 05/01/2018
Identificación y evaluación de riesgos
02 días 03/01/2018 05/01/2018
Priorización y Estimación de historias
de usuario
02 días 03/01/2018 05/01/2018
Definir el backlog priorizado del producto
02 días 03/01/2018 05/01/2018
Sprint 1 – Módulo de acceso a los vendedores
15 días 06/01/2018 16/01/2018
FASE DE PLANIFICACION Y
ESTIMACION 04 días 06/01/2018 10/01/2018
Sprint Planning 01 día 06/01/2018 07/01/2018
Creación de historias de usuario
03 días 08/01/2018 10/01/2018
Estimación de historias de usuario
03 días 08/01/2018 10/01/2018
FASE DE IMPLEMENTACIÓN
05 días 10/01/2018 16/01/2018
Análisis y diseño de base de datos
05 días 10/01/2018 15/01/2018
Desarrollo del producto 05 días 10/01/2018 15/01/2018
Daily Scrum 05 días 10/01/2018 15/01/2018
Pruebas de funcionalidad
02 días 14/01/2018 16/01/2018
FASE DE REVISIÓN Y RETROSPECTIVA
02 días 14/01/2018 16/01/2018
Sprint Review 01 día 15/01/2018 16/01/2018
Sprint Retrospective 01 día 15/01/2018 16/01/2018
30
Sprint 2 – Módulo de seguridad de la
información
15 días 16/01/2018 30/01/2018
FASE DE PLANIFICACION Y
ESTIMACION 04 días 16/01/2018 20/01/2018
Sprint Planning 01 día 16/01/2018 17/01/2018
Creación de historias de usuario
03 días 17/01/2018 20/01/2018
Estimación de historias de usuario
03 días 17/01/2018 20/01/2018
FASE DE IMPLEMENTACION
05 días 20/01/2018 26/01/2018
Análisis y diseño de base de datos
05 días 20/01/2018 25/01/2018
Desarrollo del producto 05 días 20/01/2018 25/01/2018
Daily Scrum 05 días 20/01/2018 25/01/2018
Pruebas de funcionalidad
02 días 24/01/2018 26/01/2018
FASE DE REVISION Y RETROSPECTIVA
02 días 28/01/2018 30/01/2018
Sprint Review 01 día 28/01/2018 29/01/2018
Sprint Retrospective 01 día 29/01/2018 30/01/2018
Sprint 3 – Módulo del proceso de venta
15 días 01/02/2018 16/02/2018
FASE DE PLANIFICACION Y
ESTIMACION 04 días 01/02/2018 05/02/2018
Sprint Planning 01 día 01/02/2018 02/02/2018
Creación de historias de usuario
03 días 02/02/2018 05/02/2018
Estimación de historias de usuario
03 días 02/02/2018 05/02/2018
FASE DE IMPLEMENTACION
05 días 05/02/2018 10/02/2018
Análisis y diseño de base de datos
05 días 05/02/2018 10/02/2018
Desarrollo del producto 05 días 05/02/2018 10/02/2018
Daily Scrum 05 días 05/02/2018 10/02/2018
Pruebas de funcionalidad
02 días 08/02/2018 10/02/2018
FASE DE REVISION Y RETROSPECTIVA
02 días 10/02/2018 12/02/2018
Sprint Review 01 día 10/02/2018 11/02/2018
Sprint Retrospective 01 día 11/02/2018 12/02/2018
Sprint 4 – Módulo del proceso de activación
Prepago
15 días 16/02/2018 29/02/2018
31
FASE DE PLANIFICACION Y
ESTIMACION 04 días 16/02/2018 20/02/2018
Sprint Planning 01 día 16/02/2018 17/02/2018
Creación de historias de usuario
03 días 17/02/2018 20/02/2018
Estimación de historias de usuario
03 días 17/02/2018 20/02/2018
FASE DE IMPLEMENTACION
05 días 20/02/2018 26/02/2018
Análisis y diseño de base de datos
05 días 20/02/2018 26/02/2018
Desarrollo del producto 05 días 20/02/2018 26/02/2018
Daily Scrum 05 días 20/02/2018 26/02/2018
Pruebas de funcionalidad
02 días 24/02/2018 26/02/2018
FASE DE REVISION Y RETROSPECTIVA
02 días 27/02/2018 29/02/2018
Sprint Review 01 día 27/02/2018 28/02/2018
Sprint Retrospective 01 día 28/02/2018 29/02/2018
Sprint 5 - Módulo de transparencia de la
aplicación
15 días 01/03/2018 15/03/2018
FASE DE PLANIFICACION Y
ESTIMACION 04 días 01/03/2018 04/03/2018
Sprint Planning 01 día 01/03/2018 02/03/2018
Creación de historias de usuario
03 días 02/03/2018 04/03/2018
Estimación de historias de usuario
03 días 02/03/2018 04/03/2018
FASE DE IMPLEMENTACION
05 días 05/03/2018 11/03/2018
Análisis y diseño de base de datos
05 días 05/03/2018 11/03/2018
Desarrollo del producto 05 días 05/03/2018 11/03/2018
Daily Scrum 05 días 05/03/2018 11/03/2018
Pruebas de funcionalidad
02 días 09/03/2018 11/03/2018
FASE DE REVISION Y RETROSPECTIVA
02 días 12/03/2018 15/03/2018
Sprint Review 01 día 12/03/2018 13/03/2018
Sprint Retrospective 01 día 14/03/2018 15/03/2018
Sprint 6 - Módulo de diseño de la aplicación
15 días 16/03/2018 30/03/2019
FASE DE PLANIFICACION Y
ESTIMACION 04 días 16/03/2018 21/03/2018
Sprint Planning 01 día 16/03/2018 17/03/2018
32
Creación de historias de usuario
03 días 18/03/2018 21/03/2018
Estimación de historias de usuario
03 días 18/03/2018 21/03/2018
FASE DE IMPLEMENTACION
05 días 21/03/2018 26/03/2018
Análisis y diseño de base de datos
05 días 21/03/2018 26/03/2018
Desarrollo del producto 05 días 21/03/2018 26/03/2018
Daily Scrum 05 días 21/03/2018 26/03/2018
Pruebas de funcionalidad
02 días 24/03/2018 26/03/2018
FASE DE REVISION Y RETROSPECTIVA
02 días 26/03/2018 28/03/2018
Sprint Review 01 día 26/03/2018 27/03/2018
Sprint Retrospective 01 día 27/03/2018 28/03/2018
Fase de Lanzamiento 04 días 30/03/2018 02/04/2018
Registrar las buenas practicas
02 dias 30/03/2018 01/04/2018
Refinamiento del Sprint 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.
Tabla N° 8 – Elaboración de riesgos en el proyecto Elaboración Propia
ID
Riesgo Categoría
Riesgo
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 Cambios en los requerimientos, modificaciones del flujo
ya establecido de un proceso
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 El número del equipo no es suficiente para cumplir con
el proyecto
R-09 Entorno de desarrollo Carencias en el uso de las herramientas
R-10 Tecnología La tecnología utilizada no alcanzará las expectativas
33
Tabla N° 9 – Tabla de Riesgos Elaboración Propia
Riesgo = Probabilidad x Impacto
Pro
bab
ilid
ad 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
ID
Riesgo Descripción del riesgo Probabilidad
Impact
o Valor
Clasificación
del riesgo
R-01 Subestimación del time
boxing para los sprint 0.30 0.40 0.12 MODERADO
R-02 Número de usuario mayor a lo
esperado 0.20 0.10 0.02 BAJO
R-03
Cambios en los
requerimientos,
modificaciones del flujo ya
establecido de un proceso
0.80 0.60 0.48 ALTO
R-04 El presupuesto establecido
será superado 0.10 0.80 0.08 MODERADO
R-05 Retraso en el desarrollo del
proyecto 0.30 0.40 0.12 MODERADO
R-06 Rotación de personal, salida
de un miembro del equipo 0.10 0.40 0.04 BAJO
R-07 Integrantes del equipo con un
desempeño ineficiente 0.10 0.40 0.04 BAJO
R-08
El número del equipo no es
suficiente para cumplir con el
proyecto
0.30 0.40 0.12 MODERADO
34
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 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
5
Tabla N° 11 – Estimación de Sprint 1 Elaboración Propia
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
HU-08 Verificar Cantidad de
Líneas
4
HU-09 Verificar Tipo Producto 4
Tabla N° 12 – Estimación de Sprint 2 Elaboración Propia
R-09 Carencias en el uso de las
herramientas 0.10 0.40 0.04 BAJO
R-10 La tecnología utilizada no
alcanzará las expectativas 0.05 0.70 0.035 BAJO
35
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 Puntos de Historia (PH) HU-10 Validar SIMCARD 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 Puntos de Historia (PH) HU-14 Elegir Distrito 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 Puntos de Historia (PH)
HU-19 Mostrar datos de venta 2
HU-20 Mostrar datos de activación 2
Tabla N° 15 – Estimación de Sprint 5 Elaboración Propia
36
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 Diseñar interfaz de venta 2
HU-22 Diseñar interfaz de activación 2
HU-23 Diseñar interfaz de acceso a la aplicación
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
37
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
38
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
Tabla N° 21 - Historia de Usuario HU05 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.
39
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
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”.
40
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
41
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
42
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
43
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
44
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
45
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
46
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
47
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
H
isto
rias
de
usu
ario
HU-01
HU-19
HU-23
HU-02
HU-03
HU-04
HU-05
HU-06
HU-07
HU-21
HU-08
HU-09
HU-10
HU-11
HU-12
HU-13
HU-14
HU-20
HU-22
HU-15
HU-16
HU-17
HU-18
Tabla N° 40 – Priorización de Historias de Usuario Elaboración Propia
48
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
5
HU-07 Identificar DNI Cliente 4
HU-08 Verificar Cantidad de
Líneas
4
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
HU-16 Ingresar Correo
Electrónico
3
HU-17
Activar Línea Prepago
3
HU-18 Entregar Bono Prepago 3
HU-19 Mostrar Datos de Venta 2
HU-20 Mostrar Datos de Activación Prepago
2
HU-21 Diseñar Interfaz de Venta 2
HU-22 Diseñar Interfaz de Activación de Línea
2
HU-23 Diseñar Interfaz de Acceso a la Aplicación
2
Tabla N° 41 – Asignación de puntos de Historias de Usuario Elaboración Propia
49
Realizamos la suma de cada historia de usuario y obtenemos el resultado para las épicas del
proyecto.
ID Épica Funcionalidad Puntos de
historia (PH)
E-01 Como usuario del sistema se debe validar que los vendedores que
utilicen la aplicación pertenezcan a la empresa de telecomunicaciones. 30
E-02 Como usuario del sistema quiero validar que los clientes cuenten con
registro en RENIEC. 12
E-03 Como usuario del sistema quiero validar que el SIMCARD que va a
utilizarse este disponible para la venta. 16
E-04 Como usuario del sistema quiero validar que la aplicación realice
correctamente la activación de la línea. 15
E-05 Como usuario del sistema quiero ver en todo momento los datos de la
venta y activación de la línea. 4
E-06 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.
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 ID
Épica Funcionalidad
Estimación (PH)
Prioridad
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.
30 M
Módulo de seguridad de la información
E-02 Como usuario del sistema quiero validar que los
clientes cuenten con registro en RENIEC. 12 M
Módulo del proceso de venta
E-03
Como usuario del sistema quiero validar que el SIMCARD que va a utilizarse este disponible para
la venta. 16 M
Módulo del proceso de activación Prepago
E-04 Como usuario del sistema quiero validar que la
aplicación realice correctamente la activación de la línea.
15 M
Módulo de
Transparencia de la Aplicación
E-05 Como usuario del sistema quiero ver en todo
momento los datos de la venta y activación de la línea.
4 C
Módulo de diseño de
la aplicación
E-06
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.
6 C
Tabla N° 43 – Tabla de Product Backlog Priorizado
Elaboración Propia
50
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:
Figura N° 9 – Login de la Aplicación Elaboración Propia
Figura N° 10 – Login de la Aplicación_PopUP Elaboración Propia
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)
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.
51
Figura N° 11 – Login de la Aplicación_BM
Elaboración Propia
Figura N° 12 – Login de la Aplicación_ERROR
Elaboración Propia
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)
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
52
PASO 1: INGRESAR DATOS DEL CLIENTE:
Figura N° 13 – Proceso de Venta_DatosDelCliente
Elaboración Propia
Figura N° 14 – Proceso de Venta_Modalidad
Elaboración Propia
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)
El siguiente recuadro nos permite elegir la modalidad de la
Venta, en este caso elegiremos “PREPAGO” y luego “Continuar”.
53
PASO 2: ELEGIR TIPO DE PRODUCTO E INGRESAR NÚMEROS DE SERIE (ICCID/IMEI):
Figura N° 15 – Proceso de Venta_TipoVenta
Elaboración Propia
Figura N° 16 – Tabla de Stock de Equipos Prepago
Elaboración Propia
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.
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.
54
PASO 3: CARGAR FORMULARIO
Figura N° 17 - Configuración de Cobertura
Elaboración Propia
PASO 4: ACEPTAR CONTRATO DE ALTA NUEVA Y CONFIRMAR ACTIVACIÓN
Figura N° 18 – Aceptar contratos
Elaboración Propia
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
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.
55
PASO 5: CONFIRMACIÓN DE ALTA NUEVA PREPAGO
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
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).
56
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
57
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
58
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
59
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
60
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
61
Petición de Response: El servicio web devuelve la información solicitada.
Figura N° 29 – Petición de response con SoapUI Elaboración Propia
62
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
63
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 solicitar una línea nueva debe presentar su DNI y luego solicitar su ticket de atención.
Con la Aplicación móvil no es necesario que el cliente generé un ticket de atención, lo que reduce considerablemente el tiempo de 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
64
Tabla N° 45 – Resumen del Resultado N° 1
Elaboración Propia
Figura N° 31 – Cantidad diaria de clientes atendidos por hora
Elaboración Propia
Cantidad de clientes
atendidos por hora
(10AM – 8PM)
10:00AM (1 Hora)
…
07:00PM
(10 Horas)
Reducción de
tiempo (%)
Comentario
Centro de
Atención al Cliente (CAC Mall Del Sur)
4
…
40
>33%
Con esto, evidenciamos que el primer
objetivo específico de reducir en un 20% el tiempo
de atención fue superado
Aplicación Móvil de Ventas (DAC )
12
…
120
65
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
Figura N° 32 – Ingresos en ventas según el tipo de canal de atención
Elaboración Propia
0
5,000
10,000
15,000
20,000
25,000
30,000
35,000
40,000
45,000
jul-18 ago-18 sep-18 oct-18 nov-18 dic-18
Monto mensual en soles (S/.) según canal de venta -Junio 2018 a Noviembre 2018
Centro de Atención al Cliente Cadenas
Distribuidor Autorizado App Móvil de Ventas
66
Canal de Venta
06/2018
07/2018
08/2018
09/2018
10/2018
11/2018
Monto Total S/.
Comentario
Centro de Atención al
Cliente
22,000 24,200 (10%)
26,400 (10%)
29,040 (10%)
27,588 (-5%)
30,346 (10%)
159,574
Se muestra
un incremento de ingresos constante
para el nuevo flujo de ventas por App
Móvil
Cadenas 15,000 18,000 (20%)
25,000 (39%)
32,000 (30%)
33,000 (4%)
34,000 (3%)
157,000
Distribuidor Autorizado
23,000 31,000 (35%)
35,650 (15%)
32,000 (-10%)
33,000 (4%)
34,000 (4%)
188,650
App Móvil de Ventas
20,000 22,000 (10%)
24,200 (10%)
26,620 (10%)
31,944 (20%)
39,930 (25%)
164,694
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 solicitar una línea nueva debe presentar su DNI y luego solicitar su ticket de atención.
Con la Aplicación móvil no es necesario que el cliente generé un ticket de atención, lo que reduce considerablemente el tiempo de atención.
Tabla N° 47 - Cuadro Comparativo del Resultado N° 3
Elaboración Propia
67
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
Comentario
Centro de Atención al Cliente
(CAC)
8000
6000
7000
6000
6500
5500
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.
Distribuidor Autorizado
(DAC)
1000
4000
4500
5000
7000
8500
Tabla N° 48 – Resumen del Resultado N° 3
Elaboración Propia
8000
6000
7000
60006500
5500
1000
40004500
5000
7000
8500
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
jun-18 jul-18 ago-18 sep-18 oct-18 nov-18
Cantidad de clientes atendidos CAC Vs. App MóvilJunio 2018 - Diciembre 2018
Centro de Atención al Cliente App Móvil de Ventas
68
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 Costo Mensual (S/.)
Costo Total (S/.)
Scrum Master 1 3 3,500.00 10,500.00
Arquitecto de Aplicaciones Móviles
1 3 3,000.00 9,000.00
Backend 1 3 2,400.00 7,200.00
Frontend 1 3 2,400.00 7,200.00
QA 1 3 1,800.00 5,400.00
UX Designer 1 3 2,000.00 6,000.00
Programador Android 1 3 2,400.00
7,200.00
Especialista en Flujo Prepago 1 3 2,500.00 7,500.00
Especialista en Flujo de Ventas 1 3 2,500.00 7,500.00
Costo total: 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 1 No Aplicable 100.00 100.00
TOTAL 13,300.00
Tabla N° 52 – Costo de Hardware Elaboración Propia
69
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 Meses Costo Mensual (S/.)
Costo Total (S/.)
Uso de Tecnología Linux 1 3 0.00 (Gratuito) 0.00
Base de datos Oracle 11g 1 3 3,000.00 9,000.00
Lenguaje de Programación Java
1 3 0.00 (Gratuito) 0.00
Android Studio 1 3 0.00 (Gratuito) 0.00
Costo Total 9,000.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 TOTAL (S/.)
Costo de RR.HH. 67,500.00
Costo de Hardware 13,300.00
Costo de Software 9,000.00
TOTAL 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
70
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.
71
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-aplicaciones-moviles-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.
72
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
73
Vista Posterior
74
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
75
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
76
77
78
79
80
81
82
83
84
85
86