Olivera RJC SD

FACULTAD DE INGENIERÍA Y ARQUITECTURA
ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA DE

SISTEMAS
“Aplicación web para el proceso de control de inventario en la empresa

Maxtechperu S.A.C”
TESIS PARA OBTENER EL TÍTULO PROFESIONAL DE:

Ingeniero de Sistemas
AUTOR:
Br. Olivera Rodrigo, Juan Carlos (ORCID: 0000-0003-0711-1240)
ASESOR:
Mg. Petrlik Azabache, Iván Carlo (ORCID: 0000-0002-1201-2143)
LÍNEA DE INVESTIGACIÓN:
Sistemas de información y comunicaciones
LIMA - PERÚ
2019
Página del jurado
ii
Declaratoria de autenticidad
iii
Dedicatoria
El presente proyecto está dedicado al divino

creador y a mis queridos padres por el apoyo
incondicional que me han brindado a lo largo de
mi formación profesional.
iv
Agradecimiento
A toda mi familia que me apoyó

incondicionalmente. Al Mg. Iván Petrlik
por el apoyo y asesoría a lo largo de este
proyecto de investigación. A mis
docentes por el conocimiento brindado
durante mi formación universitaria.
v
Presentación
Señores miembros del jurado:
Dando cumplimiento a las normas establecidas en el Reglamento de Grados y

Títulos sección de Pregrado de la Universidad César Vallejo para la experiencia
curricular de Metodología de la Investigación Científica, presento la siguiente tesis
titulada: “Aplicación web para el proceso de control de inventario en la empresa
Maxtechperu S.A.C”.
Esta investigación tiene como principal objetivo: “Determinar la influencia de una

aplicación web en el proceso de control de inventario en la empresa Maxtechperu
S.A.C.”
Y consta de siete capítulos:
En el primer capítulo se realiza el planteamiento del problema: incluyendo

formulación del problema, los objetivos, la hipótesis, la justificación, los
antecedentes y la fundamentación científica. En el segundo capítulo encontramos
el marco metodológico sobre la investigación en la que se desarrolla el trabajo de
campo de la variable de estudio, diseño, población y muestra, las técnicas e
instrumentos de recolección de datos y los métodos de análisis. En el tercer capítulo
observamos la interpretación de los resultados, recursos y presupuesto. En el
cuarto capítulo se construye las discusiones generadas a partir de los
antecedentes. En el quinto capítulo se generan las conclusiones. En el sexto
capítulo se presentan las recomendaciones por parte del autor, y finalmente en el
séptimo capítulo observamos las referencias bibliográficas.
Estimados miembros del jurado espero que esta investigación sea evaluada
imparcialmente y merezca su aprobación.
vi
ÍNDICE
Página del jurado……………………………………………………………………….ii

Declaratoria de autenticidad………………………………………………………….iii
Dedicatoria……………………………………………………………………………....iv
Agradecimiento…………………………………………………………………………v
Presentación…………………………………………………………………………….vi
Resumen ................................................................................................................x
Abstract ..................................................................................................................xi
I. INTRODUCCIÓN ........................................................................................... 15
1.1 Realidad Problemática .............................................................................. 17
1.2 Trabajos previos.................................................................................... 20
1.3 Teorías relacionadas con el tema ............................................................ 26
1.3 Formulación del problema.................................................................... 40
1.4 Justificación del estudio....................................................................... 40
1.5 Hipótesis ................................................................................................ 42
1.6 Objetivo .................................................................................................. 42
II. MÉTODO ....................................................................................................... 43
2.1 Diseño de investigación .............................................................................. 44
2.2 Variables, Operacionalización ................................................................. 46
2.3 Población y muestra ............................................................................. 49
2.4 Técnicas e instrumentos de recolección de datos, validez y
confiabilidad .................................................................................................... 51
2.5 Métodos de análisis de datos............................................................... 55
2.6 Aspectos éticos ..................................................................................... 57
III. RESULTADOS ........................................................................................... 58
3.1 Análisis Descriptivo .............................................................................. 59
3.2 Análisis Inferencial ................................................................................ 61
3.3 Prueba de hipótesis .............................................................................. 66
IV. DISCUSIÓN................................................................................................ 75
V. CONCLUSIONES .......................................................................................... 77
VI. RECOMENDACIONES .............................................................................. 79
VII. REFERENCIAS .......................................................................................... 81
ANEXOS ............................................................................................................... 85
vii
ÍNDICE DE TABLAS
Tabla 1: Validación de expertos para la selección de la metodología ........... 39

Tabla 2: Operacionalización de las variables .................................................. 48
Tabla 3:Validez de las fichas de registro .......................................................... 53
Tabla 4:Nivel de Confiabilidad .......................................................................... 54
Tabla 5:Resultado de confiabilidad del índice de rotación de inventario ..... 54
Tabla 6: Resultado de confiabilidad del índice de nivel de servicio .............. 55
Tabla 7: Medidas descriptivas de la rotación de inventario en el proceso de
control de inventario antes y después de la implementación de la aplicación
web. ..................................................................................................................... 59
Tabla 8: Medidas descriptivas del nivel de servicio en el proceso de control
de inventario antes y después de la implementación de la aplicación web. 60
Tabla 9: Prueba de normalidad de la rotación de inventario antes y después
de implementar la aplicación web .................................................................... 62
Tabla 10: Prueba de normalidad del nivel de servicio antes y después de
implementar la aplicación web .......................................................................... 64
Tabla 11: Prueba T-Student para la rotación de inventario en el proceso de
control de inventario antes y después de implementar la aplicación web ... 68
Tabla 12: Prueba T-Student para el nivel de servicio en el proceso de control
de inventario antes y después de implementar la aplicación web ................ 71
viii
ÍNDICE DE FIGURAS
Figura 1: Rotación de Inventario ....................................................................... 19

Figura 2: Nivel de Servicio................................................................................. 19
Figura 3:Proceso Scrum .................................................................................... 38
Figura 4: Metodología XP .................................................................................. 39
Figura 5:Diseño de Investigación pre-experimental........................................ 45
Figura 6: Rotación de inventario antes y después de implementar la
aplicación web .................................................................................................... 60
Figura 7: Porcentaje del nivel de servicio antes y después de implementar la
aplicación web .................................................................................................... 61
Figura 8: Prueba de normalidad de la rotación de inventario antes de
Figura 9: Prueba de normalidad de la rotación de inventario después de
Figura 10: Prueba de normalidad del nivel de servicio antes de implementar
la aplicación web ................................................................................................ 65
Figura 11: Prueba de normalidad del nivel de servicio después de
Figura 12: Rotación de inventario - Comparativa general .............................. 67
Figura 13: Prueba T-Student - Rotación de inventario .................................... 70
Figura 14: Nivel de servicio - Comparativa general........................................ 71
Figura 15: Prueba T-Student - Nivel de servicio .............................................. 74
ix
Resumen
La presente tesis detalla el desarrollo de una aplicación web para el proceso de

control de inventario en la empresa Maxtechperu S.A.C; debido a que la situación
de la empresa previa a la implementación de la aplicación web presentaba
deficiencias en cuanto a la rotación de inventario y el nivel de servicio. El objetivo
principal de esta investigación fue determinar la influencia de una aplicación web
en el proceso de control de inventario en la empresa Maxtechperu S.A.C.
Por tal razón, previamente, se describe aspectos teóricos del proceso de control de
inventario; así como las metodologías que se utilizaron para el desarrollo de la
aplicación web. Para el desarrollo de la aplicación web se utilizó la metodología
SCRUM, por ser una metodología de desarrollo ágil.
El tipo de investigación es aplicada, el diseño de investigación es pre experimental

y el enfoque es cuantitativo. La población es de 28 productos para el indicador de
rotación de inventario, la muestra para este indicador es de 28 productos. La
población para el indicador de nivel de servicio es de 89 órdenes de venta, cuya
muestra resultante fue de 72 órdenes de venta, estratificados en 24 días; por lo
tanto, la muestra para este indicador fue de 24 fichas de registro.
El tipo de muestreo empleado fue aleatorio probabilístico simple. Se utilizó el fichaje

como técnica para la recolección de datos; el instrumento utilizado fue la ficha de
registro, las cuales fueron validados por expertos en la materia. La implementación
de la aplicación web permitió incrementar la rotación de inventario de 0.49 a 0.77;
del mismo modo, se incrementó el nivel de servicio de 72.34% a 92.68%. Los
resultados mencionados anteriormente, permitieron llegar a la conclusión que la
aplicación web mejora el proceso de control de inventario en la empresa
Maxtechperu S.A.C.
Palabras clave: APLICACIÓN WEB, SCRUM, MVC, PHP, MYSQL.
x
Abstract
This thesis details the process to develop a web application for the process of control
inventory at Maxtechperu S.A.C; because of this fact, the situation of the company
before the implementation of the web application had many deficiencies in the
inventory rotation and the service level. The main objective of this investigation was
to determine the influence of a web application in the inventory control process in
the Company Maxtechperu S.A.C
For this reason, here is described aspects of the inventory control process; as well
as the methodologies that were used for the development of the web application.
The SCRUM methodology was used to develop the web application, because it is
an agile development methodology.
The type of research is applied, the research design is pre-experimental and the
approach is quantitative. The population is 28 products for the inventory turnover
indicator, the sample for this indicator is 28 products. The population for the service
level indicator is 89 sales orders, whose resulting sample was 72 sales orders,
stratified in 24 days; therefore, the sample for this indicator was 24 redord sheets.
The type of sampling used was simple random probabilistic. Signing was used as a
technique for data collection; The instrument used was the registration form, which
was validated by experts in the field. The implementation of the web application
allowed to increase the inventory turnover from 0.49 to 0.77; Similarly, the service
level was increased from 72.34% to 92.68%. The results mentioned above, allowed
to conclude that the web application improves the inventory control process in the
company Maxtechperu S.A.C.
Keywords: WEB APPLICACTION, SCRUM, MVC, PHP, MYSQL
xi
I. INTRODUCCIÓN
1
1.1 Realidad Problemática
En el escenario internacional, según Lopes y Gómez (2014), en el artículo Auditoría

logística para evaluar el nivel de gestión de inventarios en empresas manifiestan
que se debe considerar una decisión estratégica el iniciar el control del flujo de
información para mitigar la incertidumbre en la gestión de los inventarios. Esto se
ve reflejado en una encuesta realizada por Aberdeen en el año 2009, en la que se
indica que el 91 % de las empresas trabajaban en la optimización de los procesos
de gestión de los inventarios y el 61 % priorizaban, entre sus objetivos, el desarrollo
de la tecnología para lograrlo, debido a que la realidad evidencia que las
organizaciones están bajo presión cuando se trata de mejorar el control de los
inventarios; con la finalidad de mejorar del retorno del capital invertido, disminuir la
escasez de capital de trabajo para apoyar las operaciones y procesos de expansión
de la empresa, mejorar el nivel de servicio brindado a los clientes, etc.(p.110).
En el ámbito nacional, según Choque (2016) en la revista Gestión Logística: El

Músculo del Almacén asegura que en el puerto del callao se notó un incremento
del 15% en almacenaje, debido a retrasos en el retiro de los contenedores de
importación; aumentando así los costos de almacenamiento hasta en un 10%.
Además, las penalidades, por el ingreso tardío de contenedores de embarque,
aumentaron en un 10%. Es importante recalcar que atender los pedidos de los
clientes realizando la menor cantidad posible de pasos es una de las claves del
ahorro de costos en el picking y esto se logra teniendo una organización del
inventario además de una buena contabilidad (p.19).
Así mismo, la empresa MAXTECHPERU S.A.C, no es ajena estos problemas. Esta

compañía se dedica a la venta de productos tecnológicos como cámaras de video
vigilancia, sistemas de alarmas, control de acceso, cercos eléctricos, etc. y servicios
de metal mecánica.
Según la entrevista realizada al jefe de logística Cleydis Meléndez Salvador (Anexo

N° 7). Su proceso empieza desde que la encargada de logística elabora las órdenes
de compra para requerir los artículos a sus abastecedores, de acuerdo a la
disponibilidad de éstos, los productos llegan en un periodo de dos o tres días
hábiles y cuando los productos son de importación, la fase de compra (adquisición)
2
puede demorar hasta 45 días. Llegados los productos a la empresa Máxima
Tecnología del Perú S.A.C, se verifica que la mercadería recibida cumpla con lo
especificado en las órdenes de compra tanto en la cantidad de productos, marcas,
modelos, etc. En el caso que se detecte productos faltantes, o no coincidencias en
otros aspectos con respecto a la orden de compra, se notifica al jefe de logística
para que pueda contactar con el proveedor. Una vez finalizada esta inspección se
procede a registrar los artículos a almacenar, utilizando para ello un kardex y hojas
Excel. En esta fase es donde se presenta uno de los mayores problemas en el
proceso de control de inventario de la empresa, ya que el registro de artículos se
realiza de forma manual y en tablas de Excel, generando pérdida de información,
duplicidad de datos, registros sin actualizar, todo ello ocasiona que no se tenga un
control exacto de las existencias, lo que acarrea un problema a la hora de realizar
las compras y ventas. Se puede evidenciar un deficiente control de inventario
Luego los trabajadores se ocupan del almacenaje (productos pasan al almacén de

la empresa, ubicándolos es su respetivo sector y estante), para lo cual se pueden
llegar a requerir 3 o hasta 4 trabajadores.
Cuando un cliente solicita un producto, es atendido por el encargado del área de

logística el cual comunica al cliente la disponibilidad o no de los productos
solicitados (según el control manual que lleva la empresa). Para la venta de los
productos, la jefa de logística emite la orden de venta respectiva, cuando el
almacenero se prepara para despachar los productos solicitados se presentan
diversos problemas como que no se cuenta con stock del producto solicitado en la
orden de venta (por la falta de control de inventario mencionado anteriormente),
que se encuentre exceso de algunos productos (que se creían con stock cero,
según el control manual que lleva la empresa), lo que genera una baja rotación de
los mismos, etc. En el caso que, si se cuente con los productos detallados en la
orden de venta, se procede con el despacho y se registra en el kardex la salida de
los productos del almacén, siendo una práctica no muy habitual por negligencia del
almacenero o por alguna otra circunstancia que no permita registrar la salida de los
productos en el momento oportuno.
3
Para cuantificar la problemática actual se optó por realizar dos test, con los cuales
se medirá la rotación de inventario y el nivel de servicio. Para el primer test se tomó
una población 28 productos y como muestra 28 productos y se obtuvo que la
rotación de inventario promedio del mes de mayo fue 0.49 tal como se muestra en
la figura N°1.
Figura 1: Rotación de Inventario
Fuente: Elaboración propia
Realizando el test para el nivel de servicio, se tomó una población de 89 órdenes

de venta y como muestra 72 órdenes de venta, se obtuvo que el nivel de servicio
promedio del mes de mayo fue 72,34% tal como se muestra en la figura N°2.
Figura 2: Nivel de Servicio
4
Analizando las gráficas anteriores se puede asegurar que existen deficiencias en el
proceso de control de inventario. Debido a los problemas encontrados, se generan
inconvenientes en las ventas como que no se concrete (total o parcial) la venta, ya
que en ocasiones no se cuenta con todos los productos que solicita el cliente;
ocasionando que el nivel de servicio no sea el más óptimo. Además de tener en
almacén productos estancados, vale decir de baja rotación, ocasionando costos de
almacén innecesarios para la empresa.
Es por éstas razones que nos preguntamos ¿Qué sucederá si se siguen teniendo
los mismos problemas en el proceso de control de inventario en la empresa Máxima
tecnología del Perú S.A.C? Cuya respuesta más lógica es que al seguir
presentando estas deficiencias, en el mencionado proceso, se seguirán teniendo
bajos porcentajes de rotación de inventario y nivel de servicio; lo cual influye de
manera directa a que no se logre los propósitos estratégicos de la compañía.
1.2 Trabajos previos
Para poder realizar esta investigación se ha revisado y evaluado distintas fuentes

primarias, las cuales nos proporcionan las bases que sustentan la problemática
planteada.
Antecedentes Internacionales
Ayesha Fawad, en el año 2015, hizo un estudio que lleva por título “Inventory
management system”, en la Universidad de Effat – Jeddah, en Arabia Saudita. En
dicho estudio se observó que una empresa de contrataciones presentaba el
inconveniente de realizar el control y gestión de sus activos de manera manual, lo
que ocasionaba que las actividades (cuadre de inventario, documentación de
pedidos, etc.) que realizaban sus trabajadores, para dicho proceso, tomaran más
tiempo del deseado y en muchas ocasiones los cálculos obtenidos por los
colaboradores eran inexactos. Es por ello que la solución fue la implementación de
un sistema de gestión de inventario. Cabe mencionar que esta investigación es
aplicada, de diseño Pre-Experimental, además tiene un enfoque cuantitativo. El
investigador usó SDLC como metodología, la cual abarca las siguientes etapas:
Planificación, análisis, diseño, implementación y pruebas. Trabajó con una
5
población de 39 productos; la muestra fue 39 productos de mayor rotación. Una vez
implementado el software propuesto se incrementó la rotación a 0,79; y antes de
su uso la rotación de inventario fue de 0,75. Utilizar un sistema de gestión de
inventario provee resultados prácticos y económicas en las empresas contratistas,
fue lo que finalmente concluyó el autor.
El aporte de este estudio fue la referencia brindada para el indicador de rotación de

inventario y además se utilizó para la discusión de los resultados.
Alejandro Martínez Giménez, en el año 2016, en la tesis “Aplicación web para el

control de los inventarios y el stock con tecnología RFID” realizada en la
Universidad Politécnica de Valencia-España, trató la contrariedad del control de
inventarios, la cantidad de tiempo y de recursos elevados que se necesitan para
obtener un óptimo dominio de inventario. La propuesta fue el desarrollo de una
aplicación basada en tecnología web apoyado de la tecnología RFID. Es un estudio
de tipo aplicado cuyo diseño es Pre-Experimental. La muestra empleada fue de 45
productos a partir de una población de 45 productos de mayor rotación, para los
dos indicadores que fueron nivel de servicio y duración de inventarios. Las
herramientas utilizadas para el desarrollo fueron eclipse como IDE, Openxava como
metodología ágil de desarrollo de aplicaciones y la base de datos PostgreSQL. En
el pre test se obtuvo un nivel de servicio de 65% y una duración de inventario de 19
días. Después de la implantación de la aplicación web se obtuvo un nivel de servicio
de 85% y una duración de inventario de 15 días. Por lo que se concluyó que
realizando una aplicación web podemos gestionar la data de manera más eficiente,
logrando así que el proceso de gestión de inventario sea más óptimo.
De este trabajo de indagación se toma como observación teórica la parte de la

variable independiente haciendo énfasis en la aplicación web y el MVC como patrón
de diseño; además del indicador de nivel de servicio para la discusión de los
resultados.
6
Carlos David Guevara Zambrano, en el año 2017, en la tesis “Desarrollo de un
sistema en entorno web para el control de la gestión del inventario de la empresa
Cuenca Llantas, utilizando como framework de desarrollo Laravel” que elaboró en
la Universidad de Guayaquil, de Guayaquil-Ecuador, se enfrentó a la problemática
del ineficiente control de inventario. Carlos Guevara se percató que dicho proceso
no estaba automatizado y que se realizaba de forma manual en archivos Excel.
Además, se evidenció que, existen entradas y salidas de mercadería sin
justificación, lo que ocasiona desbalances financieros en la empresa. Por tal motivo
se planteó la posibilidad del desarrollo de un sistema web usando ICONIX
(metodología). El objetivo de esta investigación fue dar solución a los
inconvenientes encontrados en Cuenca Llantas. Éste trabajo tiene un enfoque
cuantitativo, y un diseño pre experimental. Para efectuar esta investigación la
población fue de 19 personas entre personal de la empresa, siendo la muestra el
mismo número de personas. La conclusión a la que se llegó fue que con el sistema
desarrollado se consiguió mantener la información centralizada lo que permitió a la
empresa realizar las compras y ventas de manera precisa y eficiente.
De este trabajo se valoró las tecnologías a utilizar para la elaboración de una

aplicación web; el lenguaje de backend PHP y el gestor de base de datos MySQL,
así como el framework Bootstrap por mencionar algunas.
Kerly Briggite Lucas Vega, en el año 2017, realizó su investigación “Desarrollo e

implementación de aplicación web para el control de inventario del local comercial
Máquinas Hidalgo” desarrollado en la Universidad Politécnica Salesiana sede
Guayaquil. En esta ardua tarea investigativa se logró detectar que los procesos que
se llevaban a cabo eran difíciles de manejar debido al elevado número de
documentos manuales que se manejaban, requiriendo así una mayor carga
operativa. Es por ello que el desarrollo de una aplicación web que permitiera agilizar
la gestión, el conteo de activos, información precisa y actualizada se antojaba como
una solución óptima. Fue un trabajo aplicado de diseño Pre-experimental. Para
medir el nivel de servicio se tuvo como población 42 órdenes de venta y como
muestra la misma cantidad. El patrón de diseño utilizado para esta investigación
fue modelo-vista-controlador (MVC). Se obtuvo que antes de utilizar la aplicación
7
web el nivel de servicio fue del 78% y luego de su utilización fue del 86%. Debido a
esto se concluyó que, la aplicación web dio un salto de calidad al control de
inventario de dicho negocio, ya que automatizó el proceso, disminuyendo la carga
operativa, asimismo permitió que el movimiento de mercadería sea de forma
oportuna para los diferentes almacenes.
El mencionado trabajo fue utilizado como respaldo teórico para la variable

independiente, que es la aplicación web, las tecnologías utilizadas para su
desarrollo como Mysql (motor de base de datos) y el patrón de diseño MVC.
Además del indicador de nivel de servicio para la discusión de los resultados.
Antecedentes Nacionales
Fiorela Izquierdo Aylas, en el año 2018, en su trabajo “Sistema web para el control
de inventario en la empresa mc air servis s.a.c” elaborado en la prestigiosa casa de
estudios Cesar Vallejo, de la capital peruana. La autora estudió la rotación de
inventario y rotura de stock como principales problemas de dicha empresa.
Delimitar el influjo de un sistema web para el curso del control de inventario fue el
propósito de esta investigación. Fiorela Izquierdo empleó la metodología RUP. Fue
una investigación aplicada de diseño Pre-Experimental y el enfoque fue
cuantitativo. La muestra empleada fue de 196 pedidos a partir de una población de
400 pedidos, para el indicador de rotura de stock y 309 unidades de materia prima
a partir de una población de 1571 unidades de materia prima para el indicador de
rotación de inventario. El muestreo empleado fue el probabilístico aleatorio simple.
Se obtuvo una rotación de inventario de 37,31% y una rotura de stock de 58,31%
para el pretest. Posterior a la implantación del sistema web se obtuvo una rotación
de inventario de 55,56% y una rotura de stock de 37,50%. Finalizado el estudio se
dedujo que el sistema web tuvo un impacto positivo en el control de inventarios de
la compañía mencionada.
Este antecedente fue de utilidad para la variable dependiente para referenciar el

indicador de rotación de inventario y de base para la medición del mismo. Así como
para la discusión de los resultados.
8
Ronald Romero Meza, en el año 2018, en la tesis “Sistema web para el proceso de
inventario de materiales de telecomunicaciones en la empresa Q&S INGENIEROS
S.A.C” en la casa de estudios superiores Cesar Vallejo, de la capital peruana, se
analizó la rotación y duración de inventarios de dicha empresa. El objetivo fue ver
en qué medida influye este sistema en su proceso de inventario y se empleó la
metodología SCRUM. Como principal lenguaje de backend se usó PHP, haciendo
uso de uno de sus frameworks más populares, Laravel 5.0, el cual integra en su
estructura interna el patrón de diseño MVC. Es una tesis aplicada y de diseño pre-
experimental. La muestra empleada fue de 26 fichas de inventario. En el pre test se
captó una rotación de inventario de 0.87 y una duración de inventario de 34,29 días.
Posteriormente con el uso correcto del sistema se obtuvo una rotación de 1,49 y
una duración de inventario de 20,15 días. El sistema web optimiza la gestión de
inventario (materiales de telecomunicaciones) en dicha compañía, fue lo que
finalmente concluyó Ronald Romero.
Este antecedente fue de utilidad para la variable dependiente para referenciar el

indicador de rotación de inventario y de base para la medición del mismo. Así como
para la discusión de los resultados.
Miguel Ángel Chipana Barrientos, en el año 2017, en la tesis “Sistema web para el
proceso de control de inventario de la empresa Leuka del Cercado de Lima”
desarrollada en Lima-Perú en la Universidad César Vallejo, Tuvo como
problemática controlar el grado de renovación de los productos de almacén de
dicha empresa. El objetivo fue ver en qué medida contribuye un sistema web en
dicho proceso. Chipana Barrientos empleó la metodología SCRUM. La muestra
empleada fue de 84 artículos calculados a partir de una población de 108 artículos.
Se obtuvo una rotación de inventario de 50.24% para el pretest y para el nivel de
cumplimiento de despacho se obtuvo un 49.44%. Después del uso del sistema web
la rotación fue de 88.76% y el nivel de cumplimiento de despacho fue del 86.59%.
Finalizado el estudio se concluyó que, con el uso del sistema web, el control de
inventario de la empresa, mejoró notablemente.
9
Este antecedente contribuyó, a esta tesis, referencias para teorías relacionadas con
el tema, siendo de soporte para la variable independiente y variable dependiente,
además de la metodología de desarrollo SCRUM y de referencia para el indicador
de rotación de inventario en la discusión de los resultados.
Kevin Cruz Alayo, en el año 2015, en la tesis “Sistema web en el proceso de

operaciones de la empresa promant s.r.l del distrito de san luis” desarrollada en la
prestigiosa casa de estudios superiores César Vallejo, de la capital peruana, el
autor propuso construir un sistema bajo plataforma web para el proceso de
operaciones de dicha organización. Se estudió el nivel de servicio y nivel de
producción. Se tuvo como objetivo ver en qué medida contribuye el sistema en el
proceso de operaciones del negocio antes mencionado. Se empleó la metodología
RUP. Fue un trabajo aplicado de diseño pre-experimental. La muestra empleada
fue de 7 tipos de servicios. En el pre test, el nivel de servicio fue de 82,9% y el nivel
de producción fue de 80,29%. Posterior al uso del software, el nivel de servicio
ascendió a 97,69% y el nivel de producción a 95%. Debido a ello se concluyó que
el software desarrollado mejoró dicho proceso en la empresa.
El aporte de este antecedente fue el indicador de nivel de servicio como referencia

para su medición. Así como para la discusión de los resultados.
Además, Ulises Juarez Ramirez, en el año 2017, en su tesis “Sistema informático

bajo plataforma web para el proceso de control logístico del área de almacén en la
empresa el palacio de las maletas E.I.R.L” realizada en la capital peruana en la
casa de estudios César Vallejo, propuso desarrollar un sistema informático para el
proceso de control logístico del almacén de dicho negocio local. Tuvo como
indicadores el nivel de servicio y la rotación de stock. La finalidad fue clara: verificar
la ascendencia que tiene un sistema informático en el proceso antes mencionado.
Se utilizó SCRUM como metodología de desarrollo de software. Fue un trabajo
aplicado, con un diseño pre experimental. La población utilizada para el indicador
de nivel de servicio fue 14 fichas de registro de pedidos y para la rotación de stock
fue 14 productos. Para el pre test, el nivel de servicio fue de 45% y la rotación de
stock fue 60.08%. Una vez implementado sistema informático el nivel de servicio
10
ascendió a 82.14% y la rotación de stock a un 114.50%. Por estas razones se
aseguró que el software desarrollado mejoró considerablemente el proceso de
control logístico del área de almacén del negocio analizado.
El aporte de esta tesis fue los indicadores de rotación de stock y el nivel de servicio,
tanto como referencia para su medición como en la discusión de los resultados.
1.3 Teorías relacionadas con el tema
A. Control de Inventario
Inventario
Podemos definir el inventario como una lista (realizada en un momento

determinado) de bienes, productos o artículos de un almacén o empresa, la
cual está bien organizada y clasificada (Brenes, 2015, p.158).
Escudero concuerda con Brenes ya que define el inventario como un informe

detallado el cual puede contener materiales, mercancía, etc. de una o varias
empresas en su respectivo almacén y además estos materiales pueden estar
organizados por categorías (Escudero, 2015, p.143).
Control de inventario
Son todas las actividades o prácticas que se tiene en cuenta a la hora de

almacenar los productos; es decir la parte operacional de los inventarios.
Entre estas actividades encontramos: como se debe realizar el conteo de
inventario, cada que tiempo lo debemos hacer, como deben registrarse los
inventarios (las entradas, salidas, fechas, etc.), como se debe realizar las
órdenes de compra, las órdenes de pedido, como podemos asegurar un
almacenamiento adecuado, etc. (Mora, 2014, p.181).
11
Es importante tener presente que el control de inventario debe contemplar
todos los activos de una compañía, tal como indican Sierra, Guzmán y
García (2015): “Es el dominio que se tiene sobre las existencias
pertenecientes a una empresa u organización” (p.8).
Complementario a ello se debe garantizar la exactitud entre los registros, tal

como indica Brenes (2015): “El control interno del almacén se basa en
garantizar la exactitud entre las existencias físicas reales de los artículos
almacenados y los correspondientes registros en el sistema informático o
administrativo correspondiente” (p.159).
Fases para el proceso de control de inventario
La gestión y control de inventario se debe contemplar como un proceso de

manera integral, vale decir que abarca desde el momento que una compañía
compra mercancía hasta el momento que la vende. Es por ello que podemos
discernir las fases de compras, recepción, almacenaje y entrega (Rincón y
Villarreal, 2014, p.65).
Compras: esta fase facilita los componentes indispensables para la

producción, los cuales son adquiridos de los proveedores sean materias
primas o productos finales, en la cantidad requerida, cumpliendo con los
estándares de calidad, al menor costo posible (Rincón y Villarreal, 2014,
p.65).
Recepción: se ocupa de las entradas de mercancías, descarga y

verificación, para que los registros de inventario estén actualizados. Los
responsables de esta fase se encargarán de verificar que las cantidades
entrantes correspondan con las cantidades que están en la orden de compra
generada (Rincón y Villarreal, 2014, p.65).
Almacén: una vez recepcionada la mercancía se procede a su ubicación y

conservación (teniendo en cuenta si se trata de materia prima o productos
finales) con el fin de realizar las operaciones de la empresa con éxito, ya sea
producción o venta final (Rincón y Villarreal, 2014, p.65).
12
Entrega: en esta fase se despacha los productos requeridos por los clientes,
tomando en cuenta que se debe llevar una anotación de las salidas de los
artículos de almacén y así contar con un inventario actualizado; en esta fase
se genera documentación como boletas, facturas, órdenes de venta, etc.
según sea el caso (Rincón y Villarreal, 2014, p.66).
Entonces, como el autor indica el proceso de control de inventario empieza con la

compra de productos (o insumos) y termina con la venta de los mismos a petición
del cliente.
DIMENSIONES E INDICADORES
Dimensión: Almacén
Indicador: Rotación de Inventario
Este indicador mide la cantidad de veces que se sustituye las existencias, en

un negocio o almacén, por mercadería o artículos nuevos en un lapso de
tiempo determinado. Esto hace que este indicador sea muy importante para
monitorear el estado de un almacén (Mora, 2016, p.132).
La rotación de inventario se puede considerar el ciclo que conlleva en

realizarse el inventario, vale decir, en agotarse. Por lo que, mientras más
elevada sea la rotación, denota que el lapso de permanencia de las
mercancías o productos en el inventario de la empresa es menor, lo que as
su vez es un síntoma de una buena gestión de los inventarios (Mora, 2016,
p.133).
Por lo tanto, mientras menor sea el tiempo en que los productos permanecen
en inventario menor es el capital de trabajo y costo de almacenamiento para
la empresa Máxima Tecnología del Perú S.A.C; por el contrario, entre más
dure el inventario en el almacén, mayores serán los gastos operativos.
13
Respecto a la rotación de inventario Ferrín nos indica que es la dimensión
que se encarga de evaluar o valorar el nivel en que se renuevan
determinados productos en un almacén en un tiempo establecido (Ferrín,
2014, p.52).
La rotación de inventario viene dada por la fórmula:
𝐔𝐧𝐢𝐝𝐚𝐝𝐞𝐬 𝐬𝐚𝐥𝐢𝐝𝐚𝐬
𝐑𝐨𝐭𝐚𝐜𝐢ó𝐧 =
𝐔𝐧𝐢𝐝𝐚𝐝𝐞𝐬 𝐬𝐭𝐨𝐜𝐤
Dimensión: Entrega
Indicador: Nivel de servicio
Según Escudero (2015), indica que: “El nivel de servicio es la capacidad que
tiene un establecimiento para atender la demanda de los artículos que
solicitan los clientes en el momento de la compra” (p.113).
El nivel de servicio al usuario o consumidor se calcula estableciendo la

relación entre los productos vendidos y el total de productos solicitados. Para
ello, se aplica la siguiente fórmula:
𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐨𝐬 𝐯𝐞𝐧𝐝𝐢𝐝𝐨𝐬
𝐍𝐢𝐯𝐞𝐥 𝐝𝐞 𝐬𝐞𝐫𝐯𝐢𝐜𝐢𝐨(%) = 𝐱 𝟏𝟎𝟎
𝐓𝐨𝐭𝐚𝐥 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐨𝐬 𝐬𝐨𝐥𝐢𝐜𝐢𝐭𝐚𝐝𝐨𝐬
B. Aplicación Web
Según Cardador (2014), define: “aplicación web al conjunto de herramientas

disponibles por el usuario y que son ofrecidas por un determinado servidor web […].
14
Las aplicaciones web son totalmente independientes del sistema operativo que
haya instalado y del navegador del cliente” (p.29).
Una aplicación web es aquella que normalmente se encuentra alojada en un server,

y se encuentra apta para responder peticiones por parte de un usuario (cliente).
Este usuario tiene acceso a la aplicación por diferentes medios, uno de los más
comunes es mediante un navegador web (Granados, 2014, p.128).
Las aplicaciones web se basan en el modelo client/server y las conexiones no son

persistentes, es decir el cliente realiza una petición al servidor, estableciéndose una
comunicación client-server. Pero una vez el servidor haya atendido la demanda del
cliente ya no es necesario mantener la comunicación con el cliente, puesto que el
servidor solo tiene que atender las peticiones “vivas” en ese momento (Talledo,
2015, pp.75-76).
Arquitectura de una aplicación web
Según Cardador (2015), manifiesta que: “En la arquitectura de una aplicación web
siempre vamos a tener tres componentes fundamentales” (p.30).
Servidor web: es el que distribuye la información en forma de páginas a los

clientes que la solicitan.
Conexión de red: permite distribuir los datos, usamos el protocolo HTTP.
Uno o más clientes: Son los que solicitan los datos al servidor.
Por medio del navegador, el cliente inicia la comunicación y a la vez descifra y

renderiza la información que le suministra el server. Por su parte éste está “atento”
por si nuevos usuarios (clientes) realicen solicitudes para poder dar una respuesta
(recursos, imágenes, data, etc.) correspondiente (Berenguel, 2016, p.127).
Arquitectura Modelo, Vista, Controlador (MVC)
El MVC es un patrón muy utilizado en el desarrollo de software, ya que distingue

tres capas (la interfaz, los datos, y el intermediario) permitiendo así desarrollos
seguros, robustos y mantenibles (Talledo, 2015, p.95).
15
Figura 3: Patrón de diseño MVC
Fuente: Talledo (2015)
Para ello el patrón de diseño MVC, utiliza una terna de elementos o capas
diferentes: el modelo, la vista y el controlador.
MODELO
Es la capa o componente que gestiona las consultas a la información guardada en

la base de datos y a su vez, a través del controlador, responde a la capa view con
la información solicitada (Talledo, 2015, p.95).
VISTA
Este componente muestra al usuario toda la información solicitada; y generalmente

en plataformas web está escrita en el lenguaje de estructura HTML, el lenguaje de
programación JavaScript, así como en el lenguaje de estilos CSS
independientemente de los frameworks fronted utilizados (Talledo, 2015, p.95).
CONTROLADOR
Talledo (2015) menciona que esta capa se encarga de:” responder a eventos, por
ejemplo, las peticiones del usuario para realizar una venta, la búsqueda de
información, poder visualizar uno o más elementos, etc. Estas acciones generan
una solicitud al “modelo” para que se genere un resultado o respuesta” (p.96).
16
Lenguajes de programación
Para la codificación de la aplicación planteada en este trabajo se tomó en cuenta

los siguientes lenguajes de programación.
PHP
Lenguaje interpretado, se utiliza para la creación de páginas web dinámicas, puede

incluirse o embeberse en documentos HTML. PHP es ejecutado por el servidor.
Este tipo de lenguaje es interpretado por lo que no tendrá que ser compilado para
poder ejecutarse (García, 2015, p.54).
Para poder funcionar se necesita instalar Apache o IIS con librerías PHP.
JAVASCRIPT
Según García (2015), menciona que: “Se trata de un lenguaje de scripts […] Es un
lenguaje interpretado, es decir que para ser ejecutado no necesita un intérprete,
será el navegador, quien se ocupará de compilarlo” (p.55).
Sistema de Base de Datos
Al grupo de aplicaciones informáticas cuya función es gestionar una base de datos

se le suele llamar o denominar SBD (Sistema de gestión de base de datos) (Arias,
2014, p.10).
Un gestor de bases de datos existe con el propósito de evitar que el usuario

manipule la base de datos de manera directa; a la vez brindan herramientas para
facilitar la manipulación de la data de una base de datos (Arias, 2014, p.10).
Existen muchos SDB, para las bases de datos relacionales, los sistemas más
populares y utilizados en la actualidad son:
 Oracle
 MySQL
 SQL Server
 PostgreSQL
17
MySQL
Es una base de datos cuya curva de aprendizaje es menor a la de su competencia

(PostgreSQL o SQL Server), pero a su vez ofrece un gran rendimiento y
funcionalidad para casi todo tipo de proyectos; además es opensource.
Cabe resaltar que, en la actualidad, MySQL es muy usado y valorado para el

desarrollo de aplicaciones web en general (Arias, 2014, p.10).
SQL Server
Este poderoso motor de base de datos creado por Microsoft está compuesto por
diferentes servicios; los cuales garantizan su óptimo funcionamiento y escalabilidad
en el tiempo (Gabillaud, 2014, p.41).
Es importante señalar que SQL Server utiliza una variación del estándar de
consultas SQL, denominada Transact SQL con el fin de aumentar el poder de
procesamiento de datos
Oracle
Según Muñoz (2014), asegura que: “Oracle es una base de datos relacional, que
utiliza SQL como lenguaje principal, el cual es muy eficiente y a la vez flexible, con
características muy potentes para la manipulación y examen de los datos
relacionales” (p.1).
Metodología para el desarrollo de una aplicación web
Para desarrollar la aplicación web propuesta se plantean las siguientes

metodologías de desarrollo de software:
18
Metodología RUP
En el desarrollo de aplicaciones y software en general, la metodología RUP, es muy

conveniente y suele adaptarse para proyectos de larga duración. Además, en el
ámbito de la tecnología, es uno de los principales marcos de trabajo para lograr una
certificación (Toro, 2014, p.28).
A su vez este proceso o metodología fue creado por Rational Software, como un
proceso iterativo en la elaboración de aplicaciones informáticas (Granados, 2015,
p.159).
Algunas de las ventajas de utilizar la metodología RUP para el desarrollo de
software son:
 Mejora la productividad del equipo de desarrollo: “Todos los miembros

del equipo tienen acceso a la misma base de conocimiento” (Granados,
2015, p.159).
 Creación y mantenimiento de modelos: “Más allá de acumular un gran
volumen de documentos se intenta enfatizar en el uso de modelos (que son
una representación muy rica, semánticamente hablando, del sistema en
desarrollo)” (Granados, 2015, p.159).
 Uso de UML: “UML es un estándar de la industria que facilita la
representación de requerimientos, arquitecturas y diseños de un lenguaje
común” (Granados, 2015, p.159).
 Soporte de herramientas: “Permite la automatización de partes del
proceso, tales como modelado de manera visual, programación, pruebas,
etc” (Granados, 2015, p.159).
 Integración de buenas prácticas: “RUP conlleva el uso de buenas
prácticas de desarrollo, lo cual aumenta enormemente las posibilidades de
éxito del proyecto” (Granados, 2015, p.159).
Las etapas de esta metodología son:
19
 Fase inicio: Es en esta fase inicial donde se precisa el modelo del negocio
además de la magnitud del proyecto a realizar (Granados, 2015, p.161).
 Fase elaboración: En esta etapa se examina el ámbito de la contrariedad y
se constituyen los soportes de la arquitectura (Granados, 2015, p.161).
 Fase de construcción: “durante la construcción se desarrollan e integran el
resto de componentes y características” (Granados, 2015, p.161).
 Fase de transición: “la fase final es la transición del producto software a la
comunidad de usuarios” (Granados, 2015, p.161).
Con respecto a las fases de RUP encontramos 4, las cuales están claramente
definidas y delimitadas y en cada una de ellas se llevan a cabo distintas acciones
(Granados, 2015, p.85).
Figura 4: Fases de la metodología RUP
Fuente: Brice (2018)
20
Metodología SCRUM
En los últimos años las metodologías agiles han ganado bastante terreno a las
metodologías tradicionales, siendo SCRUM una de las más utilizadas en grandes
empresas de software.
Es habitual utilizar SCRUM para el desarrollo de software, sin embargo, también
puede ser utilizado en proyectos de otra índole (Cervantes, Velasco-Elizondo y
Castro, 2016, p.107).
Scrum al igual que otras metodologías agiles posibilita desarrollar software de una
forma iterativa e incremental. En esta metodología un grupo polivalente y auto-
gestionado concibe de forma progresiva un producto en varias iteraciones cortas.
Cada una de estas iteraciones permite examinar la performance del team, así como
el producto obtenido, para luego, en caso sea necesario, realizar los cambios
solicitados (Cervantes et al, 2016, p.107).
Scrum determina un cúmulo o agrupación de roles y un proceso que se describe a

continuación:
Lo roles
Este marco de trabajo especifica una terna de roles primordiales:
Propietario del producto (product owner): Se encarga de obtener un valor

maximizado del producto que se desarrollará, además de maximizar el
rendimiento del grupo de desarrollo. Sus competencias primordiales son:
definir, priorizar e informar las exigencias del producto, de igual modo
verificar y dar el visto bueno al trabajo y los resultados obtenidos en cada
iteración. (Cervantes et al, 2016, p.108).
Equipo de desarrollo (team): es el grupo encargado de la construcción del

producto, es un equipo multifuncional y auto-organizado. Sus funciones
principales son: decidir que requerimientos se van a desarrollar en una
iteración, cual es la mejor manera para lograrlo. Dentro del equipo no hay
21
roles más específicos para los integrantes (tales como, el de programador o
de diseñador) (Cervantes et al, 2016, p.108).
Maestro Scrum (Scrum master): que la metodología sea asimilada por

todos los miembros del equipo es responsabilidad del scrum master. En otras
palabras, es un facilitador para el product owner y el team. Hay que recalcar
que es diferente al rol de un líder de proyecto, puesto que el scrum master
no da indicaciones al equipo en cuanto a las actividades a realizar. Además,
el maestro scrum incita el correcto uso de prácticas de trabajo eliminando
así cualquier dificultad durante el desarrollo (Cervantes et al, 2016, p.108).
El proceso
Abarca un cúmulo de iteraciones, que por cierto tienen una persistencia

definida, no pueden ser ampliadas y se realizan de manera consecutiva,
hasta que el proyecto se dé por finalizado (Cervantes et al, 2016, p.108).
En esta metodología, una iteración obtiene el nombre sprint, y el tiempo

estimado suele ser de 1 a 4 semanas. En la figura N°5, podemos observar
el proceso scrum, con sus principales ceremonias y artefactos.
22
Figura 5:Proceso Scrum
Fuente: Cervantes, Velasco-Elizondo y Castro (2016)
Metodología XP
Se considera una metodología ágil para desarrollar software y es catalogada como

un conjunto de buenas prácticas que la colectividad de developers viene
perfeccionando con el propósito de solucionar los inconvenientes de entrega de
software de alta calidad, de una manera rápida y así poder satisfacer las
necesidades de negocio que están en constante cambio (Laínez, 2014, p.116).
23
Figura 6: Metodología XP
Fuente: Laínez (2014)
Selección de la metodología
Para poder elegir con que metodología trabajar, en el desarrollo de la web app, se
realizó una comprobación con una terna de especialistas, los cuales cuentan con
amplia experiencia en asesorías de tesis y desarrollo de software. Se utilizó un
formato de juicio de expertos (ver Anexo 6); seguidamente, se muestra una tabla
comparativa de las metodologías con el respectivo puntaje obtenido:
Tabla 1: Validación de expertos para la selección de la

metodología
EXPERTO METODOLOGÍA
NOMBRES Y APELLIDOS RUP XP SCRUM
Mg. Anselmo Valenzuela Cegarra 44 13 45
Mg. Alex Pacheco Pumaleque 30 30 50
Mg. Orleans Gálvez Tapia 40 30 50
TOTAL 114 73 145
24
De la tabla N°1 de validación de expertos podemos observar que la metodología de
mayor puntaje es SCRUM con 145 puntos por lo que la metodología seleccionada
es SCRUM, ya que es una metodología ágil con gran flexibilidad y adaptación,
independientemente del proyecto que se desea realizar
1.4 Formulación del problema
Problema General
¿Cómo influye una aplicación web en el proceso de control de inventario en la
empresa Maxtechperu S.A.C?
Problemas Específicos
PE1: ¿Cómo influye una aplicación web en la rotación de inventario del proceso
de control de inventario en la empresa Maxtechperu S.A.C?
PE2: ¿Cómo influye una aplicación web en el nivel de servicio del proceso de
control de inventario en la empresa Maxtechperu S.A.C?
1.5 Justificación del estudio
Justificación Institucional
Este proyecto de tesis de implementación de una aplicación web contribuye en el

proceso de control de inventarios de la empresa MAXTECHPERU S.A.C logrando
una optimización en la gestión del mismo; y a su vez impactando en todos los
niveles de la organización para poder lograr los objetivos estratégicos de la
empresa siendo reconocida a nivel nacional e internacional.
25
Justificación Económica
Actualmente para realizar el control de inventario en la compañía Maxtechperu

S.A.C se utilizan 4 trabajadores (3 técnicos y la encargada de logística, como
supervisora del proceso). Lo que supone un costo de S/.5500 en salarios (Mensual).
Con la implementación de la web app desarrollada en la presente investigación se
utilizarán solo 2 trabajadores para el mencionado proceso; por lo cual el costo del
proceso sería S/ 3100, lo que supone un ahorro mensual de S/ 2400.
Justificación Operacional
La aplicación web se implementará con una interfaz amigable para el usuario,

garantizando la usabilidad en los diferentes niveles de la organización, así mismo
el personal que labora en la empresa cuenta con los conocimientos de informática
necesarios lo cual justifica operacionalmente este proyecto de investigación.
Justificación Tecnológica
Es de conocimiento que las tecnologías de información cada vez tienen mayor

impacto en las empresas, haciendo de la información un instrumento vital para la
consecución de sus objetivos estratégicos. La aplicación web garantiza la seguridad
de la información que maneja la empresa tanto en la disponibilidad, confidencialidad
e integridad de la data en todos los niveles de la organización, quedando así
justificada tecnológicamente la presente investigación.
26
1.6 Hipótesis
Hipótesis General
La aplicación web mejora el proceso de control de inventario en la empresa
Maxtechperu S.A.C
Hipótesis Específicas
HE1: La aplicación web incrementa la rotación de inventario del proceso de control

de inventario en la empresa Maxtechperu S.A.C
HE2: La aplicación web incrementa el nivel de servicio del proceso de control de

inventario en la empresa Maxtechperu S.A.C
1.7 Objetivo
Objetivo General
Determinar cómo influye una aplicación web en el proceso de control de inventario
en la empresa Maxtechperu S.A.C
Objetivos Específicos
OE1: Determinar la influencia de una aplicación web en la rotación de inventario

para el proceso de control de inventario en la empresa Maxtechperu S.A.C
OE2: Determinar la influencia de una aplicación web en el nivel de servicio para el

proceso de control de inventario en la empresa Maxtechperu S.A.C
27
II. MÉTODO
28
2.1 Diseño de investigación
Método de investigación
Método Hipotético Deductivo
En este método en particular las premisas son consideradas como puntos de

partida para obtener conclusiones nuevas. Partimos de las premisas suscitadas
por datos empíricos hasta llegar a pronósticos sujetos a verificación experimental
(Rodríguez y Pérez, 2017, p.12).
Además, si encontramos una relación con los hechos, se confirma o no la

fidelidad de la premisa de partida (Rodríguez y Pérez, 2017, p.12).
El autor nos indica que como investigadores debemos, en base a los problemas
que se han determinado, proponer hipótesis y comprobar o examinar la validez
o invalidez de éstas.
Tipo de estudio
Explicativa
El objetivo de este tipo de estudio es aclarar por qué motivo ocurre un evento
determinado, y bajo qué situaciones éste se presenta (Hernández et al, 2014,
p.95).
Experimental
En este tipo de estudios aplicamos dos test (pre test y post test) y comprobamos
si el incentivo aplicado tuvo un efecto positivo o negativo en la variable de
estudio. (Sáez, 2017, p.52).
29
Aplicada
Este tipo de estudio busca solucionar un determinado problema poniendo en
práctica la teoría; de allí su nombre. (Sáez, 2017, p.26).
Esta tesis es aplicada – experimental, debido a que se implementará una

aplicación que permitirá solucionar los inconvenientes que presenta la empresa
Maxtechperu S.A.C en su proceso de control de inventario. Una aplicación web
es el producto obtenido de la investigación.
Diseño de estudio
Pre-experimental
Esta tesis es pre-experimental, ya que se evaluó el efecto de la variable

independiente (Aplicación web) sobre la variable dependiente (Proceso de
control de inventario), se consideró cuantificar un grupo, antes y después del uso
de la aplicación web.
Se tiene un grupo de control al cual aplicaremos una prueba, para después

aplicarle un estímulo y finalmente, sobre el mismo grupo, realizaremos otra
prueba para observar si el estímulo aplicado tuvo algún efecto o no sobre éste
(Hernández et al, 2014, p.141).
Figura 7:Diseño de Investigación pre-experimental
G O1 X O2
Fuente: Hernández et al (2014)
30
Dónde:
G: Grupo experimental: muestra a la cual se aplicará la evaluación para

estimar los indicadores rotación de inventario y nivel de servicio.
X: Experimento (Aplicación web): implementación de la web app en el

proceso de control de inventario en la empresa Maxtechperu S.A.C; con
la evaluación respectiva (pre-test y post-test) se podrá aseverar si dicho
software mejora el proceso en cuestión.
O1: Pre-Test: evaluación del G con anterioridad al uso de la aplicación

web.
O2: Post-Test: evaluación del G una vez usada la aplicación web.
2.2 Variables, Operacionalización
Definición Conceptual
VI (Variable Independiente): Aplicación Web
Cardador (2014), especifica que: “aplicación web al conjunto de herramientas

disponibles por el usuario y que son ofrecidas por un determinado servidor web
[…]. Las aplicaciones web son totalmente independientes del sistema operativo
que haya instalado y del navegador del cliente” (p.29).
31
VD (Variable Dependiente): Proceso de control de inventario
El control de inventario, en un negocio o compañía, hace referencia al control o

dominio sobre sus bienes, artículos o productos (Sierra, Guzmán y García, 2015,
p.8).
Definición Operacional
VI (Variable Independiente): Aplicación Web
Es una aplicación que almacena y procesa datos o información de manera

oportuna para optimizar el proceso en cuestión, que hoy por hoy se lleva a cabo
de forma manual y con deficientes resultados en la empresa Maxtechperu S.A.C
VD (Variable Dependiente): Proceso de control de inventario
Automatizar las diferentes actividades que se ejecutan para realizar el proceso

de control de inventario, desde la fase inicial que es compras hasta la fase final
que es despacho o entrega de artículos a la clientela.
32
Tabla 2: Operacionalización de las variables
Variable Definición Definición Dimensión Indicador Instrumento

conceptual operacional
Aplicación “aplicación web al Es una aplicación que
conjunto de herramientas almacena y procesa
web
disponibles por el usuario datos o información de
y que son ofrecidas por un manera oportuna para
determinado servidor web optimizar el proceso en --------------------------------
[…]. Las aplicaciones web cuestión, que hoy por
son totalmente hoy se lleva a cabo de
independientes del forma manual y con
sistema operativo que deficientes resultados
haya instalado y del en la empresa
navegador del cliente” Maxtechperu S.A.C
Control El control de inventario, Automatizar las

en un negocio o diferentes actividades
de Almacén Rotación Ficha de
compañía, hace que se ejecutan para
inventario de registro
referencia al control o realizar el proceso de
dominio sobre sus bienes, control de inventario,
Inventario
artículos o productos desde la fase inicial que
es compras hasta la Entrega Nivel de Ficha de
fase final que es
Servicio registro
despacho o entrega de
artículos a la clientela.
33
2.3 Población y muestra
Población
La población es una agrupación de unidades o elementos los cuales presentan una
determinada característica (Lerma, 2016, p.72).
En este trabajo de investigación, la población está conformada por 28 productos

para el cálculo de la rotación de inventario y 89 órdenes de venta para el cálculo
del nivel de servicio.
Muestra
Es un subapartado o subgrupo representativo de la población de la cual se llevará
a cabo un estudio (Hernández et al, 2014, p. 173). Hallamos la muestra, a partir de
la población seleccionada, utilizando la siguiente formula
𝐙𝟐𝐍
𝐧= 𝟐
𝐙 + 𝟒𝐍(𝐄𝐄𝟐 )
Donde:
n= Tamaño de la muestra
Z= Nivel de confianza al 95% (1.96) elegido para esta investigación
N= Población total de estudio
EE= Error estimado (al 5%)
34
Muestra 1
Cálculo de la muestra para la rotación de inventario:
(𝟏. 𝟗𝟔)𝟐 (𝟐𝟖)

𝐧=
(𝟏. 𝟗𝟔)𝟐 + 𝟒(𝟐𝟖)(𝟎. 𝟎𝟓)𝟐
𝟏𝟎𝟕. 𝟓𝟔𝟓
𝐧=
𝟒. 𝟏𝟐𝟏𝟔
𝐧 = 𝟐𝟔. 𝟎𝟗𝟕𝟖… → 𝐧 ≅ 26
Para muestras menores a 50 se recomienda tomar la totalidad de la

población como muestra (Castro, 2014, p.168).
La población para la rotación de inventario es 28 productos, la cual es

claramente inferior a 50; por consiguiente, se empleó la totalidad de la
población como muestra; es decir la muestra para la rotación de inventario
queda definida en 28 productos.
Muestra 2
Cálculo de la muestra para el nivel de servicio:
(𝟏. 𝟗𝟔)𝟐 (𝟖𝟗)

𝐧=
(𝟏. 𝟗𝟔)𝟐 + 𝟒(𝟖𝟗)(𝟎. 𝟎𝟓)𝟐
𝟑𝟒𝟏. 𝟗𝟎𝟐𝟒
𝐧=
𝟒. 𝟕𝟑𝟏𝟔
𝐧 = 𝟕𝟐. 𝟐𝟓𝟗𝟑… → 𝐧 ≅ 72
35
Para nuestro indicador de nivel de servicio se calculó que la muestra es 72
órdenes de venta, las cueles fueron estratificadas por 24 días. Es por ello
que, la muestra fue constituida por 24 fichas de registro.
Muestreo: Aleatorio Simple
Según Drennan y González (2019), afirman que: “El muestreo aleatorio simple,
como su nombre lo indica, es el método más simple y directo para seleccionar una
muestra aleatoria” (p. 99). En este sentido se justifica su uso para determinar la
muestra deseada.
Precisamente este fue el tipo de muestreo utilizado en esta tesis, debido a que
contamos con una determinada población y cada uno de los sujetos tiene la misma
posibilidad de ser seleccionados.
2.4 Técnicas e instrumentos de recolección de datos, validez y confiabilidad
Técnica
Fichaje
Esta técnica en especial nos brinda la posibilidad de registrar datos o

información seleccionada a lo largo de una investigación. Para utilizar esta
técnica se emplean fichas con el fin de recolectar y estructurar la información
obtenida de fuentes diversas (Parraguez, 2017, p.150). Como indica el autor,
el fichaje, es un instrumento valioso y necesario para una investigación.
El fichaje nos permite almacenar los datos necesarios para los indicadores
rotación de inventario y nivel de servicio.
Instrumento de investigación
Ficha de registro
Las fichas de registro nos permiten registrar datos de una investigación en

cuestión (Muñoz, 2015, p.120).
36
Por consiguiente, se procedió a elaborar dos fichas de registro. Cada ficha
fue utilizada para registrar la data de un indicador en concreto.
Validez
En trabajos de investigación (incluida la presente tesis), la validez, hace alusión al
nivel en que una herramienta o instrumento realmente calcula o evalúa la variable
que procura o desea evaluar (Hernández et al, 2014, p.200).
Validez de contenido
Hace referencia al nivel que un instrumento plasma un dominio particular de
argumento de lo que se evalúa, en términos sencillos es el nivel en que la
evaluación o medición representa a la variable evaluada (Hernández et al, 2014,
p.201).
Validez de criterio
Este tipo de validez se constituye al cotejar los resultados, con criterios externos
o ajenos a la investigación, los cuales procura calcular lo mismo (Hernández et
al, 2014, p.202).
Validez de constructo
Probablemente la validez más importante en un trabajo de investigación; esta
validez hace referencia a que tan bien un instrumento simboliza y evalúa una
concepción teórica (Hernández et al, 2014, p.203).
El instrumento utilizado en esta indagación fue la ficha de registro. La cual fue

validada en base al entendimiento de tres duchos en la materia tal como se puede
contemplar en la siguiente tabla:
37
Tabla 3:Validez de las fichas de registro
Expertos Grado Puntaje: Puntaje:
Académico Rotación de Nivel de
Inventario Servicio
Alex Pacheco Pumaleque Magister 86 85
Ardiel Hilario Castañeda Doctor 85 92
Alejandro Ramírez Ríos Doctor 87 88
Las fichas de registro fueron presentadas a una terna de diestros para su respectiva
validación (ver Anexo 6), el puntaje promedio que se obtuvo de la evaluación fue
de 87,16% lo que nos asegura un alto nivel de confianza de que los instrumentos
son los idóneos para obtener los datos de los indicadores planteados.
Confiabilidad
En los trabajos de investigación, entendemos que un instrumento de medición es

confiable o tiene confiabilidad cuando puede ser aplicado de manera repetitiva, a
un mismo objeto, y los resultados producidos son iguales (Hernández et al, 2014,
p.200).
Método: Test – Retest
Es importante contar con un coeficiente de estabilidad en nuestras investigaciones,

dicho coeficiente nos garantiza que al aplicar el mismo test en distintos tiempos
tengamos una dimensión de la solidez en el tiempo; y llamamos método test-retest
al procedimiento utilizado para hallar dicho coeficiente (Navas, 2015, p. 220).
Técnica: Coeficiente de correlación de Pearson
Cuando analizamos la relación de dos variables, calculadas por intervalos, se suele

utilizar este coeficiente, ya que es una de las pruebas estadísticas mejor valoradas
por los diestros en la materia (Hernández et al, 2014, p.304).
38
Para obtener la correlación de los instrumentos de investigación utilizados en este
proyecto y con la finalidad de ratificar su confiabilidad, se utilizó esta prueba
estadística.
Para calcular este coeficiente debemos partir de las valoraciones alcanzadas en un

modelo en dos variables. Debemos vincular las valoraciones conseguidas de una
variable con las valoraciones de la otra (Hernández et al, 2014, p.305).
Tabla 4:Nivel de Confiabilidad

Coeficiente Correlación
0.00 No existe
0.10 Muy débil
0.25 Débil
0.50 Media
0.75 Considerable
0.90 Muy fuerte
1.00 Perfecta
Fuente: Hernández, Fernández y Baptista (2014)
Seguidamente podemos contemplar que el valor de la confiabilidad que presenta el

índice de rotación de inventario es de 0,887; y se encuentra en un nivel considerable
(Ver tabla N°4). Por consiguiente, el instrumento planteado para medirlo es
confiable.
Tabla 5:Resultado de confiabilidad del índice de rotación de inventario
39
Sumado a ello podemos contemplar que el valor de la confiabilidad que presenta el
índice de nivel de servicio es de 0,910; y se encuentra en un nivel muy fuerte (Ver
tabla N°4). Por consiguiente, el instrumento planteado para medirlo es confiable.
Tabla 6: Resultado de confiabilidad del índice de nivel de servicio
2.5 Métodos de análisis de datos
Hay dos puntos importantes que debemos tener en consideración al examinar datos
cuantitativos; el primero es que los modelos estadísticos son representaciones de
la materialidad y no la realidad en sí; el segundo y no menos importante es que los
resultados numéricos debemos interpretarlos según el ambiente o entorno
(Hernández et al, 2014, p. 270).
Se realizó una evaluación de datos cuantitativa, por el motivo que la estadística y

los modelos matemáticos fueron empleados para representar datos y resultados
del proyecto. Para la contrastación de hipótesis se utilizó la técnica T-Student; con
ella se comparó los resultados obtenidos del Pre-Test con los logrados después del
uso de la aplicación web.
Hipótesis de Investigación 1
a) Indicador: Rotación de Inventario
40
IRa = Rotación de inventario anterior al uso del aplicativo web
IRd = Rotación de inventario posterior al uso del aplicativo web
b) Hipótesis Específica 1 (HE1)
La aplicación web incrementa el índice de rotación de inventario del

proceso de control de inventario en la empresa Maxtechperu S.A.C.
c) Hipótesis Estadística 1
Hipótesis Nula (H0): La aplicación web no incrementa el índice de

rotación de inventario del proceso de control de inventario en la
empresa Maxtechperu S.A.C
H0: IRa ≥ IRd
Hipótesis Alternativa (HA): La aplicación web incrementa el índice

de rotación de inventario del proceso de control de inventario en la
empresa Maxtechperu S.A.C
HA: IRa < IRd
Hipótesis de Investigación 2
a) Indicador: Nivel de Servicio
INSa = Nivel de Servicio anterior al uso del aplicativo web

INSd = Nivel de Servicio posterior al uso del aplicativo web
b) Hipótesis Específica 2 (HE2)
La aplicación web incrementa el nivel de servicio en el proceso de

control de inventario en la empresa Maxtechperu S.A.C.
41
c) Hipótesis Estadística 2
Hipótesis Nula (H0): La aplicación web no incrementa el nivel de

servicio en el proceso de control de inventario en la empresa
Maxtechperu S.A.C.
H0: INSa ≥ INSd
Hipótesis Alternativa (HA): La aplicación web incrementa el nivel

de servicio en el proceso de control de inventario en la empresa
Maxtechperu S.A.C.
HA: INSa < INSd
2.6 Aspectos éticos
Para la elaboración de este proyecto se siguieron los estatutos y códigos de la

Universidad Cesar Vallejo.
Se reservó la identidad de los escritos publicados que participan en la investigación

y de las conclusiones obtenidas.
Se honró a los colaboradores, no se realizó ningún tipo de discriminación,

previamente se solicitó el consentimiento y los permisos necesarios a la empresa
Maxtechperu S.A.C
Finalmente, los resultados obtenidos en este proyecto no han sido falsificados o

reproducidos de otras indagaciones, haciéndose correcto uso de la investigación
para la utilidad de todos.
42
III. RESULTADOS
43
3.1 Análisis Descriptivo
En esta tesis se implementó una aplicación web para estimar la rotación de

inventario y el nivel de servicio en el proceso de control de inventario en la compañía
Maxtechperú S.A.C. Aplicamos un Pre-Test que sirvió para comprender las
circunstancias de partida de los indicadores. Posteriormente implementamos y
empleamos la aplicación web y nuevamente se evaluó los indicadores
mencionados para corroborar si hubo o no una mejoría sobre estos.
En las tablas N° 7 y N° 8 podemos contemplar los resultados descriptivos.
INDICADOR 1: Rotación de inventario
Seguidamente podemos observar los resultados descriptivos de este indicador.
Tabla 7: Medidas descriptivas de la rotación de inventario en el proceso de

control de inventario antes y después de la implementación de la aplicación
web.
De lo obtenido en la tabla anterior, para la rotación de inventario, podemos aseverar

un valor de 0,49 en el pre-test y 0,77 para el post-test. Como se puede confirmar
en la figura N° 8. Todo ello demuestra una notoria diferencia anterior al uso del
aplicativo web y posterior a su uso. Aportando un dato más se debe mencionar que
el valor mínimo del indicador fue de 0,27 a 0,65.
44
En la rotación de inventario, con respecto a su dispersión, se alcanzó una
variabilidad de 0,11 para el pre-test; mientras que en el post-test se alcanzó un valor
de 0,082.
Figura 8: Rotación de inventario antes y después de implementar la

aplicación web
INDICADOR 2. Nivel de servicio

Seguidamente podemos observar los resultados descriptivos de este indicador.
Tabla 8: Medidas descriptivas del nivel de servicio en el proceso de control

de inventario antes y después de la implementación de la aplicación web.
45
De lo obtenido en la tabla anterior, para el nivel de servicio, podemos aseverar una
estimación de 72,34% en el pre-test y 92,68% para el post-test. Como se puede
confirmar en la figura N° 9. Todo ello demuestra una notoria diferencia anterior al
uso del aplicativo web y posterior a su uso. Aportando un dato más se debe
mencionar que el valor mínimo del indicador fue de 37,50% a 77,78%.
En el nivel de servicio, con respecto a su dispersión, se alcanzó una variabilidad de

15,59% para el pre-test; mientras que en el post-test se alcanzó un valor de 6,63%.
Figura 9: Porcentaje del nivel de servicio antes y después de implementar la

aplicación web
3.2 Análisis Inferencial
Prueba de normalidad
Se realizó las verificaciones de normalidad para ambos indicadores (rotación de

inventario y nivel de servicio) mediante el método de Shapiro-Wilk, debido a que la
muestra para ambos indicadores es menor a 50. Para realizar esta importante
prueba se introdujeron los datos de cada uno de los indicadores de estudio en el
aplicativo SPSS 25.0.
46
Para ambos indicadores se utilizó un nivel de significancia del 95% bajo las
siguientes condiciones:
Si:
Sig. < 0.05 Adopta una distribución no normal.
Sig. ≥ 0.05 Adopta una distribución normal.
Donde:
Sig.: P – Valor o nivel crítico del contraste.
Los valores que se obtuvieron fueron se muestran a continuación:
INDICADOR: Rotación de inventario
Con el propósito de distinguir la prueba de hipótesis para el indicador, los datos se

sometieron al aplicativo SPSS 25.0, para la constatación de la distribución,
básicamente para determinar si los datos de este indicador, expresan una
distribución normal.
Tabla 9: Prueba de normalidad de la rotación de inventario antes y después

de implementar la aplicación web
Shapiro-Wilk
Estadístico gl Sig.
Pre_Test_Rotación_inventario 0,981 28 0,881
Pos_Test_Rotación_inventario 0,955 28 0,264
De lo obtenido en la tabla anterior, podemos asegurar que el rendimiento alcanzado

en la prueba muestra que el Sig. en este indicador fue de 0.881 para el pretest,
siendo esta cantidad superior a 0.05. Por consiguiente, la rotación de inventario se
distribuye de manera normal.
47
Además, el Sig. del indicador para el postest fue de 0.264, el cual también es
superior a 0.05. Por consiguiente, la rotación de inventario se distribuye de manera
normal.
Con esas pruebas confirmamos una distribución normal para ambos datos de la
muestra, como se refleja en los siguientes gráficos.
Figura 10: Prueba de normalidad de la rotación de inventario antes de

implementar la aplicación web
48
Figura 11: Prueba de normalidad de la rotación de inventario después de
INDICADOR: Nivel de servicio
Con el propósito de distinguir la prueba de hipótesis para el indicador, los datos se

sometieron al aplicativo SPSS 25.0, para la constatación de la distribución,
básicamente para determinar si los datos de este indicador, expresan una
distribución normal.
Tabla 10: Prueba de normalidad del nivel de servicio antes y después de

Shapiro-Wilk
Estadístico gl Sig.
Pre_Test_Nivel_servicio 0,967 24 0,596
Pos_Test_Nivel_servicio 0,878 24 0,080
49
De lo obtenido en la tabla anterior, podemos asegurar que el rendimiento alcanzado
en la prueba muestra que el Sig. en este indicador fue de 0.596 para el pretest,
siendo esta cantidad superior a 0.05. Por consiguiente, el nivel de servicio se
distribuye de manera normal.
Además, el Sig. del indicador para el postest fue de 0.080, el cual también es
superior a 0.05. Por consiguiente, el nivel de servicio se distribuye de manera
normal.
Con esas pruebas confirmamos una distribución normal para ambos datos de la
muestra, como se refleja en los siguientes gráficos.
Figura 12: Prueba de normalidad del nivel de servicio antes de implementar

la aplicación web
50
Figura 13: Prueba de normalidad del nivel de servicio después de
3.3 Prueba de hipótesis
Hipótesis de investigación 1:
 H1: La aplicación web incrementa la rotación de inventario del proceso de
control de inventario en la empresa Maxtechperu S.A.C
 Indicador: Rotación de inventario
Hipótesis estadística
Definición de variables:
RIa: Rotación de inventario anterior al uso del aplicativo web.
RId: Rotación de inventario posterior al uso del aplicativo web.
51
 H0: La aplicación web no incrementa la rotación de inventario en el proceso
de control de inventario en la empresa Maxtechperu S.A.C
H0: RIa ≥ RId
El indicador sin la aplicación web es mejor que el indicador con la aplicación web.
 HA: La aplicación web incrementa la rotación de inventario en el proceso de

HA: RIa < RId
El indicador con la aplicación web es mejor que el indicador sin la aplicación web.
En el siguiente gráfico se refleja que la rotación de inventario para el pretest fue

0.49 y para el postest alcanzó la cifra de 0.77.
Figura 14: Rotación de inventario - Comparativa general
52
Observando la figura anterior (N° 14) podemos confirmar el notable incremento que
sufrió la rotación de inventario, que asciende de 0.49 a 0.77
Como prueba, para poder contrastar las hipótesis, se empleó T-Student, debido a
que los datos obtenidos a lo largo del proyecto (pretest y postest) se distribuyeron
de forma normal. T contraste alcanzó un valor de -11,976 (Ver tabla N°11), el cual
es muy inferior a - 1.7033 (Ver Figura N°13).
Tabla 11: Prueba T-Student para la rotación de inventario en el proceso de

control de inventario antes y después de implementar la aplicación web
Prueba de T-Student
Media Desv. Sig.
T gl
Desviación (bilateral)
Pre_Test_RI 0,4854
0,12624 -11,976 27 0,000
Pos_Test_RI 0,7711
Aplicando la fórmula T Student:
x−μ
𝑇𝑐 =
s / √N
Donde:
x: Media del pretest
μ: Media del postest
s: Desviación estándar muestral
n: Tamaño de la muestra
x−μ
𝑇𝑐 =
s / √N
53
0.4854 − 0.7711
𝑇𝑐 =
0.12624 / √28
−0.2857
𝑇𝑐 =
0.0238571175363424
𝑇𝑐 = −11.976
De la tabla T Student observamos que el valor de T es -1.7033, ya que el grado de

libertad y el nivel de confianza es 27 y 0.05 respectivamente.
54
Figura 15: Prueba T-Student - Rotación de inventario
Tal como indica la figura N°15, el valor T obtenido se sitúa en la región de rechazo.
Es por esta razón que la hipótesis nula se rechaza y desde luego la hipótesis alterna
se acepta con un 95% de confianza. La aplicación web incrementa la rotación de
inventario en el proceso de control de inventario en la empresa Maxtechperu S.A.C
Hipótesis de investigación 2:
 H1: La aplicación web incrementa el nivel de servicio del proceso de control de

inventario en la empresa Maxtechperu S.A.C
 Indicador: Nivel de servicio
Hipótesis estadística
Definicion de varibales:
NSa: Nivel de servicio anterior al uso del aplicativo web.
NSd: Nivel de servicio posterior al uso del aplicativo web.
 H0: La aplicación web no incrementa el nivel de servicio en el proceso de

55
H0: NSa ≥ NSd
El indicador sin la aplicación web es mejor que el indicador con la aplicación web.
 HA: La aplicación web incrementa el nivel de servicio en el proceso de control

de inventario en la empresa Maxtechperu S.A.C
HA: NSa < NSd
El indicador con la aplicación web es mejor que el indicador sin la aplicación web.
En el siguiente gráfico se refleja el nivel de servicio para el pretest fue 72.34% y

para el postest alcanzó la cifra de 92.68%.
Figura 16: Nivel de servicio - Comparativa general
Observando la figura anterior (N° 16) podemos confirmar el notable incremento que
sufrió el nivel de servicio, que asciende de 72.34% a 92.68%
Como prueba, para poder contrastar las hipótesis, se empleó T-Student, debido a
que los datos obtenidos a lo largo del proyecto (pretest y postest) se distribuyeron
de forma normal. T contraste alcanzó un valor de -6,469 (Ver tabla N°12), el cual
es muy inferior a - 1.7139 (Ver Figura N°15).
56
Tabla 12: Prueba T-Student para el nivel de servicio en el proceso de control
de inventario antes y después de implementar la aplicación web
Prueba de T-Student
Media Desv. Sig.
T gl
Desviación (bilateral)
Pre_Test_NS 72,3367
15,40322 -6,469 23 0,000
Pos_Test_NS 92,6758
Aplicando la fórmula T Student:
x−μ
𝑇𝑐 =
s / √N
Donde:
x: Media del pretest
μ: Media del postest
s: Desviación estándar muestral
n: Tamaño de la muestra
x−μ
𝑇𝑐 =
s / √N
72.3367 − 92.6758
𝑇𝑐 =
15.40322 / √24
−20.3391
𝑇𝑐 =
3.144169116319392
𝑇𝑐 = −6.469
57
De la tabla T Student observamos que el valor de T es -1.7139, ya que el grado de
libertad y el nivel de confianza es 23 y 0.05 respectivamente.
58
Figura 17: Prueba T-Student - Nivel de servicio
Tal como indica la figura N°17, el valor T obtenido se sitúa en la región de rechazo.
Es por esta razón que la hipótesis nula se rechaza y desde luego la hipótesis alterna
se acepta con un 95% de confianza. La aplicación web incrementa el nivel de
servicio en el proceso de control de inventario en la empresa Maxtechperu S.A.C
59
IV. DISCUSIÓN
60
Con los resultados obtenidos en el proyecto y desarrollo de tesis podemos
confirmar que, con el uso de la aplicación web desarrollada para la empresa, se
logró incrementar la rotación de inventario de 0.49 que representa un 49% a un
0.77 lo que representa un 77%; lo que equivale a un incremento de 0.28 lo que
representa un 28%. Asimismo, Chipana Barrientos, en su investigación “Sistema
[…]” consiguió aumentar la rotación de inventario de 50.24% a un 88.76%, lo que
evidencia un incremento de 38.52 %.
En tal sentido, Izquierdo Aylas, en su investigación “Sistema […]” consiguió

incrementar la rotación de inventario de 37,31% a un 55,56%, lo que evidencia un
aumento del 18.25%.
Por su parte, Romero Meza, en la tesis “Sistema […]” consiguió incrementar la

rotación de inventario de 0.87 a 1.49, lo que evidencia un aumento de 0.62.
Por lo que se confirma que implementando y usando un aplicativo web para el

proceso control de inventario se incrementa la rotación de inventario.
Sumado a ello se obtuvieron los resultados con respecto al nivel de servicio, con el
uso de la aplicación web desarrollada para la empresa, se logró incrementar el nivel
de servicio de 72.34% a un 92.68%; lo que equivale a un incremento del 20.34%.
Asimismo, Cruz Alayo, en su investigación “Sistema web en el proceso de
operaciones de la empresa promant s.r.l del distrito de san luis” consiguió aumentar
el nivel de servicio de 82.90% a un 97.69%, lo que evidencia un incremento de
14.79%.
Por otro lado, Chipana Barrientos, en su tesis citada previamente, consiguió

aumentar el nivel de cumplimiento de despacho de 49.44% a un 86.59%, lo que
evidencia un incremento del 37.15%.
Por lo que se confirma que implementando y usando un aplicativo web para el

proceso control de inventario se incrementa el nivel de servicio.
61
V. CONCLUSIONES
62
Basándonos en los resultados conseguidos en esta tesis:
Se concluye que, se logró un aumento significativo en la rotación de inventario,

dicho incremento lo podemos corroborar al parangonar las medias respectivas, que
asciende de 0.49 (sin el uso de la aplicación web) al valor de 0.77 (después de
implementar y hacer uso correcto de la aplicación web), lo que supone un
incremento de un 0.28.
Así mismo, se consiguió optimizar el nivel de servicio, y al igual que el incremento

anterior lo podemos corroborar al parangonar las medias respectivas, que asciende
de 72.34% (sin el uso de la aplicación web) al valor de 92.68% (después de
implementar y hacer uso correcto de la aplicación web), lo que supone un
incremento de un 20.34%.
Finalmente, se rechazan las hipótesis nulas aceptando las hipótesis alternas: “La
aplicación web incrementa la rotación de inventario en el proceso de control de
inventario en la empresa Maxtechperu S.A.C” y “La aplicación web incrementa el
nivel de servicio del proceso de control de inventario en la empresa Maxtechperu
S.A.C” por lo tanto llegamos a la conclusión que implementando y usando la
aplicación web se mejora el proceso de control de inventario en la empresa
Maxtechperu S.A.C; con un 95% de confiabilidad, logrando así satisfacer los
propósitos de esta investigación.
63
VI. RECOMENDACIONES
64
Se aconseja realizar las formaciones respectivas a los usuarios que harán uso de
la aplicación web, con el propósito de que puedan utilizar la aplicación de manera
correcta; de igual manera es recomendable dedicar recursos en tecnologías que
aporten en los diversos procesos en la empresa Maxtehcperu S.A.C
Así mismo se sugiere desarrollar nuevos módulos, para la aplicación web,

orientados a otros procesos del negocio. De esta manera la aplicación no solo se
enfocará en el proceso de control de inventario, sino que abarcará otros procesos,
optimizando y automatizando los procedimientos que efectúa la empresa
Maxtechperu S.A.C.
Para investigaciones posteriores se sugiere considerar el indicador de rotación de

inventario, pues permite tener un panorama del grado de renovación de los
productos almacenados en la empresa.
Para investigaciones posteriores se sugiere considerar el indicador de nivel de

servicio, pues permite conocer la capacidad que tiene la empresa para atender la
demanda de los productos por parte del cliente.
65
VII. REFERENCIAS
ARIAS, Miguel Ángel. Bases de datos con MySQL. Estados Unidos: Createspace
Independent Publishing Platform, 2014. 10p.
ISBN: 9781495480089
BERENGUEL, José. Desarrollo de aplicaciones web en el entorno servidor. Madrid:

Ediciones Parainfo, 2016. 127p.
ISBN: 9788428397179
BRENES, Pedro. Técnicas de almacén. Madrid: Editex, 2015. 158-159p.

ISBN: 9788490785126
BRICE, Guérin. Gestión de proyectos informáticos. 3 a . Ed. Barcelona: Eni, 2018.

85p.
ISBN: 9782409016400
CARDADOR, Antonio Luis. Implantación de aplicaciones web en entornos internet,

intranet y extranet. Málaga: IC Editorial, 2014. 29-30p.
ISBN: 9788416433094
CERVANTES, Humberto, VELASCO, Perla y CASTRO, Luis. Arquitectura de

software conceptos y ciclo de desarrollo. Mexico D.F.: Cengage Learning Editores,
2016. 107pp.
ISBN: 9786075224565
CHOQUE, Jorge. Llegó la hora de piquear. Gestión Logística: El Músculo del

Almacén, (2):19-24, junio 2016.
DRENNAN, Robert y GONZÁLEZ, Víctor. Estadística para arqueólogos. Bogotá:

Ediciones Uniandes, 2019.99pp
ISBN: 9789587748000
66
El estudio y la investigación documental por Simona Parraguez [et al.]. Chiclayo:
Emdecosege, 2017.150pp.
ISBN: 9786120026038
ESCUDERO, José. Técnicas de almacén. España: Paraninfo, 2015.113pp.

ISBN: 9788497322577
ESCUDERO, José. Técnicas de almacén. España: Paraninfo, 2015.143pp.

ISBN: 9788497322577
FERRÍN, Arturo. Gestión de stocks en la logística de almacenes. 3 a . Ed. Bogotá:

Ediciones de la U, 2013. 52-53pp.
ISBN: 9789587621747
GABILLAUD, Jerome. SQL Server 2014, Transact SQL Diseño y creación de una
base de datos. Barcelona: ENI, 2015. 41pp.
ISBN: 9782746095526
GARCÍA, Ana Belén. Modelo de programación web y bases de datos. España:

Elearning, 2015. 54-55p.
ISBN: 9788416492596
GRANADOS, Rafael. Desarrollo de aplicaciones web en el entorno servidor.

Málaga: IC Editorial, 2014. 128p.
ISBN: 9788416433063
HERNÁNDEZ, Roberto, Fernández, Carlos y BAPTISTA, Pilar. Metodología de la

investigación. 6ª. Ed. Mexico D.F.: McGRAW-HILL, 2014. 200p.
ISBN: 9781456223960

investigación. 6ª. Ed. Mexico D.F.: McGRAW-HILL, 2014. 201p.
ISBN: 9781456223960
67
investigación. 6ª. Ed. Mexico D.F.: McGRAW-HILL, 2014. 304-305p.
ISBN: 9781456223960
LAÍNEZ, José. Desarrollo de software ágil: extreme programming y scrum. Madrid:

CreateSpace Independent Publishing Platform, 2014. 116p.
ISBN: 9781502952226
LOPES-MARTINEZ, Igor y GOMEZ-ACOSTA, Martha Inés. Auditoría logística para

evaluar el nivel de gestión de inventarios en empresas. Ing. Ind. [online]. 2013,
vol.34, n.1 [citado 2018-04-26], pp. 108-118.
Disponibleen:<http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S1815-
59362013000100011&lng=es&nrm=iso>. ISSN 1815-5936.
MARTÍNEZ, Alejandro. Aplicación web para el control de los inventarios y el stock

con tecnología RFID. Tesis para optar al título de ingeniero de sistemas,
Universidad Politécnica de Valencia, 2016.
MORA, Alberto. Inventario cero cuánto y cuándo pedir. Bogotá: Alfaomega, 2016.
132-133p.
ISBN: 9789587780697
MORA, Luis. Indicadores de la gestión logística. 2 a Ed. Bogotá: Ecoe Ediciones,

2017. 2p.
ISBN: 9789586485630
MORA, Luis. Gestión logística en centro de distribución, bodegas y almacenes.

Bogotá: Ecoe Ediciones, 2013. 181p.
ISBN: 9789586487221
MUÑOZ, Antolín. Oracle 11g PL/SQL Curso práctico de formación. Madrid: RC

Libros, 2014. 1p.
ISBN: 9788493945015
68
MUÑOZ, Carlos. Metodología de la investigación. Mexico D.F.: Oxford, 2015. [120]
p.
ISBN: 9786074265422
NAVAS, José. Métodos, diseños y técnicas de investigación psicológica [en línea].

Madrid, España: Uned, 2015 [citado 2018-05-02]. Disponible en:
https://books.google.com.pe/books?id=zbKzhysHsxUC&printsec=frontcover&hl=es
&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
ISBN: 9788436250220
RINCÓN, Carlos y VILLARREAL, Fernando. Costos decisiones empresariales.

Bogotá: Ecoe Ediciones, 2013. 65p.
ISBN: 9789586486163
RODRÍGUEZ, Andrés y Pérez, Alipio. Métodos científicos de indagación y

construcción del conocimiento. Revista escuela de administración de negocios [en
línea]. 2017, n°82. [Fecha de consulta: 8 de mayo de 2018]. Disponible en
https://www.redalyc.org/pdf/206/20652069006.pdf
ISSN: 01208160
SÁEZ, José. Investigación educativa, fundamentos teóricos, procesos y elementos

prácticos. Madrid: Universidad Nacional de Educación a Distancia, 2017.26-52p.
ISBN: 9788436272208
SIERRA, Jorge, GUZMÁN María V. Y GARCÍA, Francisco. Administración de

almacenes y control de inventarios [en línea].
TALLEDO, José. Implantación de aplicaciones web en entornos internet, intranet y

extranet. España: Ediciones Paraninfo, 2015.75-76p.
ISBN: 9788428397346
TORO, Francisco. Administración de proyectos de informática. Bogotá: Ecoe

Ediciones, 2014. 28p.
ISBN: 9789586488167
69
ANEXOS
70
Anexo 1: Matriz de Consistencia
71
Anexo 2: Confiabilidad de instrumento - Rotación de Inventario
72
73
Anexo 3: Confiabilidad de instrumento – Nivel de servicio
74
75
Anexo 4: Validación de metodología
76
77
78
Anexo 5: Validación de instrumento Rotación de Inventario
79
80
81
Anexo 6: Validación de instrumento Nivel de Servicio
82
83
84
Anexo 7: Instrumento de investigación – Rotación de inventario
85
86
Anexo 8: Instrumento de investigación – Nivel de servicio
87
88
Anexo 9: Entrevista
89
90
Anexo 10: Constancia de Proyecto de Investigación
91
Anexo 11: Constancia de Implementación
92
DESARROLLO DE LA METODOLOGÍA
ÍNDICE
I. INTRODUCCIÓN .................................................................................................................7
1.1 ALCANCE ....................................................................................................................7
1.2 EQUIPO SCRUM .........................................................................................................8
1.3 VALORES DE TRABAJO ..........................................................................................8
II. PLANEACIÓN DEL PRODUCTO......................................................................................9
2.1 HISTORIAS DE USUARIO .........................................................................................9
2.2 PRODUCT BACKLOG.............................................................................................. 19
2.3 SPRINT BACKLOG .................................................................................................. 21
2.3.1 Definición del sprint .............................................................................................. 22
2.3.2 Construcción del sprint ........................................................................................ 22
III. DESARROLLO DE SPRINTS ...................................................................................... 23
3.1 SPRINT 1.................................................................................................................... 23
3.2 SPRINT 2......................................................................................................................... 49
3.3 Sprint 3............................................................................................................................ 72
3.4 Sprint 4............................................................................................................................ 87
2
ÍNDICE DE TABLAS
Tabla 1: Equipo scrum .............................................................................................................8

Tabla 2: Historia de usuario 1 .................................................................................................9
Tabla 3: Historia de usuario 2 ............................................................................................... 10
Tabla 10: Historia de usuario 9............................................................................................. 15
Tabla 11: Historia de usuario 10........................................................................................... 15
Tabla 18: Requerimientos funcionales ............................................................................... 19
Tabla 19: Requerimientos no funcionales.......................................................................... 21
Tabla 20: Definición del Sprint ............................................................................................. 22
Tabla 21: Construcción del Sprint 1 .................................................................................... 22
Tabla 25: Clases de equivalencia de login ......................................................................... 44
Tabla 26: Casos de prueba de login .................................................................................... 44
Tabla 27: Clases de equivalencia de marcas ..................................................................... 45
Tabla 28: Casos de prueba de marcas ................................................................................ 45
Tabla 29: Clases de equivalencia de ubicaciones ............................................................ 46
Tabla 30: Casos de prueba de ubicaciones ....................................................................... 46
Tabla 31: Clases de equivalencia de productos ............................................................... 67
Tabla 32: Casos de prueba de productos .......................................................................... 68
Tabla 33: Clases de equivalencia de compras .................................................................. 83
Tabla 34: Casos de prueba compras ................................................................................... 84
Tabla 35: Clases de equivalencia de comprobación de inventario ............................... 96
Tabla 36: Casos de prueba de comprobación de inventario .......................................... 97
3
ÍNDICE DE FIGURAS
Figura 1: Planificación del Sprint 1 ..................................................................................... 23

Figura 2: Modelo conceptual del Sprint 1 .......................................................................... 24
Figura 3: Modelo lógico del Sprint 1 ................................................................................... 25
Figura 4: Modelo físico del Sprint 1..................................................................................... 26
Figura 5: Prototipo login ........................................................................................................ 27
Figura 6: Prototipo de listado de usuarios......................................................................... 28
Figura 7: Prototipo de registro de usuarios....................................................................... 28
Figura 8: Prototipo de listado de categorías ..................................................................... 29
Figura 9: Prototipo de registro de categorías ................................................................... 29
Figura 10: Prototipo de listado de marcas ......................................................................... 30
Figura 11: Prototipo de registro de marcas ....................................................................... 30
Figura 12: Prototipo de listado de ubicaciones ................................................................ 31
Figura 13: Prototipo de registro de ubicaciones .............................................................. 31
Figura 14: Código de login - Vista ....................................................................................... 32
Figura 15: Código de login - Controlador........................................................................... 32
Figura 16: Código de login - Modelo ................................................................................... 33
Figura 17: Interfaz de login ................................................................................................... 33
Figura 18: Código de usuarios - Vista................................................................................. 34
Figura 19: Código de usuarios - Controlador .................................................................... 34
Figura 20: Código de usuarios - Modelo ............................................................................ 35
Figura 21: Interfaz de listado de usuarios .......................................................................... 35
Figura 22: Interfaz de registro de usuarios ........................................................................ 36
Figura 23: Código de categorías - Vista ............................................................................. 36
Figura 24: Código de categorías - Controlador................................................................. 37
Figura 25: Código de categorías - Modelo ......................................................................... 37
Figura 26: Interfaz de listado de categorías....................................................................... 38
Figura 27: Interfaz de registro de categorías ..................................................................... 38
Figura 28: Código de marcas - Vista ................................................................................... 39
Figura 29: Código de marcas - Controlador ...................................................................... 39
Figura 30: Código de marcas - Modelo ............................................................................... 40
Figura 31: Interfaz de listado de marcas ............................................................................ 40
Figura 32: Interfaz de registro de marcas .......................................................................... 41
Figura 33: Código de ubicaciones - Vista .......................................................................... 41
Figura 34: Código de ubicaciones - Controlador .............................................................. 42
Figura 35: Código de ubicaciones - Modelo ...................................................................... 42
Figura 36: Interfaz de listado de ubicaciones.................................................................... 43
Figura 37: Interfaz de registro de ubicaciones .................................................................. 43
Figura 38: Burn Down del Sprint 1....................................................................................... 47
Figura 39: Acta de cierre del Sprint 1 .................................................................................. 48
Figura 40: Planificación del Sprint 2 ................................................................................... 49
Figura 41: Modelo conceptual del Sprint 2 ........................................................................ 50
Figura 42: Modelo lógico del Sprint 2 ................................................................................. 51
4
Figura 43: Modelo físico del Sprint 2 .................................................................................. 52
Figura 44: Prototipo de listado de unidades de medida .................................................. 53
Figura 45: Prototipo de registro de unidades de medida ................................................ 53
Figura 46: Prototipo de listado de productos.................................................................... 54
Figura 47: Prototipo de registro de productos .................................................................. 54
Figura 48: Prototipo de listado de proveedores ............................................................... 55
Figura 49: Prototipo de registro de proveedores.............................................................. 55
Figura 50: Prototipo de listado de clientes ........................................................................ 56
Figura 51: Prototipo de registro de clientes ...................................................................... 56
Figura 52: Código de unidades de medida - Vista ............................................................ 57
Figura 53: Código de unidades de medida - Controlador ............................................... 57
Figura 54: Código de unidades de medida - Modelo........................................................ 58
Figura 55: Interfaz de listado de unidades de medida ..................................................... 58
Figura 56: Interfaz de registro de unidades de medida ................................................... 59
Figura 57: Código de productos - Vista .............................................................................. 59
Figura 58: Código de productos - Controlador ................................................................. 60
Figura 59: Código de productos - Modelo.......................................................................... 60
Figura 60: Interfaz de listado de productos ....................................................................... 61
Figura 61: Interfaz de registro de productos ..................................................................... 61
Figura 62: Código de proveedores - Vista.......................................................................... 62
Figura 63: Código de proveedores - Controlador ............................................................. 62
Figura 64: Código de proveedores - Modelo ..................................................................... 63
Figura 65: Interfaz de listado de proveedores ................................................................... 63
Figura 66: Interfaz de registro de proveedores ................................................................. 64
Figura 67: Código de clientes - Vista .................................................................................. 64
Figura 68: Código de clientes - Controlador...................................................................... 65
Figura 69: Código de clientes - Modelo .............................................................................. 65
Figura 70: Interfaz de listado de clientes ........................................................................... 66
Figura 71: Interfaz de registro de clientes.......................................................................... 66
Figura 73: Acta de cierre del Sprint 2.................................................................................. 71
Figura 78: Prototipo de listado de compras ...................................................................... 76
Figura 79: : Prototipo de registro de compras .................................................................. 77
Figura 80: : Prototipo de listado de ventas ........................................................................ 77
Figura 81: Prototipo de registro de ventas ....................................................................... 78
Figura 82: Código de compras - Vista................................................................................. 78
Figura 83: Código de compras - Controlador .................................................................... 79
Figura 84: Código de compras - Modelo ............................................................................ 79
Figura 85: Interfaz de listado de compras .......................................................................... 80
Figura 86: Interfaz de registro de compras ........................................................................ 80
Figura 87: Código de ventas - Vista .................................................................................... 81
Figura 88: Código de ventas - Controlador........................................................................ 81
Figura 89: Código de ventas - Modelo ................................................................................ 82
5
Figura 90: Interfaz de listado de ventas.............................................................................. 82
Figura 91: Interfaz de registro de ventas ............................................................................ 83
Figura 93: Acta de cierre del Sprint 3 .................................................................................. 86
Figura 98: Código de comprobación de inventario - Vista ............................................. 92
Figura 99: Código de comprobación de inventario - Controlador................................. 92
Figura 100: Código de comprobación de inventario - Modelo ....................................... 92
Figura 101: Interfaz de listado de comprobación de inventario .................................................. 93
Figura 102: Interfaz de registro de comprobación de inventario................................... 93
Figura 103: Código arqueo de inventario - Vista .............................................................. 94
Figura 104: Código arqueo de inventario - Controlador.................................................. 94
Figura 105: Código arqueo de inventario - Modelo .......................................................... 95
Figura 106: Interfaz de arqueo de inventario ..................................................................... 95
Figura 107: Burn Down del Sprint 4 .................................................................................... 97
Figura 108: Acta de cierre del Sprint 4 ............................................................................... 98
6
I. INTRODUCCIÓN
En el presente proyecto se aplicó la metodología ágil SCRUM, la cual nos va a

permitir responder a las necesidades y cambios que requiere la empresa Máxima
Tecnología del Perú S.A.C en su proceso de control de inventario.
Al plantear esta metodología de desarrollo se tiene como objetivo tener una

planeación y un control de todas las actividades y aspectos que involucra el proceso
de desarrollo del software para la empresa, se tendrá en cuenta todas las directivas
planteadas en la metodología SCRUM de acuerdo a las características que
presenta el proyecto, designando los roles, las actividades que se van a realizar,
los artefactos generados, etc.
En SCRUM podemos realizar entregas en periodos de 1 a 4 semanas

(denominados sprint), de forma iterativa e incremental, que potencialmente se
puedan utilizar. Para lograrlo, establece ciertas pautas organizativas, a modo de
guía y no de reglamento. Por lo que en este documento se describe la
implementación de la metodología de trabajo SCRUM para el desarrollo de una
aplicación web para el proceso de control de inventario en la empresa Máxima
Tecnología del Perú S.A.C
1.1 ALCANCE
Se considera que en el presente proyecto se debe alcanzar los objetivos prioritarios:
 La aplicación web permite el registro de productos

 La aplicación web permite el registro de proveedores y clientes
 La aplicación web permite realizar movimientos de entradas y salidas de
productos del almacén
 La aplicación web permite el manejo de un stock mínimo
 La aplicación web permite realizar comprobaciones de inventario
 La aplicación web permite cuadrar el inventario
 La aplicación web permite realizar reportes
7
1.2 EQUIPO SCRUM
La metodología scrum incluye tres roles: Scrum Master, Team Member Y Product
Owner. Para desarrollar este proyecto de investigación, el equipo scrum queda
determinado como se detalla a continuación.
Tabla 13: Equipo scrum
ROL ENCARGADO FUNCIÓN
Asegurar que la metodología

Ing. Melvyn Zavala
Scrum Master scrum sea entendida y
Mendoza
adoptada por el equipo
Analista programador
Team Member Carlos Olivera Rodrigo
Maximizar el valor del

Cleydis Meléndez producto que se está
Product Owner
Salvador construyendo
1.3 VALORES DE TRABAJO
Para que la implementación de la metodología SCRUM tenga éxito, todos los

miembros involucrados en el desarrollo deben practicar los siguientes valores:
 Auto organización
 Autonomía
 Respeto mutuo
 Foco en la tarea
 Responsabilidad
 Información, transparencia y visibilidad
8
II. PLANEACIÓN DEL PRODUCTO
2.1 HISTORIAS DE USUARIO
Las historias de usuario son representaciones de las necesidades que presenta el

usuario respecto a las funcionalidades de la aplicación web. Cada historia de
usuario debe estar bien delimitada y debe ser lo sufrientemente comprensible.
Es por ello que por medio de reuniones con los usuarios y con el Product Owner,
así como también la observación del proceso de control de inventario en la
empresa, se pudo obtener una lista de necesidades de la empresa.
A continuación, se detallan las historias de usuario recabadas para esta

investigación.
Tabla 14: Historia de usuario 1
HISTORIA DE USUARIO
N° Historia H001
Estimación 3 días
Acceso a la
Nombre Prioridad Alta
aplicación
Descripción:
 El personal podrá ingresar a la aplicación web con su respectivo usuario y

contraseña.
 La aplicación debe permitir el ingreso del usuario al menú principal a través

de un login de ingreso.
Como probarlo:
 Al ingresar un usuario y contraseña correctos, deberá acceder a la

aplicación web.
 Si el usuario ingresó una contraseña incorrecta se le hará saber a través

de un mensaje.
 Si el usuario ingresó un nombre de usuario incorrecto se le hará saber a

través de un mensaje.
9
HISTORIA DE USUARIO
N° Historia
H002 Estimación 4 días
Mantenimiento de
usuarios
Descripción:
 La aplicación permitirá crear, listar, actualizar y desactivar un usuario.
 La aplicación permitirá habilitar o quitar permisos al usuario según se

considere conveniente.
 Es necesario saber todos los datos del usuario, como cuando ha sido
registrado, cuando ingresó por última vez a la aplicación web, etc.
Condiciones y restricciones:
 Los siguientes campos son obligatorios, id, tipo de documento, número de

documento, nombre, nombre de usuario, contraseña, fecha de registro en
el sistema, último acceso a la aplicación y condición de usuario.
Como probarlo:
 Al crear un nuevo usuario se le notificará con un mensaje en pantalla.
 Al actualizar la información de un usuario se le notificará con un mensaje

en pantalla.
 En el módulo de usuarios, se podrá visualizar la lista de usuarios existentes

y toda su información.
HISTORIA DE USUARIO
N° Historia H003
Estimación 3 días
Mantenimiento
de categorías
Descripción:
10
 El usuario de la aplicación podrá crear, visualizar, actualizar y eliminar una
categoría según lo requiera.
 Para registrar una nueva categoría es necesario los siguientes campos: id,
nombre, descripción y condición de la categoría.
 Los siguientes campos son obligatorios, id, nombre y condición de

categoría.
 No se permite eliminar una categoría si está asociada a un registro de

producto.
Como probarlo:
 Al registrar una nueva categoría se notificará al usuario con un mensaje

en pantalla.
 Al actualizar una categoría se notificará al usuario con un mensaje en

pantalla.
 En el módulo de categorías, se podrá visualizar la lista de categorías

existentes.
HISTORIA DE USUARIO
N° Historia
Mantenimiento
Nombre Prioridad Media
de marcas
Descripción:

marca de producto según lo requiera.
 Las marcas están asociadas a los productos.
 No se permite eliminar una marca si está asociada a un registro de

producto.
Como probarlo:
11
 Al registrar una nueva marca se notificará al usuario con un mensaje en
pantalla.
 Al actualizar una marca se notificará al usuario con un mensaje en pantalla.
 En el módulo de marcas, se podrá visualizar la lista de marcas existentes.
HISTORIA DE USUARIO
N° Historia
Mantenimiento
de ubicaciones
Descripción:

ubicación de producto según lo requiera.
 Las ubicaciones están asociadas a los productos.
 No se permite eliminar una ubicación si está asociada a un registro de

producto.
Como probarlo:
 Al registrar una nueva ubicación se notificará al usuario con un mensaje

en pantalla.
 Al actualizar una ubicación se notificará al usuario con un mensaje en

pantalla.
 En el módulo de ubicaciones, se podrá visualizar la lista de ubicaciones

existentes.
12
HISTORIA DE USUARIO
N° Historia
Mantenimiento de
unidad de medida
Descripción:

unidad de medida según lo requiera.
 Por ejemplo: unidades, cajas, rollos, etc
 No se permite eliminar una unidad de medida si está asociada a un registro

de producto.
Como probarlo:
 Al registrar una nueva unidad de medida se notificará al usuario con un

mensaje en pantalla.
 Al actualizar una unidad de medida se notificará al usuario con un mensaje

en pantalla.
 En el módulo de unidades de medida, se podrá visualizar la lista de

unidades de medida existentes.
HISTORIA DE USUARIO
N° Historia H007 Estimación 5 días
Mantenimiento
de productos
Descripción:
 El usuario de la aplicación podrá registrar, visualizar, actualizar y eliminar

un producto según lo requiera.
 Se utilizará un stock mínimo para verificar la disponibilidad o no de los

productos.
13
 No se podrá eliminar un producto si está asociado a un registro de compra
o venta.
Como probarlo:
 Al registrar un nuevo producto se le notificará con un mensaje en pantalla.
 Al actualizar la información de un producto se le notificará con un mensaje

en pantalla.
 En el módulo de productos, se podrá visualizar la lista de productos

existentes.
HISTORIA DE USUARIO
Mantenimiento
de proveedores
Descripción:
 La aplicación permitirá crear, listar, actualizar y desactivar un proveedor.
 Los siguientes campos son obligatorios, id, ruc, razón social, especialidad,
dirección fiscal, teléfono y condición.
 No se permite eliminar un proveedor si está asociado a un registro de

compra.
Como probarlo:
 Al registrar un nuevo proveedor se le notificará con un mensaje en pantalla.
 Al actualizar la información de un proveedor se le notificará con un

 En el módulo de proveedores, se podrá visualizar la lista de proveedores

existentes en la aplicación.
14
HISTORIA DE USUARIO
Mantenimiento
de clientes
Descripción:
 La aplicación permitirá crear, listar, actualizar y desactivar un cliente.
 Los siguientes campos son obligatorios, id, tipo de cliente, tipo de

documento, nombre y condición.
Como probarlo:
 Al registrar un nuevo cliente se le notificará con un mensaje en pantalla y

podrá visualizar el nuevo cliente registrado en la lista de clientes.
 Al actualizar la información de un cliente se le notificará con un mensaje

en pantalla.
 En el módulo de clientes, se podrá visualizar la lista de clientes existentes

en la aplicación.
HISTORIA DE USUARIO
Nombre Compras Prioridad Alta
Descripción:
 La aplicación permitirá registrar y listar las compras realizadas a los

proveedores.
Como probarlo:
 Al registrar una nueva compra se le notificará con un mensaje en pantalla.
 En el módulo de compras, se podrá visualizar la lista de compras

realizadas.
15
HISTORIA DE USUARIO
Nombre Ventas Prioridad Alta
Descripción:
 La aplicación permitirá registrar y listar las ventas realizadas a los clientes.
Como probarlo:
 Al registrar una nueva venta se le notificará con un mensaje en pantalla.
 En el módulo de ventas, se podrá visualizar la lista de las ventas

realizadas.
HISTORIA DE USUARIO
N° Historia H012 Estimación 3
Ingreso de
productos
Descripción:
 La aplicación permitirá registrar el ingreso de productos al almacén,

aumentando así el stock de los productos ingresados.
Como probarlo:
 Al registrar un nuevo ingreso de productos al almacén se le notificará con

un mensaje en pantalla.
 En el módulo kardex, se podrá visualizar la lista de ingresos de productos

al almacén.
 En el módulo de productos se podrá ver el incremento del stock del

producto ingresado en almacén.
16
HISTORIA DE USUARIO
Salida de
productos
Descripción:
 La aplicación permitirá registrar la salida de productos del almacén,

disminuyendo así el stock de los productos que figuran en la lista de salida.
Como probarlo:
 Al registrar una nueva salida de productos del almacén se le notificará con

un mensaje en pantalla.
 En el módulo kardex, se podrá visualizar la lista de salida de productos del

almacén.
 En el módulo de productos se podrá ver el decremento del stock del

producto salido del almacén.
HISTORIA DE USUARIO
Comprobación de
inventario
Descripción:
 La aplicación permitirá registrar comprobaciones de inventario, para

verificar si el stock del almacén coincide con el stock lógico; pudiendo
seleccionar los productos que se desea comprobar.
Como probarlo:
 Al registrar una nueva comprobación de inventario se le notificará con un

 En el módulo comprobación de inventario, se podrá visualizar la lista de

comprobaciones de inventario programadas y finalizadas.
17
HISTORIA DE USUARIO
Arqueo de
inventario
Descripción:
 La aplicación permitirá cuadrar el inventario sobrante o faltante que se

encuentre en la comprobación de inventario.
Como probarlo:
 En el módulo de arqueo de inventario, se puede cuadrar los faltantes o

sobrantes de los productos.
 En el módulo de arqueo de inventario, se puede visualizar los cuadres

realizados.
HISTORIA DE USUARIO
Reporte de
indicadores
Descripción:
 La aplicación mostrará los indicadores de rotación de inventario y el nivel

de servicio.
Como probarlo:
 En el inicio de la aplicación se mostrará los indicadores y la posibilidad de

descargarlos de manera gráfica.
18
2.2 PRODUCT BACKLOG
El product backlog es una lista de lo que podría ser necesario para el desarrollo del
producto, debe estar ordenada y priorizada y es tomada como una fuente de
requisitos para cualquier cambio a realizarse en el producto. El product backlog, su
contenido, disponibilidad y priorización es responsabilidad del product owner.
Para el desarrollo del presente proyecto; el product backlog, con la intervención

fundamental del Product Owner, se definió de acuerdo a las historias de usuario
previamente detalladas, quedando como se muestra en la siguiente tabla.
Tabla 30: Requerimientos funcionales
REQUERIMIENTOS FUNCIONALES DE LAS H.U

Requerimiento T.E
Historia Código Actividades Prioridad
Funcional (Días)
Verificar usuario
Verificar contraseña
Acceso a la
H001 RF01 Verificar estado de 3 Alta
aplicación
usuario
Verificar permisos
Registrar usuarios
Listar usuarios
Mantenimiento
H002 RF02 Modificar usuarios 4 Alta
de usuarios
Eliminar usuarios
Reporte de usuarios
Registrar categorías
Listar categorías
Mantenimiento
H003 RF03 Modificar categorías 3 Alta
de categorías
Eliminar usuarios
Reporte categorías
Registrar marcas
Listar marcas
Mantenimiento
H004 RF04 Modificar marcas 3 Media
de marcas
Eliminar marcas
Reporte de marcas
Registrar ubicaciones
Listar ubicaciones
Mantenimiento
H005 RF05 Modificar ubicaciones 3 Media
de ubicaciones
Eliminar ubicaciones
Reporte ubicaciones
19
Registrar unidad de
medida
Listar unidad de
medida
Mantenimiento
Modificar unidad de
H006 RF06 de unidades de 3 Media
medida
medida
Eliminar unidad de
medida
Reporte de unidad de
medida
Registrar productos
Listar productos
Mantenimiento
H007 RF07 Modificar productos 5 Alta
de productos
Eliminar productos
Reporte de productos
Registrar
proveedores
Listar proveedores
Mantenimiento Modificar
H008 RF08 4 Alta
de proveedores proveedores
Eliminar proveedores
Reporte de
proveedores
Registrar clientes
Listar clientes
Mantenimiento
H009 RF09 Modificar clientes 3 Alta
de clientes
Eliminar clientes
Reporte de clientes
Registrar orden de
compra
Listar orden de
compra
Orden de Modificar orden de
H010 RF10 3 Alta
compra compra
Anular orden de
compra
Reporte de orden de
compra
Registrar orden de
venta
Listar orden de venta
Modificar orden de
H011 RF11 Orden de venta venta 3 Alta
Anular orden de
venta
Reporte de orden de
venta
H012 RF12 Buscar código o.c 3 Alta
20
Ingreso de Comprobar cantidad
productos Ingresar productos
Buscar código o.v
Salida de
H013 RF13 Comprobar cantidad 3 Alta
productos
Salir productos
Comprobación Registrar C.I
H014 RF14 3 Alta
de inventario Modificar C.I
Arqueo de Cuadrar sobrantes
H015 RF15 3 Alta
inventario Cuadrar faltantes
Rotación de
Reporte de
H016 RF16 inventario 2 Alta
indicadores
Nivel de servicio
Tabla 31: Requerimientos no funcionales
REQUERIMIENTOS NO FUNCIONALES DE LAS H.U

Código
Nivel Requerimiento no funcional
La aplicación debe contar con interfaces
RNF1 Usabilidad
amigables e intuitivas para su fácil dominio.
La aplicación está disponible las 24 horas, los
RNF2 Disponibilidad
365 días del año.
La aplicación está disponible desde cualquier
RNF3 Accesibilidad
dispositivo conectado a internet.
La aplicación se adapta a cualquier pantalla de
RNF4 Responsividad dispositivo como Smartphone, Tablet, laptop,
pc de escritorio.
La aplicación debe garantizar la seguridad e
RNF5 Seguridad integridad de la data, se encriptará la
contraseña.
2.3 SPRINT BACKLOG
El sprint backlog es una estimación elaborada por el equipo de desarrollo acerca

de que funcionalidades hacen parte del próximo incremento y del trabajo que se
necesita para entregar dichas funcionalidades terminadas. Es por ello que para el
desarrollo de la aplicación web se realizaron 4 sprint, que se detallan en las
siguientes tablas.
21
2.3.1 Definición del sprint
Tabla 32: Definición del Sprint
Sprint Requerimiento Estimación (Días)

Sprint 1 RF01, RF02, RF03, RF04, RF05 16
Sprint 2 RF06, RF07, RF08, RF09 15
Sprint 3 RF10, RF11, RF12, RF13 12
Sprint 4 RF14, RF15, RF16 8
2.3.2 Construcción del sprint
Tabla 33: Construcción del Sprint 1
Sprint 1
Actividades Estimación (días) Prioridad
Acceso a la aplicación 3 Alta
Mantenimiento de usuarios 4 Alta
Mantenimiento de categorías 3 Alta
Mantenimiento de marcas 3 Media
Mantenimiento de ubicaciones 3 Media
Sprint 2
Mantenimiento de unidades de medida 3 Media
Mantenimiento de productos 5 Alta
Mantenimiento de proveedores 4 Alta
Mantenimiento de clientes 3 Alta
Sprint 3
Compras 3 Alta
Ventas 3 Alta
Ingreso de productos 3 Alta
Salida de productos 3 Alta
22
Sprint 4
Comprobación de inventario 3 Alta
Arqueo de inventario 3 Alta
Reporte de indicadores 2 Alta
III. DESARROLLO DE SPRINTS
3.1 SPRINT 1
Planificación del Sprint 1
Figura 18: Planificación del Sprint 1
Fuente: Elaboración Propia
Análisis del Sprint 1
Antes de dar inicio a las etapas de diseño e implementación es necesario conocer

y entender exactamente lo que la aplicación web debe realizar, es decir, qué
realmente se necesita de acuerdo a la comprensión de las historias de usuario del
Sprint 1.
Analizamos el funcionamiento de la aplicación web en base login, usuarios,

categorías, marcas, ubicación y los procesos específicos que se presentan:
23
 Para realizar un registro o transacción, el usuario, debe estar logueado en la
aplicación web.
 Cada usuario tiene ciertos permisos en la aplicación, siendo el administrador
el que asigne o retire permisos según lo estime conveniente.
 El usuario debe definir las categorías para cada producto del almacén,
registrando, consultando, actualizando o eliminando la categoría.
 El usuario debe definir las marcas de los productos del almacén, registrando,
consultando, actualizando o eliminando la marca.
 El usuario debe definir la ubicación de los productos en almacén,
registrando, consultando, actualizando o eliminando la ubicación.
Diseño del Sprint 1
Diseño Conceptual Sprint 1
En la figura N° 2 se muestra el diseño conceptual de la base de datos del Sprint 1;

en el cual se identificaron las entidades usuario, permiso y producto, y sus
respectivos atributos (username, dirección, per_nombre, categoría, marca,
ubicación, etc.); además se analizó las relaciones entre entidades y su respectiva
cardinalidad.
Figura 19: Modelo conceptual del Sprint 1
24
Diseño Lógico Sprint 1
En la figura N° 3 se muestra el diseño lógico de la base de datos del Sprint 1.

Obtenemos el diseño lógico a partir del diseño conceptual anterior, para ello
creamos una tabla por cada entidad del diseño conceptual y cada atributo de la
entidad será una columna de la nueva tabla. Para la relación de las tablas; en el
caso de tener una relación de muchos a muchos (tal es el caso de usuario y
permiso) se tendrá que crear una nueva tabla intermedia (usuario_permiso).
Además, normalizando la base de datos obtenemos que categoría, marca y
ubicación pasan a ser una nueva tabla.
Figura 20: Modelo lógico del Sprint 1
Fuente: elaboración propia
Diseño Físico Sprint 1
En la figura N° 4 se muestra el diseño físico de la base de datos del Sprint 1; una

vez obtenido el diseño lógico anterior se puede aplicar a cualquier SGBD, para esta
investigación se utilizó MYSQL, dando como resultado el diseño físico.
25
Figura 21: Modelo físico del Sprint 1
Arquitectura de la aplicación web: Sprint 1
Para el desarrollo de la aplicación web planteada para esta investigación, se usó el

patrón de diseño modelo vista controlador, el cual es altamente recomendado para
este tipo de aplicaciones; debido a que este patrón de diseño separa en tres capas
(MVC) bien definidas la aplicación en cuestión, asegurando la mantenibilidad,
escalabilidad y seguridad de la aplicación que se va a desarrollar.
A continuación, se detallan las capas del patrón MVC para el Sprint 1:
 Modelo: Las clases de esta capa contienen los métodos, datos y atributos
de cada una de las entidades utilizadas en este Sprint. Por ejemplo, el
nombre, el teléfono, el estado, etc. de un usuario en específico.
 Controlador: Interactúa con el modelo y la vista, y se encarga de establecer
la lógica que debe seguir los datos del modelo. Por ejemplo, el controlador
de los usuarios le enviará a la vista la lista de usuarios que están registrados
en la aplicación.
 Vista: Esta capa muestra los resultados que le envió el controlador. Por
ejemplo, una vista mostrará los usuarios, las categorías, las marcas, y las
ubicaciones.
26
Prototipos del Sprint 1
Login
En la figura N°5 se muestra el prototipo de login, que fue diseñado por el team
member y presentado al product owner para su validación respectiva. Cumpliendo
con las expectativas del product owner y los stakeholders el prototipo fue aprobado.
Figura 22: Prototipo login
Usuarios
En las figuras N°6 y N°7 se muestran los prototipos de los usuarios de la aplicación
web, que fueron diseñados por el team member y presentados al product owner
para su validación respectiva. Cumpliendo con las expectativas del product owner
y los stakeholders los prototipos fueron aprobados.
27
Figura 23: Prototipo de listado de usuarios
Figura 24: Prototipo de registro de usuarios
28
Categorías
En las figuras N°8 y N°9 se muestran los prototipos de las categorías de los
productos, que fueron diseñados por el team member y presentados al product
owner para su validación respectiva. Cumpliendo con las expectativas del product
owner y los stakeholders los prototipos fueron aprobados.
Figura 25: Prototipo de listado de categorías
Figura 26: Prototipo de registro de categorías
29
Marcas
En las figuras N°10 y N°11 se muestran los prototipos de las marcas de los
productos, que fueron diseñados por el team member y presentados al product
owner y los stakeholders, los prototipos fueron aprobados.
Figura 27: Prototipo de listado de marcas
Figura 28: Prototipo de registro de marcas
30
Ubicaciones
En las figuras N°12 y N°13 se muestran los prototipos de las ubicaciones de los
productos en almacén, que fueron diseñados por el team member y presentados al
product owner para su validación respectiva. Cumpliendo con las expectativas del
product owner y los stakeholders los prototipos fueron aprobados.
Figura 29: Prototipo de listado de ubicaciones
Figura 30: Prototipo de registro de ubicaciones
31
Implementación del Sprint 1
Login
Para el desarrollo del login, como en toda la aplicación web, se utilizó el patrón de
diseño modelo vista controlador. En las figuras N° 14, 15 y 16 se muestra
fragmentos de código del login en cada capa del patrón MVC.
 Login – Vista
Figura 31: Código de login - Vista
 Login – Controlador
Figura 32: Código de login - Controlador
32
 Login – Modelo
Figura 33: Código de login - Modelo
Interfaz Login
En la figura N° 17 se observa la interfaz gráfica de login, la cual va a permitir el

acceso a la aplicación web, mediante los campos requeridos usuario y clave,
finalmente pulsando en el botón acceder.
Figura 34: Interfaz de login
33
Usuarios
Para el desarrollo de usuarios, como en toda la aplicación web, se utilizó el patrón

de diseño modelo vista controlador. En las figuras N° 18, 19 y 20 se muestra
fragmentos de código de los usuarios en cada capa del patrón MVC.
 Usuarios – Vista
Figura 35: Código de usuarios - Vista
 Usuarios – Controlador
Figura 36: Código de usuarios - Controlador
34
 Usuarios – Modelo
Figura 37: Código de usuarios - Modelo
Interfaz de Usuarios
En las figuras N° 21 y N° 22 se observan las interfaces gráficas de usuarios,

permitiendo el registro, consulta, actualización y eliminación de los usuarios de la
aplicación.
Figura 38: Interfaz de listado de usuarios
35
Figura 39: Interfaz de registro de usuarios
Categorías
Para el desarrollo de las categorías, como en toda la aplicación web, se utilizó el

patrón de diseño modelo vista controlador. En las figuras N° 23, 24 y 25 se muestra
fragmentos de código de las categorías en cada capa del patrón MVC.
 Categorías – Vista
Figura 40: Código de categorías - Vista
36
 Categorías – Controlador
Figura 41: Código de categorías - Controlador
 Categorías – Modelo
Figura 42: Código de categorías - Modelo
37
Interfaces de Categorías
En las figuras N° 26 y N° 27 se observan las interfaces gráficas de categorías,

permitiendo el registro, consulta, actualización y eliminación de las categorías de la
aplicación.
Figura 43: Interfaz de listado de categorías
Figura 44: Interfaz de registro de categorías
38
Marcas
Para el desarrollo de marcas, como en toda la aplicación web, se utilizó el patrón

de diseño modelo vista controlador. En las figuras N° 28, 29 y 30 se muestra
fragmentos de código de las marcas en cada capa del patrón MVC.
 Marcas – Vista
Figura 45: Código de marcas - Vista
 Marcas – Controlador
Figura 46: Código de marcas - Controlador
39
 Marcas – Modelo
Figura 47: Código de marcas - Modelo
Interfaces de Marcas
En las figuras N° 31 y N° 32 se observan las interfaces gráficas de marcas,

permitiendo el registro, consulta, actualización y eliminación de las marcas.
Figura 48: Interfaz de listado de marcas
40
Figura 49: Interfaz de registro de marcas
Ubicaciones
Para el desarrollo de las ubicaciones, como en toda la aplicación web, se utilizó el

patrón de diseño modelo vista controlador. En las figuras N° 33, 34 y 35 se muestra
fragmentos de código de las ubicaciones en cada capa del patrón MVC.
 Ubicaciones – Vista
Figura 50: Código de ubicaciones - Vista
41
 Ubicaciones – Controlador
Figura 51: Código de ubicaciones - Controlador
 Ubicaciones – Modelo
Figura 52: Código de ubicaciones - Modelo
Interfaces de ubicaciones
En las figuras N° 36 y N° 37 se observan las interfaces gráficas de ubicaciones,

permitiendo el registro, consulta, actualización y eliminación de dichas ubicaciones.
42
Figura 53: Interfaz de listado de ubicaciones
Figura 54: Interfaz de registro de ubicaciones
43
Pruebas del Sprint 1
A continuación, se muestra las pruebas de caja negra realizadas a los módulos del
Sprint 1, mediante la técnica de partición equivalente, que consiste en derivar casos
de prueba mediante la división del dominio de entrada en clases de equivalencia,
evaluando su comportamiento para un valor cualquiera representativo de dicha
clase.
En las tablas N°25 y N°26 podemos observar las clases de equivalencia de login y
los casos de prueba de login respectivamente.
Tabla 37: Clases de equivalencia de login
Clases válidas Clases no válidas

C. Entrada Tipo
Código Entrada Código Entrada
Campo
Usuario Alfanumérico CEV01 0<Usuario≤20 CENV01 en
blanco
Campo
Contraseña Alfanumérico CEV02 0<Contraseña≤70 CRNV02 en
blanco
Tabla 38: Casos de prueba de login
Condiciones de
Clases de Respuesta Respuesta
ID entrada Coincide
equivalencia esperada aplicación
Usuario contraseña
CENV01, Completar Ingrese usuario
CP1 SÍ
CENV02 campo y contraseña
CENV01, Completar
CP2 1234 Ingrese usuario SÍ
CEV02 campo
CEV01, Completar Ingrese
CP3 admin Sí
CENV02 campo contraseña
CEV01, Acceso a la Acceso a la
CP4 admin 1234 Sí
CEV02 aplicación aplicación
44
En las tablas N°27 y N°28 podemos observar las clases de equivalencia de marcas
y los casos de prueba de marcas respectivamente.
Tabla 39: Clases de equivalencia de marcas

C. Entrada Tipo
Campo
Marca Alfanumérico CEV01 3<Marca≤45 CENV01 en
blanco
Campo
Conjunto de
Estado CEV02 {activo,inactivo} CRNV02 en
datos
blanco
Tabla 40: Casos de prueba de marcas
Condiciones de
ID entrada Coincide
Marca Estado
CENV01, Completar Completar
CP1 SÍ
CENV02 campo campo
CENV01, Completar
CP2 activo Ingrese marca SÍ
CEV02 campo
CEV01, Completar Seleccionar
CP3 hikvision Sí
CENV02 campo estado
CEV01, Registro Marca
CP4 hikvision activo Sí
CEV02 exitoso registrada
45
En las tablas N°29 y N°30 podemos observar las clases de equivalencia de
ubicaciones y los casos de prueba de ubicaciones respectivamente.
Tabla 41: Clases de equivalencia de ubicaciones

C. Entrada Tipo
Campo
Sector Alfanumérico CEV01 1<Sector≤10 CENV01 en
blanco
Campo
Estante Numérico CEV02 1<Estante≤10 CENV02 en
blanco
Descripción Alfanumérico CEV03 0<Descripción≤20 CENV03 -
Campo
Conjunto de
Estado CEV04 {activo,inactivo} CENV04 en
datos
blanco
Tabla 42: Casos de prueba de ubicaciones
Condiciones de entrada Respuesta Respuesta

ID CE Coincide
Sect. Estant. Desc Estado esperada aplicación
CP CENV01, CENV02, Completar Completar
SÍ
1 CENV03, CENV04 campo campo
CP CENV01, CEV02, Completar Ingrese
1 1 activo SÍ
2 CEV03, CEV04 campo sector
CP CEV01, CENV02, Completar Ingrese
A 1 activo Sí
3 CEV03, CEV04 campo estante
CP CEV01, CEV02, Registro Ubicación
A 1 - activo Sí
4 CENV03,CEV04 exitoso registrada
CP CEV01, CEV02, Selec Selec
A 1 1 Sí
5 CEV03, CENV04 elemento estado
CP CEV01, CEN02, Registro Ubicación
A 1 1 activo Sí
6 CEV03, CEV04 exitoso registrada
46
De las tablas N°26, N°28 y N°30 se puede observar que las pruebas realizadas a
login, marcas y ubicaciones fueron exitosas, ya que, en todos los casos de prueba,
la respuesta esperada y la respuesta de la aplicación web coinciden al 100%.
Burndown del Sprint 1
En la siguiente figura se visualiza dos líneas, la línea naranja representa como

debería haberse realizado el sprint 1 de acuerdo a la planificación previa y la línea
azul representa como en realidad se fue desarrollando el sprint 1. En este Sprint se
se cumplió con la planificación propuesta.
Figura 55: Burn Down del Sprint 1
Burn Down: Sprint 1

140
120
100
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Horas restantes Horas estimadas
47
Acta de cierre del Sprint 1
Figura 56: Acta de cierre del Sprint 1
48
3.2 SPRINT 2

Antes de dar inicio a las etapas de diseño e implementación del Sprint 2 es

necesario conocer y entender exactamente lo que la aplicación web debe realizar,
es decir, qué realmente se necesita de acuerdo a la comprensión de las historias
de usuario del Sprint 2.
Analizamos el funcionamiento de la aplicación web en base las unidades de

medida, productos, proveedores, clientes y los procesos específicos que se
presentan:

aplicación web.
 El usuario debe definir las unidades de medida para cada producto del
almacén, registrando, consultando, actualizando o eliminando dicha unidad
de medida.
 El usuario debe definir los productos del almacén, registrando, consultando,
actualizando o eliminando dicho producto, teniendo en cuenta la categoría,
la marca, la unidad de medida y la ubicación que se asignará un producto en
específico.
49
 El usuario debe definir los proveedores, registrando, consultando,
actualizando o eliminando dicho proveedor.
 El usuario debe definir los clientes, registrando, consultando, actualizando o
eliminando dicho cliente.
Diseño
Diseño conceptual del Sprint 2
En la figura N° 41 se muestra el diseño conceptual de la base de datos del Sprint

2; en el cual se identificaron las entidades proveedor, producto y cliente, y sus
respectivos atributos (razón social, teléfono, código, email, etc.); además se analizó
las relaciones entre entidades y su respectiva cardinalidad.
Diseño lógico del Sprint 2

creamos una tabla por cada entidad (proveedor, cliente) del diseño conceptual y
50
cada atributo de la entidad será una columna de la nueva tabla. Para la relación de
las tablas; en el caso de tener una relación de mucho a mucho se tendrá que crear
una nueva tabla intermedia. Además, normalizando la base de datos obtenemos
que el atributo unidad de medida pasa a ser una nueva tabla que hace referencia a
la tabla producto.
Diseño físico
En la figura N° 43 se muestra el diseño físico de la base de datos del Sprint 2; una

51

 Modelo: Esta capa contiene los métodos, datos y atributos de cada una de
las entidades utilizadas en este Sprint. Por ejemplo, el nombre, la categoría,
la foto, etc de un producto en específico.
de los productos le enviará a la vista la lista de productos que están
registrados en la aplicación.
ejemplo, una vista mostrará los productos, los proveedores, los clientes.
52
Unidades de medida
En las figuras N°44 y N°45 se muestran los prototipos de las unidades de medida
de los productos, que fueron diseñados por el team member y presentados al
product owner para su validación respectiva. Cumpliendo con las expectativas del
product owner y los stakeholders los prototipos fueron aprobados.
Figura 61: Prototipo de listado de unidades de medida
Figura 62: Prototipo de registro de unidades de medida
53
Productos
En las figuras N°46 Y N°47 se muestran los prototipos de los productos de la

aplicación web que fueron diseñados por el team member y presentados al product
Figura 63: Prototipo de listado de productos
Figura 64: Prototipo de registro de productos
54
Proveedores
En las figuras N°48 Y N°49 se muestran los prototipos de los proveedores de la

Figura 65: Prototipo de listado de proveedores
Figura 66: Prototipo de registro de proveedores
55
Prototipos de Clientes
En las figuras N°50 Y N°51 se muestran los prototipos de los clientes de la

Figura 67: Prototipo de listado de clientes
Figura 68: Prototipo de registro de clientes
56
Unidades de medida
Para el desarrollo de las unidades de medida, como en toda la aplicación, se utilizó

el patrón de diseño modelo vista controlador. A continuación, se muestra
fragmentos de código de cada capa del patrón MVC y el resultado de su
implementación.
 Unidad de medida – Vista
Figura 69: Código de unidades de medida - Vista
 Unidad de medida – Controlador
Figura 70: Código de unidades de medida - Controlador
57
 Unidad de medida – Modelo
Figura 71: Código de unidades de medida - Modelo
Interfaces de Unidades de medida
En las figuras N°55 y N°56, se observa las interfaces gráficas de las unidades de
medida de los productos, la cual permite el registro, consulta, actualización y
eliminación de las unidades de medida de los productos registrados en la aplicación
web.
Figura 72: Interfaz de listado de unidades de medida
58
Figura 73: Interfaz de registro de unidades de medida
Productos
Para el desarrollo de los productos en almacén, como en toda la aplicación, se

utilizó el patrón de diseño modelo vista controlador. A continuación, se muestra
implementación.
 Productos – Vista
Figura 74: Código de productos - Vista
59
 Productos – Controlador
Figura 75: Código de productos - Controlador
 Productos – Modelo
Figura 76: Código de productos - Modelo
60
Interfaces de Productos
En las figuras N°60 y N°61, se observa las interfaces gráficas de los productos en
almacén, la cual permite el registro, consulta, actualización y eliminación de los
productos registrados en la aplicación web.
Figura 77: Interfaz de listado de productos
Figura 78: Interfaz de registro de productos
61
Proveedores
Para el desarrollo de los proveedores, como en toda la aplicación web, se utilizó el

patrón de diseño modelo vista controlador. A continuación, se muestra fragmentos
de código de cada capa del patrón MVC y el resultado de su implementación.
 Proveedores – Vista
Figura 79: Código de proveedores - Vista
 Proveedores – Controlador
Figura 80: Código de proveedores - Controlador
62
 Proveedores – Modelo
Figura 81: Código de proveedores - Modelo
Interfaces de Proveedores
En las figuras N°65 y N°66, se observa las interfaces gráficas de los proveedores,
la cual permite el registro, consulta, actualización y eliminación de los proveedores
en la aplicación web.
Figura 82: Interfaz de listado de proveedores
63
Figura 83: Interfaz de registro de proveedores
Clientes
Para el desarrollo de los clientes, como en toda la aplicación web, se utilizó el patrón
de diseño modelo vista controlador. A continuación, se muestra fragmentos de
código de cada capa del patrón MVC y el resultado de su implementación.
 Clientes – Vista
Figura 84: Código de clientes - Vista
64
 Clientes – Controlador
Figura 85: Código de clientes - Controlador
 Clientes – Modelo
Figura 86: Código de clientes - Modelo
65
Interfaces de Clientes
En las figuras N°70 y N°71, se observa las interfaces gráficas de los clientes, la cual
permite el registro, consulta, actualización y eliminación de los proveedores en la
aplicación web.
Figura 87: Interfaz de listado de clientes
Figura 88: Interfaz de registro de clientes
66
A continuación, se muestra las pruebas de caja negra realizada a los módulos del
clase.

productos y los casos de prueba de productos respectivamente.
Tabla 43: Clases de equivalencia de productos

C. Entrada Tipo
Conjunto de {cámaras, Campo en
Categoría CEV01 CENV01
datos intercomunicadores,…} blanco
Conjunto de Campo en
Ubicación CEV02 {A-1,A-2,B-5,…} CENV02
datos blanco
Código Alfanumérico CEV03 0<Código≤50 CENV03 -
Descripción Alfanumérico CEV04 0<Descripción≤200 CEVN04 -
Unidad de Conjunto de Campo en
CEV05 {kg,unidad,m,…} CENV05
medida datos blanco
Conjunto de Campo en
Marca CEV06 {dahua,hikvision,…} CENV06
datos blanco
Stock Campo en
Numérico CEV07 0<Stock mínimo CENV07
mínimo blanco
67
Tabla 44: Casos de prueba de productos
Condiciones de entrada Respuesta Respuesta

ID C.E Coincide
Cat Ubica Cód Desc U.Medida marca Stock mín esperada aplicación
CEV0, CEV0,
CEV0, CEV0, Registro Producto
CP1 Cámaras A-1 P01 1 u hikvision 10 SÍ
CEV0, CEV0, guardado guardado
CENV7
CENV01,CEV
Seleccionar
02,CEV03,CE Seleccionar
CP2 A-1 P01 1 u hikvision 10 un SÍ
V04,CEV05,C categoría
elemento
EV06, CEN07,
CEV01,CENV
Seleccionar
02,CEV03,CE Seleccionar
CP3 Cámaras P01 1 u hikvision 10 un Sí
V04,CEV05,C ubicación
elemento
EV06, CEN07,
CEV01,CEV02
,CENV03,CEV Registro Producto
CP4 Cámaras A-1 - 1 u hikvision 10 Sí
04,CEV05,CE guardado guardado
V06, CEN07,
CEV01,CEV02
,CEV03,CENV Registro Producto
CP5 Cámaras A-1 P01 - u hikvision 10 Sí
04,CEV05,CE guardado guardado
V06, CEN07,
68
CEV01,CEV02
Seleccionar
,CEV03,CEV0 Seleccionar
CP6 Cámaras A-1 P01 1 hikvision 10 un Sí
4,CENV05,CE medida
elemento
V06, CEN07,
CEV01,CEV02
Seleccionar
,CEV03,CEV0 Seleccionar
CP7 Cámaras A-1 P01 1 u 10 un Sí
4,CEV05,CEV marca
elemento
N06, CEN07,
CEV01,CEV02
,CEV03,CEV0 Completar Ingresar
CP8 Cámaras A-1 P01 1 u hikvision Sí
4,CEV05,CEV campo stock mín
06, CENV07,
69
De las tablas N°32 se puede observar que las pruebas realizadas a los productos
fueron exitosas, ya que, en todos los casos de prueba, la respuesta esperada y la
respuesta de la aplicación web coinciden al 100%.

cumplió con la planificación propuesta.
Burn Down: Sprint 2

140
120
100
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
70
71
3.3 Sprint 3

Analizamos el funcionamiento de la aplicación web en base a las compras, ventas,

ingreso de productos, salida de productos y los procesos específicos que se
presentan:

aplicación web.
 El usuario debe definir las compras del almacén, registrando, consultando,
actualizando o cancelando dicha compra.
 El usuario debe definir las ventas del almacén, registrando, consultando,
actualizando o cancelando dicha venta.
72
 El usuario debe realizar el ingreso de productos, consultando el código de
orden de compra.
 El usuario debe realizar la salida de productos, consultando el código de
orden de venta.
Diseño Conceptual del Sprint 3
En la figura N°75 se muestra el diseño conceptual de la base de datos del Sprint 3;

en el cual se identificaron las entidades compra, venta, producto y sus respectivos
atributos (estado, serie, cantidad, descuento, etc.); además se analizó las
relaciones entre entidades y su respectiva cardinalidad.
Diseño Lógico del Sprint 3

creamos una tabla por cada entidad (venta, producto, compra, usuario, proveedor,
cliente) del diseño conceptual y cada atributo de la entidad será una columna de la
nueva tabla. Para la relación de las tablas; en el caso de tener una relación de
73
muchos a muchos (tal es el caso de productos y compras, y productos y ventas) se
tendrá que crear una nueva tabla intermedia (detalle_venta y detalle_compra).
Fuente: Elaboración Propia
Diseño Físico del Sprint 3
En la figura N°77 se muestra el diseño físico de la base de datos del Sprint 3; una
74

 Modelo: Esta capa contienen los métodos, datos y atributos de cada una de
las entidades utilizadas en este Sprint. Por ejemplo, la serie, el número, la
fecha, etc de una compra realizada.
75
de las compras le enviará a la vista la lista de compras que están registradas
en la aplicación.
ejemplo, una vista mostrará las compras, las ventas, ingreso y salida de
productos.
Compras
En las figuras N°78 y N°79 se muestran los prototipos de las compras que fueron
diseñados por el team member y fueron presentados al product owner para su
validación respectiva. Cumpliendo con las expectativas del product owner y los
stakeholders los prototipos fueron aprobados.
Figura 95: Prototipo de listado de compras
76
Figura 96: : Prototipo de registro de compras
Ventas
En las figuras N°80 y N°81 se muestran los prototipos de las ventas que fueron
diseñados por el team member y fueron presentados al product owner para su
validación respectiva. Cumpliendo con las expectativas del product owner y los
stakeholders los prototipos fueron aprobados.
Figura 97: : Prototipo de listado de ventas
77
Figura 98: Prototipo de registro de ventas
Compras
Para el desarrollo de las compras, como en toda la aplicación web, se utilizó el

patrón de diseño modelo vista controlador. A continuación, se muestra fragmentos
de código de cada capa del patrón MVC y el resultado de su implementación.
 Compras – Vista
Figura 99: Código de compras - Vista
Fuente. Elaboración propia
78
 Compras – Controlador
Figura 100: Código de compras - Controlador
 Compras – Modelo
Figura 101: Código de compras - Modelo
Interfaz de Compras
En las figuras N°85 y N°86, se observa las interfaces gráficas de las compras, la
cual permite el registro, consulta y anulación de las compras realizadas en la
aplicación web. Además de obtener reportes de las compras en formato PDF,
EXCEL o imprimirlas directamente.
79
Figura 102: Interfaz de listado de compras
Figura 103: Interfaz de registro de compras
Ventas
Para el desarrollo de las ventas, como en toda la aplicación web, se utilizó el patrón
de diseño modelo vista controlador. A continuación, se muestra fragmentos de
código de cada capa del patrón MVC y el resultado de su implementación.
80
 Ventas – Vista
Figura 104: Código de ventas - Vista
 Ventas – Controlador
Figura 105: Código de ventas - Controlador
81
 Ventas – Modelo
Figura 106: Código de ventas - Modelo
Interfaz de Ventas
En las figuras N°90 y N°91, se observa las interfaces gráficas de las ventas, la cual
permite el registro, consulta y anulación de las ventas realizadas en la aplicación
web. Además de obtener reportes de las ventas en formato PDF, EXCEL o
imprimirlas directamente.
Figura 107: Interfaz de listado de ventas
82
Figura 108: Interfaz de registro de ventas
A continuación, se muestra las pruebas de caja negra realizada a los módulos del
sprint 3, mediante la técnica de partición equivalente, que consiste en derivar casos
clase.
En las tablas N°33 y N°34 podemos observar las clases de equivalencia de las
compras y los casos de prueba de las compras respectivamente.
Tabla 45: Clases de equivalencia de compras

C. Entrada Tipo
Campo en
Proveedor Alfanumérico CEV01 0<Proveedor≤80 CENV01
blanco
T Conjunto de Campo en
CEV02 {Boleta,Faturas} CENV02
comprobante datos blanco
Campo en
Serie Alfanumérico CEV03 0<Serie≤8 CENV03
blanco
83
Campo en
Número Alfanumérico CEV04 0<Número≤12 CEVN04
blanco
Tabla 46: Casos de prueba compras
Clases de Condiciones de entrada

Respuesta Respuesta
ID equivalenc Coincide
Prov T comp Serie Num esperada aplicación
ia
CP CENV01, Registro Compra
1 1 1 1 SÍ
1 CENV02 guardado registrada
CP CENV01, Completar Seleccionar
1 1 1 SÍ
2 CEV02 campo proveedor
CP CEV01, Completar Seleccionar t
1 1 1 Sí
3 CENV02 campo comp
CP CEV01, Completar Completar
1 1 1 Sí
4 CEV02 campo campo
CP CEV01, Completar Completar
1 1 1 Sí
5 CEV02 campo campo
De la tabla N°34 se puede observar que las pruebas realizadas a las compras
fueron exitosas, ya que, en todos los casos de prueba, la respuesta esperada y la
respuesta de la aplicación web coinciden al 100%.
84

Burn Down: Sprint 3

120
100
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12
85
86
3.4 Sprint 4

Analizamos el funcionamiento de la aplicación web en base la comprobación de

inventario, arqueo de inventario, reporte de indicadores y los procesos específicos
que se presentan:

aplicación web.
 El usuario con el rol de jefe de almacén debe programar las comprobaciones
de inventario en la fecha, hora y los productos a comprobar que se
consideren necesarios, designando la tarea a los usuarios con el rol de
almacenero.
 El usuario con el rol de almacenero debe registrar los resultados de su
comprobación de inventario en base a los productos faltantes o sobrantes
que se halló al momento de realizar el conteo.
87
 El usuario con rol de jefe de almacén debe dar por finalizada la
comprobación de inventario cuando lo considere pertinente.
Diseño Conceptual del Sprint 4
En la figura N°95 se muestra el diseño conceptual de la base de datos del Sprint 4.

Se identificaron las entidades (producto, comprobación, usuario) y sus respectivos
atributos (código, estado, fecha, registro); además se analizó las relaciones entre
entidades y su respectiva cardinalidad.
Diseño Lógico del Sprint 4
En la figura N°96 se muestra el diseño lógico de la base de datos del Sprint 4.

creamos una tabla por cada entidad (producto, comprobación, usuario) del diseño
conceptual y cada atributo de la entidad será una columna de la nueva tabla. Para
la relación de las tablas; en el caso de tener una relación de muchos a muchos (tal
es el caso de producto y comprobación) se tendrá que crear una nueva tabla
intermedia (detalle_comprobacion).
88
Diseño Físico del Sprint 4
En la figura N°97 se muestra el diseño físico de la base de datos del Sprint 4; una
89
90

 Modelo: Esta capa contiene los métodos, datos y atributos de cada una de
las entidades utilizadas en este Sprint. Por ejemplo, el jefe de almacén, el
código, la fecha, etc. de una comprobación de inventario programada.
de comprobación de inventario le enviará a la vista la lista de
comprobaciones de inventario que están registradas en la aplicación.
ejemplo, una vista mostrará las comprobaciones de inventario, el arqueo de
inventario y reporte de indicadores.
Comprobación de inventario
Para el desarrollo de la comprobación de inventario, como en toda la aplicación

web, se utilizó el patrón de diseño modelo vista controlador. A continuación, se
muestra fragmentos de código de cada capa del patrón MVC y el resultado de su
implementación.
91
 Comprobación de inventario – Vista
Figura 115: Código de comprobación de inventario - Vista
 Comprobación de inventario – Controlador

Figura 116: Código de comprobación de inventario - Controlador
 Comprobación de inventario – Modelo

Figura 117: Código de comprobación de inventario - Modelo
92
Interfaces de Comprobación de inventario
En las figuras N°101 y N°102, se observa las interfaces gráficas de comprobación

de inventario, la cual permite el registro, consulta y cambiar el estado de las
comprobaciones de inventario registradas, por el jefe de almacén, en la aplicación.
Figura 118: Interfaz de listado de comprobación de inventario
Figura 119: Interfaz de registro de comprobación de inventario
93
Arqueo de inventario
Para el desarrollo del arqueo de inventario, como en toda la aplicación web, se

utilizó el patrón de diseño modelo vista controlador. A continuación, se muestra
implementación.
 Arqueo de inventario – Vista

Figura 120: Código arqueo de inventario - Vista
 Arqueo de inventario – Controlador

Figura 121: Código arqueo de inventario - Controlador
94
 Arqueo de inventario – Modelo
Figura 122: Código arqueo de inventario - Modelo
Interfaces de Arqueo de inventario
En la figura N°106, se observa la interfaz de arqueo de inventario, la cual permite

cuadrar los productos faltantes o sobrantes determinados en la comprobación de
inventario ejecutada por el almacenero asignado.
Figura 123: Interfaz de arqueo de inventario
95
A continuación, se muestra las pruebas de caja negra realizadas a los módulos del
clase.

comprobación de inventario y los casos de prueba de comprobación de inventario
respectivamente.
Tabla 47: Clases de equivalencia de comprobación de inventario
Clases válidas Clases no

C. válidas
Tipo
Entrada Códig Entrada Código Entrad
o a
Camp
Alfanuméri CEV0 CENV0
Código 0<Usuario≤20 o en
co 1 1
blanco
Camp
Fecha 0<Contraseña≤70 o en
co 2 2
blanco
Hora
co 2 3
Jefe Conjunto CEV0 CENV0
{jefe1,jefe2,…}
almacén de datos 2 4
Almacene Conjunto CEV0 {almacenero1,almacenero2 CENV0
ro de datos 2 ,….} 5
Conjunto CEV0 CENV0
Estado {Programado, Finalizado}
de datos 2 6
96
Tabla 48: Casos de prueba de comprobación de inventario
Condiciones de
ID entrada Coincide
Usuario contraseña
CENV01, Completar Ingrese usuario
CP1 SÍ
CENV02 campo y contraseña
CENV01, Completar
CP2 1234 Ingrese usuario SÍ
CEV02 campo
CEV01, Completar Ingrese
CP3 admin Sí
CENV02 campo contraseña
CEV01, Acceso a la Acceso a la
CP4 admin 1234 Sí
CEV02 aplicación aplicación
De la tabla N°36 se puede observar que las pruebas realizadas a las

comprobaciones de inventario fueron exitosas, ya que, en todos los casos de
prueba, la respuesta esperada y la respuesta de la aplicación web coinciden al
100%.

Burn Down: Sprint 4

100
50
0
1 2 3 4 5 6 7 8
97
98

Olivera RJC SD

Cargado por

Copyright:

Formatos disponibles

Olivera RJC SD

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Olivera RJC SD

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA Y ARQUITECTURA

ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA DE

“Aplicación web para el proceso de control de inventario en la empresa

TESIS PARA OBTENER EL TÍTULO PROFESIONAL DE:

El presente proyecto está dedicado al divino

A toda mi familia que me apoyó

Señores miembros del jurado:

Dando cumplimiento a las normas establecidas en el Reglamento de Grados y

Esta investigación tiene como principal objetivo: “Determinar la influencia de una

Y consta de siete capítulos:

En el primer capítulo se realiza el planteamiento del problema: incluyendo

Página del jurado……………………………………………………………………….ii

Tabla 1: Validación de expertos para la selección de la metodología ........... 39

Figura 1: Rotación de Inventario ....................................................................... 19

La presente tesis detalla el desarrollo de una aplicación web para el proceso de

El tipo de investigación es aplicada, el diseño de investigación es pre experimental

El tipo de muestreo empleado fue aleatorio probabilístico simple. Se utilizó el fichaje

Palabras clave: APLICACIÓN WEB, SCRUM, MVC, PHP, MYSQL.

Keywords: WEB APPLICACTION, SCRUM, MVC, PHP, MYSQL

En el escenario internacional, según Lopes y Gómez (2014), en el artículo Auditoría

En el ámbito nacional, según Choque (2016) en la revista Gestión Logística: El

Así mismo, la empresa MAXTECHPERU S.A.C, no es ajena estos problemas. Esta

Según la entrevista realizada al jefe de logística Cleydis Meléndez Salvador (Anexo

Luego los trabajadores se ocupan del almacenaje (productos pasan al almacén de

Cuando un cliente solicita un producto, es atendido por el encargado del área de

Figura 1: Rotación de Inventario

Fuente: Elaboración propia

Realizando el test para el nivel de servicio, se tomó una población de 89 órdenes

Figura 2: Nivel de Servicio

Fuente: Elaboración propia

1.2 Trabajos previos

Para poder realizar esta investigación se ha revisado y evaluado distintas fuentes

El aporte de este estudio fue la referencia brindada para el indicador de rotación de

Alejandro Martínez Giménez, en el año 2016, en la tesis “Aplicación web para el

De este trabajo de indagación se toma como observación teórica la parte de la

De este trabajo se valoró las tecnologías a utilizar para la elaboración de una

Kerly Briggite Lucas Vega, en el año 2017, realizó su investigación “Desarrollo e

El mencionado trabajo fue utilizado como respaldo teórico para la variable

Este antecedente fue de utilidad para la variable dependiente para referenciar el

Este antecedente fue de utilidad para la variable dependiente para referenciar el

Kevin Cruz Alayo, en el año 2015, en la tesis “Sistema web en el proceso de

El aporte de este antecedente fue el indicador de nivel de servicio como referencia

Además, Ulises Juarez Ramirez, en el año 2017, en su tesis “Sistema informático

1.3 Teorías relacionadas con el tema

Podemos definir el inventario como una lista (realizada en un momento

Escudero concuerda con Brenes ya que define el inventario como un informe

Son todas las actividades o prácticas que se tiene en cuenta a la hora de

Complementario a ello se debe garantizar la exactitud entre los registros, tal

Fases para el proceso de control de inventario

La gestión y control de inventario se debe contemplar como un proceso de

Compras: esta fase facilita los componentes indispensables para la

Recepción: se ocupa de las entradas de mercancías, descarga y

Almacén: una vez recepcionada la mercancía se procede a su ubicación y

Entonces, como el autor indica el proceso de control de inventario empieza con la

Indicador: Rotación de Inventario

Este indicador mide la cantidad de veces que se sustituye las existencias, en

La rotación de inventario se puede considerar el ciclo que conlleva en

La rotación de inventario viene dada por la fórmula:

Indicador: Nivel de servicio

El nivel de servicio al usuario o consumidor se calcula estableciendo la