Está en la página 1de 55

IMPLEMENTACIÓN DE UN

SISTEMA WEB
Desarrollo de Software
Universidad Autónoma del Perú
54 pag.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
INFORME DE DESARROLLO DE SOFTWARE BASADO
EN FRAMEWORKS

PROYECTO ACADÉMICO:
 IMPLEMENTACIÓN DE UN SISTEMA WEB PARA EL
PROCESO DE PEDIDOS POR DELIVERY DE LA
PANADERÍA “LA UNIÓN”

Estudiantes:
Avila Satornicio Sebastián Jesús
Cruz Cueva Juan Efrain
Cuenca Saavedra Anthony Jefferson
Espinoza Cori Ronaldo
Gonzales Jaque Rosmel Santiago
Docente:
Dr.Petrlik Azabache Ivan

INGENIERÍA DE SIST EMAS

Diciembre 2020
Ciudad – Perú

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
INDICE
INTRODUCCIÓN.................................................................................................................................. 6
CAPITULO I: GENERALIDADES. ....................................................................................................... 7
1.1. Breve descripción general de la Empresa. ................................................................................ 7
1.2. Organización de la Empresa. ................................................................................................... 8
1.3. Describir el área y/o los procesos ............................................................................................. 9
1.4. Descripción de la Realidad Problemática ............................................................................... 10
1.4.1. General ....................................................................................................................... 10
1.4.2. Especifico ................................................................................................................... 11
1.4.3. Empresa ...................................................................................................................... 11
1.5. Propuesta de Solución ........................................................................................................... 12
CAPITULO II: PROYECTO ................................................................................................................ 13
2.1. Marco Metodológico ............................................................................................................. 13
2.1.1. Aplicativo Web ........................................................................................................... 13
2.1.2. Aplicativo Móvil ......................................................................................................... 13
2.1.3. Netbeans ..................................................................................................................... 14
2.1.4. Lenguaje PHP ............................................................................................................. 14
2.1.5. Framework Laravel ..................................................................................................... 14
2.1.6. Bootstrap..................................................................................................................... 15
2.1.7. Jquery ......................................................................................................................... 15
2.1.8. Css3 ............................................................................................................................ 15
2.1.9. Plantilla administrable de AdminLTE 3 ....................................................................... 16
2.1.10. Servidor MYSQL ........................................................................................................ 16
2.1.11. Servidor Apache .......................................................................................................... 16
2.1.11.1. JavaScript ............................................................................................................... 16
2.1.11.2. Flutter ..................................................................................................................... 17
2.1.11.3. Emulador de Android Studio ................................................................................... 17
2.2. Documentación del Software ................................................................................................. 18
2.2.1. Fundamentación Teórica.............................................................................................. 18
2.2.2. Desarrollo de la Metodología ....................................................................................... 21
2.2.2.1. SPRINT 1 ............................................................................................................... 21
2.2.2.1.1. Historias de Usuario 1 ......................................................................................... 21
2.2.2.1.2. Product Backlog 1............................................................................................... 24
2.2.2.1.3. Sprint Planning Meeting 1 ................................................................................... 26
2.2.2.1.3.1. Release Planning 1 ....................................................................................... 26
2.2.2.1.3.2. Daily Standup Meetings 1............................................................................. 26
2.2.2.1.4. Sprint Backlog 1 ................................................................................................. 27
2.2.2.1.5. Reunión Retrospectiva 1 ..................................................................................... 30
2.2.2.2. Sprint 2 ................................................................................................................... 31
2.2.2.2.1. Historias de Usuario 2 ......................................................................................... 31
2.2.2.2.2. Product Backlog 2............................................................................................... 34
2.2.2.2.3. Sprint Planning Meeting 2 ................................................................................... 36

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.2.2.3.1. Release Planning 2 ....................................................................................... 36
2.2.3.2.3.2. Daily Standup Meetings 2............................................................................. 36
2.2.3.2.4. Sprint Backlog 2 ................................................................................................. 37
2.2.3.2.5. Reunión Retrospectiva 2 ..................................................................................... 40
2.2.3.3. Sprint 3 ................................................................................................................... 41
2.2.3.3.1. Historias de Usuario 3 ......................................................................................... 41
2.2.3.3.2. Product Backlog 3............................................................................................... 43
2.2.3.3.3. Sprint Planning Meeting 3 ................................................................................... 45
2.2.3.3.3.1. Release Planning 3 ....................................................................................... 45
2.2.3.3.3.2. Daily Standup Meetings 3............................................................................. 45
2.2.3.3.4. Sprint Backlog 3 ................................................................................................. 46
2.2.3.3.5. Reunión Retrospectiva 3 ..................................................................................... 49
2.2.4. Modelos de Base de Datos ........................................................................................... 50
2.2.4.1. Modelo de Base Datos Físico................................................................................... 50
2.2.4.2. Modelo de Base Datos Lógico ............................................................................. 51
2.3. Conclusiones. ........................................................................................................................ 52
2.4. Sugerencias. .......................................................................................................................... 53
Referencias Bibliográficas. ................................................................................................................... 54

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
INDICE DE FIGURAS

Figura 1. Organigrama de la Panadería la “Unión” ........................................................ 8


Figura 2 Historias de Usuario ...................................................................................... 23
Figura 3. UML ............................................................................................................. 50
Figura 4. Modelo Físico .............................................................................................. 51
Figura 5. Modelo Lógico ............................................................................................. 52

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
INDICE DE TABLAS
Tabla 1. Tabla de Descripción de las Áreas de negocio................................................ 9
Tabla 2. Release Planning 1 ....................................................................................... 26
Tabla 3.Daily Standup Meetings 1 .............................................................................. 26
Tabla 4. Reunión Retrospectiva 1 ............................................................................... 30
Tabla 5. Reunión Retrospectiva 2 ............................................................................... 40
Tabla 6. Release Planning 3 ....................................................................................... 45
Tabla 7. Dally Standup Meetings 3 ............................................................................. 45
Tabla 8. Reunión Retrospectiva 3 ............................................................................... 49

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
INTRODUCCIÓN
Este documento describe el trabajo realizado en el proyecto final del curso de
Desarrollo de Software basado en Frameworks. El proyecto consiste en la
implementación de un Sistema Web para el proceso de Pedidos por Delivery
para la Panadería "La Unión" situado en el distrito de Villa el Salvador, que
permite al negocio evitar que no se genere grandes aglomeraciones en el local
optimizando mejor sus procesos de negocio. En la actualidad este negocio está
siendo afectado por el tema de la Pandemia, ya que a comienzos del Año tuvo
mucha perdida en su rentabilidad, donde el Jefe del negocio vio que no tiene un
sistema que automatice sus procesos del negocio que esto ayudaría a optimizar
mejor todos los proceso de cual aumentaría más sus ganancias para el negocio,
entonces nos solicitó resolver este problema que enfrentan mediante nuestras
técnicas aprendidas en nuestra Carrera de Ingeniería de Sistemas.
Para el desarrollo de este proyecto se trabajó bajo la metodología Scrum que fue
la metodología más adaptable para este trabajo ya que el Jefe General solicito
realizar reuniones diarias para gestionar los cumplimientos de los requerimientos
del Sistema. El objetivo de este sistema es dar una visión general de la panadería
y los servicios que dispone, así como también brindar una serie de
funcionalidades para sus clientes registrados en el sistema, a sus vendedores, a
sus repartidores y también al administrador de la panadería. La web debe ser
agradable y ser accesible desde cualquier navegador por Internet de la cual
mostrara a sus clientes el catálogo de productos que ofrece la panadería y por
parte del administrador es la gestión de catálogos, de productos y el control
pedidos de los clientes, el repartidor podrá gestionar el control de pedidos y el
vendedor podrá ver el catálogo de productos. La panadería al realizar este
sistema se podría beneficiar enormemente al contar con un sistema web
complejo y actualizado, esto ayudara a tener mayor alcance y presencia en el
mundo Virtual, mejorando sus ganancias y seguir presentes en el mercado
nacional durante la época de Pandemia, donde también se beneficiarían sus
clientes que se permitirá realizar los servicios que tiene la panadería y por parte
del Jefe General del negocio poder gestionar de manera de una manera más
compleja sus procesos.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
CAPITULO I: GENERALIDADES.
1.1. Breve descripción general de la Empresa.
La Panadería "la Unión" es una microempresa que se ubica en el Barrio 2 Sect.1
Parcela 3 Agrupamiento Pachacamac, Villa El Salvador. La panadería comenzó
como una tienda de barrio llamada la Tienda "la Unión", de la cual fue fundada
por la familia Hernández Solís en el año 2010, en esos momentos se encargaban
de vender productos nacionales de cual estaba a cargo el Señor Frank
Avendaño, era quien dueño y atendía toda la tienda ya que no contaba con
empleados para su negocio en ese momento por la falta de recursos pero, en el
año 2011 el Señor Frank se financio con el Banco de Crédito del Perú y realizo
un inversión en el negocio para ampliar la tienda y transformarla en una
panaderia-pasteleria. Abrió la panadería con 8 empleados y su giro empresarial
es el rubro de la alimentación (panaderia-pasteleria), donde se dedica a vender
variedades de panes, pasteles, kekes y otros productos de pastelería.

La panadería se está legalmente registrado como persona física bajo el régimen


de pequeño contribuyente. La representación legal como persona física lo tiene
el hijo, Elías Avendaño quien es el Jefe General de la Panadería y es quien
ahora lidera el negocio, administra y toma las decisiones dentro de la panadería

Actualmente la Panadería cuenta con 15 empleados por la temporada de


pandemia porque en temporada normal incrementa a 20 empleados, de la cual
brindan un servicio rápido y de calidad, donde también brindan el servicio de
Delivery por teléfono que es el valor agregado de este negocio a diferencia de
sus competidores locales de su zona. La empresa por pandemia está trabajando
todos los días con un horario de 5:00 am a 4:00pm. La panadería sigue
brindando sus servicios a sus clientes durante esta pandemia recuperándose de
las perdidas en su rentabilidad a comienzos del año, pero con el pasar del tiempo
y por los decretos otorgados por el estado, la panadería se ha ido reacomodando
en el mercado bajo ciertos protocolos que se deben cumplir para su
funcionamiento

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
1.2. Organización de la Empresa.
En este organigrama representaremos las cuatro áreas que existen actualmente
en el negocio, detallando cada jerarquía correspondiente a los cargos
establecidos en la Panadería la “Unión”.

Figura 1. Organigrama de la Panadería


la “Unión”

Fuente: Elaboración Propia

En la estructura observamos que tenemos el Jefe general en la parte superior y


en la parte inferior las sub áreas que tiene la empresa como área de distribución,
área de ventas, área de producción y área de finanzas.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
1.3. Describir el área y/o los procesos
En esta tabla detallaremos la descripción y los procesos que tiene cada área de
la Panadería
Tabla 1. Tabla de Descripción de las Áreas de negocio

AREAS DEL DESCRIPCIÓN


NEGOCIO
En esta Área está encargado por Alfredo Casariego
que es el Jefe de Distribución, es quien se encarga de
organizar la recepción de la materia prima,
almacenamiento y el control de envíos de los
productos de la panadería hacia sus clientes, para que
se envié de una manera correcta esta la supervisora
Área de Distribución que se encarga de supervisar el empaquetado de los
productos y por el ultimo están los repartidores que es
encarga del envió

En el Área de Ventas está encargado por Ismael


Avendaño es quien encarga de planificar el
presupuestos de las ventas, generando así las metas
y los objetivos dentro del área y también para cada
vendedor, el supervisor de esta área se encarga de
Área de Ventas mantener un control interno en sus trabajadores,
supervisando sus metas y objetivos y por ultimo están
los vendedores que se encargan de ofrecer los
productos de la panadería

En esta Área está encargada por el Jefe Sandro


Avendaño, ella es quien supervisa y se encarga del
Área de Finanzas flujo del dinero y de los activos que entran y salen de
la panadería, con la finalidad de logar cumplir las
normas legales establecidas, vela por la entrega de las
finanzas presupuestarias con el objetivo de ser
utilizadas para las tomas de decisiones dentro del
negocio, el asistente contable apoya al Jefe de

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Finanzas y realiza diferentes tareas administrativas ,
por ultimo están los cajeros que se encargan de
administrar y son responsables del conteo de las
ganancias y atención al cliente
La encargada de esta Área es la Jefa Alisson
Gutiérrez, ella responsable de dirigir, planificar y
coordinar las actividades pertenecientes a la
producción, gestionando todos los recursos
disponibles, desarrollando estrategias y
procedimientos optimos para entregar productos de
Área de Producción alta calidad, el supervisor se encarga del control de la
producción que realizan sus trabajadores, por ultimo
están los panaderos y los pasteleros que ellos son los
responsables que la creación de los productos finales
para sus clientes

Fuente: Elaboración Propia

1.4. Descripción de la Realidad Problemática

1.4.1. General
La Confederación Española de Panadería, Pastelería, Bollería y Afines
(CEOPPAN) pide crear una titulación de panaderos/pasteleros para que "haya
gente joven emergente que pueda entrar a trabajar a las panaderías", que
"necesitan mano de obra para sobrevivir"; y se dignifique ese ancestral oficio.
El mundo de la panadería no se libra del tema de la covid-19 y está con las
ventas bajas", según (Jiménez, 2020, pag.1), para quien, a nivel nacional, "hay
sitios que lo pasan peor que otros".
Se ha referido a que para estas zonas de España que dependen del turismo, "el
bache que han atravesado en Semana Santa y verano ha sido terrible y muchas
panaderías y pastelerías han tenido que cerrar después de muchos años porque
no han conseguido sobrevivir a esta incertidumbre de la covid-19", nos comenta

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
(Jiménez,2020,pag.1)que lo que se ha remarcado esta situación, no se puede
evitar que "muchas panaderías y tiendas de los pueblos cierren", pero "no hay
que olvidar que un pueblo, sin una panadería y un bar, no es un pueblo".
Ha puntualizado que las panaderías y, en general, esos pequeños comercios
que hay en cada pueblo "es necesario que estén para darle vida, para que ese
desarrollo rural con el que tanto se le calienta la boca a los políticos pueda ser
posible y que esos pueblos existan"

1.4.2. Especifico

Actualmente a raíz de esta pandemia mundial todos los negocios se han debido
afectados por el aislamiento social obligatorio, que es una medida otorgada por
el Gobierno para evitar el contagio y propagación de este virus.
Según nos Comenta (Pío Pantoja, 2020, pag.1) que el Gobierno del Perú ha
decretado a nivel nacional el aislamiento de las personas sin poder salir, salvo
para comprar alimentos (pan) de primera necesidad donde a Nivel nacional
panaderías, pastelerías, bodegas, sólo han abierto sus puertas 11,000
aproximadamente. Ellos totalmente siguen trabajando para producir y vender
pan diariamente, tanto como los dueños, trabajadores y clientes, se siguen
costeando gastos extras, como en protocolos de seguridad de salud sin
Incrementar los precios finales.

1.4.3. Empresa

En la Panadería “La Unión” ha tenido problemas financieros a consecuencia del


impacto del COVID-19, donde tuvo problemas con la falta de liquidez para
comprar materias primas y/o insumos para su producción y señalaron que
tuvieron limitaciones para acceder a fuentes financieras y también la falta de
liquidez para poder pagar a sus proveedores y personal de trabajo, bajo estos
problemas el Jefe General tomo la decisión de cerrar el local en los meses de
Junio y Julio incluso tuvo que reducir personal, por ello tuvo que reactivarse en
el mes de Agosto bajo los protocolos de bioseguridad para evitar los contagios,
a consecuencia de estos protocolos se redujo el personal y el aforo para su
negocio.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
El Jefe General realizo un estudio interno de sus procesos de negocio, donde
todo su desarrollo lo tenían en archivos Excel, Archivos Words donde también el
proceso de pedidos que se implementó desde el año 2011 se realizan mediante
llamada y es anotado en un block de notas y guardado en un archivo especifico
de pedido en sus pc’s, esto generaba desorden y una mala gestión para este
negocio, donde siempre habían reclamos por incumplimiento de pedidos,
impuntualidad en la entrega de los pedidos o a veces se perdida la data del block
de notas y no se procesaba ninguno de los pedidos hasta que se solucionaba
generando molestia en sus clientes, de la cual esto pasa en las empresas que
no cuentan con un proceso de pedidos por delivery automatizado en un sistema
web o un app móvil.

1.5. Propuesta de Solución

 Nuestra solución como equipo Implementaremos un Sistema Web para el


Proceso de Pedidos por Delivery de la Panadería “La Unión”, ya que
actualmente su proceso de pedidos por Delivery se realiza por teléfono y
apuntado en un block de notas de la cual genera un desorden y también
han tenido reclamos por la falta de incumplimiento de la entrega de
productos o retrasos para la entrega, con esta solución nosotros haremos
que su proceso se automatice y se agilice mas los tiempos de este
proceso, de cual será un gran apoyo para el negocio, generando mayores
ingresos y recuperándose administrativamente

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
CAPITULO II: PROYECTO
2.1. Marco Metodológico
2.1.1. Aplicativo Web
Se conoce como aplicación web a la aplicación informática con una interfaz de
usuario que puede ser accedida desde un cliente web, normalmente un
navegador web. Habitualmente destaca por acceder a una base de datos y
contar con procesamiento desde un servidor. (ISI, 2017) Sin embargo, la
dificultad de crear un aplicativo web reside en el manejo del código fuente,
archivos de configuración, librerías, entre otros componentes. En el desarrollo
tradicional, todo el código generado y su administración dependían de un grupo
de personas encargadas del desarrollo de la aplicación. Ante esta problemática
surgen los frameworks con el objetivo de normalizar y estructurar el código de
una aplicación. Facilitan al programador un esqueleto o patrón para la
implementación de aplicaciones, reducen el tiempo de elaboración de código y
ayudan a elaborar un trabajo mantenible y escalable. (GUM, 2016)

2.1.2. Aplicativo Móvil


“Atendemos como aplicación móvil, cualquier aplicación software creada por
terceros y destinada a su instalación y ejecución en un dispositivo móvil, esto es
de tamaño reducido e ideado para ser utilizado de manera inalámbrica” (Soto,
2013, p. 26)
TIPO DE APLICACIONES
 Aplicaciones Nativas
 Aplicaciones Hibridas
 Aplicaciones Web

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.1.3. Netbeans
Según (Girardi, 2016), NetBeans IDE es una aplicación de código abierto "open
source" diseñada para el desarrollo de aplicaciones fácilmente portables entre
las distintas plataformas, haciendo uso de la tecnología Java, dispone de soporte
para crear interfaces gráficas de forma visual, desarrollo de aplicaciones web,
control de versiones, colaboración entre varias personas, creación de
aplicaciones compatibles con teléfonos móviles, y por si fuera poco sus
funcionalidades son ampliables mediante la instalación de packs. Por lo tanto en
NetBeans se puede encontrar la solución más completa para programar en Java.

2.1.4. Lenguaje PHP


 Es un lenguaje multiplataforma
 Capacidad de conexión con la mayoría de los manejadores de bases de
datos que se utilizan en la actualidad
 Es libre, por lo que se presenta como alternativa de fácil acceso para todos
 Permite las técnicas de Programación Orientado a Objetos
Los principales usos del PHP son los siguientes: Programación de Páginas Web
dinámicas, habitualmente en combinación con el motor de bases de datos
MySQL, aunque cuenta con soporte nativo para otros motores, incluyendo el
estándar ODBC, lo que amplía en gran medida sus posibilidades de conexión
(García, 2013)

2.1.5. Framework Laravel


Laravel es un nuevo y poderoso Framework PHP desarrollado por Taylor Otwell,
que promete llevar al lenguaje PHP a un nuevo nivel. Laravel, propone una forma
de desarrollar aplicaciones web de un modo mucho más ágil. Por ejemplo, en
Laravel opcionalmente podemos usar el patrón de diseño MVC (Modelo-Vista-
Controlador) tradicional, donde al igual que otros frameworks PHP, el controlador
es programado como una clase. 42 Por lo tanto, un Controlador es una clase
PHP que dispone de métodos públicos que son el punto de entrada final de una
petición HTTP (Request PHP) a nuestra aplicación. Pero, Laravel propone
además una forma distinta y más directa de responder a la solicitud HTTP.
(Patricio, 2015)

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.1.6. Bootstrap
Bootstrap, es un framework originalmente que fue desarrollado por Twitter, que
permite crear un sinnúmeros interfaces web con estilos CSS3 y JavaScript, y a
su vez es adaptada la interfaz del sitio web, al tamaño de un dispositivo móvil.
Esto determina al sitio web que se adapta automáticamente al tamaño de una
PC, una Tablet y otros dispositivos móvil en fin. También se denomina en diseño
y desarrollo web como formato “responsive design” o diseño adaptativo que
puede ser utilizado en cualquier proyecto de desarrollo (Montón, 2014)
(Application & Routing, 2013) (Erasmus & Azpeitia, 2014).

2.1.7. Jquery
Esta biblioteca de software libre desarrollada con JavaScript que permite
simplificar, optimizar e interactuar con los determinados documentos HTML, que
nos permite crear animaciones y generar variedad elementos que son
interactivos en la web. En definición JQuery es una biblioteca que ofrece una
serie de funcionalidades cuya implementación y desarrollo requerirían de mucho
más código, es decir, se pueden lograr grandes resultados en menor tiempo y
utilizando menor código. (Regla, 2014)

2.1.8. Css3
Según (GAUCHAT, 2015, pág. 64) indica que: “En un intento por reducir el uso
de código Javascript y para estandarizar funciones populares, CSS3 no solo
cubre diseño y estilos web sino también forma y movimiento. La especificación
de CSS3 es presentada en módulos que permiten a la tecnología proveer una
especificación estándar por cada aspecto involucrado en la presentación visual
del documento”.
Según lo expresado por GAUCHAT se puede argumentar que CSS tiene
asignados propiedades y estilo previstos por navegadores, propiedades que son
combinadas para obtener un correcto estilo en la visualización.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.1.9. Plantilla administrable de AdminLTE 3
AdminLTE es una plantilla open source para paneles de control o dashboards
desarrollada con Bootstrap 3 , la cual nos brinda vistas reusables y responsive
de muchos componentes comunes para la parte administrativa de un proyecto,
fue creado por Sergui Tur Badenas. (Torrealba, 2016)

2.1.10. Servidor MYSQL


MySQL es, por otro lado, la base datos elegida por la gran mayoría de los
programadores en PHP. Soporta el lenguaje SQL y la conexión de varios
usuarios, por, en general, se utiliza para aplicaciones de tamaño pequeño-medio.
(Borges, Ezequiel, Puertas, Jacobo p.18)

2.1.11. Servidor Apache


Apache proporciona contenidos al cliente web o navegador como:
Paginas estáticas: es el modo más básico y antiguo, pero también es el uso más
generalizado que se hace de un servidor web. De esta forma se transfieren
archivos HTML, imágenes, etc. Y no se requiere un servidor muy potente en lo
que al hardware se refiere.
Paginas dinámicas: La información que muestran las páginas que sirve Apache
cambia continuamente ya que se obtiene a partir de consultas a bases de datos
u otras fuentes de datos. Son páginas con contenido dinámico, cambiante.
(Mifsuf 2013 p. 18)

2.1.11.1. JavaScript
El código de programa de JavaScript, llamado script, se introduce directamente
en el documento HTML y no necesita ser compilado, es el propio navegador el
que se encarga de traducir dicho código. Gracias a JavaScript podemos
desarrollar programas que se ejecuten directamente en el navegador (cliente) de
manera que este pueda efectuar determinadas operaciones o tomar decisiones
sin necesidad de acceder al servidor. (Orós 2014 p. 74)

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.1.11.2. Flutter
Flutter es un SDK (Software Development Kit) para desarrollo de aplicaciones
móviles multiplataforma, es decir que con el mismo código fuente puedes crear
apps para Android y para IOS. Y estas aplicaciones son 100% nativas, no
hibridas, no pseudo nativas, sino apps que se compilan directamente para el
procesador del dispositivo. Para desarrollar con Flutter debes usar el lenguaje
de programación Dart. Villegas, (Loor 2020 p. 26)

2.1.11.3. Emulador de Android Studio


Android e s un sistema operativo, inicialmente diseñado para teléfonos móviles
como los sistemas operativos iOS (Apple), FireFoxOs (Mozilla) y Blackberry OS.
Este sistema operativo permite programar aplicaciones empleado una variación
de Java llamada Dalvik(o ART a partir de la versión 5.0 de Android) y proporciona
todas las interfaces necesarias para desarrollar fácilmente aplicaciones que
acceden a las funciones de teléfono (como el GPS, las llamadas, la agenda)
utilizando el lenguaje de programación Java. (Robledo 2017 p. 7)

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2. Documentación del Software
2.2.1. Fundamentación Teórica

METODOLOGIA SCRUM
Scrum propone una serie de roles, artefactos y actividades que hay que asumir
en el seno de un proyecto. Una gran parte de estos aspectos van orientados
principalmente a la creación de un flujo de comunicación que cubra todas las
necesidades en este aspecto en el seno de un proyecto: de cómo se comunica,
a quien se comunica y cuando se comunica depende en gran parte el éxito o el
fracaso del proyecto. (Galiano, Josep 2016 p. 15)

SPRINT:
Un sprint es la unidad de tiempo que determina un ciclo de desarrollo con Scrum.
En este tiempo deben llevarse a cabo obligatoriamente las actividades siguientes
- El sprint planning.
- Dialy meeting.
- Sprint review.
- Sprint retrospective.
Monte 2016 (p 77)

PRODUCT BACKLOG:
El product backlog es la lista de funcionalidades, productos o acciones que
conforman el producto que se ha de construir. El product backlog se escribe en
el idioma del cliente y se compone de historias de usuario, que veremos más
adelante cada historia se va completando y detallando a medida que se necesita
o debe información. Ha de tener suficiente información para permitir que el
equipo pueda hacer una estimación de lo que costaría hacerla realidad. Monte
2016 (p 55)

HISTORIA DE USUARIO:
Las historias de usuario, son pequeñas descripciones de los requerimientos de
un cliente. Su utilización es común cuando se aplica marcos de entornos ágiles
como Scrum. Al redactar las historias de usuario se debe tener en cuenta
describir el Rol, la funcionalidad y el resultado esperado en una frase corta. Debe

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
venir acompañada (al reverso) de los criterios de aceptación, hasta un máximo
de 4 por historia, redactado también en una frase que indique el contexto, el
evento y el comportamiento esperado ante ese evento.
Es deseable que las historias de usuario sean escritas por el usuario, en una
frase corta. Debe describir el rol desempeñado por el usuario. Enrique Ledesma
(2020)

SPRINT PLANNING MEETING:


El sprint planning sirve para planificar en detalle el sprint. Recoger la
funcionalidad que se ha de desarrollar, resolver dudad, crear las user stories,
determinar los criterios de aceptación del sprint y de cada user story, dividir las
user stories en tareas y determinar el esfuerzo de cada tarea. Monte 2016 (p 79)

DAILY STANDUP MEETINGS:


El daily meeting ha de realizarse siempre en el mismo lugar y a la misma hora, y
no ha de durar más de quince minutos. Por lo que se refiere a los asistentes, es
necesario que esté presente todo el DR, el SM puede asistir voluntariamente y
el PO solo puede asistir si se le invita. En esta reunión, todos los componentes
del DT han de exponer brevemente:
- Como llevan el trabajo asignado.
- Si acabarán el trabajo en el tiempo previsto.
- Si han acabado el trabajo, que nueva tarea asumen.
- Si tienen algún problema, lo expondrán para que se pueda encontrar una
solución.
Monte 2016 (p 87)

REUNION RETROSPECTIVA
En esta reunión, el DT y el SM debaten sobre los incidentes registrados en el
incident backlog y en el impediments backlog. Se buscan soluciones para las
cuestiones aparecidas durante el sprint que puedan haber sido un freno para la
productividad. Se tratan temas que permitan cerrar el sprint e iniciar uno nuevo
con el equipo reforzado en todos los sentidos. Monte 2016 (p 90)

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
BURNDOWN CHART
Un tipo de tabla utilizada en metodologías ágiles para medir la cantidad de
trabajo restante contra el tiempo. Un gráfico de trabajo pendiente típico
representará el trabajo sobresaliente (número de funciones, días ideales, días
de equipo, etc.) en el eje vertical, y el tiempo (días, iteraciones, sprints, etc.) en
el eje horizontal.
Los gráficos de trabajo pendiente son muy útiles para medir el progreso real del
trabajo en comparación con el progreso ideal del trabajo, y detectar los posibles
retrasos en los horarios y los problemas de ritmo de trabajo desde el principio.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.2. Desarrollo de la Metodología
2.2.2.1. SPRINT 1
En este documento estamos desarrollando la metodología Scrum y en la primera Fase estamos viendo las Historias de
Usuario.

 Las Historias de Usuarios son los requerimientos funcionales del sistema requeridos por el cliente, en el siguiente
cuadro podemos visualizar los Roles y Características de funcionalidad de cada uno de nuestros Usuarios.
 En el Sprint 1 Podemos observar cómo cada Rol tiene una Razón y un Resultado o Comportamiento esperado.

2.2.2.1.1. Historias de Usuario 1


Identifica
dor (ID) Característica / Número (#) de
Rol Razón / Resultado
de la Funcionalidad escenario
historia
Como Necesito un usuario Con la finalidad de poder acceder al sistema. 1
cliente/administrador/vendedor/repartidor y contraseña.
HU-1 2
3

Como cliente necesito poder Con la finalidad de tener una cuenta. 1


HU-2 registrar mis datos 2
en el formulario 3

Como administrador necesito poder Con la finalidad agregar nuevo personal. 1


HU-3 acceder a ingresar
nuevos usuarios
Como administrador/cliente necesito poder Con la finalidad de que los campos estén 1
HU-4 actualizar mis datos perfectamente llenados.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Como necesito poder cambiar Con la finalidad de tener mi cuenta segura. 1
HU-5 administrador/vendedor/cliente mi contraseña
2
Como administrador necesito poder agregar, Con finalidad de mantener las categorias 1
HU-6 modificar y eliminar actualizadas.
categoría 2
3
Como administrador/vendedor necesito poder agregar, Con finalidad de mantener el catalogo actualizado. 1
HU-7 modificar y eliminar 2
productos del catalogo 3
Como vendedor necesito visualizar los Con la finalidad de ver la cantidad de stock. 1
HU-8
productos

Como Cliente/administrador/vendedor necesito visualizar el Con la finalidad de realizar un pedido. 1


HU-9
catálogo de productos

Como Cliente/administrador/vendedor necesito visualizar Con la finalidad de obtener más información del 1
HU-10
detalle de producto producto.

Como Cliente/administrador/vendedor necesito visualizar el Con la finalidad de agregar más productos al 1


HU-11
carrito de compra carrito.

Como administrador/vendedor necesito visualizar los Con la finalidad de saber cuánto se está ganando 1
HU-12
pedidos totales en ventas.
Creación del Crud del Modelo necesito visualizar mis Con la finalidad de ver todos los pedidos 1
HU-13
Categoría pedidos realizados.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Como administrador/vendedor necesito poder exportar Con la finalidad de obtener el reporte completo y 1
HU-14
mis pedidos archivarlo.
1
HU-15 Como cliente/administrador/vendedor necesito poder realizar Con la finalidad de obtener el producto pedido.
2
un pago
3
Como cliente necesito poder visualizar Con la finalidad de saber cuántos pedidos he 1
HU-16 mis pedidos realizado. 2
Como administrador/vendedor necesito poder ver el Con la finalidad de poder atenderlos. 1
HU-17 /repartidor estado de los pedidos
2
como necesito poder modificar Con la finalidad de poder controlar los pedidos 1
administrador/vendedor/repartidor el estado del pedido que haya sido pagado.
HU-18 2

Enlace del Archivo


https://drive.google.com/file/d/1U7guI2BETPdmuO1wGf8qIk9YpmWHCjdM/view?usp=sharing

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.2.1.2. Product Backlog 1
En el Product Backlog 1 podemos observar cómo cada Historia de Usuario tiene una Estimación por Estados,
Puntos de Usuario donde Se estima bajo puntos de usuario utilizando de 0 a 13, donde 13 tiene mayor
complejidad, Se requiere más información, es muy compleja y se debe desglosar y por último por Horas.
También especifica su criterio de aceptación, su prioridad y el responsable.

ESTIMACIÓN
ID HISTORIAS DE USUARIOS ESTADO Puntos de Usuario Horas CRITERIO DE ACEPTACIÓN
1 Como cliente/administrador/vendedor/repartidor Hecho 5 5 Cuando el Product Owner acepta la
necesito un usuario y contraseña con la finalidad de funcionalidad
poder acceder al sistema.
2 Como cliente necesito poder registrar mis datos en el Hecho 5 5 Cuando el Product Owner acepta la
formulario necesito poder registrar mis datos en el funcionalidad
formulario con la finalidad de tener una cuenta.

3 Como administrador necesito poder acceder a ingresar Hecho 5 5 Cuando el Product Owner acepta la
nuevos usuarios con la finalidad agregar nuevo funcionalidad
personal.

4 Como administrador/cliente necesito poder actualizar Hecho 5 5 Cuando el Product Owner acepta la
mis datos con la finalidad de que los campos estén funcionalidad
perfectamente llenados.

5 Como administrador/vendedor/cliente necesito poder Hecho 5 5 Cuando el Product Owner acepta la


cambiar mi contraseña con la finalidad de tener mi funcionalidad
cuenta segura.

6 Como administrador necesito poder agregar, modificar Hecho 2 2 Cuando el Product Owner acepta la
y eliminar categoría con finalidad de mantener las funcionalidad
categorías actualizadas.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
COMENTARIO TIPO DE EPICA PRIORIDAD RESPONSABLE SPRINT
Se necesita el modelo de login de usuario para el acceso al aplicativo. Requerimiento Medio Sebastian A. 1

Se necesita el modelo del formulario para registrar usuarios Requerimiento Medio Rosmel G. 1

Se necesita el modelo para agregar nuevos usuarios. Requerimiento Medio Ronaldo E. 1

Se necesita el modelo de actualizar perfil de usuario. Requerimiento Medio Anthony C. 1

Se necesita el modelo de modificar mi contraseña Requerimiento Medio Juan E. 1

Se necesita el modelo de agregar, modificar y eliminar categorías Requerimiento Bajo Anthony C. 1

Enlace del Archivo


https://drive.google.com/file/d/1BEvuA71L8SnWvQLKCAr84S78ijJkrydZ/view?usp=sharing

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.2.1.3. Sprint Planning Meeting 1
En este punto se coordinó las reuniones donde el equipo hace bastantes
preguntas para estimar y distribuir las tareas que se cumplirán durante el
Sprint 1.

2.2.2.1.3.1. Release Planning 1

Tabla 2. Release Planning 1


Sprints Historia de Usuario Fecha propuesta
SPRINT 1 HU-01 18/10/20
SPRINT 1 HU-02 18/10/20

SPRINT 1 HU-03 20/10/20


SPRINT 1 HU-04 21/10/20

SPRINT 1 HU-05 22/10/20


SPRINT 1 HU-06 24/10/20

Fuente: Elaboración propia

2.2.2.1.3.2. Daily Standup Meetings 1

Tabla 3.Daily Standup Meetings 1


Sprint Participantes Fecha de reunión

Team Scrum – Dueño Del Negocio 8/10/20


Team Scrum – Dueño Del Negocio 15/10/20

Team Scrum – Dueño Del Negocio 23/10/02

Team Scrum – Dueño Del Negocio 29/10/20


1
Team Scrum – Dueño Del Negocio 30/10/20

Team Scrum – Dueño Del Negocio 31/10/20

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.2.1.4. Sprint Backlog 1
En los siguientes cuadros podemos observar los detalles completos del Sprint 1, empezando por las historias de usuarios y el
cronograma de actividades establecidas en las reuniones dándonos esta grafica del Burndown Chart

USER STORIES
Como cliente/administrador/vendedor/repartidor necesito un usuario y contraseña con la finalidad de poder acceder al sistema.
Como cliente necesito poder registrar mis datos en el formulario necesito poder registrar mis datos en el formulario con la finalidad de tener una cuenta.
Como administrador necesito poder acceder a ingresar nuevos usuarios con la finalidad agregar nuevo personal
Como administrador/cliente necesito poder actualizar mis datos con la finalidad de que los campos estén perfectamente llenados.

Como administrador/vendedor/cliente necesito poder cambiar mi contraseña con la finalidad de tener mi cuenta segura.

Como administrador necesito poder agregar, modificar y eliminar categoría con finalidad de mantener las categorías actualizadas.

Estimado Real
Días de implementación de Sprint 14 40
Horas o Puntos de usuario 41 18
Estado del Sprint Hecho

FECHA DE INICIO 18/10/2020


FECHA DE FIN 31/10/2020

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
DÍA 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Real
TAREA ESTIMADO
Planeacion y Gestion de 1
Historias de Usuario 1 1
Creacion del modelo de login 2
de usuario para el acceso al
aplicativo. 1 1 2
Creacion del modelo del 2
formulario para registrar
usuarios 1 1 2
Creacion del modelo Creación 2
de Usuario 1 1 2
Creacion del modelo de 2
actualizar perfil de usuario. 1 1 1 3
Creacion del modelo de 1
modificar mi contraseña 1 1 2
Creacion modelo de 2
agregar,modificar y eliminar
categorias 1 1 2
Correción de erros de cada 2
modulo 1 1 1 1 4

Restante 14 13 12 11 10 8 6 4 2 1 0 -1 -2 -3 -4
Estimado 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 18

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Burndown Chart
16
14 14
13
12 12
11
10 10
8 8
6 6
4 4
2 2
1
0 0
1 2 3 4 5 6 7 8 9 10 11 12 -1 13 14 15
-2 -2
-3
-4 -4
-6

Enlace del Archivo


https://drive.google.com/file/d/1BEvuA71L8SnWvQLKCAr84S78ijJkrydZ/view?usp=sharing

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.2.1.5. Reunión Retrospectiva 1
En esta última fase realizamos la reunión con el cliente mostrando el Sprint 1 terminado
y las personas que asistieron.

Resumen de la
Reunión Retrospectiva 1

Información de la empresa y proyecto:

Tabla 4. Reunión Retrospectiva 1


Empresa / Panadería “La Unión”
Organización
Proyecto Proyecto De Aplicativo Web De Delivery Panadería
“La Unión”

Información de la reunión:
Lugar VIODELLAMADA ZOOM
Fecha 31/10/20
Número De Iteración / Sprint 1

Team Scrum, Product Owner Y Dueño Del


Negocio
Personas Convocadas A La
Reunión

Personas Que Asistieron A La


Reunión Todas Las Personas Asistieron

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.2.2. Sprint 2
2.2.2.2.1. Historias de Usuario 2
Continuando podemos observar el cuadro del Sprint 2 y su historia de usuario que de igual manera son los requerimientos
funcionales del sistema requeridos por el cliente, en el siguiente cuadro podemos visualizar los Roles y Características de
funcionalidad de cada uno de nuestros Usuarios.
En el Sprint 2 Podemos observar cómo cada Rol tiene una Razón y un Resultado o Comportamiento esperado.

Identifica
dor (ID) Característica / Número (#) de
Rol Razón / Resultado
de la Funcionalidad escenario
historia
Como Necesito un usuario Con la finalidad de poder acceder al sistema. 1
cliente/administrador/vendedor/repartidor y contraseña.
HU-1 2
3

Como cliente necesito poder Con la finalidad de tener una cuenta. 1


HU-2 registrar mis datos 2
en el formulario 3

Como administrador necesito poder Con la finalidad agregar nuevo personal. 1


HU-3 acceder a ingresar
nuevos usuarios
Como administrador/cliente necesito poder Con la finalidad de que los campos estén 1
HU-4 actualizar mis datos perfectamente llenados.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Como necesito poder cambiar Con la finalidad de tener mi cuenta segura. 1
HU-5 administrador/vendedor/cliente mi contraseña
2
Como administrador necesito poder agregar, Con finalidad de mantener las categorias 1
HU-6 modificar y eliminar actualizadas.
categoría 2
3
Como administrador/vendedor necesito poder agregar, Con finalidad de mantener el catalogo actualizado. 1
HU-7 modificar y eliminar 2
productos del catalogo 3
Como vendedor necesito visualizar los Con la finalidad de ver la cantidad de stock. 1
HU-8
productos

Como Cliente/administrador/vendedor necesito visualizar el Con la finalidad de realizar un pedido. 1


HU-9
catálogo de productos

Como Cliente/administrador/vendedor necesito visualizar Con la finalidad de obtener más información del 1
HU-10
detalle de producto producto.

Como Cliente/administrador/vendedor necesito visualizar el Con la finalidad de agregar más productos al 1


HU-11
carrito de compra carrito.

Como administrador/vendedor necesito visualizar los Con la finalidad de saber cuánto se está ganando 1
HU-12
pedidos totales en ventas.
Creación del Crud del Modelo necesito visualizar mis Con la finalidad de ver todos los pedidos 1
HU-13
Categoría pedidos realizados.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Como administrador/vendedor necesito poder exportar Con la finalidad de obtener el reporte completo y 1
HU-14
mis pedidos archivarlo.
1
HU-15 Como cliente/administrador/vendedor necesito poder realizar Con la finalidad de obtener el producto pedido.
2
un pago
3
Como cliente necesito poder visualizar Con la finalidad de saber cuántos pedidos he 1
HU-16 mis pedidos realizado. 2
Como administrador/vendedor necesito poder ver el Con la finalidad de poder atenderlos. 1
HU-17 /repartidor estado de los pedidos
2
como necesito poder modificar Con la finalidad de poder controlar los pedidos 1
administrador/vendedor/repartidor el estado del pedido que haya sido pagado.
HU-18 2

Enlace del Archivo


https://drive.google.com/file/d/1U7guI2BETPdmuO1wGf8qIk9YpmWHCjdM/view?usp=sharing

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.2.2.2. Product Backlog 2
De igual manera en el Product Backlog 2 podemos observar cómo cada Historia de Usuario tiene una Estimación por
Estados, Puntos de Usuario donde Se estima bajo puntos de usuario utilizando de 0 a 13, donde 13 tiene mayor
complejidad, Se requiere más información, es muy compleja y se debe desglosar y por último por Horas.
También especifica su criterio de aceptación, su prioridad y el responsable.
7 Como administrador/vendedor necesito poder Hecho 3 3 Cuando el Product Owner acepta la
agregar, modificar y eliminar productos del funcionalidad
catálogo con finalidad de mantener el catalogo
actualizado.
8 Como vendedor necesito visualizar los productos Hecho 5 5 Cuando el Product Owner acepta la
con la finalidad de ver la cantidad de stock. funcionalidad

9 Como Cliente/administrador/vendedor necesito Hecho 2 2 Cuando el Product Owner acepta la


visualizar el catálogo de productos con la finalidad funcionalidad
de realizar un pedido.
10 Como Cliente/administrador/vendedor necesito Hecho 5 5 Cuando el Product Owner acepta la
visualizar detalle de producto con la finalidad de funcionalidad
obtener más información del producto.

11 Como Cliente/administrador/vendedor necesito Hecho 3 3 Cuando el Product Owner acepta la


visualizar el carrito de compra con la finalidad de funcionalidad
agregar más productos al carrito.

12 Como administrador/vendedor necesito visualizar Hecho 3 3 Cuando el Product Owner acepta la


los pedidos totales con la finalidad de saber cuánto funcionalidad
se está ganando en ventas.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Se necesita el modelo de agregar, modificar y Requerimiento Bajo Anthony C. 2
eliminar de catálogos de productos

Se necesita el modelo de productos para ver la Requerimiento Medio Ronaldo E. 2


calidad de stock

Se necesita el modelo de catálogos de productos Requerimiento Bajo Rosmel G. 2


para realizar un pedido

Se necesita el modelo de ventas para ver el reporte Requerimiento Medio Juan E. 2


completo de ventas.

Se necesita el modelo de carrito para ver los Requerimiento Medio Anthony C. 2


pedidos realizados.

Se necesita el modelo de pedidos para verificar los Requerimiento Medio Ronaldo E. 2


pedidos totales

Enlace del Archivo


https://drive.google.com/file/d/1lR-n6aMj8HipakD3JwkrcouebFdyS7SA/view?usp=sharing

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.2.2.3. Sprint Planning Meeting 2
En este punto se coordinó las reuniones donde el equipo hace bastantes preguntas
para estimar y distribuir las tareas que se cumplirán durante el Sprint 2.

2.2.2.2.3.1. Release Planning 2


Sprints Historia de Usuario Fecha propuesta
Sprint 2 HU-07 2/11/20
Sprint 2 HU-08 4/11/20

Sprint 2 HU-09 6/11/20

Sprint 2 HU-10 8/11/20

Sprint 2 HU-11 10/11/20

Sprint 2 HU-12 12/11/20

Fuente: Elaboración propia

2.2.3.2.3.2. Daily Standup Meetings 2


Sprint Participantes Fecha De Reunión

Team Scrum – Dueño Del Negocio 5/11/20

Team Scrum – Dueño Del Negocio 8/11/20

Team Scrum – Dueño Del Negocio 10/11/02


1
Team Scrum – Dueño Del Negocio 12/11/20

Team Scrum – Dueño Del Negocio 15/11/20

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.3.2.4. Sprint Backlog 2
En los siguientes cuadros podemos también observar los detalles completos del Sprint 2, empezando por las historias de usuarios
y el cronograma de actividades establecidas en las reuniones dándonos esta gráfica del Burndown Chart

USER STORIES
Como administrador/vendedor necesito poder agregar, modificar y eliminar productos del catálogo con finalidad de mantener el catalogo actualizado.

Como vendedor necesito visualizar los productos con la finalidad de ver la cantidad de stock.

Como Cliente/administrador/vendedor necesito visualizar el catálogo de productos con la finalidad de realizar un pedido.

Como Cliente/administrador/vendedor necesito visualizar detalle de producto con la finalidad de obtener más información del producto.

Como Cliente/administrador/vendedor necesito visualizar el carrito de compra con la finalidad de agregar más productos al carrito.

Como administrador/vendedor necesito visualizar los pedidos totales con la finalidad de saber cuánto se está ganando en ventas.

Días de implementación de Sprint 14 40


Horas o Puntos de usuario 41 17
Estado del Sprint Hecho

FECHA DE INICIO 02/11/2020


FECHA DE INICIO 15/11/2020

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
DÍA 2 3 4 5 6 7 8 9 10 11 12 13 14 15 REAL
TAREA ESTIMADO
Planeación y Gestión de Historias de Usuario para el
Sprint2 2 1 1 2
Creación del modelo de Categoría

3 1 1 1 3
Creación del Crud del Modelo Categoría
1 1 2
Creación del Modelo de Producto

2 1 1 2
Creación del Crud del Modelo Producto
1 1 1
Creación de la funcionalidad para realizar pedidos en el
modelo de catálogos de productos
3 1 1 1 3
Creación de la funcionalidad de reporte de ventas para el
modelo de ventas
1 1 1
Creación y desarrollo de las funcionalidades del modelo
de carrito 2 1 1 2
Creación y desarrollo de las funcionalidades de modelo de
pedidos
1 1 1

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Burndown Chart
18 18

16 16 16
15
14 14
13
12 12 12

10 10 10
9
8 8 8
7
6 6 6
5
4 4 4
3
2 2 2
1
0 0 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Enlace del Archivo


https://drive.google.com/file/d/1lR-n6aMj8HipakD3JwkrcouebFdyS7SA/view?usp=sharing

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.3.2.5. Reunión Retrospectiva 2
En esta última fase realizamos la segunda reunión con el cliente mostrando el Sprint 2
terminado y las personas que asistieron

Resumen de la
Reunión Retrospectiva 2

Información de la empresa y proyecto:

Tabla 5. Reunión Retrospectiva 2


Empresa / Panadería “La Unión”
Organización
Proyecto Proyecto De Aplicativo Web De Delivery Panadería
“La Unión”

Información de la reunión:
Lugar VIODELLAMADA ZOOM
Fecha 15/11/20
Número de iteración / sprint 2

Team Scrum, Product Owner Y Dueño Del Negocio

Personas convocadas a la
reunión

Personas que asistieron a la


reunión Todas las personas asistieron

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.3.3. Sprint 3
2.2.3.3.1. Historias de Usuario 3
 En este último Sprint 3 también podemos observar que las Historias de Usuarios son los requerimientos funcionales
del sistema requeridos por el cliente, en el siguiente cuadro podemos visualizar los Roles y Características de
funcionalidad de cada uno de nuestros Usuarios.
 En el Sprint 3 Podemos observar cómo cada Rol tiene una Razón y un Resultado o Comportamiento esperado.

Identifica
dor (ID) Característica / Número (#) de
Rol Razón / Resultado
de la Funcionalidad escenario
historia
Como Necesito un usuario Con la finalidad de poder acceder al sistema. 1
cliente/administrador/vendedor/repartidor y contraseña.
HU-1 2
3

Como cliente necesito poder Con la finalidad de tener una cuenta. 1


HU-2 registrar mis datos 2
en el formulario 3

Como administrador necesito poder Con la finalidad agregar nuevo personal. 1


HU-3 acceder a ingresar
nuevos usuarios
Como administrador/cliente necesito poder Con la finalidad de que los campos estén 1
HU-4 actualizar mis datos perfectamente llenados.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Como necesito poder cambiar Con la finalidad de tener mi cuenta segura. 1
HU-5 administrador/vendedor/cliente mi contraseña
2
Como administrador necesito poder agregar, Con finalidad de mantener las categorias 1
HU-6 modificar y eliminar actualizadas.
categoría 2
3
Como administrador/vendedor necesito poder agregar, Con finalidad de mantener el catalogo actualizado. 1
HU-7 modificar y eliminar 2
productos del catalogo 3
Como vendedor necesito visualizar los Con la finalidad de ver la cantidad de stock. 1
HU-8
productos

Como Cliente/administrador/vendedor necesito visualizar el Con la finalidad de realizar un pedido. 1


HU-9
catálogo de productos

Como Cliente/administrador/vendedor necesito visualizar Con la finalidad de obtener más información del 1
HU-10
detalle de producto producto.

Como Cliente/administrador/vendedor necesito visualizar el Con la finalidad de agregar más productos al 1


HU-11
carrito de compra carrito.

Como administrador/vendedor necesito visualizar los Con la finalidad de saber cuánto se está ganando 1
HU-12
pedidos totales en ventas.
Creación del Crud del Modelo necesito visualizar mis Con la finalidad de ver todos los pedidos 1
HU-13
Categoría pedidos realizados.

Enlace del Archivo


https://drive.google.com/file/d/1U7guI2BETPdmuO1wGf8qIk9YpmWHCjdM/view?usp=sharing

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.3.3.2. Product Backlog 3

 De igual manera en el Product Backlog 3 podemos observar cómo cada Historia de Usuario tiene una Estimación por Estados,
Puntos de Usuario donde Se estima bajo puntos de usuario utilizando de 0 a 13, donde 13 tiene mayor complejidad, Se
requiere más información, es muy compleja y se debe desglosar y por último por Horas.
 También especifica su criterio de aceptación, su prioridad y el responsable.

12 Como administrador/vendedor necesito visualizar Hecho 3 3 Cuando el Product Owner acepta la funcionalidad
los pedidos totales con la finalidad de saber cuánto
se está ganando en ventas.

13 Como administrador/vendedor necesito visualizar Hecho 3 3 Cuando el Product Owner acepta la funcionalidad
mis pedidos con la finalidad de ver todos los pedidos
realizados.
14 Como administrador/vendedor necesito poder Hecho 3 3 Cuando el Product Owner acepta la funcionalidad
exportar mis pedidos con la finalidad de obtener el
reporte completo y archivarlo.
15 Como cliente/administrador/vendedor necesito Hecho 3 3 Cuando el Product Owner acepta la funcionalidad
poder realizar un pago con la finalidad de obtener el
producto pedido.

16 Como cliente necesito poder visualizar mis pedidos Hecho 3 3 Cuando el Product Owner acepta la funcionalidad
con la finalidad de saber cuántos pedidos he
realizado.
17 Como administrador/vendedor /repartidor necesito Hecho 3 3 Cuando el Product Owner acepta la funcionalidad
poder ver el estado de los pedidos con la finalidad
de poder atenderlos.

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
18 Como administrador/vendedor/repartidor necesito Hecho 3 3 Cuando el Product Owner acepta la funcionalidad
poder modificar el estado del pedido con la finalidad
de poder controlar los pedidos que haya sido
pagado.

Se necesita el modelo de pedidos para verificar Requerimiento Medio Sebastian A. 3


los pedidos realizados

Se necesita el modelo de exportar documento Requerimiento Medio Ronaldo E. 3


para descargar la data de pedidos

Se necesita el modelo de pagos para finalizar la Requerimiento Bajo Sebastian A. 3


compra de un productos

Se necesita el modelo de pedidos para verificar Requerimiento Bajo Rosmel G. 3


los pedidos realizados
Se necesita el modelo de estados de pedidos Requerimiento Bajo Ronaldo E. 3

Se necesita el modelo de estados de pedidos para Requerimiento Bajo Ronaldo E. 3


modificar o controlar los pedidos

Enlace del Archivo 3


https://drive.google.com/file/d/1ImiNygXzFRd1V9ff5KND53ZwoWwsSp8Y/view?usp=sharing
Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.3.3.3. Sprint Planning Meeting 3
En este punto se coordinó las reuniones donde el equipo hace bastantes preguntas
para estimar y distribuir las tareas que se cumplirán durante el Sprint 3.

2.2.3.3.3.1. Release Planning 3


Tabla 6. Release Planning 3
Sprints Historia de Usuario Fecha propuesta
SPRINT 2 HU-13 16/11/20
SPRINT 2 HU-14 18/11/20

SPRINT 2 HU-15 20/11/20

SPRINT 2 HU-16 22/11/20

SPRINT 2 HU-17 24/11/20

SPRINT 2 HU-18 26/11/20

Fuente: Elaboración propia

2.2.3.3.3.2. Daily Standup Meetings 3


Tabla 7. Dally Standup Meetings 3
Sprint Participantes Fecha de reunión

Team Scrum – Dueño Del Negocio 18/11/20

Team Scrum – Dueño Del Negocio 23/11/20

Team Scrum – Dueño Del Negocio 25/11/02


1

Team Scrum – Dueño Del Negocio 27/11/20

Team Scrum – Dueño Del Negocio 29/11/20

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.3.3.4. Sprint Backlog 3
En los siguientes cuadros podemos también observar los detalles completos del Sprint 3, empezando por las historias de usuari os
y el cronograma de actividades establecidas en las reuniones dándonos esta gráfica del Burndown Chart
USER STORIES
Como administrador/vendedor necesito visualizar mis pedidos con la finalidad de ver todos los pedidos realizados.

Como administrador/vendedor necesito poder exportar mis pedidos con la finalidad de obtener el reporte completo y archivarlo.

Como cliente/administrador/vendedor necesito poder realizar un pago con la finalidad de obtener el producto pedido.

Como cliente necesito poder visualizar mis pedidos con la finalidad de saber cuántos pedidos he realizado.

Como administrador/vendedor /repartidor necesito poder ver el estado de los pedidos con la finalidad de poder atenderlos.

Como administrador/vendedor/repartidor necesito poder modificar el estado del pedido con la finalidad de poder controlar los pedidos que haya sido
pagado.

Días de implementación de Sprint 14 41


Horas o Puntos de usuario 41 14
Estado del Sprint Hecho

FECHA DE INICIO 16/11/2020


FECHA DE INICIO 29/11/2020

Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
DÍA 16 17 18 19 20 21 22 23 24 25 26 27 28 29 REAL
TAREA ESTIMADO
Planeación y Gestión de Historias de Usuario para el Sprint3

2 1 1 2
Desarrollo de la funcionalidad de pedido realizados para el
modelo de pedidos
1 1 1
Creación Funcional del modelo para exportar documentos
3 1 1 1 3
Creación Funcional del modelo de pagos

1 1 1
Desarrollo de la funcionalidad de pedidos realizados del
modelo de pedidos
1 1 1
Desarrollo de la funcionalidad de estados de pedidos
2 1 1 2
Desarrollo de la funcionalidad de los estados de pedidos
para modificar o controlar los pedidos
1 1 1
Verificación de Errores en el modelo de pagos
1 1 1
Verificación de Errores en los estados de pedidos
1 1 1
Pruebas del Desarrollo del Sistemas 1 1 1
revisión final del sprint 1 y 2 1 1 1
testeo final del programa hasta el sprint 3 0 0

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Burndown Chart
16
15
14 14
13
12
11
10 10

8 8
7
6 6
5
4 4
3
2 2
1
0 0 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Enlace del Archivo 3


https://drive.google.com/file/d/1ImiNygXzFRd1V9ff5KND53ZwoWwsSp8Y/view?usp=sharing
Fuente: Elaboración propia

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.3.3.5. Reunión Retrospectiva 3
En esta última fase realizamos la tercera reunión con el cliente mostrando el Sprint 3
terminado y las personas que asistieron.

Resumen de la
Reunión Retrospectiva 3
Información de la empresa y proyecto:
Tabla 8. Reunión Retrospectiva 3
Empresa / Panadería “La Unión”
Organización
Proyecto Proyecto De Aplicativo Web De Delivery
Panadería “La Unión”

Información de la reunión:

Lugar Videollamada Zoom

Fecha 29/11/20

Número de iteración / sprint 3

Team Scrum, Product Owner Y Dueño Del


Negocio
Personas Convocadas A La Reunión

Personas Que Asistieron A La Todas Las Personas Asistieron


Reunión

Fuente: Elaboración propia


49

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
2.2.4. Modelos de Base de Datos

Un modelo conceptuad identifica las relaciones de más alto nivel que incluye las
entidades importantes
y las relaciones entre ellas, no se especifica ningún atributo.

Modelo conceptual

Figura 3. UML

Fuente: Elaboración propia

2.2.4.1. Modelo de Base Datos Físico

El modelo de base de datos físico representa cómo se construirá el modelo de la


base de datos, en donde se muestra todas
Las estructuras de la tabla que incluye la clave primaria, los atributos y las relaciones
entre tablas.

50

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Las características de un modelo de datos físicos incluyen:

 Especificación de todas las tablas y columnas.

 Las claves externas se usan para identificar relaciones entre tablas.

Figura 4. Modelo Físico

Fuente: Elaboración propia

2.2.4.2. Modelo de Base Datos Lógico

Un modelo de base datos lógicos describe los datos con el mayor detalle posible,
independientemente de cómo se implementarán físicamente en la base de datos.
Las características de un modelo de datos lógicos:
 Incluye todas las entidades y relaciones entre ellos.

 Todos los atributos para cada entidad están especificados.

 La clave principal para cada entidad está especificada.

 Se especifican las relaciones entre diferentes entidades.

51

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Figura 5. Modelo Lógico

Fuente: Elaboración propia

2.3. Conclusiones.
 En conclusión hemos obtenido un sistema de cumple con los objetivos
propuestos, que el sistema optimize los recursos de la Panadería "La Unión",
mejorando los procesos del negocio y obteniendo un mayor ingreso económico
favorable en la empresa.
 La metodología Scrum nos ayudó a lo largo de todo el proyecto, ya que nos
estructura muy bien la funcionalidad del sistema, de la cual si habían cambios a
último momento esto no afectaría al éxito del proyecto, ya que esta metodología
es muy flexible a cambios.
 Utilizamos el modelo MVC (MODELO-VISTA-COTROLADOR) de la cual este
patrón de diseño nos ayudó a mantener ordenado la estructuración del proyecto
y de un fácil entendimiento cuando se realice un soporte.
 Este proyecto ayudo a la Panadería “La Unión” a recuperar terreno en el
mercado ya que anteriormente con el proceso de pedidos por teléfono no le daba

52

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
la confianza a sus clientes para adquirir su servicio, ahora con este proceso
automatizado ha comenzado aumentar su clientela y mejoras en tu rentabilidad.
 El sistema Web de la Panadería “La Unión” es un proyecto agradable de fácil
entendimiento para los trabajadores del negocio y para sus clientes.
 Por parte del Jefe General no tuvo ningún reclamo en el manejo del sistema ya
que es muy fácil de utilizarlo.

2.4. Sugerencias.

 Se sugiere implementar un módulo que realice facturación electrónica


 Se sugiere implementar protocolos de seguridad para el respaldo de la
información del negocio que se genera en la base de datos MySQL
 Se sugiere agregar un módulo de Promociones por temporada Navideña como
estrategia de negocio
 Se recomienda agregar un modelo de Reclamaciones por parte del perfil de
cliente
 Se sugiere integrar inteligencia de negocio al proyecto para poder visualizar el
rendimiento del negocio y que genere tomas de decisiones
 Se sugiere integrar un módulo de Solicitar Orneo , de la cual este módulo solo
estará disponible en temporada navideña y se encuentre en el perfil de cliente
para su solicitud y también en el admin para gestión este proceso
 Se sugiere mejorar el back-end Laravel a su ultimo versión

53

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)
Referencias Bibliográficas.
- Monte Galiano, J. (2016). Implantar scrum con éxito. Barcelona, Spain: Editorial
UOC. Recuperado de https://elibro.net/es/lc/biblioua/titulos/58575.
- Pavón Puertas, J. y Llarena Borges, E. (2015). Creación de un sitio web con
PHP y MySQL (5a. ed.). RA-MA Editorial. Recuperado de
https://elibro.net/es/lc/biblioua/titulos/106491.
- Orós Cabello, J. C. (2014). Diseño de páginas Web con XHTML, JavaScript y
CSS. RA-MA Editorial. Recuperado de
https://elibro.net/es/lc/biblioua/titulos/106414.
- Robledo, D. (2017). Desarrollo de aplicaciones para Android I. Madrid, Spain:
Ministerio de Educación de España. Recuperado de
https://elibro.net/es/lc/biblioua/titulos/49432.
- Mifsuf Talón, E. (2013). Apache. Madrid, Spain: Ministerio de Educación de
España. Recuperado de https://elibro.net/es/lc/biblioua/titulos/49359.
- B-CISC-PTG-1746-2020 Loor Muñoz Kevin Alexander - Villegas Salazar Diego
Armando.pdf
- Monte Galiano, J. (2016). Implantar scrum con éxito. Barcelona, Spain: Editorial
UOC. Recuperado de https://elibro.net/es/lc/biblioua/titulos/58575. - Sprint

54

Document shared on www.docsity.com


Downloaded by: yasel-ponce (ponceyasel@gmail.com)

También podría gustarte