Informe Final

UNIVERSIDAD CATÓLICA BOLIVIANA “SAN
PABLO”
UNIDAD ACADÉMICA REGIONAL COCHABAMBA
Departamento de Ciencias Exactas e Ingeniería
Ingeniería de Sistemas
Sistema web adaptativo para el control de inventarios en la

empresa constructora Estrutec SRL.
Tesis de Licenciatura en Trabajo Dirigido
Jhonny Camacho Encinas
Juslan Pedro Vargas Rejas
Cochabamba - Bolivia
Septiembre de 2022
TRIBUNAL EXAMINADOR
Pablo Luis Sangueza Becerra Nombre del profesor relator
Profesor Guía Profesor Relator
Wendoline Arteaga Sabja Nombre del Rector Regional
Director de Carrera Rector Regional
2
Agradecimientos
Agradecemos a Dios,
a nuestros padres y docentes
por el apoyo a lo largo de
estos años de estudio.
3
Resumen
Palabras clave: Desarrollo web, Aplicación web, Scrum, Sprint, Almacén, ítem,
Maquinaria.
4
ÍNDICE GENERAL
INTRODUCCIÓN 12
1 MARCO REFERENCIAL 13
1.1 ANTECEDENTES 13
1.1.1 Antecedentes institucionales 13
1.1.2 Antecedentes funcionales 15
1.1.3 Antecedentes tecnológicos 21
1.2 PROBLEMA 22
1.2.1 Situaciones Problemáticas 22
1.2.2 Formulación del problema 23
1.3 DEFINICIÓN DE OBJETIVOS 23
1.3.1 Objetivo general 23
1.3.2 Objetivos específicos 23
1.4 JUSTIFICACIÓN 24
1.4.1 Justificación económica 24
1.4.2 Justificación social 24
1.4.3 Justificación tecnológica 25
1.5 ALCANCES Y LÍMITES 25
1.5.1 Límites 25
1.5.2 Alcances 26
1.6 PLAN DE TRABAJO 26
2 MARCO TEÓRICO 29
2.1 Desarrollo de software 29
5
2.2 Paradigmas de desarrollo de software 31
2.3 Metodología Ágil, Scrum 32
2.4 Desarrollo Web 34
2.5 Tecnologías 36
2.5.1 Frontend 37
2.5.2 Datos 38
2.5.3 Lógica 40
3 MARCO PRÁCTICO 42
3.1 Planificación 42
3.1.1 Análisis de requerimientos 42
3.1.2 Roles 43
3.1.3 Modulación y Diagramado 44
3.1.4 Product Backlog 48
3.1.5 Cronograma 48
3.1.6 Arquitectura del sistema 48
3.2 Proceso Scrum 49
3.2.1 Sprint 1: Autorización y Autenticación de usuarios 49
3.2.2 Sprint 2: Gestión de Almacenes 56
3.2.3 Sprint 3: Gestión de Ítems: Registro 63
3.2.4 Sprint 4: Gestión de ítems: Ingresos y salidas en Almacenes 66
3.2.5 Sprint 5: Gestión de Transferencias de ítems 71
3.2.6 Sprint 6: Gestión de pedidos de ítems a proveedor 77
3.2.7 Sprint 7: Visualización de Datos y Responsividad 84
6
3.2.8 Sprint 8: Mantenimiento de equipos pesados 88
3.3 Seguridad 89
3.3.1 Controles de seguridad de información 89
3.3.2 Control de información sensible 92
CONCLUSIONES 94
RECOMENDACIONES 94
BIBLIOGRAFÍA 94
ANEXOS 96
Anexo 1. Árbol de problemas 96
Anexo 2. Diagramas de flujo 96
Anexo 3. Product Backlog 96
7
ÍNDICE DE TABLAS
Tabla 1 Análisis de las ventajas y desventajas del sistema actual Deltawin 22
Tabla 2 Descripción de actividades planificadas 27
Tabla 3 Comparación de UI Frameworks 38
Tabla 4 Comparativa de bases de datos consideradas 39
Tabla 5 Comparativa de tecnologías para desarrollar APIs 41
Tabla 6 Sprint 1 Backlog 50
Tabla 7 Criterios cumplidos en el Sprint 1 55
Tabla 8 Sprint 2 Backlog 57
Tabla 10 Sprint Backlog Sprint 3 64
Tabla 19 Criterios cumplidos en el sprint 7 87
Tabla 22 Product Backlog 97
8
ÍNDICE DE FIGURAS
Figura 1 Logo Estrutec SRL 13
Figura 2 Organigrama Organizacional de Estrutec SRL 14
Figura 3 Llenado y control manual de talonarios físicos 15
Figura 4 Inventario de Almacenes en Excel 16
Figura 5 Modulo de Inventarios en Deltawin, inserción de elementos 16
Figura 6 Hojas de registro de materiales de Estrutec 17
Figura 7 Ingreso de productos en Deltawin 18
Figura 8 Talonario físico de solicitud de material de Estrutec 19
Figura 9 Hoja de registro de maquinarias en Excel 20
Figura 10 Modelo de procesos en Cascada 31
Figura 11 Procesos del desarrollo Incremental 32
Figura 12 Proceso de un Sprint en Scrum 33
Figura 13 Interacción con un sitio web estático 35
Figura 14 Interacción con un sitio web dinámico 35
Figura 15 Descripción de Roles por "Personas" 43
Figura 16 Diagrama de Clases del Sistema 45
Figura 17 Diagrama de Entidad Relación 46
Figura 18 Planificación de iteraciones 48
Figura 19 Descripción de la arquitectura del sistema 48
Figura 20 Landing Page 50
Figura 21 Formulario de Inicio de Sesión 50
Figura 22 Formulario de Registro de usuario 51
9
Figura 23 SideBar implementado 51
Figura 24 Vista de solicitudes 52
Figura 25 Vista de usuarios registrados 52
Figura 26 Gestión de solicitud de acceso 53
Figura 27 Gestión de usuario registrado 53
Figura 28 Opción almacenes en SideBar 57
Figura 29 Lista de almacenes 58
Figura 30 Ítems en un almacén 58
Figura 31 Agregar ítem en almacén 59
Figura 32 Agregar un movimiento de ítem en almacén 59
Figura 33 Visualizar movimientos de ítem en almacén 59
Figura 34 Información de un almacén 60
Figura 35 Opción de ítems en SideBar 63
Figura 36 Tipos de ítems que maneja la empresa 64
Figura 37 Tabla de registros de ítems 64
Figura 38 Opción de quitar ítem de un almacén 66
Figura 39 Formulario de nueva maquinaria pesada 67
Figura 40 Formulario de nueva maquinaria estacionaria 67
Figura 41 Formulario de nuevo Automóvil 68
Figura 42 Formulario de nuevo Material / Herramienta 68
Figura 43 Formulario de nuevo Suministro 69
Figura 44 Opción de Traspasos en SideBar 71
Figura 45 Lista de traspasos completados o cancelados 72
10
Figura 46 Línea de procesos para solicitar traspasos 72
Figura 47 Solicitud de un traspaso 73
Figura 48 Hoja de ruta de traspaso 73
Figura 49 Opción de Pedidos de SideBar 77
Figura 50 Lista principal de pedidos 78
Figura 51 Formulario de agregar solicitud de pedido 78
Figura 52 Lista de pedidos pendientes 79
Figura 53 Solicitud de pedido 79
Figura 54 Detalle de pedido aceptado 80
Figura 55 Formulario para completar compra de pedido 80
Figura 56 Detalle de pedido comprado 81
Figura 57 Opción de Dashboard en SideBar 84
Figura 58 Lista de alertas de solicitudes pendientes 85
Figura 59 Visualización de métrica de rotación de inventario 85
Figura 60 Proceso de uso de JWT 90
Figura 61 Proceso Hash 92
Figura 62 Partes de una URL 93
Figura 63 Encriptación de Id en URL 93
Figura 64 Árbol de problemas 96
11
INTRODUCCIÓN
En Bolivia y el mundo son muchas las personas que asumen riesgos todos los días al
emprender e iniciar un nuevo negocio, en total son más de 300 mil empresas registradas
en Bolivia de las cuales casi (60 mil) (60.000) son de Cochabamba. Dentro de las
responsabilidades de cada una de ellas en definitiva está la de aprovechar y hacer uso de
los recursos tecnológicos más actuales para no perder competitividad y disolverse en el
mercado, y hoy en día los recursos tecnológicos de los que cualquier empresa puede
valerse ya sea para un sistema de ventas, de facturas, de envíos, de inventarios, de
personal, entre otros muchos, son los sistemas de información.
Los sistemas de información han ido evolucionando durante todo este tiempo hasta
toparse dentro de esta última revolución tecnológica como lo es la World Wide Web, una
red global de comunicación. Son muchas las ventajas que los sistemas de información
adquieren a través de la web, rendimiento, fiabilidad, disponibilidad, sin contar toda la
infraestructura que una red interna presupone y que ahora se contrata y se aloja en
servicios de Cloud Computing especializados.
Es por ello que la empresa Estrutec SRL opta por un sistema de información web el cual
le ayude a validar ciertos procesos de negocio con los cuales consideran no tener el
manejo más eficiente y ven en este recurso tecnológico una herramienta muy potente
para impulsar su negocio un paso más.
La empresa Estrutec SRL está dedicada al rubro de construcciones civiles y estructuras

metálicas, dentro de sus contratos, la empresa designa una bodega para el abastecimiento
del material necesario en las diferentes obras de trabajo, este material debe ser
suministrado a la bodega desde otra central y si es que no se tiene existencias hacer una
compra al proveedor y es en este flujo de negocio donde la empresa requiere una gran
cantidad de papeleo, controles, personal y coordinación. Siendo el proceso actual
tedioso, tardío, propenso a fallos e inseguro para los activos, la empresa toma la decisión
de acudir jóvenes trabajadores del área de sistemas para la elaboración de un sistema de
software que haga elevar el nivel de eficiencia de este proceso.
Es en este sentido que un grupo de estudiantes en la etapa final de su carrera de

ingeniería de sistemas de la Universidad Católica Boliviana han tomado la iniciativa de
apoyar con sus conocimientos a la empresa asumiendo el desarrollo de este proyecto
como parte de un Trabajo Dirigido.
12
1 MARCO REFERENCIAL
1.1 ANTECEDENTES
1.1.1 Antecedentes institucionales
Figura 1 Logo Estrutec SRL
Fuente: (Estrutec SRL, 2022).
La empresa se estableció formalmente en el año 2011 bajo el nombre de “Estrutec SRL”.

Inicialmente estaba dedicada al rubro de la metalmecánica, con el pasar de los años y
ganando experiencia en el área también abarcaron el rubro de la construcción civil,
pasando así a ser una empresa distinta y única que provee un servicio completo para el
área de la construcción y la metalmecánica en Bolivia.
Estrutec SRL provee servicio de metalmecánica, desde construcción de coliseos, torres

de comunicación, estaciones de servicio, naves industriales, etc. En el ámbito de la
construcción se tiene un know-how general de obras de ingeniería civil, por otra parte, se
tienen servicio de grúa, servicio y alquiler de Lowboy, servicio de corte-plegado y
cilindrado de planchas.
1.1.1.1 Misión
“Proporcionar a nuestros clientes, servicios de diseño y construcción con asesoramiento

de la mejor calidad, superando sus expectativas, utilizando la mejor tecnología, y
materiales certificados con personal altamente calificado” (Estrutec SRL, 2022).
1.1.1.2 Visión
“Posicionarnos en el ámbito nacional como una empresa líder en el ramo de la

ingeniería, el diseño y la construcción estando a la vanguardia con las nuevas
tecnologías, basándonos en la capacitación y especialización de nuestro personal”
(Estrutec SRL, 2022).
13
1.1.1.3 Organigrama
Figura 2 Organigrama Organizacional de Estrutec SRL
Fuente: Constructora Estrutec SRL, 2022.

La empresa al ser una Sociedad de Responsabilidad Limitada cuenta con un directorio a
la cabeza de toda la organización e inmediatamente secunda la Gerencia General, debajo
se encuentra el personal de asesoramiento tanto jurídico como personal.
Cuenta con 3 jefaturas, dependientes del Gerente Administrativo Financiero, los cuales a
su vez cuentan con administradores, supervisores, encargados y auxiliares.
1.1.2 Antecedentes funcionales
La empresa Estrutec SRL es una empresa dedicada a la construcción civil y de forma

secundaria a la industria de metalmecánica. Dentro de todas las funciones que realizan
sólo se va a enfocar en detallar las cuales son requeridas para su incorporación en el
nuevo sistema, siendo estas; gestión de materiales y activos en almacenes, gestión de
envíos del material entre sucursales y control de cumplimiento de funciones de los
almaceneros.
1.1.2.1 Gestión de materiales y activos en almacenes
Según el manual de funciones del cargo de “Encargado de almacén central” de la

empresa Estrutec, este se encarga explícitamente de registrar todo movimiento
de almacén en el sistema Delta, generar comprobante y hacer firmar toda salida
y entrada. Recibir y revisar la entrega de materiales, herramientas, equipos,
maquinaria y otros diversos al almacén y controlar que los mismos
correspondan a las cantidades, medidas, especificaciones de la orden de compra
y/o nota de entrega. (Estrutec SRL, 2021).
Figura 3 Llenado y control manual de talonarios físicos

La empresa en su necesidad de gestionar sus activos e inventarios hizo uso del sistema
Deltawin en su módulo de almacenes que inició con la transcripción de los datos de
tablas Excel y con ello todos los tipos de herramientas y maquinarias presentes en sus
almacenes. El registro de estos consta de la definición de la cantidad disponible, la
ubicación (almacén actual), cuando se compró, el estado en el que se encuentra (En caso
de activos), grupo al cual pertenece (plomería, eléctrico, entre otros.), entre otros. A
continuación, se presentan los formatos actuales de la empresa.
Figura 4 Inventario de Almacenes en Excel
Fuente: Documentos Almacén Estrutec SRL, 2022.
Dentro del sistema Deltawin la funcionalidad del módulo de almacenes se describe

como el módulo que permitirá el ingreso, salida, traspasos, toma de inventarios y
cualquier otro tipo de movimiento físico valorado en almacenes. En una sola operación,
el sistema genera los registros del documento, libro de compras IVA (Impuesto al Valor
Agregado), la contabilización de la compra o salida con el respectivo abono al proveedor
o cuenta de gasto, e incluso la regularización contable por anticipos a proveedores o
intercambio de servicios.
El primer paso en la gestión de almacenes es el registro digital de todas las herramientas

y maquinarias por almacén.
Figura 5 Modulo de Inventarios en Deltawin, inserción de

elementos
16
Fuente: Manual de uso Deltawin, 2022.
Los registros de materiales se migran hacia hojas de cálculo Excel o viceversa, siendo
muchas veces el medio más accesible de registro rápido por medio de Excel, siendo una
de las principales inconformidades la interfaz del sistema. La estructura de registro en
Excel es el siguiente.
Figura 6 Hojas de registro de materiales de Estrutec
Fuente: Departamento de administración de Estrutec, 2022.
En la empresa se manejan una gran cantidad de herramientas y maquinaria de todo tipo,

una herramienta sola como un alicate puede tener diferentes tipos, con diferentes
17
medidas y tamaños, por ello es que el registro de materiales en el sistema interno es muy
demorado, teniéndose muchas veces el caso de que los registros en almacenes están
desactualizados dejando de ser el punto de información de referencia y siendo el
almacenero la única persona quien tiene el mejor conocimiento acerca de los materiales
en su obra, su cantidad, ubicación, estado, etc. Evidentemente se tiene un proceso muy
lento que es rebasado por la dinámica de los procesos conllevando sin remedio a tomar
cálculos erróneos en los pedidos y una ineficaz gestión.
1.1.2.2 Gestión de envíos del material entre sucursales
Los procesos de ingreso y salidas de material son controlados también, de manera

ineficientemente a través del sistema actual.
El proceso de ingreso de material empieza por localizar dentro del sistema el módulo de
almacenes y crear un nuevo comprobante de ingreso, lo siguiente es ingresar el código
del almacén en la columna Ag, en la columna IN el tipo ingreso o salida, se ingresa la
fecha del ingreso, VQC como número de documento, un código del cliente, hasta
incluso registrar la disminución del impuesto IVA. Una vez llenado el encabezado se
procede a ingresar los ítems, dónde se despliega la lista de todos los elementos creados y
se debe hacer una búsqueda manual en una lista ordenada por código, se ingresa la
cantidad, el precio unitario, el importe y el costo de venta.
Figura 7 Ingreso de productos en Deltawin
Fuente: Manual de uso Deltawin, 2022.
Por otro lado, se encuentra el proceso de salida de material. Este se podría decir que es
desencadenado por el proceso de construcción de una obra la cual requiere el suministro
constante de tanto material, herramientas, maquinarias, entre otros.
18
El proceso de salida inicia con los ingenieros de obra, quienes realizan una planificación
inicial la cual va a determinar un rango de materiales necesarios por semana, luego es el
almacenero quien determina exactamente el material que va a requerir la obra y es
también el que va a validar la llegada del material a la obra. En este flujo se manejan
talonarios físicos (figura 8), de los cuáles se sacan copias, uno para el almacenero, otro
para el chofer, quien hace el envío del material, y otras para oficina central donde se
procesan estos pedidos y donde se deberían registrar en sistema, siendo claramente todo
este proceso muy tardado y propenso a fallos por el manejo de talonarios físicos, sin
mencionar el posterior proceso de validación del gerente.
Figura 8 Talonario físico de solicitud de material de Estrutec
Fuente: Departamento de administración de Estrutec, 2022.
Otra deficiencia está dentro de la gestión del pedido, ya que el transporte de material
está destinado a llevar cantidades mínimas y máximas de material, dándose muchas
veces el caso de que se tiene material sobrante en el envío, el cual debe ser re
transportado perdiendo en cada envío valor por el deterioro que este sufre.
1.1.2.3 Control de cumplimiento de funciones de los Almaceneros
Como se ha mencionado los principales inconvenientes con la gestión actual son por el
módulo de almacenes y la gestión de activos. Hasta ahora se ha hablado de ineficiencias
que ayudan a la devaluación de los bienes, sin embargo, la mayor preocupación va por la
pérdida total de los activos, principalmente materiales y herramientas.
19
Gerencia general ha determinado un tiempo de vida de los activos bastantes cortos, ya
sean por inconvenientes en los envíos o malos cálculos es claro que hay un problema de
sustracción de los activos. Y gracias al proceso actual demorado y con muchas etapas, el
proceso de control y determinación de responsabilidades se hace muy complicado. El
gerente aun estando pendiente de los registros de almacenes en sistema, no logra validar
el proceso antes de que el almacenero ya reporte otro pedido por la falta de material por
pérdida.
Por otra parte, respecto al control de la correcta preservación de los bienes es el

mantenimiento de los activos, en este caso estamos hablando de herramientas y
maquinarias que constantemente necesitan refacciones, recalibraciones, readaptaciones,
y todo tipo de reparaciones para extender su vida útil lo más que se pueda. Pero por la
ineficiente forma en la que se lleva a cabo el control de cada uno de estos, sin dar un
seguimiento a sus servicios realizados, próximos servicios, fechas de servicio, piezas
reemplazadas y otros relacionados. Se tienen las depreciaciones y desgastes acelerados
de los activos, maquinarias, equipos pesados. A continuación, se muestran los registros y
su vaga descripción del estado.
Figura 9 Hoja de registro de maquinarias en Excel
20
Debido a que el uso del sistema requiere capacitación las actualizaciones en sistemas
solo la puede realizar personal en central, entonces desde que un activo no apto para el
trabajo sale de la línea productiva hasta que pasa a un proceso de mantenimiento se
deben dar una gran cantidad de procesos. Una vez más la información que debería ir
desde la primera línea que es la construcción hasta los gestores y administradores se
demora y este tiempo perdido se traduce en costos.
1.1.3 Antecedentes tecnológicos
1.1.3.1 Deltawin
La empresa actualmente cuenta con un sistema contable anticuado para la

automatización de algunos procesos administrativos y operativos. El sistema se
denomina “Deltawin”, fue desarrollado por Sistema Integrado Deltawin y se puso
inicialmente en prueba en la empresa el año 2011 para posteriormente funcionar de
manera oficial en el año 2012 bajo un contrato de naturaleza mercantil logrando
consolidar un sistema que lleva a cabo las siguientes funcionalidades:
- Generación de planilla mensual del personal para reporte al ministerio de trabajo

- Actualización de la Unidad de Fomento a la Vivienda
- Gestión de activos fijos
- Gestión de almacenes
- Gestión de operaciones de banco
- Registro de baja de valor de activos fijos
- Proceso de descruce de ítems
- Gestión del personal
- Gestión de transacciones
- Gestión de importaciones
Como se observa este es un sistema completo de información el cual funciona dentro de

una red interna de la empresa y actualmente se encuentra en funcionamiento. Sin
embargo, existen contras o dificultades que hacen que el sistema no termine de satisfacer
las necesidades de optimización de la empresa, por ello es que a continuación se va a
analizar las ventajas y desventajas que actualmente tiene este sistema. (senadores, 2018)
21
Tabla 1 Análisis de las ventajas y desventajas del sistema actual
Deltawin
Ventajas Desventajas
- Centraliza la información de los - Sistema desactualizado

principales módulos de trabajo de - Interfaz de usuario rústica,
la empresa. confusa y poco intuitiva, tanto
- Estandariza procesos de los que existen manuales de uso para
principales módulos de la cada flujo de funcionalidad
empresa. - No es portable, el sistema no está
- Automatiza trámites y papeleos disponible en sucursales remotas
de administración. como bodegas y obras que se
establecen en diferentes
ubicaciones de acuerdo con el
lugar del contrato de trabajo.
- Necesidad de capacitación del
personal para su uso.
- Costos de capacitación altos.
Fuente: Elaboración propia, 2022.
De acuerdo con la recopilación de características del sistema actual Deltawin, la empresa

Estrutec ha optado por la automatización de un sistema alternativo, el cual cabe aclarar
no está pensado en reemplazar a su predecesor sino funcionar de manera
complementaria abarcando otros módulos de trabajo y mejorando algunos actuales. A
continuación, se va a ver las principales razones que sustentan la decisión de este nuevo
sistema:
- Disponibilidad en todas las bodegas/obras que vaya teniendo la empresa

- Disponibilidad para todos los cargos que interactúen en la gestión de activos y
materiales
- Dependencia de capacitación del personal que use el sistema.
- Necesidad de un medio de control de activos/materiales durante todo tiempo de
permanencia dentro de los flujos de trabajo.
- Descontinuación de uso de talonarios y registros Excel muy tardíos.
1.1.3.2 Sitio web informativo
La empresa también cuenta con un portal web con dominio: estrutec.com.bo, este sitio
se categoriza dentro de las aplicaciones web como un sitio web estático el cual tiene la
22
función de conectar en la web con un navegador y/o potencial cliente para darle a
conocer:
- La información pertinente de la empresa

- Experiencias de trabajos cumplidos
- Números y correos de contacto
- Misión y Visión de la empresa
Este sitio web actualmente está desactualizado y sin la posibilidad de editar contenido o
escalar a nuevo contenido.
1.2 PROBLEMA
1.2.1 Situaciones Problemáticas
● El deficiente manejo manual de pedidos, registros y autorizaciones provoca la

constante pérdida de información y retrasos en los procesos.
● Los datos de materiales acumulados en papel y sin procesar provocan errores en
la toma de decisiones e imprecisión de las cantidades en stock.
● El deficiente control y seguimiento de productos en almacenes provoca pérdidas
en materiales, insumos, consumibles, activos, equipos y herramientas.
● La valoración precaria de los materiales sobrantes conlleva acumulación
excesiva de activos y material con fechas fuera de vigencia.
● Los inventarios desactualizados y demora de registros de nuevos productos
provocan cálculos de reposición y envío de material inexactos.
● La poca disponibilidad de la información de los productos para reportes provoca
tiempos excesivos en cierres de proyectos e información imprecisa.
● Los procesos deficientes de control de entregas y asignación de activos a las
obras provocan un déficit económico en la empresa con respecto a la vida útil
esperada y reposición de estos, pérdida de equipos y material.
● El proceso manual deficiente de control y mantenimiento de equipos pesados
provoca reportes inexactos del estado actual de los activos, información
imprecisa de los próximos servicios de mantenimientos preventivos, gasto de
dinero en mantenimientos correctivos, desgaste y depreciación de los activos de
la empresa.
1.2.2 Formulación del problema
Los deficientes procesos implementados en el sistema actual de gestión de inventarios

en la empresa Estrutec SRL provoca un deficiente manejo manual de pedidos, control de
productos en almacenes, valoración de los materiales, actualización oportuna de
productos, control de entregas y asignación de activos a las obras, mantenimiento de
equipos pesados, poca disponibilidad de la información y acumulación de materiales.
23
1.3 DEFINICIÓN DE OBJETIVOS
1.3.1 Objetivo general
Desarrollar un sistema web adaptativo para el control de inventarios en la empresa

constructora Estrutec SRL.
1.3.2 Objetivos específicos
- Permitir la gestión de pedidos, registros y autorizaciones de materiales de

construcción y sistematización del proceso.
- Facilitar la visualización de datos de almacenes para mejorar la toma de
decisiones.
- Realizar la sistematización del control y seguimiento de productos en almacén
central y sucursales para reducir la pérdida en materiales, insumos, consumibles,
activos, equipos y herramientas.
- Facilitar controles de validación del estado de la vigencia de los materiales
críticos para la generación de alertas tempranas.
- Implementar interfaces adaptativas para la actualización de inventarios desde
dispositivos móviles y realizar cálculos de reposición y envío de materiales
exactos.
- Implementar el módulo de control y mantenimiento de equipos pesados para el
seguimiento de estados, servicios preventivos, reducción de gastos correctivos e
integridad de la información.
- Realizar la puesta a producción del sistema.
1.4 JUSTIFICACIÓN
1.4.1 Justificación económica
Estrutec, como una empresa ya consolidada ha requerido de un sistema de información

propio desde hace mucho tiempo y ha asumido una gran inversión con el sistema actual
Deltawin, sin embargo, este sistema no alcanza a satisfacer las necesidades de la
empresa, sobre todo en el módulo de almacenes, y el retorno de inversión no se dilucida
cuando las contrataciones de capacitación para el uso del sistema cuestan 50$us la hora
y el proceso aún es tardado.
La implementación de este sistema está pensada principalmente para mitigar los grandes
desafíos en la gestión de los activos en todo su proceso dentro del flujo de trabajo,
entonces el poder reducir la pérdida de estos activos y alargar su vida útil le va a
representar a la empresa mayores ingresos económicos.
24
Otro punto muy importante es que la realización de un sistema como este le hubiera
representado a la empresa otra gran inversión, la cual no se pueden permitir en estos
momentos post pandemia.
1.4.2 Justificación social
Estrutec a lo largo de estos años ha desarrollado una buena trayectoria con la

construcción de importantes proyectos en todo el país, desde condominios en la villa
olímpica, estadios de fútbol, coliseos, etc. Obras públicas con gran aporte a nuestra
sociedad, y que al ser una constructora boliviana la encargada de construirlas sienta un
buen precedente en el potencial de nuestras empresas y en la soberanía de nuestros
proyectos.
Estrutec como se ha mencionado anteriormente está en un proceso de reactivación, al

igual que todo el entorno de la construcción que han tenido un gran parón durante estos
dos años de pandemia y han tenido que rescindir de gran parte de su personal. No ha
sido nada extraño ver de vez en cuando manifestaciones de trabajadores dentro del
rubro, sobre todo albañiles, arquitectos e ingenieros civiles.
El aporte de este sistema para con la empresa contribuye directamente al apoyo de su

reactivación, y con ello a la recontratación de cientos de trabajadores bolivianos que
dependen de la empresa para el sustento de su familia.
1.4.3 Justificación tecnológica
Actualmente se ha visto que Estrutec está manteniendo un sistema de información que

no le renta, el sistema está instalado en cada computadora de la central y se comunica a
través de un sistema de red interno y todos los servicios e información resultantes de esta
red alojados en un servidor con todo el costo que esto conlleva.
El resultado finalmente no es el esperado y es que el sistema no aprovecha las grandes

ventajas que el internet ofrece hoy en día y que se acoplaron perfectamente a las grietas
que deja el sistema, ya sea en disponibilidad, accesibilidad y usabilidad.
Por ello es que el sistema que pretende implementar estaría aprovechando los recursos
tecnológicos actualmente más populares, como ser servicios de Cloud Computing para el
alojamiento de los datos y del sistema en línea en internet resolviendo las dificultades
del sistema actual sin reemplazarlo por completo, ya que el sistema con toda su
infraestructura continuaría contribuyendo en otras áreas administrativas u otros módulos
como clientes, personal o tributación.
25
1.5 ALCANCES Y LÍMITES
1.5.1 Límites
Los límites del sistema de información web a realizar para Estrutec son los siguientes:
- El sistema, a pesar de registrar datos del precio de compra, no va a determinar

precios de venta de los activos en almacenes.
- El sistema dentro de su funcionalidad de pedidos y traspasos de materiales
registra el nombre del encargado de transporte o chofer, pero no estará
contemplado como un rol con acceso al sistema.
- El sistema registra a los usuarios que forman parte de la empresa en un cargo, sin
embargo, este registro únicamente se usa para autorizarlos en la aplicación y
registrarlos en sus interacciones dentro de almacenes, no cumple la función de
gestión del personal que ya está contemplada en el sistema actual de la empresa.
- El uso del software estará condicionado al acceso a una conexión a internet.
1.5.2 Alcances
Para cumplir las metas y requerimientos del usuario, el sistema, debe tener
implementados, dentro del módulo de almacenes, las siguientes funcionalidades:
- Gestión de almacenes/obras que consta de: la división de la gestión de

inventarios por sucursales, las cuales se pueden crear, modificar, organizar y
eliminar fácilmente.
- Rápido registro de todo tipo de activos en cada almacén con Realtime Database,
que permitirá recabar información que abarca el nombre clave, descripción,
cantidad en cada almacén, estado del material, fecha de último mantenimiento,
fecha de compra.
- El acceso restringido del sistema de acuerdo con roles o cargos que se ocupe en
la empresa. Esto consta en el registro de los usuarios del sistema, su
autenticación para el acceso al sistema y su autorización hacia las diferentes
funcionalidades del sistema según su cargo lo amerite.
- Gestión de pedidos de material de una sucursal a otra, esto consta de pedidos de
material creados y recibidos por almaceneros, registrados a detalle para luego ser
supervisados por ingenieros de obra o cargos superiores. Esta funcionalidad debe
interactuar con la gestión de los almacenes para modificar las cantidades,
localizaciones y estado de los activos después de un traspaso.
- Fácil control del proceso de negocio por cargos altos, esto consta de una interfaz
visual intuitiva que permita a roles de supervisión ver todas las interacciones de
los usuarios con los datos registrados en almacén, ya sea a través de ingresos
salidas o pedidos entre sucursales.
26
1.6 PLAN DE TRABAJO
Tabla 2 Descripción de actividades planificadas
Objetivos específicos Acciones
Permitir la gestión de pedidos, registros - Obtener el formato de registro de

y autorizaciones de materiales de materiales
construcción y sistematización del - Obtener talonario de pedido
proceso. - Obtener formato de autorizaciones
- Crear modelos de información
- Implementar modelos en la API
- Implementar funciones de
comunicación con el servicio de
almacenamiento
- Implementar interfaz gráfica
Facilitar la visualización de datos de - Obtener modelos de registro de

almacenes para mejorar la toma de materiales de los almaceneros
decisiones. - Modelar Tablas para la base de
datos
- Modelar entidades y estructuras
para la extracción de datos de las
tablas
- Implementar modelos en la API.
almacenamiento
Realizar la sistematización del control y - Obtener descripción del proceso de

seguimiento de productos en almacén envío, identificando agentes y
central y sucursales para reducir la responsabilidades.
pérdida en materiales, insumos, - Obtener notas de entregas y envíos
de material
27
consumibles, activos, equipos y - Diseñar nuevo flujo de registro
herramientas. directo de pedido
- Crear Modelos para el registro
- Implementar Modelos en la API
almacenamiento
Facilitar controles de validación del - Obtener tiempos de vida de

estado de la vigencia de los materiales materiales en la empresa
críticos para la generación de alertas - Listar datos relevantes de los
tempranas. materiales necesarios para el
control de su tiempo de vida
- Incorporar en los modelos un
apartado que contenga estos datos
- Implementar modelos en servicio la
API
almacenamiento
Implementar interfaces adaptativas para - Obtener las dimensiones de

la actualización de inventarios desde pantallas más comunes, que los
dispositivos móviles y realizar cálculos usuarios usan en la empresa.
de reposición y envío de materiales - Por cada dimensión de pantalla
exactos. adaptar la guía de diseño
- Crear prototipos.
- Implementar, en el código, archivos
que contengan los valores para
cada dimensión de pantalla
- Implementar, en el código de las
vistas adaptabilidad de acuerdo con
las dimensiones establecidas.
28
Implementar el módulo de control y - Obtener tiempos de vida de equipos
mantenimiento de equipos pesados para pesados en la empresa
el seguimiento de estados, servicios - Listar datos relevantes de los
preventivos, reducción de gastos equipos pesados necesarios para el
correctivos e integridad de la control de su estado actual y
información. mantenimiento.
- Incorporar en los modelos un
apartado que contenga estos datos
- Implementar modelos en la API.
almacenamiento
Realizar la puesta a producción del - Preparar entregables de la

sistema. aplicación que sean usable para
pruebas de funcionalidad real
- Concertar reuniones periódicas de
retroalimentación a los prototipos
del diseño de la aplicación.
- Crear Stubs y Drivers para realizar
las pruebas de integración entre
módulos de diferentes niveles en la
aplicación
- Realizar pruebas de carga usando el
ingreso de registros, lecturas de
datos, obtención de recursos en
grandes dimensiones.
- Finalizar los testeos probando una
versión final del sistema con
usuarios reales.
- Realizar documentación del
desarrollo del sistema como
manuales de usuario o condiciones
de uso.
- Concertar reuniones para revisar si
el software final cumple con los
requisitos iniciales.
29
- Lanzamiento del sistema para su
uso en la empresa.
2 MARCO TEÓRICO
2.1 Desarrollo de software
(¿Cómo se va a implementar la solución?)
Dentro de las soluciones tecnológicas imprescindibles para un negocio se encuentra un

software, un programa computacional que ayude a optimizar tareas operaciones
humanas, guardar información y conectar las estructuras de la empresa. Un software, sin
embargo, no son solo programas, sino todos los documentos asociados y la
configuración de datos que la hacen funcionar correctamente (Sommerville, 2011). En
este contexto, la creación del software es un proceso complejo que ha necesitado del
desarrollo de un área de estudio a lo largo de la historia, esta se denomina: Ingeniería del
software.
La ingeniería del software es una disciplina que comprende todos los aspectos de la
producción de software. Comprende las formas prácticas para desarrollar y entregar un
software útil, formando parte metodológica de toda la disciplina de la ingeniería de
sistemas (Sommerville, 2011).
Mientras todos los proyectos de software necesitan un desarrollo y administración

profesional, diferentes técnicas son apropiadas para diferentes tipos de software, no es
correcto afirmar que existe un método mejor que otro, la ingeniería se trata de elegir
el método más apropiado para un conjunto de circunstancias, en este caso, en el
desarrollo de sistemas Web, un proceso de desarrollo menos formal es particularmente
apropiado (Sommerville, 2011, pág. 8).
Entonces ya que no hay métodos universales y técnicas que se ajusten a todo tipo de
sistemas, es necesario determinar qué tipo de sistema es el que vamos a desarrollar,
existen diferentes características que se acomodan dentro de los tipos de software, pero
el tipo de software que mejor se ajusta a la definición de la solución que buscamos es:
una “Aplicación interactiva basada en transacciones”. Estas aplicaciones se ejecutan en
computadoras remotas donde los usuarios se conectan desde sus propios dispositivos,
dentro de este tipo de software, evidentemente, están las aplicaciones web, estas
aplicaciones interactivas a menudo incorporan un gran almacén de datos, el cuál es
accedido y actualizado en cada transacción (Sommerville, 2011, págs. 20, 21).
30
A pesar de la gran diversidad del software existen atributos escenciales con los que este
debe contar, estas características con las que un software profesional debe contar son:
- Mantenibilidad. -El sistema debe estar construido de tal manera que pueda
evolucionar de acuerdo con los requerimientos cambiantes de los usuarios.
- Fiabilidad y seguridad. -El sistema no debe causar daños económicos o físicos
si llega a fallar, además no debe permitir que usuarios maliciosos accedan o
dañen el sistema
- Eficiencia. -El sistema no debe malgastar los recursos de memoria o procesado
del sistema.
- Aceptabilidad. -El sistema debe ser aceptado por el tipo de usuario para el que
fue diseñado.
2.2 Paradigmas de desarrollo de software
(¿Qué enfoques de desarrollo existen? ¿Cuál es más adecuado?)
En el desarrollo de software, un modelo de proceso de software es una representación

simplificada de un proceso de software. Cada modelo de proceso representa un proceso
desde una perspectiva particular y, por lo tanto, proporciona solo información parcial
sobre ese proceso. Por ejemplo, un modelo de actividad de proceso muestra las
actividades y su secuencia, pero puede que no muestre los roles de las personas
involucradas en estas actividades. En esta sección, se presenta una serie de modelos de
procesos muy generales (a veces llamados "paradigmas de procesos o de desarrollo") y
son presentados desde una perspectiva arquitectónica.
Estos modelos genéricos no son descripciones definitivas de procesos de software. Más

bien, son abstracciones del proceso que se pueden usar para explicar diferentes enfoques
del desarrollo de software. Se puede pensar en ellos como marcos de procesos que
pueden extenderse y adaptarse para crear procesos de ingeniería de software más
específicos.
Los modelos son:
Modelo cascada. - El modelo en cascada es un ejemplo de un proceso impulsado por un

plan: en principio, debe planificar y programar todas las actividades del proceso antes de
comenzar a trabajar en ellas.
31
Figura 10 Modelo de procesos en Cascada
Fuente: (Sommerville, 2011)
Desarrollo Incremental. - El desarrollo incremental se basa en la idea de desarrollar una

implementación inicial, exponerla a los comentarios de los usuarios y hacerla
evolucionar a través de varias versiones hasta que se haya desarrollado un sistema
adecuado. Las actividades de especificación, desarrollo y validación están intercaladas
en lugar de separadas, con una rápida retroalimentación entre actividades.
El desarrollo de software incremental, que es una parte fundamental de los enfoques

ágiles, es mejor que un enfoque en cascada para la mayoría de los sistemas
empresariales, de comercio electrónico y personales. El desarrollo incremental refleja la
forma en que resolvemos los problemas. Rara vez elaboramos una solución completa del
problema por adelantado o con una planificación total, sino que avanzamos hacia una
solución en una serie de pasos, retrocediendo cuando nos damos cuenta de que hemos
cometido un error. Al desarrollar el software de forma incremental, es más barato y fácil
realizar cambios en el software a medida que se desarrolla.
Cada incremento o versión del sistema incorpora algunas de las funcionalidades que
necesita el cliente. Generalmente, los primeros incrementos del sistema incluyen la
funcionalidad más importante o requerida con mayor urgencia. Esto significa que el
cliente puede evaluar el sistema en una etapa relativamente temprana del desarrollo para
ver si ofrece lo que se requiere. De lo contrario, solo se debe cambiar el incremento
actual y, posiblemente, definir una nueva funcionalidad para incrementos posteriores.
32
Figura 11 Procesos del desarrollo Incremental
Fuente: (Sommerville, 2011)
2.3 Metodología Ágil, Scrum
(¿Por qué se va a usar esta metodología? ¿Cómo se la pretende aplicar?)
Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y

organizaciones a generar valor a través de soluciones adaptativas para problemas
complejos.
Scrum emplea un enfoque iterativo e Incremental para optimizar la previsibilidad y

controlar el riesgo. Scrum involucra a grupos de personas que colectivamente tienen
todas las habilidades y experiencia para hacer el trabajo y compartir o adquirir dichas
habilidades según sea necesario.
Los pilares empíricos de Scrum se definen como: Transparencia, Inspección y

Adaptación. Cada uno de estos pilares depende del anterior para ser funcionales, por
ejemplo, la inspección sin transparencia es un derroche e ineficiente, igualmente la
inspección sin adaptación es inútil, el propósito de inspeccionar es detectar problemas,
los cuales deben ser ajustados en un proceso de adaptación (Schwaber & Sutherland,
2020, p. 4).
La metodología de Scrum define un marco de trabajo con eventos definidos y roles

dentro de un equipo, el Scrum Team. El Scrum Team consta de un Scrum Master, un
Product Owner y Developers. Dentro de un Scrum Team, no hay sub-equipos ni
jerarquías. Es una unidad cohesionada de profesionales enfocados en un objetivo a la
vez, el Objetivo del Producto.
Para este proyecto vamos definimos al Product Owner al gerente general de Estrutec
SRL, como Scrum Master va a figurar el tutor asignado y el equipo de trabajo somos los
autores del proyecto.
33
Cada evento en Scrum es una oportunidad formal para inspeccionar y adaptar los
artefactos Scrum. Estos eventos están diseñados específicamente para habilitar la
transparencia requerida. No operar cualquier evento según lo prescrito resulta en la
pérdida de oportunidades para inspeccionar y adaptarse. Los eventos se utilizan en
Scrum para crear regularidad y minimizar la necesidad de reuniones no definidas en
Scrum. Lo óptimo es que todos los eventos se celebren al mismo tiempo y en el mismo
lugar para reducir la complejidad.
Figura 12 Proceso de un Sprint en Scrum
Fuente: (Scrum, 2020)
Todos los eventos de Scrum son contenidos dentro de un Sprint. Todo el trabajo
necesario para lograr el Objetivo del Producto, incluido la Sprint Planning, Daily
Scrums, Sprint Review y Sprint Retrospective, ocurre dentro del Sprint. (Schwaber &
Sutherland, 2020)
Los eventos o ceremonias en el desarrollo del proyecto van a ser adaptadas a la

composición del equipo, que consta de dos desarrolladores. Para ello se darán
cumplimiento a las siguientes: Sprint Planning, Daily Scrums, Sprint Review y Demo.
Los Sprints son el corazón de Scrum, donde las ideas se convierten en valor. Son eventos
de duración fija de un mes o menos para crear consistencia, un nuevo Sprint comienza
34
inmediatamente después de la conclusión del Sprint anterior (Schwaber & Sutherland,
2020, p. 7). En el caso de este proyecto cada Sprint se aproxima a los 14 días de trabajo.
2.4 Desarrollo Web
(¿Qué son? ¿Qué tipos hay? ¿Por qué se escogió este tipo de software?)
El desarrollo web como lo indica el nombre tiene que ver con la Web o World Wide Web,
que engloba distintos sitios web enlazados y accedidos mediante internet. Entonces el
desarrollo web es la construcción y el mantenimiento de los sitios web, lo que incluye a
las aplicaciones (Seguro, 2021).
La experiencia de usuario en una aplicación web es diferente a una experiencia en una

aplicación de escritorio, el almacenamiento de los datos, limitaciones con la interfaz de
usuario y el limitado acceso a las características del sistema operativo son algunas de las
distinciones. Entre la variedad de ventajas que tiene una aplicación web se encuentran:
- Accesibilidad desde cualquier dispositivo conectado a internet.

- Funcional con diferentes sistemas operativos y browsers.
- Actualizaciones de las aplicaciones sólo deben ser instaladas en un computador y
no en todas las computadoras instaladas.
- Almacenamiento centralizado en un solo lugar significa menores preocupaciones
de seguridad.
(Connolly & Hoar, 2015)
A lo largo de la historia, desde los inicios de internet, se han ido desarrollando y

evolucionando distintas formas de crear sitios web, comenzando con lo que se conoce
como un sitio web estático. Estos sitios web únicamente permiten al usuario interactuar
con la aplicación leyendo y navegando a través de esta, sin poder dar retroalimentación o
actualizar información del sitio.
35
Figura 13 Interacción con un sitio web estático
Fuente: (Connolly & Hoar, 2015)
A medida que el internet fue creciendo los sitios web se fueron haciendo cada vez más
complejos, ahora los sitios web necesitaban generar contenido dinámicamente, a estas
aplicaciones se denominan sitios web dinámicos. Estos crean el contenido mostrado al
usuario en tiempo real por lo que el contenido va a variar entre usuarios.
Figura 14 Interacción con un sitio web dinámico
Fuente: (Connolly & Hoar, 2015)
36
En la última década, dominó un paradigma que cambió la forma en la que los sitios web
dinámicos eran creados, la Web 2.0. La lógica antes solamente programada en el
servidor ahora también necesitaba ser implementada en el browser
El desarrollo web requiere de gente con habilidades diferentes pero complementarias

unidas para alcanzar un mismo objetivo, estas habilidades irán de acuerdo con las
diferentes secciones de una aplicación web, ya sea al apartado gráfico, a la
administración de los datos o al funcionamiento lógico de la aplicación (Connolly &
Hoar, 2015).
2.5 Tecnologías
(¿Capas de una aplicación Web? ¿Qué tecnologías existen para cada capa? ¿Cuáles se
van a usar? ¿Por qué?)
En un proyecto de software es necesario definir el conjunto de tecnologías que se van a

usar en las diferentes capas de arquitectura de una aplicación. En el desarrollo de
software se definen, en general, 5 capas:
- Frontend
- Api
- Data
- Lógica
- Hosting
(Connolly & Hoar, 2015)
Entonces es necesario definir un Tech Stack. Este se define como el conjunto de

tecnologías que utiliza una organización para crear una aplicación web o móvil. Es una
combinación de lenguajes de programación, marcos, bibliotecas, patrones, servidores,
soluciones UI/UX, software y herramientas utilizadas por sus desarrolladores (Theme
Selection, 2022).
Las tecnologías usadas en cada capa de la aplicación se van a presentar y justificar a

continuación.
2.5.1 Frontend
Los lenguajes de programación en este apartado ya están estandarizados, HTML, CSS y

JavaScript. Las 3 tecnologías son indispensables y son usadas en prácticamente todos
los proyectos de aplicaciones web 2.0.
37
El dilema surge en el denominado UI Framework, que se define como la herramienta
para implementar elementos prediseñados en la interfaz de usuario. Estas herramientas
se han popularizado gracias a que proporcionan elementos con diseño elegante y
reducen tiempos de codificación.
Los principales UI Frameworks en la actualidad son: Angular, Reactjs y Vue.js. Los 3

han demostrado ser útiles ya sea en proyectos pequeños como en sistemas extensos, sin
embargo, se trata de tecnologías diferentes, todas con beneficios y desventajas.
Tabla 3 Comparación de UI Frameworks
Tecnología Arquitectura Ecosistema Rendimiento
Vue.js Se relaciona con el Es un framework Llega a ser más lenta

patrón MVVM, progresivo porque que las otras 2 en el
pero no de forma extiende fácilmente su manejo de tablas.
estricta. funcionalidad en
Proporciona paquetes terceros.
Angular Se basa en el patrón Cuenta con muchos Tiene métricas de

MVC. componentes listos tiempo bajas a la hora
para usar y que de iniciar y presentar
fácilmente se pueden las interfaces.
importar.
Reactjs No impone una Reactjs dispone Junto con Angular

estructura de fácilmente la tienden a tener
proyecto única. Da administración del soluciones de código
flexibilidad y estado global de las más largas.
simplicidad para variables en la
cualquier aplicación.
estructura.
Fuente: Elaboración propia.
De acuerdo con el análisis previo vamos a optar para este proyecto por Reactjs, debido a
su flexibilidad, simplicidad, baja curva de aprendizaje, buen rendimiento y diversidad de
soporte y tecnologías compatibles.
2.5.2 Datos
En esta capa se definen tecnologías relacionadas a la administración de Bases de Datos.

Esta capa nos va a ayudar a responder cuestiones tales como: ¿dónde vamos a almacenar
nuestros datos? y ¿de qué manera vamos a gestionarlos? Al tratarse de una aplicación
38
web, la aplicación debería funcionar en un servidor remoto, por lo que el
almacenamiento de la información no puede ser de manera local.
Por lo tanto, al momento de elegir el tipo de Base de Datos se tienen 2 opciones en el

contexto actual, o del tipo relacional o no relacional. En este caso una Base de Datos no
relacional, la cual está pensada para mejorar el rendimiento en consultas para un enorme
volumen de datos, no va a ser necesario para un sistema interno en una mediana
empresa.
Entonces la selección de una tecnología se va a contemplar dentro del rango de bases de

datos relacionales funcionales para aplicaciones web. En este rango se contemplan
varias opciones como ser: MySQL, PostgreSQL, The Oracle, Microsoft SQL Server,
entre otros. A continuación, se hará una comparativa entre las más populares
actualmente (Sis4Gen, 2022).
Tabla 4 Comparativa de bases de datos consideradas
Nombre de BBDD SQLite MySQL PostgreSQL
Arquitectura Basado en archivos Cliente/Servidor Cliente/Servidor
Soporte de ActionScript, Ada, C, C++, Delphi, NET, C, C++,

Lenguajes Basic, C, C#, C++, Perl, Java, Lua, Delphi, Java, Perl,
D, Delphi, Forth, .NET, Node.js PHP, Python, Tcl.
Fortran, Haskell,
Java, JavaScript,
Lisp, Lua,
MATLAB, PHP,
PL/SQL
Casos de uso - Sitios web - Aplicaciones - Analíticas

de tráfico Web - Data Mining
bajo - Aplicaciones - Inteligencia
- Software basadas en de Negocio
IOT OLTP - Data
- Testing warehousing
Principales Adobe, Facebook y GitHub, Facebook y Cloudera, Instagram

aplicaciones Apple YouTube. y ViaSat
39
En la comparativa anterior se observan varias similitudes entre estas tecnologías, las 3
son muy populares en el desarrollo web, por lo que el propósito de la aplicación es el
que determina cuál va a ser la mejor elección. Las tres son tecnologías son Open Source,
es decir, de acceso y uso libre, se respaldan por una gran comunidad y compañías serias,
además que, brindan seguridad y soporte a sus usuarios. Pero en nuestro criterio
PostgreSQL se acopla de mejor manera a las funcionalidades que va a presentar la
aplicación.
PostgreSQL es también llamado el Oracle gratuito, sus funcionalidades más avanzadas,

seguridad e integridad de los datos cada vez proyectan esta tecnología a superar a
MySQL en el mercado. MySQL como se describe en la comparativa (Tabla 4), es usada
para todo tipo de aplicaciones web debido a su buen rendimiento en la lectura de grandes
volúmenes de datos, por otro lado, PostgreSQL muestra, además, un buen rendimiento
en la escritura de datos, siendo preferida para aplicaciones para analíticas o inteligencia
de negocio.
Es por lo anterior que, en una aplicación de manejo de almacenes, donde la integridad y

seguridad de los datos es esencial, donde se va a requerir tanto escritura como lectura de
datos, donde se va a implementar inteligencia de negocio a partir de los datos de la
empresa es que se opta por PostgreSQL.
2.5.3 Lógica
En esta capa se encuentra la lógica principal de la aplicación. Algunos desarrolladores

llaman a esto la capa de negocio ya que está modelando las reglas y procesos del
negocio para el que se está escribiendo la aplicación (Connolly & Hoar, 2015, pág. 581).
Una regla de negocio se refiere no solo a la validación de entradas de un usuario

habitual, sino también a las reglas más complejas para los datos, que son específicos a
los métodos de una organización para llevar a cabo los procesos del negocio (Connolly
& Hoar, 2015, pág. 582).
Algunos autores se refieren a las clases dentro de la capa "media" o lógica, como objetos
de negocio; otros autores las llaman entidades u objetos de dominio.
Independientemente de cómo se llamen, los objetos de negocio representan tanto los
datos como el comportamiento de los objetos que corresponden al dominio conceptual
del negocio (Connolly & Hoar, 2015, pág. 582). Estas entidades o modelos de datos
obtenidos de la capa de Datos necesitan llegar hacia la capa Frontend y es ahí donde una
API es requerida.
Una Application Programming Interface o API, es un conjunto de reglas definidas que

explican cómo las computadoras o las aplicaciones se comunican entre sí. Las API se
sitúan entre una aplicación y el servidor web, actuando como una capa intermediaria que
40
procesa la transferencia de datos entre sistemas. El proceso comienza cuando se hace un
pedido de información o request, este pedido es procesado hacia un método de un
recurso mediante el URI (Uniform Resource Identifier) y un método o verbo HTTP,
luego se ejecuta el método de obtención del recurso y se genera una respuesta o response
de parte del servicio de Datos, la API termina por retransmitir esa respuesta al servicio
solicitante (IBM, 2020).
Entonces en esta capa es necesario seleccionar la tecnología adecuada para implementar

una API de tipo interna (sólo accesible por Estrutec SRL) y con el protocolo REST
(Representational State Transfer). Existen muchos lenguajes y Frameworks para
implementar este tipo de APIs y por ello se presenta a continuación una comparativa.
Tabla 5 Comparativa de tecnologías para desarrollar APIs
Nombre Node.JS PHP ASP.Net
Rendimiento Buen rendimiento Necesita un Tiene una

gracias a sus emparejamiento ejecución
estructuras con una máquina optimizada, acceso
asíncronas de virtual HHVM para optimo a base de
JavaScript V8 mejorar el datos con LINQ y
Engine. rendimiento. conexión
persistente.
Escalabilidad Diseñado para Esta pensada para Simplifica el

implementar alojar servidores proceso de escalar
aplicaciones específicos ya que no tiene
escalables ya que centralizados que Machines
usa un modelo no escalen con adicionales.
asíncrono basado otros servidores,
en eventos.
Frameworks Cuenta con Cuenta con un Cuenta con

librerías de gran catálogo diverso y librerías de
expansión y de gran trayectoria diferentes tipos
fiabilidad como como Laravel, como Framework
Express, Meteor, CakePHP o Class Library,
Derby o Sails. Phalcon. Common Language
Runtime o Core
Language
(ASP.NET Core).
Hosting Tiene un amplio Está diseñado para Impulsado por

rango de ser compatible con Microsoft, cuenta
41
alternativas para casi cualquier con sus propias
elegir, además de servicio de hosting. tarifas y softwares
simplicidad en el para web hosting.
proceso de deploy.
Fuente: (SimpliLearn, 2022).
En este proyecto se va a priorizar la simplicidad del código, la escalabilidad, un buen

rendimiento y facilidad en la puesta en producción de la aplicación web, por ello, se va a
optar por usar Node.JS y el framework Express para desarrollar no solo uno, sino varios
APIs para diferentes módulos de la aplicación.
3 MARCO PRÁCTICO
3.1 Planificación
En este capítulo, se describe la implementación de la metodología SCRUM, una

metodología ágil basada en ciclos de desarrollo o Sprints. Antes de comenzar con este
proceso iterativo se deben dar eventos previos donde se definen: personas y roles del
proyecto, requerimientos, casos de uso, un cronograma, arquitectura y patrones de
diseño.
Como se menciona anteriormente un Sprint comienza con una lista de tareas a realizar
llamada Product backlog, por lo que un primer paso es el de definir las tareas de esta
lista. Para ello es necesario que la visión de la aplicación que tiene el equipo de
desarrollo este en sintonía con la que tiene el cliente, para lo que se deben concertar
reuniones y trabajar colaborativamente con el cliente en esta etapa previa al desarrollo.
En este caso el cliente va a ser representado por el gerente general de Estrutec SRL, es
con su colaboración con la que primeramente se va a hacer un análisis a los
requerimientos de la aplicación.
3.1.1 Análisis de requerimientos
En el marco referencial del presente proyecto se definen las principales situaciones

problemáticas que la aplicación debe ayudar a mitigar y los objetivos específicos que se
van a cumplir con el desarrollo de la aplicación. Con todo ello y desde una visión
técnica, es que se desarrollan los requerimientos de una aplicación, estos se definen
formalmente, según la IEEE (Standard Glossary of Software Engineering Terminology),
como una representación documentada de una condición o capacidad que debe cumplir o
poseer un sistema o componente del sistema para satisfacer una necesidad o
especificación del usuario.
42
En la primera reunión con el cliente se definió como objetivo el de establecer la
“product vision”, esta es una declaración sucinta que define la esencia del producto que
se está desarrollando y explica cómo el producto difiere de otros productos
competidores. En este caso se va a usar el formato de Geoffrey Moore para definir el
“product vision”.
El: Sistema de Inventarios Estrutec SRL
Es: una aplicación WEB.
Que: pretende posicionarse como aplicación de gestión de envíos y administración de

activos/materiales y herramientas/maquinarias.
En lugar de: talonarios físicos de salidas o tablas de Excel.
Con el valor diferenciador de: ofrecer una experiencia sencilla para todo tipo de
consumidor y con una privacidad absoluta de las comunicaciones.
3.1.2 Roles
Otra pregunta que realizarse para un equipo de trabajo en esta etapa de planificación es
"¿Quiénes son los usuarios objetivo de mi producto?". Es necesario tener cierta
comprensión de los usuarios potenciales con el fin de diseñar características que son
propensos a encontrar útil y para diseñar una interfaz de usuario que se adapte a cada
uno de ellos.
De acuerdo con el cliente, existen hasta 6 cargos de la empresa involucrados en los

procesos de negocio en los que el sistema se pretende integrar. Estos cargos y sus
funciones por desempeñar en el sistema, de acuerdo con el criterio del cliente, son los
siguientes.
- Ingeniero residente de obra (balance inicial y cronograma de obra). -Solicita

material a una sucursal (obra/proyecto).
- Almaceneros/Bodegueros (Siempre en Central Cochabamba). -Registra el
material que ingresa o sale de bodega.
- Almacén Central y Adquisiciones (Cochabamba). -Registra el pedido, Registra
ingreso material desde el proveedor y habilita salida de material hacia una
sucursal.
- Jefe de Finanzas (Autorización) - Visto bueno de compra.
- Gerencia (Supervisión). - Visto bueno de compra.
Con esta información, el equipo debe identificar que operaciones dentro del sistema
tendría que poder realizar cada cargo, a partir de ello es posible identificar si 2 o más
43
cargos diferentes pueden llegar a coincidir en sus responsabilidades dentro del sistema y
así, agruparlos en un tipo de usuario. Con esto el equipo pretende definir las “personas”
o tipos diferenciados de usuarios que va a usar el sistema para diferentes propósitos o de
diferente manera. Cada “persona” va a tener acceso a diferentes funcionalidades dentro
del sistema y va a tener el acceso restringido a otras. Las “personas” identificadas dentro
del sistema son:
Figura 15 Descripción de Roles por "Personas"
3.1.3 Modulación y Diagramado
3.1.3.1 Diagramas de flujo
Una vez determinados los usuarios y sus responsabilidades, se determinan los procesos
que estos van a seguir para completar cualquier objetivo que se propongan a realizar con
nuestra aplicación, y para ello se usan diagramas, que describen los denominados “User
Flows” (Flujos del usuario), por los cuales, tanto el equipo de desarrollo como el cliente
van a poder visualizar todas las funcionalidades que se proponen desarrollar y también
entender como estas ayudan a cumplir los objetivos específicos planteados para el
sistema.
El equipo de desarrollo, antes del inicio de cada Sprint, diseñó el diagrama en conjunto,
se validó el funcionamiento y durante el proceso del sprint se fueron agregando
elementos importantes que concretan el flujo descrito.
Todos los diagramas de flujo creados durante el proceso de desarrollo están en la sección
de Anexos, Diagramas de flujo.
3.1.3.2 Diagramas de Clase
44
Los diagramas de clases son uno de los tipos de diagramas más útiles en UML, ya que
trazan claramente la estructura de un sistema concreto al modelar sus clases, atributos,
operaciones y relaciones entre objetos. Gracias a este diagrama el equipo pudo modelar
entidades como clases y determinar todos los atributos que se iban a contemplar en la
lógica del sistema.
La elaboración del diagrama de clases se ha desarrollado progresivamente durante el

desarrollo del proyecto, una vez se daba inicio con el desarrollo de un módulo, se
incorporaban las clases en este diagrama.
45
Figura 16 Diagrama de Clases del Sistema

3.1.3.3 Diagrama de entidad relación
Un diagrama de relación de entidad (ERD), también conocido como modelo de relación

de entidad, es una representación gráfica que representa las relaciones entre personas,
objetos, lugares, conceptos o eventos dentro de un sistema informático Un ERD utiliza
técnicas de modelado de datos que pueden ayudar a definir los procesos de negocio y
servir como base para una base de datos relacional.
Con este diagrama se usó de base para la creación de nuestra base de datos relacional, la
cual es extensa y de alta complejidad como se observa en la figura siguiente.
Figura 17 Diagrama de Entidad Relación

48
3.1.4 Product Backlog
De acuerdo con la metodología SCRUM, el equipo de desarrollo necesita tener, durante

todo el proceso iterativo, una lista de “Historias de usuario” o pequeñas descripciones de
los requerimientos del usuario, con las que el equipo organiza el trabajo de tal manera
que cada historia se le asigna a un miembro del equipo, se estima el tiempo de
finalización y se toma cuenta del valor agregado al implementar la historia.
3.1.5 Cronograma
Una vez creado nuestro “Product Backlog” es posible hacer una planificación de los
Sprints necesarios para completar las tareas en un determinado tiempo. El equipo de
desarrollo acordó, en cada uno de los Sprints, implementar tareas de un mismo módulo y
si el periodo de un Sprint (2 semanas) no alcanzaba para concluir el módulo, continuar
en el siguiente.
El Cronograma final se plantea en la Figura siguiente, donde el primer Sprint comienza

el 28 de marzo y se propone la conclusión de todo el proyecto en un total de 10 Sprints.
Figura 18 Planificación de iteraciones
(Cronograma de Sprints)
Fuente: Elaboración propia.
3.1.6 Arquitectura del sistema
La arquitectura de software surge de la necesidad de tener una organización, que le dé

sentido al proyecto el cual consiste en grandes cantidades de implementaciones de
código los cuales precisamos sean mantenibles y escalables a largo plazo. Para ello se
implementan y desarrollan formas o guías generales para obtener una estructura y
organización.
La estructura del sistema va a seguir un patrón arquitectónico basado en capas y

microservicios. Como es comúnmente propuesto, se tiene una capa de presentación
seguida de una capa de lógica y otra capa de administración de datos, donde en la capa
de lógica y obtención de datos es posible subdividir secciones de código de acuerdo con
los módulos identificados,
La Arquitectura del sistema se puede observar con el siguiente diagrama:
49
Figura 19 Descripción de la arquitectura del sistema
3.2 Proceso Scrum
3.2.1 Sprint 1: Autorización y Autenticación de usuarios
3.2.1.1 Planeación
(¿Que US se van a realizar?)
La planificación de este Sprint se hizo a partir de la separación de las “Historias de

usuario” correspondientes del módulo de Autorización y Autenticación del
Product Backlog. A continuación, observamos la lista de actividades
planificadas.
Tabla 6 Sprint 1 Backlog
SPRINT 1: Autenticación y Autorización

Sprint Inicio Fin Duración hrs. Días
1 28/03/22 08/04/22 112 12
SPRINT BACKLOG
Backlog ID Tarea Tipo Rol
1 Registrar un usuario Desarrollo Usuario
2 Asignar rol a usuario Desarrollo Usuario
3 Habilitar el registro de un usuario Desarrollo Gerente
4 Gestionar usuarios registrados Desarrollo Gerente
5 Inicio de sesión de un usuario Desarrollo Usuario
50
6 Vistas alternativas Diseño Usuario
7 Implementar SideBar Desarrollo Usuario
3.2.1.2 Desarrollo
(¿Cúanto tiempo ha tardado? y algún detalle)
El desarrollo de este Sprint se realizó de acuerdo con el marco de trabajo y acuerdos del
grupo de trabajo. Además, no se requirió más tiempo del planificado.
Se inicia primero con el diseño de la página con la que se tiene el primer contacto.
Figura 20 Landing Page
A continuación, se desarrolló el formulario donde el usuario ingresa sus credenciales

para iniciar sesión en el sistema.
51
Figura 21 Formulario de Inicio de Sesión
Si el usuario no tiene una cuenta creada, usa el siguiente formulario para crear una
cuenta.
Figura 22 Formulario de Registro de usuario
Una vez dentro del sistema se tiene una barra lateral con una pestaña de “Registros” para
acceder a las vistas de este módulo.
52
Figura 23 SideBar implementado
Se implementó la vista con todas las solicitudes de acceso de usuarios.
Figura 24 Vista de solicitudes
También se tiene una vista para los usuarios ya aceptados con acceso a la aplicación.
53
Figura 25 Vista de usuarios registrados
El usuario administrador podrá rechazar o aceptar una solicitud de acceso.
Figura 26 Gestión de solicitud de acceso
Cada usuario registrado dispone de una ficha con sus datos y la opción de eliminarlo,
que significa que se le remueve el acceso a la aplicación.
Figura 27 Gestión de usuario registrado
54
3.2.1.3 Resultados
Finalizada la etapa de desarrollo se pueden evaluar los criterios de validación de cada

“Historia de usuario” implementada y así darla por completada.
Tabla 7 Criterios cumplidos en el Sprint 1

Backlog
ID: 1 Registrar un usuario
Criterios de Validación
# Estado Resultados
La pantalla de registro se muestra si ingresa por primera vez a la
1 Validado
aplicación
Se puede ingresar el nombre completo en el campo "Nombre Completo"
2 Validado
del formulario
Se puede ingresar un correo electrónico en el campo "Correo
3 Validado
Electrónico" del formulario
Se puede ingresar su fecha de nacimiento en el campo "Fecha de
4 Validado
Nacimiento" del formulario
5 Validado Se puede ingresar su CI en el campo "Carné de identidad" del formulario
Se puede ingresar el número de celular en el campo desplegable
6 Validado
"Número de Celular" del formulario
Se puede seleccionar el cargo al que se desea tener acceso en el sistema
7 Validado
de la empresa, en el campo desplegable "Cargo" del formulario
Se puede ingresar la contraseña de la cuenta con mínimo 8 caracteres en
8 Validado
el campo "Contraseña" del formulario
Backlog
ID: 2 Asignar rol a usuario
55
# Estado Resultados
1 Validado Se registra la lista de privilegios habilitados para cada cargo de un usuario
Se valida el acceso a los recursos de acuerdo con los privilegios del cargo
Validado
2 del usuario
Se muestra el mensaje "No tienes acceso a esta página" en pantalla si un
Validado
3 recurso solicitado no es accesible por el usuario
Se devuelve los recursos solicitados una vez validado sus privilegios de
Validado
4 usuario
Backlog
ID: 3 Habilitar el registro de un usuario
# Estado Resultados
Se observa en la pantalla de Dashboard notificaciones de usuarios que
Validado
1 solicitan registro
Se visualizan en el sistema, en el módulo de "Registros" una lista de
Validado
2 solicitudes de registro
Se tiene la posibilidad de rechazar solicitudes de registro en la opción
Validado
3 "Ver" de la lista de solicitudes de registro
Es posible aceptar solicitudes de registro a la aplicación en la opción
Validado
4 "Ver" de la lista de solicitudes de registro
Backlog
ID: 4 Gestionar usuarios registrados
# Estado Resultados
Se visualiza a todos los usuarios registrados en la aplicación en la pestaña
1 Validado
"Registrados" del módulo "Registros".
El rol "Gerente" puede expulsar un usuario ya registrado, en la pestaña
2 Validado
"Registrados" con el botón "Gestionar" del usuario requerido
Si se intenta eliminar a un usuario que este encargado de un almacén, el
sistema muestra el mensaje "Error. El usuario es encargado de (nombre
3 Validado
del almacén)".
"
El usuario que ha sido expulsado no tiene acceso al sistema, pero sus
4 Validado datos registrados en pedidos, traspasos, salidas e ingresos no son
borrados
Backlog
ID: 5 Inicio de sesión de un usuario
# Estado Resultados
El usuario recibe la notificación "Aún no se confirma su solicitud" al
1 Validado
iniciar sesión, si no se le ha habilitado la cuenta
El usuario recibe la notificación "Su solicitud fue rechazada" al iniciar
2 Validado
sesión, si se le ha rechazado su solicitud de registro
56
Un usuario registrado y aceptado en el sistema, puede ingresar con su
3 Validado
nombre y contraseña a la página principal del sistema
Al ingresar un usuario sus credenciales de manera incorrecta, se muestra
4 Validado
el mensaje "Usuario o contraseña incorrectos".
Backlog
ID: 6 Vistas alternativas
# Estado Resultados
Si el usuario no tiene acceso a una vista, se muestra otra vista con el
1 Validado mensaje "No tienes acceso a esta página", con un botón que redireccione
al Menú principal
Si el usuario accede a una vista inexistente, visualiza otra vista que le
2 Validado
informa "Página no encontrada" y que le redirecciona a Menú principal
Si el usuario accede a una vista sin haber iniciado sesión, es
3 Validado
redireccionado a la página de Inicio de sesión
Backlog
ID: 7 Implementar SideBar
# Estado Resultados
El SideBar es visible en todas las pantallas disponibles una vez iniciada
1 Validado
sesión
2 Validado El SideBar muestra una opción que redirige a la página de Dashboard
3 Validado El SideBar muestra una opción que redirige a la sección de Traspasos
4 Validado El SideBar muestra una opción que redirige a la sección de Ítems
El SideBar muestra una opción que redirige a la Almacenes y se visualiza
5 Validado
de acuerdo con el rol y privilegios
El SideBar muestra una opción que redirige a la sección de Registro si es
6 Validado
que corresponde a los privilegios del usuario
7 Validado El SideBar se contrae y expande con un botón
8 Validado Se muestra en el SideBar un botón para cerrar sesión.
3.2.2 Sprint 2: Gestión de Almacenes
3.2.2.1 Planeación

usuario” correspondientes del módulo de Autorización y Autenticación del Product
Backlog. A continuación, observamos la lista de actividades planificadas.
Tabla 8 Sprint 2 Backlog
SPRINT 2: Almacenes
57
2 11/04/22 22/04/22 96 12
SPRINT BACKLOG
8 Crear un Almacén Planificación Gerente
9 Mostrar pantalla de todos los almacenes Desarrollo Usuario
10 Mostrar pantalla de un solo almacén Desarrollo Usuario
11 Mostrar Nombre de usuario con sesión iniciada. Desarrollo Usuario
12 Agregar Encargado a un Almacén Desarrollo Usuario
13 Mostrar y Editar información de un Almacén Desarrollo Gerente
14 Eliminar un Almacén Desarrollo Gerente
Fuente: Elaboración Propia, 2022.
3.2.2.2 Desarrollo
El módulo es representado en el SideBar con una pestaña para “Almacenes”.
Figura 28 Opción almacenes en SideBar
58
La vista principal de este módulo enlista todos los almacenes registrados, con la
posibilidad de filtrar. Y, además, muestra una opción de crear uno nuevo.
Figura 29 Lista de almacenes
Al seleccionar un almacén se muestra otra pantalla con los ítems de ese almacén y un
detalle de estos.
Figura 30 Ítems en un almacén
Se pueden agregar nuevos ítems en este almacén con esta opción.
59
Figura 31 Agregar ítem en almacén
Se tiene la posibilidad de agregar movimientos de los ítems en almacén.
Figura 32 Agregar un movimiento de ítem en almacén
Y también de visualizar un historial de los movimientos antes realizados.
60
Figura 33 Visualizar movimientos de ítem en almacén
Podemos ver una pestaña de información sobre el almacén, con la posibilidad de editar
los datos actuales.
Figura 34 Información de un almacén
3.2.2.3 Resultados


Backlog
ID: 8 Crear un Almacén
61
# Estado Resultados
En el módulo de "Almacenes" se muestra un botón para añadir un nuevo
Validado
1 almacén
Para añadir un nuevo almacén, se muestra un formulario con los campos
Validado
2 Nombre, Encargado, Ciudad y Dirección para llenar los datos del almacén
Se registra el nuevo almacén al recibir el mensaje de confirmación "Se ha
Validado
3 registrado el almacén"
Se muestra el nuevo almacén en la lista de almacenes con los
Validado
4 respectivos datos registrados
Backlog
ID: 9 Mostrar pantalla de todos los almacenes
# Estado Resultados
1 Validado Se recuperan todos los almacenes registrados
Se muestra la etiqueta por color del departamento en que se encuentra
Validado
2 el almacén
3 Validado Se muestra la dirección del almacén en la tarjeta respectiva
Cada almacén es representado por una tarjeta con el nombre del
Validado
4 almacén como titulo
Se tiene una tarjeta con el símbolo "+" para poder añadir un nuevo
Validado
5 almacén
Se filtran los almacenes según el departamento seleccionado (Color
Validado
6 seleccionado)
Backlog
ID: 10 Mostrar pantalla de un solo almacén
# Estado Resultados
El sistema muestra en la parte superior un título con el nombre del
Validado
1 almacén
2 Validado El sistema muestra dos pestañas: Items e Información
3 Validado El sistema muestra la tabla de ítems en la pestaña de Items
El sistema muestra en la tabla de ítems del almacén, junto a los campos
Validado
4 de Tipo, Grupo, Código, Descripción y Cantidad
El sistema muestra opciones de agregado y retiro de cantidad de
Validado
5 producto al pulsar sobre uno de ellos
El sistema en la pestaña ítems muestra un botón "+ Agregar" para
Validado
6 agregar un nuevo ítem al almacén
El sistema en la pestaña ítems muestra un botón de "Quitar" en cada
Validado ítem, al pulsar muestra un mensaje de confirmación antes de realizar la
7 acción
El sistema recuperar los campos; Nombre, Encargado, Ciudad y Dirección
Validado
8 del almacén en la pestaña de "Información"
62
El sistema permite editar los campos Nombre, Encargado, Ciudad y
Validado
9 Dirección del almacén en la pestaña de "Información"
En la pestaña "Información" se muestra un botón "Guardar" para grabar
Validado los cambios realizados, que al pulsar muestra el mensaje "Se ha editado
10 el almacén"
En la pestaña "Información" se muestra el botón "Eliminar Almacén",
Validado que al pulsar muestra un mensaje de confirmación para eliminar el
11 almacén
Backlog
ID: 11 Mostrar Nombre de usuario que ha iniciado sesión
# Estado Resultados
En la parte inferior del SideBar se muestra el nombre junto al rol del
Validado
1 usuario activo
El sistema muestra encima del botón "Cerrar sesión" el nombre del
Validado
2 usuario
Backlog
ID: 12 Agregar Encargado a un Almacén
# Estado Resultados
En la pestaña "Información" se tiene el campo "Encargado" con un
Validado
1 selector que contiene a todos los usuarios registrados
En la pestaña "Información" se muestra el campo "Encargado" con la
Validado
2 información previa
3 Validado El sistema muestra un botón de "Guardar" al editar el encargado
Se muestra un mensaje de confirmación de guardado "Se ha editado el
Validado
4 almacén"
Backlog
ID: 13 Mostrar y Editar información de un Almacén
# Estado Resultados
En la pestaña "Información" se muestran los campos Nombre,
Validado
1 Encargado, Ciudad y Dirección con la información previa
El sistema recupera los campos de información del almacén actuales en
Validado
2 la sección de "Información" de Almacenes
En la pestaña "Información" se muestra el botón "Guardar" para
Validado
3 confirmación de edición
El sistema muestra el mensaje "Se ha editado el almacén" de
Validado
4 confirmación al realizar un cambio en los campos anteriores
Backlog
ID: 14 Eliminar un Almacén
# Estado Resultados
63
Validado En la pestaña "Información" se muestra un botón "Eliminar Almacén"
1 Validado El sistema muestra el botón al final de la sección de "Información"
El sistema muestra un cuadro de confirmación con la posibilidad de
Validado
2 confirmar la eliminación o cancelarla
El sistema muestra el mensaje "Se ha eliminado el almacén"
Validado
3 confirmando la correcta eliminación del almacén
3.2.3 Sprint 3: Gestión de Ítems: Registro
3.2.3.1 Planeación

usuario” correspondientes del módulo de Autorización y Autenticación del
Product Backlog. A continuación, observamos la lista de actividades
planificadas.
Tabla 10 Sprint Backlog Sprint 3
SPRINT 3
3 25/04/22 07/05/22 104 13
SPRINT BACKLOG
15 Crear productos Planificación Gerente
16 Añadir productos a un almacén Desarrollo Almacenero
17 Mostrar pantalla con todos los productos creados Desarrollo Usuario
3.2.3.2 Desarrollo
Primero se puede observar la opción del módulo de “Ítems” en el SideBar.
64
Figura 35 Opción de ítems en SideBar
Se observa la pantalla principal del registro de ítems de la empresa, donde se tienen 5

tipos de activos.
Figura 36 Tipos de ítems que maneja la empresa
Por cada tipo de ítem se muestra una tabla de registros con datos críticos de cada ítem,
con la posibilidad, además, de descargar la tabla.
65
Figura 37 Tabla de registros de ítems
3.2.3.3 Resultados


Backlog
ID: 15 Crear productos
# Estado Resultados
En el módulo de "Ítems" se muestra el botón verde "+ Agregar" para
1 Validado
crear un nuevo producto
El sistema muestra un formulario respectivo a cada tipo de ítem, al
2 Validado
presionar el botón verde "+ Agregar"
El sistema confirma el nuevo producto registrado mostrando el mensaje
3 Validado
"Se ha registrado la (tipo de producto)"
El sistema muestra el nuevo producto disponible en la tabla de "Ítems",
4 Validado
para agregar en un almacén
Backlog
ID: 16 Añadir productos a un almacén
# Estado Resultados
El sistema muestra un botón con label "+ Agregar" en la vista de un
1 Validado
almacén
Al presionar el botón "+ Agregar" del módulo de almacenes en vista
2 Validado individual, despliega un modal con la opción de seleccionar un Ítem de la
lista disponible
El sistema muestra un campo de selección donde se muestren como
3 Validado
opciones todos los ítems aún no agregados en ese almacén
4 Validado El sistema muestra un botón con label "Agregar" al final del modal
El sistema agrega el ítem al presionar el botón con el mensaje de
5 Validado confirmación "Se ha registrado el ítem en almacén
"
66
Backlog
ID: 17 Mostrar pantalla con todos los productos creados
Estado Resultados
El sistema muestra una tabla con cada ítem en las filas y con las
1 Validado
propiedades del ítem en las columnas
El sistema muestra un botón de descarga en el lateral de la tabla "Items"
2 Validado
de cada Almacén.
El sistema tiene opciones de filtrado y búsqueda en las tablas para
3 Validado
aumentar su productividad
3.2.4 Sprint 4: Gestión de ítems: Ingresos y salidas en Almacenes
3.2.4.1 Planeación

SPRINT 4: Ítems
4 09/05/22 20/05/22 88 11
SPRINT BACKLOG
18 Quitar material de un almacén Desarrollo Almacenero
19 Agregar o Quitar ítems registrados Desarrollo Almacenero
20 Mostrar flujo de operaciones de un ítem Desarrollo Usuario
21 Mostrar actividad reciente Desarrollo Usuario
3.2.4.2 Desarrollo
Primero se implementa la opción de eliminar un ítem registrado en un almacén.
67
Figura 38 Opción de quitar ítem de un almacén
Por cada tipo de ítem se tiene la posibilidad de ingresar un nuevo registro de ítem.
Figura 39 Formulario de nueva maquinaria pesada
68
Figura 40 Formulario de nueva maquinaria estacionaria
Figura 41 Formulario de nuevo Automóvil
69
Figura 42 Formulario de nuevo Material / Herramienta
Figura 43 Formulario de nuevo Suministro
70
3.2.4.3 Resultados


Backlog
ID: 18 Quitar material de un almacén
Estado Resultados
En la tabla de "Items" de cada almacén individual, se muestra un botón
1 Validado
con label "Quitar" al final de la fila de cada Ítem
El sistema muestra un mensaje de confirmación para retira el ítem al
2 Validado
pulsar el botón rojo "Quitar"
El sistema muestra el mensaje de confirmación "Se ha eliminado el
3 Validado
ítem" al retirar un ítem
Backlog
ID: 19 Agregar o Quitar ítems registrados
Estado Resultados
El sistema permite pulsar en cualquier Ítem, que no sea Maquina o
1 Validado
automóvil, de la tabla de "Items" de cada almacén individual.
El sistema despliega un modal al pulsar en una fila de la tabla de "Items"
2 Validado
de cada almacén individual
El sistema muestra un campo de entrada para determinar la cantidad de
3 Validado
acuerdo con la operación seleccionada (Agregar - Retirar) en el modal
En el modal se muestra un seleccionador para elegir la opción de
4 Validado
"Agregar “o "Retirar" cantidad
El sistema muestra el campo de entrada "Motivo" para determinar la
5 Validado
razón de la operación en el modal, siendo obligatoria solo para el retiro.
El sistema muestra el mensaje de confirmación "Se ha registrado el ítem
6 Validado
en almacén" al presionar el botón "Agregar" del modal.
El sistema muestra un botón verde "Agregar" de confirmación al final del
7 Validado
modal.
Backlog
ID: 20 Mostrar flujo de operaciones de un ítem
# Estado Resultados
En la tabla de "Items" de cada almacén individual, se muestra un botón
1 Validado
naranja con label "Flujo" al final de la fila de cada Ítem
2 Validado El sistema despliega un modal al pulsar en el botón anterior.
El sistema muestra un detalle de cada operación hecha en el ítem, con
3 Validado
datos del usuario que la hizo, fecha, cantidad y operación.
71
4 Validado El sistema ordena la lista de flujos, del más reciente al más antiguo.
3.2.5 Sprint 5: Gestión de Transferencias de ítems
3.2.5.1 Planeación

SPRINT 5: Traspasos
5 23/05/22 03/06/22 96 12
SPRINT 4: Autenticación y Autorización
22 Crear solicitud traspaso Desarrollo Usuario
23 Vista solicitudes pendientes Desarrollo Usuario
23 Implementar Hoja de ruta Desarrollo Usuario
25 Aceptar traspaso de material a una sucursal Desarrollo Gerente
26 Aceptar envío de material a una sucursal Desarrollo Almacenero
27 Confirmar llegada de material a una sucursal Desarrollo Almacenero
28 Vista Traspasos Desarrollo Usuario
29 Hoja de ruta finalizada Desarrollo Gerente
3.2.5.2 Desarrollo
Primero se puede observar la opción del módulo de “Traspasos” en el SideBar.
72
Figura 44 Opción de Traspasos en SideBar
Se muestra una pantalla principal con el registro de todos los traspasos completados o
cancelados.
Figura 45 Lista de traspasos completados o cancelados
Es posible crear una solicitud de traspaso mediante esta línea de proceso con 4 pasos.
73
Figura 46 Línea de procesos para solicitar traspasos
Es posible ver los detalles de una solicitud como la fase en la que se encuentra y los
ítems enlistados en el proceso, además, se muestran opciones para aceptar y rechazar la
misma.
Figura 47 Solicitud de un traspaso
Una vez completado o cancelado el traspaso se pueden ver todos los detalles del proceso
como fases, involucrados, fechas e ítems.
74
Figura 48 Hoja de ruta de traspaso
3.2.5.3 Resultados


Backlog
ID: 21 Crear solicitud traspaso
# Estado Resultados
El sistema muestra una pestaña de "Solicitar Traspaso" en el módulo de
1 Validado
"Traspasos"
El sistema muestra un stepper al lado izquierdo que despliega pasos para
2 Validado
completar la solicitud
El primer paso para la solicitud muestra un desplegable "Solicitante" con
3 Validado todos los almacenes, y un botón "Siguiente" para confirmar el destino del
traspaso.
El segundo paso para la solicitud muestra un desplegable "Items" con
4 Validado
todos los ítems, y un botón "Siguiente" para confirmar el Ítem a traspasar.
El tercer paso para la solicitud muestra la cantidad del ítem seleccionado
5 Validado en cada almacén y nos permite seleccionar el almacén que realizara el
traspaso. Conjunto a un botón "Siguiente" para confirmar el almacén.
El cuarto paso para la solicitud muestra un campo de texto numérico con
6 Validado
el label "Enviar (nombre del ítem) desde (nombre almacén)"
El cuarto paso contiene un botón con el label "Solicitar", al pulsar se
7 Validado
muestra un detalle del ítem, cantidad y origen.
75
Debajo del detalle de ítems a traspasar, se debe mostrar un botón con el
8 Validado
label "Enviar Solicitud".
Al presionar el botón "Enviar Solicitud" se confirma la solicitud y se
9 Validado
muestra el mensaje "La transferencia está en progreso" en pantalla.
Backlog
Vista solicitudes pendientes
ID: 22
# Estado Resultados
El sistema muestra una pestaña de "Solicitudes pendientes" en el módulo
1 Validado
de "Traspasos"
El sistema muestra dentro la pestaña "Solicitudes Pendientes" una lista
2 Validado
con las solicitudes pendientes en cada fila
El sistema muestra en cada fila la fecha y hora en la que se realizó la
3 Validado
solicitud con el destino del traspaso
El sistema muestra al final de cada registro de traspaso un botón con el
4 Validado
label "Ruta"
Al pulsar al botón anterior, el sistema redirige la vista a la Hoja de Ruta
5 Validado
con el id de traspaso seleccionado
Backlog
Implementar Hoja de ruta
ID: 23
# Estado Resultados
El sistema muestra una barra de progreso al lado izquierdo de la pantalla,
1 Validado
llenando el progreso hasta el paso en el que se encuentra el traspaso.
El sistema muestra el paso siguiente y el paso completado debajo de la
2 Validado
barra anterior
El sistema muestra un call to action para confirmar el paso actual y seguir
3 Validado
con el siguiente.
El sistema muestra el detalle de todos los ítems del traspaso al lado
4 Validado
derecho de la pantalla.
Backlog
Aceptar traspaso de material a una sucursal
ID: 24
# Estado Resultados
El sistema en la pestaña "Solicitudes Pendientes" muestra al pulsar en el
1 Validado botón "Ruta" de un traspaso, la hoja de ruta un call to action, para
confirmar el paso de "Confirmar Autorización de envío".
El sistema muestra un texto "Central acepta el traspaso del detalle de
2 Validado material a destino." describiendo que se está aceptando todos los ítems,
orígenes y destino del traspaso
3 Validado El sistema muestra un botón verde "Aceptar" y otro rojo "Rechazar"
El sistema muestra el mensaje de confirmación "La transferencia está en
4 Validado
progreso" si se presiona el botón de confirmación.
76
El sistema muestra un modal con un campo de entrada texto "Razón de
5 Validado Cancelación" que requiera una razón si es que se presiona el botón de
cancelación.
Backlog
Aceptar envío de material a una sucursal
ID: 25
# Estado Resultados
1 Validado botón "Ruta" de un traspaso, la hoja de ruta con un call to action, para
confirmar el paso de "Confirmar Envío".
El sistema muestra un texto "(Almacén) confirma la salida del material
2 Validado descrito. “anunciando que se está confirmando el envío todos los ítems
especificados del traspaso
El sistema muestra el mensaje de confirmación "La transferencia está en
4 Validado
progreso" si se presiona el botón de confirmación.
El sistema muestra un modal con un campo de entrada texto "Razón de
5 Validado Cancelación" que requiera una razón si es que se presiona el botón de
cancelación.
Backlog
Confirmar llegada de material a una sucursal
ID: 26
# Estado Resultados
1 Validado botón "Ruta" de un traspaso, la hoja de ruta con un call to action, para
confirmar el paso de "Confirmar Llegada".
El sistema muestra un texto describiendo que se está recibiendo todos los
2 Validado
ítems especificados del traspaso
El sistema muestra el mensaje de confirmación "Se ha completado el
4 Validado
Traspaso" si se presiona el botón de confirmación.
El sistema muestra un modal con un campo de entrada texto que
5 Validado
requiera una razón si es que se presiona el botón de cancelación.
Backlog
Vista Traspasos
ID: 27
# Estado Resultados
El sistema muestra una pestaña de "Traspasos" en el módulo de
1 Validado
Traspasos
El sistema en la pestaña "Traspasos" muestra una lista con todos los
2 Validado
traspasos completados y cancelados.
3 Validado El sistema muestra en cada fila la fecha, hora y el destino del traspaso
77
El sistema muestra al final de cada registro de traspaso un botón con el
4 Validado label "Ver" o "Cancelado", dependiendo si este fue completado o
cancelado en algun punto de la ruta.
Al pulsar al botón "Ver" o "Cancelado" de un traspaso de la lista de
5 Validado "Traspasos", el sistema redirige a la vista a la Hoja de Ruta con el id de
traspaso seleccionado.
Backlog
Hoja de ruta finalizada
ID: 28
# Estado Resultados
El sistema muestra una barra de progreso en la parte superior, llenando el
1 Validado
progreso hasta el paso en el que se finalizó el traspaso.
2 Validado El sistema muestra con símbolos "X" y "✓" respectivamente
El sistema muestra un registro de firmante (Usuario que autorizo o
3 Validado
confirmo el paso) y fecha en cada paso transcurrido.
El sistema muestra el detalle de todos los ítems del traspaso al lado
4 Validado
derecho de la pantalla.
3.2.6 Sprint 6: Gestión de pedidos de ítems a proveedor
3.2.6.1 Planeación

SPRINT 6: Pedidos
5 01/08/22 12/08/22 96 12
SPRINT BACKLOG
30 Pestaña pedidos en SideBar Desarrollo Usuario
31 Realizar pedidos Desarrollo Usuario
32 Lista de pedidos realizados Desarrollo Usuario
33 Lista de pedidos pendientes Desarrollo Gerente
34 Detalles de un pedido Desarrollo Usuario
35 Descargar pedido Desarrollo Usuario
36 Comprar ítems Desarrollo Almacenero
37 Aceptar o rechazar Pedido Desarrollo Gerente
78
3.2.6.2 Desarrollo
Primero se puede observar la opción del módulo de “Pedidos” en el SideBar.
Figura 49 Opción de Pedidos de SideBar
Se observa en la vista principal una lista de pedidos, con la posibilidad de filtrar de

acuerdo con el estado del pedido.
79
Figura 50 Lista principal de pedidos
Es posible, también, agregar un pedido nuevo con el siguiente formulario.
Figura 51 Formulario de agregar solicitud de pedido
Un encargado puede observar las solicitudes pendientes por aprobar.
80
Figura 52 Lista de pedidos pendientes
También el encargado es quien puede aceptar o rechazar el pedido de la siguiente

manera.
Figura 53 Solicitud de pedido
Una vez aceptado el pedido se puede visualizar un detalle con los datos del pedido.
81
Figura 54 Detalle de pedido aceptado
Un almacenero puede marcar la compra de un pedido, llenando datos de la compra y

modificando cantidades y precios de acuerdo con los datos reales.
Figura 55 Formulario para completar compra de pedido
Finalmente se puede ver los detalles de un pedido ya comprado.
82
Figura 56 Detalle de pedido comprado
3.2.6.3 Resultados


Backlog
ID: 29 Pestaña pedidos en SideBar
# Estado Resultados
El sistema muestra el nuevo módulo "Pedidos" de redirección en el
1 Validado
SideBar
Al presionar el enlace anterior se redirecciona a una nueva pantalla con
2 Validado
título "Pedidos"
En la nueva pantalla el sistema muestra un título, un divider, subpestañas
3 Validado
y contenido dinámico en cada pestaña
Backlog
ID: 30 Realizar pedidos
# Estado Resultados
El sistema muestra un botón de "+ Agregar" en la pestaña de "Lista de
1 Validado
Pedidos" del módulo "Pedidos"
83
Al presionar se obtiene un formulario para poner el nombre del almacén
2 Validado
solicitante y el proveedor opcionalmente.
Se puede añadir N ítems de la base de datos en la solicitud con sus
3 Validado respectivas cantidades y este se encarga de multiplicar esa cantidad con el
precio del ítem respectivo
Se muestra el mensaje "La orden está en progreso." de confirmación al
4 Validado
realizar el pedido
5 Validado Al presionar se redirecciona a la pestaña de "Lista de Pedidos"
Backlog
ID: 31 Lista de pedidos realizados
# Estado Resultados
El sistema muestra una subsección en la página principal de pedidos que
1 Validado
se llame "Lista de Pedidos"
En esta subsección se muestra una lista de todos los pedidos aprobados,
2 Validado
comprados y rechazados
La lista de pedidos muestra, por cada pedido su respectivo # de pedido, la
3 Validado
fecha de aceptación o rechazo y un respectivo botón.
Al final de cada línea de un pedido se tiene; un botón azul "Para Comprar"
si el pedido fue aprobado, o un botón naranja "Comprado" si ya fue
4 Validado
completada la compra, o un botón rojo "Rechazado" si fue un pedido
rechazado, para ver los detalles del pedido.
Backlog
ID: 32 Lista de pedidos pendientes
# Estado Resultados
El sistema muestra una subsección en la página principal de pedidos que
1 Validado
se llame "Pedidos por aprobar" en el módulo de "Pedidos"
2 Validado En esta subsección se muestra toda la lista de pedidos por aprobar
La lista de pedidos muestra, por cada pedido, el número de pedido, la
3 Validado
fecha de aceptación o rechazo y un botón azul "Ver" para ver los detalles.
Backlog
ID: 33 Detalles de un pedido
# Estado Resultados
Los detalles de un pedido se muestran en una pantalla diferente dentro
1 Validado
del módulo de "Pedidos".
Esta pantalla tiene por título "Pedidos > Pedido #num" con el número del
2 Validado
pedido respectivo.
Se muestra datos generales del pedido: Proveedor, Fecha de Pedido y
3 Validado
almacén de destino.
Debajo se muestra una lista de ítems a comprar con los datos: Código,
4 Validado
Descripción del Ítem, Cantidad, Precio (Bs) y Total (Bs).
84
Debajo de la lista anterior se muestra a la derecha el total final, al sumar
5 Validado
los totales de cada ítem
Al final de esta pantalla se muestra una etiqueta de color verde con un
6 Validado label que indica quién autoriza el pedido y en qué fecha o una etiqueta
roja si ha sido rechazado
Backlog
ID: 34 Descargar pedido
# Estado Resultados
El sistema muestra un botón debajo la lista del pedido, para descargar al
1 Validado
momento de ver el detalle de un pedido previamente aprobado.
2 Validado El nombre del archivo PDF descargado es el número del pedido
Backlog
ID: 35 Comprar ítems del pedido
# Estado Resultados
Al final de la vista de detalle de un pedido se visualiza una casilla de
1 Validado
verificación con el label "Marcar compra de pedido"
Al marcar la casilla, se muestra una ventana para modificar las cantidades
2 Validado o precios de los productos de acuerdo con la compra realizada y
obligatoriamente adicionar el proveedor si no se tiene uno registrado.
3 Validado Se marca la compra como "comprada" y pasa a la sección de compras
Backlog
ID: 36 Aceptar o rechazar Pedido
# Estado Resultados
Al presionar el botón azul de "Ver" en la lista de la pestaña "Pedidos por
1 Validado
aprobar", se redirecciona a una pantalla nueva
Se muestra datos generales del pedido: Proveedor, Fecha de Pedido y
2 Validado almacén de destino. Debajo se muestra una lista de ítems a comprar con
los datos: Código, Descripción del Ítem, Cantidad, Precio (Bs) y Total (Bs).
Debajo de esta información se muestra un botón verde "Autorizar" que al
3 Validado presionar pasa el pedido a un estado de Para comprar, mostrando el
mensaje de confirmación "Se ha actualizado la orden".
Al lado izquierdo se muestra un botón rojo "Rechazar" que al presionar
4 Validado pasa el pedido a un estado de rechazado, mostrando el mensaje de
confirmación "Se ha actualizado la orden".
3.2.7 Sprint 7: Visualización de Datos y Responsividad
3.2.7.1 Planeación
85
SPRINT 7: Visualización de Datos y Responsividad

7 15/08/22 26/08/22 112 14
SPRINT BACKLOG
Usuari
38 Tablas Adaptativas Desarrollo
o
Usuari
39 Formularios Adaptativos Desarrollo
o
Usuari
40 Listas Adaptativas Desarrollo
o
Usuari
41 SideBar Adaptativo Desarrollo
o
Usuari
42 Pestaña Dashboard Desarrollo
o
Usuari
43 Alertas de solicitudes Desarrollo
o
Usuari
44 Gráfico para ver la rotación de inventario Desarrollo
o
3.2.7.2 Desarrollo
Primero se puede observar la opción del módulo de “Dashboard” en el SideBar.
Figura 57 Opción de Dashboard en SideBar
86
Se observa la sección de alertas, donde se observan alertas de solicitudes pendientes en

cada módulo.
Figura 58 Lista de alertas de solicitudes pendientes
La siguiente sección es de métricas, donde se puede visualizar la rotación de inventario,

ósea, la cantidad de salidas contra la cantidad de entradas de un ítem en almacén.
87
Figura 59 Visualización de métrica de rotación de inventario
3.2.7.3 Resultados

Tabla 19 Criterios cumplidos en el sprint 7

Backlog
ID: 38 Tablas Adaptativas
# Estado Resultados
El sistema adapta las dimensiones de la tabla de acuerdo con el ancho
1 Validado
de la pantalla.
2 Validado El sistema conserva el ancho de preestablecido para cada columna.
El sistema permite deslizar horizontalmente las columnas que quedan
3 Validado
ocultas al comprimir el ancho de una tabla.
El sistema conserva las funcionalidades de: presionar en una fila para
4 Validado
ver detalles, mientras cambia el ancho de pantalla.
El sistema mantiene la funcionalidad de: descargar tabla Excel, mientras
5 Validado
cambia el ancho de pantalla.
Backlog
ID: 39 Formularios Adaptativos
88
# Estado Resultados
El sistema adapta las dimensiones del formulario de acuerdo con el
1 Validado
ancho de la pantalla
El sistema conserva el ancho de preestablecido para cada campo de
2 Validado
texto o seleccionable.
El sistema desplaza los labels de cada campo por encima, ocupando una
3 Validado
línea.
El sistema permite desplazar verticalmente un formulario si se han
4 Validado
sobrepasado las dimensiones por la redistribución de los elementos.
El sistema permite cerrar el formulario o confirmarlo al modificar el
5 Validado
ancho de la pantalla.
Backlog
ID: 40 Listas Adaptativas
# Estado Resultados
El sistema adapta las dimensiones de la lista de acuerdo con el ancho de
1 Validado
la pantalla sin llegar a sobreponer el contenido
2 Validado El sistema conserva el ancho de preestablecido para cada columna.
El sistema permite deslizar horizontalmente la lista para visualizar todas
3 Validado
las columnas.
El sistema mantiene la disposición de los botones en cada fila al
4 Validado
modificar el ancho de la pantalla.
Backlog
ID: 41 SideBar Adaptativo
# Estado Resultados
1 Validado El sistema colapsa el SideBar cuando la pantalla es de celular
El sistema conserva sólo los íconos de cada opción de menú al colapsar
2 Validado
el SideBar.
3 Validado El sistema permite des colapsar y colapsar el SideBar
El sistema conserva la disposición del contenido de la vista al colapsar y
4 Validado
des colapsar el SideBar.
Backlog
ID: 42 Pestaña Dashboard
# Estado Resultados
1 Validado El sistema muestra una opción en el SideBar con label "Dashboard"
2 Validado El sistema especifica una ruta nueva para la vista.
El sistema muestra una vista con el título de Alertas al presionar la
3 Validado
opción de "Dashboard" en el SideBar
Backlog
ID: 43 Alertas de solicitudes
89
# Estado Resultados
El sistema muestra en la vista de "Dashboard" una sección para
1 Validado
"Alertas"
El sistema muestra cuatro Card por cada tipo de alerta: Usuario nuevo,
2 Validado
pedido nuevo, transferencia nueva y mantenimiento.
3 Validado El sistema muestra en cada Card el número de solicitudes pendientes.
El sistema muestra en cada Card un ícono y color distintivo del tipo de
4 Validado
alerta.
El sistema muestra en cada Card en la fecha de la solicitud más antigua
5 Validado
pendiente.
Backlog
ID: 44 Gráfico para ver la rotación de inventario
# Estado Resultados
El sistema muestra en la vista de "Dashboard" una sección para
1 Validado
"Métricas"
El sistema muestra un Card con el título "Ingresos y Salidas por
2 Validado
Almacén"
El sistema muestra dentro del Card un seleccionador con los todos los
3 Validado
almacenes a elegir.
El sistema muestra un gráfico de barras dobles (uno para salidas y otro
4 Validado
para ingresos) con los ítems en el eje x y cantidades en el eje y.
3.2.8 Sprint 8: Mantenimiento de equipos pesados
3.2.8.1 Planeación

SPRINT 8: Mantenimiento de equipos pesados

8 29/09/22 09/09/22 112 14
SPRINT BACKLOG
45 Pestaña pedidos en SideBar Desarrollo Usuario
46 Solicitar mantenimiento Desarrollo Usuario
47 Kardex de Mantenimientos Desarrollo Usuario
90
48 Lista de Mantenimientos pendientes Desarrollo Gerente
49 Detalles de un Mantenimiento Desarrollo Usuario
50 Descargar Mantenimientos Desarrollo Usuario
51 Terminar Mantenimiento Desarrollo Almacenero
52 Aceptar o rechazar Mantenimiento Desarrollo Gerente
3.2.8.2 Desarrollo
3.2.8.3 Resultados

3.3 Seguridad
La aplicación web entregada, así como cualquier sistema de información, necesita

asegurar la seguridad informática. La seguridad de un sistema informático es una tarea
crucial que debe ser una prioridad en cualquier desarrollo de software para mantener
todas las amenazas u otras tareas maliciosas, o ataques, o programas, alejados del
sistema de software.
En este proceso necesitamos asegurar la confidencialidad, integridad y autenticación de

la información que maneja el sistema, y para ello, hemos implementado los diferentes
controles, ya sean de seguridad de la información como de acceso al sistema.
3.3.1 Controles de seguridad de información
3.3.1.1 JWT
Dentro de nuestra aplicación tenemos cierta información sensible que viaja por la red
desde nuestro usuario hasta la base de datos del sistema, durante la interacción con el
sistema, el usuario en todo momento debe enviar un identificador que no solo le permita
91
acceder a los datos, sino que también ayude al sistema a devolver la información
pertinente a tal usuario.
La tecnología JWT es un estándar, que define una forma compacta y autónoma de

transmitir información de forma segura entre las partes usando un objeto en formato
JSON. Esta información se puede verificar y confiar porque está firmada digitalmente.
El sistema, en su capa de extracción y procesamiento de datos, genera este token al

iniciar la sesión de un usuario. Dentro, el token tiene el id del usuario encriptado y
firmado con una clave secreta inaccesible. Con este token el usuario puede acceder no
solo a la interfaz de usuario sino también obtener e interactuar con la información a la
que tenga acceso. En la siguiente figura se describe el proceso anterior.
Figura 60 Proceso de uso de JWT
Fuente: (AG, 2022)
Si bien este token está encriptado, la accesibilidad a este da la posibilidad de probar

medios para vulnerarlo y extraer la información de este. Por ello es por lo que se
considera correcto hacer este token un elemento con el que el usuario ejecuta sus
funciones en el sistema y al mismo tiempo no tiene acceso al mismo.
3.3.1.2 Protección de datos en BD
92
Si bien la información del usuario es protegida en los medios de comunicación con el
usuario, también es necesario valorar la seguridad de la información en su destino final
de almacenaje, es decir, la Base de Datos.
Como se describe anteriormente, el sistema usa una BD PostgreSQL, esta se ha

convertido en una elección muy común en aplicaciones web y en parte es por el nivel de
seguridad de los datos que ofrece.
La seguridad de una BD PostgreSQL se basa en tres pilares;
● Seguridad a nivel de red, incluido el uso de sockets de dominio Unix, sockets

TCP/IP y firewalls.
● Seguridad a nivel de transporte que permite una comunicación segura con la base de
datos mediante SSL/TLS.
● Funciones de seguridad a nivel de base de datos, como roles y permisos, seguridad a

nivel de fila (RLS) y auditoría.
Todas estas implementaciones de seguridad se aseguran cuando la BD es alojada en un

servicio de “cloud computing”. El servicio contratado de acuerdo con un plan nos ofrece
limitaciones de recursos de memoria o lecturas simultaneas en BD, pero las condiciones
de seguridad son siempre estándar.
Por nuestra parte, unicamente nos corresponde manejar de manera confidencial las
credenciales de acceso a la BD que nos brinda el proveedor. Para ello dentro de la
implementación de nuestra API, que es la que va a conectar con la BD, se hizo
unicamente referencias a nombres clave, tanto de usuarios o contraseñas, ubicando los
valores reales de las credenciales en un archivo único e inaccesible de entorno.
De esta manera la información almacenada en nuestra base de datos está protegida en

niveles de red por la infraestructura remota contratada, a nivel de transporte por los
protocolos propios de la tecnología PostgreSQL y a nivel de acceso ocultando las
credenciales únicas de cualquier externo.
3.3.1.3 Persistencia de la información
Otro elemento de seguridad de la información desde un punto de vista de control y

supervisión por auditorias es la persistencia de la información, esto hace referencia al
continuo almacenamiento de la actividad de los usuarios sin eliminar ningún registro.
El uso cotidiano del sistema por el usuario significa la creación, visualización,

modificación y eliminación de datos que maneja el sistema, y en ciertos casos, le es de
93
utilidad al usuario desechar aquella información que no le hace falta para continuar de
mejor manera sus funciones, pero estos datos no útiles para el usuario si lo son para la
empresa, al momento de auditar operaciones, generar reportes o un análisis de los datos,
y para ello se necesita toda la actividad registrada por el sistema.
Por ello, en el sistema, si bien existen interfaces que dicen eliminar o quitar registros,
realmente se maneja una política de persistencia de los datos. Aquellos registros ya no
requeridos por el usuario pasan a un estado de inactivos, donde ya no podrán interactuar
con el usuario, pero el registro de este permanecerá en la BD.
3.3.2 Control de información sensible
3.3.2.1 Contraseña Confidencial
En el módulo de autenticación y autorización del sistema requerimos que el usuario

defina una contraseña que le da el acceso al sistema desde una cuenta personal. Esta
contraseña le asegura que ningún externo pueda interactuar en el sistema usando su
nombre.
Esta contraseña por lo tanto debe ser confidencial incluso dentro del sistema y de la BD,
por ello es por lo que esta es una información crítica que se decidió hacer esta cadena de
texto una cadena Hash, la cual se usa principalmente para validar la integridad de los
datos sin acceder a la información original.
Figura 61 Proceso Hash
Fuente: IPCisco, 2022.
Para el proceso de validación de una contraseña, se compara el texto Hash de la

contraseña proporcionada con la que se tiene registrada. Por ello, no es necesario ni
almacenar, ni realizar ninguna operación con la contraseña original del usuario, de esta
manera se conserva confidencial esta información sensible.
94
3.3.2.2 Encriptación de JWT en el navegador
Como se comentó en una sección anterior, el JWT es inaccesible por el usuario durante
la interacción el sistema, sin embargo, cuando el usuario reinicia la sesión del navegador
por cualquier razón, el sitio web pierde los datos de la anterior sesión, incluido el token,
requiriendo nuevamente inicio de sesión, perdiendo así tiempo y esfuerzos. En este caso,
comúnmente, se usa un almacenamiento interno del navegador, el “session storage”,
donde el token se guarda y permanece al reinicio de la ventana en un navegador, dejando
una vez más expuesto el token ya que esta memoria es accesible por el usuario.
En el sistema se implementa entonces una capa de encriptación extra sobre el token

antes de almacenarlo en el “session storage”, en este caso se usa la especificación AES
(Advanced Ecryption Standard), la cual requiere una clave secreta que es inaccesible por
el usuario. De esta manera el token queda oculto cuando queda expuesto en el “session
storage”.
3.3.2.3 Encriptación de Id en la URL
La interfaz de usuario del sistema muestra diferentes vistas de acuerdo con la dirección
lógica o URL de la aplicación en la red, y dentro del URL, después del nombre del
dominio, se tiene el path o dirección hacia un recurso de nuestra API, adicionalmente
podemos especificar parametros que requiera el servicio en particular.
Figura 62 Partes de una URL
Fuente: Learn Microsoft, 2022.
Un parámetro esta siempre presente en muchos recursos de nuestra API, el ID, gracias a
este identificador es posible servir un recurso específico, ya que cada registro en base de
datos tiene este identificador único. Sin embargo, este identificador puede ayudar a
usuarios maliciosos a realizar diferentes ataques a nuestra aplicación, por lo que no
puede dejarse expuesto.
En el sistema se implementa una encriptación a este identificador al momento de

exponerlo en la URL del navegador, se usa la encriptación AES, la cual requiere una
llave para firmar, una llave que es aislada en un archivo inaccesible, por lo que se logra
mantener esta información sensible confidencial.
95
Figura 63 Encriptación de Id en URL
96
CONCLUSIONES
En el presente proyecto se propuso la implementación de un sistema web adaptativo para

la gestión de inventarios de la empresa Estrutec SRL. Este objetivo se llevó a cabo
mediante una metodología SCRUM adaptada y aplicada por ocho Sprints de dos
semanas cada una aproximadamente. Durante este proceso se siguieron etapas de diseño,
validación, codificación, presentación y validación, para cada funcionalidad requerida
por el gerente general de Estrutec SRL. Al término de la totalidad del sistema se
concluye lo siguiente.
● El sistema permite centralizar los agentes involucrados en los procesos de

almacenes en una misma plataforma, de acuerdo con sus roles, el sistema les
permite desempeñar sus funciones desde cualquier dispositivo con internet.
● Toda la información generada en los procesos de almacenes ahora se almacena de
manera automática, en un mismo sitio, siendo accesible en cualquier momento,
permitiendo a los cargos de control y supervisión estar al tanto en tiempo real de los
procesos de almacenes.
● El sistema ofrece a la empresa la posibilidad de manejar de manera más simple toda
la información de los activos de la empresa, datos del estado, ubicación, cantidad y
movimientos en almacenes, le proporcionan a la empresa certeza y claridad sobre la
gestión de sus activos, mejorando laos métodos anteriores y reduciendo riesgo de
pérdidas y malentendidos con los empleados.
● Procesos antes tan complejos como el traspaso de material entre sucursales o
pedidos de materiales a un proveedor ahora se controlan de manera online, se
registran a los involucrados, se tienen todos los registros con fechas y cantidades
exactas, mejorando no solo la logística sino el tiempo de ejecución de los procesos.
● Se mejora un proceso antes muy complejo para la empresa, el mantenimiento de
maquinarias, ahora no se tiene incertidumbre de los equipos que se encuentran en
mantenimiento, ni se pasan por alto las fechas establecidas en manuales, ni se
pierden facturas o comprobantes, ahora se tiene un proceso bien documentado y
automatizado.
● El aprovechamiento de la centralización y recolección de datos del sistema junto al
procesamiento de datos dan una ventaja a los agentes de control de la empresa.
Ahora se cuenta con alertas de solicitudes pendientes y visualización de métricas
que miden el rendimiento del almacén.
97
RECOMENDACIONES
- Estar familiarizado con las tecnologías es un factor importante al momento de

elegirlas, un sistema tan grande y complejo no deja lugar a errores de un equipo
poco experimentado.
- La arquitectura de microservicios es recomendable para sistemas grandes,
aunque no siempre se puedan abstraer módulos completamente independientes,
separar la lógica y el código junto a patrones de diseño hacen más simple y
escalable el sistema.
- Es necesario adaptar las metodologías de trabajo adoptadas al equipo de trabajo
más pequeño y de esta forma ahorrar tiempo en ceremonias o prácticas
innecesarias.
- Prototipar y validar las funcionalidades con el cliente previo al desarrollo. Es un
esfuerzo adicional en la etapa de planificación, sin embargo, volver atrás en un
código ya implementado y modificar la planificación del siguiente Sprint causa
aún más retrasos.
- Mantener una dinámica colaborativa con tutores, maestros y clientes es necesario
para asegurar que el sistema.
98
BIBLIOGRAFÍA
AG, S. (2022, 10 1). Software AG. Retrieved from

https://documentation.softwareag.com/webmethods/compendiums/v10-5/C_API
_Management/index.html#page/api-mgmt-comp/co-jwt_usecase_workflow.html
Binde, T., Michelis, G. d., Ehn, P., Jacucci, G., Linde, P., & Wagner, I. (2011). Design
Things (Design Thinking, Design Theory). The MIT Press.
Connolly, R., & Hoar, R. (2015). Fundamentals of web development. New Jersey:
Pearson.
Estrutec SRL. (2021). Descripción de Funciones Encargado de almacén central.

Cochabamba.
Estrutec SRL. (2022, 2 16). estrutec. Retrieved from https://estrutec.com.bo/
Hurtado, M. E. (2011). Módulo de Almacenes - Manual de usuario. Cochabamba:

Sistema Integrado Deltawin.
I. C. (2020, 8 19). IBM. Retrieved from IBM Cloud Learn:

https://www.ibm.com/cloud/learn/api#toc-types-of-a-DMAvqUq6
Schwaber, K., & Sutherland, J. (2020). The Scrum Guide, The Definitive Guide to
Scrum: The Rules of the Game.
Scrum, O. o. (2020, 4 18). Scrum org. Retrieved from Scrum org:

https://www.scrum.org/resources/scrum-framework-poster
Seguro, N. (2021, 09 16). coderhouse. Retrieved from ¿Qué es el desarrollo web?:

https://us.coderhouse.com/blog/que-es-el-desarrollo-web
senadores, C. d. (2018). Manual de administración de almacenes. Asamblea legislativa

plurinacional de Bolivia.
SimpliLearn. (2022, 07 07). SimpliLearn. Retrieved from SimpliLearn:

https://www.simplilearn.com/tutorials/nodejs-tutorial/what-is-express-js
Sis4Gen. (2022). https://www.sis4neg.com/por-que-elegir-postgresql/.
Sommerville, I. (2011). Ingeniería del software. Madrid, España: Pearson.
Theme Selection. (2022, 2 24). dev. Retrieved from dev:

https://dev.to/theme_selection/best-web-development-stack-2jpe
99
ANEXOS
Anexo 1. Árbol de problemas
Figura 64 Árbol de problemas
Anexo 2. Diagramas de flujo
Anexo 3. Product Backlog
Tabla 22 Product Backlog

Backlog
ID Prioridad Descripción Sprint Módulo
1 Muy Alta Registrar un usuario 1 Autenticación y Autorización
2 Muy Alta Asignar rol a usuario 1 Autenticación y Autorización
3 Muy Alta Habilitar el registro de un usuario 1 Autenticación y Autorización
100
4 Alta Gestionar usuarios registrados 1 Autenticación y Autorización
5 Muy Alta Inicio de sesión de un usuario 1 Autenticación y Autorización
6 Media Vistas alternativas 1 Autenticación y Autorización
7 Media Implementar SideBar 1 Autenticación y Autorización
8 Alta Crear un Almacén 2 Almacenes
Mostrar pantalla de todos los
Almacenes
9 Media almacenes 2
Mostrar pantalla de un solo
Almacenes
10 Media almacén 2
Mostrar Nombre de usuario con
Almacenes
11 Media sesión iniciada 2
12 Alta Agregar Encargado a un Almacén 2 Almacenes
Mostrar y Editar información de
Almacenes
13 Media un Almacén 2
14 Alta Eliminar un Almacén 2 Almacenes
15 Alta Crear productos 3y4 Items
16 Alta Añadir productos a un almacén 3y4 Items
Mostrar pantalla con todos los
17 Media productos creados 3y4 Items
18 Media Quitar material de un almacén 3y4 Items
Agregar o Quitar ítems
19 Alta registrados 3y4 Items
Mostrar flujo de operaciones de
20 Alta un ítem 3y4 Items
21 Media Mostrar actividad reciente 3y4 Items
22 Alta Crear solicitud traspaso 5 Traspasos
23 Media Vista solicitudes pendientes 5 Traspasos
24 Alta Implementar Hoja de ruta 5 Traspasos
Aceptar traspaso de material a
25 Alta una sucursal 5 Traspasos
Aceptar envío de material a una
26 Alta sucursal 5 Traspasos
Confirmar llegada de material a
27 Alta una sucursal 5 Traspasos
28 Media Vista Traspasos 5 Traspasos
29 Alta Hoja de ruta finalizada 5 Traspasos
30 Alta Pestaña pedidos en SideBar 6 Pedidos
31 Alta Realizar pedidos 6 Pedidos
32 Media Lista de pedidos realizados 6 Pedidos
33 Media Lista de pedidos pendientes 6 Pedidos
34 Media Detalles de un pedido 6 Pedidos
35 Media Descargar pedido 6 Pedidos
101
36 Alta Comprar ítems 6 Pedidos
37 Alta Aceptar o rechazar Pedido 6 Pedidos
Vistas Responsivas /
Media Tablas Adaptativas 7
38 Visualización de datos
Alta Formularios Adaptativos 7
Media Listas Adaptativas 7
Media SideBar Adaptativo 7
Media Pestaña Dashboard 7
Media Alertas de solicitudes 7
Gráfico para ver la rotación de Vistas Responsivas /
Media 7
44 inventario Visualización de datos
Mantenimiento de equipos
45 Alta Pestaña pedidos en SideBar 8
pesados
Alta Solicitar mantenimiento 8
46 pesados
Alta Kardex de Mantenimientos 8
47 pesados
Lista de Mantenimientos Mantenimiento de equipos
Alta 8
48 pendientes pesados
Media Detalles de un Mantenimiento 8
49 pesados
Media Descargar Mantenimientos 8
50 pesados
Alta Terminar Mantenimiento 8
51 pesados
Aceptar o rechazar Mantenimiento de equipos
Alta 8
52 Mantenimiento pesados
102

Informe Final

Cargado por

Información del documento

Descripción original:

Título original

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

Informe Final

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD CATÓLICA BOLIVIANA “SAN

Sistema web adaptativo para el control de inventarios en la

Tesis de Licenciatura en Trabajo Dirigido

Jhonny Camacho Encinas

Juslan Pedro Vargas Rejas

Pablo Luis Sangueza Becerra Nombre del profesor relator

Profesor Guía Profesor Relator

Wendoline Arteaga Sabja Nombre del Rector Regional

Director de Carrera Rector Regional

1.1.1 Antecedentes institucionales 13

1.1.2 Antecedentes funcionales 15

1.1.3 Antecedentes tecnológicos 21

1.2.1 Situaciones Problemáticas 22

1.2.2 Formulación del problema 23

1.3 DEFINICIÓN DE OBJETIVOS 23

1.3.1 Objetivo general 23

1.3.2 Objetivos específicos 23

1.4.1 Justificación económica 24

1.4.2 Justificación social 24

1.4.3 Justificación tecnológica 25

1.5 ALCANCES Y LÍMITES 25

1.6 PLAN DE TRABAJO 26

2.1 Desarrollo de software 29

2.3 Metodología Ágil, Scrum 32

2.4 Desarrollo Web 34

3.1.1 Análisis de requerimientos 42

3.1.3 Modulación y Diagramado 44

3.1.4 Product Backlog 48

3.1.6 Arquitectura del sistema 48

3.2 Proceso Scrum 49

3.2.1 Sprint 1: Autorización y Autenticación de usuarios 49

3.2.2 Sprint 2: Gestión de Almacenes 56

3.2.3 Sprint 3: Gestión de Ítems: Registro 63

3.2.4 Sprint 4: Gestión de ítems: Ingresos y salidas en Almacenes 66

3.2.5 Sprint 5: Gestión de Transferencias de ítems 71

3.2.6 Sprint 6: Gestión de pedidos de ítems a proveedor 77

3.2.7 Sprint 7: Visualización de Datos y Responsividad 84

3.3.1 Controles de seguridad de información 89

3.3.2 Control de información sensible 92

Anexo 1. Árbol de problemas 96

Anexo 2. Diagramas de flujo 96

Anexo 3. Product Backlog 96

Tabla 1 Análisis de las ventajas y desventajas del sistema actual Deltawin 22

Tabla 2 Descripción de actividades planificadas 27

Tabla 3 Comparación de UI Frameworks 38

Tabla 4 Comparativa de bases de datos consideradas 39

Tabla 5 Comparativa de tecnologías para desarrollar APIs 41

Tabla 6 Sprint 1 Backlog 50

Tabla 7 Criterios cumplidos en el Sprint 1 55

Tabla 8 Sprint 2 Backlog 57

Tabla 9 Criterios cumplidos en el Sprint 2 61

Tabla 10 Sprint Backlog Sprint 3 64

Tabla 11 Criterios cumplidos en el Sprint 3 66

Tabla 12 Sprint Backlog Sprint 4 67

Tabla 13 Criterios cumplidos en el Sprint 4 71

Tabla 14 Sprint Backlog Sprint 5 72

Tabla 15 Criterios cumplidos en el Sprint 5 75

Tabla 16 Sprint Backlog Sprint 6 78

Tabla 17 Criterios cumplidos en el Sprint 6 82

Tabla 18 Sprint Backlog Sprint 7 85

Tabla 19 Criterios cumplidos en el sprint 7 87

Tabla 20 Sprint Backlog Sprint 8 89