UPN FACULTAD DE INGENIERIA

“Sistema Web para La empresa Tootus”

Integrantes: Camasca Torres Erickson - N00168320

Castro Jeremy - N00063329

Javier Meza Bryan – N00174403

Pablo Luis Medina Tapara - N00168320

Docente: Hector Hernan Henriquez Taboada

Carrera profesional: Ingeniería de sistemas computacionales

Curso: Calidad Y Pruebas De Software
Clase: 7129
Ciclo: VIII

LIMA- PERÚ
2021
UPN FACULTAD DE INGENIERIA

CAPITULO I:

1. GENERALIDADES:
1.1. Titulo del trabajo de campo:
1.2. Descripción de la empresa:
Tootus ofrece una gran variedad de productos, la cadena de mercados más
grande del Perú. De esta manera usted y su familia pueden acceder a los
mejores productos, brindándoles el mejor servicio en atención al cliente.
Todos nuestros productos son supervisados por los mejores profesionales en
alimentación de salud.
1.3. Misión y Visión de la empresa
1.3.1.Misión: - Lograr la satisfacción y confianza de nuestros clientes y colaboradores.
1.3.2.Visión: Mantenernos como la cadena de supermercados más grande del país, con
personal altamente capacitado, motivado y apoyado en tecnología de punta.
1.4. Organigrama:
UPN FACULTAD DE INGENIERIA

CAPITULO II:

2. PROBLEMÁTICA
2.1. Planteamiento del problema y descripción
2.1.1.Problema General
2.1.1.1. Optimizar el funcionamiento del negocio tomando en cuenta los
procesos de compra y venta de los productos que se ofrecen en el
supermercado tootus.
2.1.2.Problemas específicos
2.1.2.1. Incrementar el índice de clientes
2.1.2.2. Aumentar las ventas.
2.1.2.3. Disminuir el tiempo de atención por cliente.
2.2. Objetivos
2.2.1.Objetivos General
2.2.1.1. Desarrollar un sistema para optimizar el proceso de ventas y compras
de supermercados tootus.
2.2.2.Objetivos Específicos
2.2.2.1. Aumentaremos el índice de clientes en un 30%
2.2.2.2. Aumentar el índice de ventas en un 25%
2.2.2.3. El tiempo tendrá un decrecimiento por cliente del 30%
3. Marco Teórico de Referencia
3.1. Proceso de Atención
Esta conceptualización del proceso de atención médica pone de manifiesto su
carácter de objeto de aprendizaje para el estudiante de Medicina. Por ello, surge la
necesidad de contar con un modelo orientador que sirva de referencia tanto a
alumnos como a profesores para guiar este proceso de enseñanza-aprendizaje.
3.2. Ingeniería de Software
La ingeniería de software es una disciplina de
ingeniería que se preocupa por todos los aspectos de la producción de software
UPN FACULTAD DE INGENIERIA

desde las primeras etapas del sistema especificación hasta el mantenimiento del
sistema después de que ha entrado en uso.
3.3. Sistema Web
Los sistemas Web o también conocido como aplicaciones Web son aquellos que están
creados e instalados no sobre una plataforma o sistemas operativos (Windows,
Linux). Sino que se alojan en un servidor en Internet o sobre una intranet (red local).
Su aspecto es muy similar a páginas Web que vemos normalmente, pero en realidad
los ‘sistemas Web’ tienen funcionalidades muy potentes que brindan respuestas a
casos particulares.
3.4. Servidor
Es un aparato informático que almacena, distribuye y suministra información. Los
servidores funcionan basándose en el modelo “cliente-servidor”. El cliente puede ser
tanto un ordenador como una aplicación que requiere información del servidor para
funcionar. Por tanto, un servidor ofrecerá la información demandada por el cliente
siempre y cuando el cliente esté autorizado. Los servidores pueden ser físicos o
virtuales.
3.5. SSL
El Nivel de Conectores Seguros (Secure Sockets Layer o SSL) fue el protocolo de
cifrado más ampliamente utilizado para garantizar la seguridad de las comunicaciones
a través de Internet antes de ser sustituido por el TLS (inglés) (Seguridad de la Capa de
Transporte, o Transport Layer Security) en 1999. Aunque el desuso del protocolo SSL
dio paso a la adopción del TLS, la mayoría de las personas sigue refiriéndose a este
tipo de tecnología como «SSL».
3.6. Metodología SCRUM
La metodología Scrum permite abordar proyectos complejos desarrollados en
entornos dinámicos y cambiantes de un modo flexible. Está basada en entregas
parciales y regulares del producto final en base al valor que ofrecen a los clientes.
Dicho en otras palabras: Scrum sirve para mejorar el trabajo colaborativo entre
equipos.
3.7. Artefactos de SCRUM
Los artefactos son todos los elementos que te garantizan la transparencia y el registro
de la información fundamental del proceso de Scrum. Es decir, son los recursos que
cimientan la productividad y la calidad de cualquier proyecto, por ejemplo:

3.7.1.Product backlog
Es una lista ordenada con todo lo que necesita un producto para cumplir las
necesidades de los clientes potenciales y única fuente de requisitos para realizar
modificaciones en el.
3.7.2. Sprint backlog
Es un subconjunto de elementos del PB elegidos para abordarse en el peridodo
de tiempo o sprint mas un plan para ofrecerlos como incremento del producto y
lograr el objetivo del sprint.
3.7.3. Incremento
Se trata del resultado del sprint; un entregable utilizable y potencialmente
despegable.
UPN FACULTAD DE INGENIERIA

3.8. Eventos de Scrum

3.8.1.Sprint
El desarrollo del producto es realizado en iteraciones sucesivas denominadas
Sprint. Cada Sprint debe declarar un objetivo y entregar una pequeña muestra
que incremente el valor del producto. Es decir, cada uno de ellos debe terminar
entregando valor tangible al producto. Dentro de un Sprint se realizan diversos
eventos y actividades.
3.8.2.Sprint Planing
Esta reunión tiene como propósito definir el objetivo del Sprint y negociar qué
ítems del backlog pasarán a ser ejecutados o desarrollados. En esta reunión
participa todo el Scrum Team.
Su propósito es determinar qué es lo que se puede entregar en el incremento
resultante del Sprint que comienza, y cómo se hará el trabajo necesario para ello
3.8.3.Daily Scrum
Es la reunión diaria fija. Todos los días, el equipo de desarrollo se reúne por un
máximo de 15 minutos, ojalá a la misma hora y en el mismo lugar.
La Daily Scrum está orientada a realizar una inspección y adaptación con un ciclo
rápido. De esta forma
3.9. Arquitectura N capas
La arquitectura en capas es una de las más utilizadas, no solo por su simplicidad, sino
porque también es utilizada por defecto cuando no estamos seguros que arquitectura
debemos de utilizar para nuestra aplicación.
La arquitectura en capas consta en dividir la aplicación en capas, con la intención de
que cada capa tenga un rol muy definido, como podría ser, una capa de presentación
(UI), una capa de reglas de negocio (servicios) y una capa de acceso a datos (DAO)
3.10. Base de datos MySQL
MySQL es un componente importante de una pila empresarial de código abierto
llamada LAMP. LAMP es una plataforma de desarrollo web que utiliza Linux como
sistema operativo, Apache como servidor web, MySQL como sistema de gestión de
bases de datos relacionales y PHP como lenguaje de scripting orientado a objetos (a
veces se utiliza Perl o Python en lugar de PHP).
3.11. XAMPP
Xampp es un servidor independiente en base a software libre, con el cual podemos
disponer de un servidor propio o simplemente usarlo para hacer pruebas de nuestras
páginas web, bases de datos, para desarrollar aplicaciones en php, con conexión a
base de datos sql (LAMPP = Linux + Apache + MySQL + PHP + Perl)

El programa está liberado bajo la licencia GNU y actúa como un servidor web libre,
fácil de usar y capaz de interpretar páginas dinámicas. Actualmente Xampp está
disponible para GNU/Linux, Microsoft Windows y MacOS X (para Solaris está
descatalogado).
3.12. SublimeText3
Sublime Text es un editor de código multiplataforma, ligero y con pocas concesiones a
las florituras. Es una herramienta concebida para programar sin distracciones. Su
UPN FACULTAD DE INGENIERIA

interfaz de color oscuro y la riqueza de coloreado de la sintaxis, centra nuestra

atención completamente.
3.13. PHP
PHP (acrónimo recursivo de PHP: Hypertext Preprocessor) es un lenguaje de código
abierto muy popular especialmente adecuado para el desarrollo web y que puede ser
incrustado en HTML.
En lugar de usar muchos comandos para mostrar HTML (como en C o en Perl), las
páginas de PHP contienen HTML con código incrustado que hace "algo" (en este caso,
mostrar "¡Hola, soy un script de PHP!). El código de PHP está encerrado entre las
etiquetas especiales de comienzo y final <?php y ?> que permiten entrar y salir del
"modo PHP".
3.14. Hojas de estilos (CSS)
Una hoja de estilo es un archivo de extensión *.CSS (CSS, Cascading Style Sheets =
Hojas de estilo) que contempla definiciones de formato (tipo de fuente, tamaño, color
de la fuente, color de fondo, párrafos, etc) de las distintas etiquetas que forman una
página *.HTML.
Su principal ventaja es definir un mismo aspecto para todas las páginas de un sitio
web. Se crea una hoja de estilo y se vinculan todas las páginas del sitio web a este
archivo. Cualquier cambio efectuado en la hoja de estilo afecta instantáneamente al
formato de todas las páginas vinculadas a la misma.
3.15. JavaScript
JavaScript® (a menudo abreviado como JS) es un lenguaje ligero, interpretado y
orientado a objetos con funciones de primera clase, y mejor conocido como el
lenguaje de programación para las páginas Web, pero también se utiliza en muchos
entornos que no son de navegador. Es un lenguaje de scripts que es dinámico,
multiparadigma, basado en prototipos y admite estilos de programación orientados a
objetos, imperativos y funcionales.
3.16. Bootsrap 4
Bootstrap es una biblioteca multiplataforma o conjunto de herramientas de código
abierto para diseño de sitios y aplicaciones web. Contiene plantillas de diseño con
tipografía, formularios, botones, cuadros, menús de navegación y otros elementos de
diseño basado en HTML y CSS, así como extensiones de JavaScript adicionales. A
diferencia de muchos frameworks web, solo se ocupa del desarrollo front-end.
Bootstrap es el segundo proyecto más destacado en GitHub1 y es usado por la NASA y
la MSNBC entre otras organizaciones
3.17. AJAX
AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es
una técnica de desarrollo web para crear aplicaciones web asíncronas. Estas
aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios
mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De
esta forma es posible interactuar con el servidor sin necesidad de recargar la página
web, mejorando la interactividad, velocidad y usabilidad en las aplicaciones.
3.18. Pruebas de software
Las pruebas de software (en inglés software testing) son las investigaciones empíricas
y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre
UPN FACULTAD DE INGENIERIA

la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el

proceso de control de calidad.
3.19. Calidad de software
La calidad del software es una preocupación a la que se dedican muchos esfuerzos.
Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo
producir software de la mejor calidad posible, que cumpla, y si puede supere las
expectativas de los usuarios.

CAPITULO IV

4. DESARROLLO ÁGIL DEL PRODUCTO

4.1. Historias de Usuario

Historia de Usuario N°1

Prioridad
Descripción:
2
Como Administrador quiero poder registrar, actualizar y eliminar
los datos de los productos que ingresen al supermercado, para
saber con mayor precisión los productos que sobran y faltan.
T.Estimado

3 días
Criterios de Aceptación:

-Solo el Administrador podrá registrar, actualizar y eliminar los

datos correspondientes a un producto. Puntos
Estimados
-Se debe seleccionar el ícono correspondiente a la operación y fila
del producto que se desea actualizar o eliminar. 80

-Debe de existir un campo donde se pueda filtrar a un producto por

su nombre, marca o categoría.

-Debe validarse que el nombre del producto no exista en la base de

datos a la hora de efectuar un registro.

-Se debe validar que los campos no se encuentren vacíos.

-El patrón de los mensajes que se notificará al usuario tras una

operación exitosa deberá ser similar a "Producto registrado o
actualizado o eliminado satisfactoriamente".
 UPN FACULTAD DE INGENIERIA

Historia de Usuario N°2

Descripción: Prioridad

4
Como Administrador quiero generar una orden de compra para
poder tener un documento que certifique los productos que
ingresan al supermercado. T.Estimado

Criterios de Aceptación: 2 días

-Solo el usuario Administrador contará con el permiso para elaborar

órdenes de compra. Puntos
-Se requiere vincular con los módulos “Buscar Proveedor” y Estimados
“Agregar Productos Faltantes”. 80
-Se debe visualizar una tabla con el detalle de la orden de compra.

-Debe de haber una sección que permita calcular y visualizar

subtotal, IGV, total de los productos de la orden de compra.

-Se debe permitir la impresión de la orden de compra generada. -El

sistema captura y guarda el código y fecha que se realiza la orden
de compra

Historia de Usuario N°3

Descripción: Prioridad

4
Como Administrador quiero buscar los datos de un proveedor para
poder agregarlo al momento de registrar una orden de compra.

T.Estimado
Criterios de Aceptación: 1 días

-Solo se podrá visualizar los proveedores existentes en la base de

datos. Puntos
Estimados
-Debe de existir la posibilidad de filtrar a los proveedores según sus
datos. 20
UPN FACULTAD DE INGENIERIA

Historia de Usuario N°4

Prioridad
Descripción:
4
Como Administrador quiero registrar el ingreso de productos al
supermercado.

T.Estimado
Criterios de Aceptación: 3 días

-Se requiere vincular con el módulo “Buscar Orden de Compra” a fin

de facilitar este proceso.
Puntos
-El sistema debe actualizar el stock de los productos contenidos en Estimados
la orden de compra seleccionada cuando se registre un ingreso de
40
productos al supermercado.

-El estado de la orden de compra elegida debe cambiar a

“Procesado” y registrarse la hora, fecha y nombre completo del
usuario responsable de llevarlo a cabo.

Historia de Usuario N°5

Descripción: Prioridad

Como Administrador quiero buscar los datos de una orden de 4

compra para poder agregarlo al momento de registrar ingreso de
productos.

T.Estimado
Criterios de Aceptación:
2 días
-Solo deberán visualizarse
Prioridad las órdenes de compra que tengan
estado pendiente.
2
-Debe de existir la posibilidad de filtrar órdenes de compra según Puntos
sus datos. Estimados
-Debe notificársele al usuario cuando no seleccione una orden de 20
compra a cargar.
 UPN FACULTAD DE INGENIERIA

Historia de Usuario N°6

Descripción: Prioridad

4
Como Administrador quiero registrar, actualizar y eliminar los
datos correspondientes a un proveedor para poder tener una
adecuada base de datos de los proveedores.
T.Estimado

Criterios de Aceptación: 4 días

-Solo el usuario Administrador podrá registrar, actualizar y dar de

baja los datos correspondientes a un proveedor. Puntos
Estimados
-Se debe seleccionar el ícono correspondiente a la operación y fila
del proveedor que se desea actualizar o eliminar. 50
-Debe de existir un campo donde se pueda filtrar a un proveedor
por Nombre.

-Se debe validar que los campos no se encuentren vacíos.

-El patrón de los mensajes que se notificará al usuario tras una

operación exitosa deberá ser similar a "Proveedor registrado o
actualizado o eliminado satisfactoriamente".
 UPN FACULTAD DE INGENIERIA

Historia de Usuario N°7

Descripción: Prioridad

3
Como Vendedor quiero registrar una venta de productos brindados
para generar ingresos todos los días.

T.Estimado
Criterios de Aceptación:
4 días
-El módulo de “Registrar Venta” debe estar únicamente disponible
para el usuario Vendedor.
Puntos
-Se debe mostrar el nombre del trabajador que registra la venta.
Estimados
-Cuando se procesa una venta, paralelamente se debe crear una
70
boleta, pero con estado pendiente de pago.

-El sistema debe capturar y guardar el ID, fecha y el monto en el que

se realiza la venta.

-El stock de productos contenidos en la venta debe disminuir.

-Se debe notificar al usuario si es que existiesen productos no

disponibles en el stock y por lo tanto impiden que se pueda
continuar con la venta.
 UPN FACULTAD DE INGENIERIA

Historia de Usuario N°8

Descripción:
Prioridad

Como Vendedor quiero registrar el pago realizado por un cliente 3

para poder así comprobar los pagos realizados por cada venta.

Criterios de Aceptación: T.Estimado

3 días
-Se deberá visualizar la lista de boletas con estado pendiente de
pago.

-Se deberá filtrar la lista de boletas según sus datos.

Puntos
-Cuando se registre el pago, la boleta deberá cambiar a estado Estimados
pagada
70
-La boleta deberá ser impresa.

Historia de Usuario N°9

Descripción:
Prioridad
Como Vendedor quiero registrar, actualizar y eliminar los datos
1
correspondientes a un cliente para poder tener una correcta
gestión de la base de datos de cada cliente.

Criterios de Aceptación: T.Estimado

3 días
-Solo el usuario Vendedor podrá registrar, actualizar y eliminar los
datos correspondientes a un cliente.

-Se debe seleccionar el ícono correspondiente a la operación y fila

Puntos
del cliente que se desea actualizar o eliminar.
Estimados
-Debe de existir un campo donde se pueda filtrar a un cliente por su
60
DNI o nombre.

-Debe validarse que el DNI del cliente no exista en la base de datos

a la hora de efectuar un registro.

-Se debe validar que los campos no se encuentren vacíos.

-El patrón de los mensajes que se notificará al usuario tras una

operación exitosa deberá ser similar a "Cliente registrado o
actualizado o eliminado satisfactoriamente".
 UPN FACULTAD DE INGENIERIA

Historia de Usuario N°10

Descripción: Prioridad

3
Como Administrador quiero registrar, actualizar y dar de baja los
datos correspondientes a un trabajador para tener un correcto
control de la base de datos de los trabajadores.
T.Estimado
Criterios de Aceptación: 3 días
-Solo el usuario Administrador podrá registrar, actualiza y dar de
baja los datos correspondientes a un trabajador.
Puntos
-Se debe seleccionar el ícono correspondiente a la operación y fila Estimados
de la marca del trabajador que se desea actualizar o eliminar.
70
-Debe de existir un campo donde se pueda filtrar a un trabajador
por DNI, nombre.

-Debe validarse que el DNI del trabajador sea único a la hora de

efectuar un registro en la base de datos.

-Se debe validar que los campos no se encuentren vacíos.

-El patrón de los mensajes que se notificará al usuario tras una

operación exitosa deberá ser similar a "Trabajador registrado o
actualizado o eliminado satisfactoriamente".
 UPN FACULTAD DE INGENIERIA

Historia de Usuario N°11

Prioridad
Descripción:
1
Como Usuario de la empresa quiero contar con una página de
inicio de sesión para acceder al contenido del sistema.

T.Estimado

Criterios de Aceptación: 1 días

-El módulo acceder al sistema solo puede ser usada por los
empleados del supermercado, a los que se les haya asignado un ID y
que cuenten con un usuario y contraseña Puntos
Estimados
-Si se ingresa un usuario o contraseña incorrecto se deberá mostrar
un mensaje de error. 30

-Si el usuario y la contraseña coinciden se deberá mostrar un

mensaje de bienvenida y el acceso al sistema.

Historia de Usuario N°12

Prioridad
Descripción:
5
Como usuario quiero poder realizar el cambio de contraseña para
poder proteger mi cuenta.

T.Estimado
Criterios de Aceptación: 2 días

-Solo el usuario podrá realizar el cambio de contraseña.

-Se deberá pedir ingresar la contraseña anterior para proceder con Puntos
el cambio. Estimados
-En caso el cambio se requiera porque el usuario olvidó su 50
contraseña, se deberá solicitar su DNI y correo como método de
validación.
 UPN FACULTAD DE INGENIERIA

Historia de Usuario N°13

Descripción: Prioridad

2
Como administrador quiero poder registrar, actualizar y eliminar
una categoría de productos para poder tener una adecuada base
de datos de categoría ofrecidas.
T.Estimado

1 días
Criterios de Aceptación:

- Solo el usuario Administrador podrá registrar, actualizar y dar de

baja los datos correspondientes a la categoría de productos. Puntos
Estimados
- Se debe seleccionar el ícono correspondiente a la operación y fila
de la categoría de productos que se desea actualizar o eliminar. 40

- Debe existir un campo donde se pueda filtrar las categorías de

productos por su nombre.

- Se debe validar que el nombre de la categoría de productos sea

único a la hora de efectuar un registro de la base de datos.

- Debe validarse que ningún campo se encuentre vacío.

- El patrón de los mensajes que se notificará al usuario tras una

operación exitosa deberá ser similar a “Categoría de productos
registrada, actualizada o eliminada satisfactoriamente”.
UPN FACULTAD DE INGENIERIA

4.3 Matriz de Impacto

Tabla 1: Matriz de Impacto de Prioridades

Prioridad

Muy Alta 1

Alta 2

Media 3

Baja 4

Muy Baja 5

Fuente: Elaboración propia.

4.4 Product Backlog

El Product backlog se muestra a continuación, en el cual se muestra los

requerimientos funcionales, debidamente especificados con su número de

historia, prioridad y tiempo estimado.

Pila del Producto (Product Backlog)

Requerimientos Funcionales Historias T.E P.E P.

RF1: La aplicación web deberá mostrar una página en la que

se pueda registrar, actualizar y eliminar los datos de los H1 3 80 2
productos que ingresen al supermercado.
RF2: La aplicación web deberá mostrar una página en la que
se pueda generar una orden de compra. H2 2 80 4

RF3: El sistema web deberá buscar los datos de un proveedor

para poder agregarlo al momento de registrar una orden de H3 1 20 4
compra.
RF4: La aplicación web permitirá registrar el ingreso de
productos. H4 3 40 4

RF5: El sistema web deberá a través de una interfaz buscar los

datos de una orden de compra para poder agregarlo al H5 2 20 4
momento de registrar ingreso de productos.
UPN FACULTAD DE INGENIERIA

Requerimientos Funcionales Historias T.E P.E P.

RF6: El sistema web deberá permitir registrar, actualizar y

eliminar los datos correspondientes a un proveedor. H6 4 50 4

RF7: La aplicación web deberá permitir mediante una interfaz

registrar una venta de productos brindados. H7 4 70 3

RF8: La aplicación web deberá permitir registrar el pago

realizado por un cliente y guardar como detalle la fecha y hora
H8 3 70 3
de la transacción, así como también el método de pago
empleado.
RF9: El sistema web permitirá mediante una interfaz registrar,
actualizar y eliminar los datos correspondientes a un cliente H9 3 60 2

RF10: La aplicación web deberá permitir registrar, actualizar y

dar de baja los datos correspondientes a un trabajador. H10 3 70 1

RF11: El sistema web deberá permitir mediante una interfaz

una página de inicio de sesión, donde se debe ingresar
H11 1 30 1
usuario y contraseña para acceder al contenido del sistema.

RF12: El sistema web deberá permitir el cambio de

contraseña cuando sea solicitado por el usuario. H12 2 50 5

RF13: La aplicación web deberá permitir mediante una

interfaz registrar, actualizar y eliminar una categoría de H13 1 40 2
productos.

4.5. Entregables Por Sprint

En este punto se detalla la cantidad de Sprints, los requerimientos funcionales de la

Pila de Producto y sus respectivos prioridades y tiempos estimados
UPN FACULTAD DE INGENIERIA

4.6 ENTREGABLES POR SPRINT

En este punto se detalla la cantidad de Sprints, los requerimientos funcionales

de la Pila de Producto y sus respectivos prioridades y tiempos estimados

UPN FACULTAD DE INGENIERIA

4.7 PLAN DE TRABAJO

En este apartado observamos el plan de trabajo, la cual es una herramienta indispensable que
el equipo scrum utilizará para la planificación y gestión del trabajo de campo, debido a que
permite una clara visión acerca de las actividades que se deben desarrollar para culminar cada
sprint.

SPRINT N1 SPRINT N2 SPRINT N3 SPRINT N4 SPRINT N5

Sprint planning Sprint planning Sprint planning Sprint planning Sprint planning
22/09 10/10 25/10 10/11 26/11
Desarrollo del Desarrollo del Desarrollo del Desarrollo del Desarrollo del
sprint 01/10 sprint 20/10 sprint 01/11 sprint 20/11 sprint 01/12
UPN FACULTAD DE INGENIERIA

4.8 DIAGRAMA DE CLASES DE DISEÑO

4.9 DIAGRAMA FÍSICO DE LA BASE DE DATOS

4.10 4.9 DIAGRAMA FÍSICO DE LA BASE DE DATOS

UPN FACULTAD DE INGENIERIA

El siguiente diagrama representa el modelo arquitectónico del software, que como se puede
observar, consiste en un diagrama de paquetes que muestra cómo el sistema se divide en
agrupaciones lógicas y las dependencias entre dichas agrupaciones.

4.11. SPRINT 1
4.11.1. SPRINT BACKLOG
A continuación, se visualiza el sprint backlog con los requerimientos funcionales
correspondientes al Sprint N°1.

RF11: El sistema web deberá permitir mediante

una interfaz una página de inicio de sesión,
H11 1 30 1
SPRINT 1

donde se debe ingresar usuario y contraseña

para acceder al contenido del sistema.
RF9: El sistema web permitirá mediante una
interfaz registrar, actualizar y eliminar los datos H9 3 60 2
correspondientes a un cliente

4.11.2. SPRINT PLANNING

A continuación, se visualiza la planificación con respecto al sprint N°1, la cual se
llevó a cabo el día 29/09/2021 a las 9:00 a.m. Esta reunión tuvo una duración de
4 horas, de las cuales el Scrum Máster dividió 2 horas a la planificación de las
actividades con participación activa del PO y 2 horas en las que participó
activamente el equipo de desarrollo.

• Objetivo:
UPN FACULTAD DE INGENIERIA

Permitir a los usuarios utilizar el sistema logrando un correcto inicio de

sesión para tener acceso a operaciones como el mantenimiento de
clientes, servicios y usuarios aplicando los criterios correctos.

• Tiempo estimado: 10 días

4.11.3. DESARROLLO
Requerimiento Funcional N° 11:
El sistema web deberá permitir mediante una interfaz una página de inicio de
sesión, donde se debe ingresar usuario y contraseña para acceder al contenido
del sistema.

• Implementación:

En la figura N°1 se observa la implementación final en el sistema del RF11,

desarrollado por el equipo de trabajo

Requerimiento Funcional N° 9:
El sistema web permitirá mediante una interfaz registrar, actualizar y
eliminar los datos correspondientes a un cliente.
UPN FACULTAD DE INGENIERIA

• Análisis:
Diagrama físico de la BD de RF 9:

En la figura N° 1 se muestra el diagrama físico de la base de datos

del sprint 1, RF 09 respectivamente.

• Implementación:

En la figura N°2 se observa la implementación final en el sistema del RF9,

desarrollado por el equipo de trabajo.
UPN FACULTAD DE INGENIERIA

4.12. SPRINT 2

4.12.1. SPRINT BACKLOG

A continuación, se visualiza el sprint backlog con los requerimientos funcionales

correspondientes al Sprint N°2

4.12.2. SPRINT PLANNING

A continuación, se visualiza la planificación con respecto al sprint N°1, la cual se
llevó a cabo el día 10/10/2021 a las 9:00 a.m. Esta reunión tuvo una duración de
4 horas, de las cuales el Scrum Máster dividió 2 horas a la planificación de las
actividades con participación activa del PO y 2 horas en las que participó
activamente el equipo de desarrollo.

4.12.3. DESARROLLO
Requerimiento Funcional N° 1:
La aplicación web deberá mostrar una página en la que se pueda registrar, actualizar y
eliminar los datos de los productos que ingresen al supermercado.
UPN FACULTAD DE INGENIERIA

4.13. SPRINT 3
4.13.1. SPRINT BACKLOG

A continuación, se visualiza el sprint backlog con los requerimientos funcionales

correspondientes al Sprint N°3

4.13.2. SPRINT PLANNING

A continuación, se visualiza la planificación con respecto al sprint N°1, la cual se
llevó a cabo el día 25/10/2021 a las 9:00 a.m. Esta reunión tuvo una duración de
4 horas, de las cuales el Scrum Máster dividió 2 horas a la planificación de las
actividades con participación activa del PO y 2 horas en las que participó
activamente el equipo de desarrollo.

4.13.3. DESARROLLO
Requerimiento Funcional N° 7:
La aplicación web deberá permitir mediante una interfaz registrar una venta de
productos brindados.
UPN FACULTAD DE INGENIERIA

5. PRUEBAS
5.1. Pruebas unitarias
5.1.2. Prueba del sprint 1:

Requerimiento Funcional N° 9:
El sistema web permitirá mediante una interfaz registrar, actualizar y
eliminar los datos correspondientes a un cliente.

5.2. Pruebas TDD