Facultad de Ingeniería -...

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.

https://www.gartner.com/doc/reprints?id=1-58BE78T&ct=180720&st=sb

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

https://cdn2.hubspot.net/hubfs/4784080/Files/Website%20PDFs/EN/Other%20Studies/The_Forrester_Wave%E2%84%A2-B2C_Commerce_Suites-Q3_2018.pdf

https://cdn2.hubspot.net/hubfs/4784080/Files/Website%20PDFs/EN/Other%20Studies/The_Forrester_Wave%E2%84%A2-B2C_Commerce_Suites-Q3_2018.pdf

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

https://www.sap.com/latinamerica/products/crm/e-commerce-platforms/pricing.html

https://www.sap.com/latinamerica/products/crm/e-commerce-platforms/pricing.html

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/

https://blogs.oracle.com/cx/is-my-b2b-business-ready-for-oracle-commerce-cloud


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.

https://magento.com/

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.


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/

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

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

https://www.mysql.com/

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/

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#

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


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


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/

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.

https://www.redhat.com/es/topics/middleware/what-is-middleware

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.

https://sell.emprendepyme.net/proceso-de-compra

https://sell.emprendepyme.net/proceso-de-compra

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


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


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


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


Desarrollador de la plataforma

Lima Desarrolladores

Dedicar todo tiempo posible para

desarrollar los módulos

personalizados.

Desarrollar las soluciones requeridas

Alto Alto Todo el


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: 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



8 CIERRE/Acta de Conformidad P P P S P S


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.


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


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


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


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


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)


84

Tabla 14. 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. 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.



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.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.




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

Facebook

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


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


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


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


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


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


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

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


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


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


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


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


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


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


Escrito por Desarrollador Descripción: Gestión de productos



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


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






Nombre del proyecto

Implementación y Optimización de

una plataforma e-commerce


No. Caso de prueba


Escrito por Desarrollador Descripción: libro de Reclamaciones



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


Captura del Registro de Reclamos:

Figura 43. Libro de Reclamaciones

112


En esta prueba haremos la prueba de calidad de la creación de una orden de venta.


Nombre del proyecto

Implementación y Optimización de

una plataforma e-commerce


No. Caso de prueba Prueba número 4 Versión: 1.0

Escrito por Desarrollador Descripción: ORDEN DE PEDIDO



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



en un campo oculto



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


Flujo de compra de un cliente

Figura 44. Flujo de compra

114






Nombre del proyecto

Implementación y Optimización

de una plataforma e-

commerce


No. Caso de prueba Prueba número 5 Versión: 1.0

Escrito por Desarrollador Descripción: creación de os



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


Una la figura “45” vamos a visualizar las ordenes generadas en el portal del


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


En esta prueba haremos la prueba de calidad la creación de promociones

especiales a través de un modulo de Magento.



Nombre

del

proyecto

Implementación y

Optimización de una

plataforma e-commerce


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.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.




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


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


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


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


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


128

En la siguiente figura 49 se estará mostrando el modelo relacional de esta extensión:

Figura 49. Modelo relacional de formularios Libres


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


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


130


Esta prueba consiste en almacenar la información de destino del cliente cuando él

haga una orden de venta.


Nombre del proyecto



commerce


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


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


131


Esta prueba consiste en la suscripción en el boletín de noticias para así poderle

enviar campañas de marketing.


Nombre del proyecto



commerce


No. Caso de prueba


Escrito por Desarrollador Descripción: Newsletter



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


Adjunta las capturas de pantallas de los procesos de registro en un newsletter.

Figura 52. Prototipo del Apartado de Newsletter


132

Figura 53. Mensaje de satisfacción de inicio de sesión

Fuente: Elaboración del CMS de Pruebas


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.


Nombre del proyecto



commerce


No. Caso de prueba


Escrito por Desarrollador Descripción: Creación de una tienda



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


133


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.


Nombre del proyecto



commerce


No. Caso de prueba

Prueba número 10

Versión: 1.0

Escrito por Desarrollador Descripción: Método de pago



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


134

Figura 54. Mockup de Método de pago


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


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.


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


140

Figura 58. Stock de Producto


Figura 59. Stock detallado - Tienda


Figura 60.Regla de Carrito de compra


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


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.


• OBJETIVO 3:

o Realizar de manera eficiente la creación de ordenes de servicio del


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


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.


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


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


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


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


Figura 62. Costos Acumulables


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%


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


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


¿Qué es un Operador Logístico? - Operador Logístico. (2015, 25 noviembre).


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?


https://www.abc.es/tecnologia/consultorio/20150216/abci--201502132105.html

https://magento.com/products/magento-commerce

https://riunet.upv.es/handle/10251/89942



http://repositorio.ugm.cl/handle/12345/1082

https://www.salesforce.com/es/products/commerce-cloud/ecommerce/

https://www.shopify.com/encyclopedia/what-is-ecommerce

https://www.ibm.com/support/knowledgecenter/es/SSZLC2_8.0.0/com.ibm.commerce.admin.doc/concepts/covoverall.htm

https://www.ibm.com/support/knowledgecenter/es/SSZLC2_8.0.0/com.ibm.commerce.admin.doc/concepts/covoverall.htm



https://www.smartinsights.com/ecommerce/more-people-browse-on-mobile-but-buy-via-desktop/

https://www.smartinsights.com/ecommerce/more-people-browse-on-mobile-but-buy-via-desktop/

https://www.gob.pe/institucion/minsa/normas-legales/243470-29733

https://www.gartner.com/en/research/methodologies/magic-quadrants-research

https://www.oracle.com/es/mysql/


https://www.sap.com/latinamerica/products/crm/e-commerce-platforms.html


https://comunidad.iebschool.com/operadorlogistico/2015/11/25/que-es-un-operador-logistico/

https://comunidad.iebschool.com/operadorlogistico/2015/11/25/que-es-un-operador-logistico/

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

https://devcode.la/blog/frontend-y-backend/

https://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-controlador-mvc.html

https://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-controlador-mvc.html

https://metodomarketing.com/que-es-target/

https://azure.microsoft.com/es-es/overview/what-is-middleware/

https://azure.microsoft.com/es-es/overview/what-is-middleware/

https://ecommaster.es/tipos-de-productos-tienda-magento

https://www.actualidadecommerce.com/que-es-y-como-funciona-la-pasarela-de-pago-en-ecommerce/

https://www.actualidadecommerce.com/que-es-y-como-funciona-la-pasarela-de-pago-en-ecommerce/

https://aws.amazon.com/es/what-is-aws/

https://aws.amazon.com/es/what-is-aws/

https://www.marketing-xxi.com/seo.html

https://www.marketing-xxi.com/seo.html

http://www.ipyme.org/es-ES/DatosPublicaciones/Paginas/DefinicionPYME.aspx

http://www.ipyme.org/es-ES/DatosPublicaciones/Paginas/DefinicionPYME.aspx

https://www.redhat.com/es/topics/api/what-are-application-programming-interfaces

https://www.redhat.com/es/topics/api/what-are-application-programming-interfaces

https://sell.emprendepyme.net/que-es-el-checkout-en-el-e-commerce.html

https://sell.emprendepyme.net/que-es-el-checkout-en-el-e-commerce.html

https://proyectosagiles.org/que-es-scrum/

https://about.gitlab.com/

https://magento.com/

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










155

Anexo 4. WBS o EDT

Vista jerárquica Vista de Árbol

Fuente: https://medium.com/administrador-de-proyectos/crear-la-edt-wbs-cd3d988e3469

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


Facultad de Ingeniería -...

Documents

Transcript of Facultad de Ingeniería -...