RONALD ARIEL MAMANI LLUSCO

ESTUDIANTES :
ROLY YURI QUISPE BAUTISTA
SEMESTRE : 7mo SEMESTRE
DOCENTE : Lic. MSc. Claudia Yañiquez.

La Paz - Bolivia

2019

0
Contenido
Capítulo 1: Generalidades................................................................. 3
1.1 Presentación .............................................................................. 3

1.3 DESCRIPCIÓN DEL OBJETO DE ESTUDIO............................. 5

1.4 PLANTEAMIENTO DEL PROBLEMA ........................................ 6

1.4.1 Problema Principal ............................................................ 6

1.4.2 FORMULACIÓN DEL PROBLEMA. ................................... 7
1.5 OBJETIVOS DE LA INVESTIGACIÓN ....................................... 7

1.5.1 OBJETIVO GENERAL ........................................................ 7

1.5.2 OBJETIVOS ESPECÍFICOS. .............................................. 7
1.6 ALCANCES Y LIMITACIONES DEL PROBLEMA ...................... 7

CAPÍTULO 2: MARCO TEÓRICO..................................................... 10

2.1 METODOLOGÍA ...................................................................... 10

Metodología Scrum ........................................................................ 10

Transparencia ........................................................................... 10
Inspección ................................................................................. 10
Adaptación ................................................................................ 11
Equipo Scrum ................................................................................ 11

El Product Owner ........................................................................... 11

El Equipo de Desarrollo ................................................................. 11

El Scrum Master ............................................................................ 12

Eventos de Scrum: Inspección y Eventos de Adaptación ............... 13

Entendiendo el Sprint ..................................................................... 14

Planificación del Sprint ................................................................... 14

Objetivo del Sprint .................................................................... 16

Scrum Diario .................................................................................. 16

Revisión del Sprint ......................................................................... 17

1
 Retrospectiva del Sprint ................................................................. 18

Elementos de Scrum ...................................................................... 19

El Backlog de Producto .............................................................. 20

Monitorizar el Progeso de Cara a Conseguir un Objetivo ........... 21
Backlog del Sprint....................................................................... 21
Monitorizar el Progreso del Sprint .................................................. 22

Incremento ................................................................................. 22
Transparencia en los Elementos .................................................... 22

Definición de “Finalizado” ............................................................... 23

Capítulo 3: Análisis de factibilidad................................................. 25

3.1 Factibilidad Operacional ........................................................... 25

3.2 Factibilidad Técnica ................................................................. 26

3.2.1 Hardware disponible para el desarrollo ......................... 26

3.2.2 Software para el desarrollo ............................................. 26
3.2.3 Lenguaje de desarrollo.................................................... 27
3.3 Factibilidad Económica ............................................................ 28

3.3.1 Estimación de costo del proyecto .................................. 29

2
Capítulo 1: Generalidades

1.1 Presentación

El presente proyecto es el desarrollo de un sistema web para la venta de productos

ofrecidos por una tienda de abarrotes. Desarrollado para apoyar a su negocio.

En este documento se indica y especifica la empresa para la que se desarrolla este

proyecto de título, indicando los aspectos principales del proyecto. Como la
obtención de los requisitos, la que es realizada con los datos y requerimientos que
la empresa entrega y los datos entregados por las encuestas realizadas, todo esto
para comprender mejor sistema que necesita la tienda para su negocio.

También se presenta el análisis de la factibilidad del desarrollo del proyecto, tanto

técnico, operativo y económicamente.

3
1.2 Antecedentes

Un proyecto fue desarrollado para la empresa de comercio masivo de

productos “HIPERMERCADOS KETAL S.A.”, para el control y gestión de los
espacios con respecto a sus productos que tienen todas sus salas de toda La
Paz. Proporcionar información y comportamiento de sus espacios;
modificación, eliminación, reubicación del espacio en un área de la sala,
registro histórico en tiempo, rotación de productos, de generar reportes de la
rentabilidad de cada espacio que genera en un determinado tiempo;
obteniendo índices de análisis gerenciales con el fin de evitar pérdidas a la
empresa y generar ganancias.
Con la realización de ese proyecto se tuvo una consolidación personal de los
conocimientos adquiridos durante la carrera, tanto de planificación y análisis,
como de programación y base de datos; así como la involucración en el
desarrollo de un proyecto de suficiente magnitud. Con eso se obtuvo una serie
de mejoras y beneficios para la empresa. Por una parte se ha conseguido la
fusión de Merchandising, donde se complementara al saber, cual es la mejor
ubicación del espacio en la sala, la mayor rentabilidad de cada espacio con
respecto a sus productos, Merchandising se enfoco en trabajar con los
espacios de menor rentabilidad , con la información que proporciono el
proyecto, se tuvo un análisis de manera inmediata, de la re-ubicación de
productos, en base a los espacios con mayor rotación, de colocar nuevos
productos sabiendo su comportamiento en base a registros históricos de cada
espacio en la sala.

Hoy en día la información se maneja de una forma rápida y confiable, por lo

cual tener herramientas que ofrezcan estas dos cualidades se hacen más
indispensables, es por esto que los sistemas web son cada día más necesarios
para empresarios, comerciantes y para el público en general.

4
1.3 DESCRIPCIÓN DEL OBJETO DE ESTUDIO

El objeto de estudio en el presente proyecto de desarrollo de la aplicación

mencionada anteriormente es el negocio que provee un servicio orientada a
ofrecer variedad de productos, brindándoles a sus clientes mayores opciones
de compra, descuentos y servicio las 24 horas del día. Ofreciendo a la comuna
un estilo diferente y único de atención a las personas.

La aplicación será realizada para poder eliminar la necesidad de tener un lugar

físico para el desarrollo de un negocio y así poder brindar una plataforma para
los clientes con todas las comodidades que puede ofrecer un servicio virtual.

5
1.4 PLANTEAMIENTO DEL PROBLEMA

1.4.1 Problema Principal

En la actualidad tanto los Medianos y Pequeños negocios el problema que

tienen es la necesidad de cumplir las necesidades que tienen los clientes, para
ello es usualmente que tengan un lugar físico en donde puedan efectuar sus
actividades.

Para el negocio del cliente, este ha sido su mayor problema, ya que al momento
no cuenta con un lugar en donde vender sus productos para cubrir las
necesidades del cliente interno y externo.

Los pedidos de las personas son tomados vía telefónica, por tanto el cliente no
tiene la oportunidad de ver los productos solicitados, de allí nace la
inconformidad por el servicio prestado, lo cual perjudica el nivel de atención al
usuario, evitando un crecimiento del negocio.

6
1.4.2 FORMULACIÓN DEL PROBLEMA.

¿Cómo diseñar y desarrollar un servicio de ventas virtual que permita

visualizar, satisfacer el seguimiento y control de los pedidos realizados?

1.5 OBJETIVOS DE LA INVESTIGACIÓN

1.5.1 OBJETIVO GENERAL

Desarrollar una aplicación web para la venta productos, que permita visualizar
y manejar las transacciones de los mismos, por medio de una interfaz intuitiva,
para ayudar al crecimiento del negocio.

1.5.2 OBJETIVOS ESPECÍFICOS.

✓ Diseñar una base de datos práctica y segura para la consulta de

información.
✓ Diseñar un módulo para permitir al usuario adquirir los pedidos mediante un
proceso de registro.
✓ Recopilar información característica de los diversos productos que se tiene.
✓ Brindar los elementos necesarios para la satisfacción del cliente al
momento que realice la compra.

1.6 ALCANCES Y LIMITACIONES DEL PROBLEMA

ALCANCES

El negocio busca interactuar con el usuario brindándole servicios de consultas,

solicitudes, ventas y atención al cliente.

El sistema planteado pretende eliminar la necesidad de realizar compras

físicas, conservando la información de los clientes en una sola base de datos
y un módulo que permita al usuario la visualización de productos, novedades
y promociones, todos estos campos al tiempo y permita una atención oportuna.

7
Para poder ofrecer una ayuda al cliente al ingresar a nuestra web contaremos
con la ayuda de un chatbot que brinde la información necesaria. Este sistema
no esta planeado para el registro de varios de los elementos de una tienda,
sino para la de una plataforma virtual donde el cliente podrá adquirir los
productos sin la necesidad de una interacción física.

LIMITACIONES

El sistema será manipulado por el encargado de la tienda o alguien designado

por el dueño de la tienda y exclusivamente por la persona encargada de la
gestión telefónica.

Para el cliente será opcional el tener que registrar un usuario y contraseña para
su suscripción, ya que este no es requisito indispensable.

El ingreso de datos por parte del usuario, al momento de realizar su pedido,

deberá ser concreto y completo, de lo contrario será rechazada su petición.

8
9
CAPÍTULO 2: MARCO TEÓRICO

2.1 METODOLOGÍA

Metodología Scrum
Se usa Scrum para la dirección del desarrollo de productos complejos (como
es el caso de una Tienda Virtual), varios procesos que ayudaran a realizar el
proyecto acerca de una Tienda Virtual dichos procesos serán aplicados con las
técnicas que garantizan que esto ocurra. La estructura está compuesta de
Equipos Scrum que llevan a cabo una serie de funciones (que ayudaran a
desarrollar el sitio Web), tienen diferentes utensilios y eventos y siguen una
serie de reglas. Cada parte de la estructura tiene un propósito.

Scrum busca las acciones que se utilizara para realizar la tienda virtual sucesos
de la forma más óptima y controlar el riesgo utilizando un método Iterativo e
Incremental para ver el progreso que se tiene con el sitio Web y la asistencia
del Chatbot. Para que esto suceda, hay tres pilares que se deben
implementar.Estos son la Transparencia, la Inspección y la Adaptación.

Transparencia

Hay partes de este proceso que necesitan ser visibles para aquellos responsables
de los resultados al momento de probar si efectivamente funciona las compras
mediante la página si se puede acceder a los servicios que brinda. Esto requiere
definiciones estándar de todos los aspectos para asegurarse de que hay un
entendimiento común de todas las observaciones. Considera estos ejemplos:

• Todos los participantes en el proceso deben usar un lenguaje común.

• Tanto aquellos que llevan a cabo el trabajo, como los que aceptan el resultado,
deben tener una definición estándar de “Finalizado”.

Inspección

Si Scrum necesitan inspeccionar periódicamente los instrumentos para desarrolar

el sitio web, Chatbot y el progreso del avance del sitio web en el Sprint. Esto
asegura que puedan detectar variaciones no deseadas a tiempo. Las inspecciones

10
deben llevarse a cabo de vez en cuando, de manera que no se interrumpa el avance
en progreso.

Adaptación

Después de una inspección, puede revelarse que uno o más aspectos del proceso
se ha desviado de los límites aceptables. Esto significa que el producto final podría
no ser aceptable y que es necesario hacer algún ajuste en el proceso o el material
que se está usando. Cuanto antes ocurra, mejor, de manera que se eviten más
desviaciones.

Equipo Scrum
Tres miembros componen el Equipo Scrum básico, y son el Product
Owner(responsable de la página o el proyecto a desarrollar), el Equipo de
Desarrollo (desarrollo del sitio web y el Chatbot) y el Scrum Master(líder del
proyecto).
El Product Owner
Se trata de maximizar el valor del sitio web y el trabajo del Equipo de Desarrollo, es
el Product Owner el responsable de ello. Esto varía según los Equipos Scrum y las
personas del equipo. El Product Owner tiene la responsabilidad de gestionar el
Backlog del Producto. Esta gestión incluye:
✓ Expresar claramente los elementos a desarrolar del sitio web.
✓ Ordenar los elementos del Backlog de Producto para alcanzar el desarrollo
y los objetivos a realizar del sitio web.
✓ Optimizar el valor del sitio web que realiza el Equipo de Desarrollo.
✓ Asegurar que el Backlog del sitio web es visible, transparente y claro.

El Equipo de Desarrollo
Equipo formado por profesionales que trabajan para entregar un Incremento de
producto “Finalizado” que se pueda lanzar al final de cada Sprint. Solo los miembros
de este equipo pueden crear el Incremento (avances referentes al sitio web).

La organización asegura que el Equipo de Desarrollo está empoderado para

organizar y gestionar el proyecto. La sinergia que ocurre, como resultado,

11
optimizará la eficiencia y efectividad del Equipo de Desarrollo. Estos equipos tienen
las siguientes características:

✓ Se auto-organizan. No reciben instrucciones ni consejo de nadie sobre cómo

convertir el Backlog de Producto en Incrementos de funcionalidades
potencialmente liberables.

✓ Son multifuncionales y tienen todas las habilidades necesarias para crear un

Incremento de producto.

✓ Todo el mundo es desarrollador, sin importar el trabajo que desempeñen.

Esto se aplica sin excepciones todos contribuyen en el avance del sitio web
para que pueda cumplir las metas que se desea alcanzar.

✓ Dentro del Equipo de Desarrollo, el Scrum reconoce que no hay sub-equipos.

Esto ocurre incluso cuando hay muchos dominios que tienen que ser
tratados, como el análisis de ventas que proporcionara el sitio web. Esto se
aplica sin excepciones.

✓ Cada miembro del Equipo de Desarrollo podría tener una habilidad o zona
de confort especial, pero si hablamos de responsabilidades, se considera al
equipo como un todo.

El Scrum Master
El Scrum Master responsable de asegurar que se ha entendido y aprobado el
método que se esta utilizando para alcanzar las acciones que debe realizar el sitio
de ventas. Trabajan con el Equipo Scrum, por lo que pueden adherirse a la teoría,
prácticas y reglas de Scrum. El Scrum Master es esencialmente el líder-ayudante
del Equipo Scrum.

Hay tres grupos de Servicio del Scrum Master, y estos incluyen:

El Servicio del Scrum Master para el Product Owner

Esto se hace de numerosas maneras, incluyendo:

12
• Encontrar técnicas para gestionar de manera efectiva el Backlog de Producto

• Ayudar al Equipo Scrum a entender la necesidad de tener elementos claros y

concisos en el backlog de Producto

• Comprensión del planteamiento de producto en un ambiente empírico

• Asegurar que el Product Owner conoce la mejor manera de organizar el backlog

de Producto para maximizar el valor

• Comprensión y práctica de la agilidad.

• Facilitar eventos de Scrum según se requiera.

Eventos de Scrum: Inspección y Eventos de Adaptación

Son normalmente eventos programados. Normalmente regulan y minimiza la
necesidad de llevar a cabo reuniones no planeadas para saber el avance que se
tiene sobre el desarrollo de la base de datos y la pagina. Todos estos eventos son
de tiempo limitado, lo que significa que tienen una duración máxima.

En el momento que un evento, como un Sprint, comienza, tiene una duración fija
que no puede cambiarse. Una vez que se cumplen los reportes que se tiene acerca
de la página como tal, todos los eventos restantes pueden finalizarse. Esto asegura
que se gasta el mínimo tiempo posible en el proceso.

Cada evento da la oportunidad de inspeccionar o adaptar algo y ha sido diseñado

para permitir una transparencia radical. Hay cuatro eventos formales programados
que son:

✓ Planificación del Sprint

✓ Scrum Diario

✓ Revisión del Sprint

✓ Retrospectiva del Sprint

13
Entendiendo el Sprint
Se puede definir como un periodo de tiempo de un mes o menos en el que se
crea el sitio, utilizable y “Finalizado”. Normalmente tienen una duración
consistente durante un periodo de desarrollo. Los Sprint deberían tener
duraciones constantes durante todo el desarrollo. Un nuevo Sprint comienza
solo cuando el anterior ha finalizado.

Es seguro considerar cada Sprint como la duración del proyecto de un mes en el

que se ha de conseguir que funcione. Por esta razón, en el Sprint se define
claramente qué se va a construir, diseñar, un plan para la producción, el trabajo y
el producto final. Si el Sprint durara más de un mes, la definición de lo que se va a
crear cambiaría, y el riesgo podría subir junto a la complejidad general. Los Sprints
son importantes ya que aseguran que el trabajo es predecible y puede ser
inspeccionado y adaptado mientras se trabaja por el objetivo del Sprint. Limitan el
riesgo, particularmente si nos fijamos en el coste.

Es posible cancelar un Sprint antes de que finalice. Sin embargo, la única persona
que puede hacer esto es el Product Owner. La decisión puede estar influenciada
por otros, incluyendo las partes interesadas, el Equipo de Desarrollo o el Scrum
Master. Una cancelación puede hacerse efectiva cuando el Objetivo del Sprint se
vuelve obsoleto.
La obsolescencia puede estar causada por el azar en la dirección, las condiciones
del mercado o las condiciones de la tecnología. Si el Sprint deja de tener sentido,
debería ser cancelado. Sin embargo, verás que raramente se cancela un Sprint, ya
que tienen una duración bastante corta.

Planificación del Sprint

Cualquier trabajo que va a hacerse en el Sprint se planea en la Planificación del
Sprint. La planificación une al Equipo Scrum y se crea mediante un trabajo
colaborativo. La planificación del Sprint tiene una duración concreta de ocho horas
como máximo para un Sprint de un mes; aquí puedes encontrar sugerencias sobre
cómo llevar a cabo una efectiva planificación del sprint.
Cuando el Sprint dura menos, también el evento tiene a ser más corto. Depende
del Scrum Master asegurar que el evento tiene lugar y que los asistentes entienden

14
la razón del mismo. El Scrum Master enseñará al equipo a mantenerse en la
duración establecida.
En la Planificación se responden las preguntas sobre qué se puede liberar en el
Incremento del siguiente Sprint, y cómo se conseguirá realizar el trabajo que se va
a liberar.

¿Cómo se logrará el trabajo?

Una vez establecido el Objetivo del Sprint y que los elementos de Backlog de
Producto se han seleccionado, entonces el Equipo de Desarrollo decidido
cómo se construirá la funcionalidad para conseguir un Incremento del sitio
web“Finalizado” durante el Sprint. Los elementos del Backlog de Producto
elegidos para este Sprint, junto al plan para liberarlos.

El Equipo de Desarrollo diseñará un sistema para convertir el Backlog de

Producto en un Incremento de producto funcional. La carga de trabajo puede
variar según el esfuerzo necesario y el tamaño del trabajo. Durante la
Planificación del Sprint, el Equipo de Desarrollo pronosticará qué piensan que
se puede conseguir en el siguiente Sprint.

Al final de la reunión, el trabajo planeado para los primeros días del Sprint, que
debe realizar el Equipo de Desarrollo, se descompone en unidades diarias (o
menos). La auto-organización tiene lugar a la hora de realizar el trabajo del
Backlog del Sprint, tanto durante la Planificación del Sprint como cuando sea
requerido en el Sprint.

El Product Owner tiene la tarea de ayudar a aclarar los elementos del Backlog
de Producto elegidos e intercambiarlos cuando sea necesario. Si el Equipo de
Desarrollo decidiera que es mucho o poco trabajo, entonces debería ser
renegociado basándose en los elementos del Backlog de Producto.

Esto se hace junto al Product Owner. El Equipo de Desarrollo tiene también la

libertad de invitar a otros a asistir en beneficio del dominio o para dar consejos
técnicos. Al final de la Planificación del Sprint, el Equipo de Desarrollo debería
tener la capacidad de explicar al Product Owner y al Scrum Master cómo se

15
 realizará el trabajo trabajando como un equipo auto-organizado para alcanzar
el Objetivo del Sprint.

Objetivo del Sprint

Es un objetivo que se pone en el Sprint para poder alcanzar la meta que el sitio web
de la funcionalidad en totalidad, que se consigue con facilidad una vez que se ha
implementado el Backlog de Producto. Actúa, de alguna manera, como una guía al
Equipo de Desarrollo sobre la razón por la que se crea el Incremento. El Objetivo
del Sprint se establece en la reunión de Planificación del Sprint.

Se asegura que el Equipo de Desarrollo tiene un nivel de flexibilidad, en

relación a la funcionalidad implementada en el Sprint. El Objetivo del Sprint se
entrega a través de los Elementos del Backlog del Producto y asegura que el
Equipo de Desarrollo puede trabajar conjuntamente, en lugar de dividirse en
diferentes iniciativas.

Scrum Diario
Cada día, el Equipo de Desarrollo deja 15 minutos para sincronizar sus actividades
y desarrollar un plan para las siguientes 24 horas. Esto se conoce como el Scrum
Diario. Incluye una inspección del trabajo que se ha hecho desde el anterior Scrum
Diario y posteriormente se enfatiza sobre el trabajo que ha de realizarse antes del
siguiente.

Es esencial que la hora y el lugar del Scrum Diario sean siempre iguales, ya que
esto evitará cualquier complejidad. En la reunión, el Equipo de Desarrollo se
centrará en:

• Qué se hizo el día anterior que ayudó a alcanzar el Objetivo del Sprint

• Qué se ha hecho hoy para ayudar a alcanzar el Objetivo del Sprint

• Qué impedimentos pueden poner trabas a la consecución del Objetivo del

Sprint

16
Esto significa que el Scrum Diario es como una manera de chequear el grado de
consecución del Objetivo del Sprint. Asegura que el trabajo se basa en el Backlog
del Sprint y facilita la tarea de alcanzar el objetivo. Se desafía al Equipo de
Desarrollo durante el Scrum Diario a trabajar conjuntamente como un equipo auto-
organizado a través de discusiones detalladas, en las cuales puede que tengan que
adaptar o repetir el trabajo del resto del Sprint.

Es el Scrum Master quien asegura que esta reunión se realiza a diario, aunque está
dirigida por el Equipo de Desarrollo. Los Scrum Mastersaseguran que el equipo no
se sobresale de los 15 minutos, y hacen cumplir las reglas de participación.
Los beneficios del Scrum Diario son numerosos, incluyendo la mejora en la
comunicación, la no necesidad de otras reuniones, la identificación de trabas al
desarrollo, la rápida toma de decisiones y el aumento del conocimiento general del
Equipo de Desarrollo. Hace un tiempo escribí un artículo sobre “Cómo llevar a cabo
un Scrum Diario efectivo”, al que puedes echar un vistazo.
Revisión del Sprint
La Revisión del Sprint se lleva a cabo una vez que el Sprint ha finalizado. En ella,
se inspecciona el Incremento y se adapta el Backlog de Producto si fuera necesario.
Cuando la Revisión del Sprint tiene lugar, el Equipo Scrum y las partes interesadas
evalúan qué se ha hecho durante el Sprint.

El resultado de la discusión podría llevar a adoptar cambios en el backlog de

Producto, así como a la revisión de lo que podría ser optimizado con el objetivo de
añadir valor. La revisión sirve para compartir información y no es una reunión sobre
el estado del proyecto. Solo se mantiene para conseguir algo de feedback y para
asegurar que existe colaboración. Duraría unas cuatro horas si el Sprint fuera de
un mes. Si el Sprint fuera más corto, también lo sería la reunión.

Incluye los siguientes elementos:

• Asistencia del Equipo Scrum y de las partes interesadas, invitados por

el Product Owner

• El Product Owner explica qué elementos del Backlog de Producto están

“Finalizados” y cuáles no.

17
• El Equipo de Desarrollo explica qué funcionó durante el Sprint y qué no
funcionó, y cómo se solventaron los problemas

• El Equipo de Desarrollo revela qué se ha “Finalizado” y propone preguntas

sobre el Incremento

• El Product Owner habla sobre el estado del Backlog de Producto y posibles

fechas de finalización de los proyectos
• El grupo al completo colabora en los siguientes pasos, de manera que la
Revisión del Sprint proporciona información valiosa para la Planificación de
próximos Sprints

• Revisar el mercado o el posible uso del producto, cualquier cambio, y lo mejor

para hacer a continuación

• Revisar el cronograma, el presupuesto, las capacidades y el mercado para el

lanzamiento del producto

Después de la Revisión del Sprint, el Backlog de Producto se suele revisar, y se

definen los elementos del Backlog de Producto que se utilizarán probablemente en
el siguiente Sprint. Puede que se hagan ajustes generales para encontrar nuevas
oportunidades.

Retrospectiva del Sprint

Es una oportunidad para el Equipo Scrum de realizar una inspección sobre lo que
se ha realizado y desarrollar un plan para conseguir mejoras en el siguiente Sprint.
Ocurre una vez que la Revisión del Sprint se ha finalizado, antes de que la
Planificación del Sprint vuelva a comenzar.

Es una reunión con una duración concreta de unas tres horas para Sprints de un
mes. Sprints más cortos darán lugar a reuniones más cortas. El Scrum Master se
asegurará de que la reunión tiene lugar y los asistentes entienden claramente su
propósito.

18
El Scrum Master participará como un miembro del equipo para proporcionar
información sobre las responsabilidades en el proceso Scrum. El objetivo de esta
reunión es:

• Inspeccionar el último Sprint

• Identificar y ordenar lo que funcionó y lo que necesita ser mejorado

• Desarrollar un plan para implementar mejoras al Equipo Scrum y la manera en

que trabajan

El Scrum Master usará esta reunión para animar al Equipo Scrum a mejorar en las
prácticas y procesos del desarrollo. Esto asegurará que el siguiente Sprint sea más
efectivo y disfrutable. Se implementan los planes para elevar la calidad del
producto, estableciendo una definición apropiada de producto “Finalizado”.
Una vez que se ha completado la Retrospectiva del Sprint, el Equipo Scrum habrá
identificado qué se puede mejorar en el siguiente Sprint. Se adoptarán estas
mejoras y serán inspeccionadas por el propio Equipo Scrum. La Retrospectiva del
Sprint es una oportunidad formal de centrarse en la inspección y la adaptación.

Si te interesa este tema, puedes echar un vistazo a mi otro artículo: “La Guía Sobre
Las Retrospectivas Ágiles Que Te Convertirá En Un Magnífico Facilitador”. Mi
amigo Marc Loeffler escribió este artículo: “Las cinco preguntas más comunes
sobre las Retrospectivas Ágiles”. Y, por supuesto, si buscas nuevas ideas para tu
Retrospectiva del Sprint, echa un vistazo a: “Ideas sobre las Retrospectivas Ágiles”.
Elementos de Scrum
Representan el trabaj o valor para proporcionar transparencia, así como
oportunidades para la inspección y la adaptación. Se definen como
específicamente diseñadas para maximizar la transparencia sobre la información
clave, de manera que todos tienen el mismo conocimiento del elemento en
cuestión.

19
El Backlog de Producto

Esto se refiere a una lista ordenada de todas las cosas que se requieren para
desarrollar un producto. Contiene todos los requisitos para cualquier corrección que
se tenga que hacer a un producto; el responsable de ello es el Product Owner.

Es un trabajo en progreso (WIP), y no llega a tener nunca una versión final.

Establece los requisitos y evoluciona a la vez que el producto. Sufre cambios
basándose en qué es más conveniente, útil y competitivo para el producto y existirá
mientras que exista el producto.

Contiene una lista de todas las funciones, requisitos, características, mejoras y

arreglos, que constituyen los cambios que tienen que realizarse al producto en la
siguiente release. Los elementos del Backlog del Producto tienen una descripción,
orden, estimación y valor.
Cuanto más se use el producto, y obtenga valor, más feedback puede esperarse
del mercado. Esto resultará en el crecimiento del Backlog del Producto, al mismo
tiempo que los requisitos evolucionan. También puede sufrir cambios basados en
los requisitos de negocio, condiciones del mercado y la tecnología.

Donde hay muchos Equipos Scrum, puede que necesiten trabajar juntos en un
producto. En Este caso, solo un Backlog de Producto será utilizado para describir
el producto. Para refinar el Backlog del producto, los detalles, las estimaciones y el
orden de los elementos podrían ser modificados.

Esto lo realizan mediante la colaboración el Product Owner y el Equipo de

Desarrollo. Mientras se refina, también se revisan los elementos que se quedan
dentro. Es el Equipo Scrum quien decide cómo se realizará el perfeccionamiento,
de manera que no se coja más del 10% de la capacidad del Equipo de Desarrollo.
El Product Owner tiene la capacidad de actualizar los elementos del Backlog del
Producto en cualquier momento.
Hay elementos del Backlog del Producto ordenados más arriba y otros más abajo,
siendo los que están más arriba los más aclarados y detallados. Son los que están
arriba los elementos que pueden ser “Finalizados” por el Equipo de Desarrollo, y

20
pueden ser considerados como “Listos” para la selección en la Planificación del
Sprint.

El Equipo de Desarrollo es responsable de todas las estimaciones, ya que son los

que van a realizar el trabajo.

Monitorizar el Progeso de Cara a Conseguir un Objetivo

Es posible calcular la cantidad de trabajo necesaria para alcanzar un objetivo.

Durante la Revisión del Sprint, el Product Owner establecerá cuánto trabajo queda
por hacer. Se realiza una comparación entre el trabajo sobrante de Revisiones de
Sprint pasadas y el progreso necesario para completar el Sprint actual en el tiempo
que se ha establecido. Esta información se comparte después con todas las partes
que están involucradas.

Para pronosticar el progreso, se utilizan gráficos burn-up y burn down y diagramas

de flujo acumulado. Allá donde existe un ambiente complejo, el resultado podría ser
desconocido, de manera que solo lo que ha ocurrido en el pasado sería tomado en
cuenta a la hora de tomar decisiones.

Backlog del Sprint

Se conoce a los elementos del Backlog de Producto que se han seleccionado para
el Sprint como el Backlog del Sprint. Incluyen también el plan para entregar el
Incremento del Producto y alcanzar el Objetivo del Sprint. Fundamentalmente, el
Backlog del Sprint es un pronóstico del Equipo de Desarrollo que se centra en saber
cuán funcional será cada Incremento, así como el trabajo que es necesario para
convertir la funcionalidad en un Incremento “Finalizado”.

El Backlog del Sprint asegura que todo el trabajo realizado por el Equipo de
Desarrollo es visible y que se puede alcanzar el Objetivo del Sprint. El Backlog del
Sprint es esencialmente un plan que contiene el detalle necesario para que en el
Scrum Diario se comprendan los cambios realizados.

El Equipo de Desarrollo puede modificar el Backlog del Sprint durante todo el Sprint
y después surgir durante el Sprint, mientras que el Equipo de Desarrollo trabaja en

21
el plan. Esto se debe a que se aprende más sobre el trabajo necesario para
alcanzar el Objetivo del Sprint.

Si existe la necesidad de finalizar el trabajo, el Equipo de Desarrollo lo añade al

Backlog del Sprint. Mientras se completa, el trabajo restante se actualiza. Por el
camino, se elimina cualquier elemento del plan que no sea necesario.

Solo el Equipo de Desarrollo puede cambiar el Backlog del Producto en el curso de

un Sprint. El Backlog del Sprint es como una huella visible para el Equipo de
Desarrollo y pertenece solamente a este equipo.

Monitorizar el Progreso del Sprint

Durante el Sprint, se puede resumir el Backlog del Sprint en cualquier comento.
Depende del Equipo de Desarrollo el monitorizar en cada Scrum Diario el trabajo
restante para alcanzar el Objetivo del Sprint. Monitorizarlo le permite al Equipo de
Desarrollo gestionar el progreso del proyecto.

Incremento

Se puede resumir todo el trabajo que resta del Backlog del Sprint en cualquier
momento. El Incremento es la suma de esto y del valor de cualquier otro Incremento
de Sprints previos. El incremento final al terminar el Sprint debería estar
“Finalizando”, que significa que está en una condición utilizable y cumple con la
definición establecida por el Equipo Scrum. La condición utilizable es indispensable,
sea cual sea la decisión del Product Owner de lanzarlo o no.
Transparencia en los Elementos
Para que el método Scrum sea como es, la transparencia es esencial. Es la base
de las decisiones que se toman para optimizar el valor y el control del riesgo. El
grado de cumplimiento de la transparencia determina si las decisiones son
correctas o no. Si los elementos no son completamente transparentes, entonces
las decisiones tienen defectos y su valor disminuye. Además, el riesgo aumentará.
El Scrum Master debe trabajar con todas las partes participantes, incluyendo el
Product Owner y el Equipo de Desarrollo, para asegurar que los elementos son
totalmente transparentes. En el caso de que no exista una fuerte transparencia, hay
prácticas para salir adelante.

22
El Scrum Master debe a ayudar a todos a aplicar las prácticas más apropiadas para
conseguir una buena transparencia. Un Scrum Master puede detectar una
transparencia incompleta mediante la inspección de los elementos, el razonamiento
sobre los patrones y la observación cuidadosa de toda la información disponible.

Desde aquí, se pueden detectar las diferencias entre los resultados reales y los
esperados. El Scrum Master ha de trabajar con el Equipo Scrum y la organización
para aumentar la transparencia de los elementos. Esto se consigue mediante el
aprendizaje, el convencimiento y los cambios, y requiere un largo camino.
Definición de “Finalizado”
El término “Finalizado” ha aparecido bastantes veces en este texto. Cuando se dice
que un elemento del backlog del Producto o un Incremento está “Finalizado”, es
muy importante que todas las partes involucradas entiendan el significado.

Está directamente relacionado con completar el trabajo y asegura que existe

transparencia. Para el Equipo Scrum, “Finalizado” significa que el trabajo está
completado en el Incremento del producto. Hace un tiempo, escribí un ejemplo de
una “Checklist de la Definición de Finalizado”. Es esta la definición que servirá como
guía para el Equipo de Desarrollo en el número de elementos del Backlog del
Producto que deberían seleccionarse durante la Planificación del Sprint. La razón
de existencia de cada Sprint es entregar Incrementos de funcionalidades
potencialmente liberables que cumplan con la definición de “Finalizado” del Equipo
Scrum.
Con cada Sprint, el Equipo de Desarrollo debería entregar un Incremento de
funcionalidades del producto. Es utilizable y un Product Owner podría decidir
lanzarlo inmediatamente. En el evento en el cual la definición de “Finalizado” para
un Incremento es parte de las costumbres o estándares de la organización de
desarrollo, entonces todos los Equipos Scrum deben seguirla.
En el evento en el cual la definición de “Finalizado” no es un estándar de la
organización de desarrollo, entonces se pide al Equipo de Desarrollo del Equipo
Scrum traer una definición de “Finalizado” que vaya en la línea del producto. Allí
donde hay muchos Equipos Scrum trabajando en el lanzamiento del producto, los
Equipos de Desarrollo de todos ellos deben definir mutuamente el término
“Finalizado”.

23
Cada Incremento es acumulable a los Incrementos anteriores y se prueba
minuciosamente. Esto asegura que todos trabajan conjuntamente.

A la vez que los Equipos Scrum maduran, sus definiciones de “Finalizado” se

expanden para incluir más criterios. Aquí presento algunas sugerencias para
empezar con este acercamiento. Todos los sistemas y productos necesitan una
definición de “Finalizado”, que es el estándar que se aplica al trabajo realizado en
ellos.

24
Capítulo 3: Análisis de factibilidad

3.1 Factibilidad Operacional

Las expectativas depositadas por los usuarios se centran en un sistema de

gran viabilidad que se adecuen a sus necesidades y satisfaga de forma fácil la
manipulación del sistema. Convirtiéndolo de esta manera en un método
innovador que cumple de forma eficiente con las especificaciones dadas.

De acuerdo con lo ya mencionado se requieren los siguientes requerimientos:

El sistema debe contar con una BD confiable con respecto a la información de

los usuarios y los productos

Debe permitir la inscripción de nuevos usuarios para poder adquirir los

productos Debe tener la capacidad de permitir al administrador actualizar la
información de la base de datos.

Contar con el servicio de chatbot para despejar dudas, inquietudes o recibir

opiniones de los clientes.

PERSONAL PERFIL CONOCIMIENTO horas de

S MINIMOS capacitacio
n
GENERENTE DUEÑO operador de 5 horas
GENERAL computadoras
COMPRADORE CLIENTE operador de
S computadoras
EMPLEADO Encargad operador de 6 horas
o de la computadoras
pagina

25
3.2 Factibilidad Técnica

Partiendo del concepto que es un sistema web se determina el uso específico

del software como la mejor tecnología para satisfacer las especificaciones del
proyecto plenamente y no de forma ineficiente. Aunque también se necesita de
hardware para poner en funcionamiento el software con el contamos a
continuación se detallara los elementos a usar.

3.2.1 Hardware disponible para el desarrollo

El hardware con el que cuenta actualmente el equipo de desarrollo es el
siguiente:

EQUIPO COMPONENTES CAPACIDAD

Laptop Ram 16 GB
1 Disco Duro 2 TB
Mouse/Teclado SI
Procesador Intel core i7
DVD-ROM SI
Laptop Ram 8 GB
2 Disco Duro 1 TB
Mouse/Teclado SI
Procesador AMD
DVD-ROM NO
Servidor Ram 2 GB
Disco Duro 100 GB
Procesador DUAL
CORE
Monitor SI
Mouse/Teclado SI
DVD-ROM NO

3.2.2 Software para el desarrollo

Para el desarrollo del proyecto se hizo un estudio de diferentes herramientas
para crear una Tienda Online, donde se concluyó que la herramienta a utilizar
es Brackets con la cual solo uno de los miembros del equipo de desarrollo tiene

26
 experiencia, así que se necesitara capacitación para el resto del equipo. Por lo
tanto, se deberá estudiar e implementar durante el proyecto.

Se consideró también las siguientes herramientas para la creación de la página

web:

- Wix
- Adobe Dreamweaver
- Sublime text

3.2.3 Lenguaje de desarrollo

El lenguaje que se usara para el desarrollo del proyecto debe de poder:

- Soporte para una base de datos

- Ampliamente usado para el desarrollo web

Los lenguajes de desarrollo que cuentan con esas características son los
conocidos como:

Html5 es un lenguaje markup (de hecho, las siglas de HTML significan Hyper
Text Markup Language) usado para estructurar y presentar el contenido para
la web. Es uno de los aspectos fundamentales para el funcionamiento de los
sitios web.

PHP es un lenguaje de código abierto muy popular especialmente adecuado

para el desarrollo web y que puede ser incrustado en HTML.

CSS es un lenguaje que sirve para dotar de presentación y aspecto, de “estilo”,

a páginas web. CSS no es un lenguaje de programación. Podríamos decir que
es un lenguaje que suele aparecer relacionado o próximo a un lenguaje de
programación o que suele colaborar con un lenguaje de programación, pero no
es un lenguaje de programación propiamente dicho.

3.2.4 sistema gestor de base de datos

Este es un factor muy importante ya que determinara la manera en el que se

guarda la información, la velocidad de procesamiento, el respaldo de datos y
la seguridad.

27
El sistema gestor de nuestra base de datos debe ser estale, seguro, soporte
para grandes cantidades de información, conexión con diferentes lenguajes de
programación y con una comunidad activa para resolver diferentes dudas.

De acuerdo con las características presentadas el sistema gestor de base de

datos es MySQL, no solo por cumplir las características mencionadas, sino
también por la experiencia que se tiene con esta herramienta.

3.2.5 Sistema Operativo

Uno de los elementos para que todo nuestro software y la capacidad de nuestro
hardware funcionen es el sistema operativo, este debe contar con estabilidad,
velocidad, facilidad de uso, seguridad, y tener soporte para los distintos
programas que fueron mencionados en los puntos anteriores. Se cuenta con
sistemas operativos para los equipos de los desarrolladores y para el servidor
que se usara. Como lo son:

- Windows 10
- CentOS 7
- Ubuntu

3.3 Factibilidad Económica

Se refiere a los recursos económicos y financieros necesarios para desarrollar

o llevar a cabo las actividades o procesos y/o para obtener los recursos básicos
que deben considerarse son el costo del tiempo, el costo de la realización y el
costo de adquirir nuevos recursos.

Costos de Software

La mayoría de las herramientas de software a utilizar son de código abierto así

no presentaron ningún gasto para el proyecto.

Costo de Hardware

El equipo ya cuenta con el hardware necesario para el desarrollo.

Costos de Capacitación

Algunos miembros del equipo no están capacitados en los lenguajes y

herramientas para el desarrollo del proyecto así que el costo para la

28
capacitación es un estimado de 200 (BOB) por un tiempo aproximado de un
mes.

3.3.1 Estimación de costo del proyecto

Entre los distintos métodos de estimación de costes de desarrollo de software,
el modelo COCOMO desarrollado por Barry M. Boehm, se engloba en el grupo
de los modelos algorítmicos que tratan de establecer una relación matemática
la cual permite estimar el esfuerzo y tiempo requerido para desarrollar un
producto.

COCOMO define tres modos de tipos de proyecto.

Orgánico: proyectos relativamente sencillos, menores de 50 KDLC líneas de

código, en los cuales se tiene experiencia de proyectos similares y se
encuentran en entornos estables.

Semi-acoplado: proyectos intermedios en complejidad y tamaño (menores de

300 KDLC), donde la experiencia en este tipo de proyectos es variable, y las
restricciones intermedias.

Empotrado: proyectos bastantes complejos, en los que apenas se tiene

experiencia y se engloban en un entorno de gran innovación técnica. Además,
se trabaja con unos requisitos muy restrictivos y de gran volatilidad.

Por la naturaleza de este proyecto se opto por un desarrollo del tipo Orgánico.

Y por otro lado existen diferentes modelos que define COCOMO:

Modelo básico: Se basa exclusivamente en el tamaño expresado en LDC.

Modelo intermedio: Además del tamaño del programa incluye un conjunto de

medidas subjetivas llamadas conductores de costes.

Modelo avanzado: Incluye todo lo del modelo intermedio además del impacto
de cada conductor de coste en las distintas fases de desarrollo.

El modelo que se escogió es el Básico.

Las fórmulas para utilizarse serán las siguientes:

- E = Esfuerzo = a KLDC e * FAE (persona x mes)

- T = Tiempo de duración del desarrollo = c Esfuerzo d (meses)
- P= Personal = E/T (personas)

29
 Dónde:

E = Esfuerzo

KLDC = Kilo líneas de código

FAE = Personas por mes

T = Tiempo de duración de desarrollo

a, b, c, d Son constantes

Para calcular el Esfuerzo, necesitaremos hallar la variable KDLC (Kilo-líneas

de código), donde los PF son 261,36 y las líneas por cada PF equivalen a 32
según vemos en la tabla que se ilustra a continuación:

LENGUAJE LDC/PF

Ensamblador 320

C 160

COBOL 105

PASCAL 90

PROLOG/LISP 64

C++ 64

VISUAL BASIC 32

SQL 12

Como no se encuentra el lenguaje que se va a usar en el proyecto, se tuvo que

recurrir a una fuente externa.

Como el lenguaje que usamos es uno orientada a objetos nuestro LDC/PF es

30

Con ese dato procedemos a calcular el KLDC.

KLDC= (PF * Líneas de código por cada PF)/1000 = (261,36*30)/1000= 7,8408

KDLC

30
 Como se anticipó el tipo orgánico es el más apropiado para nuestro proyecto
ya que el numero de líneas de código no supera los 50 KLDC, por consiguiente,
los coeficientes que usaremos serán las siguientes:

PROYECTO SOFTWARE a e c d

ORGANICO 3,2 1,05 2,5 0,38

SEMI-ACOPLADO 3,0 1,12 2,5 0,35

EMPOTRADO 2,8 1,20 2,5 0,32

CONDUCTORES DE VALORACION
COSTE Muy Bajo Nominal Alto Muy Extr.
bajo Alto Alto
Fiabilidad requerida del 0.75 0.88 1.00 1.15 1.40
software
Tamaño de la base de 0.94 1.00 1.08 1.16
datos
Complejidad del producto 0.70 0.85 1.00 1.15 1.30 1.65
Restricciones del tiempo 1.00 1.11 1.30 1.65
de ejecución
Restricciones del 1.00 1.06 1.21 1.56
almacenamiento principal
Volatilidad de la máquina 0.87 1.00 1.15 1.30
virtual
Tiempo de respuesta del 0.87 1.00 1.07 1.15
ordenador
Capacidad del analista 1.46 1.19 1.00 0.86 0.71
Experiencia en la 1.29 1.13 1.00 0.91 0.82
aplicación

31
 Capacidad de los 1.42 1.17 1.00 0.86 0.70
programadores
Experiencia en SO 1.21 1.10 1.00 0.90
utilizado
Experiencia en el lenguaje 1.14 1.07 1.00 0.95
de programación
Prácticas de 1.24 1.10 1.00 0.91 0.82
programación modernas
Utilización de 1.24 1.10 1.00 0.91 0.83
herramientas software
Limitaciones de 1.23 1.08 1.00 1.04 1.10
planificación del proyecto

Para hallar la FAE, multiplicamos los valores evaluados en los diferentes 15

conductores de coste que se observan en la siguiente tabla:

FAE=
1.15*1.00*1.00*1.00*1.06*1,15*1,07*1.00*1.00*1.17*0.90*1.00*1.10*0.91*1.0
0

= 1.581057892

Cálculo del esfuerzo del desarrollo:

E= a KLDC e * FAE = 3,2 * (7,8408) ^1,05 * 1.5810= 43.97 personas /mes

E = 43.97

Cálculo tiempo de desarrollo:

T = c Esfuerzo d = 2,5 * (43.97) ^0,38 = 10.53meses

T= 10.53

32
Productividad:

PR = LDC/Esfuerzo = 8363/43.97 = 190.2 LDC/personas mes

PR = 190.2

Personal promedio:

P = E/T = 43.97/10.31 = 4.3 personas

P = 4.3

Por lo tanto se determina que para el desarrollo del sistema se requieren cuatro
personas para su programación pero solo contamos con 2.

33
CAPITULO 4: INGENIERÍA DE REQUERIMIENTOS

4.1 PLAN PARA LA DETERMINACION DE LOS REQUERIMEINTOS DEL

SOFTWARE

TAREA OBJETIVO ENTREGABLE FECHA

Concepción -Identificar las - Recopilación
razones por las que de información
se ha optado por un
- Descripción
sistema web para las
26/9/2019
del como se
ventas
encuentra
- identificar los Bolivia en cuanto
motivos del porque la a las compras
gente prefiere realizar online
sus compras en línea,
además de la
comodidades que
este necesita
Indagación -Identificar a las - Lista de actores
personas que van a
- Encuestas
interactuar de alguna
forma con el sistema
26/9/2019

-Identificar el rol de
los actores
Elaboración -Determinar los - tabla de 26/9/2019
requerimientos en requerimientos
base a lo que sugiere
- flujograma
el cliente

-Realizar diagramas
que ayuden a
comprender mejor
estos requerimientos

34
 Negociación -Organizar una - contrato o 26/9/2019
reunión para realizar compromiso de
la presentación de los aprobación
requerimientos pactado entre el
obtenidos a el cliente encargado del
para que este de su proyecto con el
observación y su cliente
aprobación
Especificación Especificar el -Especicacion 26/9/2019
funcionamiento de de
los requerimientos requerimienos

Concepción

Recopilación de información

La tendencia actual en Bolivia acerca de las compras en línea es que esta en

un crecimiento constante.
Lo que estamos viendo es que es un camino sin retorno, donde el consumidor
cada vez está obligando más a la oferta a resolver estos puntos de venta y
estos puntos de contacto a través de estas nuevas tecnologías, principalmente
la móvil. Lo que están haciendo los dispositivos móviles y el alcance que esta
teniendo el internet actualmente, por el empoderamiento, por cómo lo están
usando los usuarios, esos consumidores, que lo hacen ya casi nativamente, es
un tema de usabilidad, porque es sencillo y amigable la forma de comprar, lo
están incorporando.
Lo que estamos viendo es que en los próximos cinco años estos cambios van
a ser mucho más grandes mientras la oferta esté, que ese es el gran desafío
que tenemos a nivel latinoamericano. En México, Brasil, Argentina, Colombia,
Chile y Perú vemos como la oferta local está entendiendo que tiene que
enfrentar de forma profesional estos nuevos puntos de venta y nuevos puntos
de contacto porque el consumidor se los obliga y porque el consumidor está
comprando en sitios de afuera, cuando no hay oferta local.
Es una realidad en todos los países de Latinoamérica, incluido Bolivia. Y la
tendencia es que el internet va a ser el principal canal de compra. Todavía no
lo es porque hay un ciclo de maduración o de incorporación de al canal online
por parte del consumidor que llega un poco de tiempo, pero como cada vez
más empresas se está ofreciendo una experiencia de compra positiva a través
del internet, están ingresando con experiencias que van del delivery, el traslado
o la ‘uberización’ de la economía en sus distintos verticales que están haciendo
que la gente compre un pasaje, compre una entrada o una comida, y de

35
 repente le resulte normal comprar un televisor o una prenda de vestir a través
del mismo medio.
El desafío en Bolivia no es la demanda. El 58% de los Bolivianos está
conectado a internet. Entonces, busca por el dispositivo móvil, termina
comprando por el desktop, porque va haciendo esa omnicanalidad, mientras la
oferta esté. Lo que falta en Bolivia es oferta.
Vemos casos como Multicenter, Totto, Mitsuba o BoA, por nombrar algunos de
los 30 casos, que demuestran que en Bolivia se puede hacer comercio
electrónico porque ellos están con números positivos. Todavía el retail
tradicional no se está atreviendo a enfrentar el desafío porque como no hay
oferta local no había competencia local, pero si hay competencia afuera y se
está viendo cada vez más sitios locales como TuMomo.com,
TuMercadazo.com que están facilitando lo complejo de forma sencilla. Lo
complejo es comprar de afuera y recibir una factura local, pero lo están
resolviendo. Y el consumidor está viendo una experiencia de compra positiva
y que eso funciona. Y el marketing boca a boca ayuda a difundir esa
experiencia.
Multicenter es un caso muy bueno para tomar, ellos ganaron el año pasado el
Ecommerce Awards Bolivia, en la categoría retail. Sus ventas online han
crecido apalancándose con las ventas offline, con las tiendas físicas. Por
ejemplo, ahora abrieron una sucursal en Sucre que es una tienda muy chica,
de 120 m2, comparado con las grandes salas de Multicenter. Allí exponen sus
principales productos, pero todo lo demás se puede comprar online y lo
entregan ese mismo día o al día siguiente. Ese tipo de modalidades son las
que tienen que aprovechar los retailers tradicionales, porque no quiere decir
que el boliviano va a ir 100% de primera online. Lo que va hacer es comprar
online y retirar offline. Va haber una omnicanalidad del consumidor.
Indagación

Encuesta
1 ¿Has realizado alguna compra en online?
2 ¿Consideras que es complicado realizar compras online?
3 ¿Qué productos has comprado online?
4 ¿Cuál sería la forma de pago que usarías en tu compra en línea?
5 ¿Qué tipo de promoción te atraería más para realizar tus compras online?
6 ¿Te sientes seguro comprando en línea?
7 ¿Qué producto te gustaría comprar en línea con la finalidad de ahorrar tiempo?
8 ¿Te gustaría que te enviáramos promociones para compras en línea?
9 ¿Qué tan satisfecho estas con la logística de las compras de productos fisicos?

36
Los actores que se representan en el sistema son tres y se especificarán a
continuación junto al perfil con el que ingresarán al sistema y las tareas que
realiza cada uno:
Actor Perfil Tareas
Administrador administrador -iniciar sesión
-gestionar
productos
-gestionar clientes
-gestionar
categorías
Empleado empleado -iniciar sesión
-ver producto
-añadir producto
-ver carro de
compra
-gestionar atención
al cliente
Visitante Usuario -registrar usuario
- ver información
- ver producto
- consultar
Cliente Usuario -iniciar sesión
-ver producto
-ver información
-ver carro de
compra
-consultar

37
Elaboración
Tabla de requerimientos funcionales
ID REQUERIMIENTOS DESCRIPCION
1 Creación de modulo de Debe tener un formulario de registro, para
registro de usuario el que el cliente pueda crearse una cuenta
en la Tienda Online. Este registro debe
ser intuitivo y rápido.

2 Creación Chatbot de Debe tener una sección de ayuda, que

Ayuda brindara la información necesaria para los
clientes.
3 Creación del módulo de En ek visor del producto podremos ver
visor del producto una foto de este además de una
descripción del producto, además, se
debe mostrar la cantidad disponible del
producto en la Tienda.
4 Crear vía de contacto Debe tener un formulario para que el
con el encargado cliente pueda comunicarse y enviar un
mensaje a la Tienda Online. Además, de
información de contacto (teléfono y correo
electrónico).
5 Crear módulo de Al seleccionar un producto debe permitir
descripción del ver la descripción del producto,
producto entregando información de las
características de éste, además, de
imágenes del producto y la Pyme que
ofrece el producto.
6 Creación de menú de Mostrar las promociones como imagen al
Promociones inicio de la Tienda Online.

7 Carrito de compras Debe proveer un carro de compra en el

cual se vaya guardando los productos que
se deseen comprar, para luego proceder
al pago de los mismos.
8 Creación de la base de Se debe realizar una base de datos para
datos del sistema almacenar los datos de los productos, así
con la información de nuestros usuarios

9 Creación de interfaz Crear un modulo para brindar al

administrador administrador para agregar, actualizar,
quitar algún producto

10 Creación de modulo de Debe presentar un modulo por el cual el

acceso al sistema usuario podrá entrar a su perfil para
realizar compras en la pagina

38
Especificación

El proyecto a realizar contara con las siguientes actividades:

Registro de usuarios
Logeo
Visualización de productos
Selección de categorías de producto
Carro de compra
ChatBot de asistencia
Y a continuación se realizará la especificación de cada una de las
actividades mencionadas anteriormente
Registro de usuarios: Las personas que visiten la pagina si están
interesados en adquirir algún producto podrán registrarse en la
pagina para conseguir un perfil de compras.
Logeo (inicio de sesion): El usuario registrado podrá ingresar a su
perfil de la pagina con su nombre de usuario y contraseña.
Carro de compra: El usuario una vez ya este en su interfaz, podrá
navegar por la pagina y realizar las compras de los productos que
le interese que serán agregados a su carro de compra que acumula
los precios y el nombre de estos productos.
Visualización de producto: Se podrá ver cada producto con una
imagen adjunta a este, para mejor interacción con la página además
del su costo y una breve descripción de este.
Selección de categoría de producto: En la página se tendrá la
posibilidad de listar los productos disponibles de acuerdo con una
categoría seleccionada,
Chatbot: Es un modulo que simula las atividades de un operador de
atención al cliente, se podra interactuar con este para recibir la
información acerca de los producto, información del encargado y
cualquier duda dentro de lo que pueda solucionar del cliente.

CAPITULO 5

39
METODOLOGIA SCRUM

FASE TAREA ENTREGABLES FECHA

VISION DEL DECRIPICION 26-9-19
PROYECTO
INICIACION
ROLES DEL TABLA ROLES 26-9-19
PROYECTO DE PROYECTOS
LISTA ENCUESTAS, 26-9-19
PRIORIZADA REUNION,
PRODUCT
BACKLOG
PLAN DE TABLA DE 26-9-19
LANZAMIENTO ENTREGAS
FECHAS
PLANIFICACION ELABORAR HISTORIAS DE
HISTORIAS DE USUARIO
USUARIO
APROBACION PRODUCT
DE PRODUCT BACKLOG
BACKLOG APROVADO
DISEÑO DEL DIAGRAMA DE
SISTEMAES CASOS DE USO
DE ALTO NIVEL

DIAGRAMA DE
CASOS DE USO
EXPANDIDO

ESTIMACION Y PRODUCT
ASIGNACION DE BACKLOG CON
HISTORIAS DE TAREAS
USUARIO ASIGNADAS

40
 ELABORAR PARA LOS
TAREAS MIEMBROS DEL
LISTA DE PROYECTO
PENDIENTES

5.1 INICIACION

5.1.1 Visión del proyecto

Proveer un servicio competente para la venta de productos via web, brindando

la facilidad y seguridad a el usuario final para mejorar su experiencia haciendo
la compra de productos.
5.1.2 Roles de proyecto
Persona Rol Siglas
Cliente Product Owner PO
Estudiante 1 Scrum Master SM
Estudiante 2 Equipo Scrum ES

Scrum Máster: Se encargará de administrar el proceso del proyecto, su

planificación, coordinación con el equipo y realizar un seguimiento e informes del
progreso del proyecto, en términos de calidad, costo y plazos de entrega.

- Realiza la planificación todas las actividades generales del proyecto.

- Acepta o rechaza los resultados del trabajo del equipo.
- Responsable de promover los valores y normas de SCRUM.
- Remueve impedimentos.
- Se asegura de que el equipo es completamente funcional y productivo.
- Permite la estrecha cooperación en todos los roles y funciones.

Product Owner: Se encargará de crear la lista de funcionalidades del sistema,

planificar el inicio de cada sprint y la revisión del producto al término de cada sprint
para determinar si se cumplió con todas las funcionalidades.

Equipo: Las principales funciones son:

41
 - Comprometerse al inicio de cada sprint desarrollar todas las funcionalidades
en el tiempo determinado.
- Son responsables de entregar un producto a cada término del Sprint.
- Define como se desarrolla del sistema.5.2 Lista priorizada (ver capítulo 4)

5.2.1 Product Backlog

Id Requerimiento Prioridad Importancia

8 Creación de ALTA 100
base de datos
1 Creación de ALTA 99
modulo de
registro de
usuario
10 Creación de ALTA 98
módulo de
acceso al
sistema

9 Creación de ALTA 90
interfaz
administrador
3 Creación del ALTA 85
modulo de
visor de
producto
5 Crear módulo ALTA 80
de descripción
del producto
2 Creación de ALTA 70
chatbot de
ayuda

7 Carrito de MEDIA 60
compras

42
6 Creación de BAJA 40
menú de
promociones

4 Crear via de BAJA 30

contacto con el
encargado

DIAGRAMA DE ALTO NIVEL

DIAGRAMA EXPANDIDO DE REGISTRO DE PRODUCTOS

43
DIAGRAMA EXPANDIDO VENTAS

44