Post on 09-Oct-2020
1
Facultad de Ingeniería
Ingeniería de Software
Programa Especial de Titulación:
“Implementación y optimización de una
plataforma E-Commerce
para una empresa de productos deportivos Lima,
2019”
Para optar el Título Profesional de Ingeniero de
Software
Juan Carlos Guerrero Fernández
Lima – Perú
2019
2
Tabla de contenido
INDICE DE FIGURAS .................................................................................................... 5
INDICE DE TABLAS ...................................................................................................... 7
INDICES DE ANEXOS ................................................................................................... 8
DEDICATORIA ............................................................................................................ 9
AGRADECIMIENTO ................................................................................................... 10
RESUMEN ................................................................................................................ 11
INTRODUCCION ....................................................................................................... 12
CAPITULO 1 .............................................................................................................. 13
ASPECTOS GENERALES ............................................................................................. 13
1.1. Definición del Problema ..................................................................................... 13 1.1.1. Descripción del Problema ................................................................................................ 13 1.1.2. Árbol de problema .......................................................................................................... 16 1.1.3. Formulación del Problema ............................................................................................... 17
1.2. Definición de objetivos ...................................................................................... 18 1.2.1. Objetivo general .............................................................................................................. 18 1.2.2. Objetivos específicos ....................................................................................................... 18
1.3. Alcances y limitaciones ...................................................................................... 18 1.3.1. Alcances .......................................................................................................................... 18 1.3.2. Limitaciones .................................................................................................................... 19
1.4. Justificación ....................................................................................................... 20
1.5. Estado del Arte .................................................................................................. 20
CAPITULO 2 .............................................................................................................. 28
MARCO TEÓRICO ..................................................................................................... 28
2.1. METODOLOGIA.................................................................................................. 28 2.1.1. PMI.................................................................................................................................. 28
Estas fases se estarán explicando con mayor detalles en el marco metodológico. ............ 28 2.1.2. SCRUM ............................................................................................................................ 28
2.1.3. MAGENTO ..................................................................................................... 33 A. Magento Open Source (Community) .................................................................................... 33 B. Magento Enterprise Edition ................................................................................................. 33
2.1.4. GITLAB .......................................................................................................... 34
2.1.5. PHP (Hypertext Preprocessor) ........................................................................ 34
2.1.6. MYSQL .......................................................................................................... 35
2.1.7. Modelo de datos ........................................................................................... 35 2.1.7.1. Modelo Eav ................................................................................................................. 36
2.2. MARCO LEGAL ................................................................................................... 38 2.2.1. LEY Nº 29733 ................................................................................................................... 38
2.3. MARCO METODOLOGICO ................................................................................... 39 2.3.1. FASES DEL PROYECTO ...................................................................................................... 39 2.3.1.1. FASE 1- INICIACIÓN ..................................................................................................... 39
3
2.3.1.1.1. PROJECT CHARTER ................................................................................................. 39 2.3.1.1.2. Gestión De Interesados Del Proyecto ..................................................................... 39 2.3.1.2. FASE 2 – PLANIFICACIÓN ............................................................................................. 40 2.3.1.2.1. Cronograma ........................................................................................................... 40 2.3.1.2.2. Work Breakdown Structure (WBS) ......................................................................... 40 2.3.1.2.3. Gestión De Comunicaciones ................................................................................... 40 2.3.1.2.4. Gestión De Riesgos ................................................................................................. 40 2.3.1.2.5. Documento De Riesgo Presentado ......................................................................... 42 2.3.1.3. FASE 3 – EJECICIÓN ..................................................................................................... 42 2.3.1.3.1. SPRINT 0................................................................................................................. 43 2.3.1.3.2. PRODUCT BACKLOG ............................................................................................... 43 2.3.1.3.3. DEFINICIÓN DE LOS SPRINT 1 y 2 ............................................................................ 43 2.3.1.3.4. SPRINT 1................................................................................................................. 43 2.3.1.3.5. SPRINT 2................................................................................................................. 44 2.3.1.4. FASE 4 – CIERRE .......................................................................................................... 45 2.3.2. ALCANCE ......................................................................................................................... 46 2.3.3. CALIDAD .......................................................................................................................... 46
2.4. Marco conceptual .............................................................................................. 46 2.4.1. E-Commerce: ................................................................................................................... 46 2.4.2. Target .............................................................................................................................. 47 2.4.3. Open Source .................................................................................................................... 47 2.4.4. Retargetting .................................................................................................................... 48 2.4.5. Lenguaje de programación .............................................................................................. 48 2.4.6. MVC ................................................................................................................................ 48 2.4.7. Front-end ........................................................................................................................ 49 2.4.8. Back-end ......................................................................................................................... 49 2.4.9. Cuadrante mágico de Gartner ......................................................................................... 50 2.4.10. Banco de datos ........................................................................................................... 51 2.4.11. Datos sensibles ........................................................................................................... 51 2.4.12. Amazon Cloud............................................................................................................. 52 2.4.13. Seo ............................................................................................................................. 52 2.4.14. On-line ........................................................................................................................ 52 2.4.15. Smartphone ................................................................................................................ 52 2.4.16. PYMES ........................................................................................................................ 52 2.4.17. API (Application Programming Interface) .................................................................... 53 2.4.18. Middleware ................................................................................................................ 53 2.4.19. Libro de reclamaciones ............................................................................................... 53 2.4.20. Pasarela de Pago ......................................................................................................... 53 2.4.21. Operador logístico ...................................................................................................... 54 2.4.22. Checkout E-commerce ................................................................................................ 54 2.4.23. Producto Configurable ................................................................................................ 54 2.4.24. Producto Simple ......................................................................................................... 54 2.4.25. Modulo de Magento – Plugins .................................................................................... 55
CAPITULO 3 .............................................................................................................. 56
METODOLOGIA DEL DESARROLLO ............................................................................ 56
3.1. FASES DEL PROYECTO ........................................................................................ 56
3.1.1. FASE 1: INICIACION ........................................................................................ 56 3.1.1.1. PROJECT CHARTER ...................................................................................................... 56 3.1.1.2. GESTION DE INTERESADOS DEL PROYECTO ................................................................. 58
3.1.2. FASE 2: PLANIFICACIÓN ................................................................................. 60 3.1.2.1. CRONOGRAMA ........................................................................................................... 60 3.1.2.2. WBS o EDT .................................................................................................................. 62 3.1.2.3. GESTIÓN DE COMUNICACIONES ................................................................................. 65
4
3.1.2.4. GESTION DE RIESGOS .................................................................................................. 67
3.1.3. FASE 3: EJECUCION ........................................................................................ 70 3.1.3.1. SPRINT 0 ..................................................................................................................... 70 3.1.3.1.1. Definición De Historias De Usuario ......................................................................... 70 3.1.3.1.2. PRODUCT BACKLOG: .............................................................................................. 78 3.1.3.1.3. Definición De Sprint Backlog................................................................................... 82 3.1.3.2. SPLINT 1 ...................................................................................................................... 85 3.1.3.2.1. FASE DE PLANIFICACION:........................................................................................ 85 3.1.3.2.1.1. REVISIÓN Y MODIFICACIÓN DEL Sprint BACKLOG ................................................... 85 3.1.3.2.2. FASE DE ANALISIS ................................................................................................... 86 3.1.3.2.2.1. REVISION Y MODIFICACION DE HISTORIAS DE USUARIOS ....................................... 86 3.1.3.2.2.2. VERIFICACION Y MODIFICACION DEL PRODUCT BACKLOG: ..................................... 89 3.1.3.2.2.3. DISEÑO DE PROTOTIPOS ........................................................................................ 91 3.1.3.2.3. FASE DE DISEÑO ..................................................................................................... 97 3.1.3.2.3.1. MODELO DE DATOS................................................................................................ 97 3.1.3.2.4. FASE DE CONSTRUCCION Y PRUEBAS ................................................................... 101 3.1.3.2.4.1.1. Prueba Funcional 1 .......................................................................................... 105 3.1.3.2.4.1.2. Prueba Funcional 2 .......................................................................................... 108 3.1.3.2.4.1.3. Prueba Funcional 3 .......................................................................................... 110 3.1.3.2.4.1.4. Prueba Funcional 4 .......................................................................................... 112 3.1.3.2.4.1.5. Prueba Funcional 5 .......................................................................................... 114 3.1.3.2.4.1.6. Prueba Funcional 6 .......................................................................................... 116 3.1.3.2.5. FASE DE IMPLEMENTACIÓN ................................................................................. 118 3.1.3.3. SPRINT 2 ................................................................................................................... 118 3.1.3.3.1. FASE DE PLANIFICACION:...................................................................................... 118 3.1.3.3.1.1. REVISION Y MODIFICACION DEL Sprint BACKLOG ................................................. 118 3.1.3.3.2. FASE DE ANALISIS ................................................................................................. 119 3.1.3.3.2.1. REVISION Y MODIFICACION DE HISTORIAS DE USUARIOS ..................................... 119 3.1.3.3.2.2. VERIFICACIÓN Y MODIFICACIÓN DEL PRODUCT BACKLOG: ................................... 122 3.1.3.3.3. FASE DE DISEÑO ................................................................................................... 125 3.1.3.3.4. FASE DE CONSTRUCCIÓN Y PRUEBAS ................................................................... 127 3.1.3.3.4.1.1. Prueba Funcional 7 .......................................................................................... 130 3.1.3.3.4.1.2. Prueba Funcional 8 .......................................................................................... 131 3.1.3.3.4.1.3. Prueba Funcional 9 .......................................................................................... 132 3.1.3.3.4.1.4. Prueba Funcional 10 ........................................................................................ 133 3.1.3.3.5. FASE DE IMPLEMENTACIÓN ................................................................................. 134
3.1.4. FASE 4: CIERRE ............................................................................................. 135
CAPITULO 4 ............................................................................................................ 136
RESULTADOS.......................................................................................................... 136
4.1. Resultados ...................................................................................................... 136
4.2. Presupuesto .................................................................................................... 144
4.2.1. Gastos en personal ...................................................................................... 144
4.2.2. Gastos por Equipos ...................................................................................... 145
4.2.3. Gasto por Software ...................................................................................... 145
4.2.4. COSTOS ....................................................................................................... 146
4.2.5. Calculo del Var y Tir del proyecto ................................................................. 146
CONCLUSIONES ...................................................................................................... 148
BIBLIOGRAFÍAS ...................................................................................................... 149
5
ANEXOS ................................................................................................................. 151
INDICE DE FIGURAS
Figura 1. Árbol de problema........................................................................................... 16 Figura 2. Cuadrante de Mágico de Gartner .................................................................... 21 Figura 3. Forrester Wave: B2C Commerce Suites, Q3 2018 ......................................... 22 Figura 4. Logo de IBM Watson ...................................................................................... 23 Figura 5. Logo de SAP Hybris ....................................................................................... 23 Figura 6. Proceso de Oracle Commerce Cloud .............................................................. 24 Figura 7. Logo de Salesforce .......................................................................................... 24 Figura 8. Logo de Magento ............................................................................................ 25 Figura 9.Scrum ............................................................................................................... 31 Figura 10. Roles de Scrum ............................................................................................. 32 Figura 11.Flujo del proceso de Scrum ............................................................................ 32 Figura 12. Gitlab ............................................................................................................. 34 Figura 13. Logo lenguaje de Programación PHP ........................................................... 34 Figura 14. Logo de la Base de datos ............................................................................... 35 Figura 15. Modelo EAV ................................................................................................. 37 Figura 16. Modelo EAV ................................................................................................. 37 Figura 17. Cronología de la Legislación ........................................................................ 38 Figura 18. Frontend y Backend ...................................................................................... 49 Figura 19.Cuadrante de Gartner ..................................................................................... 50 Figura 20. Modelo de Middleware ................................................................................. 53 Figura 21. Pasarela de Pagos .......................................................................................... 54 Figura 22. Modulo básico de Magento ........................................................................... 55 Figura 23. Cronograma del proyecto .............................................................................. 61 Figura 24. EDT del Proyecto .......................................................................................... 63 Figura 25. Mockups Home Page .................................................................................... 91 Figura 26. Segunda Parte ................................................................................................ 92 Figura 27. Categoría de Productos ................................................................................. 93 Figura 28. Mockups de Product Page ............................................................................. 94 Figura 29. Mockupds de Carrito de compras ................................................................. 95 Figura 30. Onepage Checkout ........................................................................................ 96 Figura 31. Tabla Relacional del Producto ...................................................................... 98 Figura 32. Atributos creados para un producto personalizado ....................................... 99 Figura 33. Tipos de atributos - Productos....................................................................... 99 Figura 34. Componentes de un Atributo - Producto Magento ..................................... 100 Figura 35. Opciones del Atributo Creado ..................................................................... 100 Figura 36. Tablas de atributos ...................................................................................... 101 Figura 37. Flujograma de proceso de compra .............................................................. 102 Figura 38. Flujograma de inicio de sesión .................................................................... 103 Figura 39. Flujograma de Creación de Ordenes de Servicios del Operador Logístico 104 Figura 40. Modelo Relacional de las tablas de compra y de envío .............................. 105 Figura 41. Captura de Registro de Usuario .................................................................. 107 Figura 42. Información del Producto ............................................................................ 109 Figura 43. Libro de Reclamaciones .............................................................................. 111 Figura 44. Flujo de compra........................................................................................... 113
6
Figura 45. Creación de ordenes de servicio del operador logístico .............................. 115 Figura 46. Ingreso de Cupón en el carrito de compra .................................................. 117 Figura 47. Tablas Relacionadas a las Ventas ............................................................... 125 Figura 48. Formulario Libre ......................................................................................... 127 Figura 49. Modelo relacional de formularios Libres .................................................... 128 Figura 50. Flujograma de la administración de stock ................................................... 128 Figura 51. Matriz de costos de envío ............................................................................ 129 Figura 52. Prototipo del Apartado de Newsletter ......................................................... 131 Figura 53. Mensaje de satisfacción de inicio de sesión ................................................ 132 Figura 54. Mockup de Método de pago ........................................................................ 134 Figura 55. Pedidos ........................................................................................................ 137 Figura 56. Atributos Producto ...................................................................................... 139 Figura 57. Atributo Precio - Producto .......................................................................... 139 Figura 58. Stock de Producto ....................................................................................... 140 Figura 59. Stock detallado - Tienda.............................................................................. 140 Figura 60.Regla de Carrito de compra.......................................................................... 140 Figura 61. Operador logístico ....................................................................................... 142 Figura 62. Costos Acumulables .................................................................................... 146
7
INDICE DE TABLAS
Tabla 1. Árbol de problemas .......................................................................................... 17 Tabla 2. Comparación de CMS Open Source ................................................................. 25 Tabla 3. Valores para estimar de Riesgos....................................................................... 41 Tabla 4. Valores para estimar Impacto ........................................................................... 41 Tabla 5. Semaforización de Riesgos............................................................................... 41 Tabla 6. Categorización de los Riesgos .......................................................................... 42 Tabla 7. Acta de Iniciación del Proyecto ........................................................................ 56 Tabla 8. Gestión de Interesados ...................................................................................... 59 Tabla 9. Matriz de Asignaciones de Responsabilidades................................................. 66 Tabla 10. Tabla de Riesgos............................................................................................. 68 Tabla 11. Sprint 0 ........................................................................................................... 71 Tabla 12. Product Backlog ............................................................................................. 78 Tabla 13. Sprint 1 ........................................................................................................... 83 Tabla 14. Sprint 2 ........................................................................................................... 84 Tabla 15. Planificación y Revisión del Sprint 1 ............................................................. 85 Tabla 16. Revisión de las Historias de Usuario del Sprint 1 .......................................... 86 Tabla 17. Modificación del Product Backlog en el Sprint 1 .......................................... 89 Tabla 18. Prueba Funcional 1 - Sprint 1 ....................................................................... 105 Tabla 19. Prueba funcional 2 - Sprint 1 ........................................................................ 108 Tabla 20. Prueba Funcional 3 - Sprint 1 ....................................................................... 110 Tabla 21. Prueba Funcional 4 - Sprint 1 ....................................................................... 112 Tabla 22. Prueba Funcional 5 - Sprint 1 ....................................................................... 114 Tabla 23. Prueba Funcional 6 - Sprint 1 ....................................................................... 116 Tabla 24. Sprint 2 ......................................................................................................... 118 Tabla 25. Revisión del las Historias De Usuario - Sprint 2 .......................................... 119 Tabla 26. Revisión del Product Backlog - Sprint 2 ...................................................... 122 Tabla 27. Prueba Funcional 7 - Sprint 2 ....................................................................... 130 Tabla 28. Prueba Funcional 8 - Sprint 2 ....................................................................... 131 Tabla 29. Prueba Funcional 9 - Sprint 2 ....................................................................... 132 Tabla 30. Prueba Funcional 10 - Sprint 2 ..................................................................... 133 Tabla 31. Cierre del Proyecto ....................................................................................... 135 Tabla 32. Cuadro Antes y Ahora - Encuesta 1 ............................................................. 138 Tabla 33. Cuadro Antes y Ahora - Encuesta 2 ............................................................. 142 Tabla 34. Cuadro Antes y Ahora - Encuesta 3 ............................................................. 143 Tabla 35. Tabla de Presupuesto del Personal que labora en la empresa ...................... 144 Tabla 36. Gastos detalles por Equipos.......................................................................... 145 Tabla 37. Detallado de gastos por software .................................................................. 145 Tabla 38. TABLA DE COSTOS .................................................................................. 146 Tabla 39. Detalle del Van y TIR................................................................................... 147
8
INDICES DE ANEXOS
Anexo 1. Formato de Project Charter ........................................................................... 151 Anexo 2. Gestión de Interesados .................................................................................. 153 Anexo 3. Matriz de Asignación de Responsabilidades ................................................ 154 Anexo 4. WBS o EDT .................................................................................................. 155 Anexo 5. Documento de Riesgo ................................................................................... 156 Anexo 6. Sprint 0 .......................................................................................................... 157 Anexo 7. Product Backlog ............................................................................................ 158 Anexo 8. Documento del Sprint Backlog 1 .................................................................. 159 Anexo 9. Documento del Sprint Backlog 2 .................................................................. 160 Anexo 10. Plan de Pruebas ........................................................................................... 161 Anexo 11. Cierre de Proyecto....................................................................................... 162 Anexo 12. Encuesta sobre conclusiones de proyecto ................................................... 163 Anexo 13. Informe de Turnitin ..................................................................................... 165
9
DEDICATORIA
Dedico este trabajo a mi madre Rosa Fernández, quien han dedicado su todo su tiempo,
amor, paciencia, tolerancia para darme todo lo he necesitado para alcanzar mis metas.
Todos mis logros son gracias a ella a su dedicación y seguiré logrando más porque es lo
más importante en mi vida.
10
AGRADECIMIENTO
A mi mama por darme la oportunidad de superarme, por los grandes sacrificios que ha
hecho para que pueda llegar a cumplir una de muchas metas, por su apoyo incondiconal
ante mis decisiones, por siempre querer lo mejor para mi y para mi futuro.
A la universidad por la capación, a los profesores que nos apoyaron y nos aconsejaron
para el desarrollo de este informe.
A mi asesor por su orientación, los consejos o sugerencias y recomendaciones para el
desarrollo del este informe.
A mis amigos de la universidad UTP, que juntos comenzamos este camino y juntos
estamos terminando cada meta que nos proponemos como ingenieros.
A mis amigos más cercanos por su apoyo y recomendaciones para cumplir esta meta.
11
RESUMEN
La empresa se encarga de vender productos deportivos al por menor a nivel nacional, la
cual quiere incrementar sus ventas a través de una mejor disponibilidad 24/7 su
disponibilidad y vender más. Al no poder contar con una atención al cliente no podrá
administrar de mejor forma los procesos.
El proyecto nos guiaremos de las buenas practicas de PMBOK y para la personalización
y el desarrollo de módulos usaremos Scrum para poder realizar una plataforma e-
commerce la cual cumpla todos los aspectos necesarios para que el cliente final puede
realizar una venta de forma cómoda y fácil.
El presente informe se estará dividiendo en 4 partes las cuales son:
En el primer capitulo hablaremos sobre la problemática que se genero para poder llegar a
realizar este proyecto, cuales fueron las causas y el efecto de estas que le trajo a la
empresa.
En el capitulo dos hablaremos sobre en base a que vamos a desarrollar este proyecto es
decir cual seria el marco teórico, los conceptos básicos que se deben manejar. En que nos
hemos basado para llevar acabo este proyecto.
El tercer capitulo se estará viendo como hemos desarrollado el proyecto, aquí se usarán
los formatos designados, se visualizará las fases de este aplicando los marcos teóricas o
buenas practicas.
En el ultimo capitulo podemos visualizar los resultados que se medirán en forma de
encuestas cumpliendo los objetivos específicos, también se hablara del presupuesto y de
las conclusiones sobre el proyecto.
12
INTRODUCCION
En el presente informe tiene como finalidad, el implementar y optimizar una plataforma
de comercio electrónico para una empresa de ventas de productos a nivel nacional, el que
generara mas ventas en un nuevo canal virtual.
Para este proyecto relacionado a una plataforma E-Commerce nos basaremos en lo
siguiente: SCRUM para el desarrollo de los módulos personalizados y algunas
modificaciones de los módulos que viene por defecto en el CMS y para la gestión de
proyecto usaremos Guía PMI.
13
CAPITULO 1
ASPECTOS GENERALES
1.1. Definición del Problema
1.1.1. Descripción del Problema
En esta empresa de ventas de productos, una de sus metas anuales es crecer
constantemente, aspira a tener mejores ganancias. No obstante, se necesita tener ciertos
aspectos para realizar esto, por ejemplo, vender sus productos a nivel nacional, esto
ayudara al público objetivo pueda reconocer con mayor facilidad la marca.
Para que se realice esto se debe implementar varios puntos de ventas a lo largo del
país es decir una en cada departamento o provincias o distritos, esto ayudara a los
residentes de esa localidad pueden visitarla y conocer más sobre ella. Sin embargo, esto
implique varios gastos como en el alquiler de un espacio para el local, la implementación
de la tienda, la exposición de los productos, todo el tema visual (graficas, diseño de
muebles), los equipos físicos, software especializado para tiendas, gastos fijos y variables.
Lo negativo de esta idea es el apartado geográfico es decir por un tema de logística es un
poco difícil apertura varios centros de ventas.
Otro problema es el espacio limitado en los almacenes, al ser una zona física debe
tener dimensiones ya fijadas en el contrato. A esto se le hace una planificación por el área
comercial para que puede analizar los cubicajes y poder enviar la mercadería necesaria y
así la tienda pueda tener un poco de cada colección de productos. Este es un punto clave
ya que el sector retail de venta de productos se basa en los gustos personales, en pocas
palabras si un cliente viene decidido a comprar, pero no encuentra su talla se ira a la
competencia y culmina la compra en ese lugar.
Otro aspecto es la tecnología estamos en una constante evolución en la actualidad,
hay una cantidad de usuarios conectado desde su celular “60% mobile y 40% desktop”
14
(Joanna Carter, 2019). Esta tarea les ayuda a hacer sus actividades más rápido o coordinar
o comunicarse.
Un punto no menos importante es la atención, con esto deseo explicar que el
horario de apertura y de cierre de una tienda es un promedio de 10:00 a.m. hasta 22:00
p.m. Habrá grupo de personas que no podrán asistir puesto se encuentra laborando o
estudiando o realizando otra actividad en ese rango de horario. Al no tener una tienda
abierta las 24 horas estas personas están obligadas a ir un fin de semana sumándole que
hay una probabilidad que la talla o producto que vio ya no se encuentre disponible.
Ante esta necesidad se vio necesario investigar como poder mejorar estos aspectos
y/o procesos, trayendo como consecuencia la implementación de un sitio de ventas online,
aquí surge una nueva interrogante: ¿qué plataforma usar o es necesario hacer un
desarrollar desde 0?
En la actualidad, existe una gran variedad de plataformas e-commerce, por
ejemplo: Shopify, PrestaShop, Magento, SAP Hybris, Vtex, Oracle, Ibm, Salesforce y
otras más.
En caso de que se opte por un desarrollo propio, esto implicaría un tiempo
adicional además se debería tener todo el conocimiento para así poder desarrollar todos
los requerimientos necesarios y sobre todo optimizar el sitio ya que tendrá un alto tráfico.
Posteriormente se debe analizar si la empresa cuenta con el presupuesto necesario
para hacer una inversión en una plataforma que cumple con todos los requerimientos
principales como: el flujo de compra (inicio de sesión, búsqueda, página de categoría,
página del producto, agregar al carrito, página de pago y gracias por tu compra),
Inventario de producto, gestor de clientes, gestor de promociones, estándares de
seguridad, sea escalable.
15
Se debe tener en cuenta que la empresa tiene un sistema de tienda y esta debería
ser el eje principal porque brindara la información del producto como características,
componentes, stock, precio, tiendas, promociones y otros más. Debería estar integrada
directamente con el e-commerce.
16
1.1.2. Árbol de problema
En la posterior Figura 1. Podemos divisar el árbol de problema a partir de los
objetivos anteriores:
Fuente: Elaboración Propia
Figura 1. Árbol de problema
Incrementar las ventas de productos deportivos a través de una plataforma e-commerce open source (Magento).
Poca variedad de producto, pocas ventas.
Horario de apertura y de cierre de tiendas
físicas.
Limitaciones en espacio en los
almacenes físicos.
Deficiencia en la atención de
los clientes.
No se cuenta con una automatización
de creación de ordenes de servicios
del courier
Creación manual de ordenes de servicios.
17
1.1.3. Formulación del Problema
En la siguiente Tabla 1, se muestra un cuadro de las causas y los efectos
identificados en la implementación y optimización de una plataforma e-commerce. Esto
nos ayudara a conseguir nuestros objetivos del proyecto.
Tabla 1. Árbol de problemas
Problema: Incrementar las ventas de productos deportivos a través de una plataforma
E-Commerce Open Source (Magento).
CAUSA EFECTO
Deficiencia en la atención de los clientes.
Horario de apertura y de cierre de tiendas
físicas.
Desconocimiento del stock de productos. Reducción de ventas a nivel de tiendas.
No se cuenta con una automatización de
creación de ordenes de servicios del
operador logístico.
Creación manual de ordenes de servicios.
Fuente: Propia Elaboración
18
1.2. Definición de objetivos
1.2.1. Objetivo general
Incrementar las ventas de productos deportivos a través de una plataforma e-
commerce Open Source (Magento).
1.2.2. Objetivos específicos
o Aumentar la disponibilidad de la atención de la tienda virtual (24/7).
o Administrar de forma eficiente el stock de la tienda virtual cumpliendo
reglas definidas.
o Realizar de forma eficiente y rápida la creación de órdenes de servicios
del operador logístico.
1.3. Alcances y limitaciones
1.3.1. Alcances
La elección fue Magento Community versión 1.9.2.3 con un lenguaje de
programación PHP además cuenta con algunas propiedades de Zend Framework también
aplica MVC (modelo-vista-controlador) cuenta con Msql como Base de datos, utiliza el
modelo de entidad-atributo-valor para almacenar datos. Ya que se puede migrar más
adelante a una versión Cloud o Enterprise.
La plataforma de ventas online nos permite generar contenido al producto es decir
todos los atributos relacionados a este como color, nombre, genero, edad, marca, precio,
precio con descuento, inventario (stock), categorización y otros atributos.
Nos permite crear landing page, bloques estáticos para que automatice algunas
funciones rutinarias. Cuenta con un proceso de venta predeterminado que a su vez puede
ir variando según las necesidades.
19
Se debe crear ciertos módulos para el funcionamiento. Por ejemplo, las
ubicaciones de los clientes (departamento, provincia, distrito con Ubigeo) esto ayudara
para hacer una integración con el proveedor logístico.
Implementación de las pasarelas de pago, creación de un modulo de libro de
reclamación para protegerse de las multas al no tenerlo, implementar un flujo de estados
dentro de los pedidos para poder llevar un orden, datos extras del cliente (boleta o
factura(ruc)).
Implementación de front-end para tener una mejor experiencia, decir tener
practicas de UX por ejemplo ubicaciones de los botones, si es Mobile tiene que ser
responsiva implica hacer ciertas modificaciones para lograr esto.
Se debe tener en cuenta que Magento tiene un modelo de check out, el cuales un
poco largo por la cantidad de clic, se va a requerir simplificar el modo de compra, es decir
usar un modelo de check out.
El cliente actual debe iniciar sesión con su correo o por Facebook según su
preferencia.
1.3.2. Limitaciones
• La plataforma solo puede generar ventas desde el administrador o desde el front-
end.
• Tiene una configuración para que solo utilice un dominio puesto que hay empresas
que usan multi-store es decir 2 tiendas con un solo administrador.
• No permite hacer retargetting (remarketing) puesto necesita ciertos elementos
para poder realizarlo (configuración de Google Analytics, Google Tag Manager).
20
1.4. Justificación
El proyecto de implementar una plataforma traerá beneficios a un largo plaza ya
que al ser relativamente nuevo en el país recién las personas se están adaptando hacer
compras por internet por el temor a la inseguridad de sus datos.
La tienda virtual esta abierta las 24 horas de los 7 días de la semana es decir no
dejará de funcionar salvo un error técnico que no permita realizar esto, se podrá enviar a
todas las partes a nivel nacional posiblemente (dependiendo del proveedor logístico).
Se tendrá un mayor surtido de productos puesto que se generarán reglas para
contabilizar stock de tiendas y de los almacenes principales.
Al realizar esto generara un mayor reconocimiento de la marca puesto que las
personas tienen acceso a internet más rápido y podrá verificar las colecciones de
productos.
1.5. Estado del Arte
Hoy en día podemos ver que diversas empresas del sector retail (departamentales
o especificas) ya cuenta con una plataforma de ventas online.
Tenemos el informe del cuadrante mágico de Gartner donde podemos visualizar
varias plataformas usadas en la actualidad la cual podemos ver en la figura 2.
Este informe esta enfocado a satisfacer las necesidades a futuro de los usuarios
finales. “Gartner define el mercado del comercio digital como la compra y venta de bienes
y servicios utilizando tecnologías de digitalización que resultan en una transacción de
valor para el cliente.”
Las plataformas de comercio electrónico cuentan con varias funcionalidades entre
esas tenemos: Gestión de Productos, Carrito de compras, Checkout, Thank you page,
sistema de SEO, búsqueda de productos en toda la tienda, visualizar los puntos de ventas
físicos, reportes y sobre todo seguridad.
21
Figura 2. Cuadrante de Mágico de Gartner
Fuente: https://www.gartner.com/doc/reprints?id=1-58BE78T&ct=180720&st=sb
Se analizo otro informe de the forrester para definir cuales eran lo lideres en la
actualidad, podemos ver en la Figura 3. Que los líderes son SAP Hybris y Salesforce
Commerce y otros como Magento, IBM y KIBO. Para hacer la elección de los lideres se
baso en los siguientes puntos: tiempo de ejecución desde la personalización de la tienda
virtual particularmente en las capacidades de aprendizaje automático implica IA esto
ayudaría a previsualizar productos sugeridos por anteriores compras o recomendaciones
en búsqueda.
22
Figura 3. Forrester Wave: B2C Commerce Suites, Q3 2018
Fuente:https://cdn2.hubspot.net/hubfs/4784080/Files/Website%20PDFs/EN/Other%20S
tudies/The_Forrester_Wave%E2%84%A2-B2C_Commerce_Suites-Q3_2018.pdf
Según los informes que fueron mencionados anteriormente podemos indagar un
poco más sobre estas plataformas que son robustas, internacionales, seguras y apuntan a
hacer crecer el negocio:
IBM WebSphere Commerce:
Admiten los siguientes modelos de negocios B2C y B2B, existe un amplio
ecosistema de aplicaciones que se interconectan con su plataforma de comercio tales
como, IBM Watson Commerce incluye IBM WebSphere Commerce, Gestión de
pedidos; Watson Commerce Insights; Precio dinámico; Watson Content centro de
23
operaciones; Compromiso de la tienda; y Configurar, Precio, Cotización. IBM
WebSphere Commerce tiene una gran amplia gama de funciones, a demás tiene un
enorme ecosistema ofrece una gran cantidad de productos que deberían integrarse.
Figura 4. Logo de IBM Watson
Fuente: IBM
SAP Hybris Commerce:
Se puede hospedar en forma local o teniendo la infraestructura en la nube privada
o publico.
La suite SAP Customer Experience, con la marca SAP C/4HANA, también
incluye Marketing Cloud, Sales Cloud, Service Cloud y Customer Data Cloud. Además,
el proveedor también ofrece una capa de agilidad de microservicios.
Figura 5. Logo de SAP Hybris
Fuente: https://www.sap.com/latinamerica/products/crm/e-commerce-
platforms/pricing.html
Oracle Commerce:
Cuenta con una variedad soluciones SaaS o software local (Oracle Commerce o
Commerce Cloud) ambos productos están dirigidos a B2B y B2C lo bueno que utilizan
tecnología común.
Estas soluciones cuentan con integraciones nativas con otros productos Oracle,
como Oracle Content y Experience Cloud, Integration Cloud Service, Data Cloud, Mobile
24
Cloud Service para Bots y CPQ Cloud. Ambas utilizan la misma base de código para los
servicios principales, utilizan API REST para como fuente principal del IU y aplicaciones
de Oracle para sacar mayor provecho de la herramienta.
Figura 6. Proceso de Oracle Commerce Cloud
Fuente: https://blogs.oracle.com/cx/is-my-b2b-business-ready-for-oracle-commerce-
cloud
Salesforce Commerce:
Es líder por tercera vez consecutiva en el cuadrante de Gartner, ofrece
funcionalidades como gestión de inventarios, búsquedas en el sitio, personalización,
clienteling (experiencia del cliente), lo mejor de esta plataforma es la incorporación de
un sistema de inteligencia artificial de propio Salesforce conocido como Einstein, nos
permitirá hacer una mejor búsqueda y recomendaciones de productos todos basados en
compras previas. Tiene una integración con todos los servicios que proporciona
Salesforce como su CRM, Marketing Cloud, Sales Cloud y otras más.
Figura 7. Logo de Salesforce
Fuente: https://www.salesforce.com/es/
25
Magento:
Es una plataforma de código liberado (open Source) su función básica es
implementar una tienda virtual, es decir nos puede brindar lo básico para empezar a
vendar vía online. Además, nos permite la construcción de un sitio totalmente
personalizable puesto que es libre y sobre todo tener el control de las funcionalidades.
Existen dos versiones: Community y Enterprise.
Figura 8. Logo de Magento
Fuente: https://Magento.com/
Hacemos un cuadro comparativo entre las otras plataformas open source que
existe que a su vez son las mas populares:
Tabla 2. Comparación de CMS Open Source
MAGENTO WOOCOMERCE PRESTASHOP
Código abierto Código abierto Código abierto
Robusta y compleja al
configurar todos
sus parámetros, su buenas
practicas para crear modulo lo
hacen es estable y optimo.
Esta en un periodo de
crecimiento constante, al ser
un plugin de wordpress.
Es una de las plataforma que
hace unos años estaba a la
vanguardia,
pero woocomerce le esta
ganando terreno.
Tiene versión de pago y
gratuita.
Diseñada para que funcione
con wordpress esto lo puede
Solo tiene una versión y es
gratuita.
26
Funciona en: Linux, Apache,
PHP y MySQL.
Funciona en: Linux, Apache
o Nginx, PHP y MySQL.
Funciona en: Linux o
Windows o MacOs,Apache
o Nginx, PHP yMySQL.
Hechas para Mediana o
grandes empresas.
Hecha para pequeñas
empresas
Hecha para medianas
empresas.
Puede soportar una gran
cantidad de trafico siempre y
cuando tenga una
buena arquitectura.
No se comporta de manera
optima cuando tiene una gran
cantidad de tráfico.
No se comporta de manera
optima cuando tiene una gran
cantidad de tráfico.
Parches de seguridad en
tiempos cortos, cuenta con la
opción de multiplestiendas
Problemas de seguridad por
estar unida a wordpress.
No tiene la opción de
multiples tiendas en el sitio
El proveedor del ERP de la
empresa tiene una integración
con este CMS.
El proveedor del ERP no
tiene
El proveedor del ERP de la
empresa tiene una integración
con este CMS.
Fuente: Elaboración Propia
TESIS
(Carlos Quer Barberá, 2016 - 2017) Implantación de una plataforma eCommerce
basada en SAP Hybris para una empresa multinacional del sector servicios.
Este informe de tesis me ayudo a ver como es el trabajo en equipo ya que se
dividen en dos equipos de Backend y Frontend con la finalidad que el primero cumpla
con las necesidades de la empresa, mientras el segundo se encargara de traer algo atractivo
para el cliente el cual debe ser intuitiva y rápida.
27
(Daniel Andrés Manque Paineo ,2017) INTEGRACIÓN DE E-COMMERCE Y
BUSINESS INTELLIGENCE CON TECNOLOGÍA OPEN SOURCE PARA PYMES
Implementar una plataforma E-Commerce a una Pyme, esto conllevaría una
analista de business intelligence. Lo que aporto en mi informe es el funcionamiento de la
tienda online los 365 días del año.
28
CAPITULO 2
MARCO TEÓRICO
En estos párrafos se mencionarán y se describirían en forma específicos para poder
comprender mejor el proyecto:
2.1.METODOLOGIA
Nos estaremos basando en dos marcos de trabajo, para la gestión global de
proyecto haremos uso de PMI (Project Management Institute) y para la implementación
hare uso de Scrum.
2.1.1. PMI
El Project Management Institute (o PMI) tiene como instrumento la guía de
PMBOK y sus siglas significa: Project Management Body of Knowledge (el Compendio
del Saber de la Gestión de Proyectos), esto nos quiere decir: es el estándar para la
Administración de Proyectos.
Usaremos las siguientes fases para poder implementar el proyecto:
• Fase 1: Iniciación
• Fase 2: Planificación
• Fase 3: Ejecución
• Fase 4: Cierre
Estas fases se estarán explicando con mayor detalles en el marco metodológico.
2.1.2. SCRUM
SCRUM es un marco de trabajo o un Framework para el desarrollo Ágil de
productos el cual puede ser un software o un proyecto basado en este, gracias a
sus principios, prácticas y valores ágiles podemos lograr las metas del proyecto.
Se presentó en 1995 y hoy en día, más del 70% de los equipos de desarrollo de
Software en el mundo lo usan.
29
Los Eventos Scrum
Se utilizan para disminuir la necesidad de reuniones no definidas en Scrum y
establecer un flujo de trabajo para tener una mejor comunicación y colaboración para
poder reducir el tiempo en reuniones extensas, esto tiene un efecto de reducción de
procesos restrictivos y predictivos
Todos los eventos tienen una caja de tiempo o “TimeBox”. Una vez que se inicia
un Sprint este tiene una duración fija y no se puede acortar o alargar.
Los eventos de Scrum son:
• Sprint
El Sprint es un período en el cual se realiza el trabajo. Además, se recomienda que
la duración de este sea constante y definida por el mismo equipo por la experiencia. Se
puede empezar con una duración en particular, aproximadamente 2 o 3 semanas y luego
ir ajustando según el ritmo del equipo sin relajarlo mucho. Al finalizar, el equipo debe
presentar los avances realizados y el resultado.
El tiempo de un Sprint es de 2 o 4 semanas aproximadamente.
• Sprint Planning
Al comienzo de un sprint, el equipo de scrum tiene un evento de planificación de
sprint. Con la finalidad de identificar, analizar, comunicar o verificar cuánto del trabajo
se puede hacer en cada sprint.
• Daily Scrum
También llamado Daily Standup. Cada día durante la iteración, tiene lugar una
reunión de estado del proyecto. Su objetivo es que los miembros del equipo se mantengan
actualizados unos a otros sobre el trabajo de cada uno desde el ultimo standup, qué
problemas han encontrado o proveen encontrar, y qué planean hacer.2
La reunión tiene una duración fija de entre 5 y 15 minutos.
30
Se recomienda hacerla de pie para recordar que debe ser una reunión breve y
centrada en su objetivo, sin divagaciones. Es obligatorio parar todo lo que se está
haciendo para concentrarse en la reunión.
Si se requiere ampliar un tema, se hará tras el Daily Standup, pero no se interrumpe
la dinámica del Standup para elaborar una discusión.
Se hace siempre a la misma hora y en el mismo lugar. Si falta alguien, no se
pospone la reunión.
• Sprint Review
Al final de un sprint, el equipo realiza dos eventos: la revisión del sprint y la
retrospectiva del sprint.
En la reunión de revisión de sprint se presentan los trabajos completados y su
duración no debería ser superior a 4 horas para un Sprint de 1 mes.
• Sprint Retrospective
Al finalizar cada sprint, se lleva a cabo una retrospectiva del sprint, consiste que
todos los miembros del equipo dejan sus comentarios o sugerencias sobre el sprint que
acaba de superar o de terminar. El objetivo fundamental de la retrospectiva es realizar una
mejora continua del proceso. Esta reunión tiene una duración como mínimo de cuatro
horas.
31
Figura 9.Scrum
Fuente: Scrum.org
Artefactos Scrum
Los artefactos de Scrum formas para proveer transparencia y oportunidades de
inspección y adaptación. Los artefactos definidos por Scrum están específicamente
definidos para fomentar la transparencia de la información de tal manera que todos tengan
el mismo entendimiento de lo que se está llevando a cabo a través de los artefactos. Los
artefactos Scrum son:
o Product Backlog
o Sprint Backlog
o Increment
Roles de Scrum
En Scrum vamos a encontrar los siguientes roles: El Product Owner, el Scrum
Master y el Equipo de desarrollo. Un equipo está conformado entre 3 a 9 miembros más
el Scrum Master y el equipo de Desarrollo.
Cada rol tiene sus propias responsabilidades bien definidas, esto conllevará a que
deberá rendir cuentas de distinta manera a favor del proyecto para la empresa. La suma
32
de todos los roles de Scrum es el Equipo Scrum. En la figura 10 podemos ver los roles y
en la 11 los procesos que se llevan en Scrum.
Figura 10. Roles de Scrum
Fuente: Scrum.org
Figura 11.Flujo del proceso de Scrum
Fuente: https://www.ntaskmanager.com/blog/scrum-meetings/
33
2.1.3. MAGENTO
Es gestor de contenidos web de código abierto para comercio electrónico. En la
actualidad existe 2 versiones de Magento como:
A. Magento Open Source (Community)
Magneto Community es la plataforma actualmente adquirida por Adobe, que se
encarga del comercio electrónico la cual es código abierto, cuenta con muchas
características significativas siendo capaces de hacer varias modificaciones en su núcleo
creando plugins que reemplaza los eventos principales.
Los desarrolladores hacen que se pueda implementar los archivos del núcleo
ampliando su funcionalidad a través de nuevos módulos plug-in, los cuales son
proporcionados por un tercero o creado por uno mismo.
En el 2007 fue liberada la primera versión beta pública, por lo cual Community
Edition y se ha creado una comunidad que va encontrado nuevas cosas para mejorarlo y
hacerlo mas robusto.
B. Magento Enterprise Edition
La versión Enterprise Edition es una variante de Magento Open Source que posee
el mismo núcleo de archivos, en relación con el Open Source, este no es gratuito tiene un
costo por la licencia, pero contiene una gran variedad de características y funcionalidad.
Esta edición esta creada especialmente para grandes empresas en las cuales se requiere
de un soporte técnico de instalación, el uso, la configuración y la solución de problemas.
Ambas versiones de Magento no se incluye el alojamiento, por lo cual se debe
verificar donde podría ser el sitio más adecuado.
34
2.1.4. GITLAB
Es un servicio web de control de versiones y desarrollo de software colaborativo
basado en Git. Además de gestor de repositorios, el servicio ofrece también alojamiento
de wikis y un sistema de seguimiento de errores, todo ello publicado bajo una Licencia
de código abierto.
Figura 12. Gitlab
Fuente: about.gitlab.com
2.1.5. PHP (Hypertext Preprocessor)
“Es un lenguaje de código abierto muy popular especialmente adecuado para el
desarrollo web, diseñado originalmente para la creación de Páginas web dinámicas”.
Publicado bajo la PHP License, la Free Software Foundation considera como open
source. ("PHP: ¿Qué es PHP? - Manual", s.f.)
Figura 13. Logo lenguaje de Programación PHP
Fuente: https://www.php.net/manual/es/intro-whatis.php
35
2.1.6. MYSQL
Es un sistema de gestión de base de datos relacional (RDBMS) el cuales es de
código abierto, basado en lenguaje de consulta estructurado (SQL). Actualmente es el
líder en aplicaciones web o sitios web, debido a su veracidad, fiabilidad y simplicidad de
uso.
Figura 14. Logo de la Base de datos
Fuente: https://www.mysql.com/
2.1.7. Modelo de datos
Magento sigue un esquema ORM (Mapeador Objeto-relacional). ORM define un
sistema de conversión de datos entre una programación orientada a objetos y una base de
datos relacional.
Existen 2 tipos de entidades gestionadas por modelos:
• FLAT: implementa un mapeo sencillo de un objeto a una tabla, esto
significa que cada atributo del objeto coincide con un campo de la
estructura de la tabla.
• EAV: describe una entidad con un número dinámico de atributos
Cada tipo de entidad está formado por 3 capas de modelos:
o Model Class
o Resource Model Class
o Model Collection Class
36
Un “Model” es usado para trabajar una entidad individual, une la lógica del
negocio con la lógica de datos.
Un “Resource Model” es usado para interactuar con la base de datos (o la capa de
persistencia de datos) en nombre del modelo. Actualmente sigue el esquema CRUD
(Crear, Obtener, Actualizar, Borrar).
Un “Collection” proporciona los mecanismos para obtener y trabajar varias
entidades al mismo tiempo usando el “Resource Model”.
2.1.7.1.Modelo Eav
El modelo Entity Attribute Value es un modelo de datos para describir entidades
donde el número de atributos (propiedades y parámetros) que se pueden usar para
describirlos es potencialmente vasto, pero el número de atributos que realmente se
aplicarán a una entidad dada es relativamente modesto.
En matemáticas, este modelo se conoce como una matriz dispersa. EAV también
se conoce como modelo objeto-atributo-valor, modelo de base de datos vertical y
esquema abierto.
EAV significa Entidad, Atributo y Valor. Explicaremos cada definición para
poder entender mejor cada punto.
• Entidad: La entidad representa elementos de datos de Magento, como
productos, categorías, clientes y pedidos. Cada entidad (producto, categoría,
etc.) tendrá su propio registro de entidad en la base de datos.
• Atributo: los atributos representan elementos de datos que pertenecen a una
entidad. Por ejemplo, la entidad del producto tiene atributos como nombre,
precio, estado y muchos más.
• Valor: el valor es el más simple de entender, ya que es simplemente un valor
vinculado a un atributo. Para una mejor comprensión, consideremos la entidad
37
del producto. Cada entidad de producto tendrá una serie de atributos, uno de
ellos es el atributo de nombre. Cada producto tendrá un valor para el atributo
de nombre (y todos los demás atributos). ¡Esto puede no estar claro todavía,
pero sigue leyendo!
Figura 15. Modelo EAV
Fuente: Magento
Figura 16. Modelo EAV
Fuente: https://blog.magestore.com/entity-attribute-value-in-Magento/
38
2.2.MARCO LEGAL
2.2.1. LEY Nº 29733
Como es de su conocimiento, esta ley es sobre la Protección de Datos Personales
del Perú la cual tiene como objetivo salvaguardar o proteger todos los datos personales
(sensibles), regulando un adecuado tratamiento de estos. Los datos deben estar incluidos
en un banco de datos, el cual será registrado ante el ente responsable.
Las empresas, entidades publicas, instituciones del sector privado y personas
naturales deben cumplir con esto.
Los requisitos son para cumplir la ley son los siguientes puntos:
a) Obtención de datos.
b) Transferencia
c) Declaración de base de datos
d) Derecho Arco
e) Medidas organizativas
f) Medidas Legales
g) Medidas técnicas
Figura 17. Cronología de la Legislación
Fuente: https://www2.deloitte.com/pe/es/pages/risk/articles/data_law_protection.html#
39
2.3.MARCO METODOLOGICO
Para poder llegar a la solución del problema nos vamos a basar en PMI porque
nos ayudara a la gestión del proyecto y Scrum para el desarrollo en si y así poder
conseguir a cumplir con todos los requerimientos.
Se hizo la elección de estos dos marcos puesto PMI encajaba bien con el plan de
trabajo que se manejara para hacer esta implementación.
2.3.1. FASES DEL PROYECTO
La gestión se llevará acabo en las siguientes fases:
o Fase 1: Iniciación
o Fase 2: Planificación
o Fase 3: Ejecución
o Fase 4: Cierre
Estas se van a desarrollar de la siguiente manera:
2.3.1.1.FASE 1- INICIACIÓN
En esta fase vamos a desarrollar todo lo que se va a necesitar para el proyecto, los
tiempos definidos, los objetivos y el alcance.
Para esto vamos a desarrollar lo siguiente:
2.3.1.1.1. PROJECT CHARTER
Nos ayudara a definir los objetivos, los beneficios, la finalidad del proyecto.
Además, quienes serian los involucrados con el proyecto.
En el anexo 1 veremos el formato de este.
2.3.1.1.2. Gestión De Interesados Del Proyecto
Vamos a designar los responsables y cuales serán las actividades realizadas por
cada uno de ellos.
El formato lo podemos ver en el anexo 2.
40
2.3.1.2.FASE 2 – PLANIFICACIÓN
Se desarrollará todo lo que se vera en el proyecto con ayuda de algunos procesos para
poder llevar el control del proyecto.
2.3.1.2.1. Cronograma
Vamos a tener un cronograma donde definimos nuestras actividades con inicio –
fin con fecha. Anexo 3
2.3.1.2.2. Work Breakdown Structure (WBS)
Conocido también como Estructura Desagregada de Trabajo (EDT), consiste
en partir al proyecto en menores partes o componentes para agilizar la planificación del
proyecto, con esto se puede dar una visión estructurada de lo que se debe enviar o entregar
según los acuerdos.
Se puede decir que es una descomposición jerárquica del alcance total del trabajo
a realizar por el equipo del proyecto. Ver Anexo 4.
2.3.1.2.3. Gestión De Comunicaciones
Esto lo vamos a definir según el formato de RAM (matriz de asignación de
responsabilidades) quienes serán los responsables Primarios y Secundarios según las
fases del proyecto. Ver Anexo 3
2.3.1.2.4. Gestión De Riesgos
La gestión de riesgo tiene como objetivo identificar los posibles riesgos que puede
ocurrir en el desarrollo del proyecto, se ejecutara a través de un documento.
Estaremos definiendo los riesgos dentro de la planificación del proyecto siguiendo
las siguientes tablas para poder definir de manera optima el impacto y la probabilidad de
esta:
Tabla 2 veremos los valores ante una posibilidad de riesgo.
41
Tabla 3 veremos el impacto de estos riegos
Tabla 4 veremos una semaforización de estos riegos.
Tabla 5 Categorización de riesgo, es decir las prioridades.
Tabla 3. Valores para estimar de Riesgos
Estimación Verbal Rangos Descripción
MA Muy Alta Entre 80% y 100% Puede ocurrir en 1 en 2 meses, al
momento de finalizar el proyecto
A Alta Entre 60% y menor a 80% Puede ocurrir una cada 4 meses
M Media Entre 40% y menor a 60% Puede ocurrir más de 1 en 6 meses
B Baja Entre 20% y menor a 40% Puede ocurrir una a cada 8 meses
MB Muy Baja Menor a 20% Puede ocurrir una a cada 12 meses
Fuente: Elaboración Propia
Tabla 4. Valores para estimar Impacto
Estimación Verbal
Proy Especiales Mantenimiento
Rango Rango
MA Muy Alta (Mayor a 72) hh (Mayor a 48) hh
A Alta (más de 56 a 72) hh (más de 24 a 48) hh
M Media (más de 32 a 56) hh (más de 16 a 24) hh
B Baja (más de 16 a 32) hh (más de 8 a 16) hh
MB Muy Baja (de 1 a 16) hh (de 1 a 8) hh
Fuente: Elaboración Propia
Tabla 5. Semaforización de Riesgos
42
Tabla 6. Categorización de los Riesgos
2.3.1.2.5. Documento De Riesgo Presentado
En este documento podemos ver la descripción de los riegos, cual seria su
impacto, la probabilidad, severidad de este como también la respuesta para mitigar este
riesgo, estos divididos en categorías. Ver anexo 5.
2.3.1.3. FASE 3 – EJECICIÓN
En esta fase comenzaremos con las fases de Scrum para hacer el desarrollo
personalizado de Magento.
43
2.3.1.3.1. SPRINT 0
Es un paso previo al desarrollo que nos permite establecer una base sobre la que
trabajar, se puede definir las características de producto, la estructura de Product Backlog
y el Equipo.
Nos va a permitir conocer o definir las historias de usuario antes de iniciar Sprint.
Ver Anexo 6.
2.3.1.3.2. PRODUCT BACKLOG
Básicamente es una lista de todas las cosas que deben hacerse dentro del proyecto.
Todas las tareas o requerimientos se deben poner en este documento para que todo el
equipo puede verificarlo. Ver Anexo 7.
2.3.1.3.3. DEFINICIÓN DE LOS SPRINT 1 y 2
En este documento están las tareas que se realizaran según el product backlog,
dependiendo de sprint que le corresponda. Ver anexo 8.
2.3.1.3.4. SPRINT 1
o FASE DE PLANIFICACIÓN
▪ Revisión y Modificación Del Sprint Backlog: se usará el mismo
documento del anexo 8 para planificar los posibles cambios que se
pueden hacer para hacerlo especifico y claro respecto al Sprint 1.
▪ Gestión de riesgos: Para poder mitigar algún posible incidente y
poder cumplir con todo el tiempo indicado.
o FASE DE ANALISIS
▪ Revisión Y Modificación De Historias De Usuario: se usará el
anexo 6.
▪ Revisión Y Modificación De Product Backlog: Se usará el anexo
7 para desarrollar este punto.
44
▪ Diseño De Prototipos encontraremos mockups o posibles vistas del
sistema.
o FASE DE DISEÑO:
▪ Nos basaremos en el formato de EVA propio de Magento, se
agrega las tablas y los campos nuevos que se llevo en la
personalización de Magento.
o FASE DE CONSTRUCCIÓN Y PRUEBAS:
▪ Se adjuntará en el anexo 8 el formato de las pruebas que se
realizará en el sprint 1.
▪ Se ejecutará pruebas de funcionalidad.
▪ Se ejecutará pruebas de vulnerabilidades.
▪ Se ejecutará pruebas de Optimización.
• Usaremos las herramientas de Google para verificar el
score, seo, buenas practicas, usabilidad y performance.
o FASE DE IMPLEMENTACIÓN:
▪ Se desarrollará a través de los Sprint.
2.3.1.3.5. SPRINT 2
o FASE DE PLANIFICACIÓN
▪ Revisión y Modificación Del Sprint Backlog: se usará el mismo
documento del anexo 8 para planificar los posibles cambios que se
pueden hacer para hacerlo especifico y claro respecto al Sprint 2.
▪ Gestión de riesgos: Para poder mitigar algún posible incidente y
poder cumplir con todo el tiempo indicado.
45
o FASE DE ANALISIS
▪ Revisión y Modificación De Historias De Usuario: según el anexo
6 se hará el análisis de las HU adjuntas y se verificaran si necesita
algún ajuste.
▪ Revisión y Modificación De Product Backlog: Se usará el anexo 7
para desarrollar este punto.
▪ Diseño De Prototipos encontraremos mockups o posibles vistas del
sistema.
o FASE DE DISEÑO:
▪ Nos basaremos en el formato de EVA propio de Magento, se
agrega las tablas y los campos nuevos que se llevo en la
personalización de Magento.
o FASE DE CONSTRUCCIÓN Y PRUEBAS:
▪ Se adjuntará en el anexo 8 el formato de las pruebas que se
realizará en el sprint 1.
▪ Se ejecutará pruebas de funcionalidad.
▪ Se ejecutará pruebas de vulnerabilidades.
▪ Se ejecutará pruebas de Optimización.
• Usaremos las herramientas de Google para verificar el
score, seo, buenas prácticas, usabilidad y performance.
o FASE DE IMPLEMENTACIÓN:
▪ Se desarrollará a través de los sprint.
2.3.1.4.FASE 4 – CIERRE
Usaremos una acta de cierre, el formato de esta podemos encontrarla en el
Anexo 10.
46
2.3.2. ALCANCE
El alcance del proyecto podemos definirlo dentro del Project Chárter ya que
observamos nuestros objetivos del proyecto y sobre todo cual seria la finalidad de este.
2.3.3. CALIDAD
Ejecutaremos este punto a través de pruebas funcionales se estarán definiendo
después de los Sprint, en estas pruebas veremos los siguientes puntos:
a) Pruebas de caja negra (pruebas de funcionales).
b) Prueba de optimización del sitio siguiendo algunas herramientas.
c) Revisar o instalar un modulo de revisión de compatibilidad de módulos de
Magento.
d) Revisando los de errores de Magento (system y exception).
e) Revisando el modo depurador del Magento para analizar y solucionar algunos
problemas de incompatibilidad.
En el anexo 9 se agregará una plantilla donde vamos a poner todas pruebas que se
hicieron en los sprint.
2.4.Marco conceptual
A continuación, voy a definir ciertos conceptos básicos para poder comprender
mejor de lo que se esta escribiendo, por ejemplo:
2.4.1. E-Commerce:
En pocas palabras es el comercio electrónico, también lo podemos encontrar como
comercio por Internet, se debe describir a la compra y venta de bienes o servicios a través
de la red o internet. Otro pequeño concepto es utilizado a menudo para referirse a la venta
47
de productos físicos en línea o se refiere cualquier tipo de transacción comercial que se
realice a través de Internet.
El E-Commerce tiene varios puntos positivos con respecto al comercio
tradicional:
o La disponibilidad 24/7 durante todo el tiempo.
o Lo más importante no hay problemas geográficos.
o Mejor segmentación de los clientes.
o Hacer crecer los números de usuarios nuevos.
o Variedad de productos (tallas, cantidad de tallas, etc.).
Existe los siguientes tipos de formato de E-Commerce:
a) B2B (Business-to-Business): es cuando la empresa vente un servicio o
bien a otras empresas u organizaciones.
b) B2C (Business-to-Consumer): El más conocido es: Empresas que
comercian con consumidores.
c) B2G (Business-to-Government): Empresas que comercian con
instituciones del gobierno.
d) C2C (Consumer-to-Consumer) y C2B (Consumer-to-Business)
2.4.2. Target
Básicamente se desarrolla en el área de marketing digital, la importancia de esto
es que nos puede indicar el tipo de personas al que pueda ir dirigido un producto y/o
servicio.
2.4.3. Open Source
Se define a los programas informáticos o aplicativo o software que nos permite
ingresar al código fuente, a la programación, la cual podemos hacer ciertas
48
modificaciones o las que deseamos con la ayuda otros programadores no importa si no
han iniciado el proyecto.
2.4.4. Retargetting
Conocido como remarketing, además es una técnica de marketing digital cuyo
objetivo es impactar a los usuarios que previamente han interactuado con una determinada
marca.
2.4.5. Lenguaje de programación
Un lenguaje de programación es un lenguaje de manera formal, el cual
proporciona ciertas instrucciones con el fin de permitir que el programador pueda escribir
secuencias de ordenes, algoritmos y con esto poder controlar el comportamiento físico y
lógico de un dispositivo (desktop o mobile) para que ésta produzca diversas clases de
datos. A estos, escritos a través de un lenguaje de programación, se le conoce como
programa.
2.4.6. MVC
Es un patrón de arquitectura de software el cual se encarga de separar los datos y
la lógica del negocio de una aplicación, y el módulo que se encarga de los eventos y las
comunicaciones.
Es por ese motivo que MVC propone la construcción de componentes los cuales
son: el modelo, la vista y el controlador. En otras palabras, MVC define componentes
para la representación de la información además de la interacción del usuario.
Dicho patrón se basa en las ideas de reutilización de código y la separación de
conceptos, también de características que facilitan la tarea de desarrollo de las
aplicaciones y del mantenimiento de estas.
Modelo: Información almacenada en la base de datos, esta se unirá con las reglas
del negocio.
49
Vista: Es la página web cara al cliente (HTML)
Controlador: código fuente el cual obtiene de forma dinámica los datos y tiene
la función de generar el contenido HTML.
2.4.7. Front-end
Se enfoca en el usuario o cliente final, en lo que podemos hacer es decir las
interacciones y lo que observamos mientras estamos navegando el sitio web. Esto utiliza
CSS, HTML y JS, también tiene que ver con la experiencia de usuario, inmersión y
usabilidad.
Además, para tener un buen front se necesita un recurso principal que es la
creatividad, ya que tendrá que decidir qué fuente, colores, imágenes debe utilizar para
crear sitios amigables es decir que se vean bien en todos los dispositivos y resoluciones.
2.4.8. Back-end
Es la capa de acceso a datos de un software o cualquier dispositivo, que no es
directamente accesible por los usuarios, además contiene la lógica de la aplicación que
maneja dichos datos.
El Backend también accede al servidor, que es una aplicación especializada que
entiende la forma como el navegador solicita cosas.
Figura 18. Frontend y Backend
Fuente: https://platzi.com/blog/que-es-frontend-y-backend/
50
2.4.9. Cuadrante mágico de Gartner
("Magic Quadrant Research Methodology", s.f.) Es una referencia para seguir,
puesto que el Cuadrante Mágico de Gartner lo podemos considerar como un primer paso
para comprender cuales serian los proveedores de tecnología (los lideres) que podría
considerar para una oportunidad de inversión, este informe cambia cada año.
Figura 19.Cuadrante de Gartner
Fuente: Cuadrante de Garnert
Se divide en los siguientes campos
a) Lideres: los proveedores de esta categoría obtienen la mayor puntuación
debido a la combinación de la visión del mercado y la habilidad para
ejecutar el mismo. Las empresas ofertan la solución de los productos de
una manera amplia, completa y madura, que va evolucionando de acuerdo
con la demanda del mercado.
b) Retadores: ellos se caracterizan por brindar buenas funcionalidades,
además de un gran número de instalaciones del producto. Sin embargo,
51
ofrecen una menor variedad en los productos debido a estar centrados en
un solo aspecto de la demanda del mercado.
c) Visionarios: por lo general, estos poseen todas las capacidades para
adelantarse a las necesidades del mercado, sin embargo, no tienen la
habilidad de realizar implantaciones, debido a su tamaño u otras
particularidades.
d) Nichos específicos: ellos están orientados a ciertas áreas de las tecnologías
de gestión empresarial, sin embargo, no disponen de una suite en su
totalidad.
2.4.10. Banco de datos
Nos estamos refiriendo a que cierta información está clasificada y ordenada de
acuerdo con diferentes parámetros. Porque puede ser solicitada con diversos fines las
veces que sean necesarias.
2.4.11. Datos sensibles
Es información personal del individuo las cuales podrían ser:
• Los datos biométricos como la huella digital, la retina, el iris estos
mecanismos pueden identificar a la persona,
• Datos sobre al origen racial y étnico.
• Salarios o ingresos económicos(salario).
• Opiniones o convicciones o costumbre políticas, religiosas, filosóficas o
morales; afiliación sindical.
• Información relacionada a la salud o a la vida sexual.
Solamente pueden ser objeto de tratamiento con el consentimiento.
52
2.4.12. Amazon Cloud
Se basa en un sistema de precios basado en el consumo, tiene las siguientes
tecnologías: Almacenamiento por ejemplo S3, Aplicaciones (ecom), Linux y cuales
serian los parches.
Esto es en la nube, es decir nuestro archivo se sincronizarán.
2.4.13. Seo
Es el conjunto de acciones dirigidas para el mejoramiento del posicionamiento en
los resultados de google. Se usan técnicas para optimizar los motores de búsqueda.
2.4.14. On-line
Como lo dice su nombre en línea, se refiere al estado activo en la internet.
2.4.15. Smartphone
También en la actualidad se le conoce celular inteligente, en estos días las
personas pueden elegir que Smartphone desea usar. ¿Que sistema operativo tendrá
Android? ¿O iOS?
Podemos usar para varias funciones, por ejemplo:
• Comunicarse por medido de las redes sociales.
• Usar las aplicaciones (juego o utilidades).
• Leer, escuchar música etc. acciones.
2.4.16. PYMES
Se le da esta definición a una pequeña y mediana empresa en el país.
53
2.4.17. API (Application Programming Interface)
Es un grupo de rutinas que provee acceso a funciones de un determinado software,
además es una interfaz de programación de aplicaciones.
2.4.18. Middleware
Te sirve para que puedas conectar un software a otro software, nos quiere decir
que es el interceptor que almacena y envía la data de un lado a otro.
Figura 20. Modelo de Middleware
Fuente: https://www.redhat.com/es/topics/middleware/what-is-middleware
2.4.19. Libro de reclamaciones
Es un registro donde el consumidor puede dejar constancia de su queja o reclamo
sobre el bien adquirido o servicio contratado.
Los proveedores están obligados a contar con este, ya sea en físico (libro con
hojas) o virtual (a través de una computadora).
2.4.20. Pasarela de Pago
Es un servicio que se implementa en las tiendas virtual, para facilitar a los clientes
el pago. Existen varios proveedores que te brinda el servicio de este.
54
Figura 21. Pasarela de Pagos
Fuente: Tesis: Implantación de una plataforma eCommerce basada en SAP Hybris para
una empresa multinacional del sector servicios.
2.4.21. Operador logístico
Es una empresa que se encarga de diseñar los procesos de una o varias etapas de
su cadena de suministro como son el aprovisionamiento, transporte, almacenaje y
distribución.
2.4.22. Checkout E-commerce
Se referencia a todas las fases por las que pasa un consumidor o cliente o usuario
tiene que realizar en una tienda online. Junta todas las etapas de un proceso de
compra online como: Inicio de sesión, Registro, Método de envió, método de pago.
2.4.23. Producto Configurable
Un producto configurable es un tipo de conjunto que contiene los componentes
estándar compartidos entre todos los modelos y los componentes exclusivos específicos
de cada uno de ellos.
2.4.24. Producto Simple
Es ideal para productos que no tienen variaciones sobre sí mismos. En este tipo
de producto no das opción a elegir ninguna característica.
55
2.4.25. Modulo de Magento – Plugins
Un modulo es conocido también a una extensión, la cual tiene buenas practicas
para su creación, por ejemplo, si se desea crear una nueva columna en una tabla de la base
de datos la cual interactuara con el Magento, se debe hacer una extensión. Lo que dice el
CMS es que no se debe tocar los archivos del core, en caso se desee cambiar un archivo
de ahí se debe hacer una copian al directorio y agregarlo en la carpeta app/local o
app/communitty. La figura 22 nos mostrara como se compone una extensión.
Figura 22. Modulo básico de Magento
Fuente: Elaboración Propia
app
code
local
Mimodule
ControlProductos
model
observer.php
etc
config.xml
etc
modules
Mimodulo.xml
56
CAPITULO 3
METODOLOGIA DEL DESARROLLO
Para poder llegar a la solución del problema nos vamos a basar en PMI porque
nos ayudara a la gestión del proyecto y Scrum para el desarrollo en si y así poder
conseguir a cumplir con todos los requerimientos.
Se hizo la elección de estos dos marcos puesto PMI encajaba bien con el plan de
trabajo que se manejara para hacer esta implementación.
3.1.FASES DEL PROYECTO
3.1.1. FASE 1: INICIACION
3.1.1.1.PROJECT CHARTER
Es el documento donde se detalla el alcance del proyecto y da autorización para
el inicio del proyecto.
Tabla 7. Acta de Iniciación del Proyecto
NOMBRE DEL PROYECTO SIGLAS DEL PROYECT0
Plataforma E-commerce en empresa Retail E commerce
DESCRIPCION DEL PROYECTO
La plataforma E-commerce, la cual esta alojada en un servidor optimizado para Magento. En un corto plazo estará en AWS dependiendo del crecimiento de este. El sistema nos permitirá hacer lo siguiente:
• El producto nos brindara todos los pasos de un e-commerce: home page, categorías de producto, página del producto, agregar al carrito de compras y pagar.
• Nos permite ingresar datos del cliente (datos personales).
• Nos permite generar un reclama sin necesidad de ir a la tienda física.
• El cliente puede elegir que método de pago desea aplicar.
• El cliente puede elegir la dirección de envió.
• Hacer promociones para clientes. DEFINICIÓN DEL PRODUCTO
El producto tendrá las siguientes funcionalidades:
• Creación/Edición de productos
• Creación de clientes.
• Creación de atributos para cliente y productos.
• Historial de comentarios con nuevos estados.
• Reglas en la web (pagos, envíos o promociones).
57
EL proyecto tiene una duración de 3 meses, ya que hay que desarrollar ciertos de acuerdo con el cliente, rediseñar los módulos de Magento siguiendo las buenas practicas proporcionada por este, también se deberá crear módulos personalizados para cumplir ciertos aspectos locales. Usar ciertos estándares(W3C) para poder tener un buen performance.
REQUISITOS DEL PROYECTO
El proyecto debe cumplir ciertos:
• Capturar los datos de la integración con el sistema que la empresa.
• Pueda enviar datos al RPE de la empresa.
• Cliente puede registrarse e iniciar sesión.
• Puede generar un pedido según los pasos (Búsqueda, Categoría, Página de producto, Agregar al carrito de compras, Check-out y gracias por tu compra).
• Pueda registrar reclamos.
• Pueda enviar por Web Services a los operadores logístico la data del pedido.
• Usar las pasarelas de pago para generar pagos.
• Administrar los productos en la web.
• Administrar clientes.
• Administrar promociones especificas.
• Localización de tiendas.
OBJETIVOS DEL PROYECTO
Implementar una plataforma e-commerce desde un open source Magento Community, para poder cumplir con los siguientes objetivos:
• Pueda crear una cuenta con todos sus datos para poder hacer más adelante campanas de marketing.
• Cliente pueda generar un pedido sin preocupación a que la página sea lenta o no tenga métodos de envió.
• Incrementar las ventas.
• Poder fidelizar más al cliente.
• Tener más exposición como marca.
• Poder tener una comunicación 24/7.
• Generar pedidos en cualquier lugar.
FINALIDAD DEL PROYECTO
Poder llegar a todo territorio peruano. Mejorar procesos físicos a virtuales. Tener una comunicación más integrada con el cliente (usuario final). Exponer más productos.
PROJECT MANAGER DEL PROYECTO
Nombre Plataforma e-commerce en empresa Retail Nivel de
Autoridad Descripción Implementar y personalizar una plataforma e-commerce desde un open source
Project Manager PD Cumplir con todos los entregables
Project Team Resources
TEAM
58
CRONOGRAMA DEL PROYECTO
EVENTO FECHA
Inicio de Proyecto Marzo 2016 Planificación Mayo 2016 Ejecución Junio 2016
Cierre Mayo 2016
AMENAZAS DEL PROYECTO
El proyecto no se lleve acabo con todos los requerimientos que se cumplan estos a no medida.
OPORTUNIDADES DEL PROYECTO
Implementación de una plataforma e-commerce, con todos los requerimientos pedidos, con una optima performance.
PLANEAMIENTO INICIAL DEL PROYECTO
CONCEPTO MONTO (s/.)
Equipo de Desarrollo 20.000
PRESUPUESTO TOTAL 20.000
Fuente: Elaboración Propia
3.1.1.2.GESTION DE INTERESADOS DEL PROYECTO
Es el documento donde se detalla a los interesados del proyecto, así mismo se
define las actividades que se van ha desarrollar durante el proyecto.
59
Tabla 8. Gestión de Interesados
INFORMACIÓN DE IDENTIFICACIÓN Información de evaluación Clasificación de los
interesados
Puesto Ubicación Rol en el proyecto Requisitos principales Expectativas principales
Grado de influencia
Grado de interés
Fase de mayor interés
Interno / Externo
Apoyo / Neutral / Reticente
Jefe del área e-commerce
Lima Jefe del Área Revisa los entregables
Supervisar el cumplimiento de avances del proyecto
Alto Alto Todo el
proyecto Interno Apoyo
Lima Encargado del
Proyecto Revisa que se cumpla
los requerimientos
Pedir los informes de acuerdo con el cronograma
Alto Alto Todo el
proyecto Interno Apoyo
Lima Project Manager
Dedicar todo el tiempo posible para
cumplir con los objetivos del proyecto
Entregar el proyecto en el
tiempo estimado Alto Alto
Todo el proyecto
Interno Apoyo
Analista / Progrmador
Lima Analista Analizara la
problemática e rediseñar los procesos
Supervisar el avance del proyecto
Alto Alto Todo el
proyecto Interno Apoyo
Desarrollador de la plataforma
Lima Desarrolladores
Dedicar todo tiempo posible para
desarrollar los módulos
personalizados.
Desarrollar las soluciones requeridas
Alto Alto Todo el
proyecto Interno Apoyo
Gerente Comercial Lima Scrum Máster
Dedicar todo el tiempo posible para
cumplir con los estándares de Scrum
supervisa y Aplica el marco de trabajo
Scrum Alto Alto
Todo el proyecto
Interno Apoyo
Fuente: Elaboración Propia
Fuente: Propia
60
3.1.2. FASE 2: PLANIFICACIÓN
3.1.2.1.CRONOGRAMA
A Continuación, en la tabla 7 se detalla el cronograma de actividades del proyecto,
detallamos el plan de trabajo de acuerdo con el Project Charter; particionado en 4 fases
con una duración de 4 meses (91 días).
o La primera fase es de Iniciación tiene una duración de 2 días.
o La segunda fase es de Implementación tiene duración 3 días.
o La tercera fase es Ejecución teniendo una duración de 85 días.
o La ultima fase cierre teniendo un día de duración.
61
Figura 23. Cronograma del proyecto
62
Fuente: elaboración propia
3.1.2.2.WBS o EDT
Este tiene como principal función el detallar las fases del desarrollo del proyecto,
el cual además detalla las actividades por cada fase.
63
Figura 24. EDT del Proyecto
64
fuente: Elaboración propia
65
3.1.2.3.GESTIÓN DE COMUNICACIONES
La gestión de comunicaciones tiene como objetivo mantener al usuario informado
el desarrollo del proyecto.
66
Tabla 9. Matriz de Asignaciones de Responsabilidades
Matriz de Asignación de Responsabilidades (RAM)
Responsabilidades: P: Responsable Primario, S: Responsable Secundario
Paquete de Trabajo / Actividad Responsabilidades
ID Descripción Paquete de Trabajo o Actividad Project
Manager Jefe de área Encargado del
Proyecto Analista Scrum Máster Desarrollador
1 GESTION DEL PROYECTO/PLAN DEL PROYECTO P P S S P S
2 GESTION DEL PROYECTO/ACTA DE REUNION P P P P P S
3 GESTION DEL PROYECTO/ACTA DE CONFORMIDA P P P S P S
4 GESTION DEL PROYECTO/ACTA DE CONFORMIDAD APROBADA P P P S P S
5 EJECUCION/Sprint 0 P S P P P P
6 EJECUCION/Sprint 1 P S P P P P
7 EJECUCION/Sprint 2 P S P P P P
8 CIERRE/Acta de Conformidad P P P S P S
Fuente: elaboración propia
67
3.1.2.4.GESTION DE RIESGOS
En la siguiente tabla podemos visualizar la matriz de riesgo, mostrando los
posibles riesgos que se pueden dar durante el proyecto detallando el porcentaje (%) de
consecuencia, probabilidad que ocurra y factor de riegos.
Según las matrices anteriores podemos sacar la siguiente data adjunta en la tabla
posterior.
68
Tabla 10. Tabla de Riesgos
REGISTRO DE RIESGOS
Area/Linea Linea 1
Exposición total al Riesgo 21%
Identificación Analisis Planificación Respuesta Monitoreo
Nr Descripción de Riesgos Categoría Probab. Impacto Severidad Responsable Respuesta Disparador Estado Contingencia
1 Que no se termine el proyecto en
el plazo indicado. Proyecto 0.3 3 0.9 AP
Trabajar tiempo extra, priorizar el trabajo en equipo, para terminar el proyecto en la fecha establecida.
Incumplimiento de Fechas establecidas
No incurrido
2 No disponer de tiempo para
Reuniones Proyecto 0.3 2 0.6 PD
Organizar mejor el tiempo a disponer para realizar el proyecto. Respetar los compromisos al inicio del proyecto.
Falta de Coordinación y Trabajo en Grupo
No incurrido
3 No contar con los equipos de
computo en la fecha indicada para desarrollo de Software
Tecnología 0.1 3 0.3 AP Contar con equipos de contingencia.
Incumplimiento de Fechas establecidas
No incurrido
4 Que el producto no cumpla las
expectativas del cliente Producto 0.3 5 1.5 PD
Informar al cliente de manera detallada sobre el avance del producto.
Señales de inconformidad por parte del cliente, en
reuniones. No incurrido
5 Pérdida de documentación
referente al proyecto Proyecto 0.1 3 0.3 AP
Establecer un Repositorio de Archivos
Perdida de Documentos No incurrido
6 Controlar las versiones del
proyecto Proyecto 0.3 3 0.9 PD
Almacenar las versiones por medio de un GIT
Documentos no cumplen estándares de calidad
Desaparecio
Almacenar en Gitlab las versiones con comentarios
7 Controlar la seguridad del cms Tecnología 0.4 4 1.6 PD
Contar con una politica de seguridad (cambio de url de dominio admin, bloquear accesos a los distintos puntos de ingresos al admin)
Acceso no permitido a las instancias de la infraestructura
No incurrido
8 Ingreso no permitido al
administrador Tecnología 0.4 4 1.6 PD
Politica de cambio de contraseña (3 veces por mes)
Colaboradores pueden ingresar a ciertos partes que no tenga permiso
No incurrido
69
9 Seguridad en el Proceso de Pago Tecnología 0.4 4 1.6 PD Tener un certificado de Seguridad dado por el Balanceador de AWS
Problemas con las pasarelas de pago
No incurrido
10 Seguridad ante cambios fuera del
horario Tecnología 0.3 4 1.2 PD
WAF de AWS para controlar los cambios no perminitidos
Cambios no permitidos en el CMS (landing page o
productos) no incurrido
11 Incremento de tráfico en el sitio
web Tecnología 0.3 3 0.9 PD
Cambio de Instancias RDS o EC2
Lentitud en el sitio o alertas constantes de
AWS - Monitoreo Desaparecio
Tener mapeada las instancias de cambio.
Fuente: elaboración propia
70
3.1.3. FASE 3: EJECUCION
A través del marco de trabajo SCRUM vamos a definir lo fases del desarrollo de
proyecto comenzaremos con un Split 0 para definir todos los requerimientos.
3.1.3.1.SPRINT 0
Como consecuencia de las reuniones iniciales con la encargada del área se define
las historias de usuarios, posterior a esto al recolectar estos datos se puede iniciar a
conformaron del requerimiento.
Nos servirá para reconocer los requerimientos más complejos y los menos
complejos para decidir cual seria el flujo correcto de desarrollo para poder cumplir con el
cronograma del proyecto.
En la posterior tabla podemos hacer un detallado:
3.1.3.1.1. Definición De Historias De Usuario
71
Tabla 11. Sprint 0
HISTORIAS CRITERIOS DE ACEPTACION
Identificación
Rol Funcionalidad Resultado
Número de Escenario
Criterio de Aceptación (Titulo)
Contexto
Evento Resultado/Comportamiento esperado
HU-1 Cliente
Final
necesita crear, eliminar, editar un
cliente desde el administrador
necesita crear clientes para
poder vender por centro de atención
telefónica
1 CLIENTE N/A Crear un nuevo
cliente
Cara al cliente un formulario de
registro, para el administrador una
ventana con los campos del cliente.
HU-2 sistema
Necesita designar clientes a ciertos
grupos (ej. Colaboradores)
Editar a las cuentas de
usuarios que trabajan ahí
2 CLIENTE N/A Designar un
cliente Designar a un
grupo un cliente
HU-3 Administr
ador leer y responder libro
de reclamaciones
la finalidad de cumplir con la ley
de consumidor 3 CLIENTE N/A
Administrar un reclamo
Cara al cliente llenar un
formulario, para el administrador pude
ver el reclamo
HU-4 Administr
ador
Se requiere crear un campo de validacion de termininos y condiciones en el checkout
El cliente acepte antes de comprar
4 CLIENTE N/A Cliente seleciona este campo
Cliente hace clic en el checkbox para proseguir con su compra
72
HU-5 Administr
ador
necesito crear promociones para los
productos
finalidad de captar o vender
más 5
PROMOCIONES/PRODUCTOS
N/A crear
promociones
modulo de promociones para
productos.
HU-6 administr
ador
necesita una matriz de precio para envió a
domicilio
la finalidad de poder llegar a nivel nacional
6 MÉTODO DE ENVIÓ N/A Administrar cobros de
envíos
modulo de una matriz de precio
por distrito o provincias
HU-7 Cliente
Final Necesita aplicar reglas a los métodos de envió
finalidad de logísticos de la
empresa 7 MÉTODO DE ENVIÓ N/A
Administrar envíos
modulo con reglas de envíos
dependiendo al administrador o
campana de marketing
HU-8 Cliente
Final
Se necesita que la orden de compra, el
cliente pueda decidir si elige boleta o factura
finalidad al momento de
imprimir el ticket de venta sea
boleta o factura
8 ORDEN DE VENTA N/A Cliente puede
elegir si es boleta o factura
Modificar el flujo del cliente que
viene por defecto en Magento
HU-9 Cliente
Final
SE Requiere por cada estado de la orden de
compra enviar un correo al cliente
finalidad informativa para
el cliente 9 ORDEN DE VENTA n/A
enviar correos cuando cambie
de estado
a través de la grilla de ordenes se
pueda cambiar de estado, estados automatizados.
HU-10 administr
ador
necesita que las ordenes de servicio con
los operadores logísticos(terceros) se
creen
finalidad no crear manual las OS
10 ORDEN DE VENTA N/A
Crear Ordenes de servicios de
los Courier automatizadas
Modificar el flujo de Magento
73
automáticamente al cambiar un estado del
pedido
HU-11 Cliente
Final
necesita que los productos
recientemente vistos aparezcan en el flujo de
compra
finalidad poder atraer al cliente
11 CLIENTE/PRODUCT
O n/A
mayor exposición de los productos
Un apartado en el home de los productos
recientemente visto
HU-12 Cliente
Final Necesita simplificar el
flujo de compras
finalidad tener una mejor conversión
12 CLIENTE/CHECKOU
T n/A
Implicar el modelo de
compra
Usar Onepage Check-out
HU-13 Cliente
Final Se requiere el inicio sesión por Facebook
finalidad, su login sea más rápido
13 CLIENTE n/A Iniciar sesión con Facebook
Poder ingresar con Facebook a la tienda online
HU-14 Cliente
Final
Se necesita la implementación de un
método de pago
finalidad del que cliente puede
convertir (finalice su compra)
14 CLIENTE/CHECKOU
T n/A
Usar métodos de pago
Creación de métodos de pago
HU-15 Cliente
Final
Se requiere implementar los atributos de los
productos adecuados
Finalidad la data de RPE sea la misma del e-commerce
15 CARGA DE
INVENTARIO n/A
A través de una integración con
el RPE de la empresa
Misma data del sistema
HU-16 Administr
ador
Se necesita crear una barra de menu con todas las categorias
que se maneja
finalidad una buena
distribución de productos
16 PRODUCTO N/A crear y
administrar las categorías
modulo de categoría para 1 o
mucho store
74
HU-17 Administr
ador
Se requiere descargar la orden de venta al
POS
finalidad las ventas del e-
commerce deben acabar en RPE de
la empresa
17 ORDEN DE VENTA n/A
integración con el sistema para que cada cierto
tiempo las ordenes
pagadas se descarguen
consolidación de data
HU-18 Administr
ador
se requiere que se guarde campos como
DNI, Dirección, Departamento,
Provincia, Ubigeo
finalidad tener más datos del
cliente 18 CLIENTE n/A
guardar datos de los clientes
en su registro o CHECKOUT
se guarda personalizando el
modulo de Customer de
Magento, creando un modulo
personalizando
HU-19 Administr
ador
Se necesita enviar campañas de
marketing con los clientes suscriptos en la
web
finalidad de enviar los nuevos clientes al portal
de email marketing
19 CLIENTE n/A newsletter
apartado de newsletter para ver que clientes se han
suscrito
HU-20 Administr
ador
El producto debe contar con todos sus
atributos desde el principal hasta los
menos importantes
la finalidad de poder vender y captar clientes
según los atributos
20 PRODUCTO N/A Crear un producto
El administrador tendrá una ventana con los campos de los atributos de los
productos.
HU-21 administr
ador
Se necesita las pruebas de performance del
sitio
finalidad que sitio web sea
rápido. 21 USABILIDAD n/A
Usar las herramientas para probar el
sitio web
Resultados de las pruebas
75
HU-22 sistema Seguir un mockup para
las interfaces
finalidad seguir con la línea
graficas de las tiendas
físicas(branding)
22 CLIENTE n/A
Hacer las Implementacion
es según el prototipo
Lineamiento de la marca
HU-23 administr
ador necesita poder el
detallados de ordenes
finalidad hacer reportes de
ventas 23 ORDEN DE VENTA n/A
Crear un modulo para
poder descargar todo el
detallado de las ordenes
Modulo de exportar o importar
ordenes
HU-24 Administr
ador
Formularios para ciertas campañas de
suscripciones
finalidad de crear automáticament
e formularios cortos para
suscripciones
24 REGISTRO/CLIENTE n/A
Crear un formulario corto para
campanas de registro
modulo de registros sin que este unido a los registros de los
clientes.
HU-25 Administr
ador
Se requiere crear paginas y bloques
dentro de la web que sean editables de
forma rapida
finalidad hacer cambios de
contenido(texto) sin tocar el
código fuente
25 BLOQUE ESTÁTICOS n/A
hacer modificaciones
en bloques personalizados
Facilidad de uso para insertar
ciertas nuevas cosas.
HU-26 administr
ador
Necesita localizar los puntos de ventas
físicos
finalidad poder tener un
apartado de localidades
26 TIENDAS - MAPA N/A
Administrar las tiendas
(dirección, nombre,
teléfono, etc.)
modulo de tiendas o almacenes
HU-27 administr
ador Se requiere la
categorización de los Finalidad tener
un mejor proceso 27 PRODUCTO n/A
Los atributos de los productos
A través de una tarea programada
76
productos automatizada
de categorización basada en atributos
decidirán a que categoría van
ejecutar después de la carga de
inventario
HU-28 sistema
Se necesita que los productos tenga
atributos para que estos sean de manera filtable es decir que el cliente puede elegir
Finalidad la data de RPE sea la misma del e-commerce
28 CARGA DE
INVENTARIO n/A
A través de una integración con
el RPE de la empresa
Misma data del sistema
HU-29 Administr
ador
Necesita informarle al cliente por estados como va su pedido
finalidad de tener más
estados que vayan con el flujo
de trabajo
29 ORDEN DE VENTA N/A Administrar el flujo de estado de una compra
Modulo de estados personalizados
HU-30 administr
ador
crear las vistas comunes (Sobre
nosotros, Únete a nosotros, las guías
como comprar, etc.)
finalidad del que el cliente tenga más datos sobre
la empresa
30 CLIENTE n/A
Hacer las configuraciones necesarias para usar las página s
estáticas de Magento
Rellenar las página s de contenido
HU-31 Administr
ador
Se necesita ver el nombre del codigo y la
edad del producto dentro de la pagina de
producto
Finalidad de esto es que el usuario
final pueda distingir si el producto le
corresponde o esta buscando
31 PRODUCTO n/A
Se debe imprimir las
variables de los productos en el
catalogo
Campos visibles al cliente
77
HU-32 Cliente
Final
necesita ver las guías de tallas dependiendo del producto y genero
finalidad que el cliente pueda elegir su talla
correcta
32 PRODUCTO n/A Más
información de un producto
Usar un popup para las tallas
Fuente: elaboración propia
78
3.1.3.1.2. PRODUCT BACKLOG:
Se detalla los requerimientos de usuarios obtenidos en el historial de usuario,
mostrando la priorización y estimación de esfuerzo:
Tabla 12. Product Backlog
PRODUCTO BACKLOG
ID Historias
de usuarios
Prioridad Requerimiento ESTIMACIÓN HORAS/DÍAS
SPRINT
Registro de cliente desde el Administrador
R1 HU-1 MEDIA El administrador de la web puede crear
un usuario 1 DÍA 1
R2 HU-2 BAJA
Necesita designar clientes a ciertos
grupos (ej. Colaboradores)
4 HORAS 1
LIBRO DE RECLAMACIONES
R3 HU-3 MEDIA Debe registrar los reclamos según la ley del consumidor
3 DÍAS 1
Reseñas de productos
R4 HU-4 MEDIA debe contar un
campo 1 DÍA 1
Promociones del producto
R5 HU-5 MEDIA
debe contar con un modulo de
promociones (X y buy X for 30%
1 DÍA 1
Matriz de precios para envió a domicilio o destino final
R6 HU-10 MEDIA
Se debe crear una matriz o un método
de envió con distintos precios según el lugar vs cantidad vs peso
2 DÍAS 1
Modulo de Reglas de método de envió
R7 HU-7 MEDIA Se debe crear un
modulo para ejecutar reglas para
2 DÍAS 1
79
los distintos métodos de envió
Crear y modificar los cambios de registro de una orden
R8 HU-8 MEDIA
se debe modificar y agregar los cambios
de elección si es (Boleta -> datos normales), si es factura -> Ruc y
Razón social
3 DÍAS 1
modulo de estados personalizados
R9 HU-9 MEDIA
Se debe crear un modulo donde se
pueda crear estados predeterminados
que permita enviar correos a los
clientes.
3 DÍAS 1
modulo de creación de OS de operadores logísticos
R10 HU-10 MEDIA
se debe crear un modulo que cree automáticamente
las ordenes de servicio con los
datos de la orden
3 DÍAS 1
Visualización de producto cara al usuario final
R11 HU-11 MEDIA
se debe crear los productos
recientemente vistos por usuario
final
2 DÍAS 1
Modelo de CHECKOUT
R12 HU-12 MEDIA
se debe implementar un
modelo de CHECKOUT distinto
al que viene por defecto en Magento
5 días 1
Registro de usuario final
R13 HU-13 MEDIA modulo
personalizado de 3 DÍAS 1
80
inicio de sesión a través de Facebook
implementación de método de pago
R14 HU-14 MEDIA crear los módulos de
métodos de pago 7 días 1
PRODUCTOS
R15 HU-15 MEDIA
Por medio de la integración con el RPE de la empresa
se debe integrar los productos (nombre,
genero, etc.)
4 DÍAS 1
R16 HU-16 MEDIA
se debe definir los ID de las categorías
para hacer el cruce según los atributos
1 DÍA 1
ORDEN DE VENTA
R17 HU-17 MEDIA
Debe descargar la orden de venta al RPE de la empresa
(bridar las variables)
1 DÍA 1
R18 HU-18 MEDIA crear un modulo
para guardar nuevos datos del cliente
3 DÍAS 1
Newsletter integrada con plataforma, envía trama a otra data
R19 HU-19 BAJA
Cliente que este en el newsletter debe
estar en la plataforma de email
marketing
3 DÍAS 2
Implementación de atributos del producto
R20 HU-20 MEDIA
debe contar con todos los atributos
de un producto (color, edad, talla,
etc.)
1 DÍA 2
TEST de performance de sitio
81
R21 HU-21 BAJA Hacer test de prueba del sitio y mejorar el
tiempo de carga 2 DÍAS 2
Personalización de la vista al cliente
R22 HU-22 MEDIA
debe implementar todas los estilos y los apartados según los
mockups
10 días 2
Modulo de exportar/importar ordenes
R23 HU-23 BAJA
crear un modulo para la exportación
de ordenes de forma masiva
2 DÍAS 2
modulo de formularios personalizados
R24 HU-24 BAJA
Nos permita crear formularios
personalizados con solo arrastrar los campos deseados
2 DÍAS 2
usar los bloques estáticos
R25 HU-25 BAJA
Se debe implementar los
bloques predeterminados, espacios definidos
1 DÍA 2
modulo de localización de tiendas físicas
R26 HU-26 MEDIA
Se debe crear un modulo de puntos
de ventas (ubicación en el mapa)
2 DÍAS 2
Categoría de los productos
R27 HU-27 BAJA
Se debe crear todas las categorías
posibles para una mejor segmentación
7 horas 2
Filtros de los productos
R28 HU-28 BAJA
Se debe crear todos los atributos de los productos de forma
adecuada
1 DÍA 2
ORDEN DE VENTA
82
R29 HU-29 MEDIA
se requiere que cada estado del pedido pueda enviar un
correo al cliente // personalizar
plantillas
2 DÍAS 2
Crear los apartados informativos
R30 HU-30 BAJA
Según el modulo de CMS/Página s crear
las landing pages informativas
4 DÍAS 2
R31 HU-31 BAJA
Debe imprimir la variable SKU del
producto configurable
(producto madre), edad y genero
3 hora 2
Visualización de producto cara al usuario final
R32 HU-32 MEDIA
crear las guías de tallas de los
productos cuales deben mostrarse según marcas y el
genero
3 DÍAS 2
Fuente: elaboración propia
3.1.3.1.3. Definición De Sprint Backlog
Se explica los pasos para realizar el desarrollo de software
83
Tabla 13. Sprint 1
SPRINT 1
id TAREAS 1 Modificaciones en el User Story
2 Realizar la creación del flujo de compra
3 Prototipo del Front y de Modo Administrador
4 Revisión de la base de datos para lograr los requerimientos personalizados
5 Desarrollo de Historia de Usuario 5.1. Modificación de los datos del cliente. 5.2. Creación de Atributos de producto.
5.3. Verificar la integración el sistema de tiendas con la plataforma.
5.4. Verificar si las ordenes generadas se descargan al sistema de tiendas.
5.5. Creación de categorías en el sitio. 5.6. Desarrollo de modulo de exportación ordenes.
5.7. Estados personalizados de los pedidos.
5.8. Modulo de Libro de reclamaciones.
5.9. Asignar a clientes a un cierto grupo.
5.10. Cliente puede iniciar sesión por Facebook
6 Pruebas funcionales
7 Aprobación del producto(entregable)
Fuente: elaboración propia
84
Tabla 14. Sprint 2
Fuente: Elaboración Propia
SPRINT 2
id TAREAS
1 Verificación del Sprint 2
2 Modificación de la base de datos
3 Prototipo del Front-end (cara al usuario final)
4 Desarrollo de Historia de Usuario
4.1. Desarrollo de Módulo de Promociones
4.2. Desarrollo de Módulo de Restricciones en envió
4.3. Desarrollo de Módulo de Restricciones de método de pago
4.4. Desarrollo de Módulo de formularios libres
4.5. Desarrollo de Localización de Perú
4.6. Desarrollo de Matriz de todos los lugares del Perú
4.7. Mejoramiento del CHECKOUT
4.8. Integración con el operador logístico
4.9. Implementar las pasarelas de pago.
4.10. Estados en el flujo compras.
6 Pruebas funcionales
7 Aprobación del producto(entregable)
85
3.1.3.2.SPLINT 1
Empezaremos con los módulos personalizados para Magento.
3.1.3.2.1. FASE DE PLANIFICACION:
3.1.3.2.1.1.REVISIÓN Y MODIFICACIÓN DEL Sprint BACKLOG
Se hará un análisis para verificar si se puede hacer algo más claro el sprint Backlog para
el fácil entender del equipo.
Las siguientes son las modificaciones
Tabla 15. Planificación y Revisión del Sprint 1
SPRINT 1
id TAREAS
1 Modificaciones en el HU
2 Realizar la creación del flujo de compra
3 Prototipo del Front y las tablas modificadas del Modo Administrador
4 Revisión de la base de datos para lograr los requerimientos personalizados
5 Desarrollo de Historia de Usuario
5.1. Modificación de los datos del cliente para agregar nuevos datos. Creación de un modulo personalizado que agregue los nuevos campos del cliente.
5.2. Creación de Atributos de producto en caso sea simple o configurable.
5.3. Verificar la integración el sistema de tiendas con el sistema de tiendas físicas.
5.4. Verificar si las ordenes generadas se descargan al sistema de tiendas físicas.
5.5. Creación de categorías en el sitio y distribución automática de los productos.
5.6. Desarrollo de modulo de exportación ordenes, para detener un reporte de los pedidos realizados.
5.7. Implementar la integración con el proveedor de servicio de correo masivo.
6 Pruebas funcionales
7 Aprobación del producto(entregable)
Fuente: Elaboración Propia
86
3.1.3.2.2. FASE DE ANALISIS
3.1.3.2.2.1.REVISION Y MODIFICACION DE HISTORIAS DE USUARIOS
Se revisará y se analizará si en caso se necesita hacer algún cambio en Product
Backlog, en este caso no sufrirá ninguna variación las historias.
Tabla 16. Revisión de las Historias de Usuario del Sprint 1
Identificación
Rol Funcionalida
d Resultado
Número de Escenario
Criterio de
Aceptación (Titulo)
Contexto
Evento Resultado/Comp
ortamiento esperado
HU-1 Administrador
necesita crear,
eliminar, editar un
cliente desde el
administrador
necesita crear
clientes para poder
vender por centro de atención
telefónica
0 CLIENTE N/A Crear un
nuevo cliente
Cara al cliente un formulario de
registro, para el administrador
una ventana con los campos del
cliente.
HU-2 Administrador
Necesita designar clientes a
ciertos grupos (ej.
Colaboradores)
Editar a las cuentas de
usuarios que trabajan ahí
1 CLIENTE N/A Designar un
cliente Designar a un
grupo un cliente
HU-3 Administrador
leer y responder
libro de reclamacion
es
la finalidad de cumplir
con la ley de consumidor
2 CLIENTE N/A Administrar un reclamo
Cara al cliente llenar un
formulario, para el administrador
pude ver el reclamo
HU-4 Cliente
Final
Se requiere el inicio
sesión por Facebook
finalidad, su login sea
más rápido 24 CLIENTE n/A
Iniciar sesión con
Poder ingresar con Facebook a la tienda online
HU-5 sistem
a
Se requiere implementar los atributos
de los productos adecuados
Finalidad la data de RPE del sistema
sea la misma del e-
commerce
27
CARGA DE
INVENTARIO
n/A
A través de una
integración con el RPE
de la empresa
Misma data del sistema
87
HU-6 sistem
a
Se requiere descargar la
orden de venta al POS
finalidad las ventas del e-commerce
deben acabar en RPE de la empresa
29 ORDEN
DE VENTA n/A
integración con el
sistema para que cada
cierto tiempo las
ordenes pagadas se descarguen
consolidación de data
HU-7 administrador
SE Requiere por cada
estado de la orden de compra
enviar un correo al cliente
finalidad informativa
para el cliente
30 ORDEN
DE VENTA n/A
enviar correos cuando
cambie de estado
a través de la grilla de ordenes
se pueda cambiar de
estado, estados automatizados.
HU-8 Cliente
Final
necesita ver las guías de
tallas dependiend
o del producto y
genero
finalidad que el cliente
pueda elegir su talla
correcta
21 CLIENTE/PRODUCT
O n/A
Más información
de un producto
Usar un popup para las tallas
HU-9 Cliente
Final
necesita que los
productos recientemen
te vistos aparezcan
en el flujo de compra
finalidad poder atraer
al cliente 22
CLIENTE/PRODUCT
O n/A
mayor exposición
de los productos
Un apartado en el home de los
productos recientemente
visto
HU-10 Cliente
Final
Necesita simplificar el
flujo de compras
finalidad tener una
mejor conversión
23 CLIENTE/CHECKOU
T n/A
Implicar el modelo de
compra
Usar Onepage Check-out
HU-11 Cliente
Final
necesita que se visualice la edad del producto y
el código(sku)
finalidad que el cliente
pueda elegir bien el
producto
20 CLIENTE/PRODUCT
O n/A
Mayor detalle del producto
Información extra del producto
HU-12 Administrador
revisar y aceptar
reseñas de productos
la finalidad de mejorar experiencia de compra
5 PRODUCT
O N/A
Revisar y aprobar
reseñas de productos
apartado de reseñas
pendientes
88
HU-13 Administrador
necesito crear
promociones para los productos
finalidad de captar o
vender más 6
PROMOCIONES/PRODUCTOS
N/A crear
promociones
modulo de promociones
para productos.
HU-14 administrador
necesito crear
categorías para los
productos
finalidad una buena
distribución de
productos
7 PRODUCT
O N/A
crear y administrar
las categorías
modulo de categoría para 1
o muchas tiendas
HU-15 sistem
a
Se requiere la
categorización de los
productos automatizad
a
Finalidad tener un
mejor proceso de categorización basada
en atributos
28 PRODUCT
O n/A
Los atributos de los
productos decidirán a
que categoría
van
A través de una tarea
programada ejecutar después
de la carga de inventario
HU-16 administrador
se requiere que se guarde campos
como DNI, Dirección,
Referencia, Departamento, Provincia,
Distrito, Ubigeo
finalidad tener más datos del
cliente
31 CLIENTE n/A
guardar datos de los clientes en
su registro o checkout
se guarda personalizando el modulo de
cliente de Magento,
creando un modulo
personalizando
Fuente: Elaboración Propia
89
3.1.3.2.2.2.VERIFICACION Y MODIFICACION DEL PRODUCT BACKLOG:
En el presente documento del sprint 1 podemos ver que ha sufrido una pequeña
variación en desarrollo:
Tabla 17. Modificación del Product Backlog en el Sprint 1
PRODUCTO BACKLOG
ID Historias
de usuarios
Prioridad Requerimiento ESTIMACIÓN HORAS/DÍAS
SPRINT
Registro de cliente desde el Administrador
R1 HU-1 MEDIA El administrador de la web
puede crear un usuario 1 DÍA 1
R2 HU-2 BAJA Necesita designar clientes a
ciertos grupos (ej. Colaboradores)
4 HORAS 1
LIBRO DE RECLAMACIONES
R3 HU-3 MEDIA Debe registrar los reclamos según la ley del consumidor
3 DÍAS 1
Reseñas de productos
R4 HU-4 MEDIA debe contar un campo 1 DÍA 1
Promociones del producto
R5 HU-5 MEDIA debe contar con un modulo de promociones (X y buy X
for 30% 1 DÍA 1
Matriz de precios para envió a domicilio o destino final
R6 HU-10 MEDIA
Se debe crear una matriz o un método de envió con distintos precios según el lugar vs cantidad vs peso
2 DÍAS 1
Modulo de Reglas de método de envió
R7 HU-7 MEDIA Se debe crear un modulo
para ejecutar reglas para los distintos métodos de envió
2 DÍAS 1
Crear y modificar los cambios de registro de una orden
R8 HU-8 MEDIA
se debe modificar y agregar los cambios de elección si es (Boleta -> datos normales), si es factura -> Ruc y Razón
social
3 DÍAS 1
90
modulo de estados personalizados
R9 HU-9 MEDIA
Se debe crear un modulo donde se pueda crear
estados predeterminados que permita enviar correos
a los clientes.
3 DÍAS 1
modulo de creación de OS de operadores logísticos
R10 HU-10 MEDIA
se debe crear un modulo que cree automáticamente las ordenes de servicio con
los datos de la orden
3 DÍAS 1
Visualización de producto cara al usuario final
R11 HU-11 MEDIA se debe crear los productos
recientemente vistos por usuario final
2 DÍAS 1
Modelo de CHECKOUT
R12 HU-12 MEDIA
se debe implementar un modelo de CHECKOUT
distinto al que viene por defecto en Magento
5 días 1
Registro de usuario final
R13 HU-13 MEDIA modulo personalizado de
inicio de sesión a través de Facebook
3 DÍAS 1
implementación de método de pago
R14 HU-14 MEDIA crear los módulos de
métodos de pago 7 días 1
PRODUCTOS
R15 HU-15 MEDIA
Por medio de la integración con el RPE de la empresa se
debe integrar los productos(nombre, genero,
etc.)
4 DÍAS 1
R16 HU-16 MEDIA se debe definir los ID de las
categorías para hacer el cruce según los atributos
1 DÍA 1
ORDEN DE VENTA
R17 HU-17 MEDIA Debe descargar la orden de venta al RPE de la empresa
(bridar las variables) 1 DÍA 1
R18 HU-18 MEDIA crear un modulo para
guardar nuevos datos del cliente
3 DÍAS 1
91
Fuente: Elaboración Propia
3.1.3.2.2.3.DISEÑO DE PROTOTIPOS
Primeramente, veremos lo mockup que son la base de todo, y posteriormente se
ira definiendo los estilos en el front-end.
HOME PRINCIPAL
Figura 25. Mockups Home Page
92
Fuente: Elaboración Propia - Illustrator
Figura 26. Segunda Parte
Fuente elaboración Propia
93
PÁGINA DE CATEGORIA DE PRODUCTO
Figura 27. Categoría de Productos
Fuente: Elaboración propia
94
PÁGINA DE PRODUCTO
Figura 28. Mockups de Product Page
Fuente: Elaboración Propia
95
AGREGAR AL CARRITO DE COMPRAS
Figura 29. Mockupds de Carrito de compras
Fuente: Elaboración propia por mockups
96
CHECKOUT - ECOMMERCE
Figura 30. Onepage Checkout
Fuente: Elaboración propia.
97
3.1.3.2.3. FASE DE DISEÑO
3.1.3.2.3.1.MODELO DE DATOS
El modelo de base de datos es modelo EAV, entidad, atributo y valor.
En la figura 31 podemos observar las tablas que pueden involucrar al producto, la
tabla principal es catalog_product_entity es la cual se genera los Id de los productos
(simple y configurable). Una parte
Podemos visualizar catalog_category_entity la cual se encarga de llevar los id de
las categorías, es decir, estas pueden ser una categoría de productos, una landing page.
En la figura 32 podemos observar los componentes que se debe tener para crear
un producto, cada atributo cuenta con distintas variables, en la figura 33 podemos ver que
tipo de atributos puede haber.
En la figura 34 y 35 podemos observar lo siguiente: para el tema de productos de
los atributos de los productos se pueden crear de manera rápida y fácil desde el modo
administrador de CMS, estos se llegan a distribuir en ciertas tablas referentes a los
productos, dependiendo que tipo de atributo se elija en la figura 36 podemos ver las tablas
que almacenan estos datos.
98
Figura 31. Tabla Relacional del Producto
Fuente: https://i.stack.imgur.com/3gCTk.jpg
99
Figura 32. Atributos creados para un producto personalizado
Fuente: elaboración de Magento
Figura 33. Tipos de atributos - Productos
Fuente: elaboración del CMS
100
Figura 34. Componentes de un Atributo - Producto Magento
Elaboración: CMS Magento
Figura 35. Opciones del Atributo Creado
Elaboración Propia – CMS Magento
101
Figura 36. Tablas de atributos
Elaboración Propia – CMS Magento
3.1.3.2.4. FASE DE CONSTRUCCION Y PRUEBAS
En esta fase vamos a detallar las pruebas correspondientes para revisar si los
requerimientos esta conforme al cliente.
Se estarán realizando 6 pruebas funcionales para poder visualizar si los módulos
creados cumplen con la finalidad de la creación de estos, estas pruebas se harán para pulir
los posibles errores y tomar medidas correctivas.
Hay una prueba que se realizara a través de la configuración del propio CMS para
poder verificar si los módulos esta correctamente insertados, puesto la data puede ser
guarda en las bases de datos, pero puede generar algún conflicto con otro modulo que no
se verificara en estas pruebas funcionales.
A continuación, veremos la creación de flujogramas de ciertos proceso o extensión
de que se han generado en el sprint 1, para poder llegar al resultado final.
102
Flujograma de proceso de compras
En la figura 37 veremos el proceso que sigue un cliente desde que entra a la web
hasta que recibe su pedidos para poder entender que pasos debe pasar el cliente final y el
administrador del sistema para concretar una venta.
Figura 37. Flujograma de proceso de compra
Fuente: Elaboración Propia
Flujograma de inicio de sesión
En la figura 38 podemos ver el flujograma de un cliente cuando inicia sesión, por
defecto, Magento no trae algunos campos los cuales se tiene que crear un modulo el cual
agregara estos campos poder interactuar con estos al momento de llamar un evento y
imprima las variables.
103
Va desde que el cliente intenta iniciar sesión, en caso de no tener cuenta debe
registrarse e ingresar los datos personales de él, hasta que le llegue el mensaje de cuenta
creada.
Figura 38. Flujograma de inicio de sesión
Fuente: Elaboración Propia
Flujograma de Creación de ordenes de servicios
En la figura 39 podemos ver el flujograma de creación de ordenes de servicio con
el operador logístico, para poder llegar al resultado final tanto como el cliente debe pasar
ciertos pasos, por ejemplo el cliente final debe generar un pedido en estado pago
confirmado posterior a esto hay un modulo que verificara si algún pedido ha cambiado
de estado para enviar la trama (datos de la orden de compra) al operador y este genere las
etiquetas para el pagado en las cajas y además el código de seguimiento que se le estará
enviado al cliente por correo para que haga el control de su pedido..
104
Figura 39. Flujograma de Creación de Ordenes de Servicios del Operador Logístico
Fuente: Elaboración Propia
Todo este proceso interactúa con los datos guardados en la base de datos, para esto
se mostrará en la figura 40 como es el modelo relación de estas tablas para entender un
poco más: Directory_country se ubicará los países, directory_country_region en esta tabla
se agregarán las regiones que tiene nuestro país puesto no viene por defecto estas.
Localizacion_distritos y Localizacion_provincias, son unas tablas creada para guardar los
distritos y provincias respectivamente en nuestro país. Sales_flat_order es la tabla donde
se guarda la transacción. Sales_flat_order_address donde se guarda la información de
envió de la compra y matrix_rate donde se guarda la matriz de costos por destinos.
105
Figura 40. Modelo Relacional de las tablas de compra y de envío
Fuente: Elaboración Propia
3.1.3.2.4.1.1. Prueba Funcional 1
Veremos el flujo de un ingreso de registro de un usuario nuevo, a través de la web
desde él de la vista principal.
Tabla 18. Prueba Funcional 1 - Sprint 1
Nombre del proyecto
Implementación y Optimización de una
plataforma e-commerce Navegador: Google Chrome
No. Caso de prueba
Prueba número 1 Versión: 1.0
Escrito por Desarrollador Descripción: Gestión de Cliente
Probado por Project Manager Probado en: Ambiente de prueba
Prueba # Acción Resultados esperados
Resultados actuales
Aprobado
1 cliente se redirige a la web Lo redirige al panel de mi
cuenta
Lo redirige al panel de mi
cuenta CORRECTO
2 cliente hace clic en el
registrarse/ iniciar sesión
lo redirige para que elija si
desea iniciar sesión o
registrarse
muestra una ventana con dos
columnas, registro e iniciar
sesión.
CORRECTO
106
3
cliente llena todos los campos correspondientes
(Nombre, Apellido, Genero, Fecha de cumpleaños, DNI,
correo y la contraseña. También debe aceptar los
términos y condiciones
cliente se registra
correctamente, recibe correo de
bienvenida además se guardan los
datos en la base de datos
cliente se registra
correctamente, recibe correo de
bienvenida además se guardan los
datos en la base de datos
CORRECTO
4 la persona encargada puede
crear una cuenta desde el ambiente de administrador
Genera un cliente desde el
lado administrador,
registra sus datos y se envía
el correo al cliente.
Guarda los datos y genera
envíos CORRECTO
5 Cliente puede seleccionar
iniciar con Facebook
Cliente se puede iniciar
sesión con Facebook da su
correo y su cumpleaños
Cliente se puede iniciar
sesión con Facebook da su
correo y su cumpleaños
CORRECTO
6
Cliente es asignado a un grupo, el administrador
puede designar a clientes a ciertos grupos
Cliente cambia en
administrador los clientes
Cliente cambia en
administrador los clientes
CORRECTO
Fuente: Elaboración Propia
En la figura 41 podemos ver el resultado final, es decir una captura de pantalla de los
campos que se debe llenar, para así obtener el resultado final
107
Figura 41. Captura de Registro de Usuario
Fuente: Elaboración propia // CMS de prueba
108
3.1.3.2.4.1.2. Prueba Funcional 2
En esta prueba haremos la prueba de calidad sobre el objetivo 2 para poder
verificar que el desarrollo del modulo de producto se encuentra funcionando bien y con
esto se resolvería el efecto que causaría.
Tabla 19. Prueba funcional 2 - Sprint 1
Nombre del proyecto
Implementación y Optimización de una
plataforma e-commerce
Navegador: Google Chrome
No. Caso de prueba
Prueba número 2 Versión: 1.0
Escrito por Desarrollador Descripción: Gestión de productos
Probado por Project Manager Probado en: Ambiente de prueba
Prueba # Acción Resultados esperados
Resultados actuales
Aprobado
1
Ejecutar la carga de inventario masivo, desde el ERP del
sistema de tiendas.
Se espera que los productos deben
almacenar lo siguiente: color, tipo,
producto simple o configurable, talla, peso, nombre, sku,
stock.
Guarda en la base de datos los datos pedidos. Guardar los atributos del producto: color,
precio, nombre, sku, stock, tipo, si es
producto simple o compuesto
CORRECTO
2
el administrador de la web puede editar manualmente los
productos
Cliente entra al apartado de
producto y hace los cambios respectivos
Cliente entra al apartado de
producto y hace los cambios respectivos
CORRECTO
3
EL administrador entra al menú Catalogo y busca el común de esos productos en
nuestro caso tienen un dato común los
productos madre e hijos llamado código
de proveedor
Se requiere actualizar unos productos y sus
tallas con un nuevo atributo para que pueda usarse los
filtros
los cambios se generan
correctamente CORRECTO
4 el cliente puede ver en
el product page los atributos del producto
Puede ver el nombre, la marca, descripción y stock
Puede ver el nombre, la marca, descripción y stock
CORRECTO
109
Fuente: Elaboración Propia
En la figura 42 podemos observar la información del producto, los atributos que
tendrá el producto.
Figura 42. Información del Producto
Fuente: extracción del portal de ventas
5
Probar el store procedure de
categorización de producto
un producto puede tener más de una
categoría
un producto puede tener más de una
categoría CORRECTO
6 Productos recientes vistos por usuario
Cliente ve un producto y al
navegar por el home page puede ver sus
productos vistos
Cliente ve un producto y al
navegar por el home page puede ver sus productos
vistos
CORRECTO
7 Reseñas de los
productos
Cliente puede poner su opinión en los productos, nos
puede contar su experiencia con el
producto
Cliente puede poner su opinión en los productos, nos
puede contar su experiencia con el
producto
CORRECTO
8 Guía de talla de
producto
Cliente al elegir un producto le figura
una guía de talla de la marca y del
genero
Cliente al elegir un producto le figura
una guía de talla de la marca y del
genero
CORRECTO
110
3.1.3.2.4.1.3. Prueba Funcional 3
En esta prueba haremos la prueba de calidad sobre el objetivo 2 para poder
verificar que el desarrollo del modulo de producto se encuentra funcionando bien y con
esto se resolvería el efecto que causaría.
Tabla 20. Prueba Funcional 3 - Sprint 1
Nombre del proyecto
Implementación y Optimización de
una plataforma e-commerce
Navegador: Google Chrome
No. Caso de prueba
Prueba número 3 Versión: 1.0
Escrito por Desarrollador Descripción: libro de Reclamaciones
Probado por Project Manager Probado en: Ambiente de prueba
Prueba # Acción Resultados esperados
Resultados actuales
Aprobado
1
EL cliente entra a la imagen del libre de reclamaciones que se encuentra en el footer de la
página
Cliente hace clic en la imagen lo deriva a la
página de reclamaciones
Cuando el cliente hace clic lo dirige a
la página de reclamos para que
pueda llenar los datos
CORRECTO
2 Cliente llena los
datos del libro de reclamaciones
Cliente llena todos los campos obligatorios
Cliente llena todos los campos obligatorios
CORRECTO
3
Cliente puede enviar el reclamo dando el clic en el botón enviar, pero
con la info obligatoria
El reclamo se guarda en la base de datos y
se puede ver el contenido del
reclamo en un menú del administrador
El reclamo se guarda en la base
de datos y se puede ver el contenido del
reclamo en un menú del
administrador
CORRECTO
4 Reglas de libro de reclamaciones una
copia al cliente.
Cliente recibe una copia de su reclamo
por correo
Cliente recibe una copia de su reclamo
por correo CORRECTO
111
5
Cliente puede responder el
reclamo y así darle solución a este
Cliente envía un correo con la
respuesta en un plazo de 30 días
hábiles como máximo
Cliente envía un correo con la
respuesta en un plazo de 30 días
hábiles como máximo
CORRECTO
Fuente: Elaboración Propia
Captura del Registro de Reclamos:
Figura 43. Libro de Reclamaciones
112
3.1.3.2.4.1.4. Prueba Funcional 4
En esta prueba haremos la prueba de calidad de la creación de una orden de venta.
Tabla 21. Prueba Funcional 4 - Sprint 1
Nombre del proyecto
Implementación y Optimización de
una plataforma e-commerce
Navegador: Google Chrome
No. Caso de prueba Prueba número 4 Versión: 1.0
Escrito por Desarrollador Descripción: ORDEN DE PEDIDO
Probado por Project Manager Probado en: Ambiente de prueba
Prueba # Acción Resultados esperados
Resultados actuales
Aprobado
1 Administrador
define el checkout que se usara
Cliente elige un producto, lo
agrega al carrito y procesa la dirige a una página nueva con los datos de
envió y pago
Cliente elige un producto, lo
agrega al carrito y procesa la dirige a una página nueva con los datos de
envió y pago
CORRECTO
2
Cliente final tiene que agregar su
dirección y referencia
Cliente llena los campos de dirección y referencia
Cliente llena los campos de dirección y referencia
CORRECTO
3
Cliente debe elegir provincia departamento y
distrito
Cliente rellena los campos
mencionados
Cliente rellena los campos
mencionados CORRECTO
4
Ubigeo de la dirección se
agregará automáticamente
en un campo oculto
Ubigeo de la dirección se
agregará automáticamente
en un campo oculto
Ubigeo de la dirección se
agregará automáticamente
en un campo oculto
CORRECTO
5 Si se desea factura el cliente debe llenar su ruc y razón social
el cliente debe llenar su ruc y razón social
CORRECTO
6 Se modelo de
checkout se elige
Se elige onepage checkout, todo en
una sola vista
Se elige onepage checkout, todo en
una sola vista CORRECTO
7 Estados
personalizados
Se puede definir nuevos estados
secundarios para
Se puede definir nuevos estados
secundarios para CORRECTO
113
una orden de pedido
una orden de pedido
8 descargar ordenes
desde el administrador
el administrador de Magento
puedes descargar los pedidos de
Magento
el administrador de Magento
puedes descargar los pedidos de
Magento
CORRECTO
9 ordenes en el
punto de venta del RPE
si el pedido esta pagado bajara al
sistema de tiendas para generar la
boleta electrónica
si el pedido esta pagado bajara al
sistema de tiendas para generar la
boleta electrónica
CORRECTO
Fuente: Elaboración Propia
Flujo de compra de un cliente
Figura 44. Flujo de compra
114
3.1.3.2.4.1.5. Prueba Funcional 5
En esta prueba haremos la prueba de calidad sobre el objetivo 3 para poder
verificar que el desarrollo del modulo de producto se encuentra funcionando bien y con
esto se resolvería el efecto que causaría.
Tabla 22. Prueba Funcional 5 - Sprint 1
Nombre del proyecto
Implementación y Optimización
de una plataforma e-
commerce
Navegador: Google Chrome
No. Caso de prueba Prueba número 5 Versión: 1.0
Escrito por Desarrollador Descripción: creación de os
Probado por Project Manager Probado en: Ambiente de prueba
Prueba # Acción Resultados esperados
Resultados actuales
Aprobado
1
Crear un Orden de servicio del
operador logístico
cliente al momento de generar una orden y pagarla enviara una trama al operador
logístico
cliente al momento de generar una
orden y pagarla enviara una
trama al operador logístico
CORRECTO
2
Las órdenes de servicio se crean si tienen ubigeo y
los otros datos
cliente al momento de elegir en su checkout elige su dirección de
destino
cliente al momento de elegir en su
checkout elige su dirección de
destino
CORRECTO
3
aplicar una regla de ubicaciones para que vaya a
distintos operadores
logístico
el sistema detecta si es lima y envía al cliente
un operador logístico y si es otro enviara con
este segundo operador
el sistema detecta si es
lima y envía al cliente un operador
logístico y si es otro enviara con
este segundo operador
CORRECTO
115
Fuente: Elaboración Propia
Una la figura “45” vamos a visualizar las ordenes generadas en el portal del
operador logístico.
Figura 45. Creación de ordenes de servicio del operador logístico
Fuente: Proveedor (Operador Logístico)
4 Crear un log con la trama que se
envía
Visualizar si toda la trama es correcta.
Encontrar en el system.log la
trama enviada. CORRECTO
5
Revisar si la orden de servicio
se creo en la plataforma
Encontrar un orden de servicio hecha desde el
portal de web
La orden se crea y adjunto el código de
seguimiento de la orden.
CORRECTO
6 Aplicar las
credenciales de producción
Después de hacer las pruebas necesarias
para proceder a producción
Ver que las ordenes se
creen después de un cambio de
estado.
CORRECTO
116
3.1.3.2.4.1.6. Prueba Funcional 6
En esta prueba haremos la prueba de calidad la creación de promociones
especiales a través de un modulo de Magento.
Tabla 23. Prueba Funcional 6 - Sprint 1
Fuente: Elaboración Propia
Nombre
del
proyecto
Implementación y
Optimización de una
plataforma e-commerce
Navegador: Google Chrome
No. Caso
de prueba Prueba número 6 Versión: 1.0
Escrito por Desarrollador Descripción: PROMOCIONES
Probado
por Project Manager Probado en: Ambiente de prueba
Prueba # Acción Resultados esperados Resultados
actuales Aprobado
1 El administrador del sitio
desea hacer una promoción
dar clic en el menú
promociones,
podemos crear una
promoción con regla
dar clic en el
menú
promociones,
podemos crear
una
promoción
con regla
CORRECTO
2
Cliente final pondrá el
cupón o verificará la
promoción en el carrito de
compras
Respuesta
satisfactoria del
ingreso de cupón
El cupón se
aplica
correctamente
CORRECTO
3
Cliente final tiene que
agregar su dirección y
referencia
Cliente llena los
campos de dirección y
referencia
Cliente llena
los campos de
dirección y
referencia
CORRECTO
4 Cliente puede hacer
distintas promociones
Si es una promoción
especifica.
Si es una
promoción
especifica.
CORRECTO
117
Figura 46. Ingreso de Cupón en el carrito de compra
Fuente: Elaboración propia desde Mockups
118
3.1.3.2.5. FASE DE IMPLEMENTACIÓN
Para esta fase debemos poner en producción subir todo lo realizado al ambiente
de calidad a través de un control de versiones, haremos uso de GITLAB, para poder
regresar a una rama cuando sea necesario y llevar el control de alguna modificación
realizada post subida.
3.1.3.3.SPRINT 2
Empezaremos con los módulos personalizados para Magento.
3.1.3.3.1. FASE DE PLANIFICACION:
3.1.3.3.1.1.REVISION Y MODIFICACION DEL Sprint BACKLOG
Podemos observar algunos cambios, los cuales son pequeñas modificaciones para
una mejor lectura.
Tabla 24. Sprint 2
SPRINT 2
id TAREAS
1 Verificación del Sprint 2
2 Modificación de la base de datos
3 Prototipo del Front-end (cara al usuario final)
4 Desarrollo de Historia de Usuario
4.1. Creación de matriz de envió a nivel nacional (peso x cantidad x lugar)
4.2. Desarrollo de Módulo de Restricciones en envió
4.3. Desarrollo de Módulo de Restricciones de método de pago
4.4. Desarrollo de Módulo de formularios libres
4.5. Desarrollo de Localización de Perú
4.6. Desarrollo de Matriz de todos los lugares del Perú
4.7. Mejoramiento del CHECKOUT
4.8. Cambios en el diseño, crear css personalizados con js
4.9. Implementar las pasarelas de pago.
4.10. Estados en el flujo compras.
6 Pruebas funcionales
7 Aprobación del producto(entregable)
Fuente: Elaboración Propia
119
3.1.3.3.2. FASE DE ANALISIS
3.1.3.3.2.1.REVISION Y MODIFICACION DE HISTORIAS DE USUARIOS
Se revisará y se analizará si en caso se necesita hacer algún cambio en Product
Backlog, en este caso no sufrirá ninguna variación las historias.
Tabla 25. Revisión del las Historias De Usuario - Sprint 2
Identificación
Rol Funcionali
dad Resultado
Númer
o de Escenario
Criterio de Aceptación
(Titulo)
Contexto
Evento Resultado/Compo
rtamiento esperado
HU-17 administrado
r
necesito integrar mi servidor de
correos masivos
(campanas de
marketing)
finalidad de enviar los
nuevos clientes al portal de
email marketing
3 cliente n/A newsletter
apartado de newsletter para
ver que clientes se han suscrito
HU-18 Administrado
r
necesita crear
productos con sus
atributos
la finalidad de poder vender y
captar clientes
según los atributos
4 PRODUCTO N/A Crear un producto
El administrador tendrá una
ventana con los campos de los
atributos de los productos.
HU-19 administrado
r
necesito filtros de
los atributos
más importante
s
Una mejor búsqueda
8 PRODUCTO N/A
Automatizar los
atributos de los
productos
A través de los atributos de los
productos configurar
HU-20 Administrado
r
necesita una matriz de precio
para envió a domicilio
la finalidad de poder
llegar a nivel nacional
9 MÉTODO DE ENVIÓ
N/A Administrar cobros de
envíos
modulo de una matriz de precio
por distrito o provincias
120
HU-21 Administrado
r
Necesita aplicar
reglas a los métodos de envió
finalidad de logísticos de la empresa
10 MÉTODO DE ENVIÓ
N/A Administra
r envíos
modulo con reglas de envíos
dependiendo al administrador o
campana de marketing
HU-22 Administrado
r
Necesita localizar
los puntos de ventas
físicos
finalidad poder tener un apartado
de localidades
11 TIENDAS -
MAPA N/A
Administrar las
tiendas (dirección, nombre, teléfono,
etc.)
modulo de tiendas o almacenes
HU-23 Administrado
r
necesita que la
orden de venta salga
boleta o factura
finalidad al momento de imprimir el
ticket de venta sea boleta o factura
12 ORDEN DE
VENTA N/A
Cliente puede
elegir si es boleta o factura
Modificar el flujo del cliente que
viene por defecto en Magento
HU-24 Administrado
r
necesita un flujo de estado en
la orden de venta
finalidad de tener más
estados que vayan con el
flujo de trabajo
13 ORDEN DE
VENTA N/A
Administrar el flujo de estado de
una compra
Modulo de estados
personalizados
HU-25 Administrado
r
necesita que las
ordenes de servicio con los
operadores
logísticos(terceros) se
creen automática
mente al cambiar un estado del
pedido
finalidad no crear manual
las OS 14
ORDEN DE VENTA
N/A
Crear Ordenes de
servicios de los
Courier automatiza
das
Modificar el flujo de Magento
HU-26 administrado
r
necesita poder el
detallados de ordenes
finalidad hacer
reportes de ventas
15 ORDEN DE
VENTA n/A
Crear un modulo
para poder descargar
todo el detallado
Modulo de exportar o
importar ordenes
121
de las ordenes
HU-27 administrado
r
crear formulario
s para especiales campanas
finalidad de crear
automáticamente
formularios cortos para suscripcione
s
16 REGISTRO/
CLIENTE n/A
Crear un formulario corto para campanas de registro
modulo de registros sin que este unido a los registros de los
clientes.
HU-28 Cliente
Final
Crear bloques de
fácil modificaci
ón
finalidad hacer
cambios de contenido(texto) sin tocar
el código fuente
17 BLOQUE
ESTÁTICOS n/A
hacer modificacio
nes en bloques
personalizados
Facilidad de uso para insertar
ciertas nuevas cosas.
HU-29 Cliente
Final
Seguir un mockup para las
interfaces
finalidad seguir con la línea graficas
de las tiendas
físicas(branding)
18 CLIENTE n/A
Hacer las implement
aciones según el
prototipo
Lineamiento de la marca
HU-30 Cliente
Final
crear las vistas
comunes (Sobre
nosotros, Únete a
nosotros, las guías
como comprar,
etc.)
finalidad del que el
cliente tenga más datos
sobre la empresa
19 CLIENTE n/A
Hacer las configuraci
ones necesarias para usar
las páginas s estáticas
de Magento
Rellenar las páginas s de contenido
HU-31 Cliente
Final
Se necesita la
implementación de
un método de pago
finalidad del que cliente
puede convertir
(finalice su compra)
25 CLIENTE/CHECKOUT
n/A Usar
métodos de pago
Creación de métodos de pago
122
HU-32 Cliente
Final
Se necesita las pruebas
de performance del sitio
finalidad que sitio web sea
rápido. 26
USABILIDAD
n/A
Usar las herramient
as para probar el sitio web
Resultados de las pruebas
Fuente: Elaboración Propia
3.1.3.3.2.2.VERIFICACIÓN Y MODIFICACIÓN DEL PRODUCT BACKLOG:
En el presente documento del sprint 2 podemos ver que ha sufrido una pequeña
variación en desarrollo:
Tabla 26. Revisión del Product Backlog - Sprint 2
PRODUCTO BACKLOG
ID Historias
de usuarios
Prioridad Requerimiento ESTIMACIÓN HORAS/DÍAS
SPRINT
Newsletter integrada con plataforma, envía trama a otra data
R19 HU-19 BAJA
Cliente que este en el newsletter debe estar en la plataforma de
email marketing
3 DÍAS 2
Implementación de atributos del producto
R20 HU-20 MEDIA
debe contar con todos los atributos
de un producto (color, edad, talla,
etc.)
1 DÍA 2
TEST de performance de sitio
R21 HU-21 BAJA
Hacer test de prueba del sitio y mejorar el tiempo
de carga
2 DÍAS 2
Personalización de la vista al cliente
R22 HU-22 MEDIA
debe implementar todas los estilos y
los apartados según los mockups
10 días 2
Modulo de exportar/importar ordenes
123
R23 HU-23 BAJA
crear un modulo para la
exportación de ordenes de forma
masiva
2 DÍAS 2
modulo de formularios personalizados
R24 HU-24 BAJA
Nos permita crear formularios
personalizados con solo arrastrar
los campos deseados
2 DÍAS 2
usar los bloques estáticos
R25 HU-25 BAJA
Se debe implementar los
bloques predeterminados, espacios definidos
1 DÍA 2
modulo de localización de tiendas físicas
R26 HU-26 MEDIA
Se debe crear un modulo de puntos
de ventas (ubicación en el
mapa)
2 DÍAS 2
Categoría de los productos
R27 HU-27 BAJA
Se debe crear todas las
categorías posibles para una mejor segmentación
7 horas 2
Filtros de los productos
R28 HU-28 BAJA
Se debe crear todos los atributos de los productos
de forma adecuada
1 DÍA 2
ORDEN DE VENTA
R29 HU-29 MEDIA
se requiere que cada estado del pedido pueda
enviar un correo al cliente //
personalizar plantillas
2 DÍAS 2
Crear los apartados informativos
124
R30 HU-30 BAJA
Según el modulo de CMS/Página s crear las landing
pages informativas
4 DÍAS 2
R31 HU-31 BAJA
Debe imprimir la variable SKU del
producto configurable
(producto madre), edad y genero
3 hora 2
Visualización de producto cara al usuario final
R32 HU-32 MEDIA
crear las guías de tallas de los
productos cuales deben mostrarse según marcas y el
genero
3 DÍAS 2
Fuente: Elaboración Propia
125
3.1.3.3.3. FASE DE DISEÑO
El modelo de base de datos es modelo EAV, entidad, atributo y valor, en la figura
“42” podemos visualizar todas las tablas que se van a utilizar para la creación de una
orden de venta, las cuales nos ayudara a guardar los datos necesarios, las cuales nos
ayudara a enviar la data al operador logístico y se cree una orden de venta.
Nos ayuda a ver si los pagos son reales o hay alguno que tiene posibilidad de
fraude.
Figura 47. Tablas Relacionadas a las Ventas
Se agrego:
Ubigeo
Dni
Referencia
Boleta/Factura
126
Fuente: Diagrama relacional de Magento
New Table
”Localizacion_
provincia”
Id_region
Id_provincia
Name
New Table
”Localizacion_distritos
”
Id_region
Id_provincia
Name
Ubigeo
127
3.1.3.3.4. FASE DE CONSTRUCCIÓN Y PRUEBAS
En esta fase vamos a detallar las pruebas correspondientes para revisar si los
requerimientos esta conforme al cliente:
A continuación, se mostrará flujo y explicación de algunos componentes creados
en este Sprint 2.
Flujograma de Formularios Libres
En la figura 48 se mostrará como se debe crear estos formularios que básicamente
van a ser utilizados para campañas de suscripciones. Este formulario trata de arrastrar y
crear campo sin necesidad de interactuar con el código fuente para una optima creación
de forma fácil y rápida.
El Administrador de CMS debe crear un nuevo bloque en el cual debe agregar los
campos que necesitara para que el usuario final(cliente) pueda agregar sus datos. Estos
datos se guardarán en la base de datos según los id de los formularios.
Figura 48. Formulario Libre
Fuente: Elaboración Propia
128
En la siguiente figura 49 se estará mostrando el modelo relacional de esta extensión:
Figura 49. Modelo relacional de formularios Libres
Fuente: Elaboración Propia
Flujograma de Carga de Inventario
En la siguiente figura 50, podemos ver como el ERP de tiendas físicas interactúa
con el CMS. Es decir, como llega al punto de crear el producto o actualizar el stock de
este.
Figura 50. Flujograma de la administración de stock
Fuente: Elaboración Propia
129
Matriz de costos de envío
En el checkout, el CMS reconoce el distrito y lo asocia el PostCode, además
verifica el peso ítems, en este caso se usa un valor por defecto 1 por cada producto. El
costo de envió es la combinación del peso volumétrico del pedido (Kilo base * 1 kilo
adicional).
En la figura 51 podemos observar una parte de esta matriz (.csv) la cual se sube en
Magento y las almacén en sus respectivas tablas.
Figura 51. Matriz de costos de envío
Fuente: elaboración propia
130
3.1.3.3.4.1.1. Prueba Funcional 7
Esta prueba consiste en almacenar la información de destino del cliente cuando él
haga una orden de venta.
Tabla 27. Prueba Funcional 7 - Sprint 2
Nombre del proyecto
Implementación y Optimización
de una plataforma e-
commerce
Navegador: Google Chrome
No. Caso de prueba
Prueba número 7
Versión: 1.0
Escrito por Desarrollador Descripción: Creación de matriz de destino
Probado por Project
Manager Probado en: Ambiente de prueba
Prueba # Acción Resultados esperados
Resultados actuales
Aprobado
1
Cuando el cliente se
encuentre en el checkout, él
tiene que poner su dirección
saldría el costo de envió
cuando el cliente pone su dirección hace un calculo de cuantos
productos y lugar para generar el costo de
envió
cuando el cliente pone su dirección hace un calculo de
cuantos productos y lugar para generar el
costo de envió
CORRECTO
2 Se almacena en
la orden de compra
Se guardan en la tabla sales_flat_order,
sales_flat_order_address
Los datos se encuentran
registrados en la base de datos.
CORRECTO
Fuente: Elaboración Propia
131
3.1.3.3.4.1.2. Prueba Funcional 8
Esta prueba consiste en la suscripción en el boletín de noticias para así poderle
enviar campañas de marketing.
Tabla 28. Prueba Funcional 8 - Sprint 2
Nombre del proyecto
Implementación y Optimización
de una plataforma e-
commerce
Navegador: Google Chrome
No. Caso de prueba
Prueba número 8 Versión: 1.0
Escrito por Desarrollador Descripción: Newsletter
Probado por Project Manager Probado en: Ambiente de prueba
Prueba # Acción Resultados esperados
Resultados actuales
Aprobado
1
Cliente se suscribe al boletín de
noticias
Confirmación de registro
Mensaje de satisfacción del
Newsletter CORRECTO
2
Verificar si el modulo brindado por el proveedor
de marketing lleva
correctamente la data
Visualizar si el cliente se quede
guardado
Cliente se guarda en una lista
CORRECTO
Fuente: Elaboración Propia
Adjunta las capturas de pantallas de los procesos de registro en un newsletter.
Figura 52. Prototipo del Apartado de Newsletter
Fuente: Elaboración Propia
132
Figura 53. Mensaje de satisfacción de inicio de sesión
Fuente: Elaboración del CMS de Pruebas
3.1.3.3.4.1.3. Prueba Funcional 9
Esta prueba consiste en crear distintas tiendas y así poderlas geolocalizar, para el
cliente se le hará más fácil ver donde están las tiendas más cercas a el por medio del mapa.
Tabla 29. Prueba Funcional 9 - Sprint 2
Nombre del proyecto
Implementación y Optimización
de una plataforma e-
commerce
Navegador: Google Chrome
No. Caso de prueba
Prueba número 9 Versión: 1.0
Escrito por Desarrollador Descripción: Creación de una tienda
Probado por Project Manager Probado en: Ambiente de prueba
Prueba # Acción Resultados esperados
Resultados actuales
Aprobado
1
El administrador desea crear una tienda física con
datos de esta
Cliente debe dar clic en
storelocator y llenar los campos
necesarios
Cliente debe dar clic en
storelocator y llenar los campos
necesarios
CORRECTO
2
geolocalizar una tienda
Se vera en una página informativa
Se vera en una página informativa
CORRECTO
Fuente: Elaboración Propia
133
3.1.3.3.4.1.4. Prueba Funcional 10
Esta prueba consiste en los métodos de envió definidos anteriormente en el
product backlog, es básicamente en la elección del método de envió que elegirá o método
de pago que erigiría el cliente.
Tabla 30. Prueba Funcional 10 - Sprint 2
Nombre del proyecto
Implementación y Optimización
de una plataforma e-
commerce
Navegador: Google Chrome
No. Caso de prueba
Prueba número 10
Versión: 1.0
Escrito por Desarrollador Descripción: Método de pago
Probado por Project Manager Probado en: Ambiente de prueba
Prueba # Acción Resultados esperados
Resultados actuales
Aprobado
1
En el checkout debemos iniciar
sesión y elegir un producto
Al iniciar sesión debe derivarlos a
mi cuenta.
Los resultados son correctos, es
redirigido a mi cuenta.
CORRECTO
2 Agregarlo en el
carrito de compra
Ir a la vista de agregar al carrito
Aparecerá el producto agregado
CORRECTO
3 Erigiremos
nuestro método de envió.
Seleccionar un método de envió (envió a domicilio
o recojo en tienda)
Aceptara el método de envió designado por el
usuario
CORRECTO
4
Haremos la selección de
método de pago para revisar si
esta correcta la integración.
Elegir el método de pago a probar
después de elegir el método saldrá
la pasarela de pago del método
de pago.
CORRECTO
5
hacer pruebas de envíos de dato a
la pasarela de pago
Envías la trama de un pedido a la pasarela y ver si figuran errores
Envías la trama de un pedido a la pasarela y ver si figuran errores
CORRECTO
Fuente: Elaboración Propia
134
Figura 54. Mockup de Método de pago
Fuente: Elaboración Propia
3.1.3.3.5. FASE DE IMPLEMENTACIÓN
Para esta fase debemos poner en producción subir todo lo realizado al ambiente
de calidad a través de un control de versiones, haremos uso de GITLAB, para poder
regresar a una rama cuando sea necesario y llevar el control de alguna modificación
realizada post subida.
135
3.1.4. FASE 4: CIERRE
Se hará el cierre del proyecto con un acta.
Tabla 31. Cierre del Proyecto
PROYECTO
FECHA DE INICIO DEL PROYECTO Abril 2016 LIDER USUARIO AP
FECHA DEL CIERRE DEL PROYECTO Agosto 2016 LIDER TI PD
PRINCIPALES ENTREGABLES
ENTREGABLES FASE DEL PROYECTO
1. Lista de requerimiento Planificación
2. Modulo de gestión de cliente DESARROLLO
3. Modulo de gestión de producto DESARROLLO
4. Modulo de creación de ordenes de servicio DESARROLLO
5. Modulo de libro de reclamaciones DESARROLLO
6. Personalización del checkout DESARROLLO
7. Creación y personalización de modulo de envió DESARROLLO
8. Creación de modulo de pago DESARROLLO
9. Pruebas funcionales, de Optimización y de vulnerabilidades
DESARROLLO
10. Realización de estilos en el frontend DESARROLLO
CONTROLES DE CAMBIO
DESCRIPCION FASE DEL PROYECTO
136
CAPITULO 4
RESULTADOS
4.1.Resultados
Al cumplir con los objetivos específicos se puede validar que se cumplió
correctamente con el desarrollo del proyecto, esto se llevara acabo a través de encuestas
y data que se proporcionara para obtener los resultados y poder definir si cumplieron los
objetivos.
Los datos podemos obtener con los reportes de Google Analytics, encuestas para
ver si se han eliminados ciertos procesos manuales.
Usando los objetivos planteados en el capitulo 2, se realizo una encuesta de
satisfacción del producto para poder medir si la implementación de este fue la correcta y
se llego a cumplir con todos lo que se estaba esperando.
Estas preguntas las podemos encontrar en el anexo 11, para hacer la tabla
comparativa haremos una tabla de antes y ahora para verificar como era antes al cambio
realizado.
137
• OBJETIVO 1:
o Aumentar la disponibilidad de la atención de la tienda virtual (24/7).
Captura de pantalla de las ventas realizadas:
Figura 55. Pedidos
Fuente: Elaboración Propia
Descripción:
Podemos observar la cantidad de pedidos que se han realizado en el mes de Julio
y así poder visualizar la cantidad de artículos vendidos y tener información sobre la
atención o la apertura de la tienda.
138
Encuesta:
Tabla 32. Cuadro Antes y Ahora - Encuesta 1
ANTES AHORA
• La atención de las tiendas era de 10am
a 10pm.
• Las tiendas no podían indicar que
otros modelos podrían tener.
• Tenia a que ir a una tienda hacer un
cambio o hacer un reclamo.
• La atención es de 24 horas.
• Pueden ver la variedad de productos.
• Ayuda a la post venta (cambios o
devoluciones de productos).
• Orientación a la hora de hacer una
compra.
Fuente: Elaboración Propia
139
• OBJETIVO 2:
o Administrar el stock de la tienda virtual cumpliendo reglas definidas.
CAPTURAS DEL SISTEMA BLOQUE DEL PRODUCTO
Figura 56. Atributos Producto
Fuente: Elaboración del CMS – Magento
Figura 57. Atributo Precio - Producto
Fuente: Elaboración del CMS – Magento
140
Figura 58. Stock de Producto
Fuente: Elaboración del CMS – Magento
Figura 59. Stock detallado - Tienda
Fuente: Elaboración del CMS – Magento
Figura 60.Regla de Carrito de compra
Fuente: Elaboración del CMS – Magento
141
DESCRIPCION:
Podemos observar las distintas pantallas sobre el manejo del producto, los
atributos que se necesitan para crear un producto, el cual será visto por el cliente final.
El precio del producto, la oferta que tiene como la fecha de inicio y fin de este
descuento. El stock de producto, la sumatoria de stock de todas las tiendas que aplican.
La figura “50” captura podemos verificar que el stock del producto se encuentra
detallado por tiendas. La regla de stock solo se puede comprar 3 máximo por producto,
internamente el stock que refleja es la sumatoria de las tallas mayor a 3.
ENCUESTA:
142
Tabla 33. Cuadro Antes y Ahora - Encuesta 2
ANTES AHORA
• La tienda no puede tener mucha
cantidad de stock.
• Limitación por el espacio físico.
• Poca variedad de modelos.
• Clientes insatisfechos por no
encontrar su talla.
• Puede usar el stock de varias tiendas
para así mostrar una mayor gama de
tallas y modelos.
• Si se desea tener mayor cantidad de
productos se haría un upgrade a la
instancia de la base de datos.
Fuente: Elaboración Propia
• OBJETIVO 3:
o Realizar de manera eficiente la creación de ordenes de servicio del
operador logístico.
Captura de pantallas:
o Cliente genera un pedido por la web.
o Cliente paga el pedido, automáticamente a través de un evento se envía
la trama al Courier, cumpliendo ciertas reglas.
o Se crea una orden de servicio en el portal de Courier con los datos del
cliente.
Figura 61. Operador logístico
Fuente: Operador logístico
143
Se hizo una integración de la plataforma e-commerce y del operador logístico con
el fin de eliminar o detener la creación de ordenes de servicios. Este proceso se realiza
cuando el cliente paga un pedido automáticamente se crea un orden de servicio en el
operador.
ENCUESTA
Tabla 34. Cuadro Antes y Ahora - Encuesta 3
144
ANTES AHORA
• La generación de ordenes de servicio
se hacían copiando y pegando la
información.
• Mucha demora en copiar datos y
pegarlos.
• La generación se hace a través de web
services, cuando el cliente haya
pagado el pedido este cambiara a
estado pedido pagado.
Fuente: Elaboración Propia
4.2.Presupuesto
Para el presupuesto no estaremos basando en las formulas de VAN y TIR, con la
finalidad de sacar un prepuesto estimado para dicho proyecto.
4.2.1. Gastos en personal
En la tabla 34 veremos el detalla de gastos por puesto y el costo de cada uno.
Tabla 35. Tabla de Presupuesto del Personal que labora en la empresa
Trabajadores
Puesto Cantidad Costo indiviual Total
Jefe del Proyecto 1 S/6,000 S/6,000
Jefe Ecommerce 1 S/6,000 S/6,000
Analista Programador 1 S/3,000 S/3,000
Analista Funcional 1 S/3,000 S/3,000
Total S/18,000
Fuente: Elaboración propia
145
4.2.2. Gastos por Equipos
En la tabla 35 podemos ver el detalla de gastos por equipos que se realizo entorno
al proyecto.
Tabla 36. Gastos detalles por Equipos
EQUIPOS (hardware)
Equipo Cantidad Costo
individual Total Comentarios
Laptops 2 S/3,500.00 S/7,000.00 Para el desarrollo y la implementación
Escritorio 2 S/250.00 S/500.00 Para la lectura de datos o
documentación
Sillas 2 S/250.00 S/500.00 Para sentarse y avanzar
Tachos 1 S/250.00 S/250.00 Botar la basura
Celular Android
1 S/2,000.00 S/2,000.00 Testing responsive Android
Celular IOS 1 S/2,000.00 S/2,000.00 Testing responsive iOS
Total S/12,250
Fuente: Elaboración propia
4.2.3. Gasto por Software
En la tabla 36 podemos ver el detalla de gastos por software que se realizo entorno
al proyecto.
Tabla 37. Detallado de gastos por software
SOFTWARE
Licencia Cantidad Costo individual Total
Microsoft Visual Code 4 S/0.00 S/0.00
Xamp 0 S/0.00 S/0.00
Google Analytics 0 S/0.00 S/0.00
Google Tag Manager 0 S/0.00 S/0.00
Magento Communitty 0 S/0.00 S/0.00
Microsoft Office 2016 4 S/500.00 S/2,000.00
Microsoft Windows 10 4 S/680.00 S/2,720.00
Microsoft SQL 2014 1 S/931.00 S/931.00
TOTAL S/5,651.00
Fuente: Elaboración propia
146
4.2.4. COSTOS
En la tabla 37 podemos ver los gastos en estos 4 meses.
Tabla 38. TABLA DE COSTOS
Mes 1 Mes 2 Mes 3 Mes 4 total S/
Costos x Tiempo Mensual Mensual Mensual Mensual Soles
Trabajadores S/18,000 S/18,000 S/18,000 S/18,000 S/72,000
Equipos(hardware) S/12,250 S/0 S/0 S/0 S/12,250
Software S/5,651 S/0 S/0 S/0 S/5,651
Otros Gastos(fijos o varibles)
S/350 S/350 S/350 S/350 S/1,400
Total S/36,251 S/18,350 S/18,350 S/18,350 S/91,301
Acumulado S/36,251 S/54,601 S/72,951 S/91,301
Fuente: Elaboración propia
Figura 62. Costos Acumulables
Fuente: Elaboración propia
4.2.5. Calculo del Var y Tir del proyecto
En la siguiente Tabla 38, haremos el calculo la rentabilidad del proyecto y saber
si es viable o no. Los parámetros que usaremos para calcular la viabilidad de nuestro
proyecto serán el VAN (Valor Actual Neto) y el TIR (Tasa Interna de Retorno).
147
Tabla 39. Detalle del Van y TIR
Tasa de descuento
anual 10.00%
COSTO DEL PROYECTO
COSTO DE EQUIPOS
COSTO DE SOFTWARE
COSTO DEL PERSONAL
0 S/36,251
1 -S/36,251 S/20,399 S/5,651.00 S/18,000
VAN S/487.46
TIR 11%
Fuente: Elaboración propia
Como se puede observar en la tabla anterior se representa los ingresos obtenidos
por cada mes, los cuales son llevados al presente, hasta que, se puede observar que a partir
del 1er mes se termina de pagar la inversión requerida y el flujo empieza a ser positivo.
Por consiguiente, queda confirmando que la VAN > 0 y que el proyecto será rentable.
148
CONCLUSIONES
Se consiguió implementar la tienda virtual a través de un CMS, el cual es Magento
logramos reducir el tiempo de creación desde cero de una plataforma de ventas online
la cual tiene un prestigio a nivel global.
Se logró personalizar Magento con distintos módulos para poder llegar a cumplir los
objetivos definidos en el Project chárter.
1. Al crear la tienda virtual, se pudo mejorar la atención puesto que, al ser virtual
esta estará abierta las 24 horas de los 7 días, nos dará varios beneficios ya que
cumplirá con las ventas pronosticas, los visitantes esperados.
2. Se consiguió la incrementar los productos visibles en la web es decir si en tienda
expone X cantidad bueno en la tienda online esto puede aumentar increíblemente
ya que al no tener un espacio físico se puede exponer todo el producto posible
para evitar inconvenientes se deben crear unas reglas de stock por ejemplo mínimo
productos ósea no mostrar productos con menos 2 de stock y más reglas.
3. Se consiguió la integración con un operador logístico el cual nos puede brindar
las ordenes de servicios creadas en su portal. Se agilizo la creación de estas
ordenes para que no copien y pega la información del pedido realizado.
149
BIBLIOGRAFÍAS
eCommerce Platforms | eCommerce Solutions | Magento. (2018, 5 junio). Recuperado
23 agosto, 2019, de https://magento.com/products/magento-commerce
Boza García, Andrés, B. G. A. (2017, 24 octubre). Implantación de una plataforma
eCommerce basada en SAP Hybris para una empresa multinacional del sector
servicios. Recuperado 22 agosto, 2019, de
https://riunet.upv.es/handle/10251/89942
Bruce, B. (2019, 9 mayo). Magento Entity Attribute Value (EAV) Model - Magento
Tutorial. Recuperado 22 agosto, 2019, de https://blog.magestore.com/entity-
attribute-value-in-magento/
Carú Cisternas, Roberto. Profesor guía, C. C. R. (2018, 28 mayo). Integración e-
commerce y business intelligence con tecnología open source para pymes.
Recuperado 22 agosto, 2019, de http://repositorio.ugm.cl/handle/12345/1082
Comercio B2C. (s.f.). Recuperado 23 agosto, 2019, de
https://www.salesforce.com/es/products/commerce-cloud/ecommerce/
Ecommerce Definition - What is Ecommerce. (s.f.). Recuperado 22 agosto, 2019, de
https://www.shopify.com/encyclopedia/what-is-ecommerce
IBM Knowledge Center. (s.f.). Recuperado 23 agosto, 2019, de
https://www.ibm.com/support/knowledgecenter/es/SSZLC2_8.0.0/com.ibm.com
merce.admin.doc/concepts/covoverall.htm
Is My B2B Business Ready for Oracle Commerce Cloud? (2017, 21 septiembre).
Recuperado 23 agosto, 2019, de https://blogs.oracle.com/cx/is-my-b2b-business-
ready-for-oracle-commerce-cloud
Joanna Carter, J. (2019, 18 febrero). Más personas navegan en dispositivos móviles,
pero compran a través de computadoras de escritorio. Recuperado 21 agosto,
2019, de https://www.smartinsights.com/ecommerce/more-people-browse-on-
mobile-but-buy-via-desktop/
Ley N° 29733. (s.f.). Recuperado 22 agosto, 2019, de
https://www.gob.pe/institucion/minsa/normas-legales/243470-29733
Magic Quadrant Research Methodology. (s.f.). Recuperado 22 agosto, 2019, de
https://www.gartner.com/en/research/methodologies/magic-quadrants-research
MySQL | La base de datos de código abierto más popular del mercado | Oracle España.
(s.f.). Recuperado 22 agosto, 2019, de https://www.oracle.com/es/mysql/
PHP: ¿Qué es PHP? - Manual. (s.f.). Recuperado 22 agosto, 2019, de
https://www.php.net/manual/es/intro-whatis.php
Plataformas de comercio electrónico y soluciones de software omnicanal | SAP. (s.f.).
Recuperado 23 agosto, 2019, de
https://www.sap.com/latinamerica/products/crm/e-commerce-platforms.html
¿Qué es el middleware? (s.f.). Recuperado 22 agosto, 2019, de
https://www.redhat.com/es/topics/middleware/what-is-middleware
¿Qué es un Operador Logístico? - Operador Logístico. (2015, 25 noviembre).
Recuperado 22 agosto, 2019, de
https://comunidad.iebschool.com/operadorlogístico/2015/11/25/que-es-un-
operador-logístico/
Abc tecnología, A. B. C. (2015, 16 febrero). ¿Qué es una API y para qué sirve?
Recuperado 23 agosto, 2019, de
https://www.abc.es/tecnologia/consultorio/20150216/abci--201502132105.html
150
Frontend y Backend. (2016, 21 septiembre). Recuperado 23 agosto, 2019, de
https://devcode.la/blog/frontend-y-backend/
Modelo vista controlador (MVC). Servicio de Informática ASP.NET MVC 3
Framework. (s.f.). Recuperado 23 agosto, 2019, de
https://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-controlador-
mvc.html
Que es "target"? | metodo marketing. (2018, 6 febrero). Recuperado 23 agosto, 2019, de
https://metodomarketing.com/que-es-target/
Qué es middleware: definición y ejemplos | Microsoft Azure. (s.f.). Recuperado 23
agosto, 2019, de https://azure.microsoft.com/es-es/overview/what-is-
middleware/
Tipos de productos que puedes tener en tu tienda Magento. (s.f.). Recuperado 23 agosto,
2019, de https://ecommaster.es/tipos-de-productos-tienda-magento
Susana Maria Urbano Mateos, S. S. UM. (2019, 1 abril). Qué es y como funciona la
pasarela de pago en ecommerce. Recuperado 23 agosto, 2019, de
https://www.actualidadecommerce.com/que-es-y-como-funciona-la-pasarela-de-
pago-en-ecommerce/
¿Qué es AWS? (s.f.). Recuperado 23 agosto, 2019, de https://aws.amazon.com/es/what-
is-aws/
¿Qué es el SEO? (s.f.). Recuperado 23 agosto, 2019, de https://www.marketing-
xxi.com/seo.html
¿Qué es la PYME? (s.f.). Recuperado 23 agosto, 2019, de http://www.ipyme.org/es-
ES/DatosPublicaciones/Paginas/DefinicionPYME.aspx
¿Qué es una API? (s.f.). Recuperado 23 agosto, 2019, de
https://www.redhat.com/es/topics/api/what-are-application-programming-
interfaces
Qué es el checkout en el e-commerce | Proceso de compra online. (2018, 30 enero).
Recuperado 23 agosto, 2019, de https://sell.emprendepyme.net/que-es-el-
checkout-en-el-e-commerce.html
Qué es SCRUM. (2018, 9 octubre). Recuperado 23 agosto, 2019, de
https://proyectosagiles.org/que-es-scrum/
The first single application for the entire DevOps lifecycle - GitLab. (s.f.). Recuperado
26 agosto, 2019, de https://about.gitlab.com/
eCommerce Platforms | Best eCommerce Software for Selling Online | Magento. (2018,
24 mayo). Recuperado 26 agosto, 2019, de https://magento.com/
Ley de Protección de Datos Personales. (2017, 6 junio). Recuperado 26 agosto, 2019, de
https://www2.deloitte.com/pe/es/pages/risk/articles/data_law_protection.html
151
ANEXOS
Anexo 1. Formato de Project Charter
NOMBRE DEL PROYECTO SIGLAS DEL PROYECT0
DESCRIPCION DEL PROYECTO
DEFINICIÓN DEL PRODUCTO
REQUISITOS DEL PROYECTO
OBJETIVOS DEL PROYECTO
152
FINALIDAD DEL PROYECTO
PROJECT MANAGER DEL PROYECTO
Nombre Nivel de Autoridad Descripción
Project Manager
Project Team Resources
CRONOGRAMA DEL PROYECTO
EVENTO FECHA Inicio de Proyecto
Planificación
Ejecución
Cierre
AMENAZAS DEL PROYECTO
OPORTUNIDADES DEL PROYECTO
PLANEAMIENTO INICIAL DEL PROYECTO
CONCEPTO MONTO (s/.)
TOTAL PRESUPUESTO
153
Anexo 2. Gestión de Interesados
Registro de interesados (Stakeholders)
INFORMACIÓN DE IDENTIFICACIÓN Información de evaluación Clasificación de los
interesados
Puesto Ubicación Rol en el proyecto
Requisitos principales
Expectativas principales
Grado de influencia
Grado de interés
Fase de mayor interés
Interno / Externo
Apoyo / Neutral / Reticente
154
Anexo 3. Matriz de Asignación de Responsabilidades
Matriz de Asignación de Responsabilidades (RAM)
Responsabilidades: P: Responsable Primario, S: Responsable Secundario
Paquete de Trabajo / Actividad Responsabilidades
ID Descripción Paquete de Trabajo o Actividad Colaborador 1 Colaborador 2 Colaborador 3 Colaborador 4 Colaborador 5
1 Paquete de Trabajo / Actividad 1
2 Paquete de Trabajo / Actividad 2
3 Paquete de Trabajo / Actividad 3
4 Paquete de Trabajo / Actividad 4
5 Paquete de Trabajo / Actividad 5
6 Paquete de Trabajo / Actividad 6
7 Paquete de Trabajo / Actividad 7
8 Paquete de Trabajo / Actividad 8
9 Paquete de Trabajo / Actividad 9
10 Paquete de Trabajo / Actividad 10
155
Anexo 4. WBS o EDT
Vista jerárquica Vista de Árbol
Fuente: https://medium.com/administrador-de-proyectos/crear-la-edt-wbs-cd3d988e3469
156
Anexo 5. Documento de Riesgo
REGISTRO DE RIESGOS
Area/Linea Linea 1
Exposición total al Riesgo =promedio de la severidad
Identificación Análisis Planificación Respuesta Monitoreo
Nr Descripción de Riesgos Categoría Probab. Impacto Severidad Responsable Respuesta Disparador Estado Contingencia
157
Anexo 6. Sprint 0
Identificación Rol Funcionalidad Resultado Número
de Escenario
Criterio de Aceptación (Titulo)
Contexto Evento Resultado/Comportamiento
esperado
158
Anexo 7. Product Backlog
PRODUCTO BACKLOG
ID Historias de
usuarios Prioridad Requerimiento
ESTIMACIÓN HORAS/DÍAS
SPRINT
159
Anexo 8. Documento del Sprint Backlog 1
id TAREAS
1
2
3
4
5
6
7
160
Anexo 9. Documento del Sprint Backlog 2
id TAREAS
1
2
3
4
5
6
7
161
Anexo 10. Plan de Pruebas
Nombre del proyecto Navegador:
No. Caso de prueba Versión:
Escrito por Descripción:
Probado por Probado en:
Prueba # Fecha Acción Resultados esperados Resultados actuales Aprobado?
162
Anexo 11. Cierre de Proyecto
PROYECTO
FECHA DE INICIO DEL PROYECTO LIDER USUARIO
FECHA DEL CIERRE DEL PROYECTO LIDER TI
PRINCIPALES ENTREGABLES
ENTREGABLES FASE DEL PROYECTO
CONTROLES DE CAMBIO
DESCRIPCION FASE DEL PROYECTO
163
Anexo 12. Encuesta sobre conclusiones de proyecto
164
Fuente: elaboración propia