UNIVERSIDAD NACIONAL DEL ALTIPLANO - PUNO

FACULTAD DE MECANICA ELÉCTRICA, ELECTRÓNICA Y

SISTEMAS

ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS

SISTEMA DE GESTIÓN COMERCIAL PARA LA TIENDA

DE ZAPATERÍA “LOS PINOS”- JULIACA

PRESENTADA POR:

YENME ROSSEL YUNGANINA FARFAN

CURSO DE: ADMINISTRACION DE ORGANIZACIONES POR SISTEMAS

DOCENTE: JOSE LUIS JUARES RUELAS

PUNO – PERÚ
2019
 ÍNDICE
ÍNDICE DE FIGURAS ....................................................................................................................... 4
ÍNDICE DE TABLAS ......................................................................................................................... 5
INTRODUCCIÓN ............................................................................................................................. 6
CAPÍTULO I .................................................................................................................................... 7
1. PLANTEAMIENTO DEL PROBLEMA. ....................................................................................... 7
1.1. DESCRIPCION DE LA SITUACIÓN COMERCIAL DE LA TIENDA “EL ZAPATON” ................ 7
1.1.1. PLANTEAMIENTO DEL PROBLEMA ........................................................................ 7
1.1.2. OBJETIVO GENERAL ................................................................................................... 8
1.1.3. OBJETIVO ESPECIFICO ............................................................................................... 8
1.1.4. AMBITO DEL SISTEMA ............................................................................................... 8
CAPÍTULO II ................................................................................................................................... 9
2. DESARROLLO DEL SISTEMA ................................................................................................... 9
2.1. REQUERIMIENTOS FUNCIONALES DEL SOFTWARE SEGÚN CLIENTE. ........................... 9
2.2. REQUERIMIENTOS NO FUNCIONALES DEL SOFTWARE. ................................................ 9
2.3. SPRINT PLANING: ............................................................................................................ 10
2.3.1. HISTORIAL DE USUARIO ...................................................................................... 10
2.4. PRIORIZACIÓN DE LAS HISTORIAS DE USUARIO SEGÚN PRODUCT OWNER: .............. 16
Personal Involucrado (Distribución de Roles) ......................................................................... 17
2.5. HISTORIA DE TAREAS DE CADA HISTORIA DE HISTORIA DE USUARIO POR PRIORIDAD:
18
2.5.1. Sprint Gestión de Usuarios .................................................................................. 18
2.5.2. Caso de uso: ........................................................................................................ 20
2.5.3. Diagrama de secuencia: ...................................................................................... 21
2.5.4. Diagrama de colaboración: ................................................................................. 21
2.5.5. Diagrama de clases: ............................................................................................. 22
2.6. Sprint Gestión de Producto ..................................................................................... 22
2.6.1. Caso de uso: ........................................................................................................ 23
2.6.2. Diagrama de secuencia: ...................................................................................... 24
2.6.3. Diagrama de colaboración: ................................................................................. 24
2.6.4. Diagrama de clases: ............................................................................................. 24
2.7. Sprint Gestión de Ventas ......................................................................................... 25
2.7.1. Caso de uso: ........................................................................................................ 26
2.7.2. Diagrama de secuencia: ...................................................................................... 27
2.7.3. Diagrama de colaboración: ................................................................................. 28
2.7.4. Diagrama de clases: ............................................................................................. 28
 2.8. ESTIMACION DE LOS PRODUCT BACKLOG .................................................................. 28
2.8.1. Estimación por el método planning pocker: ....................................................... 29
2.8.2. Planning scrum según criterio de método kamba. ............................................. 30
CAPÍTULO III ................................................................................................................................ 31
3. EJECUCIÓN DE SPRINTS ....................................................................................................... 31
3.1. SPRINT 1 GESTION DE USUARIO:................................................................................. 31
3.1.1. Daily meeting....................................................................................................... 31
3.1.2. Burdown chart:.................................................................................................... 32
3.2. SPRINT PLANING SPRINT GESTION DE PRODUCTO: ........................................................ 32
3.2.1. RETROSPECTIVA: ................................................................................................. 32
3.2.2. Planning sprint: ................................................................................................... 32
3.2.3. Propuesto ............................................................................................................ 33
3.2.4. Nuevo cuadro de puntuación y sprint ................................................................. 33
3.2.5. Burdown chart ..................................................................................................... 33
3.2.6. Daily meeting....................................................................................................... 34
3.3. SPRINT PLANING SPRINT GESTION DE VENTAS:.............................................................. 34
3.3.1. RETROSPECTIVA: ................................................................................................. 34
3.3.2. Planning sprint: ................................................................................................... 35
3.3.3. Propuesto ............................................................................................................ 35
3.3.4. Nuevo cuadro de puntuación y sprint ................................................................. 35
3.3.5. Burdown chart ..................................................................................................... 36
3.3.6. Daily meeting....................................................................................................... 36
3.3.7. Diagrama de clases de la base de datos del sistema de ventas de zapatos “Los
Pinos” 37
ÍNDICE DE FIGURAS
Figura N° 1: Caso de uso ............................................................................................................. 20
Figura N° 2: Diagrama de secuencia ........................................................................................... 21
Figura N° 3: Diagrama de colaboración ...................................................................................... 21
Figura N° 4: Diagrama de clases ................................................................................................. 22
Figura N° 5: Caso de uso del administrador ............................................................................... 23
Figura N° 6: Diagrama de secuencia del administrador ............................................................. 24
Figura N° 7: Diagrama de colaboración del administrador ........................................................ 24
Figura N° 8: Diagrama de clases del administrador ................................................................... 24
Figura N° 9: Caso de uso búsqueda de series............................................................................. 26
Figura N° 10: Caso de uso búsqueda de series dos .................................................................... 26
Figura N° 11: Diagrama de secuencia serie ................................................................................ 27
Figura N° 12: Diagrama de secuencia ......................................................................................... 27
Figura N° 13: Diagrama de colaboración .................................................................................... 28
Figura N° 14: Diagrama de clases ............................................................................................... 28
Figura N° 15: Análisis de la puntuación de cada módulo -Sprint ............................................... 29
Figura N° 16: Análisis de la puntuación de cada módulo -Sprint 2 ............................................ 29
Figura N° 17: Análisis de la puntuación de cada módulo -Sprint 3 ............................................ 30
Figura N° 18: Apreciación del Burdown chart ............................................................................ 32
Figura N° 19: Apreciación del Burdown chart ........................................................................... 33
Figura N° 20: Apreciación de Burdown chart ............................................................................. 36
Figura N° 21: Diagrama de clases de la base de datos del sistema ............................................ 37
ÍNDICE DE TABLAS
Tabla N° 1: Historial uno............................................................................................................. 10
Tabla N° 2: Historial dos ............................................................................................................. 11
Tabla N° 3: Historial tres............................................................................................................. 12
Tabla N° 4: Historial cuatro ........................................................................................................ 13
Tabla N° 5: Historial cinco .......................................................................................................... 15
Tabla N° 6: Historial seis ............................................................................................................. 16
Tabla N° 7: Historial de Product Owner .................................................................................... 16
Tabla N° 8: Distribución de roles ................................................................................................ 17
Tabla N° 9: segunda distribución de roles .................................................................................. 17
Tabla N° 10: Tercera distribución de roles ................................................................................. 17
Tabla N° 11: Cuarta distribución de roles................................................................................... 18
Tabla N° 12: Quinta distribución de roles .................................................................................. 18
Tabla N° 13: Desarrollo del Sprint de usuario ............................................................................ 18
Tabla N° 14: Desarrollo del Sprint del usuario dos..................................................................... 19
Tabla N° 15: Desarrollo del Sprint del usuario tres .................................................................... 19
Tabla N° 16: Desarrollo del sprint cuatro ................................................................................... 19
Tabla N° 17: Desarrollo del sprint cinco ..................................................................................... 20
Tabla N° 18: Desarrollo del Sprint Gestión de Producto ............................................................ 22
Tabla N° 19: Desarrollo del Sprint Gestión de Producto dos ..................................................... 23
Tabla N° 20:Desarrollo del Sprint Gestión de Producto tres ...................................................... 23
Tabla N° 21: Desarrollo del Sprint para gestión de ventas......................................................... 25
Tabla N° 22: Desarrollo del Sprint para gestión de ventas dos .................................................. 25
Tabla N° 23: Desarrollo del Sprint para gestión de ventas tres ................................................. 25
Tabla N° 24: Puntuación de los sprints....................................................................................... 30
Tabla N° 25: Programación de Daily meeting............................................................................. 31
Tabla N° 26: Puntuación de los nuevos atributos del sprints..................................................... 32
Tabla N° 27: Cuadro de puntuacion-Sprint ................................................................................ 33
Tabla N° 28: Cuadro de puntuación y Sprint .............................................................................. 33
Tabla N° 29: Cronograma Daily meeting .................................................................................... 34
Tabla N° 30: Puntuación de Planning sprint ............................................................................... 35
Tabla N° 31: Puntuación de sprint.............................................................................................. 35
Tabla N° 32: Puntuación de sprint.............................................................................................. 35
Tabla N° 33: Cronograma de Daily meeting ............................................................................... 36
 INTRODUCCIÓN
En el presente trabajo se describirá el análisis y desarrollo del Sistema de ventas
de Zapato para la empresa “Los Pinos”. Guiándonos con la metodología de
trabajo SCRUM para la gestión del desarrollo del sistema, usando los pasos
descritos en el Marco Teórico.
También se describirá cada ciclo de vida iterativo e incremental del proyecto, los
artefactos o documentos con los que se gestionan las tareas de adquisición y
suministro: requisitos, monitorización y seguimiento del avance, así como las
responsabilidades y compromisos de los participantes en el proyecto.

La empresa sin procesos bien diseñados y sistemas de información de apoyo, la

organización nos será capaz de competir, utilizaremos la metodología SCRUM
para la gestión del desarrollo del sistema.
La tienda “Los Pinos” se encarga de brindar el servicio de venta de zapatos a la
población en general, zapatos de diferentes tipos de tallas y modelos.

El actual proceso de ventas y el inventariado en la tienda se realiza

manualmente. Es por ello que se decidió desarrollar un software para dicha
organización con el fin de que esta tienda pueda Gestionar sus procesos ya
antes mencionados.
 CAPÍTULO I
1. PLANTEAMIENTO DEL PROBLEMA.

1.1. DESCRIPCION DE LA SITUACIÓN COMERCIAL DE LA TIENDA

“EL ZAPATON”
En la actualidad las tecnologías de información han aumentado y
evolucionado rápidamente y esto conlleva a que toda entidad que haga
manejo de una gran cantidad de información, tenga que encontrar la forma
de organizarla y controlar eficientemente.

Hoy en día, resulta casi indiscutible que la información cumple papel

fundamental en toda la empresa para su adecuado funcionamiento. El
presente Proyecto del Sistema de venta de Zapato para la tienda “Los Pinos”,
empresa dedicada a la venta de zapatos, con el objetivo de automatizar los
procesos en ventas ya que en gestiones pasadas dichos procesos se hacían
de forma manual.

En el presente documento se dará una explicación de cómo se hará el

análisis y desarrollo se dará solución a los problemas de esta empresa,
comenzando con la identificación de los requerimientos de los usuarios. Una
explicación de las herramientas a utilizarse y finalmente la forma en que se
hará uso de estas herramientas para lograr un sistema confiable y eficiente.

El resultado de este proyecto de implementación de un sistema, será el de

lograr que la empresa logre una gran evolución en el ámbito de la
información, todo esto repercutirá para hacer que más empresas requieran
de esta herramienta tan indispensable.

Para el desarrollo del proyecto se utilizó la metodología Ágil SCRUM, que

propone un modelo de proceso incremental, basado en iteraciones y
revisiones continuas.

Para la conclusión del desarrollo de sistema Web se utilizará como

herramienta primordial el lenguaje de programación PHP, con el gestor de
base de datos MySQL.

1.1.1. PLANTEAMIENTO DEL PROBLEMA

La Zapatería “El Pino”, Ubicado en la provincia de Juliaca y
departamento de Puno. La zapatería no cuenta con ningún sistema para
el proceso de ventas.

El manejo de la venta se realiza de forma manual donde el control de los

productos, genera una situación problemática a la hora de sacar cuentas
mensuales.
1.1.2. OBJETIVO GENERAL
Desarrollar un Sistema de gestión comercial para la tienda “El Pino”

1.1.3. OBJETIVO ESPECIFICO

 Utilizar la metodología SCRUM y ayudarnos con otras
metodologías agiles para el desarrollo del sistema comercial
para la tienda “El Pino”.
 Realizar todo el análisis de los procesos que se realizan en la
tienda “El Pino”.

1.1.4. AMBITO DEL SISTEMA

El sistema hará un proceso más eficaz en la venta y el inventariado de
los productos.

Gracias a este sistema se obtendrán grandes resultados en manejo

sistemático de ventas por que se tendrá un mejor manejo por parte del
administrador y beneficiará a los clientes a una mejor atención.
 CAPÍTULO II
2. DESARROLLO DEL SISTEMA

2.1. REQUERIMIENTOS FUNCIONALES DEL SOFTWARE SEGÚN

CLIENTE.

 El sistema mostrará un menú dando cada una de las posibilidades

del sistema.
 El sistema deberá enviar uno de estos archivos (XML, TXT, JSON)
en formato digital al facturador de SUNAT.
 El sistema debe recibir la constancia validada o rechazada del
facturador de SUNAT.
 El sistema debe otorgar una factura al cliente receptor con los
detalles de la compra.
 El sistema tendrá dos tipos de usuario administrador y vendedor.
 El administrador creara, eliminar, editara y consultara usuarios.
 El sistema deberá solicitar al administrador un usuario al momento
de ingresar al sistema.
 El sistema deberá solicitar al administrador un usuario al momento
de ingresar al sistema.
 El sistema deberá solicitar al vendedor un usuario al momento de
ingresar al sistema.
 El sistema deberá solicitar al vendedor una contraseña al momento
de ingresar al sistema.
 El sistema deberá mostrar los productos por categoría (tallas,
modelos, por edades, genero) disponible para los clientes.
 El sistema mostrara al administrador la cantidad de productos
como los detalles de cada producto.
 El sistema permitirá al administrador buscar, agregar, editar,
eliminar, productos del sistema.
 El sistema permitirá elaborar y emitir reportes de las diferentes
ventas que se realizaron.

2.2. REQUERIMIENTOS NO FUNCIONALES DEL SOFTWARE.

 El usuario debe tener el sistema instalado para poder utilizar el

sistema.
 El sistema será desarrollado en los programas XAMPP, código
html5.
  El sistema deberá funcionar en distintos tipos de sistemas
operativos (multiplataforma) como Windows 7, Windows 8
Windows 10.
 El desempeño del sistema no presentará problemas
(homogenización de datos) para el manejo o implementación de
información
 El administrador podrá de modificar la información almacenada en
la base de datos.
 El rendimiento del sistema deberá soportar el manejo de una gran
cantidad de información durante el proceso.
 El sistema debe ser fácil de usar con la ayuda de interfaces
intuitivas (usabilidad).
 La capacidad y tiempo de respuesta deberá ser menor a diez
segundos.
 El sistema deberá tener un mantenimiento de actualización de
información semestral.
 El aprendizaje sobre el uso del sistema por un usuario deberá ser
menor a 4 horas.
 El sistema debe contar con manuales de usuario estructurados
adecuadamente.
 El sistema debe de ser amigable entendible, aceptable y fácil de
usar para los clientes de da zapatería.

2.3. SPRINT PLANING:

2.3.1. HISTORIAL DE USUARIO

Tabla N° 1: Historial uno

Historial de usuario

Id 01

Nombre Gestión de usuarios

Prioridad 1

Riesgo Alta
Descripción Administrador y empleados controlan el sistema, para
agregar nuevos productos al sistema.
Realizara los cambios modificaciones de un producto
para su posterior venta
Condiciones  El logo de la zapatería tiene que estar presente al
ingresar a este módulo en la parte superior izquierda.
 El logueo debe permitir el uso de caracteres especiales
como la “ñ”.
 El sistema debe tener la opción de recordar contraseña
 El loguin de administrador y empleados debe ser visible
en todo momento junto con la fecha y hora del último
ingreso.
 Debe existir una pequeña barra de actividades a la
derecha de la página para ver la actividad realizada.
 Debe de haber una opción para poder visualizar a los
proveedores y perderlos contactar en caso de olvidos.
 El sistema debe alertar la falta de recursos y sugerir
adquirir.
 Debe de gestionar y guardar las actividades realizadas.

Tabla N° 2: Historial dos

Historial de usuario

Id 02

Nombre Gestión de clients

Prioridad 05

Riesgo Alta

Descripción El cliente se registrará y podrá realizar la compra

de un producto. Podrá realizar la pre compra de un
producto, también podrá poder pagar en cuotas.
Condiciones  El logo de la zapatería tiene que estar
presente al ingresar a este módulo en la
parte superior izquierda.
  El logueo debe permitir el uso de caracteres
especiales como la “ñ”.
 El sistema debe tener la opción de recordar
contraseña.
 El sistema debe permitir la opción de pagar
por distintos medios.
 El sistema debe mostrar en un cuadro
atractivo y vistoso las ofertas que se
publicaron.
 El sistema debe de tener la opción de
comunicar y sugerir sus opiniones.
 Debe de existir un cuadro de actividades
del cliente.
 Debe poder guardar adquisiciones
realizadas de acuerdo a ellas sugerir
producto.
 El sistema debe de permitir poner
puntuaciones a sus compras.
 El sistema debe de tener un lugar en la
parte inferior izquierda para realizar
marketing de proveedores.

Tabla N° 3: Historial tres

Historial de usuario

Id 03

Nombre Gestión productos

Prioridad 2

Riesgo Alta

Descripción - Introducir nuevos artículos en el sistema.

- Los artículos deben agruparse por su tipología.
- Cada artículo tiene asociado un precio de venta.
- Los datos almacenados se pueden modificar
posteriormente.
Condiciones  El logo de la zapatería tiene que estar
presente al ingresar a este módulo en la
parte superior izquierda.
  El registro debe permitir introducir
caracteres especiales.
 Debe existir una pequeña barra de
actividades a la derecha de la página para
ver la actividad realizada.
 Debe de haber una opción para poder
visualizar a los proveedores y perderlos
contactar en caso de olvidos.
 El sistema debe alertar la falta de recursos
y sugerir adquirir.
 El sistema debe tener la opción de poner en
oferta algunos artículos.
 Debe de gestionar y guardar las actividades
realizadas.
 El sistema debe de ser capaz de clasificar
un artículo ingresado de manera
automática sin errores.
 El sistema debe de mostrar en forma de
alerta la actividad que se realizó.
 El sistema debe de tener la opción de
recuperar datos borrados sin perjudicar el
almacén.
 El sistema debe de tener una interfaz que
no sea estresante ni desconcéntrate para el
administrador.

Tabla N° 4: Historial cuatro

Historial de usuario

Id 04

Nombre Gestión ventas

Prioridad 3

Riesgo Alta
Descripción Se debe poder registrar la venta realizada de un
artículo también debe de estar ordenado y al
realizar la venta el almacén debe de actualizarse
Condiciones  El logo de la zapatería tiene que estar
presente al ingresar a este módulo en la
parte superior izquierda.
 El registro debe permitir introducir
caracteres especiales.
 El sistema debe guardar RUC o DNI con la
cual se realizó la compra para ofrecer
ofertas.
 Los datos guardados del cliente deben de
ser actualizadas cada mese “borrar si no
compro en este mes si compro realizar
oferta”.
 Registrar venta forma de pago que se
realizó.
 La transacción debe de ser segura en caso
de usar pago con tarjeta.
 Debe de haber una opción para introducir
comentarios de los clientes “una opción
para ingresar sugerencias de producto”.
 Las ventas deben de ser guardadas sin
errores para realizar reportes.
 Los artículos deben agruparse por su
tipología.
 Cada artículo tiene asociado un precio de
venta.
 Los datos almacenados se pueden
modificar posteriormente.
 El almacén debe de actualizar los
productos que se vendieron.
 El sistema debe tener la opción de
descomprar y regresar al almacén los
artículos comprados.
 Tabla N° 5: Historial cinco

Historial de usuario

Id 05

Nombre Gestión de reportes

Prioridad 4

Riesgo Media

Descripción Obtener información concreta y detallada de cómo

y cuánto se vendió durante un día.
Tamicen un informe de que artículos fueron más
vendidos, y la posibilidad de ver el estado del
almacén y si existe la necesidad de adquirir
nuevos productos.
 Antes de tener los reportes virtuales el
sistema debe de solicitar a manera de
Condiciones seguridad nombre completo y cuenta
registrada directamente te en la base de
datos y contraseña.
 El reporte debe de ser mostrado con el
nombre del solicitante, fecha, hora.
 Guardar esta actividad realizada.
 Realizar reporte de las ventas del día.
 Almacenara todos los datos para modificar
posteriormente
 Generar backup de todos los gastos
realizados en el día.
 Generar un reporte de los empleados del
local, también del administrador.
 Recoger información necesaria de cada
área para realizar un reporte a la zapatería.
 Tabla N° 6: Historial seis

Historial de usuario

Id 06

Nombre Gestión de facturas

Prioridad 6

Riesgo Alta

Descripción El usuario administrador y cajero podrán consultar

la factura del cliente en donde se detallan los
pedidos del producto y el total a pagar.
Condiciones  La facture debe mostrar el logo de la
zapatería.
 Debe mostrar información del cliente de la
zapatería.
 Debe mostrar el ruc la tienda, así como
información de la tienda necesaria para
encontrar.
 De acuerdo a las compras realizadas
verificadas por el DNI o ruc imprimir una
oferta especial para el cliente.
 Mostrar detalles de la compra
 Imprimir factura en cuadros para mejor
entendimiento de lo adquirido.

2.4. PRIORIZACIÓN DE LAS HISTORIAS DE USUARIO SEGÚN

PRODUCT OWNER:
Tabla N° 7: Historial de Product Owner

HISTORIA DE USUARIO PRIORIDAD

Gestión de usuario Alta (1)
Gestión product Alta (2)
Gestión de ventas Alta (3)
Gestión de reports Media (4)
Gestión de cliente Media (5)
Gestión de facturas Baja (6)
Personal Involucrado (Distribución de Roles)
Tabla N° 8: Distribución de roles

NOMBRE Rossel Yunganina Farfan

ROL Product Owner

CATEGORIA PROFESIONAL Estudiante

RESPONSABILIDAD Planificador, Analista

INFORMATION DEL CONTACTO

Tabla N° 9: segunda distribución de roles

NOMBRE Juan Perez

ROL Developer

CATEGORIA PROFESIONAL Estudiante

RESPONSABILIDAD Programadores

INFORMATION DEL CONTACTO

Tabla N° 10: Tercera distribución de roles

NOMBRE Jose Ramos

ROL Developer

CATEGORIA PROFESIONAL Estudiante

RESPONSABILIDAD Programadores

INFORMATION DEL CONTACTO

 Tabla N° 11: Cuarta distribución de roles

NOMBRE Edy Condori

ROL Developer

CATEGORIA PROFESIONAL Estudiante

RESPONSABILIDAD Desarrollador

INFORMATION DEL CONTACTO

Tabla N° 12: Quinta distribución de roles

NOMBRE Mario Rozales

ROL Scrum Master

CATEGORIA PROFESIONAL Estudiante

RESPONSABILIDAD Planificador, Analista

INFORMATION DEL CONTACTO

2.5. HISTORIA DE TAREAS DE CADA HISTORIA DE HISTORIA DE

USUARIO POR PRIORIDAD:
2.5.1. Sprint Gestión de Usuarios
Tareas:
Tabla N° 13: Desarrollo del Sprint de usuario
Tabla N° 14: Desarrollo del Sprint del usuario dos

Tabla N° 15: Desarrollo del Sprint del usuario tres

Tabla N° 16: Desarrollo del sprint cuatro

 Tabla N° 17: Desarrollo del sprint cinco

2.5.2. Caso de uso:

Figura N° 1: Caso de uso

2.5.3. Diagrama de secuencia:

Figura N° 2: Diagrama de secuencia

2.5.4. Diagrama de colaboración:

Figura N° 3: Diagrama de colaboración

 2.5.5. Diagrama de clases:

Figura N° 4: Diagrama de clases

2.6. Sprint Gestión de Producto

Tareas:
Tabla N° 18: Desarrollo del Sprint Gestión de Producto
 Tabla N° 19: Desarrollo del Sprint Gestión de Producto dos

Tabla N° 20: Desarrollo del Sprint Gestión de Producto tres

2.6.1. Caso de uso:

Figura N° 5: Caso de uso del administrador

2.6.2. Diagrama de secuencia:

Figura N° 6: Diagrama de secuencia del administrador

2.6.3. Diagrama de colaboración:

Figura N° 7: Diagrama de colaboración del administrador

2.6.4. Diagrama de clases:

Figura N° 8: Diagrama de clases del administrador

2.7. Sprint Gestión de Ventas
Tareas:
Tabla N° 21: Desarrollo del Sprint para gestión de ventas

Tabla N° 22: Desarrollo del Sprint para gestión de ventas dos

Tabla N° 23: Desarrollo del Sprint para gestión de ventas tres

2.7.1. Caso de uso:

Figura N° 9: Caso de uso búsqueda de series

Figura N° 10: Caso de uso búsqueda de series dos

2.7.2. Diagrama de secuencia:

Figura N° 11: Diagrama de secuencia serie

Figura N° 12: Diagrama de secuencia

 2.7.3. Diagrama de colaboración:

Figura N° 13: Diagrama de colaboración

2.7.4. Diagrama de clases:

Figura N° 14: Diagrama de clases

2.8. ESTIMACION DE LOS PRODUCT BACKLOG

Según el product owner cada sprint debe de ser realizado en un periodo de
entre mínimo 1 semana y como máximo 3 semanas. Según conversaciones
con el cliente para verificar el funcionamiento de los resultados de cada
sprint.
2.8.1. Estimación por el método planning pocker:
Se usó la serie de Fibonacci para realizar la estimación de esfuerzo (0,
1, 2, 3, 5, 8, 13, 20, 40, 10, ?).
La participación de los developers, scrum master y product owner se
llegó a las siguientes conclusiones de puntuación. Solo para los 3 sprints
que tienen prioridad alta. Mediante el análisis de la puntuación de cada
módulo que tendrá cada sprint.

Figura N° 15: Análisis de la puntuación de cada módulo -Sprint

Figura N° 16: Análisis de la puntuación de cada módulo -Sprint 2

 Figura N° 17: Análisis de la puntuación de cada módulo -Sprint 3

DATO: al ser los developers nuevos en la forma de trabajar en el método

scrum

 no se realizará una medición para el tiempo de ejecución de sprint

de acuerdo a la experiencia que tienen porque sería echar a la
suerte.
 La medición se realizará en la forma en la cual se trabaja en el
método kamba, pero poniendo un límite de tiempo de 3
semanas como coordinó el product owner.
 Para el análisis se escogió entre los tres primarios o de alta
prioridad el que se encuentra en la mitad de puntuación de esfuerzo
el sprint “gestión de usuario”.
 para ello se diseñó un kamba de ejecución con sin límites de
tiempo, pero sí en que tiempo se inició y termino.

2.8.2. Planning scrum según criterio de método kamba.

Según el sprint “gestión de usuario” que tiene 20 puntos se puede
deducir lo siguiente:
Tabla N° 24: Puntuación de los sprints

Sprint Prioridad Puntuación Tiempo

Gestión de usuario Alta (1) 20 10 días
Gestión de product Alta (2) 26 13 dias
Gestión de ventas Alta (3) 16 8 dias
 CAPÍTULO III
3. EJECUCIÓN DE SPRINTS

3.1. SPRINT 1 GESTION DE USUARIO:

3.1.1. Daily meeting.
Tabla N° 25: Programación de Daily meeting

Día Inconveniente
1  Ubicación de software.
 Ubicación de personal.
2  El Sistema debería tener términos y condiciones de uso
(agregar en siguiente sprint).
 El sistema debería tener un cuadro de ayuda (agregar en sgte
sprint)
3  Ningún inconveniente.
4  Presión por parte de uno de los developers.
 Falta de control en llegada de todos los integrantes del
equipo scrum.
5  El sistema debe permitir registrar con cuentas en redes
sociales (agregar en sgte sprint).
 El sistema debe permitir registrar con un número de teléfono
(agregar en sgte sprint).
 El sistema debe tener ayuda en forma de video para crear
usuario (agregar en sgte sprint).
6  Presión por el product owner.
 Poca aparición del master scrum
7  Ningún inconveniente
8  Product owner intente revisar todo el product en el día sin
reunión general.
 3.1.2. Burdown chart:

Figura N° 18: Apreciación del Burdown chart

3.2. SPRINT PLANING SPRINT GESTION DE PRODUCTO:

3.2.1. RETROSPECTIVA:
Según las observaciones que se dieron en el anterior sprint para agregar
al sistema que se desarrolla se ampliara el tiempo de entrega del
siguiente sprint según puntuación de nuevas condiciones y atributos a
implementar

3.2.2. Planning sprint:

Puntuación de los nuevos atributos a implementar a sprint.
Tabla N° 26: Puntuación de los nuevos atributos del sprints

 El Sistema debería tener términos y condiciones de 1 punto

uso
 El sistema debería tener un cuadro de ayuda 1 punto

 El sistema debe permitir registrar con cuentas en 1 punto

redes sociales
 El sistema debe permitir registrar con un número
de teléfono

 El sistema debe tener ayuda en forma de video 2 puntos

para crear usuario

Total puntos al aumentar 5

Se produce un incremento en los puntos para implementar el sprint.

3.2.3. Propuesto

Tabla N° 27: Cuadro de puntuación-Sprint

Sprint Prioridad Puntuación Tiempo

Gestión de usuario Alta (1) 20 10 dias
Gestión de producto Alta (2) 26 13 dias
Gestión de ventas Alta (3) 16 8 dias

3.2.4. Nuevo cuadro de puntuación y sprint

Tabla N° 28: Cuadro de puntuación y Sprint

Sprint Prioridad Puntuación Tiempo

Gestión de usuario Alta (1) 20 10 dias
Gestión de product Alta (2) 31 15.5 dias
Gestión de ventas Alta (3) 16 8 dias

3.2.5. Burdown chart

Figura N° 19: Apreciación del Burdown chart

 3.2.6. Daily meeting.

Tabla N° 29: Cronograma Daily meeting

Día Inconveniente
1  Ningún inconveniente
2  Ningún inconveniente.
3  El sistema debería de tener un ranking de marcas más vendidas
(agregar en sgte sprint).
 El sistema debería de permitir ingresar el beneficio de algunos
productos nuevos (agregar en sgte sprint).
 El sistema debería de poner un símbolo a la imagen del producto
indicando que es nueva marca (agregar en sgte sprint).
4  Presencia de product owner.
5  Ningún inconveniente.
6  El sistema debe no debe permitir símbolos como “%$|”
implementar el sgte día compromiso developers Edilberto autorizo
product owner y master scrum.
7  Se demoró implementar el compromiso del día anterior pero se
cumplió.
8  El inconveniente del día anterior no retraso nada.
 Sugerencia mejor implementar las observaciones en el Daily
meeting en el siguiente sprint.
9  Ningún inconveniente.
10  Presión de producto owner para cumplir día.
 Retraso por parte de product owner al querer revisar todo.
11  Un poco de retraso por el inconveniente de ayer.
12  Se regulo el tiempo de trabajo.
13  Ningún inconveniente.
14  Para terminar rápido se quedaron la mayoría más tiempo para la
entrega de mañana.
15  Se entregó normal el sprint.

3.3. SPRINT PLANING SPRINT GESTION DE VENTAS:

3.3.1. RETROSPECTIVA:
Según las observaciones que se dieron en el anterior sprint para agregar
al sistema que se desarrolla se ampliara el tiempo de entrega del
siguiente sprint según puntuación de nuevas condiciones y atributos a
implementar
3.3.2. Planning sprint:
Puntuación de los nuevos atributos a implementar a sprint.
Tabla N° 30: Puntuación de Planning sprint

 El sistema debería de tener un ranking de 2punto

marcas más vendidas.
 El sistema debería de poner un símbolo a la
imagen del producto indicando que es nueva
marca.
 El sistema debería de permitir ingresar el 2 punto
beneficio de algunos productos nuevos
(agregar en sgte sprint).
 Total puntos a aumentar 4

Se produce un incremento en los puntos para implementar el sprint.

3.3.3. Propuesto

Tabla N° 31: Puntuación de sprint

Sprint Prioridad Puntuación Tiempo

Gestión de usuario Alta (1) 20 10 dias
Gestión de producto Alta (2) 26 13 dias
Gestión de ventas Alta (3) 16 8 dias

3.3.4. Nuevo cuadro de puntuación y sprint

Tabla N° 32: Puntuación de sprint.

Sprint Prioridad Puntuación Tiempo

Gestión de usuario Alta (1) 20 10 dias
Gestión de producto Alta (2) 26 13 dias
Gestión de ventas Alta (3) 20 10 dias
3.3.5. Burdown chart

Figura N° 20: Apreciación de Burdown chart

3.3.6. Daily meeting.

Tabla N° 33: Cronograma de Daily meeting

Dia Inconveniente
1  Developers Edilberto enfermo no asistió hoy día.
 Se sobrecargo trabajo a máximo.
2  Desubicación por parte de Edilberto no sabía cómo
empezar ni que modulo hacer “falta de comunicación con
los compañeros”.
3  Se trabajó normal pese a los inconvenientes del anterior día
se logró igualar el trabajo.
4  Ningún inconveniente
5  Ningún inconveniente.
6  Es sistema debería de analizar a un usuario con DNI o RUC
denominándolo con colores de verde a rojo para ofertarle
producto al momento de comprar (consulta product owner a
cliente para implementar).
7  No se implementó sugerencia de ayer se esperó 2 horas
para respuesta de product owner.
 Producto owner pensó que se realizaría en el sgte sprint.
8  Durante el sprint no hubo presión por parte del product
owner.
9  Ningún inconveniente.
10  Se entregó sin problemas.
3.3.7. Diagrama de clases de la base de datos del sistema de
ventas de zapatos “Los Pinos”

Figura N° 21: Diagrama de clases de la base de datos del sistema