Escuela Superior Politécnica de Chimborazo

ESCUELA SUPERIOR POLITÉCNICA DE CHIMBORAZO
FACULTAD DE INFORMÁTICA Y ELECTRÓNICA
CARRERA DE SOFTWARE
Desarrollo de un sistema portable para la gestión de inventarios bajo

el modelo de Software como Servicio (SaaS) para la empresa
"Industria Textil Paoli’s"
TRABAJO DE INTEGRACIÓN CURRICULAR
TIPO: Proyecto Técnico
Presentado para optar el grado académico de:
INGENIERO EN SISTEMAS INFORMÁTICOS
AUTORES: LUCERO MIREYA ULCUANGO ABALCO
ALEX LENIN YAGUACHI YAUCÉN
DIRECTORA: Ing. GLADYS LORENA AGIRRE SAILEMA
Riobamba – Ecuador
2023
© 2023, Lucero Mireya Ulcuango Abalco y Alex Lenin Yaguachi Yaucén
Se autoriza la reproducción total o parcial, con fines académicos, por cualquier medio o
procedimiento, incluyendo cita bibliográfica del documento, siempre y cuando se reconozca el
Derecho del Autor.
i
Nosotros, LUCERO MIREYA ULCUANGO ABALCO y ALEX LENIN YAGUACHI
YAUCÉN, declaramos que el presente trabajo de titulación es de nuestra autoría y los resultados
de este son auténticos. Los textos en el documento que provienen de otras fuentes están
debidamente citados y referenciados.
Como autores asumimos la responsabilidad legal y académica de los contenidos de este trabajo
de titulación; el patrimonio intelectual pertenece a la Escuela Superior Politécnica de
Chimborazo.
Riobamba, día de enero de 2023
Lucero Mireya Ulcuango Abalco Alex Lenin Yaguachi Yaucén
220038377-2 060409692-5
ii
ESCUELA SUPERIOR POLITÉCNICA DE CHIMBORAZO
FACULTAD DE INFORMÁTICA Y ELECTRÓNICA
CARRERA DE INGENIERÍA EN SISTEMAS INFORMÁTICOS
El Tribunal del Trabajo de Titulación certifica que: El trabajo de titulación; tipo Proyecto Técnico
DESARROLLO DE UN SISTEMA PORTABLE PARA LA GESTIÓN DE
INVENTARIOS BAJO EL MODELO DE SOFTWARE COMO SERVICIO (SAAS) PARA
LA EMPRESA "INDUSTRIA TEXTIL PAOLI’S", realizado por los señores: LUCERO
MIREYA ULCUANGO ABALCO y ALEX LENIN YAGUACHI YAUCÉN, ha sido
minuciosamente revisado por los Miembros del Trabajo de Titulación, el mismo que cumple con
los requisitos científicos, técnicos, legales, en tal virtud el Tribunal Autoriza su presentación.
FIRMA FECHA
Ing. / Dr. Nombres y Apellidos _________________ aa-mm-dd
PRESIDENTE DEL TRIBUNAL
Ing. Gladys Lorena Aguirre Sailema _________________ aa-mm-dd
DIRECTORA DE TRABAJO DE
TITULACIÓN
Ing. Jorge Ariel Menéndez Verdecia _________________ aa-mm-dd
MIEMBRO DEL TRIBUNAL
iii
DEDICATORIA
Dedicamos este trabajo de titulación a Dios, por darnos la fuerza necesaria para superar todas las
adversidades de la vida, a nuestros padres por el apoyo constante que nos han impulsado día a día
para poder alcanzar nuestras metas profesionales
Alex, Lucero
iv
AGRADECIMIENTO
Agradecemos a Dios por ser la guía que nos ha permitido alcanzar nuestra meta, a
nuestros queridos padres, hermanos, y hermanas por habernos dado su fuerza y apoyo
incondicional.
Alex, Lucero
v
TABLA DE CONTENIDO
TABLA DE CONTENIDO ........................................................................................................ vi
ÍNDICE DE TABLAS ................................................................................................................ xi
ÍNDICE DE FIGURAS ............................................................................................................ xiii
ÍNDICE DE GRÁFICOS......................................................................................................... xiv
ÍNDICE DE ANEXOS .............................................................................................................. xv
RESUMEN................................................................................................................................ xvi
SUMMARY ............................................................................................................................. xvii
INTRODUCCIÓN .................................................................................................................... 18
CAPÍTULO I
1 DIAGNÓSTICO DEL PROBLEMA....................................................................... 19
1.1 Antecedentes .............................................................................................................. 19

1.2 Formulación del problema ....................................................................................... 20
1.3 Sistematización del problema................................................................................... 20
1.4 Justificación del trabajo de titulación ..................................................................... 20
1.4.1 Justificación teórica ................................................................................................... 20
1.4.2 Justificación aplicativa .............................................................................................. 22
1.5 Objetivos .................................................................................................................... 24

1.5.1 Objetivo general.......................................................................................................... 24
1.5.2 Objetivos específicos ................................................................................................... 24
CAPÍTULO II
2 REVISIÓN DE LITERATURA ............................................................................... 25
2.1 Estudios previos......................................................................................................... 25
vi
2.2 Computación en la nube ........................................................................................... 26
2.2.1 Modelos de servicios en la nube................................................................................. 26
2.3 Software como servicio (SaaS) ................................................................................. 27

2.3.1 Características de SaaS .............................................................................................. 27
2.3.2 Ventajas y desventajas de SaaS ................................................................................. 28
2.3.3 Estrategias de pago para software bajo el modelo SaaS ........................................... 28
2.3.4 Tipos de arquitecturas SAAS ..................................................................................... 29
2.3.4.1 Arquitectura multi-tenant (multiinquilino).................................................................. 29
2.3.4.2 Arquitectura single-tenant (un solo inquilino) ............................................................ 30
2.3.4.3 Beneficios de la arquitectura single- tenant y multi-tenant ........................................ 31
2.4 Gestión de inventarios............................................................................................... 32

2.4.1 Tipos de inventarios ................................................................................................... 32
2.4.2 Stock............................................................................................................................ 32
2.5 Herramientas de desarrollo del sistema .................................................................. 32

2.5.1 Servicios REST ........................................................................................................... 33
2.5.2 Laravel ........................................................................................................................ 33
2.5.3 PHPStomr ................................................................................................................... 33
2.5.4 MySQL ........................................................................................................................ 33
2.5.5 Framework Angular................................................................................................... 33
2.5.6 Modelado de datos (BPMN) ....................................................................................... 34
2.6 Calidad de software................................................................................................... 34

2.6.1 ISO/IEC 25010 ........................................................................................................... 34
2.6.1.1 Características de la norma ISO/IEC 25010 .............................................................. 34
2.6.2 Portabilidad ................................................................................................................ 35
2.6.2.1 Web responsive ........................................................................................................... 35
2.6.3 Eficiencia en función del tiempo ............................................................................... 36
2.6.3.1 Métricas para medir eficiencia ................................................................................... 36
vii
CAPÍTULO III
3 MARCO METODOLÓGICO.................................................................................. 37
3.1 Tipo de investigación................................................................................................. 37

3.2 Métodos y técnicas..................................................................................................... 37
3.3 Descripción de las características del modelo de software como servicio ............ 38
3.3.1 Investigación bibliográfica ........................................................................................ 38
3.4 Proceso de gestión de inventarios de la empresa Industria Textil Paoli´s............ 39

3.5 Desarrollo del sistema ............................................................................................... 41
3.5.1 Conceptualización del sistema ................................................................................... 42
3.5.2 Fase de planificación ................................................................................................. 44
3.5.2.1 Requerimientos............................................................................................................ 44
3.5.2.2 Estudio de factibilidad ................................................................................................ 45
3.5.2.3 Riesgos ........................................................................................................................ 46
3.5.2.4 Planificación ............................................................................................................... 48
3.5.3 Fase de desarrollo ...................................................................................................... 50
3.5.3.1 Estándar de programación ......................................................................................... 50
3.5.3.2 Arquitectura del sistema ............................................................................................. 51
3.5.3.3 Interfaz de usuario ...................................................................................................... 51
3.5.3.4 Base de datos .............................................................................................................. 53
3.5.4 Historias de usuario ................................................................................................... 55
3.5.5 Historias técnicas ....................................................................................................... 56
3.5.6 Tareas de ingeniería ................................................................................................... 56
3.5.7 Pruebas de aceptación ................................................................................................ 57
3.6 Fase de finalización ................................................................................................... 58

3.6.1 Burndown chart.......................................................................................................... 58
3.7 Evaluación de la portabilidad .................................................................................. 58

3.8 Evaluación de eficiencia en función del tiempo ...................................................... 60
3.8.1 Formulación de hipótesis ........................................................................................... 60
viii
3.8.2 Tamaño de la muestra ................................................................................................ 61
3.8.3 Recolección de datos .................................................................................................. 62
CAPÍTULO IV
4 RESULTADOS.......................................................................................................... 63
4.1 Nivel de portabilidad del sistema desarrollado ...................................................... 63

4.1.1 Especificación de las características y subcaracterísticas ........................................ 63
4.1.2 Descripción de niveles de puntuación para la calidad externa ................................ 63
4.1.3 Nivel de importancia .................................................................................................. 64
4.1.4 Ponderación de las características............................................................................. 65
4.1.5 Resultados de evaluación ........................................................................................... 65
4.2 Criterios de evaluación para eficiencia ................................................................... 67

4.2.1 Análisis descriptivo ..................................................................................................... 68
4.2.1.1 Reporte de clientes ...................................................................................................... 68
4.2.1.2 Reporte de existencia de productos terminados .......................................................... 69
4.2.1.3 Reporte de existencias de materia prima .................................................................... 69
4.2.1.4 Reporte de productos en proceso ................................................................................ 70
4.2.1.5 Reporte de pedidos de productos terminados ............................................................. 71
4.2.1.6 Reporte de pedidos de materia prima ......................................................................... 71
4.2.1.7 Reporte de proveedores............................................................................................... 72
4.2.2 Test para la distribución normal................................................................................ 73
4.2.3 Prueba de hipótesis..................................................................................................... 73
4.2.3.1 Análisis de resultados para el reporte de clientes ...................................................... 73
4.2.3.2 Análisis de resultados para el reporte existencias de productos terminados ............. 75
4.2.3.3 Análisis de resultados para el reporte de existencias de materia prima .................... 77
4.2.3.4 Análisis de resultados para el reporte de productos en proceso ................................ 79
4.2.3.5 Análisis de resultados para el reporte de pedidos de clientes .................................... 80
ix
4.2.3.6 Análisis de resultados para el reporte de pedidos de materia prima ......................... 82
4.2.3.7 Análisis de resultados para el reporte de proveedores ............................................... 84
4.2.4 Resultados de evaluación para el nivel de eficiencia ................................................ 86
CONCLUSIONES ..................................................................................................................... 88
RECOMENDACIONES ........................................................................................................... 90
BIBLIOGRAFÍA......................................................................................................................... 5
x
ÍNDICE DE TABLAS
Tabla 1-2: Ventajas y desventajas del modelo SaaS ............................................................. 28

Tabla 2-2: Beneficios de la arquitectura single-tenant y multi-tenant .................................. 31
Tabla 1-3: Métodos y técnicas .............................................................................................. 37
Tabla 2-3: Valores aproximados de búsquedas en sitios web y bases de datos .................... 39
Tabla 3-3: Product Backlog .................................................................................................. 44
Tabla 4-3: Resultados de estimación COCOMO II .............................................................. 45
Tabla 5-3: Priorización de riesgos ........................................................................................ 46
Tabla 6-3: Técnica de estimación T-Shirt ............................................................................. 48
Tabla 7-3: Planificación sprint .............................................................................................. 48
Tabla 8-3: Historias de Usuario ............................................................................................ 56
Tabla 9-3: Tareas de Ingeniería ............................................................................................ 56
Tabla 10-3: Pruebas de Aceptación ........................................................................................ 57
Tabla 11-3: Características y métricas relacionadas con la portabilidad ................................ 59
Tabla 12-3: Métricas y fórmulas para medir portabilidad ...................................................... 59
Tabla 1-4: Niveles de puntuación final para calidad externa ................................................ 63
Tabla 2-4: Definición del nivel de importancia .................................................................... 64
Tabla 3-4: Nivel de importancia para las características de calidad externa......................... 64
Tabla 4-4: Ponderación en porcentajes para calidad externa ................................................ 65
Tabla 5-4: Subcriterios para evaluar adaptabilidad ............................................................... 65
Tabla 6-4: Resultados de adaptabilidad a diferentes dispositivos ......................................... 65
Tabla 7-4: Resumen de resultados ........................................................................................ 66
Tabla 8-4: Resultados del cálculo de portabilidad ................................................................ 67
Tabla 9-4: Valores porcentuales para los factores de portabilidad ....................................... 67
Tabla 10-4: Variable dependiente ........................................................................................... 67
Tabla 11-4: Variable independiente ........................................................................................ 68
Tabla 12-4: Tiempos de obtención del reporte de clientes ..................................................... 68
Tabla 13-4: Tiempos de obtención del reporte existencia de productos terminados .............. 69
xi
Tabla 14-4: Tiempos de obtención del reporte de existencias de materia prima .................... 70
Tabla 15-4: Tiempos de obtención del reporte de productos en proceso ................................ 70
Tabla 16-4: Tiempos de obtención del reporte de pedidos de productos terminados ............. 71
Tabla 17-4: Tiempos de obtención del reporte de pedidos de materia prima ......................... 71
Tabla 18-4: Tiempos de obtención del reporte de proveedores .............................................. 72
Tabla 19-4: Resultados de los tiempos de obtención de reportes de clientes ......................... 74
Tabla 20-4: Prueba T-Student pareada de reporte de clientes................................................. 75
Tabla 21-4: Resultados de tiempos de obtención de reportes de productos terminados ......... 76
Tabla 22-4: Prueba T-Student pareada de reporte de productos terminados .......................... 77
Tabla 23-4: Resultados de tiempos de obtención de reportes de materia prima ..................... 78
Tabla 24-4: Prueba T-Student pareada de reporte de materia prima....................................... 78
Tabla 25-4: Resultados de tiempos de obtención de reportes de productos en proceso ......... 79
Tabla 26-4: Prueba T-Student pareada de reporte de productos en proceso ........................... 80
Tabla 27-4: Resultados de tiempos de obtención de reportes de pedidos de clientes ............. 81
Tabla 28-4: Prueba T-Student pareada de reporte de pedidos de clientes .............................. 82
Tabla 29-4: Resultados de tiempos de obtención de reportes de pedidos de materia prima ... 83
Tabla 30-4: Prueba T-Student pareada de reporte de pedidos de materia prima .................... 84
Tabla 31-4: Resultados de tiempos de obtención de reportes de proveedores ........................ 85
Tabla 32-4: Prueba T-Student pareada de reporte de proveedores ......................................... 86
Tabla 33-4: Promedio de tiempo antes y después del sistema ................................................ 87
xii
ÍNDICE DE FIGURAS
Figura 1-2: Modelo de servicios en la nube .......................................................................... 26

Figura 2-2: Arquitectura multi-tenant. .................................................................................. 30
Figura 3-2: Arquitectura single-tenant .................................................................................. 30
Figura 4-2: Características de la ISO/IEC 25010 ................................................................. 34
Figura 1-3: Diagrama de procesos gestión de inventario Industria Textil Paoli´s ................ 41
Figura 2-3: Flujo de navegación administrador .................................................................... 42
Figura 3-3: Flujo de navegación empleado ........................................................................... 43
Figura 4-3: Flujo de navegación super administrador .......................................................... 43
Figura 5-3: Arquitectura del sistema .................................................................................... 51
Figura 6-3: Bosquejo pantalla principal................................................................................ 52
Figura 7-3: Bosquejo pantalla para reportes ......................................................................... 52
Figura 8-3: Bosquejo pantalla general .................................................................................. 53
Figura 9-3: Modelo físico módulo inventarios ..................................................................... 54
Figura 10-3: Modelo físico modulo Software como servicio (SaaS)...................................... 55
Figura 1-4: Test de Shapiro-Wilk para distribución normal ................................................. 73
xiii
ÍNDICE DE GRÁFICOS
Gráfico 1-3: Burndown Chart ................................................................................................. 58

Gráfico 1-4: Promedio de tiempos de obtención de reporte de clientes.................................. 75
Gráfico 2-4: Promedio de tiempos de obtención de reportes de productos terminados .......... 76
Gráfico 3-4: Promedio de tiempos de obtención de reportes de materia prima ...................... 78
Gráfico 4-4: Promedio de tiempos de obtención de reportes de productos en proceso .......... 80
Gráfico 5-4: Promedio de tiempos de obtención de reportes de pedidos de clientes .............. 82
Gráfico 6-4: Promedio de tiempos de obtención de reportes de pedidos de materia prima .... 84
Gráfico 7-4: Promedio de tiempos de obtención de reportes de proveedores ......................... 86
Gráfico 8-4: Tiempo promedio de obtención de reportes ....................................................... 87
xiv
ÍNDICE DE ANEXOS
Anexo A: Resultados entrevista
Anexo B: Manual técnico
xv
RESUMEN
La presente investigación tuvo como objetivo el desarrollo de un sistema web portable que
automatice los procesos de gestión de inventarios bajo el modelo de software como servicio
(SaaS) que influya en el tiempo de obtención de reportes de inventario. El aplicativo web se
realizó mediante la metodología SCRUM, siguiendo cada una de sus fases de desarrollo, además
se utilizaron como herramientas de desarrollo los servicios REST, framework Laravel para el
desarrollo de la API, framework angular para el desarrollo de la interfaz de usuario, PHPStorm
como entono de desarrollo integrado y MySQL como gestor de base de datos. Se utilizaron
métodos de recopilación de información, como entrevista y encuesta para la obtener el proceso
de inventario interno de la empresa. El sistema permite el registro de productos por categorías:
materia prima, proceso y producto terminado, así como el registro de variantes para cada
producto. Una concluido el sistema se evaluó el nivel de portabilidad y eficiencia en función del
tiempo utilizando las normas ISO/IEC 25010 e ISO 9126, donde se determinó que el sistema
desarrollado es portable con un promedio global de 87.5 %; se evaluó la eficiencia en la obtención
de reportes obteniendo una diferencia significativa a favor del proceso automatizado a
comparación de los tiempos manuales. Se concluye que el sistema bajo el modelo SaaS influye
positivamente en la obtención de reportes de inventario al reducir el tiempo de generación de
estos.
Palabras clave: < TECNOLOGÍA Y CIENCIAS DE LA INGENIERÍA>, < INGENIERÍA DE

SOFTWARE>, < GESTIÓN DE INVENTARIO>, < SOFTWARE COMO SERVICIO >, <
PORTABILIDAD DEL SISTEMA>, < EFICIENCIA >.44C44361
xvi
SUMMARY
Keywords:
xvii
INTRODUCCIÓN
Actualmente las empresas están optando por mantenerse a la vanguardia en el mercado y utilizar
tecnologías que permitan mejorar sus procesos para garantizar un mejor servicio a sus clientes y
beneficiarse del ahorro de recursos y tiempo, en este sentido se puede mencionar al modelo de
software como servicio como una alternativa para las empresas que no tienen la capacidad que
invertir en la tecnología necesaria para alojar un sistema. Siendo SaaS un modelo de servicio en
la nube, el proveedor se encarga de alojar el sistema en sus servidores, dando acceso a sus usuarios
a través de un navegador web con conexión a internet, el proveedor se encarga de dar soporte a
la aplicación para que el cliente sea libre de realizar estas tareas.
“Industria Textil Paoli´s” es una empresa dedicada a la industria textil, en la empresa los procesos
de gestión de inventario se realizan de forma manual lo que lleva mucho tiempo, por esta razón
es necesario desarrollar una aplicación web que automatice los procesos de inventario para
optimizar el tiempo.
El presente trabajo se divide en cuatro capítulos, los cuales se detallan a continuación:
Capítulo I Diagnóstico del problema, en este capítulo se detalla el problema que condujo al
desarrollo del sistema, también se describen la justificación teórica y aplicativa, y se detalla los
objetivos que se pretende alcanzar.
Capítulo II Revisión de literatura, detalla las características, ventajas, desventajas, arquitectura

del modelo de software como servicio SaaS y las herramientas necesarias para el desarrollo del
sistema web.
En el capítulo III Marco metodológico, se describen los métodos, técnicas e instrumentos que
fueron necesarios para el desarrollo del proyecto.
Por último, en el capítulo IV de los Resultados se presenta el análisis de resultados donde se

evaluó la eficiencia en función del tiempo de obtención de reportes y la portabilidad del sistema
en diferentes dispositivos.
18
CAPÍTULO I
1 DIAGNÓSTICO DEL PROBLEMA

1.1 Antecedentes
El software como servicio (SaaS) es un modelo que permite acceder a los datos desde cualquier
dispositivo con conexión a internet y un navegador web (Herazo, 2020). En este método basado
en la web, los proveedores de software alojan, mantienen los servidores, las bases de datos y el
código que conforma una aplicación, este tipo de modelos de pago por suscripción SaaS ayudan
a las empresas con pequeños presupuestos a distribuir el costo total de propiedad a lo largo del
tiempo, por lo que incluso las pequeñas empresas pueden adoptar un software sólido y moderno.
La Empresa "Industria Textil Paoli’s" ubicada en la ciudad de Riobamba se dedica a la confección

de prendas de todo tipo lo cual da lugar a que sus productos se comercialicen a nivel nacional,
sus principales clientes son las entidades públicas, privadas, personas naturales, entre otros.
En la empresa "Industria Textil Paoli’s", el principal problema es que cuenta con un software para
la gestión de inventarios que fue desarrollado únicamente para funcionar en un entorno de
escritorio y se lo instaló solo en un computador que por el paso del tiempo ha quedado obsoleto,
impidiendo que el sistema pueda ser utilizado en dicha máquina y tampoco pueda ser instalado
en otra, ya que no fue construido tomando en cuenta características de portabilidad, lo que ha
provocado que se deba realizar la obtención de reportes de inventarios de forma manual,
incrementándose el tiempo utilizado para obtener información actualizada, sumado a que se
cuenta con un limitado presupuesto para invertir en la compra de un nuevo software y el hardware
requerido.
19
1.2 Formulación del problema
¿Es posible desarrollar un sistema portable de gestión de inventarios bajo el modelo de software
como servicio (SaaS) que influya en el tiempo de generación de reportes de inventario?
1.3 Sistematización del problema

¿Cuáles son las principales características, ventajas y desventajas del modelo SaaS?
¿Cuál es el proceso que se realiza para implementar el modelo SaaS?
¿Cuál es la arquitectura para implementar el modelo SaaS?
¿Cuáles son los parámetros para determinar el nivel de portabilidad?
¿Cuál es el proceso para la gestión de inventarios?
¿Es posible desarrollar la aplicación de gestión de inventarios bajo el modelo SaaS que influya
en el tiempo de generación de reportes de Inventarios?
¿Cuál es el nivel de portabilidad del sistema?
1.4 Justificación del trabajo de titulación

1.4.1 Justificación teórica
Es importante para cualquier empresa mantenerse a la vanguardia y adoptar tecnologías que

mejoren sus procesos, en este contexto se puede mencionar al modelo SaaS como una alternativa
para pequeñas y medianas empresas que no tengan la capacidad de invertir inicialmente en
tecnología necesaria para alojar sistemas. SaaS es un modelo de servicios mediante el cual el
proveedor aloja la aplicación en sus propios servidores, dándole al cliente acceso a ella a través
de internet. La empresa provee del servicio de mantenimiento diario, almacenamiento de la
información y seguridad de los datos, liberando así al cliente de estas tareas y los gastos asociados
como servidores, hardware, software, etc. Los proveedores del software como servicio pueden
fijar el precio de sus aplicaciones basándose en una selección de múltiples factores de uso, como
el número de usuarios, las transacciones, la cantidad de datos u otras unidades de medida
(Evaluando ERP, 2021).
Para entender el ahorro real del SaaS hay que mirar más allá de la concesión de licencia y de las
suscripciones. Los ahorros en SaaS se desprenden de la posibilidad de no tener que destinar una
gran cantidad de recursos al departamento IT ya que este estaría externalizado. Con un sistema
SaaS, el proveedor asume el «trabajo pesado» que conlleva el hosting, el mantenimiento del
software y la garantía en la seguridad de los datos. Aun así, es probable que el administrador
todavía tenga que configurar el sistema o hacer pruebas para asegurar la funcionalidad del
entorno.
20
Por otro lado, los compradores de sistemas tradicionales son responsables de mantener la
infraestructura (servidores, bases de datos…), que alimenta el software y asegurar los datos y el
tiempo de actividad. Si el sistema falla, también responsabilidad del departamento IT. La
naturaleza impredecible de este tipo de problemas hace que sea difícil saber exactamente cuánto
tiempo se tendrá que invertir para solucionar el problema y cuál es el coste que le supondrá a la
empresa.
Por ejemplo, la empresa Perseo ofrece servicios SaaS con los siguientes costos mensual y anual
(Perseo, 2020):
• Costo de facturación con un valor de 14.99 + IVA, para lo cual incluye:

Facturación Electrónica Ilimitada, Video Tutoriales y Capacitaciones Zoom, Actualizaciones
3 usuarios, Gráficos de BI / Dash Board y 1 licencia App PerseoMóvil
• Costo de facturación anual con un valor de 144.99 +IVA para lo cual incluye: 15 meses de
servicio, Facturación Electrónica Ilimitada, Video Tutoriales, Capacitaciones Zoom
Actualizaciones, 3 usuarios, Gráficos de BI / Dash Board y 1 licencia App PerseoMóvil
SaaS es un modelo de servicio que se adapta más fácilmente a muchos de los requerimientos de
todo tipo de organizaciones tanto públicas como privadas e incluso instituciones educativas
(Delgado Sandí, 2017, pp. 22-23).
Según (Delgado Sandí, 2017, pp. 22-23) entre las principales ventajas de utilizar SaaS se
encuentran:
• Licenciamiento - No existe costo por licencias, se cuenta con un modelo de pago flexible (por
tipo de recurso y tiempo consumido).
• Ubicuidad – ofrece el acceso desde cualquier dispositivo en cualquier momento
• Instalación - No se requiere de la instalación de ningún tipo de software adicional, debido a
que únicamente se requiere de conexión a internet y un navegador web para ejecutar las
aplicaciones.
• Actualizaciones automáticas y constantes - El consumidor siempre tendrá a su disposición la
última versión de las aplicaciones (mejorar de la aplicación, así como las actualizaciones de
seguridad) sin costos adicionales.
• Respaldo de información - Respaldos diarios por parte del proveedor de los servicios SaaS,
sin necesidad de intervención por parte del consumidor.
• Soporte - El soporte se realiza en línea por parte del proveedor de los servicios, no se requiere
de visitas de técnicos en el sitio.
21
• Mantenimiento – No es necesario el mantenimiento del sistema en la computadora del usuario
o consumidor, debido a que las aplicaciones se encuentran alojadas en los servidores de los
proveedores y, son ellos los responsables de brindar dicho mantenimiento.
Según (ISO 25010, 2011) Portabilidad es la capacidad del producto o componente de ser
transferido de forma efectiva y eficiente de un entorno hardware, software, operacional o de
utilización a otro. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:
• Adaptabilidad. Capacidad del producto que le permite ser adaptado de forma efectiva y
eficiente a diferentes entornos determinados de hardware, software, operacionales o de uso.
• Capacidad para ser instalado. Facilidad con la que el producto se puede instalar y/o
desinstalar de forma exitosa en un determinado entorno.
• Capacidad para ser reemplazado. Capacidad del producto para ser utilizado en lugar de
otro producto software determinado con el mismo propósito y en el mismo entorno.
1.4.2 Justificación aplicativa
El sistema propuesto permitirá a la empresa influir en el tiempo de generación de reportes de

inventario, será desarrollado tomando en cuenta características de portabilidad lo que permitirá al
usuario usarlo desde cualquier entorno y lugar evitando procesos de instalación, además al ser
proporcionado bajo el modelo de Software como Servicio (SaaS) reducirá el costo para la
empresa ya que no deberá comprar el software ni el hardware sino que pagará una suscripción
mensual únicamente por el servicio que se contrate lo cual es mucho más accesible (Catania,
2019).
Otros beneficios que brindará el sistema serán:
• Accesibilidad a la información a través de un medio web.

• Respaldo digital de la información.
• Asistencia remota.
• Sistema siempre actualizado.
El sistema contará con los siguientes módulos:
• Módulo de Autenticación: Este módulo permitirá iniciar, y terminar la sesión a los usuarios.
• Módulo de gestión de usuarios: Este módulo permitirá el registro, edición o eliminación de
usuarios en el sistema.
• Módulo de gestión de empresas de un usuario: permitirá el registro, edición o eliminación de
empresas de un usuario.
22
• Módulo de contratación de servicios: Este módulo permitirá a los usuarios contratar uno o
varios servicios para cada una de sus empresas registradas.
• Módulo de gestión de cobros: permitirá automatizar el cobro anual, mensual, semanal y diario
a los usuarios por los servicios contratados.
• Módulo Ubicaciones que permitirá, identificar áreas específicas dentro de los almacenes con
el objeto de tener una localización más precisa del inventario según se requiera.
• Módulo de gestión inventario: permitirá registrar, editar, eliminar productos, generando
reportes de inventario.
Sub-módulos:
Módulo de Entrada de Inventario
Módulo Salida de Inventario
Módulo Traspaso de Inventario
23
1.5 Objetivos
1.5.1 Objetivo general
Desarrollar un sistema portable de gestión de inventarios usando el modelo de software como

servicio (SaaS) que influya en el tiempo de generación de reportes de inventario.
1.5.2 Objetivos específicos
• Describir las principales características, ventajas, desventajas, proceso y la arquitectura

necesaria para implementar el modelo SaaS.
• Analizar los procesos de gestión de inventarios de la empresa Industria Textil Paoli’s
• Desarrollar el software de gestión de inventarios bajo el modelo SaaS utilizando la
metodología SCRUM.
• Determinar el nivel de portabilidad del sistema desarrollado.
• Obtener el nivel de eficiencia en función de los tiempos de generación de los reportes de
inventario, del sistema portable desarrollado.
24
CAPÍTULO II
2 REVISIÓN DE LITERATURA
En el presente capítulo se detallan estudios previos acerca de aplicaciones que funcionan bajo el
modelo de software como servicio SaaS, además de conceptos correspondientes a herramientas y
tecnologías fundamentales para el desarrollo del trabajo.
2.1 Estudios previos
El trabajo de los autores Chandi y Roldán (2015) sirve de base para la construcción de la presente
investigación, pues se centra en un problema empresarial recurrente: la empresa no cuenta con un
sistema web que permita a sus clientes la consulta de saldos y movimientos de cuentas de ahorro
y depósitos desde cualquier ubicación en la que se encuentren. En base a ello, esta investigación
apunta hacia los siguientes objetivos: describir el modelo de distribución SaaS a fin de especificar
sus características y funcionalidades; describir y comparar los principales proveedores de
Servicios Virtuales IaaS para determinar la infraestructura adecuada para la aplicación a ser
implementada. Es evidente la relación con el estudio en mención, ya que el presente trabajo de
integración curricular propone un aplicativo web alineado con el modelo de servicio SaaS.
También cabe mencionar que el estudio de Chandi y Roldán describe de manera breve a SaaS, ya
que dicho estudio se limita al análisis de la infraestructura en la nube IaaS.
El trabajo de Alegre (2020) también es de interés, puesto que plantea “implementar un Sistema
de Gestión de Procesos de Negocio basado en el Modelo SaaS, que permita automatizar flujos de
trabajo empresariales en T&S Servicios de Ingeniería SAC - Año 2018”. Sugiere que, para
obtener información requerida para la descripción del sistema, se aplique entrevistas y encuestas
para recopilar datos más precisos para el desarrollo del producto. Además, en su contenido se
precisa el diseño, desarrollo y funcionamiento del Sistema de Gestión de Procesos de Negocio
basado en el modelo SaaS, gracias a los requerimientos funcionales y no funcionales para la
automatización de flujos de trabajo empresariales. En este contexto, es posible afirmar que este
estudio se relaciona estrechamente con el presente trabajo ya que muestra cómo se organiza el
modelo SaaS conforme a una estructura de tres capas, lo que resulta en una contribución
importante que brinda una idea clara acerca de la implementación del modelo de negocios de
software entendido como un servicio.
25
2.2 Computación en la nube
Según IBM (2019), la computación en la nube o Cloud Computing es una tecnología que permite
el acceso remoto a softwares, almacenamiento de archivos y procesamiento de datos a través de
Internet, lo que la convierte en una alternativa eficiente frente a la ejecución tradicional en una
computadora personal o servidor local. Además, en el modelo de nube no existe la necesidad de
instalar aplicaciones localmente en computadoras.
2.2.1 Modelos de servicios en la nube
Según Microsoft (2020), cada una de las clasificaciones de la implementación del Cloud
Computing presenta un modelo de funcionamiento para brindar servicios en función de las
necesidades del usuario. En la Figura 1-2 se observa una representación de los modelos en el
cual SaaS se ubica en el nivel más alto, lo que significa que todos los recursos tanto de hardware
como de software son gestionados por el proveedor del servicio.
Figura 1-2: Modelo de servicios en la nube
Fuente: (Microsoft Azure, 2020)
Es posible catalogar a los modelos de servicio de la siguiente forma.
• Infraestructura como servicio. Este modelo permite a los clientes acceder a los servicios de
uso del CPU, capacidades de almacenamiento, redes y otros, de tal manera que el consumidor
es capaz de ejecutar el software a su elección, mismo que puede ser aplicaciones y / o sistemas
operativos.
• Plataforma como servicio. Este tipo de modelo permite a los usuarios disponer de un espacio
en la nube en el que pueden desarrollar sus propias aplicaciones de negocios.
26
• Software como servicio. Es un método apto para la entrega de aplicaciones de software a
través de Internet, bajo demanda y generalmente por suscripción. Con SaaS, los proveedores
de la nube alojan y administran la aplicación de software y la infraestructura subyacente;
además es posible manejar varios tipos de mantenimiento como actualizaciones de software
y parches de seguridad.
Los modelos en la nube hoy en día son una herramienta importante para mantenerse actualizado
en tecnología ya que facilita el acceso a un sistema desde cualquier lugar, tal es el caso del modelo
de software como servicio que permite a las pequeñas empresas automatizar sus procesos sin la
necesidad de invertir grandes cantidades de dinero en infraestructura basta con un pago mensual
o anual para tener todos los beneficios que ofrece esta herramienta.
2.3 Software como servicio (SaaS)
SaaS ofrece una solución de software integral que se adquiere a un proveedor de servicios en la
nube mediante un modelo de pago por uso; es decir que el usuario alquila el uso de una aplicación
para su organización y sus clientes se conectan a ella a través de Internet, normalmente con un
explorador web.
El proveedor de servicios administra el hardware y el software, y a través de un contrato de

servicios adecuado garantiza la disponibilidad, seguridad de la aplicación y de sus datos. SaaS
permite que una organización se ponga en marcha y pueda ejecutar aplicaciones con un costo
inicial mínimo (Microsoft Azure, 2020).
2.3.1 Características de SaaS
Según Microsoft (2020), el software como servicio puede funcionar fácilmente en la mayoría de
los contextos empresariales, aportando características como:
• Obtener acceso a aplicaciones sofisticadas. Para proporcionar aplicaciones SaaS a los

usuarios, no es necesario comprar, instalar, actualizar o mantener ningún hardware,
middleware o software.
• Pagar sólo por lo que usa. Es una herramienta de ahorro, pues el servicio de SaaS se
incrementa o disminuye automáticamente según el nivel de uso.
• Acceder a los datos de la aplicación desde cualquier lugar. Con los datos almacenados en
la nube, los usuarios pueden acceder a su información desde cualquier ordenador o dispositivo
móvil al que esté conectado a Internet.
27
Una de las características que destacan del modelo SaaS es el modelo de pago por uso, ya que se
puede contratar el servicio y pagar por lo que realmente se utiliza, y puedes cancelarlo en
cualquier momento sin ningún problema.
2.3.2 Ventajas y desventajas de SaaS
En la siguiente Tabla 1-2 se puede observar algunas de las principales ventajas y desventajas que
surgen del modelo de software como servicio (SaaS).
Tabla 1-2: Ventajas y desventajas del modelo SaaS
Ventajas Desventajas
No existen costos de hardware. Se comparte datos con el proveedor.

No existen costos iniciales de instalación. Posibles interrupciones del servicio.
Sólo se paga por lo que se usa. Necesidad de una conexión a Internet rápida
Las actualizaciones son automáticas. y constante.
Compatibilidad con todos los dispositivos. Incapaz de usar en caso de tiempo de
Accesible desde cualquier lugar. inactividad.
Las aplicaciones se pueden personalizar.
Fuente: (Catania, 2019).
Realizado por: Ulcuango, L. y Yaguachi, A., 2020.
Como en cualquier software existen pros y contras y en el caso del modelo de software como
servicio no hay excepción como se muestra en la Tabla 1-2 y una de las ventajas que más
llamativas de este tipo de modelo es el pago por uso que es también una de las principales
características, otra ventaja importante es que las aplicaciones se pueden personalizar, además no
es necesario invertir en costes iniciales de hardware, software y mantenimiento. También
podemos destacar que este tipo de servicio en la nube tiene varias desventajas como las posibles
interrupciones del servicio ya que es necesario tener una conexión a internet rápida y estable
además la información se comparte con el proveedor lo que puede ser comprometedor para el
usuario.
2.3.3 Estrategias de pago para software bajo el modelo SaaS
Según Bąk (2018), existen tres estrategias de pago que se pueden utilizar en software como
servicio (SaaS).
• Freemium. Su aplicación proporciona funcionalidades estándar de forma gratuita y se puede

ampliar a más características de pago premium. Este modelo permite a los usuarios conocer
la aplicación.
28
• Suscripción. Similar a Freemium, este modelo se basa en una tarifa recurrente
(mensualmente, por ejemplo) para acceder a contenido adicional. Es la estrategia más
adecuada para aplicaciones centradas en el contenido, como es el caso de la aplicación de
alojamiento de vídeo.
• Aplicaciones de pago. Su solicitud está disponible para una compra única. La ventaja de esta
estrategia es que incluso si el usuario deja de usar su producto, la empresa todavía obtiene el
dinero.
Las estrategias de pago se adaptan a las necesidades de los usuarios, el proveedor del servicio
puede ofrecer funcionalidades estándar o básicas que son gratuitas para que el usuario conozca la
aplicación durante un tiempo determinado, también están las suscripciones que permiten contratar
el servicio a través una cuota recurrente que puede ser mensual o anual y para este tipo de modelo
esta modalidad de pago por suscripciones recurrentes es la más idónea.
2.3.4 Tipos de arquitecturas SAAS
Las soluciones SaaS modernas cuentan con un tipo de arquitectura llamada multi-tenant o
multiinquilino, donde una instancia del software se utiliza para varios usuarios potencialmente de
diferentes organizaciones (Toth y Vigo, 2014, p. 368). A su vez, SaaS cuenta con otro tipo de
arquitectura denominada single-tenant (un solo inquilino).
2.3.4.1 Arquitectura multi-tenant (multiinquilino)
La arquitectura de software llamada multi-tenant está orientada a la nube, implica una sola
instancia de la aplicación, pero sirve a múltiples clientes u organizaciones, como se observa en la
Figura 2-2. Cada instancia de base de datos está separada en un servidor totalmente aislado, por
lo que se pueden cumplir con necesidades importantes como el alojamiento de la información en
distintas regiones. Esto implica que desde una organización no se pueda acceder a los datos de
otra, por lo que el nivel de aislamiento es alto e implica grandes ventajas (Valdes, 2020).
29
Además, es importante resaltar que la arquitectura multiinquilino es un concepto clave en la
construcción y entrega de soluciones de software como servicio (SaaS) (Amgai, 2019).
Figura 2-2: Arquitectura multi-tenant.
Fuente: (Amgai, 2019)
2.3.4.2 Arquitectura single-tenant (un solo inquilino)
En la arquitectura de un solo inquilino, una sola instancia del software se ejecuta en un servidor
dedicado de la nube, es decir, este sirve a un solo cliente (Goyal, 2019). Esto significa que los
clientes no pueden compartir la base de datos o la aplicación entre ellos, porque cada uno tiene
sus propias instancias de base de datos y aplicaciones (Valdes, 2020). Se puede apreciar una
representación de este tipo de arquitectura en la Figura 3-2.
Figura 3-2: Arquitectura single-tenant
Fuente:(Amgai, 2019)
30
2.3.4.3 Beneficios de la arquitectura single- tenant y multi-tenant
En la Tabla 2-2 se muestra los beneficios más importantes de los dos tipos de arquitectura SaaS,
que también marcan las diferencias que cada una de estas posee, por lo que resulta importante de
analizar para así escoger una arquitectura adecuada para el desarrollo del software.
Tabla 2-2: Beneficios de la arquitectura single-tenant y multi-tenant
Arquitectura single-tenant (un solo inquilino) Arquitectura multi-tenant (multiinquilino)
Personalizable: el cliente es libre de realizar cambios en Menores costos: Permite el intercambio de servicios,
la configuración de software o hardware (Hoogenraad, bases de datos, recursos y aplicaciones, por lo que puede
2019). costar menos que una estructura de un solo inquilino.
Máxima privacidad: sólo hay una instancia para un Recursos eficientes: todos los recursos se comparten, la
usuario, por lo que existen menos riesgos (Mundra, arquitectura multiinquilino utiliza herramientas que
2015). ofrecen una eficiencia óptima.
Operaciones confiables: dado que las actividades de un Menos costos de mantenimiento: los clientes no tienen
usuario no pueden afectar a otros, la arquitectura SaaS que pagar costosas tarifas para mantener el software
de un sólo inquilino se considera más fiable. actualizado.
Restauración y copia de seguridad fáciles: la base de Centro de datos compartido: de forma similar a un
datos de cada cliente cuenta con una copia de seguridad entorno de un solo inquilino, un proveedor no tiene que
aislada, resultando más fácil restaurar o realizar copias crear un nuevo centro de datos para cada nuevo usuario.
de seguridad de la base de datos en una estructura SaaS
Mayor capacidad informática: proporciona a las
de un solo inquilino.
organizaciones la capacidad de permanecer en el mismo
Mejoras individuales: las empresas que utilizan la centro de datos e infraestructura.
arquitectura de un solo inquilino pueden actualizar sus
servicios individualmente (Takyar, 2020)
Fuente: (Takyar, 2020)

Realizado por: Ulcuango, L.; Yaguachi, A., 2020
Las dos arquitecturas analizadas tienen beneficios que se adaptan a las necesidad del usuario, tal
es el caso de este proyecto que teniendo en cuenta toda la información encontrada sobre el modelo
de software como servicio, se ha determinado que la arquitectura multiinquilino o mutitenant se
adapta más a las necesidades requeridas para el desarrollo del sistema de inventario ya que, como
se observa en la Figura 2-2, cada instancia de la base de datos está separada en un servidor
totalmente aislada, y además representa un mayor beneficio para el usuario ya que los costos de
mantenimiento con menores y la capacidad de información es mayor así como también los
recursos son más eficientes.
31
2.4 Gestión de inventarios
El control de inventario con respecto a cualquier proceso de fabricación hace referencia a las
medidas adoptadas para mantener los niveles adecuados de materias primas y productos
terminados (Smook, 2016, p. 189). El objetivo básico del control de inventarios es reducir la
inversión en ellos y asegurar que el proceso de producción no sufra como resultado (Yadav y
Malik, 2014, p. 554).
2.4.1 Tipos de inventarios
Según (Fernández, 2018,p 166 ), existen numerosas clasificaciones y tipos de inventario, pero
algunos de los más importantes y elementales son:
• Materias primas. Registran los materiales que ingresan al proceso de fabricación y son
entregados por los proveedores.
• Productos semiterminados. Documentan las etapas por las que pasa un producto durante la
fabricación o producción.
• Productos terminados. Recolectan productos para vender a los clientes.
Estos tipos de inventario son muy comunes en las empresas de manufactura como es el caso de
la empresa Industria Textil Paoli´s que maneja materias primas, productos semiterminados y
productos terminados por lo que se hace el ingreso y salida de estos cambiando el stock que se
tiene en bodega.
2.4.2 Stock
En un almacén, el stock se analiza físicamente usando cantidades y financieramente usando

valoración. Desde el punto de vista físico, requiere un recuento fijado en el inventario, custodia,
mantenimiento y manipulación, de forma adecuada para su conservación en perfecto estado, para
la venta o incorporación al proceso de fabricación (Fernández, 2018,p. 166).
2.5 Herramientas de desarrollo del sistema
En este apartado se describen las herramientas que se utilizarán en el desarrollo de un sistema

portable para la gestión de inventarios bajo el modelo de Software como Servicio (SaaS),
adaptado a la empresa "Industria Textil Paoli’s".
32
2.5.1 Servicios REST
Los servicios web basados en la arquitectura REST (Representational State Transfer), son una
alternativa más simple a SOAP y a WSDL; esta transmite los datos sobre el protocolo
estandarizado HTTP.
Varias empresas como Google, Facebook y Yahoo! son casos de éxito que migraron sus servicios
a esta tecnología (Haro, Guarda, Zambrano, Ninahualpa, 2019).
2.5.2 Laravel
Laravel es un marco de aplicación web de sintaxis expresivo, elegante y moderno. Los marcos
web proporcionan una estructura y un punto de partida para crear aplicaciones, de modo que
pueda concentrarse en crear excelentes aplicaciones mientras ajusta los detalles. Brinda una
excelente experiencia de desarrollador al mismo tiempo que facilita características poderosas
como inyección de dependencia profunda, capa de abstracción de base de datos expresiva,
trabajos y colas programados, pruebas de unidad e integración, y más (Laravel, 2021).
2.5.3 PHPStomr
Es un IDE altamente pulido para trabajar con PHP, JavaScript y otros lenguajes relacionados con
la Web; su interfaz de edición es amigable y de fácil utilización.
PhpStorm es una herramienta ideal para trabajar con Symfony, Laravel, Drupal, WordPress, Zend
Framework, Magento, Joomla!, CakePHP, Yii y otros marcos (Logon, 2020).
2.5.4 MySQL
MySQL es un sistema de gestión de bases de datos relacionales (RDBMS) de código abierto

utiliza el lenguaje de programación (SQL). Funciona prácticamente en la totalidad de plataformas,
incluidas Linux, UNIX y Windows; a pesar de que se puede utilizar en una amplia gama de
aplicaciones, MySQL se asocia directamente con las aplicaciones basadas en la web y la
publicación en línea (Baram, 2015).
2.5.5 Framework Angular
Angular es una plataforma destinada a la creación de aplicaciones de una sola página mediante
HTML y TypeScript. Implementa la funcionalidad principal y opcional como un conjunto de
bibliotecas TypeScript que se importan en las aplicaciones. La arquitectura de una aplicación
Angular se basa en ciertos conceptos fundamentales (Angular, 2020).
33
2.5.6 Modelado de datos (BPMN)
Para tener un claro concepto del diagrama de proceso, se hizo uso del estándar de modelado y
notación conocido como Business Process Model and Notation (BPMN), cuyo principal objetivo
es simplificar la representación de los procesos, ya sean comerciales o de aplicación, para facilitar
su comprensión y ejecución por todos sus usuarios (Prego-Nieto, 2020).
Las herramientas que se han descrito facilitan el desarrollo del sistema ya que por medio del uso
de cada una de estas podemos crear la parte del frontend y backend tenido como resultado un
sistema web de gestión de inventarios.
2.6 Calidad de software
La calidad de un sistema, aplicación o producto depende de los requisitos que describen el

problema, el diseño que simula la solución, el código que conduce a un programa ejecutable y las
pruebas que ejecuta el software para encontrar errores (Pressman, 2010, p.582).
2.6.1 ISO/IEC 25010
La norma ISO/IEC 25010 es parte de la familia de normas ISO 25000. Esta define que la calidad
del producto software se puede considerar como el grado de satisfacción frente a los requisitos de
sus usuarios, aportando de esta forma valor.
2.6.1.1 Características de la norma ISO/IEC 25010

La ISO/IEC 25010 se conforma por ocho características simultáneas y cada una cuenta con
subcaracterísticas de calidad que se muestran en la Figura 4-2:
Figura 4-2: Características de la ISO/IEC 25010
Fuente: ISO 25010, 2011
La ISO 25010 (2011) describe a cada una de las características de la siguiente manera:
• Adecuación funcional. Capacidad del producto software para proporcionar funciones que
satisfacen las necesidades declaradas e implícitas, siempre y cuando se use en las condiciones
especificadas.
34
• Eficiencia de desempeño. Representa el rendimiento relativo a la cantidad de recursos
utilizados en determinadas condiciones.
• Compatibilidad. Capacidad de dos o más sistemas o componentes para intercambiar

información, y/o llevar a cabo sus funciones cuando comparten el mismo entorno de hardware
o software.
• Usabilidad. La capacidad de un producto de software para ser entendido, aprendido, usado y

atractivo para los usuarios cuando se usa bajo condiciones específicas.
• Fiabilidad. Facultad de un sistema o componente para desempeñar las funciones

especificadas cuando se utiliza bajo condiciones y periodos de tiempo determinados.
• Seguridad- Protección de información y datos para que personas o sistemas no autorizados

estén impedidos en leerlos o modificarlos.
• Mantenibilidad. La capacidad de un producto de software para modificarse efectivamente

como resultado del desarrollo, corrección o mejora.
• Portabilidad: Capacidad del producto o componente para ser transferido de forma efectiva
y eficiente de un entorno hardware, software, operacional o de utilización a otro.
2.6.2 Portabilidad
Según (Nori, Karodiya, Reza, 2013, pp.1–8), la portabilidad de un sistema se refiere a la facilidad
con la que se puede hacer que este funcione en diferentes plataformas.
Los autores (Nori, Karodiya, Reza, 2013, pp.1–8) coinciden con la norma (ISO 25010, 2011) en
el concepto de portabilidad, ambos mencionan que es la capacidad con la que un sistema puede
funcionar dentro de un sistema diferente o en diferentes plataformas.
2.6.2.1 Web responsive

Se describe como una técnica de diseño y desarrollo web que le permite refinar sitios web
utilizando estructuras e imágenes fluidas, así como de media-queries en la hoja de estilo CSS,
consigue adaptar el sitio web al entorno del usuario.
Una aplicación web tiene como característica ser responsiva cuando se busca que su diseño se
adapte a los diferentes tipos de dispositivos que existen, ya sea tablets, celulares, ordenadores,
etc. (Cajiao Barrera y Lazo Villanueva, 2022. p.27). El diseño web responsivo, también conocido
como diseño web adaptativo, se encarga de adaptarse automáticamente a cada pantalla,
independientemente del dispositivo utilizado y su resolución o tamaño(Arevalo, 2021).
35
Según (Martínez et al., 2013) para hacer un diseño web adaptativo se debe cumplir con los
siguientes aspectos:
• Diseño fluido con cuadrículas flexibles o fluid grids.

• Media Queries.
• Imágenes, objetos, videos o medios similares flexibles.
• Fuentes tipográficas con valores relativos
2.6.3 Eficiencia en función del tiempo
Según (ISO 25010, 2011), la eficiencia representa el desempeño relativo a la cantidad de recursos
utilizados bajo determinadas condiciones. Esta característica se subdivide en las siguientes
subcaracterísticas:
• Comportamiento temporal. Los tiempos de respuesta y procesamiento y las ratios de

throughput de un sistema cuando lleva a cabo sus funciones bajo condiciones determinadas
en relación con un banco de pruebas (benchmark) establecido (ISO/IEC, 2011a).
• Utilización de recursos. Relacionado con las cantidades y tipos de recursos utilizados cuando
el software lleva a cabo su función bajo condiciones determinadas (ISO/IEC, 2011b).
2.6.3.1 Métricas para medir eficiencia
Para medir la eficiencia en función del tiempo del sistema se utiliza un análisis inferencia el cual
permite determinar una hipótesis alterna y nula de tal modo que con una prueba de hipótesis se
pueda aceptar o rechazar una de las hipótesis mismas que se analizan tomando en cuenta los
tiempos de antes y después del sistema.
36
CAPÍTULO III
3 MARCO METODOLÓGICO
El presente capítulo se analiza el tipo de investigación, los métodos y técnicas para la recolección
de información, además se describe de manera breve las herramientas que se implementan en el
desarrollo del proyecto.
3.1 Tipo de investigación
Este trabajo de titulación se constituye como una investigación de tipo aplicativa, pues busca
solucionar el problema de gestión de inventarios de la empresa Industria Textil Paoli´s a través
de un sistema que permita influir en el tiempo de generación de reportes de inventario, ya que
actualmente este proceso se realiza de forma manual.
3.2 Métodos y técnicas
En esta sección se detalla los métodos y técnicas que se emplearon en el desarrollo de cada uno
de los objetivos planteados como se puede evidenciar en la Tabla 1-3.
Tabla 1-3: Métodos y técnicas
Métodos y técnicas
Objetivos Métodos Técnicas Fuentes
Describir las principales características, Analítico • Revisión bibliográfica • Internet

ventajas, desventajas, proceso y la • Bases de datos
arquitectura necesaria para implementar el • Artículos
modelo SaaS. científicos
• Libros
Analizar los procesos de gestión de Analítico • Observación no • Usuario

inventarios de la empresa Industria Textil estructurada
Paoli’s. • Encuesta
• Diagrama de procesos
Desarrollar el software de gestión de SCRUM • Observación • Desarrolladores
inventarios bajo el modelo SaaS utilizando • Entrevista • Usuarios
la metodología SCRUM. • Historias de Usuario
• Historias técnicas
• Pruebas de aceptación
Determinar el nivel de portabilidad del Inductivo • Observación • ISO/IEC 25010
sistema desarrollado. • Pruebas de Portabilidad • ISO/IEC 25023
• ISO/IEC 25040
37
• ISO/IEC 9126
• Desarrolladores
• Usuarios
Obtener el nivel de eficiencia en función de Inductivo • Tiempo de respuesta • Desarrolladores

los tiempos de generación de los reportes de • Modelo estadístico • Usuarios
inventario, del sistema portable • ISO/IEC 25010
desarrollado. • ISO7IEC 9126
Realizado por: Ulcuango, L.; Yaguachi, A. 2021
El método analítico se lo usa ya que permite descomponer en partes pequeñas para observar las
causa, naturaleza y efectos, permite ir de los general a lo especifico (Echavarría et al., 2010).
La entrevista facilita la recolección de información que permite definir los requerimientos

funcionales del sistema, la observación permite visualizar el entorno libremente para entender
cómo funciona el proceso interno de gestión de inventarios de la empresa.
3.3 Descripción de las características del modelo de software como servicio
Mediante el uso del método analítico es posible investigar acerca del software como servicio
(SaaS). Es así como se analiza la información correspondiente logrando entender de mejor manera
el modelo; también se utiliza la técnica de investigación bibliográfica para cumplir con el primer
objetivo.
Es importante explicar que el proceso de recolección de datos, información y documentos es

complejo, por lo que requiere de una serie de pasos para el correcto manejo de la información
(Matos Ayala, 2020), que se detallan a continuación.
3.3.1 Investigación bibliográfica
Partiendo de la acumulación de referencias se realiza la búsqueda de información misma que se

inicia con la determinación de palabras clave como Software as a service (SaaS), software como
servicio, arquitectura SaaS, ventajas SaaS, características SaaS, computación en la nube,
multiinquilino. Para la investigación se toma en cuenta diferentes sitios web y bases de datos de
artículos científicos como Springer, Knovel, ScienceDirect, Scielo, IEEE Xplore, Google
Académico, siendo seleccionadas las fuentes más relacionadas con el tema de estudio.
En la Tabla 2-3 se pude apreciar los valores de resultados aproximados que se obtuvieron en los
diferentes sitios web y base de datos, tomando en cuenta las palabras clave.
38
Tabla 2-3: Valores aproximados de búsquedas en sitios web y bases de datos
Sitio web / Base de datos Resultados

Google Académico 21 resultados
Springer 29 resultados
Scielo 10 resultados
ScienceDirect 26 resultados
IEEE Xplore 31 resultados
Knovel 16 resultados
Total 133 resultados
Realizado por: Ulcuango, L; Yaguachi, A, 2021
Como se observa en la Tabla 2-3, se obtiene un total de 133 referencias entre sitios web y bases
de datos-. Cada una fue considerada en base al tema y se revisa que la fecha de publicación no
sea mayor a 5 años de antigüedad.
Se clasifica la información relevante sobre el tema, otorgando importancia a la calidad por sobre
la cantidad por lo que se realiza un filtrado de información revisando las referencias
individualmente, analizando títulos, resúmenes, conclusiones y recomendaciones. En base a esto
se definieron los artículos, libros, revistas, etc., que se utilizaron para la elaboración del marco
teórico, haciendo una lectura rápida de cada una de las referencias, verificando que se alineen con
el tema de investigación.
En consecuencia, se obtiene un total 44 referencias entre sitios web y bases de datos, mismas que
fueron plasmadas en el marco teórico y bibliografía del presente trabajo.
3.4 Proceso de gestión de inventarios de la empresa Industria Textil Paoli´s
Con el objetivo de conocer a detalle la funcionalidad de los procesos de gestión de inventarios,

se realiza una entrevista a la propietaria de la empresa Industria Textil Paoli´s. Para este fin se
aplica una entrevista de tipo semiestructurado, ya que es más flexible y permite realizar preguntas
abiertas que ayudan a recolectar de una mejor manera la información de los procesos de gestión
de inventarios de la empresa.
Según (Murillo, 2020), la entrevista se realiza en estos tres momentos definidos:
Momento de preparación
Se define el objetivo de la entrevista, la persona a la que se aplica y posteriormente se formula las

preguntas. En este caso, el objetivo es analizar los procesos de gestión de inventarios de la
39
empresa Industria Textil Paoli´s y se realiza a la gerente propietaria de la empresa, en la ciudad
de Riobamba, el 05 de noviembre del 2020 a las 15:00 horas.
Las preguntas que se formulan con el fin de recolectar toda la información necesaria son:
• ¿Cómo se inicia el proceso de un pedido de un producto?
• ¿De qué forma se realiza el control de productos terminados en bodega?
• ¿De qué forma se realiza el control de materia prima en bodega?
• ¿Cómo se realiza la adquisición de materia prima al proveedor?
• ¿Qué información de los pedidos almacena y qué manera lo realiza?
Momento de desarrollo
La entrevista se lleva a cabo en el lugar y fecha establecida con una duración aproximada de una
hora. Dado que la propietaria tiene conocimiento de todo el manejo del negocio, la entrevista
fluye con agilidad y permite reunir una gran cantidad de información, logrando entender con
claridad cada uno de los procesos de la empresa.
Respuestas obtenidas durante la entrevista
Los resultados que se obtuvieron en la entrevista se encuentran detallados en el Anexo A
Se obtienen resultados satisfactorios que ayudan a conocer el funcionamiento que tiene la

empresa. Con la valoración de las respuestas también se logra identificar ciertos problemas que
son trascendentales para el desarrollo del sistema de gestión de inventarios.
Se aplica la técnica de observación no estructurada para recolectar datos y conocer cómo se

desarrollan los registros de materia prima, productos terminados, gestión de pedidos, y de compra
de materiales. Es posible destacar que la materia prima y los productos terminados que se
almacenan en bodega no tienen un registro de ingresos y salidas de almacenamiento, es así como
al no contar con un control adecuado en esta área se han generado pérdidas de materia prima y de
productos terminados.
La empresa Industria Textil Paoli´s actualmente registra los pedidos de manera manual en un
cuaderno de pedidos, y no se realiza un control de materia prima disponible en stock. Es evidente
que no se tiene un control de la cantidad de productos que se encuentran en el proceso de
confección, así como tampoco se conoce la cantidad de productos terminados que pasan a la
bodega y se desconoce en qué estante específico se encuentran almacenados.
40
Mediante la aplicación del método analítico, la técnica de la entrevista y la observación, se
recolecta la información necesaria para desarrollar un diagrama de procesos que resume el manejo
aplicado en la empresa, así se observa en la Figura 1-3. El proceso inicia cuando un cliente realiza
un pedido de un producto terminado, se verifica su existencia en bodega y de ser el caso que no
exista la prenda pasa al área de producción este proceso es netamente interno de la empresa por
lo cual no se invierne en este como funcionalidad del sistema a desarrollar, en este proceso interno
se verifica la existencia de materia en bodega; de no constar se realiza una compra de materiales
faltantes. Una vez completados los materiales, se pasa a producción y cuando el producto está
terminado, se empaca cada prenda, se almacena en la bodega y el proceso culmina con la entrega
del producto final al cliente.
Figura 1-3: Diagrama de procesos gestión de inventario Industria Textil Paoli´s

Como se observa en la Figura 1-3, en el proceso están involucrados tres tipos de usuarios, de los
cuales dos se convertirán en usuarios del sistema. Cada usuario tiene actividades que están
claramente definidas y en el diagrama de procesos se puede evidenciar un total de 9 actividades,
cada una ligada a un usuario en específico.
3.5 Desarrollo del sistema
Para cumplir con objetivo de desarrollo del sistema de gestión de inventarios para la empresa
Industria Textil Paoli´s, se emplea la metodología SCRUM mediante la implantación de cada una
41
de sus fases que parten de la planificación, desarrollo y finalización (Metodologías ágiles en
Gestión de Proyectos, 2016).
3.5.1 Conceptualización del sistema
Para un mejor entendimiento sobre el flujo de navegación para cada uno de los usuarios del
sistema se ha realizado la conceptualización para cada rol teniendo en cuenta las funciones que
cada uno puede realizar dependiendo del cargo que tenga a su cargo tal es el caso que se ha
definido tres tipos de usuarios para el sistema es así que se tiene un administrador el cual tiene
como funciones la gestión de empresas, suscripciones de un plan que desee contratar en el módulo
SaaS, también se encarga de la gestión de empleados de su empresa, la gestión de pagos de las
suscripciones contratadas y todo lo referente a la gestión de inventarios de su empresa como se
puede evidenciar en la Figura 2-3.
Figura 2-3: Flujo de navegación administrador
En la Figura 3-3 se muestra el flujo de navegación del empleado que previamente fue registrado
por el administrador, este usuario tiene funciones específicas que fueron establecidas por las
reglas del negocio tal es el caso este usuario tiene como funciones a su cargo la gestión de pedidos,
clientes, ubicaciones de productos terminados dentro del almacén así también puede acceder a los
reportes de inventarios.
42
Figura 3-3: Flujo de navegación empleado
La Figura 4-3 muestra el flujo de navegación para el super administrador que este caso se encarga
del manejo del módulo SaaS en la cual tiene como funciones la gestión de servicios y planes que
provee el sitio web también tiene acceso a los reportes de usuarios que han contratado uno o
varios servicios disponibles de la página de igual manera para el caso de los reportes de pagos de
los clientes que hacen uso de uno o varios servicios contratados.
Figura 4-3: Flujo de navegación super administrador

43
3.5.2 Fase de planificación
En esta fase se realizan varios procesos: análisis, definición de requerimientos, estudio de

factibilidad y gestión de riesgos.
3.5.2.1 Requerimientos
En base a los requerimientos proporcionados por el usuario se pueden entender o determinar las
funcionalidades que desea el cliente para su sistema. Para definir los requerimientos del usuario
se realizan 3 reuniones con la gerente de la empresa y se obtienen 19 requerimientos de los cuales
9 son propios del negocio y 10 son para el manejo del sistema SaaS. Todos se documentan
mediante tarjetas de historias de usuarios que se encuentran en el manual técnico.
Con las especificaciones mencionadas por el cliente y por parte de los desarrolladores, se divide
los requerimientos en dos partes, una parte para el módulo SaaS y otra para el módulo de gestión
de inventarios, tal como se aprecia en la Tabla 3-3, y que también se encuentran detalladas en el
manual técnico pag.10-11.
Tabla 3-3: Product Backlog
ID Descripción Prioridad
HT_01 Análisis y definición de la arquitectura del sistema. Alta
HT_02 Análisis y definición del estándar de la interfaz de usuario. Alta
HT_03 Análisis y definición del estándar del estándar de programación. Alta
HT_04 Diseñar el esquema de base de datos. Alta
HT_05 Implementar el diseño de la base de datos. Alta
HT_06 Redactar la documentación Baja
HU_01 Registro de usuarios Alta
HU_02 Consulta de usuarios registrados Alta
HU_03 Eliminar usuarios registrados Alta
HU_04 Autenticación de usuario Alta
HU_05 Control se sesiones activas de un usuario Alta
HU_06 Contratación de servicio de gestión de inventarios Alta
HU_07 Registro de datos de la empresa de un usuario Alta
HU_08 Modificar los datos de una empresa de un usuario Alta
HU_09 Verificación pago de una suscripción de un servicio Alta
HU_10 Notificación de suscripciones por expirar Alta
HU_11 Agregar nuevos planes a un módulo Alta
HU_12 Registro de proveedores de materia prima Alta
HU_13 Modificar proveedores de materia prima Alta
HU_14 Buscar proveedores de materia prima Alta
HU_15 Eliminar proveedores de materia prima Alta
44
HU_16 Registro de materia prima Alta
HU_17 Modificar materia prima Alta
HU_18 Buscar materia prima Alta
HU_19 Eliminar materia prima Alta
HU_20 Ingresar productos terminados Alta
HU_21 Modificar productos terminados Alta
HU_22 Buscar productos terminados Alta
HU_23 Eliminar productos terminados Alta
HU_24 Reporte de proveedores Alta
HU_25 Ingreso de estantes Alta
HU_26 Modificar estantes Alta
HU_27 Buscar estantes Alta
HU_28 Eliminar estantes Alta
HU_29 Reportes de inventarios materia prima Alta
HU_30 Reportes de inventarios productos terminados Alta
HU_31 Reportes de clientes Alta
HU_32 Pruebas del sistema Baja
Realizado por: Ulcuango, Lucero y Yaguachi, Alex, 2021
Como se observa en la Tabla 3-3, se detallan cada una de las historias técnicas del sistema que
son necesarias para que los desarrolladores las ejecuten previo a la realización de las historias de
usuario. Se alcanza un total de 6 historias técnicas (HT) y 32 historias de usuario (HU), cada una
de estas tiene como base los requerimientos que fueron definidos con antelación.
3.5.2.2 Estudio de factibilidad
En el estudio de factibilidad se realiza la recopilación de información sobre el proyecto, previo a

su desarrollo, se determina los recursos tecnológicos, operacionales y económicos que justifican
la puesta en marcha del desarrollo de este trabajo de titulación.
Según el estudio de factibilidad, para el desarrollo del sistema se requiere un costo aproximado
de $3,650.00, tomando en cuenta los costos de software y hardware que en su mayoría son
gratuitos. También se tomó en cuenta el salario mensual de cada uno de los programadores,
mismo que es definido en $450 por 4 meses de trabajo.
Se estima el tiempo de desarrollo del sistema con el método de COCOMO II. En la Tabla 4-3 se
muestra los resultados obtenidos, mismos que fueron de un total de 274 puntos de función, 8.343
líneas de código (SLOC), esfuerzo de 2 personas y un tiempo estimado de 12.8 semanas.
Tabla 4-3: Resultados de estimación COCOMO II

Puntos de Función 274
45
Líneas de Código (SLOC) 8343
Esfuerzo 25.9
Personas 2
Tiempo de Desarrollo 12.8 semanas
Realizado por: Ulcuango, L.; Yaguachi, A., 2021.
𝐸𝑆𝐹𝑈𝐸𝑅𝑍𝑂
𝑇=
𝑁𝑈𝑀 𝑃𝐸𝑅𝑆𝑂𝑁𝐴𝑆
25.9
𝑇=
2
𝑻 =12.95
Con la información obtenida en el estudio de factibilidad detallado en el manual técnico pag.28-

42, se determina que la realización del software de gestión de inventarios es viable y realizable
por los miembros del equipo, desde el punto de vista tecnológico, operacional y económico.
3.5.2.3 Riesgos
Como todo proyecto, es necesario llevar a cabo un análisis y gestión de los posibles riesgos que
implica su ejecución. Este proceso está ligado a fases ordenadas, inicia con la identificación de
cada uno de los riesgos, posteriormente se realiza el respectivo análisis y priorización de estos.
En ese sentido, se identificaron 13 posibles riesgos que se detallan en la Tabla 5-3, los cuales se
pueden presentar en la etapa de desarrollo, provocar retrasos en la entrega del producto y causar
posibles pérdidas económicas. Para una mejor organización, los riesgos son clasificados en tres
categorías que se detallan a continuación:
• Riesgos del Proyecto. Son en total 10 y afectan específicamente el desarrollo del sistema.
• Riesgos Técnicos. Se determinó 2 riesgo de este tipo, que afecta directamente a los recursos
que permiten la realización del proyecto.
• Riesgos del Negocio. Hace referencia a la rentabilidad de la empresa y que por ende puede
perjudicar con mayor impacto el desarrollo del proyecto para esta labor se detectaron 1 riesgos
de este tipo.
Para poder realizar la gestión de los riesgos, se los clasifica según su exposición de mayor a menor
impacto, como se observa en la Tabla 5-3, a continuación, se detallan la priorización de los
riesgos del proyecto:
Tabla 5-3: Priorización de riesgos
IDENTIFICADOR DESCRIPCIÓN RIESGO EXPOSICIÓN VALOR PRIORIDAD
46
Mala recolección de información para
R_03 ALTA 12 1
los requisitos funcionales.
Mala planificación de los recursos a
R_05 emplear y el tiempo requerido para el ALTA 12 1
proyecto.
Cambio de directivos en el
departamento de finanzas, que no está
R_06 ALTA 12 1
de acuerdo con el proyecto o tiene otras
prioridades.
R_07 Incumplimiento de entregables. ALTA 9 2
Falta de personal necesario para el
R_10 ALTA 9 2
Mal diseño y desarrollo de la base de
R_02 ALTA 8 3
datos.
Retiro inesperado de algún integrante
R_09 ALTA 6 4
del equipo de desarrollo.
R_01 Mala estimación de tiempo de proyecto. MEDIA 4 5
No se tiene acceso exitoso a la base de

R_08 datos centralizada existente que requiere MEDIA 4 5
el sistema.
Dificultad para extraer información de
R_12 MEDIA 4 5
la base de datos centralizada.
R_13 Falta de servicios de conectividad. MEDIA 3 3
Desconocimiento de las herramientas de
R_04 BAJA 1 6
desarrollo.
Incomprensión entre los integrantes de
R_11 BAJA 1 6
desarrollo.
Realizado por: Ulcuango, L.; Yaguachi A., 2021.
El objetivo de esta clasificación es diferenciar los riesgos según su nivel de exposición

(importancia) que tengan: alta, media o baja. Es así como se define 7 riegos con prioridad alta, 4
con prioridad media y 2 con prioridad baja que se deben tomar en cuenta durante la etapa de
desarrollo.
En caso de presentarse uno o varios riesgos, es necesario contar con un plan de acción al que debe
alinearse todo el grupo de trabajo para poder sustentar los inconvenientes de manera óptima y
eficiente. Es así como para el proyecto se establecen 13 hojas de gestión, mismas que son
documentadas en el manual técnico pag.11-28 y que cumplen con un orden de prioridad con
estrategias de control y seguimiento.
47
La fase exploratoria es el punto de partida para el desarrollo del software, por ende, es necesario
detallar cada una de las etapas que intervienen; es así como se identificaron 32 requerimientos del
sistema y 6 historias técnicas. Además, mediante el estudio de factibilidad se determinó que el
proyecto es viable y por ende se puede continuar con su ejecución.
3.5.2.4 Planificación
En la fase de planificación se realiza las estimaciones que permiten determinar el tiempo

requerido para el desarrollo del sistema, para lo cual se toman en cuenta todas las variables e
indicadores tales como el tiempo, el esfuerzo y la cantidad de personas.
En la siguiente Tabla 6-3 se muestra los puntos estimados para cada una de las historias de
usuarios, este proceso se lo realizo con la técnica de estimación T-Shirt, las tallas S, M, L, XL, se
toman como referencia la duración 1 día equivalente a 8 horas de trabajo y cada punto representa
4 horas de trabajo.
Tabla 6-3: Técnica de estimación T-Shirt

Iteración Talla Puntos
3/4 S 3
1/2 M 5
1 L 10
2 XL 20
Realizado por: Ulcuango, L.; Yaguachi A., 2021.
Tabla 7-3: Planificación sprint
Fecha Fecha Duración

Sprint Tarea
Inicio Fin Horas
Sprint 1 16/11/20 27/11/20
HT_01 Análisis y definición de la
16/11/20 27/11/20 40
arquitectura del sistema.
HT_02 Análisis y definición del estándar de

16/11/20 27/11/20 40
la interfaz de usuario.
HT_03 Análisis y definición del estándar de

16/11/20 27/11/20 40
programación.
HT_04 Diseñar el esquema de base de
16/11/20 27/11/20 40
datos.
Sprint 2 30/11/20 11/12/20
48
HT_05 Implementar el diseño de la base de
30/11/20 11/12/20 40
datos.
HT_06 Redactar la documentación 30/11/20 11/12/20 40
HU_01 Registro de usuarios. 30/11/20 11/12/20 20
HU_02 Consulta de usuarios registrados. 30/11/20 11/12/20 20
HU_03 Eliminar usuarios registrados. 30/11/20 11/12/20 20
HU_04 Autenticación de usuario. 30/11/20 11/12/20 20
Sprint 3 14/12/20 25/12/20
HU_05 Control se sesiones activas de un
14/12/20 25/12/20 20
usuario
HU_06 Contratación de servicio de gestión
14/12/20 25/12/20 20
de inventarios.
HU_07 Registro de datos de la empresa de
14/12/20 25/12/20 20
un usuario.
HU_08 Modificar los datos de una empresa
14/12/20 25/12/20 20
de un usuario.
HU_09 Verificación pago de una
14/12/20 25/12/20 20
suscripción de un servicio.
HU_10 Notificación de suscripciones por
14/12/20 25/12/20 20
expirar.
Sprint 4 28/12/20 08/01/21
HU_11 Agregar nuevos planes a un
28/12/20 01/01/21 20
módulo.
HU_12 Registro de proveedores de materia
28/12/20 01/01/21 20
prima.
HU_13 Modificar proveedores de materia
28/12/20 01/01/21 20
prima.
HU_14 Buscar proveedores de materia
04/01/21 08/01/21 20
prima.
HU_15 Eliminar proveedores de materia
04/01/21 08/01/21 20
prima.
HU_16 Registro de materia prima. 04/01/21 08/01/21 20
HU_17 Modificar materia prima. 04/01/21 08/01/21 20
Sprint 5 11/1/21 22/01/21
49
HU_18 Buscar materia prima. 11/1/21 15/01/21 20
HU_19 Eliminar materia prima. 11/1/21 15/01/21 20
HU_20 Registro de productos terminados. 18/1/21 22/01/21 20

HU_21 Modificar productos terminados. 18/1/21 22/01/21 20
HU_22 Buscar productos terminados. 18/1/21 22/01/21 20
HU_23 Eliminar productos terminados. 18/1/21 22/01/21 20
Sprint 6 25/1/21 5/02/21
HU_24 Reporte de proveedores 25/01/21 05/02/21 20
HU_25 Registro de estantes. 25/01/21 05/02/21 20
HU_26 Modificar estantes. 25/01/21 05/02/21 20
HU_27 Buscar estantes. 25/01/21 05/02/21 20
HU_28 Eliminar estantes. 25/01/21 05/02/21 20
HU_29 Reportes de inventarios materia
25/01/21 05/02/21 20
prima.
HU_30 Reportes de inventarios productos
25/01/21 05/02/21 20
terminados.
HU_31 Reportes de clientes 25/01/21 05/02/21 20
Sprint 7 08/02/21 15/02/21

HU_32 Pruebas del sistema. 08/02/21 15/02/21 80
Total, de horas 1020
Realizado por: Ulcuango, L.; Yaguachi A., 2021
Según lo planificado, el desarrollo del sistema inicia a partir del 16/11/2020 y culmina el
15/02/2021 como se muestra en la Tabla 7-3. En este contexto, se establecen 32 historias de
usuario y 6 historias técnicas del sistema que se dividen en 7 Sprint, cada uno equivalente a dos
semanas de trabajo con un total de 255 puntos lo que da como resultado 1020 horas.
3.5.3 Fase de desarrollo
Se analizó los estándares de programación, interfaz de usuario, arquitectura del sistema y se

realizó además el diseño de la base de datos.
3.5.3.1 Estándar de programación
Para la determinación del estándar de programación se estudian las herramientas que se

implementarán, como MySQL, que por defecto usa el estándar de programación snake_case. Así
50
mismo se establece el estándar de programación de Laravel, que permite normalizar parámetros
tanto en el código Laravel, archivos HTML y los aspectos relacionados con la base de datos. Los
dos estándares de escritura y programación permiten que la codificación sea más comprensible
por los desarrolladores, teniendo un estilo único a seguir.
3.5.3.2 Arquitectura del sistema
La siguiente Figura 5-3 se detalla la arquitectura, organización de los componentes y la relación

entre cada uno de estos, la estructura y el comportamiento en base a un tipo de arquitectura. Es
así como se plantea la arquitectura de n capas, misma que permite la autonomía en cada uno de
los componentes y facilita a la persona trabajar en la interfaz de usuario, mientras las demás capas
se centraran en procesos específicos.
Figura 5-3: Arquitectura del sistema
3.5.3.3 Interfaz de usuario
Para el análisis de la interfaz de usuario se establece un estándar de ubicación general de los

componentes gráficos como botones, imágenes, texto y tablas, para lo cual se realizan bosquejos
de las interfaces generales del sistema.
51
Figura 6-3: Bosquejo pantalla principal
En la Figura 6-3 se muestra el bosquejo de la pantalla principal del módulo SaaS con sus
respectivos elementos. En la parte superior izquierda se mostrará el logo de la empresa, seguido
del nombre y al lado derecho el botón para iniciar sesión. En el área central se visualizará una de
fondo e información que se considere necesaria.
Figura 7-3: Bosquejo pantalla para reportes
52
La Figura 7-3 es el bosquejo de la pantalla para los reportes de inventarios. En el encabezado se
despliega el nombre de la empresa, en la parte superior izquierda se coloca su logo y el resto del
contenido muestra una tabla con los campos que contiene cada reporte.
Figura 8-3: Bosquejo pantalla general
En este bosquejo de la Figura 8-3 se visualiza la pantalla general del módulo de inventarios, en
la cual el panel izquierdo muestra todas las opciones que el sistema contenga.
Los bosquejos de pantalla presentados son una idea de cómo se diseñará la interfaz de usuario
tanto para el módulo SaaS como el de inventarios, dichos bosquejos representan de forma general
como se mostrarán todos los reportes de inventario, también la pantalla general muestra por
defecto al iniciar sesión el listado de productos.
3.5.3.4 Base de datos
Mediante el análisis previo de los procesos que se gestionan en la empresa Industria Textil Paoli´s,
se realiza el diseño de la base de datos partiendo del diseño relacional, continuamente con el
diagrama de entidad relación y para finalizar en el diagrama físico que se muestra una sección de
la base de datos misma que se detalla en la Figura 9-3 y 10-3 correspondientes al módulo SaaS
y gestión de inventarios. Los diagramas completos de la base de datos se encuentran en el manual
técnico pag.67-68.
53
Figura 9-3: Modelo físico módulo inventarios
54
Figura 10-3: Modelo físico módulo Software como servicio (SaaS)
Tomando en cuenta los dos módulos, se obtuvieron 29 tablas que se implementan en el gestor de
bases de datos MySQL. Cabe mencionar que el diccionario correspondiente a la base de datos se
encuentra detallado en el manual técnico pag.70-82.
3.5.4 Historias de usuario
Las historias de usuario son formas rápidas de administrar los requisitos de las personas, pero sin
tener que elaborar una gran cantidad de documentos formales ni requerir mucho tiempo para
administrarlos (Suaza, García, Jaramillo, 2015). Son descripciones cortas y simples que siguen la
plantilla cómo (rol del usuario), quiero (objetivo), para poder (beneficio) (Salazar, 2020).
55
Las Historias de usuarios están descritas como se muestra a continuación y en la Tabla 8-3 se
indica el formato a seguir.
• Número. Las historias técnicas se identifican con el prefijo HT, seguido de la numeración y
las historias de usuario con el prefijo HU seguido de la numeración.
• Nombre. Es el nombre que se asigna para describir cada una de las historias de usuario.
• Descripción. Se resume brevemente lo que se va a desarrollar en la historia de usuario.
• Usuario. Indica el usuario para el que está relacionada la actividad.
Tabla 8-3: Historias de Usuario
HISTORIA DE USUARIO
Número: HU_01 Nombre: Registro de usuarios
Modificación de metáfora número:
Usuario: Administrador Sprint Asignado: 2
Prioridad en Negocio: Alta Puntos Estimados: 10
Riesgo en desarrollo: Bajo Puntos Reales: 10
Descripción: Como administrador quiero registrar usuarios al sistema para poder tener un
registro de todos los usuarios del sistema.
Observaciones:
3.5.5 Historias técnicas
Las historias técnicas cuentan con la misma estructura que una historia de usuario, ya que el
tratamiento es parecido.
3.5.6 Tareas de ingeniería
Cada una de las historias técnicas y de usuario cuentan con tareas de ingeniería que se realizan
para dar cumplimiento a los requerimientos. En ese sentido, la siguiente Tabla 9-3 muestra el
formato a seguir para las tareas de ingeniería.
Tabla 9-3: Tareas de Ingeniería
TAREA DE INGENIERÍA
Historia técnica: HU_01 Registro de usuarios.
Número de Tarea: TI_01. Nombre de Tarea: Registro de usuarios
Tipo de Tarea: Desarrollo. Puntos Estimados: 5
Fecha Inicio: 23-11-2020 Fecha Fin: 25-11-2020
56
Programador Responsable: Alex Yaguachi
Descripción: Registrar los usuarios al sistema
3.5.7 Pruebas de aceptación
Cada historia de usuario e historia técnica tiene una o más pruebas de aceptación como se muestra
en la Tabla 10-3, que el cliente debe evaluar después de desarrollar la historia. Si la historia de
usuario satisface los requisitos del cliente, se define como una prueba exitosa, de lo contrario,
debe modificarse para cumplir con las expectativas del usuario.
Tabla 10-3: Pruebas de Aceptación
PRUEBA DE ACEPTACIÓN
Código: PA_01_HU_01 Historia de Usuario: HU_01 registro de usuarios
Nombre: registro de usuarios

Responsable: Lucero Ulcuango Fecha:
Descripción: Registrar usuarios al sistema
Condiciones de Ejecución: Que ya este creado el acceso a datos y la interfaz de usuario.
Pasos de ejecución:
• Acceder al sistema
• Ir a la opción de agregar nuevo usuario
• Ingresar los datos de registro de un usuario
• Guardar los datos
• Verificar el usuario registrado
• Salir
Resultado esperado: usuario nuevo registrado exitosamente
Evaluación de la prueba: Exitosa
Se obtuvieron un total de 31 historias de usuario finalizadas, por cada historia se generó dos tareas
de ingeniería teniendo un total de 3 pruebas de aceptación para cada historia con su respectiva
tarea, en consecuencia, se realizaron 62 tareas de ingeniería y un total de 93 pruebas de aceptación
y toda esta información se encuentra detallada en el manual técnico pag.52-177.
57
3.6 Fase de finalización
Al llegar a esta fase de la metodología SCRUM implica que el sistema desarrollado cumpla con
todos los requerimientos establecidos por el usuario, para ello se establecen reuniones con el
cliente para la revisión donde se hace una demostración de la tal manera que se pueda determinar
si se cumple con las expectativas del usuario.
3.6.1 Burndown chart
Para poder verificar el avance de las historias de usuario y técnicas se aplica el Burndown chart.
A continuación, se presenta el progreso del proyecto en la Figura 11-3: cada uno de los Sprints
se muestran en el eje X y los puntos de estimación se encuentra en el eje Y. La línea de color azul
indica el avance ideal del proyecto mientras que la línea naranja muestra el avance real.
90
75
60
45
30
15
0
Sprint Sprint Sprint Sprint Sprint Sprint Sprint
1 2 3 4 5 6 7
Puntos estimados 40 40 40 40 40 45 80
Puntos reales 40 43 42 44 46 47 84
Puntos estimados Puntos reales
Gráfico 1-3: Burndown Chart
Como se observa, el tiempo del sprint 1 es mayor ya que al iniciar con la fase de desarrollo se
presentaron varios inconvenientes, entre ellos el desconocimiento de las tecnologías que se
utilizan para la creación del sistema.
Además, se concluyó con el desarrollo de 31 historia de usuario, haciendo referencia a que una
de las funcionalidades no se desarrolló ya que actualmente a empresa ha cerrado sus almacenes
por lo tanto la funcionalidad de ubicación en estantes ya no es necesaria, esto se debe a la
consideración del nuevo dueño de la empresa ya que hubo un cambio de personal.
3.7 Evaluación de la portabilidad
Las subcaracterísticas para evaluar portabilidad del sistema son tomadas de la norma ISO/IEC
25010 así también se utilizan de las fórmulas de las métricas externas de portabilidad tomadas de
58
la ISO/IEC 9126 que hace referencia principalmente a la adaptabilidad e instabilidad
(Guamangate, Caisaluisa y Cerda, 2021), los parámetros a medir se muestran en la Tabla 11-3.
Tabla 11-3: Características y métricas relacionadas con la portabilidad
Subcaracterísticas de la ISO/IEC
Métricas de la ISO /IEC 9126
25010:2011
Adaptabilidad Adaptabilidad a distintos dispositivos
Facilidad de instalación
Capacidad de ser instalado
Facilidad de reinstalación
Capacidad de ser reemplazado Uso continuo de los datos
Fuente:(Guamangate, Caisaluisa y Cerda, 2021)
Las métricas y fórmulas que nos permiten obtener un valor cuantitativo de cada una de las
subcaracterísticas a evaluar se muestran en la Tabla 12-3, así también se puede observar el valor
de x que cuanto más cercano a uno es mejor el valor de este se obtiene aplicando la fórmula para
cada caso de estudio.
Tabla 12-3: Métricas y fórmulas para medir portabilidad
Subcaracterística Métricas Fórmula Valores de X
X = 1-A/B
B= Número de dispositivos
especificados en los que el 0≤X≤1
Adaptabilidad a producto software debe ser
Adaptabilidad adaptable. Cuanto más cercano a
distintos dispositivos
1 mejor
A= Número de dispositivos en los
que la adaptabilidad no es del
todo satisfactoria.
X = A/B
A= Número de veces que el

usuario ha tenido éxito en 0≤X≤1
Capacidad de ser Facilidad de cambiar la instalación Cuanto más cercano a
instalado instalación
B= Número de veces que el 1 mejor
usuario lo ha intentado, haya

tenido éxito o no
59
X=1-A/B
0≤X≤1
Facilidad de A= Numero de fallos del usuario
al intentar reinstalar de software Cuanto más cercano a
reinstalación
1 mejor
B= Numero de intentos
X = A/B
A = Numero de datos que se

usaban en el software anterior y
que se pueden seguir usando en el 0≤X≤1
Capacidad de ser Uso continuo de los nuevo software Cuanto más cercano a
reemplazado datos
B = Numero de datos que se 1 mejor
usaban en el software anterior y

de los cuales se planea su
reutilización en el nuevo software
Fuente:(Guamangate, Caisaluisa y Cerda, 2021)
Para poder medir si el sistema es responsivo se evaluará la adaptabilidad a diferentes dispositivos

tomando los criterios de adaptabilidad para sistemas web responsivos con diseño fluido con
cuadrículas flexibles a los diferentes dispositivos, además las imágenes, objetos también debe ser
flexibles, se verificará si es responsive mediante la herramienta de desarrollo de Microsoft Edge.
3.8 Evaluación de eficiencia en función del tiempo
En esta sección se evalúan los tiempos de generación de reportes de inventarios, a través de un

estudio explicativo por lo cual se platea una hipótesis causal.
3.8.1 Formulación de hipótesis
El tipo de hipótesis que se analiza para obtener el nivel de eficiencia en función del tiempo es de
tipo causal, ya que no solo establece relaciones entre las variables sino la naturaleza causal de las
mismas. Es decir, se crea un efecto que repercute de una de estas a la otra, de modo tal que se
establece un margen de incidencia (Espinoza Freire, 2018).
Hipótesis nula (H0)
La automatización del proceso de gestión de inventarios no influye en el tiempo de generación de

los reportes sin automatizar.
Hipótesis alternativa (HA)
60
La automatización del proceso de gestión de inventarios influye en el tiempo de generación de
los reportes sin automatizar.
Las hipótesis se formulan de forma que se identifique si existe una diferencia significativa en los
tiempos de ejecución de los procesos manuales con respecto a los automatizados.
3.8.2 Tamaño de la muestra
Para el cálculo del tamaño de la muestra se tiene en cuenta que la población es de tipo infinita o
desconocida, ya que se considera que la población es el número de veces que se puede ejecutar
los reportes, para este cálculo se sigue el siguiente procedimiento:
Ecuación 1-3: Fórmula del tamaño muestral población infinita

Fuente: (Murray R. y Larry J., 2005)
Donde:
n: tamaño muestral
n: tamaño de la población
z: valor correspondiente a la distribución de gauss, Zα=0.05= 1.96 y Zα=0.01= 2.58
p: prevalencia esperada del parámetro a evaluar, en caso de desconocerse (p = 0.5), que hace
mayor el tamaño muestral
q: 1-p (si p= 70%, q = 30%)
i: error que se prevé cometer si es del 10%, i = 0.1
1,9599642 × 0,5 × 0,5

𝑛=
0,12
𝑛 = 96,0365
𝑛 = 96
A partir de un muestreo simple con población infinita, siguiendo el procedimiento se ha obtenido
un tamaño de muestra de 96. El valor obtenido se dividirá en el total de 7 reportes que se obtienen
del sistema y, en consecuencia, se tomarán 14 muestras para cada uno.
Los reportes que serán parte del estudio son únicamente los que se generan en el módulo de
gestión de inventarios y se mencionan a continuación:
• Reporte de clientes
61
• Reporte de productos terminados
• Reporte de materia prima
• Reporte de productos en proceso
• Reporte de pedidos de clientes
• Reporte de pedidos de materia prima
• Reporte de proveedores
3.8.3 Recolección de datos
Para recopilar datos que permitan evaluar la eficiencia en función del tiempo de la generación de
los reportes de inventario, se utiliza la técnica de la observación y, mediante el uso de un
cronómetro se el tiempo que se tarda en obtener los reportes tanto manuales como automatizado.
Para consolidar los datos de forma manual, el usuario debe llenar las hojas de reportes
manualmente; mientras que, para el caso de los datos automatizados, se utiliza el aplicativo web
y se ejecutan los mismos procesos para obtener los reportes.
62
CAPÍTULO IV
4 RESULTADOS
En este capítulo se muestran los resultados que se obtuvieron de cada uno de los objetivos. Para
la evaluación de las variables de calidad, se utilizó la norma ISO/IEC 25010, adaptando las
métricas de la norma ISO/IEC 9126, lo que permitió obtener resultados del nivel de portabilidad
y eficiencia en función del tiempo del sistema de gestión de inventarios para la empresa Industria
Textil Paoli´s.
4.1 Nivel de portabilidad del sistema desarrollado

Para evaluar el nivel de portabilidad del sistema de gestión de inventarios, se deben crear
parámetros y métricas tomadas de la familia de la norma ISO/IEC 25000, para que mediante su
aplicación se obtenga un porcentaje satisfactorio para sistema web desarrollado.
4.1.1 Especificación de las características y subcaracterísticas
Para medir el nivel de portabilidad se utilizó el estándar de calidad ISO/IEC 25010, que detalla
las subcaracterísticas de portabilidad, como adaptabilidad, capacidad de instalación y la capacidad
de ser reemplazado. Además, se utilizó las métricas especificadas en la norma ISO/IEC 9126 y
los niveles de puntuación presentados en la norma ISO/IEC 25040 para la evaluación.
Esta investigación tiene en cuenta dos características principales a medir: la adaptabilidad y la

capacidad de ser reemplazado; no se evalúa la capacidad de instalación ya que, al ser un sistema
web, no requiere dicha evaluación.
4.1.2 Descripción de niveles de puntuación para la calidad externa
Se tomó como referencia la norma ISO/IEC 25040 ya que permite instanciar rangos de medición
como se indica en la Tabla 1-4.
Tabla 1-4: Niveles de puntuación final para calidad externa

Valor de medición Nivel de Puntuación Grado de satisfacción
0.90 - 1.00 Cumple con los requisitos Muy satisfactorio
0.60 - 0.89 Aceptable Satisfactorio
0.30 - 0.59 Mínimamente aceptable No satisfactorio
0.00 - 0.39 Inaceptable No satisfactorio
Fuente: (Reina y Patiño, 2019).
Con el valor cuantitativo obtenido de las mediciones se puede establecer la relación cualitativa,
como se observa en la Tabla 1-4, siendo, el rango inaceptable, los valores que no cumplen con el
63
requerimiento mínimo establecido; y el rango objetivo, los valores deseados, otorgando un
equilibrio (Reina y Patiño, 2019, p.114).
4.1.3 Nivel de importancia
En la Tabla 2-4 se presenta una definición del nivel de importancia que se aplicará a las
características del sistema a evaluarse.
Tabla 2-4: Definición del nivel de importancia
Nivel de Porcentaje referencial del

Simbología Significado
importancia nivel de importancia
El grado de importancia de la característica y

Alto A 70% - 100% subcaracterística es alto por ende se realizará las
mediciones
La característica y subcaracterística no es tan

Medio M 25% - 69% relevante, pero puede o no ser medida
dependiendo del criterio del evaluador
La característica y subcaracterística no tiene

Bajo B 1% - 24%
relevancia y no será medida.
Este valor se dará a la característica y

No aplica NA 0% subcaracterística que no se pueden medir
dependiendo de diferentes factores
Fuente:(Chisaguano Balseca, 2014).
La Tabla 3-4 muestra el nivel de importancia de cada una de las subcaracterísticas de

portabilidad, para este caso no se mide la capacidad de ser instalado por lo que el nivel de
importancia es del 0% lo cual indica que no aplica, para medir adaptabilidad se le asigna un
porcentaje de 75% y la capacidad de ser reemplazado con un 25% lo que indica un nivel alto y
medio respectivamente.
Tabla 3-4: Nivel de importancia para las características de calidad externa

Nivel de importancia características de calidad externa/interna
Características Subcaracterística Nivel de importancia
Adaptabilidad A
Portabilidad Capacidad de ser instalado NA
Capacidad de ser reemplazado M
Realizado por: Ulcuango L.; Yaguachi A., 2021
64
4.1.4 Ponderación de las características
En la Tabla 4-4 se asigna el porcentaje de importancia para cada métrica a evaluar, se le asigna
un porcentaje de 75% a adaptabilidad ya que se considera de mayor importancia en la evaluación,
la capacidad de ser instalado no se toma en cuenta por lo que se le asigna un valor de 0% y se
asigna el 25% a la capacidad de ser remplazado el mismo que hace referencia al uso continuo de
los datos.
Tabla 4-4: Ponderación en porcentajes para calidad externa

Ponderaciones características de calidad externa/interna
Características Subcaracterística Nivel de importancia Ponderación
Adaptabilidad A 75%
Portabilidad Capacidad de ser instalado NA 0%
Capacidad de ser reemplazado M 25%
La Tabla 5-4 muestra los subcriterios de evaluación para adaptabilidad misma que hace
referencia a la adaptabilidad a diferentes dispositivos puntuando con un valor de 1 cuando cumple
con todos los componentes o criterios para aplicaciones web responsivas y 0 cuando no se cumple
en su totalidad con dichos criterios.
Tabla 5-4: Subcriterios para evaluar adaptabilidad
Puntaje
Criterio Subcriterio
Cumple No cumple
Adaptabilidad Web responsive 1 0
4.1.5 Resultados de evaluación
Se obtiene los resultados de adaptabilidad a diferentes dispositivos marcando con visto si cumple
y con una x si no cumple para cada uno de los componentes para aplicaciones web responsivas,
la aplicación web se evaluó en el navegador Google Chrome en todos los dispositivos, para este
los dispositivos deben tener un diseño fluido, las imágenes, objetos también deben ser flexibles y
la fuente tipográfica debe ser visible para cualquier tamaño de pantalla, si cumple con todos los
requerimientos se le da un puntaje de 1 o de cero si no cumple con todos los criterios como se
muestra en la Tabla 6-4.
Tabla 6-4: Resultados de adaptabilidad a diferentes dispositivos
Componentes para web responsive
65
Diseño Multimedia Fuentes tipográficas
Dispositivos Puntaje
fluido flexible con valores relativos
Ordenadores ✓ ✓ ✓ 1
Smartphone ✓ ✓ ✓ 1
Smart TV ✓ ✓ ✓ 1
Tablet ✓ X ✓ 0
La Tabla 6-4 muestra los resultados de medir adaptabilidad en 4 diferentes dispositivos

tecnológicos, se obtuvo un total de tres dispositivos adaptables satisfactoriamente que cumplen
con todos los componentes para tener una aplicación web responsiva o adaptable, y se tiene un
dispositivo no del todo satisfactorio que no cumple con todos los criterios para ser una aplicación
responsiva, por lo que se le asigna una puntuación de cero.
Tabla 7-4: Resumen de resultados

Resumen de criterios de medir adaptabilidad
Dispositivos Diseño flexible Multimedia flexible Fuentes tipográficas
Las imágenes de registro e inicio
El diseño de la aplicación
de sesión se adaptan El tamaño y tipo de letra es
web responde y se adapta a
Ordenadores correctamente a ordenador visible y legible en la pantalla del
las dimensiones del
mostrándose en el centro de la ordenador.
ordenador.
pantalla.
El diseño de la aplicación se
Las imágenes y tablas se adaptan El tamaño de letra y tipo de letra
adapta a las dimensiones de
al ancho y largo del smartphone es visible y legible en la pantalla
Smartphone un smartphone mostrando un
ocupando todo el espacio de la se adapta a la resolución del
scroll que permite ver todo el
pantalla. dispositivo.
contenido del aplicativo.
El diseño de la aplicación se La imágenes y tablas se adaptan
El tamaño de letra y tipo de letra
adapta correctamente al correctamente en la pantalla y a la
Smart TV se adapta correctamente a la
dispositivo mostrando todos resolución de está mostrando
resolución de la pantalla.
los elementos del aplicativo. claramente todos los elementos.
Las imágenes no se adaptan al
El diseño de la aplicación se tipo de pantalla, la imagen de
adapta al tamaño de la inicio se muestra cortada a la El tamaño de letra y tipo de letra
Tablet pantalla, muestra un scroll mitad y se refleja en el centro de se adapta correctamente a la
para una mejor visualización la pantalla, los campos de los resolución de la pantalla.
de los elementos. formularios y tablas no presentan
inconvenientes.
La Tabla 7-4 se describe de manera breve como se presentó el aplicativo desarrollado en los
dispositivos de estudio, se puede evidenciar que en 3 dispositivos como ordenador, smartphone,
Smart tv si se cumple correctamente los criterios para web responsiva ya que los elemento del
diseño, multimedia y tipografía se adaptan a la resolución de pantalla de cada dispositivo, también
se evidencia que en una Tablet se presentó una falla en cuanto a multimedia ya que la imagen de
66
inicio de sesión se muestra a la mitad es decir no se muestra de manera completa ni se adapta al
tamaño de la pantalla es por ellos que al no cumplir con todos los criterios se le asignó una
puntuación de cero.
Tabla 8-4: Resultados del cálculo de portabilidad
Subcaracterísticas Métricas Fórmula Valor de X
Adaptabilidad Adaptabilidad en distintos dispositivos X = 1 - A/B X = 0.75
Capacidad de ser reemplazado Uso continuo de los datos X = A/B X=1

Los resultados obtenidos para cada subcaracterística de portabilidad seleccionada se muestran en

la Tabla 8-4, se obtuvo un valor X de 0.75 para adaptabilidad en diferentes dispositivos lo que
indica que tiene un nivel de puntuación aceptable y un grado satisfactorio, además se obtuvo un
valor de X = 1 para la capacidad de ser reemplazado con un nivel de puntuación que muestra
cumple con los requisitos y con un grado muy satisfactorio, el nivel de puntuación final se muestra
en la Tabla 1-4.
Tabla 9-4: Valores porcentuales para los factores de portabilidad
Factor de portabilidad Valor porcentual %

Adaptabilidad en distintos dispositivos 75%
Capacidad para ser reemplazado 100%
TOTAL 87,5%
Los resultados finales determinan que la aplicación web de gestión de inventarios bajo el modelo
SaaS alcanza un porcentaje global de 87.5% de portabilidad como se observa en la Tabla 9-4,
este porcentaje se ha obtenido tras calcular las subcaracterísticas utilizando las métricas ISO/IEC
25010 adaptadas a las métricas ISO/IEC 9126.
4.2 Criterios de evaluación para eficiencia

Con la finalidad de evaluar la eficiencia en función del tiempo del sistema desarrollado de gestión
de inventarios bajo el modelo de software como servicio (SaaS), se establece los indicadores
tomados como referencia de la norma ISO/IEC 9126.
La Tabla 10-4 muestra la variable dependiente que se ha identificado, así también muestra el
indicador, descripción, técnica y herramientas que se utilizara para la recolección de los datos.
Tabla 10-4: Variable dependiente
Variable Tipo Indicador Descripción Interpretación Técnica Herramienta
67
¿Qué tan rápido Influye el
se pueden tiempo de Cronómetro, modelo
Tiempo de Observación
Eficiencia Dependiente obtener los obtención de estadístico y
respuesta directa
reportes de reportes de R Studio
inventarios? inventario
La Tabla 11-4 muestra la variable independiente que se ha identificado, así también muestra la
descripción, técnica y herramientas que se utilizó para el desarrollo del sistema.
Tabla 11-4: Variable independiente
Variable Tipo Descripción Interpretación Técnica Herramienta
Laravel
¿Influye los tiempos de
Automatizar el proceso Node Js
Sistema web Independiente obtención de reportes de SCRUM
de gestión de inventarios Angular
inventario?
PHPStorm
4.2.1 Análisis descriptivo
Para el análisis de los tiempos de obtención de los reportes de inventarios ya planteados en la

muestra se realiza un análisis descriptivo e inferencial a cada uno de los reportes, para el presente
análisis la palabra reporte se utiliza para referirse tanto al registro manual que lleva la empresa
sin sistema como a los resultados que se obtienen con el software.
4.2.1.1 Reporte de clientes
Para evaluar la eficiencia del tiempo de obtención del reporte de clientes, se toma el tiempo antes
y después de implementar el sistema desarrollado utilizando un cronómetro, el tiempo obtenido
se expresa en segundos, como se observa en la Tabla 12-4.
Tabla 12-4: Tiempos de obtención del reporte de clientes
Nro repeticiones Antes del sistema Después del sistema

1 313,20 47,41
2 303,00 42,45
3 250,20 46,28
4 246,60 43,59
5 301,20 44,43
6 325,80 48,56
7 316,20 42,19
8 369,60 42,42
9 321,60 43,52
68
10 384,60 44,63
11 382,20 44,07
12 304,20 42,50
13 315,00 43,41
14 393,00 41,67
4.2.1.2 Reporte de existencia de productos terminados
Evaluación de la eficiencia del tiempo de obtención del reporte de productos terminados se toma
en cuenta los tiempos antes y después de emplear el sistema mediante el uso de un cronómetro,
los tiempos que se obtienen se encuentran expresados en segundos como se puede evidenciar en
la Tabla 13-4.
Tabla 13-4: Tiempos de obtención del reporte existencia de productos

terminados

1 606,60 47,75
2 575,40 54,33
3 558,00 59,97
4 562,20 51,40
5 450,00 47,88
6 615,60 43,46
7 629,40 41,43
8 514,80 51,80
9 506,40 46,01
10 437,40 59,00
11 603,60 43,53
12 484,20 52,58
13 630,00 41,02
14 486,60 41,36
4.2.1.3 Reporte de existencias de materia prima
Para poder evaluar la eficiencia del tiempo de obtención del reporte de existencias de materia
prima se toma en cuenta el tiempo antes y después de implementar el sistema desarrollado
mediante el uso de un cronómetro, los tiempos se expresan en segundo como se evidencia en la
Tabla 14-4.
69
Tabla 14-4: Tiempos de obtención del reporte de existencias de materia
prima

1 1044,00 59,00
2 906,00 46,25
3 1089,60 56,82
4 682,80 44,98
5 629,40 47,06
6 724,80 44,19
7 1213,20 53,35
8 1105,20 46,80
9 669,60 47,28
10 961,20 56,47
11 909,00 49,32
12 1020,60 47,25
13 682,80 54,02
14 807,60 48,91
4.2.1.4 Reporte de productos en proceso
la Tabla 15-4.
Tabla 15-4: Tiempos de obtención del reporte de productos en proceso

1 790,80 53,84
2 930,60 41,24
3 502,80 52,41
4 812,40 44,11
5 631,80 54,45
6 513,60 59,74
7 1051,20 41,97
8 977,40 58,90
9 1086,00 58,39
10 616,80 50,17
11 1042,20 43,29
12 784,80 53,46
13 915,00 54,93
70
14 868,80 44,58
4.2.1.5 Reporte de pedidos de productos terminados
la Tabla 16-4.
Tabla 16-4: Tiempos de obtención del reporte de pedidos de productos

terminados

1 667,80 55,93
2 1929,40 39,73
3 2054,40 39,87
4 1566,60 57,34
5 1291,20 41,90
6 1030,20 49,30
7 1873,80 46,61
8 661,20 38,09
9 1805,40 45,43
10 684,00 40,65
11 2123,40 40,17
12 849,60 51,95
13 1653,00 49,34
14 1643,40 47,07
4.2.1.6 Reporte de pedidos de materia prima
la Tabla 17-4.
Tabla 17-4: Tiempos de obtención del reporte de pedidos de materia prima

1 1863,60 47,28
2 1573,20 49,78
3 723,60 51,16
71
4 1752,00 51,92
5 1509,60 45,73
6 2298,00 46,15
7 2046,00 45,20
8 1052,40 50,91
9 748,80 57,33
10 993,60 50,89
11 856,20 45,54
12 1090,20 48,10
13 993,60 55,29
14 2010,60 47,87
4.2.1.7 Reporte de proveedores
la Tabla 18-4.
Tabla 18-4: Tiempos de obtención del reporte de proveedores

1 1172,40 50,62
2 1944,00 45,36
3 1570,80 40,41
4 1032,00 58,99
5 1269,60 46,41
6 1102,80 47,80
7 1328,40 42,35
8 1509,00 45,67
9 1744,20 42,36
10 1625,40 46,81
11 972,00 45,61
12 1455,60 50,33
13 1516,80 40,93
14 924,60 50,56
72
4.2.2 Test para la distribución normal
Se utilizó la prueba de Shapiro-Wilk utilizando la herramienta R Studio para determinar si existe

una distribución normal de los datos y también para comprobar si hay valores atípicos con el fin
de realizar una prueba t de muestras pareadas.
Se plante la hipótesis siguiente:
Ha: Las variables están normalmente distribuida
Ho: Las variables no están normalmente distribuida
Rechazamos la Ho si el p-valor es mayor de 0.05, para este caso se rechaza la hipótesis nula y se
determina que los datos están normalmente distribuidos tanto para los valores de antes y después
del sistema como se puede evidenciar en la Figura 1-4, se realizó el mismo proceso para
determinar normalidad de los datos para todos los reportes.
Figura 1-4: Test de Shapiro-Wilk para distribución normal
4.2.3 Prueba de hipótesis
Teniendo en cuenta el nivel de significancia de α = 0.05, con la ayuda de este test podremos
aceptar o rechazar la hipótesis nula, por lo que también es necesario seguir cada uno de los pasos
para realizar la prueba de hipótesis como son: Planteamiento o formulación de la hipótesis nula y
alterna, determinar el nivel de significancia, elegir el método adecuado, calcular el valor de p y
tomar la decisiones respecto a la aceptación o rechazo de la hipótesis que se ha planteado para
cada uno de los reportes de estudio (Dagnino S., 2014).
4.2.3.1 Análisis de resultados para el reporte de clientes
• Paso 1: Planteamiento de la hipótesis

73
H0: La automatización del proceso de gestión de inventarios no influye en el tiempo de
generación del reporte de clientes sin automatizar.
HA: La automatización del proceso de gestión de inventarios influye en el tiempo de generación

del reporte del reporte de clientes sin automatizar.
• Paso 2: Especificación del nivel de significancia
El nivel de significancia es del 5% equivalente a 0.05, lo que garantiza un nivel de confianza del
95% para la investigación.
• Paso 3: Pruebas
Para obtener los resultados se utiliza el modelo estadístico T-Student, previamente se ha

comprobado que los datos de antes y después del sistema se distribuyan normalmente, por lo que
pueden realizar las pruebas t para dos muestras emparejadas ya que son el mismo tipo de datos.
En la Tabla 19-4 se muestra los resultados obtenidos en los que existe una diferencia significativa
en el tiempo promedio antes y después del sistema para los reportes de clientes.
Tabla 19-4: Resultados de los tiempos de obtención de reportes de clientes

Estadísticos de muestras relacionadas
Nro Desviación
Media
Repeticiones típ.
AntesSistema 14 323,3143 45,53185
DespuesSistema 14 44,0807 2,05157

En el Gráfico 1-4 se puede observar visualmente que existe una diferencia significativa en el
tiempo de obtención de reportes de clientes con referencia al antes y después del sistema, con
promedios de 323,31 y 44,08 respectivamente.
74
REPORTE DE CLIENTES
350
300
250
200
150
100
50
0
AntesSistema DespuesSistema
Gráfico 1-4: Promedio de tiempos de obtención de reporte de clientes

La Tabla 20-4 muestra los resultados que se obtuvieron al aplicar la prueba estadística T-Student
para dos muestras relacionadas.
Tabla 20-4: Prueba T-Student pareada de reporte de clientes

Prueba T de muestras relacionadas
95% Intervalo de confianza
Diferencia de para la diferencia t df p-valor
medias Inferior Superior
AntesSistema -
279,2336 252,6443 305,8228 22,688 13 7.696e-12
DespuesSistema
• Paso 4: Decisión y conclusiones
Según los datos analizados, los resultados de la prueba de T-Student emparejada fueron
estadísticamente significativos dado con un nivel de significancia del 5% y un valor p-valor de
prácticamente 0 como se muestra en la Tabla 20-4, por lo que hay suficiente evidencia estadística
para rechazar la hipótesis nula y concluir que la automatización de los procesos si influye en el
tiempo de generación de reportes de clientes, ya que el tiempo ha disminuido considerablemente
como se evidencia en el Gráfico 1-4.
4.2.3.2 Análisis de resultados para el reporte existencias de productos terminados

generación del reporte de productos terminados sin automatizar.
75
del reporte de productos terminados sin automatizar.
• Paso 3: Pruebas

en el tiempo promedio antes y después del sistema para los reportes de productos terminados.
Tabla 21-4: Resultados de tiempos de obtención de reportes de productos

terminados

Nro Desviación
Media
Repeticiones típ.
AntesSistema 14 547,1571 66,79305

En el Grafico 2-4 se puede observar visualmente que existe una diferencia significativa en el
tiempo de obtención de reportes de productos terminados con referencia al antes y después del
sistema, con promedios de 547,15 y 48,68 respectivamente.
REPORTE DE PRODUCTOS
TERMINADOS
600
500
400
300
200
100
0
Gráfico 2-4: Promedio de tiempos de obtención de reportes de productos terminados

76
Tabla 22-4: Prueba T-Student pareada de reporte de productos terminados

AntesSistema -
498.4771 458.1418 538.8125 26.699 13 9.667e-13
DespuesSistema
Paso 4: Decisión y conclusiones
tiempo de generación de reportes de productos terminados, ya que el tiempo ha disminuido
considerablemente como se evidencia en el Gráfico 2-4.
4.2.3.3 Análisis de resultados para el reporte de existencias de materia prima

generación del reporte de existencias de materia prima sin automatizar.

del reporte de existencias de materia prima sin automatizar.
• Paso 3: Pruebas

77
en el tiempo promedio antes y después del sistema.
Tabla 23-4: Resultados de tiempos de obtención de reportes de materia prima

Nro Desviación
Media
Repeticiones típ.
AntesSistema 14 888,9857 190,84566
tiempo de obtención de reportes de existencias de materia prima con referencia al antes y después
del sistema, con promedios de 888,98 y 50,12 respectivamente.
REPORTE DE MATERIA PRIMA

1000
800
600
400
200
Gráfico 3-4: Promedio de tiempos de obtención de reportes de materia prima

Tabla 24-4: Prueba T-Student pareada de reporte de materia prima

AntesSistema -
838,8346 729,9941 947,7344 16,646 13 3.797e-10
DespuesSistema

78
tiempo de generación de reportes de existencia de materia prima, ya que el tiempo ha disminuido
4.2.3.4 Análisis de resultados para el reporte de productos en proceso

generación del reporte de productos en proceso prima sin automatizar.

del reporte de productos en proceso sin automatizar.
• Paso 3: Pruebas

Tabla 25-4: Resultados de tiempos de obtención de reportes de productos en

proceso
Nro Desviación
Media
Repeticiones típ.
AntesSistema 14 823,1571 195,17488
tiempo de obtención de reportes de productos en proceso con referencia al antes y después del
79
REPORTE DE PRODUCTOS EN
PROCESO
900,00
800,00
700,00
600,00
500,00
400,00
300,00
200,00
100,00
0,00
Gráfico 4-4: Promedio de tiempos de obtención de reportes de productos en proceso

Tabla 26-4: Prueba T-Student pareada de reporte de productos en proceso

AntesSistema -
772,3371 658,3777 886,2966 14,641 13 1.86e-09
DespuesSistema
tiempo de generación de reportes de productos en proceso, ya que el tiempo ha disminuido
4.2.3.5 Análisis de resultados para el reporte de pedidos de clientes
80
generación del reporte de pedidos de clientes sin automatizar.

del reporte de pedidos de clientes sin automatizar.
• Paso 3: Pruebas

Tabla 27-4: Resultados de tiempos de obtención de reportes de pedidos de

clientes
Nro Desviación
Media
Repeticiones típ.
AntesSistema 14 1416,6714 541,64222
tiempo de obtención de reportes de pedidos de clientes con referencia al antes y después del
81
REPORTE DE PEDIDOS DE
CLIENTES
1600,00
1400,00
1200,00
1000,00
800,00
600,00
400,00
200,00
0,00
Gráfico 5-4: Promedio de tiempos de obtención de reportes de pedidos de clientes

Tabla 28-4: Prueba T-Student pareada de reporte de pedidos de clientes

AntesSistema -
1370.716 1057.131 1684.301 9,4432 13 3.483e-07
DespuesSistema
tiempo de generación de reportes de pedidos de clientes, ya que el tiempo ha disminuido
4.2.3.6 Análisis de resultados para el reporte de pedidos de materia prima
82
generación del reporte de pedidos de materia prima sin automatizar.

del reporte de pedidos de materia prima sin automatizar.
• Paso 3: Pruebas

Tabla 29-4: Resultados de tiempos de obtención de reportes de pedidos de

materia prima
Nro Desviación
Media
Repeticiones típ.
AntesSistema 14 1393,6714 533,58379
tiempo de obtención de reportes de pedidos de materia prima con referencia al antes y después
del sistema, con promedios de 1393,67 y 49,51 respectivamente.
83
REPORTE DE PEDIDOS DE
MATERIA PRIMA
1600,00
1400,00
1200,00
1000,00
800,00
600,00
400,00
200,00
0,00
Gráfico 6-4: Promedio de tiempos de obtención de reportes de pedidos de materia prima

Tabla 30-4: Prueba T-Student pareada de reporte de pedidos de materia prima

AntesSistema -
1344.161 1034.878 1653.444 9.3891 13 3.72e-07
DespuesSistema
tiempo de generación de reportes de pedidos de materia prima, ya que el tiempo ha disminuido
4.2.3.7 Análisis de resultados para el reporte de proveedores
84
generación del reporte de proveedores sin automatizar.

del reporte de proveedores sin automatizar.
• Paso 3: Pruebas

Tabla 31-4: Resultados de tiempos de obtención de reportes de proveedores

Nro Desviación
Media
Repeticiones típ.
AntesSistema 14 1369,1143 305,90604

tiempo de obtención de reportes de proveedores con referencia al antes y después del sistema, con
promedios de 1369,11 y 46,72 respectivamente.
85
REPORTE DE PROVEEDORES
1600,00
1400,00
1200,00
1000,00
800,00
600,00
400,00
200,00
0,00
Gráfico 7-4: Promedio de tiempos de obtención de reportes de proveedores

Tabla 32-4: Prueba T-Student pareada de reporte de proveedores

AntesSistema -
1322.385 1144.205 1500.565 16.033 13 6.052e-10
DespuesSistema
tiempo de generación de reportes de proveedores, ya que el tiempo ha disminuido
4.2.4 Resultados de evaluación para el nivel de eficiencia
Un análisis general de los tiempos de obtención de reportes de antes y después del sistema, en el
Tabla 33-4 se puede evidenciar de forma general el promedio de tiempo para cada uno de los
reportes.
86
Tabla 33-4: Promedio de tiempo antes y después del sistema
Items evaluados
(seg) (seg)
Listado de clientes 323,31 44,08
Listado de existencias de productos terminados 547,15 48,68
Listado de existencias de materia prima 888,98 50,12
Listado de productos en proceso 823,16 50,82
Listado de pedidos de clientes 1416,67 45,95
Listado de pedidos de materia prima 1393,67 49,51
Listado de proveedores 1369,11 46,72
Promedio 966,007 47,98
En el Gráfico 8-4 se puede observar que el tiempo que se tardaba en obtener los reportes de
inventario antes del sistema es mayor, ya que en promedio se tardaba 966,007 segundos, que en
minutos equivale a 32,76 minutos, a diferencia de hacer un reporte con el sistema, el tiempo
promedio que se tarda es de 47,98 segundos, lo cual es menor a un minuto en obtener un reporte,
lo que demuestra que utilizando el sistema los reportes se generan en un tiempo mucho menor
rediciendo el tiempo a un 4.96% con respecto al tiempo que se requería al realizarlo de forma
manual.
Tiempo promedio de obtención de

reportes
Promedio
0 200 400 600 800 1000 1200
Promedio
DespuesSistema 47,98
AntesSistema 966,007
DespuesSistema AntesSistema
Gráfico 8-4: Tiempo promedio de obtención de reportes

87
CONCLUSIONES
• Se investigó todo lo relacionado con el estado del arte haciendo énfasis en software como
servicio (SaaS) teniendo como tema principal entre los cuales se destacaron las principales
características de las cuales la más notoria es el pago por uso lo que significa que se debe
pagar sólo por el servicio contratado que puede ser mensual o anual misma que también es
una de las ventajas importantes de SaaS. En cuanto a la arquitectura para SaaS, se encontraron
dos tipos de arquitectura single-tenant y multi-tenant. Para el sistema implementado se
consideró la arquitectura multi-tenant, donde una instancia del software es utilizada por
muchos usuarios.
• Se utilizaron métodos de recopilación de información como la entrevista y la encuesta para

obtener el proceso de inventario interno del establecimiento, como resultado se obtuvo un
diagrama de procesos donde se muestra el flujo de gestión de inventario, así como se obtuvo
un total de 5 roles que forman parte del flujo donde se inicia con el pedido del cliente se sigue
el proceso paso a paso tomando en cuenta las 12 fases hasta culminar el proceso con la entrega
del producto al cliente.
• Para el desarrollo del sistema se utilizaron herramientas como los servicios REST, framework
Laravel para el desarrollo de la API, framework Angular para el desarrollo de la interfaz de
usuario, PHPStorm como entorno de desarrollo integrado y MySQL como gestor de base de
datos. Siguiendo la metodología de desarrollo SCRUM se obtuvo un total de 32 historias de
usuario y 6 historias técnicas las cuales se las distribuyó en 7 Sprint en la que cada Sprint
tiene como duración 2 semanas lo que dio como resultado 1020 horas de trabajo.
• Una vez completado el sistema, se evaluó el nivel de portabilidad utilizando las

subcaracterísticas de las ISO/IEC 25010 y las fórmulas de las métricas externa de la norma
ISO/IEC 9126, y para la evaluación se utilizaron los niveles de puntuación presentados en la
ISO/IEC 25040; para esto se midió la adaptabilidad a distintos dispositivos tomándose en
cuenta los componentes para aplicaciones web responsivas y el uso continuo de los datos.
Los resultados indican que el sistema web alcanza un nivel de portabilidad de 87.5%, por lo
que se considera que, si es posible desarrollar un sistema portable, pero sin tener en cuenta la
característica de facilidad de instalación ya que es una aplicación web y no se requiere este
proceso.
88
• Para obtener el nivel de eficiencia en función del tiempo, se definieron las hipótesis nula y
alternativa, se determinó el tamaño muestral teniendo en cuenta que la población es de tipo
infinita o desconocida y se consideró como el número de veces posibles que se puede ejecutar
un reporte de inventario, para este estudio se obtuvo una muestra de 96 misma que se dividió
en el total de reportes que se pueden generar en el sistema para este caso son 7 reportes y se
toman 14 muestras para cada uno. Se utilizó la prueba de Shapiro-Wilk para comprobar la
normalidad de los datos y los resultados indican que con la implantación del sistema se ha
influido positivamente, ya que el tiempo promedio que se tarda en generar un reporte es de
47,98 segundos, es decir, menos de un minuto para obtener un reporte, a diferencia de lo que
ocurría antes del sistema, que el tiempo era mayor, tardando en promedio 966,007 segundos,
que equivalen a 32,76 minutos rediciendo el tiempo a un 4.96% con respecto al tiempo que
se requería al realizarlo de forma manual.
89
RECOMENDACIONES
• Estudiar el efecto de rendimiento del modelo software con servicio utilizando la arquitectura
single-tenant (un solo inquilino).
• Se recomienda continuar con el desarrollo del sistema implementando los módulos de

facturación y elaboración de proformas para que se pueda complementar con el servicio de
inventario.
• Medir el nivel de portabilidad con otra metodología que no requiera la medición del proceso
de instalación de sistema, de tal manera que se pueda obtener un porcentaje de portabilidad
más eficiente.
• Además, se recomienda medir el tiempo de obtención de reportes lo más cercano al servidor

para que la latencia no perjudique los tiempos de medición.
90
GLOSARIO
N° TÉRMINO SIGNIFICADO
1 APIS Application programming interface (interfaz de programación de aplicaciones)
2 CPU Central processing unit (unidad central de procesamiento)
3 EIS Escuela de Ingeniería en Sistemas
4 ESPOCH Escuela Superior Politécnica de Chimborazo
5 FIE Facultad de Informática y Electrónica
6 HT Historia de usuario
7 HU Historia técnica
International Electrotechnical Commission(Comisión Electrotécnica
8 IEC
Internacional)
International Organization for Standardization(Organización Internacional de
9 ISO
Normalización)
10 PC Personal Computer (computadora personal)
11 REST Representational State Transfer
12 SaaS Software as a service (software como servicio)
13 SEG Segundos
BIBLIOGRAFÍA
ALEGRE MONTALVO, A.P., Sistema de gestión de procesos de negocio basado en el modelo

SAAS para automatizar flujos de trabajo empresariales en T&S servicios de ingeniería SAC - año
2018 [en línea]. S.l.: Universidad Nacional Santiago Antúnez de Mayolo. 2020. [Consulta:22-7-
2020]. Disponible en: http://repositorio.unasam.edu.pe/handle/UNASAM/4054.
AMGAI, R., "Getting Started with a multi tenant application on Nodejs". Medium [en línea].
2019. [Consulta:24 febrero 2021]. Disponible en: https://blog.lftechnology.com/designing-a-
secure-and-scalable-multi-tenant-application-on-node-js-15ae13dda778.
ANGULAR, "Angular - Introduction to Angular concepts". [en línea]. 2020. [Consulta:17

noviembre 2020]. Disponible en: https://angular.io/guide/architecture.
AREVALO, A., "Diseño Web Responsive | Claves y Consejos Útiles". Reactiva Online [en
línea]. 2021. [Consulta:29/7/2022]. Disponible en: https://www.reactivaonline.com/web-
responsive/.
BĄK, T., "How To Design A SaaS Application? (2020 Update)". [en línea]. 2018. [Consulta:24
noviembre 2020]. Disponible en: https://selleo.com/blog/how-to-design-a-saas-application.
BARAM, R., "¿Qué es MySQL? - Definición en WhatIs.com".

SearchDataCenter en Español [en línea]. 2015. [Consulta:11 febrero 2021].
Disponible en: https://searchdatacenter.techtarget.com/es/definicion/MySQL.
CAJIAO BARRERA, F.L., & LAZO VILLANUEVA, A.D. "Prototipo de Aplicación Web
Responsive para gestión de reservas de áreas recreativas, buzón de comentarios y publicación de
comercio ciudadano dirigido al GAD “El Triunfo”.". En: Accepted: 2022-05-17T06:54:42Z [en
línea], 2022. [Consulta:29-7-2022]. Disponible en:
http://repositorio.ug.edu.ec/handle/redug/59926.
CATANIA, S., "¿Qué es SaaS y por qué se considera la industria del futuro?". noticias.ltda [en
línea]. 2019. [Consulta:02/8/2020]. Disponible en: https://www.noticias.ltda/sociedad-
digital/que-es-saas-industria-del-futuro/.
CHANDI ARGOTI, L.P., & ROLDÁN MOLINA, G. del R., Implementación de un aplicativo
Web como servicio SAAS, bajo una infraestructura en la nube IAAS, para la cooperativa San
Vicente del Sur Matriz [en línea]. S.l.: Universidad de las Fuerzas Armadas ESPE. Carrera de
Ingeniería en Sistemas e Informática. 2015. [Consulta:11/7/2020]. Disponible en:
http://repositorio.espe.edu.ec/jspui/handle/21000/10779.
CHISAGUANO BALSECA, A.E. "Evaluación de calidad de productos de software en empresas

de desarrollo de software aplicando la norma ISO/IEC 25000". En: Accepted: 2015-02-
02T21:22:07Z [en línea], 2014. [Consulta:17/2/2021]. Disponible en:
http://bibdigital.epn.edu.ec/handle/15000/9113.
DAGNINO S., J. "INFERENCIA ESTADÍSTICA: PRUEBAS DE HIPÓTESIS". Revista

Chilena de Anestesia [en línea], 2014. vol. 43, (no. 2). [Consulta:27/6/2022]. ISSN 07164076,
07196792. DOI 10.25237/revchilanestv43n02.10. Disponible en:
http://revistachilenadeanestesia.cl/inferencia-estadistica-pruebas-de-hipotesis/.
DELGADO SANDÍ, C.J., Cloud computing: posibilidades para la ejecución de juegos serios
educativos as a service (JSEaaS) [en línea]. Tesis. S.l.: Universidad Nacional de La Plata. 2017.
p22-23 p [Consulta:28/11/2020]. Disponible en: http://sedici.unlp.edu.ar/handle/10915/63388.
ECHAVARRÍA, J.D.L.,et al "EL MÉTODO ANALÍTICO COMO MÉTODO NATURAL".
Nómadas. Revista Crítica de Ciencias Sociales y Jurídicas, 2010. vol. 25, (no. 1), pp. 28. ISSN
1578-6730.
ESPINOZA FREIRE, E.E. "La hipótesis en la investigación". Mendive. Revista de Educación

[en línea], 2018. vol. 16, (no. 1), pp. 122-139. [Consulta:09/2/2021]. ISSN 1815-7696. Disponible
en: http://scielo.sld.cu/scielo.php?script=sci_abstract&pid=S1815-
76962018000100122&lng=es&nrm=iso&tlng=es.
EVALUANDO ERP, "SaaS: El modelo de suscripción para usar el ERP". Evaluando ERP [en
línea]. 2021. [Consulta:25/2/2021]. Disponible en: https://www.evaluandoerp.com/software-
erp/saas-software-como-servicio/.
FERNÁNDEZ, A.C. 2018. Gestión de inventarios. COML0210. S.l.: IC Editorial. 2018. ISBN
978-84-9198-190-9.
GOYAL, S., "Single-Tenant vs Multi-Tenant Architecture for SaaS Application Design".

Insights - Web and Mobile Development Services and Solutions [en línea]. 2019.
[Consulta:24/11/2020]. Disponible en: https://www.netsolutions.com/insights/5-reasons-why-
you-should-choose-multi-tenant-architecture-for-your-saas-application/.
GUAMANGATE, Y.K.M., CAISALUISA, J.L.M. y CERDA, V. del C.T. "Medición de

usabilidad y portabilidad de una Aplicación Web desarrollada con tecnología PWA".
ConcienciaDigital [en línea], 2021. vol. 4, (no. 4), pp. 6-27. [Consulta:10/6/2022]. ISSN 2600-
5859. DOI 10.33262/concienciadigital.v4i4.1882. Disponible en:
https://cienciadigital.org/revistacienciadigital2/index.php/ConcienciaDigital/article/view/1882.
HARO, E., GUARDA, T., ZAMBRANO, A. y NINAHUALPA, G., "Desarrollo backend para
aplicaciones web, Servicios Web Restful: Node.js vs Spring Boot - ProQuest". [en línea]. 2019.
[Consulta:30/9/2020]. Disponible en:
https://search.proquest.com/openview/a78cfaa62708fd24f38ac8d1025050eb/1?pq-
origsite=gscholar&cbl=1006393.
HERAZO, L., "¿Qué es el software como servicio SaaS? | Anincubator - Blog". Anincubator
Website [en línea]. 2020. [Consulta:08/9/2021]. Disponible en: https://anincubator.com/que-es-
el-software-como-servicio-saas/.
HOOGENRAAD, W., "Multi-tenant o Single-tenant, pero SaaS First Strategy". Information

Technology [en línea]. 2019. [Consulta:24/11/2020]. Disponible en:
https://es.itpedia.nl/2019/06/10/multi-tenant-or-single-tenant-but-saas-first-strategy/.
IBM, "¿Qué es cloud computing?". [en línea]. 2019. [Consulta:11/7/2020]. Disponible en:
https://www.ibm.com/es-es/cloud/learn/cloud-computing.
ISO 25010, "ISO 25010". [en línea]. 2011. [Consulta:11/7/2020]. Disponible en:
https://iso25000.com/index.php/en/iso-25000-standards/iso-25010?limit=3&start=6.
ISO/IEC. ISO 25000. [en línea]. 2011 [Consulta: 26 enero 2023]. Disponible en:
https://iso25000.com/index.php/normas-iso-25000/iso-25010/21-eficiencia-de-desempeno.
LARAVEL, "Installation - Laravel - The PHP Framework For Web Artisans". [en línea]. 2021.
[Consulta:22/1/2021]. Disponible en: https://laravel.com/docs/8.x.
LOGON, "PhpStorm | Enjoy Productive PHP". LOGON [en línea]. 2020. [Consulta:24/2/2021].
Disponible en: https://logon-int.com/jetbrains/phpstorm/.
MARTÍNEZ, E.L., CEBALLOS, C.S., 3025335, 3025373, RN y RN. "Diseño Web Adaptativo
o responsivo". En: Accepted: 2018-06-28T05:22:53Z, Revista Digital Universitaria (1607 -
6079). Vol. 14, No. 1 (2013) [en línea], 2013. [Consulta:28/7/2022]. Disponible en:
https://www.ru.tic.unam.mx/xmlui/handle/123456789/2097.
MATOS AYALA, A., "Investigación Bibliográfica: Definición, Tipos, Técnicas". Lifeder [en
línea]. 2020. [Consulta:26/1/2021]. Disponible en: https://www.lifeder.com/investigacion-
bibliografica/.
Metodologías ágiles en Gestión de Proyectos [en línea], 2016. [Consulta:02 septiembre 2021].
Disponible en: https://www.youtube.com/watch?v=4nwlqsZtWWQ.
MICROSOFT, "What Is Cloud Computing? A Beginner’s Guide | Microsoft Azure". [en línea].
2020. [Consulta:11 julio 2020]. Disponible en: https://azure.microsoft.com/en-us/overview/what-
is-cloud-computing/.
MICROSOFT AZURE, "¿Qué es SaaS? Software como servicio | Microsoft Azure". [en línea].
2020. [Consulta:02 agosto 2020]. Disponible en: https://azure.microsoft.com/es-
es/overview/what-is-saas/.
MUNDRA, M., "Multi-tenant Vs. Single-tenant Architecture (SaaS) | SAP Blogs". [en línea].
2015. [Consulta:24 noviembre 2020]. Disponible en: https://blogs.sap.com/2015/07/12/multi-
tenant-vs-single-tenant-architecture-saas/.
MURILLO, J., "15 Murillo La Entrevista | Información | Realidad". Scribd [en línea]. 2020.
[Consulta:22 enero 2021]. Disponible en: https://es.scribd.com/presentation/407327461/15-
Murillo-La-Entrevista.
MURRAY R., S. y LARRY J., S., "Estadística. Serie Schaum- 4ta edición - Murray R.
Spiegel.pdf (1)". studylib.es [en línea]. 2005. [Consulta:27/7/2022]. Disponible en:
https://studylib.es/doc/8875182/estadística.-serie-schaum--4ta-edición---murray-r.-spie...
NORI, R., KARODIYA, N. y REZA, H., "Portability testing of scientific computing software
systems". IEEE International Conference on Electro-Information Technology, EIT [en línea],
2013, (Rapid City, SD, USA): IEEE, 2013. pp. 1-8. [Consulta:11 julio 2020]. ISBN 978-1-4673-
5208-6. DOI 10.1109/EIT.2013.6632686. Disponible en:
http://ieeexplore.ieee.org/document/6632686/.
PERSEO," Perseo Sistema Contable". [en línea]. 2020. [Consulta: 21 octubre 2020]. Disponible
en: https://perseo.ec/web/.
PREGO-NIETO, M., "BPMN 2.0: qué es y para qué sirve. ¿Cómo usarlo? | Appvizer".
appvizer.es [en línea]. 2020. [Consulta:01 junio 2021]. Disponible en: /revista/organizacion-
planificacion/business-performance/bpmn.
PRESSMAN, R.S. "Ingeniería del software: un enfoque práctico" [en línea], 2010. Séptima
edición. S.l.: s.n. [Consulta:11 julio 2020]. ISBN 978-1-4562-1836-2. Disponible en:
http://www.ingebook.com/ib/NPcd/IB_BooksVis?cod_primaria=1000187&codigo_libro=4272.
REINA, E. y PATIÑO, S. "Evaluación de la calidad en uso de un sistema web/ móvil de control

de asistencia a clases de docentes y estudiantes aplicando la norma ISO/IEC 25000 SQuaRe".
RISTI - Revista Iberica de Sistemas e Tecnologias de Informacao, 2019. vol. E19, pp. 108.
SALAZAR, L., "Historias de Usuario - Introducción con: Luis Salazar". IT Service [en línea].
2020. [Consulta:08 febrero 2021]. Disponible en: https://itservice.com.co/historias-de-usuario/.
SMOOK, G.A. "12.4 Inventory Control". Handbook for Pulp & Paper Technologists (4th
Edition) [en línea], 2016. S.l.: TAPPI, pp. 189. ISBN 978-1-59510-245-4. Disponible en:
https://app.knovel.com/hotlink/pdf/id:kt012806G1/handbook-pulp-paper-
technologists/inventory-control.
SUAZA, K.V., GARCÍA, J.J.T.; & JARAMILLO, C.M.Z. "Mejora de historias de usuario y
casos de prueba de metodologías ágiles con base en TDD.". Cuaderno Activa [en línea], 2015.
vol. 7, pp. 41-53. [Consulta:08 febrero 2021]. ISSN 2619-5232. Disponible en:
https://190.217.57.229/index.php/cuadernoactiva/article/view/246.
TAKYAR, A., "Single vs Multi-Tenant SaaS Architecture". [en línea]. 2020.

[Consulta:24/11/2020]. Disponible en: https://blog.hubspot.com/service/single-vs-multi-tenant-
saas.
TOTH, P.; & VIGO, D. "System Architectures and Service Interfaces". Vehicle Routing -
Problems, Methods, and Applications (2nd Edition) [en línea], 2014. S.l.: Society for Industrial
and Applied Mathematics, pp. 368. ISBN 978-1-61197-358-7. Disponible en:
https://app.knovel.com/hotlink/pdf/id:kt0119ZWV2/vehicle-routing-problems/system-
architectures.
VALDES, A., "Single-Tenant vs Multi-Tenant: SaaS Architecture - DZone Cloud". dzone.com

[en línea]. 2020. [Consulta:22 junio 2021]. Disponible en: https://dzone.com/articles/single-
tenant-vs-multi-tenant-saas-architecture.
YADAV, S.R.; & MALIK, A.K. "Inventory Control". Operations Research [en línea], 2014.
S.l.: Oxford University Press, pp. 554. ISBN 978-0-19-809618-4. Disponible en:
https://app.knovel.com/hotlink/pdf/id:kt00UPS661/operations-research/inventory-control.
Anexo A: Resultados entrevista
• ¿Cómo se inicia el proceso de un pedido de un producto?
El proceso inicia cuando el cliente realiza un pedido específico de una prenda; primero se
comprueba si existe en bodega dicha prenda y de no existir se llena una hoja de pedido con los
datos del cliente y del o los productos que se van a confeccionar. Se anota los detalles de cada
prenda como color, talla, tipo de tela, estampados y bordados dependiendo del tipo de prenda.
Cabe mencionar que existen prendas que requieren de una talla especial, estos datos también se
los adjunta en la hoja del pedido, se anotan los datos de fecha de recepción y la fecha en la que se
entregará.
• ¿De qué forma se realiza el control de productos terminados en bodega?
Los productos terminados se almacenan sin ningún registro previo, estos se guardan en los
estantes vacíos de la bodega lo cual al momento de requerir dicha prenda es difícil de localizar y
se produce un desorden de los productos que ya están ahí guardados, además no hay un control
de tallas, colores, ni tipo de producto.
• ¿De qué forma se realiza el control de materia prima en bodega?
La materia prima se guarda en los espacios vacíos de la bodega o dentro del área de producción
lo que dificulta encontrar algún material al momento de necesitarlo por lo cual en muchas
ocasiones se considera perdido y se procede a comprar de nuevo el material que se requiere, lo
que también ocasiona una pedida económica para la empresa al no contar con un registro de toda
la materia prima disponible.
• ¿Cómo se realiza la adquisición de materia prima al proveedor?
Se hace una o varias compras directas en los almacenes distribuidores de la materia prima que se
requiera para una determinada prenda, en algunas ocasiones se realiza un pedido dónde se detalla
lo que se requiere comprar, una vez realizada la compra, la materia prima se guarda en bodega o
se almacena en el área de producción.
• ¿Qué información de los pedidos almacena y qué manera lo realiza?
Se almacena los datos del cliente como el nombre, apellido, cédula, teléfono, dirección y ruc,
también se registran los datos de las prendas solicitadas para esto se anota la cantidad, una
descripción de la prenda como la talla, color, modelo de la prenda, si se requiere se anotan medidas
especiales, el costo unitario y el costo total es importante tenerlo registrado también.
Anexo B: Manual técnico
Manual Técnico
Proyecto: Sistema portable para la gestión de inventarios

bajo el modelo de Software como Servicio (SaaS) para la
empresa "Industria Textil Paoli’s"
Escuela Superior Politécnica De Chimborazo
Facultad de informática y electrónica
Carrera de Software
Enero 2023
Sistema LULY SaaS
Página 2
MANUAL TÉCNICO
ÍNDICE DE TABLAS ................................................................................................................. 5
ÍNDICE DE FIGURAS ............................................................................................................... 7
INTRODUCCIÓN ...................................................................................................................... 8
5 OBJETIVOS ................................................................................................................ 9
5.1 Objetivos específicos ................................................................................................... 9

6 Alcance ......................................................................................................................... 9
7 Usuarios........................................................................................................................ 9
7.1 Super usuario............................................................................................................... 9

7.2 Administrador de la empresa ..................................................................................... 9
7.3 Empleado de la empresa ........................................................................................... 10
CAPÍTULO II ........................................................................................................................... 11
8 CONTENIDO TÉCNICO ........................................................................................ 11
8.1 Requerimientos del sistema ...................................................................................... 11

8.1.1 Requisitos funcionales ............................................................................................... 11
8.1.2 Requisitos no funcionales ......................................................................................... 12
8.2 Análisis y gestión de riesgos ..................................................................................... 12

8.2.1 Identificación de riesgos ........................................................................................... 12
8.2.2 Análisis de riesgos ..................................................................................................... 14
8.2.3 Valorización de riesgos ............................................................................................. 14
8.2.4 Priorización de riesgos .............................................................................................. 17
8.2.5 Gestión de riesgos ...................................................................................................... 18
8.3 Análisis de factibilidad.............................................................................................. 30

8.3.1 Factibilidad técnica ................................................................................................... 31
8.3.2 Factibilidad operativa ............................................................................................... 32
8.3.3 Factibilidad económica ............................................................................................. 33
9 FASE DE PLANIFICACIÓN .................................................................................. 36
9.1 Estimaciones .............................................................................................................. 36

9.2 Plan de entrega .......................................................................................................... 45
10 DESARROLLO ......................................................................................................... 49
10.1 Análisis de proceso del sistema ................................................................................ 49

Sistema LULY SaaS
Página 3
MANUAL TÉCNICO
10.2 Conceptualización del sistema para el usuario modulo SaaS ............................... 49

10.3 Conceptualización del sistema módulo gestión de inventario ............................... 50
10.4 SPRINT 1 ................................................................................................................... 52
10.4.1 HT_01 Análisis y definición de la arquitectura del sistema. ................................. 52
10.4.2 HT_02 Análisis y definición del estándar de la interfaz de usuario ..................... 59
10.4.3 HT_03 Análisis y definición del estándar del estándar de programación............ 65
10.4.4 HT_04 Diseñar el esquema de base de datos. ......................................................... 70
10.5 SPRINT 2 ................................................................................................................... 19

10.5.1 HT_05 Implementar el diseño de la base de datos ................................................. 19
10.5.2 HT_06 Redactar la documentación ......................................................................... 21
10.5.3 HU_01 Registro de usuarios ..................................................................................... 24
10.5.4 HU_02 Consulta de usuarios registrados ................................................................ 28
10.5.5 HU_03 Eliminar usuarios registrados ..................................................................... 31
10.5.6 HU_04 Autenticación de usuario ............................................................................. 34
10.6 SPRINT 3 ................................................................................................................... 37

10.6.1 HU_05 Control de sesiones activas de un usuario .................................................. 38
10.6.2 HU_06 Contratación de servicio de gestión de inventarios ................................... 41
10.6.3 HU_07 Registro de datos de la empresa de un usuario.......................................... 44
10.6.4 HU_08 Modificar los datos de una empresa de un usuario ................................... 48
10.6.5 HU_09 Verificación pago de una suscripción de un servicio................................. 51
10.6.6 HU_10 Notificación de suscripciones por expirar .................................................. 55
10.7 SPRINT 4 ................................................................................................................... 58

10.7.1 HU_11 Agregar nuevos planes a un servicio .......................................................... 58
10.7.2 HU_12 Registro de proveedores de materia prima ................................................ 62
10.7.3 HU_13 Modificar proveedores de materia prima .................................................. 65
10.7.4 HU_14 Buscar proveedores de materia prima ....................................................... 69
10.7.5 HU_15 Eliminar proveedores de materia prima .................................................... 72
10.7.6 HU_16 Registro de materia prima ........................................................................... 76
10.7.7 HU_17 Modificar materia prima ............................................................................. 79

Sistema LULY SaaS
Página 4
MANUAL TÉCNICO
10.8 SPRINT 5 ................................................................................................................... 82

10.8.1 HU_18 Buscar materia prima .................................................................................. 82
10.8.2 HU_19 Eliminar materia prima ............................................................................... 86
10.8.3 HU_20 Registro de productos terminados .............................................................. 89
10.8.4 HU_21 Modificar productos terminados ................................................................ 93
10.8.5 HU_22 Buscar productos terminados ..................................................................... 96
10.8.6 HU_23 Eliminar productos terminados ................................................................ 100
10.9 SPRINT 6 ................................................................................................................. 103

10.9.1 HU_24 Reporte de proveedores ............................................................................. 103
10.9.2 HU_25 Registro de estantes .................................................................................... 106
10.9.3 HU_26 Modificar estantes ...................................................................................... 109
10.9.4 HU_27 Buscar estantes ........................................................................................... 112
10.9.5 HU_28 Eliminar estantes ........................................................................................ 116
10.9.6 HU_29 Reportes de inventarios materia prima .................................................... 119
10.9.7 HU_30 Reportes de inventarios productos terminados ....................................... 121
10.9.8 HU_31 Reportes de clientes .................................................................................... 124
10.10 SPRINT 7 ................................................................................................................. 126

10.10.1 HU_32 Pruebas del sistema .................................................................................... 126
Bibliografía .............................................................................................................................. 131

Sistema LULY SaaS
Página 5
MANUAL TÉCNICO
ÍNDICE DE TABLAS
Tabla 1: Identificación de riesgos ......................................................................................... 12

Tabla 2: Criterios de valoración de la probabilidad .............................................................. 14
Tabla 3: Criterios de valoración del impacto ........................................................................ 15
Tabla 4: Criterios de valoración de la exposición al riesgo .................................................. 15
Tabla 5: Criterios de valoración impacto de probabilidad .................................................... 15
Tabla 6: Clasificación de riesgos .......................................................................................... 16
Tabla 7: Priorización de riesgos ............................................................................................ 17
Tabla 8: Hoja de gestión de riesgo R_01 .............................................................................. 18
Tabla 21: Hardware existente ................................................................................................. 31
Tabla 22: HARDWARE REQUERIDO ................................................................................. 31
Tabla 23: Software existente ................................................................................................... 31
Tabla 24: Software requerido.................................................................................................. 32
Tabla 25: Personal existente ................................................................................................... 32
Tabla 26: Personal requerido .................................................................................................. 32
Tabla 27: Recursos Humanos ................................................................................................. 32
Tabla 28: Costo de personal .................................................................................................... 33
Tabla 29: Costos de Hardware y Software.............................................................................. 33
Tabla 30: Costos de Capacitación a usuarios .......................................................................... 34
Sistema LULY SaaS
Página 6
MANUAL TÉCNICO
Tabla 31: Costos de operación ................................................................................................ 34

Tabla 32: TABLA ILF/ EIF .................................................................................................... 36
Tabla 33: ENTRADA EXTERNA .......................................................................................... 36
Tabla 34: SALIDA EXTERNA .............................................................................................. 36
Tabla 35: ENTRADA ............................................................................................................. 37
Tabla 36: Salida ...................................................................................................................... 37
Tabla 37: ILF: INTERNAL LOGIC FILE (Archivo lógico interno) ...................................... 37
Tabla 38: EIF: EXTERNAL INTERFACE FILE (Archivo lógico externo) .......................... 38
Tabla 39: EI: Entrada externa ................................................................................................ 39
Tabla 40: EO salida externa .................................................................................................... 40
Tabla 41: EQ consulta externa ................................................................................................ 41
Tabla 42: tabla de resumen de los puntos de función ............................................................. 42
Tabla 43: Resultados Reales de Estimación............................................................................ 44
Tabla 44: Tecnica de estimacion T-Shirt ................................................................................ 45
Tabla 45: Plan de entrega ........................................................................................................ 46
Sistema LULY SaaS
Página 7
MANUAL TÉCNICO
ÍNDICE DE FIGURAS
Figura 1: Resultados puntos de estimación........................................................................... 43

Figura 2: Resultados preliminares de esfuerzo ..................................................................... 44
Figura 3: Representación de resultados finales COCOMO II............................................... 44
Figura 4: Representación del funcionamiento del módulo SaaS para el usuario .................. 50
Figura 5: Representación del funcionamiento del módulo inventario usuario gerente ......... 51
Figura 6: Representación del módulo inventario usuario empleado ..................................... 51
Figura 7: Arquitectura N capas ............................................................................................. 55
Figura 8: Paleta de colores .................................................................................................... 59
Figura 9: Diseño botones ...................................................................................................... 59
Figura 10: Interlineado............................................................................................................ 60
Figura 11: Bosquejo pantalla principal ................................................................................... 60
Figura 12: Bosquejo pantalla reportes .................................................................................... 61
Figura 13: Bosquejo pantalla general ..................................................................................... 61
Figura 14: Base de datos módulo inventario .......................................................................... 69
Figura 15: Base de datos módulo SaaS ................................................................................... 69
Sistema LULY SaaS
Página 8
MANUAL TÉCNICO
INTRODUCCIÓN
Este manual técnico tiene como finalidad mostrar al usuario final los requisitos y procesos que
fueron necesarios para el desarrollo del sistema el mismo que pretende influir en el tiempo de
generación de reportes de inventarios.
Es necesario tener en cuenta ciertos parámetros técnicos para el desarrollo del sistema, lo que
permite el correcto funcionamiento de la aplicación en los entornos para lo cual fue desarrollada
como es el caso dicho software se puede ejecutar desde cualquier plataforma ya que se requiere
de cualquier navegador para su ejecución; teniendo en cuenta que la aplicación fue desarrollada
en el con el framework PHP y como gestor de base de datos se usa MySQL.
Sistema LULY SaaS
Página 9
MANUAL TÉCNICO
CAPÍTULO I
5 OBJETIVOS
El objetivo de este manual técnico es dar a conocer los detalles de desarrollo del sistema de gestión
de inventarios para la empresa Industria Textil Paoli’s.
5.1 Objetivos específicos

• Guiar al personal encargado de brindar soporte al sistema web, a través de la descripción de
cada proceso que interviene en el desarrollo de la aplicación.
• Definir los requerimientos funcionales y no funcionales para el correcto planteamiento de la
solución.
• Realizar el análisis y gestión de riesgos para mitigar posibles causas que puedan retrasar el
• Realizar el estudio de factibilidad para tener en cuenta tiempos de entrega, costos y duración
del proyecto.
• Definir el plan de entrega del proyecto implementado la metodología SCRUM.
6 Alcance
El manual técnico está destinado a usuarios con conocimientos básicos en ingeniería de software
o ingenieros en sistemas que tengan la responsabilidad de guiar el proceso de soporte del sistema
web.
7 Usuarios
Los usuarios son las personas que tendrán acceso al sistema, de los cuales se ha determinado un
super administrador, administrador de la empresa, empleado de la empresa.
7.1 Super usuario
Es el usuario encargado de manejar el módulo SaaS, en este módulo se realizan las funciones de
gestión de servicios y planes que provee el sistema web, así también tiene acceso a reportes de
usuarios que han contratado uno o más servicios disponibles en la página.
7.2 Administrador de la empresa
Sistema LULY SaaS
Página 10
MANUAL TÉCNICO
Este usuario cuenta con funciones que son propias de la empresa en cuanto al manejo de
inventarios internos, contratación de servicios, registro de empleados, obtención de reportes de
inventarios.
7.3 Empleado de la empresa
El empleado debe estar previamente registrado por el administrador de la empresa para poder
tener acceso a las funciones que le corresponde al rol empleado dichas funciones fueron
establecidas acorde a las reglas del negocio.
Sistema LULY SaaS
Página 11
MANUAL TÉCNICO
CAPÍTULO II
8 CONTENIDO TÉCNICO
8.1 Requerimientos del sistema
La gestión de los requerimientos del sistema es necesaria ya que en base a los requerimientos
proporcionados por el usuario se pueden entender o determinar las funcionalidades que desea el
cliente para su sistema.
8.1.1 Requisitos funcionales
Cuando se ha determinado el principal problema existente en la empresa “Industria Textil

Paoli´s”, con sus causas y efectos, es necesario definir los requerimientos del sistema de manera
detalla y minimizando la ambigüedad de tal modo que sea fácil de comprender las funcionalidades
que se van a desarrollar y que deben ir de la mano con las necesidades del usuario
Con las especificaciones mencionadas por el cliente y por parte de los desarrolladores se dividió
los requerimientos en dos partes una parte para el módulo SaaS y otra para el módulo de gestión
de inventarios.
8.1.1.1 Requerimientos módulo SaaS
• Los usuarios podrán registrarse.

• Consultar y eliminar usuarios registrados.
• Autenticación de usuarios.
• Cada usuario podrá tener solo una sesión activa a la vez.
• El usuario registrado podrá contratar el servicio de gestión de inventarios.
• El usuario podrá registrar los datos de una o más empresas
• El usuario registrado podrá modificar los datos de su empresa o negocio.
• El sistema verificará que el usuario haya cancelado el valor de la suscripción para conceder
acceso al servicio contratado.
• El sistema mostrará una notificación cuando su suscripción esté por expirar
• El sistema permitirá agregar nuevos planes para los servicios
8.1.1.2 Requerimientos Módulo de gestión de inventarios
• El sistema permitirá registrar proveedores de materia prima.

• El sistema permitirá la búsqueda, modificación y eliminación de proveedores.
• El sistema permitirá registrar el ingreso de materia prima.
• El sistema permitirá la búsqueda, modificación y eliminación de materia prima.
Sistema LULY SaaS
Página 12
MANUAL TÉCNICO
• El sistema permitirá el registro productos terminados.

• El sistema permitirá la búsqueda, modificación y eliminación de productos terminados.
• El sistema permitirá identificar áreas específicas dentro de los almacenes para registrar la
localización del inventario.
• El sistema permitirá mantener un control de stock de materia prima y productos terminados.
• El usuario administrador podrá agregar empleados en el módulo contratado
8.1.2 Requisitos no funcionales
Los requerimientos no funcionales fueron definidos con el fin de asegurar la calidad del software
para lo cual se estableció dos parámetros como se muestra a continuación:
8.1.2.1 Portabilidad
El sistema debe cumplir con las características de portabilidad tales como: adaptabilidad, facilidad
de instalación y coexistencia.
8.1.2.2 Eficiencia en función del tiempo

El sistema debe ser eficiente en función el tiempo cuando se obtienen los reportes de inventarios.
8.2 Análisis y gestión de riesgos
El desarrollo de un proyecto implica determinados riesgos por lo cual es importante llevar a cabo
un análisis y gestión de los posibles riesgos que tendrá este proyecto. Este proceso está ligado a
fases ordenadas, iniciando con la identificación de cada uno de los riesgos, posteriormente se
realiza el respectivo análisis y priorización de los riesgos los mismos que serán de gran
importancia. Estos resultados sirven posteriormente para la priorización de los riesgos. Su
exposición se determina multiplicando la probabilidad del riesgo y el impacto del riesgo
8.2.1 Identificación de riesgos
En esta etapa se identificaron 13 posibles riesgos lo cuales se pueden presentar en el transcurso

del desarrollo mismos que pueden provocar retrasos en la entrega del producto, ocasionando
posibles pérdidas económicas.
A continuación, se detallan los riesgos identificados:
Tabla 34: Identificación de riesgos

Identific Descripción del riesgo Categoría Consecuencias
ación
Sistema LULY SaaS
Página 13
MANUAL TÉCNICO
R_01 Mala estimación de tiempo de R. Proyecto Pérdida de tiempo y dinero
proyecto
R_02 Mal diseño y desarrollo de la R. Proyecto Redundancia e inconsistencia de datos.

Base de Datos.
R_03 Mala recolección de R. Proyecto Los desarrolladores recogen la información y lo

información para los requisitos proyectan en nuevas funcionalidades que no han
funcionales. sido requeridas por el Departamento,
ocasionando retraso en la entrega del Proyecto.
R_04 Desconocimiento de las R. Técnico Costos adicionales para capacitar a

herramientas de desarrollo. desarrolladores.
R_05 Mala planificación de los R. Proyecto Incremento de costos y tiempo.

recursos a emplear y el tiempo
requerido para el proyecto
R_06 Cambio de Directivos en el R. Negocio Suspensión parcial o definitiva del proyecto.

departamento financiero que no
está de acuerdo con el proyecto
o tiene otras prioridades.
R_07 Incumplimiento de entregables a R. Proyecto Retraso en la entrega del proyecto.

tiempo
R_08 No se tiene acceso exitoso a la R. Proyecto Retraso en la entrega del proyecto

base de datos centralizada
existente que requiere el sistema.
R_09 Retiro inesperado de algún R. Proyecto Retraso en la entrega del proyecto.

integrante del equipo de
desarrollo.
R_10 Poco personal para el desarrollo R. Proyecto Retraso en la entrega del proyecto.
del proyecto
R_11 Incomprensión entre los R. Proyecto Abandono de algún integrante del equipo, cargo
integrantes de desarrollo. excesivo de trabajo.
R_12 Dificultad para extraer R. Proyecto Dificultad en la implementación del sistema.

información de la Base de Datos
centralizada.
R_13 Falta de servicios de R. Técnico Retraso en la entrega del proyecto

conectividad
Realizado por: Ulcuango, Lucero y Yaguachi, Alex, 2020.

Sistema LULY SaaS
Página 14
MANUAL TÉCNICO
8.2.2 Análisis de riesgos
Los riesgos fueron clasificados en tres categorías que se detallas a continuación:
• Riesgos del Proyecto: Estos riesgos afectan específicamente el desarrollo del proyecto, para
el desarrollo de este sistema se detectaron 10 riesgos de esta categoría.
• Riesgos Técnicos: Estos riesgos afectan directamente a los recursos que permiten la
realización del proyecto en este análisis se determinaron 2 de este tipo.
• Riesgos del Negocio: Este tipo de riesgos son las perjudiciales pues afecta a la rentabilidad
de una empresa determinada y perjudica con mayor impacto el desarrollo del proyecto para
esta labor se detectaron 1 riesgos de este tipo.
8.2.3 Valorización de riesgos
Para esta fase se realizó un estudio completo de cada riesgo identificando sus características
principales y grado de afectación si ocurrieran dentro del desarrollo del proyecto para este estudio
se utilizaron criterios de valoración aprobados por El consejo de la Federación de Asociaciones
Europeas de Gerencia de Riesgos (FERMAN).
8.2.3.1 Criterios de valoración de la probabilidad
La probabilidad de que ocurra un riesgo ha sido cuantificada de acuerdo con los siguientes
criterios:
Tabla 35: Criterios de valoración de la probabilidad

RANGO DE DESCRIPCIÓN VALOR
PROBABILIDADES
1% - 33% BAJA 1
34% – 67% MEDIA 2
68% -99% ALTA 3
8.2.3.2 Criterios de valoración del impacto
El impacto del riesgo ha sido valorado en función de aspectos como retrasos en la entrega del
producto e impacto técnico de acuerdo con los siguientes parámetros:
Sistema LULY SaaS
Página 15
MANUAL TÉCNICO
Tabla 36:Criterios de valoración del impacto
IMPACTO IMPACTO TÉCNICO VALOR
BAJO Ligero efecto en el desarrollo del proyecto 1
MODERADO Moderado efecto en el desarrollo del 2

proyecto
ALTO Severo efecto en el desarrollo del proyecto 3
CRÍTICO Proyecto no puede ser culminado 4
8.2.3.3 Criterios de valoración de la exposición al riesgo
La exposición al riesgo ha sido determinada multiplicando la probabilidad del riesgo y el impacto

del riesgo y se la ha categorizado de la siguiente manera:
Tabla 37: Criterios de valoración de la exposición al riesgo

EXPOSICIÓN AL VALOR COLOR
RIESGO
BAJA 1o2 1
MEDIA 3o4 2
ALTA Mayor a 6 3
Tabla 38:Criterios de valoración impacto de probabilidad
Impacto BAJO = 1 MODERADO= 2 ALTO =3 CRITICO=4

Probabilidad.
ALTA = 3 3 6 9 12
MEDIA= 2 2 4 6 8
BAJA = 1 1 2 3 4
En base a los criterios expuesto se clasificaron los riesgos determinados anteriormente de la

siguiente manera
Sistema LULY SaaS
Página 16
MANUAL TÉCNICO
Tabla 39: Clasificación de riesgos

Identif Descripción Probabilidad Impacto Exposición al
icació riesgo
n
% Probabilidad Valor Impacto Valor Exposició Val

n or
R_01 Mala estimación de 40% MEDIA 2 MODERA 2 MEDIA 4

tiempo de proyecto DO
R_02 Mal diseño y 30% MEDIA 2 CRITICO 4 ALTA 8

desarrollo de la Base
de Datos.
R_03 Mala recolección de 80% ALTA 3 CRITICO 4 ALTA 12

información para los
requisitos
funcionales.
R_04 Desconocimiento de 10% BAJA 1 BAJO 1 BAJA 1

las herramientas de
desarrollo.
R_05 Mala planificación 75% ALTA 3 CRITICO 4 ALTA 12

de los recursos a
emplear y el tiempo
requerido para el
proyecto
R_06 Cambio de 80% ALTA 3 CRITICO 4 ALTA 12

Directivos en el
departamento de
finanzas que no está
de acuerdo con el
proyecto o tiene
otras prioridades.
R_07 Incumplimiento de 70 ALTA 3 ALTO 3 ALTA 9

entregables a tiempo
R_08 No se tiene acceso 50% MEDIA 2 MODERA 2 MEDIA 4

exitoso a la base de DO
datos centralizada
existente que
requiere el sistema.
Sistema LULY SaaS
Página 17
MANUAL TÉCNICO
R_09 Retiro inesperado de 55% MEDIA 2 ALTO 3 ALTA 6
algún integrante del
equipo de
desarrollo.
R_10 Poco personal para 70% ALTA 3 ALTO 3 ALTA 9

el desarrollo del
proyecto.
R_11 Incomprensión entre 33% BAJO 1 BAJO 1 BAJA 1

los integrantes de
desarrollo.
R_12 Dificultad para 35% MEDIA 2 MODERA 2 MEDIA 4

extraer información DO
de la Base de Datos
centralizada.
R_13 Falta de servicios de 10% BAJA 1 ALTO 3 MEDIA 3

conectividad
8.2.4 Priorización de riesgos
Para poder realizar la gestión de los riesgos establecidos se los establecieron según su exposición
siendo descrita con color rojo a los de mayor impacto, por lo cual su gestión se realizó
inicialmente, a continuación, se detallan la priorización de los riesgos del proyecto:
Tabla 40: Priorización de riesgos

IDENTIFICADOR DESCRIPCIÓN RIESGO EXPOSICIÓN VALOR PRIORIDAD
Mala recolección de información

R_03 ALTA 12 1
para los requisitos funcionales.
Mala planificación de los recursos

R_05 a emplear y el tiempo requerido ALTA 12 1
para el proyecto
Cambio de Directivos en el
departamento de finanzas que no
R_06 ALTA 12 1
está de acuerdo con el proyecto o
tiene otras prioridades.
Incumplimiento de entregables a
R_07 ALTA 9 2
tiempo
Poco personal para el desarrollo

R_10 ALTA 9 2
del proyecto.
Sistema LULY SaaS
Página 18
MANUAL TÉCNICO
Mal diseño y desarrollo de la Base

R_02 ALTA 8 3
de Datos.
Retiro inesperado de algún
R_09 integrante del equipo de ALTA 6 4
desarrollo.
Mala estimación de tiempo de
R_01 MEDIA 4 5
proyecto
No se tiene acceso exitoso a la

R_08 base de datos centralizada MEDIA 4 5
existente que requiere el sistema.
Dificultad para extraer
R_12 información de la Base de Datos MEDIA 4 5
centralizada.
R_13 Falta de servicios de conectividad MEDIA 3 3
Desconocimiento de las
R_04 BAJA 1 6
herramientas de desarrollo.
Incomprensión entre los

R_11 BAJA 1 6
integrantes de desarrollo.
8.2.5 Gestión de riesgos
Con el fin de evitar el mal manejo de los riesgos si estos llegan a suceder se plantearon estrategias
que ayuden al grupo de trabajo a manejar estos inconvenientes y que se puedan tomar decisiones
que eviten dificultades que puedan perjudicar el desarrollo del proyecto. Para el proyecto se
determinaron 13 hojas de gestión las mismas que fueron documentadas siguiendo un orden de
prioridad establecido en el estudio anterior cada una cuenta con estrategias de control y
seguimiento.
Tabla 41: Hoja de gestión de riesgo R_01
HOJA DE GESTIÓN DE RIESGO

ID. DEL RIESGO: R_01 FECHA: 04-11-2020
Probabilidad: media Impacto: moderado Exposición: media Prioridad: 5
Valor: 2 Valor: 2 Valor: 4
DESCRIPCIÓN: Mala estimación de tiempo de proyecto.
REFINAMIENTO:
Causas:
• Mala planificación del tiempo de desarrollo.

Sistema LULY SaaS
Página 19
MANUAL TÉCNICO
• Mala comunicación con el cliente.

Consecuencia:
• Reducción de ganancias.
• Pérdida de tiempo.
REDUCCIÓN:
• Establecer las políticas, procedimientos y documentación que es necesario recopilar para la
planificación, ejecución y control de la programación del proyecto.
• Identificar y documentar las acciones concretas que será necesario realizar para producir los
entregables del proyecto.
• Definir las relaciones entre las distintas actividades del proyecto.
SUPERVISIÓN:
• Desarrollar el cronograma de proyecto.

• Control del cronograma.
• Actualizar el avance del proyecto.
GESTIÓN:
• Aplicar la regla del 80/20

• Recomposición del esquema.
ESTADO ACTUAL:
Fase de reducción iniciada □

Fase de Supervisión iniciada □
Gestionando el riesgo: □
RESPONSABLE:
Lucero Ulcuango
Alex Yaguachi
HOJA DE GESTIÓN DE RIESGO

Probabilidad: Media Impacto: Crítico Exposición: Alta Prioridad: 3
DESCRIPCIÓN: Mal diseño y desarrollo de la Base de Datos.
REFINAMIENTO:
Causas:
• Mala comunicación entre el cliente y el equipo de trabajo.

• Falta de atributos y tablas en la base de datos.
• Mala relación entre tablas.
Sistema LULY SaaS
Página 20
MANUAL TÉCNICO
Consecuencia:
• Retraso del proyecto.
• No cumplir con los requisitos establecidos.
REDUCCIÓN:
• Reunirse con el personal para determinar las causas del mal funcionamiento.
• Rediseño de la base de Datos.
• Listar entidades y relaciones.
• Realizar la adecuada normalización de las tablas.
SUPERVISIÓN:
• Actitud de los miembros del proyecto

• Grado de compromiso del equipo
• Revisión de los estándares de normalización de las tablas de la Base de Datos
• Revisión del cumplimiento de los requisitos establecidos al principio del proyecto
• Revisión de los estados de las consultas realizadas a la Base de Datos
GESTIÓN:
• Se tienen copias de la documentación del trabajo.

• El jefe del proyecto puede volver a asignar los recursos y reajustar la planificación.
• Pedir al equipo de trabajo, instalar parches para el funcionamiento de la base.
• Rediseñar las relaciones y tablas que sean necesarias.
ESTADO ACTUAL:

RESPONSABLE:
Lucero Ulcuango
Alex Yaguachi
HOJA DE GESTIÓN DEL RIESGO

Probabilidad: Alta Impacto: Crítico Exposición: Alta Prioridad: 1
DESCRIPCIÓN: Mala recolección de información para los requisitos funcionales.

REFINAMIENTO:
Causas:
• Falta de comunicación con el cliente
• Visión de los desarrolladores diferente que la del cliente
Sistema LULY SaaS
Página 21
MANUAL TÉCNICO
• Dificultad del cliente para relacionar sus necesidades con los requerimientos dados Dificultad del
desarrollador de capturar la información relevante de los requisitos
Consecuencias:
• Incremento en los costos de desarrollo
• Retraso del proyecto
• Difícil mantenimiento del software
• Mala calidad del software
REDUCCIÓN:
• Interacción con el cliente en cada fase del desarrollo para ir validando los requerimientos
• Documentar cada requisito e ir controlando el cumplimiento de estos.
• Si es posible corregir los errores antes de que inicie el proyecto
• Elegir una metodología de desarrollo que sea flexible a cambios
SUPERVISIÓN:
• Grado de compromiso del equipo de desarrollo en el proyecto
• Mejor relación del equipo desarrollador con el cliente
• Comprobar el cumplimiento de los estándares de documentación
• Verificar la correcta adaptación de los nuevos cambios al proyecto
GESTIÓN:
• Flexibilidad adaptando los nuevos cambios sin afectar los avances desarrollados
• Estimar nuevos costos por los cambios a realizar
• Realizar cambios con el menor costo
• Llegar a un acuerdo con el cliente sobre el incremento del costo y la fecha de entrega del proyecto
por los nuevos cambios a realizar.
• Nueva asignación de recursos y reajuste de planificación
ESTADO ACTUAL:
RESPONSABLE:
Lucero Ulcuango
Alex Yaguachi

Probabilidad: Baja Impacto: Baja Exposición: Baja Prioridad: 6
DESCRIPCIÓN: Desconocimiento de las herramientas de desarrollo.

REFINAMIENTO:
Causas:
Sistema LULY SaaS
Página 22
MANUAL TÉCNICO
• Falta de comunicación mutua entre desarrolladores.

• No existe suficiente presupuesto para contratar a personal adecuado para el desarrollo del sistema.
Consecuencias:
• Incremento en los costos de desarrollo.
• Suspensión temporal del proyecto.
• Postergación del proyecto a entregar.
REDUCCIÓN:
• Los desarrolladores deben tener los conocimientos necesarios para no tener inconvenientes.
SUPERVISIÓN:
• Desempeño de los miembros del proyecto.
• Relaciones interpersonales de los desarrolladores del sistema.
GESTIÓN:
• Contratar nuevo personal de forma inmediata.
• Capacitación para el nuevo personal de forma inmediata.
• El jefe del proyecto puede volver asignar recursos y reajustar la planificación.
ESTADO ACTUAL:
RESPONSABLE:
Lucero Ulcuango
Alex Yaguachi

DESCRIPCIÓN: Mala planificación de los recursos a emplear y el tiempo requerido para el proyecto.
REFINAMIENTO:
Causas:
• Estimaciones mal desarrolladas.
• No tener en cuenta los posibles problemas o inconvenientes a presentarse.
• Poca comunicación con el cliente.
• Sobrestimar las capacidades del equipo de desarrollo.
• Falta de reuniones con el equipo de trabajo.
Sistema LULY SaaS
Página 23
MANUAL TÉCNICO
Consecuencias:
• Replanificación del proyecto
• Incremento de los costos en el desarrollo hasta equilibrar el tiempo de avance
• Sobrecarga de trabajo al equipo de desarrollo
• Generación de costos no planificados e incremento del costo de proyecto.
REDUCCIÓN:
• Estimar todos los posibles inconvenientes a presentarse
• Comunicación con el equipo de desarrollo
• Conocer las capacidades de cada integrante del equipo de desarrollo
• Establecer con los involucrados en el proyecto, tiempo de ejecución y cumplimiento de fases y
avances del proyecto
SUPERVISIÓN:
• Compromiso del equipo en el proyecto
• Verificar el cumplimiento de la replanificación
• Reuniones con los involucrados del proyecto.
• Grado de compromiso del equipo.
GESTIÓN:
• Reajuste de planificación
• Mejorar el desarrollo de estimaciones
• Identificar cambios a realizarse
ESTADO ACTUAL:
RESPONSABLE:
Lucero Ulcuango
Alex Yaguachi


Valor: 3 Valor: 12
Valor: 4
DESCRIPCIÓN: Cambio de Directivos en el departamento de finanzas que no está de acuerdo con el proyecto
o tiene otras prioridades.
REFINAMIENTO:
Sistema LULY SaaS
Página 24
MANUAL TÉCNICO
Causas:
• Falta de presupuesto para el desarrollo del proyecto.
• Mal ambiente de trabajo
• Malentendidos entre directivos y programadores
Consecuencias:
• Replanificación de tareas dadas por la nueva directiva.
• Suspensión definitiva del proyecto
• Desacuerdos entre integrantes del proyecto
• Retrasos en las entregas de avances del proyecto en fechas ya determinadas.
• Retraso en la presentación del proyecto final.
REDUCCIÓN:
• Aceptar los cambios planteados en reuniones con los clientes.
• Reunirse con el personal para determinar las causas del cambio de Directiva del proyecto.
• Actuar para reducir estas causas antes de que continúe el proyecto.
• Asegurarse de desarrollar técnicas que garanticen la continuidad del trabajo cuando se vaya la gente
SUPERVISIÓN:
• Grado de compenetración del equipo
• Condición que se ha cordado con cada uno de los miembros con la directiva
• Relaciones interpersonales
• Revisar la planificación del proyecto y realizar la replanificación de tareas para entregar el producto
final en los tiempos acordados anteriormente.
GESTIÓN:
• Realizar reuniones diarias con los nuevos Clientes.
• Aceptar los nuevos cambios de funcionalidades que poseerá el sistema.
ESTADO ACTUAL:

RESPONSABLE:
Alex Yaguachi
Lucero Ulcuango
Probabilidad: Alta Impacto: Alta Exposición: Alta Prioridad: 2

Sistema LULY SaaS
Página 25
MANUAL TÉCNICO
DESCRIPCIÓN: Incumplimiento de entregables a tiempo
REFINAMIENTO:
Causas:
• Hacer un presupuesto limitado.
• Escaso nivel de enfoque en la creación de un proyecto
• Falta de experiencia en la administración de un proyecto.
• No tener en cuenta alternativas más baratas.
Consecuencias:
• Insatisfacción del equipo de trabajo por salarios bajos.
• No tener los equipos necesarios para la creación del proyecto.
REDUCCIÓN:
• Realizar una estimación económica en base a lo que necesita el cliente.
SUPERVISIÓN:
• Realizar las tareas en base a la planificación del proyecto y con las con las necesidades del cliente
y no con una sobrecarga de trabajo sobre una tarea del sistema.
GESTIÓN:
• Tener metas certeras en el financiamiento permitirá alcanzar los objetivos.
• Adquirir varias propuestas de elementos con sus costos para minimizar pérdidas económicas.
• No sobre estimar tareas innecesarias para el sistema.
ESTADO ACTUAL:
RESPONSABLE:
Lucero Ulcuango
Alex Yaguachi

Probabilidad: Media Impacto: moderado Exposición: Media Prioridad: 5
DESCRIPCIÓN: No se tiene acceso exitoso a la base de datos centralizada existente que requiere el sistema.
REFINAMIENTO:
Causas:
• Servidores desconectados.
• Falla en la sintaxis del código.
• Desconocimiento de información de la base de datos.
Sistema LULY SaaS
Página 26
MANUAL TÉCNICO
• Fallas eléctricas.
Consecuencias:
• Información errónea.
• Campos en el sistema vacío.
• Pérdida de Datos.
• Déficit en la información extraída.
REDUCCIÓN:
• Mantener un diálogo con el personal encargado del área de Desarrollo y Mantenimiento.
• Mantener un archivo de respaldo con la conexión a la base de datos.
• Analizar las causas por lo que deciden dejar su trabajo.
SUPERVISIÓN:
• Poseer entre los archivos diferentes comandos que ayuden a la extracción de información de la base
de datos.
GESTIÓN:
• Resolver de forma eficiente la conexión de la base de datos.
• El encargado del área de Desarrollo y Mantenimiento deberá actuar de manera inmediata ante los
fallos presentados en el proceso de Desarrollo del Proyecto.
ESTADO ACTUAL:
RESPONSABLE:
Lucero Ulcuango
Alex Yaguachi

Probabilidad: Media Impacto: Alta Exposición: Alta Prioridad: 4
DESCRIPCIÓN: Retiro inesperado de algún integrante del equipo de desarrollo.

REFINAMIENTO:
Causas:
• Sueldos no pagados a tiempo.
• Existe un mal ambiente de trabajo.
• Sobrecarga de trabajo en el equipo.
Consecuencias:
• Capacitación necesaria a nuevos empleados
REDUCCIÓN:
Sistema LULY SaaS
Página 27
MANUAL TÉCNICO
• Revisión de los fallos del sistema.

• Dialogar sobre el ambiente de trabajo.
• Analizar las causas por lo que deciden dejar su trabajo.
SUPERVISIÓN:
• Mejorar la relación entre empleados y jefes del proyecto.
• Supervisar la actitud de los miembros del proyecto.
• Suspensión de pagos temporalmente.
GESTIÓN:
• Revisión de los contratos.
• Capacitación a los miembros sobre el trabajo por parte de quien lo está dejando.
• Asignación de carga de trabajo
ESTADO ACTUAL:
RESPONSABLE:
Lucero Ulcuango
Alex Yaguachi

Probabilidad: Media Impacto: Alta Exposición: Media Prioridad: Media
DESCRIPCIÓN: Falta de personal necesario para el desarrollo del proyecto.

REFINAMIENTO:
Causas:
• No posee recursos para contrato de Nuevo Personal
• No existe una compenetración del equipo de trabajo.
Consecuencias:
REDUCCIÓN:
• Actuar para reducir estas causas antes de que empiece el proyecto.
• Organizar equipos de trabajo para que cada actividad sea conocida por algunas personas
• Definir estándares de documentación y controlar el cumplimiento de su uso.
SUPERVISIÓN:
• Grado de compenetración del equipo
• Comprobar que los estándares de documentación se estén cumpliendo
GESTIÓN:
Sistema LULY SaaS
Página 28
MANUAL TÉCNICO
• Revisión de los contratos.

• Capacitación a los nuevos miembros sobre el trabajo por parte de quien lo está dejando.
• Asignación de carga de trabajo
ESTADO ACTUAL:
RESPONSABLE:
Lucero Ulcuango
Alex Yaguachi

Probabilidad: Baja Impacto: Exposición: Baja Prioridad: Baja
Valor: 1 Moderado Valor: 2
Valor: 2
DESCRIPCIÓN: Incomprensión entre los integrantes de desarrollo.
REFINAMIENTO:
Causas:
• Mala comunicación entre los miembros del equipo
• El equipo de desarrollo del sistema no mantiene buenas relaciones para poder gestionar el proyecto.
• Desacuerdos en las decisiones para realizar funcionalidades.
• Opiniones divididas en la toma de decisiones que beneficien al desarrollo del proyecto
Consecuencias:
• Retraso de la ejecución del proyecto.
• Incumplimiento de las actividades designadas a los miembros del equipo de desarrollo.
REDUCCIÓN:
• Mejorar las relaciones dentro del equipo de desarrollo.
• Gestionar de manera adecuada las diferentes actividades que se realizarán durante el desarrollo del
sistema.
SUPERVISIÓN:
• Supervisar las diferentes actividades a realizarse para tener un control adecuado de las0 mismas y
así verificar que estas se estén realizando.
GESTIÓN:
• Reuniones de socialización con los miembros del equipo de desarrollo para resolver posibles
desacuerdos surgidos.
• Verificación de actividades asignadas a cada uno de los miembros del equipo de desarrollo.
Sistema LULY SaaS
Página 29
MANUAL TÉCNICO
ESTADO ACTUAL:
RESPONSABLE:
Lucero Ulcuango
Alex Yaguachi

Probabilidad: Media Impacto: Alta Exposición: Media Prioridad: Media
DESCRIPCIÓN: Dificultad para extraer información de la Base de Datos.

REFINAMIENTO:
Causas:
• Servidores desconectados.
• Falla en la sintaxis del código.
Consecuencias:
• Información errónea.
• Pérdida de Datos.
REDUCCIÓN:
• Mantener un diálogo con el personal encargado del área de Desarrollo y Mantenimiento.
• Mantener un archivo de respaldo con la conexión a la base de datos.
SUPERVISIÓN:
• Poseer entre los archivos diferentes comandos que ayuden a la extracción de información de la base
de datos.
GESTIÓN:
• Resolver de forma eficiente la conexión de la base de datos.
• El encargado del área de Desarrollo y Mantenimiento deberá actuar de manera inmediata ante los
fallos presentados en el proceso de Desarrollo del Proyecto.
ESTADO ACTUAL:
RESPONSABLE:
Lucero Ulcuango
Sistema LULY SaaS
Página 30
MANUAL TÉCNICO
Alex Yaguachi

Probabilidad: Baja Impacto: Alto Exposición: Media Prioridad: 3
DESCRIPCIÓN: Falta de servicios de conectividad.

REFINAMIENTO:
Causas:
• No existen proveedores del servicio en la zona.
• Alto costo del servicio.
Consecuencias:
• Demoras en el proceso de desarrollo.
• Retraso del proyecto. Mala calidad del software
REDUCCIÓN:
• Pago del servicio de conectividad móvil.
• Trabajo en casa.
SUPERVISIÓN:
● Comprobar que el servicio móvil cumpla con las necesidades de todos.
● Dar seguimiento constante al desarrollo desde casa
GESTIÓN:
• Contratación del servicio de conectividad satelital en la empresa.
ESTADO ACTUAL:
RESPONSABLE:
Lucero Ulcuango
Alex Yaguachi
8.3 Análisis de factibilidad

El estudio de factibilidad es importante ya que en esta etapa es necesaria la recolección de datos
necesarios que define si el desarrollo del proyecto para la empresa Industria Textil Paoli´s es
factible o no el desarrollo tanto para los desarrolladores como para el usuario final, este análisis
tiene como base la determinación de la infraestructura tecnológica y la capacidad técnica que
implica la implementación del sistema, así como los costos, beneficios y el grado de aceptación,
Sistema LULY SaaS
Página 31
MANUAL TÉCNICO
es por ellos que se debe tomar en cuenta los recursos que dispone el equipo de desarrollo antes de
poner en marcha el desarrollo del sistema.
8.3.1 Factibilidad técnica
La factibilidad técnica consiste en la evaluación de los recursos tecnológicos tanto los existente y
los que se requieren para el desarrollo e implementación del sistema.
Tabla 54: Hardware existente
Cantidad Descripción Estado
1 Computadora: LENOVO, SO de 64bits, Procesador Intel i7, Funcional

Memoria RAM 8GB, Disco Duro: 1 TB, Disco Sólido 128
GB
1 Computadora: DELL SO de 64bits, Procesador Intel i7, Funcional

Memoria RAM 16 GB, Disco Duro: 1 TB.
1 Impresora Canon Funcional
2 Memorias USB 16 GB Funcional
2 Modem de Internet Funcional
Tabla 55: Hardware requerido

Cantidad Descripción Observaciones
Al implementarse el sistema para gestión de inventarios bajo el modelo de software como servicio
(SAAS) no será necesaria la adquisición de ninguna herramienta física en la empresa ya que los
equipos servidores serán manejados por el proveedor del servicio.
Tabla 56: Software existente
Nombre Descripción Estado
Windows 10 Sistema Operativo Legal
COCOMO II Programa para realizar estimaciones del proyecto Legal
IDE NETBEANS Para el desarrollo del sistema Legal
Node js Herramienta de desarrollo Legal

Sistema LULY SaaS
Página 32
MANUAL TÉCNICO
Angular Cli Framework Legal
Visual Studio code Editor de código Legal
Lector de PDF Software que permite ver e imprimir los reportes. Legal
Ubuntu server Servidor Legal
MySQL Gestor de la Base de Datos Legal
Payara Server Servidor de aplicaciones Legal
Postman ADE Entorno de desarrollo API (Testing) Legal
Tabla 57: Software requerido

Nombre Descripción Estado
Power Designer Herramienta para modelizar datos Versión de

prueba
Tabla 58: Personal existente
Nombre Función
Alex Yaguachi Desarrollador
Lucero Ulcuango Desarrollador
Tabla 59: Personal requerido

Función Formación académica Experiencia en:
8.3.2 Factibilidad operativa
(SAAS) no será necesario incurrir en costos de operación ya que esta tarea estará a cargo del
proveedor del servicio.
Tabla 60: Recursos Humanos

Recursos Humanos
Sistema LULY SaaS
Página 33
MANUAL TÉCNICO
Personal Función
Alex Yaguachi Técnico de soporte
Lucero Ulcuango Técnico de soporte
8.3.3 Factibilidad económica
Para el desarrollo del sistema se requiere de un costo de personal total de $3600.00, el costo es
considerablemente bajo para el desarrollo, pero se debe tomar en cuenta que el valor total va a ser
$0 ya que se trata de un proyecto de titulación.
En cuanto a los costos de hardware se obtuvo la suma de $ 0 ya que los integrantes del grupo de
desarrollo cuentan con computadoras y demás hardware necesario para la realización del sistema,
como Memorias USB y costos de software es $0 ya que los recursos necesarios para la
implantación del sistema son de uso libre.
La administración del sistema requiere de distintos parámetros con los cuales será factible
determinar los costos en la utilización e instalación del sistema, por ello estos factores incluyen
la capacitación del personal en cuanto al manejo adecuado del sistema.
Tabla 61: Costo de personal

Cantidad Cargo Pago mensual Meses Total
2 Desarrollador $450,00 4 $3.600,00
Total $3.600,00
Tabla 62: Costos de Hardware y Software

Cantidad Descripción Valor Unitario Valor Total
2 Windows 10 Gratuito Gratuito
1 COCOMO II Gratuito Gratuito
2 Power Designer Versión de evaluación Versión de evaluación
2 IDE NETBEANS Gratuito Gratuito
2 Node js gratuito Gratuito
2 Angular Cli Gratuito Gratuito
2 Visual Studio Code Gratuito Gratuito
2 Lector de PDF Gratuito Gratuito

Sistema LULY SaaS
Página 34
MANUAL TÉCNICO
2 MySQL Gratuito Gratuito
1 Ubuntu server Gratuito Gratuito
2 Payara Server Gratuito Gratuito
2 Postman ADE Gratuito Gratuito
Total, costos de Desarrollo $ 0,00
Costo de Hardware: $ 0, 00 ya que el grupo de desarrollo cuenta con sus propias computadoras y
dispositivos de almacenamiento para guardar y respaldar la información (Memorias USB).
Costo de software es $0 ya que los recursos necesarios para la implantación del sistema son de
uso libre.
8.3.3.1 COSTOS DE INSTALAR EL SISTEMA
Tabla 63: Costos de Capacitación a usuarios

Cantidad Descripción Valor por hora Valor Total
1 Capacitación general $ 50,00 $ 50,00
Total $ 50,00
(SAAS) será necesaria una capacitación general para el usuario que contrate el servicio con el fin
de que tenga claro el funcionamiento del sistema y pueda solicitar cambios o nuevos desarrollos
en caso de que lo considere necesario.
Tabla 64: Costos de operación

Cantidad Descripción Valor Mensual Valor Total
Total $ 0,00
Los costos de operación no se consideran necesarios ya que esto es proporcionado por parte de
los proveedores del servicio SaaS, lo cual representa una ventaja bastante considerable para el
usuario esto en cuanto al costo que no es necesario ya que este se incluye en el pago mensual de
la suscripción al servicio.
El costo total del proyecto fue de $ 3650,00 lo cual demuestra es bastante factible su realización.
Sistema LULY SaaS
Página 35
MANUAL TÉCNICO
Sistema LULY SaaS
Página 36
MANUAL TÉCNICO
9 FASE DE PLANIFICACIÓN
El desarrollo de la planificación del proyecto a desarrollarse es una etapa importante ya que nos
permite ordenar de manera sistemática las tareas para lograr los objetivos planteados de esta
manera se puede exponer lo que se necesita hacer y cómo se debe llevar a cabo el desarrollo.
9.1 Estimaciones
El objetivo de estimar es para determinar el tiempo que tomara el desarrollo del sistema, se debe
tomar en cuenta todas las variables o indicadores involucrados en la gestión del proyecto tales
como el tiempo, el esfuerzo y cantidad de personas que intervienen en el proceso del desarrollo
se debe tomar en cuenta el tipo de metodología de desarrollo ya que esta también influye en el
proceso.
Tabla 65: TABLA ILF/ EIF

RET DET
1 a 19 20 a 50 51 o más
1 Baja Baja Media
2a5 Baja Media Alta
6 o más Media Alta Alta
Tabla 66: ENTRADA EXTERNA

FTR DET
1a4 5 a 15 16 o más
0a1 Baja Baja Media
2 Baja Media Alta
Tabla 67: SALIDA EXTERNA

FTR DET
Sistema LULY SaaS
Página 37
MANUAL TÉCNICO
1a4 5 a 19 20 o más
0a1 Baja Baja Media
2a3 Baja Media Alta
CONSULTA EXTERNA
Tabla 68: ENTRADA

FTR DET
1a4 5 a 15 16 o más
0a1 Baja Baja Media
2 Baja Media Alta
SALIDA
Tabla 69: Salida

FTR DET
1a4 5 a 19 20 o más
0a1 Baja Baja Media
2a3 Baja Media Alta
Tabla 70: ILF: INTERNAL LOGIC FILE (Archivo lógico interno)

Fichero lógico interno Complejidad
No. DET No. RET
Usuarios 7 2 Baja
Proveedor 5 1 Baja
Sistema LULY SaaS
Página 38
MANUAL TÉCNICO
Módulo 3 1 Baja
Materia prima 6 4 Baja
Productos 6 1 Baja
Categoría_producto 2 1 Baja
Categoría_materia prima 2 1 Baja
Talla 2 1 Baja
Color 2 1 Baja
Empresa 7 1 Baja
Suscripción 2 1 Baja
Orden_pago 4 2 Baja
Plan 3 1 Baja
Usuario_extra 3 1 Baja
Almacen 3 1 Baja
Empleado 5 1 Baja
Pedido 4 3 Baja
Compras 3 3 Baja
Estanteria 3 1 Baja
Cliente 6 1 Baja
Costo_adicional 3 1 Baja
Datos_costo 5 1 Baja
Tabla 71: EIF: EXTERNAL INTERFACE FILE (Archivo lógico externo)

Archivos de interfaces
externas
No. DET No. RET Complejidad
Sistema LULY SaaS
Página 39
MANUAL TÉCNICO
Tabla 72: EI: Entrada externa

Entrada externa Función Número de entradas
Registro de usuario ingresar/modificar 2
Registro de empresa ingresar/modificar 2
Registrar proveedores ingresar/modificar 2
Registro de materia prima ingresar/modificar 2
Registro de productos ingresar/modificar 2
Registro de módulos ingresar/modificar 2
Registro de planes ingresar/modificar 2
Registro de pagos ingresar/modificar 2
Registro de almacenes ingresar/modificar 2
Registrar talla ingresar/modificar 2
Registrar color ingresar/modificar 2
Registrar categoría_materiaprima ingresar/modificar 2
Registrar categoría_producto ingresar/modificar 2
Entrada externa No. FTR No. DET Complejidad
Registro de usuario 1 7 Baja
Registro de empresa 1 7 Baja
Registrar proveedores 1 5 Baja
Registro de materia prima 3 6 Baja
Registro de productos 2 6 Baja
Registro de módulos 1 3 Baja

Sistema LULY SaaS
Página 40
MANUAL TÉCNICO
Entrada externa No. FTR No. DET Complejidad
Registro de planes 1 3 Baja
Registro de pagos 2 4 Baja
Registro de almacenes 1 3 Baja
Registrar talla 1 2 Baja
Registrar color 1 2 Baja
Registrar categoría materia prima 1 2 Baja
Registrar categoría producto 1 2 Baja
Modificar usuario 1 7 Baja
Modificar empresa 1 7 Baja
Modificar proveedores 1 5 Baja
Modificar materia prima 3 6 Baja
Modificar productos 3 6 Baja
Modificar módulos 1 3 Baja
Modificar planes 1 3 Baja
Modificar pagos 2 4 Baja
Modificar almacenes 1 3 Baja
Modificar talla 1 2 Baja
Modificar color 1 2 Baja
Modificar categoría materia prima 1 2 Baja
Modificar categoría producto 1 2 Baja
Tabla 73: EO salida externa

Salida externa Función Número de entradas
Reporte de existencia de productos Pantalla/papel 2

Sistema LULY SaaS
Página 41
MANUAL TÉCNICO
Reportes de existencia de materia prima Pantalla/papel 2
Reportes de ordenes de pedido Pantalla/papel 2
Reporte de orden de compra Pantalla/papel 2
Notificación de expiración de suscripción Pantalla 1
Salida externa No FTR No DET Complejidad
Reporte de existencia de productos 6 8 Alta
Reportes de existencia de materia prima 5 6 Alta
Reportes de ordenes de pedido 12 10 Alta
Reporte de orden de compra 7 6 Alta
Notificación de expiración de suscripción 3 1 Baja
Tabla 74: EQ consulta externa

Consulta externa Función Número de entradas
Buscar y visualizar los datos de un producto en Pantalla 1

específico
Buscar y visualizar los datos de materia prima Pantalla 1
Buscar y visualizar las ventas de productos de un día Pantalla 1
Buscar y visualizar las ventas de productos de un mes Pantalla 1
Buscar y visualizar las ventas de productos de un año Pantalla 1
Consulta externa ENTRADA SALIDA
DET FTR DE FTR

T
Buscar y visualizar los datos de un producto en específico 1 1 10 9

Sistema LULY SaaS
Página 42
MANUAL TÉCNICO
Buscar y visualizar los datos de materia prima 1 1 5 3
Buscar y visualizar los pedidos de productos que se deben 1 1 7 8

entregar de un día determinado
Consulta externa C. C. Complejid

Entrada Salida ad
Buscar y visualizar los datos de un producto en específico Baja Alta Media
Buscar y visualizar los datos de materia prima Baja Medio Medio
Buscar y visualizar los pedidos de productos que se deben Baja Alto Media
entregar de un día determinado
El proceso empieza desde las estimaciones, se lleva a cabo gracias a la determinación de las
Funciones de Datos en donde obtenemos la información necesaria para los Puntos de Función
requeridos en el modelo matemático como son las entradas, salidas, consultas, archivos internos
y archivos externos que van a estar involucradas en nuestro sistema.
Luego de todo el proceso correspondiente se obtuvo la tabla de resumen de los puntos de función
los cuales serán utilizados para utilizar el software basado en el modelo matemático COCOMO
II
Tabla 75: tabla de resumen de los puntos de función

Parámetro Complejidad Numero Peso Total
ALTO 0 15 0
ILF MEDIO 0 10 0
BAJO 23 7 161
ALTO 0 10 0
EIF MEDIO 0 7 0
BAJO 0 5 0
ALTO 0 6 0
EI MEDIO 0 4 0
BAJO 23 3 69
Sistema LULY SaaS
Página 43
MANUAL TÉCNICO
ALTO 4 7 28
EO MEDIO 0 5 0
BAJO 1 4 4
ALTO 0 6 0
EQ MEDIO 3 4 12
BAJO 0 3 0
TOTAL 274
Para el cálculo de estimaciones sobre esfuerzo, tiempo y personal del proyecto usamos el modelo
matemático “COCOMO” utilizando como referencia puntos de función que se obtuvieron
anteriormente.
Figura 2: Resultados puntos de estimación
Como se observa en la Figura 2-3 el total de puntos de función de 274 y un total de 7946 SLOC
que representan las líneas de código.
Sistema LULY SaaS
Página 44
MANUAL TÉCNICO
Figura 3: Resultados preliminares de esfuerzo
Para nuestro caso el modelo intermedio será el que usaremos como se observa en la Figura 3-3,
dado que realiza las estimaciones con bastante precisión.
Figura 4: Representación de resultados finales COCOMO II
Esfuerzo
El esfuerzo necesario para concretar un proyecto de desarrollo de software, cualquiera sea el

modelo empleado, representa el trabajo realizado por las personas cada mes, requerido para
desarrollar el sistema.
Personas
Es todo el recurso humano que va a ser utilizado para desarrollar el sistema en nuestro caso se
dispone de 2 personas, pero con la utilización de la metodología SCRUM.
Tiempo
Representa el tiempo total para que el grupo de desarrollo concluya con el desarrollo del sistema
el cual se va a calcular de acuerdo con el esfuerzo y el número de personas en el proyecto se
determinó un aproximado de desarrollo de 12.8 semanas.
Tabla 76: Resultados Reales de Estimación
Puntos de Función 274
Líneas de Código (SLOC) 8343

Sistema LULY SaaS
Página 45
MANUAL TÉCNICO
Esfuerzo 25.9
Personas 2
Tiempo de Desarrollo 12.8 semanas
𝐸𝑆𝐹𝑈𝐸𝑅𝑍𝑂
𝑇=
𝑁𝑈𝑀 𝑃𝐸𝑅𝑆𝑂𝑁𝐴𝑆
25.9
𝑇=
2
𝑻 =12.95
La Tabla muestra los puntos estimados para cada una de las historias de usuarios, este proceso se
lo realizo con la técnica de estimación T-Shirt, las tallas S, M, L, XL, se toman como referencia
la duración 1 día de trabajo es equivalente a 8 horas de trabajo.
Tabla 77: Técnica de estimación T-Shirt
Talla Puntos
S 3
M 5
L 10
XL 20
9.2 Plan de entrega

Según lo planificado se conoce que el Desarrollo del Sistema se iniciará a partir del 16/11/2020
y culmina el 10/02/2021, se realizó la planificación con 22 requerimientos los cuales se dividieron
en diferentes Sprints; estas iteraciones han sido definidas en base a las reuniones realizadas con
el equipo que desarrollara el sistema.
Todas estas, medidas en horas basados en estos antecedentes el plan de entrega se estructuro de
la siguiente manera:
Sistema LULY SaaS
Página 46
MANUAL TÉCNICO
Tabla 78: Plan de entrega
Fecha Duración
Sprint Tarea Fecha fin
inicio Horas
Sprint 1 16/11/2020 27/11/2020
HT_01 Análisis y definición de la
16/11/2020 27/11/2020 40
arquitectura del sistema.
HT_02 Análisis y definición del estándar

16/11/2020 27/11/2020 40
de la interfaz de usuario.
HT_03 Análisis y definición del estándar

16/11/2020 27/11/2020 40
de programación.
HT_04 Diseñar el esquema de base de
16/11/2020 27/11/2020 40
datos.
Sprint 2 30/11/2020 11/12/2020
HT_05 Implementar el diseño de la base
30/11/2020 11/12/2020 40
de datos.
HT_06 Redacción de documentación. 30/11/2020 11/12/2020 40
HU_01 Registro de usuarios. 30/11/2020 11/12/2020 20
HU_02 Consulta de usuarios registrados. 30/11/2020 11/12/2020 20
HU_03 Eliminar usuarios registrados. 30/11/2020 11/12/2020 20
HU_04 Autenticación de usuario. 30/11/2020 11/12/2020 20

Sprint 3 14/12/2020 25/12/2020
HU_05 Control se sesiones activas de un
14/12/2020 25/12/2020 20
usuario
HU_06 Contratación de servicio de
14/12/2020 25/12/2020 20
gestión de inventarios.
HU_07 Registro de datos de la empresa
14/12/2020 25/12/2020 20
de un usuario.
HU_08 Modificar los datos de una
14/12/2020 25/12/2020 20
empresa de un usuario.
HU_09 Verificación pago de una
14/12/2020 25/12/2020 20
suscripción de un servicio.
HU_10 Notificación de suscripciones por
14/12/2020 25/12/2020 20
expirar.
Sprint 4 28/12/2020 8/1/2021

HU_11 Agregar nuevos planes a un
28/12/2020 1/1/2021 20
módulo.
Sistema LULY SaaS
Página 47
MANUAL TÉCNICO
HU_12 Registro de proveedores de

28/12/2020 1/1/2021 20
materia prima.
HU_13 Modificar proveedores de materia
28/12/2020 1/1/2021 20
prima.
HU_14 Buscar proveedores de materia
4/1/2021 8/1/2021 20
prima.
HU_15 Eliminar proveedores de materia
4/1/2021 8/1/2021 20
prima.
HU_16 Registro de materia prima. 4/1/2021 8/1/2021 20
HU_17 Modificar materia prima. 4/1/2021 8/1/2021 20
Sprint 5 11/1/2021 22/1/2021
HU_18 Buscar materia prima. 11/1/2021 15/1/2021 20
HU_19 Eliminar materia prima. 11/1/2021 15/1/2021 20
HU_20 Registro de productos

18/1/2021 22/1/2021 20
terminados.
HU_21 Modificar productos terminados. 18/1/2021 22/1/2021 20
HU_22 Buscar productos terminados. 18/1/2021 22/1/2021 20
HU_23 Eliminar productos terminados. 18/1/2021 22/1/2021 20
Sprint 6 25/1/2021 5/2/2021
HU_24 Reporte de proveedores 25/1/2021 5/2/2021 20
HU_25 Registro de estantes. 25/1/2021 5/2/2021 20

HU_26 Modificar estantes. 25/1/2021 5/2/2021 20
HU_27 Buscar estantes. 25/1/2021 5/2/2021 20
HU_28 Eliminar estantes. 25/1/2021 5/2/2021 20
HU_29 Reportes de inventarios materia
25/1/2021 5/2/2021 20
prima.
HU_30 Reportes de inventarios
25/1/2021 5/2/2021 20
productos terminados.
HU_31 Reportes de productos en proceso 25/1/2021 5/2/2021 20
Sprint 7 8/2/2021 15/2/2021

HU_32 Pruebas del sistema. 8/2/2021 15/2/2021 80
Total, de horas 1020
Según lo planificado se conoce que el Desarrollo del Sistema se iniciará a partir del 16/11/2020
y culmina el 15/02/2021 como se muestra en la Tabla, se realizó la planificación de 33 historias
de usuario y 5 historias técnicas del sistema los cuales se dividieron en 7 Sprints cada sprint
Sistema LULY SaaS
Página 48
MANUAL TÉCNICO
equivale a dos semanas de trabajo con un total de 255 puntos; cada punto es equivalente a 4 horas
de trabajo lo que da como resultado un total de 1020 horas.
Sistema LULY SaaS
Página 49
MANUAL TÉCNICO
10 DESARROLLO
En este capítulo se describirán las acciones realizadas para el desarrollo del sistema, todas las
actividades se deben desarrollar en un periodo de tiempo mismo que está establecido en el plan
de entrega del proyecto.
10.1 Análisis de proceso del sistema
Con el fin de tener un mejor entendimiento de las actividades que se desarrollaran en el sistema
se crean diagramas que ayuden a comprender el funcionamiento del sistema tanto para la parte
del usuario como para el administrador.
10.2 Conceptualización del sistema para el usuario modulo SaaS
Como se puede observar en la Figura 1-5 , el usuario que requiere realizar la contratación de un
servicio podrá dirigirse a la página principal la misma que contendrá toda la información necesaria
así como los planes que se ofrecen, para lo cual deberá autenticarse en el sistema cuando desee
contratar uno de los planes, posteriormente se requiere que el usuario ingrese la información de
la empresa de tal manera que pueda continuar con la contratación del servicio así también de ser
el caso de que el plan no cumpla con el número de usuarios, este puede agregar usuarios extras
de ser el caso. A continuación, podrá gestionar el pago del plan el mismo que será verificado para
que el usuario pueda acceder al servicio que ha contratado.
Sistema LULY SaaS
Página 50
MANUAL TÉCNICO
Figura 5: Representación del funcionamiento del módulo SaaS para el usuario
10.3 Conceptualización del sistema módulo gestión de inventario
Como se puede observar en la Figura 5 el gerente de la empresa una vez que se ha validado el
pago en el módulo de SaaS este debe volver a autenticarse para poder acceder a todas las
funcionalidades que contiene el sistema de inventarios tales como el registro de empleados,
empresa, proveedores, materia prima, estantes, clientes, productos, pedidos, ordenes de
producción, productos, costos de producción de los productos así también podrá generar los
reportes correspondientes a los pedidos de un cliente, ordenes de producción de un pedido, orden
de comprar de materia prima y reporte de existencias de materia prima.
Sistema LULY SaaS
Página 51
MANUAL TÉCNICO
Figura 6: Representación del funcionamiento del módulo inventario usuario gerente
En la Figura 6 se muestran las funcionalidades que puede realizar el empleado previo a su

autenticación.
Figura 7: Representación del módulo inventario usuario empleado

Sistema LULY SaaS
Página 52
MANUAL TÉCNICO
10.4 SPRINT 1
En este primer sprint se llevaron a cabo 4 historia técnicas, las cuales son importantes ya que en
base a esto se puede partir con el desarrollo, cabe mencionar que dichas historias técnicas no
fueron sugeridas por el usuario, pero son indispensables para los desarrolladores.
10.4.1 HT_01 Análisis y definición de la arquitectura del sistema.
La arquitectura del sistema permite tener una visión global del sistema que se va a desarrollar.
Para el desarrollo de la aplicación móvil como web se tomó en cuenta la Arquitectura MVC
(Cliente, Vista, Controlador) y la arquitectura en N-Capas para el estudio y definición de la
arquitectura para el sistema.
Para el desarrollo del proyecto se definió como arquitectura N- Capas ya que el estudio realizado
demostró que esta arquitectura:
• Reduce el tráfico de información en la red por lo que mejora el rendimiento de los sistemas.
• Las capas se pueden sustituir con implementaciones alternativas de los mismos servicios
básicos.
• Se minimizan dependencias entre capas.
• Las capas posibilitan la estandarización de servicios.
• Luego de tener una capa construida, puede ser utilizada por muchos servicios de mayor nivel.
• Brinda una mayor flexibilidad de desarrollo y de elección de plataformas sobre la cual montar
las aplicaciones.
10.4.1.1 Arquitectura MVC.
La arquitectura Modelo-Vista-Controlador, es la implementación de la arquitectura en tres capas

más extendida.
Modelo Encapsula los datos y las funcionalidades. El modelo es independiente de cualquier

representación de salida y/o comportamiento de entrada. El modelo debe de preservar la
integridad de los datos.
Las principales características del Modelo son:
• Consiste en un conjunto de Clases y Objetos correspondientes al Modelo del Negocio para

nuestra aplicación (estados y funcionalidad).
• Tiene un bajo acoplamiento con Vistas y Controladores.
Sistema LULY SaaS
Página 53
MANUAL TÉCNICO
• En el definen métodos para realizar consultas (informar el estado), comandos (modificar el

estado), y mecanismos de notificación (para informar a los observadores/ vistas)
Vista Es la representación del modelo en forma gráfica disponible para la interacción con el
usuario. En el caso de una aplicación Web, la Vista es una página HTML con contenido dinámico
sobre el cual el usuario puede realizar operaciones.
Las principales características de las Vistas son:
• Administra la visualización y presentación de la información.

• Observa al Modelo para actualizar los cambios.
• Al definirse en el modelo una interfaz clara y estable, es fácil implementar múltiples Vistas
para un mismo modelo.
• Altamente dependiente del dispositivo y tecnología de visualización.
• Muy dependiente del Modelo (debe conocerlo).
Controlador Es la capa encargada de manejar y responder las solicitudes del usuario, procesando
la información necesaria y modificando el Modelo en caso de ser necesario. Es código que no
tiene que ver con las ventanas visuales ni con las reglas de nuestro modelo.
Las principales características del Controlador son:
• Responsable de definir el comportamiento de la aplicación.

• Recibe los eventos del usuario y decide qué es lo que se debe hacer, mapeándolos en
comandos (mensajes) hacia el Modelo.
• Altamente dependiente de los dispositivos y mecanismos de interacción del usuario muy
dependiente del Modelo (debe conocerlo).
Es un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de
usuario, y la lógica de control en tres componentes distintos Modelo — Vista — Controlador.
Responsabilidades del modelo
El modelo en una aplicación de MVC representa el estado de la aplicación y cualquier lógica de

negocios u operaciones que esta deba realizar. La lógica de negocios debe encapsularse en el
modelo, junto con cualquier lógica de implementación para conservar el estado de la aplicación.
Las vistas fuertemente tipadas normalmente usan tipos ViewModel diseñados para que contengan
los datos para mostrar en esa vista. El controlador crea y rellena estas instancias de ViewModel
desde el modelo.
Responsabilidades de las vistas

Sistema LULY SaaS
Página 54
MANUAL TÉCNICO
Las vistas se encargan de presentar el contenido a través de la interfaz de usuario. Usan el Razor
motor de vistas para insertar código .net en el marcado HTML. Debería haber la mínima lógica
entre las vistas y cualquier lógica en ellas debe estar relacionada con la presentación de contenido.
Si ve que necesita realizar una gran cantidad de lógica en los archivos de vistas para mostrar datos
de un modelo complejo, considere la opción de usar un componente de vista, ViewModel, o una
plantilla de vista para simplificar la vista.
Responsabilidades del controlador
Los controladores son los componentes que controlan la interacción del usuario, trabajan con el
modelo y, en última instancia, seleccionan una vista para representarla. En una aplicación de
MVC, la vista solo muestra información; el controlador controla y responde a la interacción y los
datos que introducen los usuarios. En el patrón de MVC, el controlador es el punto de entrada
inicial que se encarga de seleccionar con qué tipos de modelo trabajar y qué vistas representar (de
ahí su nombre, ya que controla el modo en que la aplicación responde a una determinada
solicitud).
10.4.1.2 Arquitectura basada en N capas
Principios fundamentales
Los principios comunes que se aplican cuando se diseña para usar este estilo de arquitectura
incluyen:
• Abstracción. La arquitectura basada en capas abstrae la vista del modelo como un todo
mientras que provee suficiente detalle para entender las relaciones entre capas.
• Encapsulamiento. El diseño no hace asunciones acerca de tipos de datos, métodos,
propiedades o implementación.
• Funcionalidad claramente definida. El diseño claramente define la separación entre la
funcionalidad de cada capa. Capas superiores como la capa de presentación envía comandos
a las capas inferiores como la capa de negocios y la capa de datos y los datos fluyen hacia y
desde las capas en cualquier sentido.
• Alta cohesión. Cada capa contiene funcionalidad directamente relacionas con la tarea de
dicha capa.
• Reutilizable. Las capas inferiores no tienen ninguna dependencia con las capas superiores,
permitiéndoles ser reutilizables en otros escenarios.
• Desacople. La comunicación entre las capas está basada en la abstracción lo que provee un
desacople entre las capas.
Sistema LULY SaaS
Página 55
MANUAL TÉCNICO
Figura 22: Arquitectura N capas
Interacción de los Componentes
Capa de interfaz del Usuario (IU)
• Interactúa con el usuario, mediante esta capa se aceptan peticiones o solicitudes realizadas
por el usuario del sistema. Estas solicitudes son controladas y procesadas por la capa lógica
de negocio la cual devolverá las peticiones solicitadas en la interfaz de Usuario.
Capa de Controlador (C)
• Es la capa que responde a eventos (usualmente acciones del usuario) e invoca peticiones a la
lógica de negocio cuando se hace alguna solicitud sobre la información (por ejemplo, editar
un documento o un registro en una base de datos). También puede enviar comandos a su
interface de usuario asociada si se solicita un cambio en la forma en que se presenta la lógica
de negocio (por ejemplo, desplazamiento o scroll por un documento o por los diferentes
registros de una base de datos) por tanto, se podría decir que el controlador hace de
intermediario entre el interfaz de usuario y la lógica de negocio.
Capa Lógico De Negocio (Modelo)
• Es la representación de la información con la cual el sistema opera, por lo tanto, gestiona

todos los accesos a dicha información, tantas consultas como actualizaciones, implementando
también los privilegios de acceso que se hayan descrito en las especificaciones de la
aplicación. Envía a la Interfaz de Usuarios aquella parte de la información que en cada
momento se le solicita para que sea mostrada (típicamente a un usuario). Las peticiones de
acceso o manipulación de información llegan al modelo a través del controlador.
Acceso de datos (AD)

Sistema LULY SaaS
Página 56
MANUAL TÉCNICO
• Permitirá la conexión a la base de datos o denominada la capa de almacenamiento en la cual

se encuentran los diferentes servicios enviados la capa de lógica de negocios.
Almacenamiento
• Se encuentra los diferentes datos almacenados que serán consumidos por los servicios de las
capas anteriores mencionadas, en este proyecto se utilizara como motor a MySQL.
HISTORIA TÉCNICA
Número: HT_01 Nombre: Análisis y definición de la arquitectura

del sistema
Modificación de la historia técnica número:
Usuario: Desarrollador Sprint Asignado: 1
Riesgo en desarrollo: Alta Puntos Reales: 10
Descripción: Como desarrolladores queremos analizar la arquitectura del sistema web, para
conocer las capas necesarias a desarrollar.
Observaciones:
PRUEBAS DE ACEPTACIÓN
• Verificar que la arquitectura de la aplicación cumpla con lo establecido en la

arquitectura n-capas.
Código: PA_01 Historia técnica: HT_01 Análisis y definición de

la arquitectura del sistema.
Nombre: Verificar que el diseño planteado sea fiel a los conceptos de la arquitectura de N
capas.
Responsable: Alex Yaguachi. Fecha: 20/11/2020
Descripción: Como responsable de esta prueba de aceptación quiero verificar que la

arquitectura este diseñada en n capas.
Sistema LULY SaaS
Página 57
MANUAL TÉCNICO
Condiciones de Ejecución:
La arquitectura está diseñada en N capas.
• Revisar el diagrama UML de la arquitectura.

• Verificar que en su diseño este implementado e N capas.
Resultado esperado: se comprueba que la arquitectura este diseñada en N capas.
Evaluación de la prueba: Exitosa.
Historia técnica: HT_01 Análisis y definición de la arquitectura del sistema web.
Número de Tarea: TI_01 Nombre de Tarea: Investigación de la arquitectura de N

capas.
Tipo de Tarea: Investigación Puntos Estimados: 5
Fecha Inicio: 16/11/2020 Fecha Fin: 18/11/2020
Programador Responsable: Alex Yaguachi.
Descripción: Investigación de todo lo referente a la estructura de la arquitectura de N capas.
Verificar que se haya entendido la arquitectura de N capas para el posterior análisis de la
arquitectura.
Código: PA_02 Tarea de Ingeniería: Investigación de la arquitectura de N
capas.
Nombre: Verificar que se haya entendido la arquitectura de N capas para el posterior diseño
de la arquitectura del sistema web.
Responsable: Lucero Ulcuango Fecha: 18/11/2020
Descripción: Probar que se realizó un correcto análisis y estudio de la arquitectura de N capas
que se implementará en el sistema.
Sistema LULY SaaS
Página 58
MANUAL TÉCNICO
• Contar con que la arquitectura que se implementará en el sistema sea la arquitectura de

N capas.
• Investigar sobre la arquitectura de N capas.
• Realizar una socialización con el grupo de trabaja para verificar que esta entendida la
arquitectura.
Resultado esperado: Se comprueba que la investigación de la arquitectura de N capas está
correctamente realizado.
Evaluación de la prueba: Exitoso
Historia técnica: HT_01 Análisis y definición de la arquitectura del sistema web.
Número de Tarea: TI_02 Nombre de Tarea: Investigación de la arquitectura MVC.
Tipo de Tarea: Investigación Puntos Estimados: 5
Programador Responsable: Alex Yaguachi.
Descripción: Investigación de todo lo referente a la estructura de la arquitectura MVC.
Verificar que se haya comprendido la arquitectura MVC para el posterior análisis de la
arquitectura.
Código: PA_03 Tarea de Ingeniería: Investigación de la arquitectura MVC
Nombre: Verificar el entendimiento de la arquitectura MVC
Descripción: Probar que se realizó un correcto análisis y estudio de la arquitectura de N capas
que se implementará en el sistema.
• Contar con que la arquitectura que se implementará en el sistema sea la arquitectura
MVC.
Sistema LULY SaaS
Página 59
MANUAL TÉCNICO
• Investigar sobre la arquitectura MVC.
• Realizar una socialización con el grupo de trabaja para verificar que esta entendida
la arquitectura.
Resultado esperado: Se comprueba que la investigación de la arquitectura de MVC está
correctamente realizado.
Evaluación de la prueba: Exitoso
10.4.2 HT_02 Análisis y definición del estándar de la interfaz de usuario
Es importante definir la interfaz de usuario de manera adecuada ya que se debe seguir un estándar
de ubicación general de los componentes gráficos que formaran parte del sistema tales como:
botones, imágenes, texto y reportes.
Para el módulo de gestión de inventarios se establecieron los colores correspondientes al logo de

la empresa.
10.4.2.1 Componentes de la interfaz de usuario
Paleta de colores
Figura 9: Paleta de colores
Botones
Figura 10: Diseño botones
Interlineado
Sistema LULY SaaS
Página 60
MANUAL TÉCNICO
Figura 11: Interlineado
10.4.2.2 Bosquejos de pantallas
Pantalla principal
El bosquejo de la pantalla principal del módulo SaaS muestra la ubicación de los elementos que
contendrá dicha pantalla, en la parte superior se mostrará el logo de la empresa, el nombre de la
empresa y al lado derecho estará el botón para iniciar sesión, en la parte central de la empresa se
mostrará una imagen de fondo y la información necesaria.
Figura 12: Bosquejo pantalla principal
Pantalla para reportes

Sistema LULY SaaS
Página 61
MANUAL TÉCNICO
El bosquejo de la pantalla para los reportes de inventarios, en el encabezado se detalla el nombre

de la empresa, en la parte superior izquierda se colocará el logo de la empresa, el resto del
contenido mostrara una tabla con los campos que contiene cada reporte.
Figura 13: Bosquejo pantalla reportes
Pantalla general
El bosquejo de la pantalla general del módulo de inventarios muestra en el cual en el panel

izquierdo todas las opciones que el sistema contenga.
Figura 14: Bosquejo pantalla general

Sistema LULY SaaS
Página 62
MANUAL TÉCNICO
Los bosquejos de pantalla presentados son una idea de cómo se diseñará la interfaz de usuario
tanto para el módulo SaaS como el de inventarios, dichos bosquejos representan de forma general
como se mostrarán todos los reportes de inventario, también la pantalla general muestra por
defecto al iniciar sesión el listado de productos.
HISTORIA TÉCNICA
Número: HT_02 Nombre: Análisis y definición del estándar de la

interfaz de Usuario
Riesgo en desarrollo: Baja Puntos Reales: 10
Descripción: Como Desarrollador necesito definir un estándar para la interfaz de usuario

de la aplicación para poder mantener uniformidad en las diferentes funcionalidades.
Observaciones: Se definirá un estándar preliminar de la interfaz para poner a

consideración del cliente y del equipo de desarrollo.
• Verificar que el bosquejo siga los lineamientos del cliente
Código: PA_01 Historia técnica: HT_02 Análisis y definición del estándar de la
interfaz de Usuario.
Nombre: Verificar que el bosquejo siga los lineamientos del cliente
Descripción: Se requiere verificar si el bosquejo de pantallas cumple con los lineamientos
del cliente de Ejecución:
Condiciones
• El bosquejo de pantallas debe estar diseñado.
● Revisar que el bosquejo de la interfaz de usuario cumpla con los
lineamientos del cliente
Resultado esperado:
Todos los parámetros del bosquejo cumplirán con los lineamientos del cliente.
Sistema LULY SaaS
Página 63
MANUAL TÉCNICO
Historia técnica: HT_02 Análisis y definición del estándar de la interfaz de Usuario.
Número de Tarea: TI_02 Nombre de Tarea: Definición de la paleta de

colores para la interfaz de usuario.
Tipo de Tarea: Desarrollo Puntos Estimados: 5
Programador Responsable: Lucero Ulcuango
Descripción: Como desarrollador quiero diseñar los elementos básicos para usarse en la
interfaz de usuario.
• se deberá establecer los colores para la interfaz de usuario junto con el cliente
Código: PA_01 Historia técnica: HT_02 Análisis y definición del estándar de la

interfaz de Usuario.
Nombre: Definición de la paleta de colores
Responsable: Alex Yaguachi Fecha: 25/11/2020
Descripción: se deberá establecer los colores para la interfaz de usuario junto con el
cliente
• Se habrán mantenido una reunión con el cliente.

Pasos de Ejecución:
• Junto al cliente verificar los colores que identifican a la empresa.

Resultado Esperado:
• La paleta de colores presentada cumple con las especificaciones del cliente.

Evaluación de la Prueba: Exitosa
Sistema LULY SaaS
Página 64
MANUAL TÉCNICO
Historia técnica: HT_02 Análisis y definición del estándar de la interfaz de Usuario.
Número de Tarea: TI_02 Nombre de Tarea: Análisis del estándar de diseño

de interfaces.
Tipo de Tarea: Desarrollo Puntos Estimados: 5
Descripción: Como desarrollador quiero analizar la definición del estándar de diseño de

la interfaz para modelar las posibles pantallas del sistema de acuerdo con los
requerimientos del cliente.
• Verificar que el estándar del diseño de la interfaz cumpla con las expectativas
del Cliente.
Código: PA_02 Historia técnica: HT_02 Análisis del estándar de la interfaz de
Usuario.
Nombre: verificar que el estándar del diseño de la interfaz cumpla con las expectativas del
Cliente.
Descripción: El estándar diseño de la interfaz debe cumplir con las especificaciones dadas
por el cliente.
• El bosquejo de pantallas debe estar diseñado.
Pasos de Ejecución:
• Junto al cliente establecer si el bosquejo de pantallas cumple con sus expectativas
para el desarrollo de la interfaz.
Resultado Esperado:
• Los estándares utilizados en el bosquejo de pantalla cumplen con las
Sistema LULY SaaS
Página 65
MANUAL TÉCNICO
especificaciones del cliente.
Evaluación de la Prueba: Exitosa
10.4.3 HT_03 Análisis y definición del estándar del estándar de programación.
Es importante establecer un estándar de codificación ya que de este modo todos los involucrados
en el desarrollo del sistema pueden trabajar de forma ordenada de tal modo que no se presenten
problemas en la integración de los módulos.
El uso de estándares para la programación promueve la usabilidad del sistema, además es una
forma de asegurar el desarrollo del proyecto ya que puede ser interpretado con facilidad.
La conclusión viene dada después del siguiente estudio:
10.4.3.1 Estándar de programación Laravel

Con el apoyo del lenguaje de programación PHP junto con el marco Laravel, necesitan un el
estándar básico de programación también son estándares de programación orientados a objetos, y
nuevamente al combinar las ventajas del marco, se obtiene un compacto, rápido y fácil de evitar
el desorden de código o el llamado desorden de código adicional (Toasa Chisaguano, 2019).
Las características y las estructuras de control deben coincidir con el estilo de soporte de Allman.
El estilo de Allman dicta que la llave abierta de la estructura de control se coloque en la siguiente
línea. La llave de cierre debe estar al mismo nivel que la llave de apertura. Y el cuerpo de la
estructura debe estar sangrado con tabulaciones y alineado con espacios (Tubío, 2015).
10.4.3.2 Estándar de programación SNAKE CASE
Los símbolos de snake_case usan el guión bajo _ como enlace para agrupar palabras. Hay dos
versiones de esta notación: una en la que todas las letras están en minúsculas y otra en la que todas
las letras están en mayúsculas. Esta notación, cuando se usa en mayúsculas, es común en
declaraciones constantes en lenguajes como PHP o JavaScript (Lázaro, 2020).
La versión pequeña de la notación Snake Case también se usa ampliamente en las declaraciones
de nombres de campos de bases de datos. Además, se usa para declaraciones de variables de PHP
y, de hecho, sigue siendo la configuración predeterminada para muchos desarrolladores cuando
escriben complementos o temas de WordPress (Lázaro, 2020).
HISTORIA TÉCNICA
Sistema LULY SaaS
Página 66
MANUAL TÉCNICO
Número: HT_03 Nombre: Análisis y definición del estándar de

programación
Riesgo en desarrollo: Bajo Puntos Reales: 10
Descripción: Como desarrolladores deseamos analizar el estándar de programación,

bajo el cual se regirá el desarrollo del proyecto, para poder codificar de forma
homogénea y que sea de fácil comprensión.
Observaciones: Analizar y definir el estándar de programación que será utilizado.
• Verificar que el estándar de codificación contenga reglas para definir elementos

tales como: variables, constantes, clases, objetos, métodos, paquetes, comentarios.
Código: PA_01 Historia técnica: HT_03 Análisis y definición del estándar

de programación.
Nombre: Verificar el estándar de programación.
Responsable: Alex Yaguachi Fecha: 27-11-2020
Descripción: Verificar que el estándar de codificación contenga reglas para definir

elementos tales como: variables, constantes, clases, objetos, métodos, paquetes,
comentarios.
Condiciones de Ejecución: El estándar con el que se va a desarrollar el proyecto debe

estar debidamente planteado por los desarroladores.
• Verificar que en el estándar se especifique las reglas para definir variables

• Verificar que en el estándar se especifique las reglas para definir Constantes
• Verificar que en el estándar se especifique las reglas para definir Clases
• Objetos
Sistema LULY SaaS
Página 67
MANUAL TÉCNICO
• Verificar que en el estándar se especifique las reglas para definir Métodos

• Verificar que en el estándar se especifique las reglas para definir Paquetes
• Verificar que en el estándar se especifique las reglas para definir comentarios
Resultado esperado:
• Se obtuvo las reglas para definir variables dentro del estándar

• Se obtuvo las reglas para definir Constantes dentro del estándar
• Se obtuvo las reglas para definir Clases dentro del estándar
• Se obtuvo las reglas para definir Objetos dentro del estándar
• Se obtuvo las reglas para definir Métodos dentro del estándar
• Se obtuvo las reglas para definir Paquetes dentro del estándar
• Se obtuvo las reglas para definir comentarios dentro del estándar
Historia técnica: HT_03 Análisis y definición del estándar de programación.
Número de Tarea: TI_01. Nombre de Tarea: Analizar el estándar de

codificación que se implementa con el framework
Laravel.
Descripción: Analizará el estándar de codificación Laravel para poder tener una guía al
momento de codificar el sistema.
• Verificar que el estándar consultado sea apropiado para el desarrollo del sistema.
Código: PA_01_TI_01 Historia de Usuario: TI_01 Analizar el estándar Laravel para

codificación
Sistema LULY SaaS
Página 68
MANUAL TÉCNICO
Nombre: Estándar de codificación de Laravel
Responsable: Lucero Ulcuango Fecha: 25-11-2020
Descripción: Analizar el contenido del estándar de codificación de Laravel y verificar que

se determine las reglas para los elementos propuestos variables, constantes, clases, objetos,
métodos, paquetes, comentarios.
Condiciones de Ejecución: Haber realizado la investigación respectiva.

• Verificar que en la documentación del estándar se encuentren establecidos las

reglas de variables
reglas de Constantes
reglas de Clases
reglas de Objetos
reglas de Métodos
reglas de Paquetes
reglas de comentarios.
Resultado esperado: El estándar escogido contiene todos los aspectos necesarios para
que el código a desarrollar se pueda llevar de una manera organizada en el desarrollo del
sistema.
Historia técnica: HT_03 Análisis y definición del estándar de programación.
Número de Tarea: TI_02 Nombre de Tarea: Analizar el estándar de

desarrollo de bases de datos MySQL.

Sistema LULY SaaS
Página 69
MANUAL TÉCNICO
Descripción: Analizará el estándar de codificación de MySQL para poder tener una guía
al momento de codificar el sistema.
• Verificar que el estándar de MySQL sea apropiado para el desarrollo del sistema.
Código: PA_01_TI_02 Historia de Usuario: TI_01 Analizar el estándar de MySQL

para codificación
Nombre: Estándar de codificación de MySQL
Descripción: Analizar el contenido del estándar de codificación de MySQL y verificar

que se determine las reglas para los elementos propuestos variables, constantes, clases,
objetos, métodos, paquetes, comentarios.
Condiciones de Ejecución: Haber realizado la investigación respectiva.


reglas de variables
reglas de Constantes
reglas de Clases
reglas de Objetos
reglas de Métodos
reglas de Paquetes
reglas de comentarios.
Sistema LULY SaaS
Página 70
MANUAL TÉCNICO
Resultado esperado: El estándar escogido contiene todos los aspectos necesarios para
que el código a desarrollar se pueda llevar de una manera organizada en el desarrollo del
sistema.
10.4.4 HT_04 Diseñar el esquema de base de datos.
En este apartado se detalla uno a uno los componentes fundamentales en el desarrollo de la

aplicación, por lo cual se realizó el diseño preliminar mismo que consta del diagrama Entidad-
Relación, modelo físico y diccionario de datos.
Los modelos creados son la representación de la base de datos los cuales fueron creados en SAP
PowerDesigner la cual es una herramienta de modelado empresarial producida por Sybase, esta
herramienta permite mutar el modelo inicial MER al modelo físico determinando la estructura
correcta de la base.
Para identificar las principales entidades de la tabla y las relaciones entre ellas se define como
modelo inicial el diagrama:
Sistema LULY SaaS
Página 68
MANUAL TÉCNICO
Modelo entidad relación módulo de inventarios

Sistema LULY SaaS
Página 69
MANUAL TÉCNICO
Modelo físico modulo inventarios
Figura 15: Base de datos módulo inventario

Sistema LULY SaaS
Página 68
MANUAL TÉCNICO
Modelo entidad relación módulo SaaS

Sistema LULY SaaS
Página 69
MANUAL TÉCNICO
Modelo Físico módulo SaaS
Figura 16: Base de datos módulo SaaS

Sistema LULY SaaS
Página 4
MANUAL TÉCNICO
10.4.4.1 Diccionario de datos
Es importante determinar un diccionario de datos ya que de esta manera se puede tener una idea
puntual de los datos que se van a utilizar en el sistema, incluyendo nombre de las entidades, tipo
de datos, longitud de los datos, etc.
Nombre del archivo: tipo_estantes
Descripción del archivo: tipo de estante materia prima y productos terminados
Nombre del campo Descripción Tipo de dato NULL Valor permitido de dato
id (pk) Identificador de la Serial No [00000] * permite un numero

tabla entero auto incrementable*
tipo_estante Tipo de cliente Character varing No Tipo de cliente = {[A-Z|a-z]}
Nombre del archivo: estantes
Descripción del archivo: estantes de ubicaciones de productos terminados y materia prima
id (pk) Identificador de Serial No [00000] * permite un numero

codigo_estante Código de estante Character varing No [00000] * permite un caracter [A-

Z] y requiere 2 caracteres * +”-”
+* permite un caracter [A-Z] y
requiere 2 caracteres*
descripcion_estante Descripción del Character varing No Descripción = {[A-Z|a-z]}

estante
disponibilidad_estante Disponibilidad del Booleano No [0| 1] * significado: 0: Activo | 1:

estante Inactivo *
id_tipo_estante Identificador de tipo Integer No [00000] * permite un numero

estante entero*
(fk)
id_almacen Identificador de Integer No [00000] * permite un numero

almacen entero*
(fk)
Nombre del archivo: almacenes
Descripción del archivo: almacenes que le pertenecen a un usuario
Sistema LULY SaaS
Página 5
MANUAL TÉCNICO
id Identificador de la Serial No [00000] * permite un numero
(pk)
id_estado Identificador de Integer No [00000] * permite un numero

estado entero*
(fk)
descripcin_almacen Descripción de Character varing Si Descripción = {[A-Z|a-z]}

almacén
direccion_almacen Dirección de Character varing No Calle principal + número =

almacén {[AZ|a-z]} + {999999}
Nombre del archivo: estados
Descripción del archivo: estados para empleados y almacenes (activo, incactivo)
id Identificador de Serial No [00000] * permite un numero

estado entero auto incrementable*
(pk)
estado Nombre de estado Character varing No Descripción = {[A-Z|a-z]}
Nombre del archivo: empleados
Descripción del archivo: empleados de la empresa

empleado entero auto incrementable*
(pk)
id_estado Identificador de Integer No [00000] * permite un numero

estado entero*
(fk)
id_permiso Identificador de Integer No [00000] * permite un numero

permiso entero*
(fk)
cedula_empleado Cedula de empleado Character varing No [0000000000] * permite un dígito

[0 a 9] y requiere la entrada de los
10 dígitos *
nombre_empleado Nombres de Character varing No primer nombre + (segundo

empleado nombre) = {[A-Z|a-z]}
Sistema LULY SaaS
Página 6
MANUAL TÉCNICO
apellido_empleado Apellidos de Character varing No primer apellido + (segundo
empleado apellido) = {[A-Z|a-z]}
email Nombre de Usuario Character varing No Correo electrónico *permite

de empleado cualquier caracter*
password Contraseña de Character varing No *permite 8 caracteres*

empleado
Nombre del archivo: permisos
Descripción del archivo: permisos de los empleados, control de accesos a las funciones

permiso entero auto incrementable*
(pk)
nivel_permiso Nivel de permiso en Integer No [0000000000] * permite un

números dígito [1 a 5] y requiere la
entrada de 1 dígito *
descripción_permiso Descripción de Character varing Si Descripción = {[A-Z|a-z]}

permiso
Nombre del archivo: clientes
Descripción del archivo: clientes que realizan pedidos

cliente entero auto incrementable*
(pk)
nombre_cliente Nombre de cliente Character varing No primer nombre + (segundo

nombre) = {[A-Z|a-z]}
apellido_cliente Apellidos de cliente Character varing No primer apellido + (segundo

apellido) = {[A-Z|a-z]}
cedula_cliente Cédula de cliente Character varing No [0000000000] * permite un dígito

[0 a 9] y requiere la entrada de los
10 dígitos *
telefono_cliente Número de teléfono de Character varing Si [0000000000] * permite un dígito

cliente [0 a 9] y requiere la entrada de los
10 dígitos *
Sistema LULY SaaS
Página 7
MANUAL TÉCNICO
email_cliente Correo electrónico de Character varing Si Correo electrónico *permite
cliente cualquier carácter*
Nombre del archivo: pedidos
Descripción del archivo: pedidos de productos, materia prima

pedido entero auto incrementable*
(pk)
id_tipo_pedido Identificador de tipo Integer No [00000] * permite un numero

pedido entero*
(fk)
id_estado_pedido Identificador de Integer No [00000] * permite un numero

estado pedido entero*
(fk)
id_cliente Identificador de Integer Si [00000] * permite un numero

cliente entero*
(fk)
id_empleado Identificador de Integer No [00000] * permite un numero

empleado entero*
(fk)
valor_total_pedido Costo del pedido Money No *permite números

fraccionarios*
fecha_pedido Fecha que se realiza el Date No *formato: dd-mm-aaaa*

pedido
fecha_entrega Fecha que se entrega Date No *formato: dd-mm-aaaa*

el pedido
Nombre del archivo: tipo_pedidos
Descripción del archivo: tipo de pedidos (interno, externo, cliente)
id Identificador de pedido Serial No [00000] * permite un

numero entero auto
(pk)
incrementable*
tipo_pedido Tipo de pedido character varing No Tipo pedido= {[A-Z|a-z]}
descripción_tipo_pedido Descripción de tipo de character varing Si Descripción = {[A-Z|a-z]}

pedido
Sistema LULY SaaS
Página 8
MANUAL TÉCNICO
Nombre del archivo: estado_pedidos
Descripción del archivo: estado de los pedidos (pendiente, finalizado y entregado)

estado de pedido entero auto incrementable*
(pk)
estado_pedido Estado de pedido Character varing No Estado = {[A-Z|a-z]}
Nombre del archivo: facturas
Descripción del archivo: facturas emitidas por la compra de materia prima a un proveedor
id Identificador de factura Serial No [00000] * permite un numero

entero auto incrementable*
(pk)
id_pedido Identificador de pedido Integer No [00000] * permite un numero

entero*
(fk)
id_proveedor Identificador de proveedor Integer No [00000] * permite un numero

entero*
(fk)
factura Dirección de imagen de Character No Dirección factura ={[A-Z|a-z]}

factura varing
Nombre del archivo: pedido_producto
Descripción del archivo: relación de pedido con producto
id_pedido Identificador de pedido Integer No [00000] * permite un

numero entero*
(fk)
id_color_producto_talla Identificador de la Integer No [00000] * permite un

relación color, producto numero entero*
(fk)
y talla
Sistema LULY SaaS
Página 9
MANUAL TÉCNICO
id Identificador de relación Serial No [00000] * permite un
pedido-producto numero entero auto
(pk)
incrementable*
cantidad_por_producto Cantidad de unidades por Double No *permite números

producto fraccionarios*
total_costo_por_producto Costo total de producto Money No *permite números

fraccionarios*
Nombre del archivo: proveedores
Descripción del archivo: proveedores de materia prima
id Identificador de Serial No [00000] * permite un

proveedor numero entero auto
(pk)
incrementable*
ruc_proveedor Ruc de proveedor Character varing No [0000000000000] * permite

un dígito [0 a 9] y requiere
la entrada de los 13 dígitos *
razón_social_proveedor Razón social de Character varing No Razón social={[A-Z|a-z]}

proveedor
telefono_proveedor Teléfono de proveedor Character varing Si [0000000000] * permite un

dígito [0 a 9] y requiere la
entrada de los 10 dígitos *
email_proveedor Correo de proveedor Character varing Si Correo electrónico *permite

cualquier caracter*
Nombre del archivo: users
Descripción del archivo: Persona que contrata un servicio
Nombre del Descripción Tipo de dato NULL Valor permitido de dato

campo
id Identificador de la tabla Serial No [00000] * permite un valor entero auto

incrementable*
(pk)
id_estado Identificador del estado Integer No [00000] * permite un numero entero*
(fk)
Sistema LULY SaaS
Página 10
MANUAL TÉCNICO
cedula Cedula de ciudadanía del Character varing No [0000000000] * permite un dígito [0 a
usuario 9] y requiere la entrada de los 10
dígitos *
name Nombres completos del Character varing No primer nombre + (segundo nombre) =
usuario {[A-Z|a-z]}
apellido Apellidos completos del Character varing No primer apellido + (segundo apellido) =
usuario {[A-Z|a-z]}
telefono Telefono del usuario Character varing Si [0000000000] * permite un dígito [0 a

9] y requiere la entrada de los 10
dígitos *
email Correo del usuario Character varing No [0000000000] * permite un dígito [0 a

49] y/o {[A-Z|a-z]} y requiere la
password Contraseña del usuario Character varing No [0000000000] * permite un dígito [0 a

14] y/o {[A-Z|a-z]} y requiere la
rol Rol del usuario SaaS Character varing No Rol={[A-Z|a-z]}
Nombre del archivo: empresas
Descripción del archivo: empresa perteneciente a una persona
id Identificador de la tabla Serial No [00000] * permite un valor

(pk)
id_user Identificador de la tabla Integer No [00000] * permite un numero

usuarios entero*
(fk)
ruc_empresa Identificador de la Character varing No [0000000000] * permite un

empresa dígito [0 a 12] y requiere la
razon_social_empresa Nombre de la empresa Character varing No Nombre empresa = {[A-Z|a-

z]}
direccion_empresa Dirección de ubicación Character varing Si Calle principal + número =

de la empresa {[AZ|a-z]} + {999999}
telefono_empresa Teléfono de la empresa Character varing Si [0000000000] * permite un

dígito [0 a 9] y requiere la
Sistema LULY SaaS
Página 11
MANUAL TÉCNICO
logo_empresa Logo de la empresa Character varing Si Texto = {[AZ|a-z]}
slogan_empresa Slogan de la empresa Character varing Si Slogan empresa = {[A-Z|a-z]}
slug Identificador de la Character varing No Slug = {[A-Z|a-z]}

empresa que genera la
base de datos
Multitenant
Nombre del archivo: servicios
Descripción del archivo: servicio que se presta a una persona
id Identificador de la Serial No [00000] * permite un valor entero

tabla auto incrementable*
(pk)
nombre_servicio Nombre del servicio Character varing No Nombre servicio = {[A-Z|a-z]}
descripcion_servicio Descripción y/o Character varing No Descripcion servicio = {[A-Z|a-

detalles del servicio z]}
id_estado Estado servicio Integer No [00000] * permite un valor entero

*
(fk)
Nombre del archivo: estados
Descripción del archivo: estado de un servicio (activo, inactivo)

campo
id Identificador de la tabla Serial No [00000] * permite un valor entero auto

incrementable*
(pk)
estado Estado activo o inactivo Bool No [0| 1] * significado: 0: Activo | 1:

del servicio Inactivo *
Nombre del archivo: plan_servicio
Descripción del archivo: relación de servicio con planes y suscripciones
id Identificador de la Serial No [00000] * permite un valor entero

relación auto incrementable*
Sistema LULY SaaS
Página 12
MANUAL TÉCNICO
(pk)
id_servicio Identificador del Integer No [00000] * permite un valor entero *

servicio
(fk)
id_plan Identificador del Integer No [00000] * permite un valor entero *

plan
(fk)
Costo_plan_servicio Costo del plan Money No *permite números fraccionarios*

contratado
Nombre del archivo: planes
Descripción del archivo: planes disponibles pertenecientes un servicio pueden ser mensuales o anuales
id Identificador de la serial No [00000] * permite un valor entero

tabla auto incrementable*
(pk)
id_estado Estado del servicio Integer No [00000] * permite un valor entero *
(fk)
nombre_plan Nombre del plan Character No Nombre plan = {[A-Z|a-z]}

varing
descripción_plan Descripción plan Character Si Descripción plan = {[A-Z|a-z]}

varing
Nombre del archivo: suscripciones
Descripción del archivo: suscripciones de la empresa a un servicio con un plan
Nombre del Descripción Tipo de NULL Valor permitido de dato

campo dato
id Identificador de la tabla Serial No [00000] * permite un valor

(pk)
id_empresa Identificador de la empresa Integer No [00000] * permite un valor

entero *
(fk)
id_plan_servicio Identificador del plan servicio Integer No [00000] * permite un valor

entero *
(fk)
Sistema LULY SaaS
Página 13
MANUAL TÉCNICO
activo Estado de la suscrición Bool No [0| 1] * significado: 0: Activo
contratada | 1: Inactivo *
fecha_inicio Fecha en la que se contrata una Date No *formato: dd-mm-aaaa*

suscripción
fecha_fin Fecha fin de una suscripción Date No *formato: dd-mm-aaaa*
fecha_cancelacion Fecha de cancelación de una Date No *formato: dd-mm-aaaa*

suscripción
fecha_notificacion Fecha notificación de próximo Date No *formato: dd-mm-aaaa*

pago
motivo_cancelacion Motivo por el cual se realizó la Character Si Motivo cancelación =

cancelación de una varing {[AZ|a-z]}
suscripción
Nombre del archivo: pagos
Descripción del archivo: registro de pagos de las suscripciones contratadas por el usuario

campo
id Identificador de los pagos Serial No [00000] * permite un numero

(pk)
id_suscripcion Identificador de las Integer No [00000] * permite un numero

suscripciones entero*
(fk)
codigo_pago Código de pago generado por Character No Estado = {[A-Z|a-z]}

PAYPAL varing
Fecha_pago Fecha de pago Date No *formato: dd-mm-aaaa*
Nombre del archivo: estante_producto
Descripción del archivo: relación estantes y productos

campo
id Identificador de estante Serial No [00000] * permite un numero entero

producto auto incrementable*
(pk)
Sistema LULY SaaS
Página 14
MANUAL TÉCNICO
id_estante Identificador del estante Integer No [00000] * permite un numero entero*
(fk)
id_producto Identificador del Integer No [00000] * permite un numero entero*

prodcuto
(fk)
Nombre del archivo: productos
Descripción del archivo: registro de productos, productos terminados, materia prima, productos en proceso
id Identificador de la tabla Serial No [00000] * permite un numero

productos entero auto incrementable*
(pk)
id_tipo_prodcuto Identificador tipo Integer No [00000] * permite un numero

producto entero*
(fk)
id_categoria_product Identificador de Integer No [00000] * permite un numero

o categoria producto entero*
(fk)
id_unidad_medida Identificador unidad de Integer No [00000] * permite un numero

medida del producto entero*
(fk)
codigo_producto Código de producto Character No Código producto = {[A-Z|a-z]}

varing
nombre_producto Nombre del producto Character No Nombre producto = {[A-Z|a-z]}

varing
descripcion_producto Descripción del Character Si Descripción producto = {[A-

producto varing Z|a-z]}
Nombre del archivo: categoría_productos
Descripción del archivo: Categoría de los productos

categoría productos entero auto incrementable*
(pk)
Sistema LULY SaaS
Página 15
MANUAL TÉCNICO
categoría_producto Descripción de la Character No Categoría producto = {[A-Z|a-
categoría de los varing z]}
productos
Nombre del archivo: unidad_medidas
Descripción del archivo: unidad de medida de los productos (cm, metros)

(pk)
unidad_medida Nombre de la unidad de Character No Unidad de medida = {[A-Z|a-

mdida varing z]}
siglas_unidad_medida Siglas de la unidad de Character Si Siglas = {[A-Z|a-z]}

medida varing
Nombre del archivo: tipo_productos
Descripción del archivo: tipo de productos (materia prima, terminados, proceso)

campo

productos entero auto incrementable*
(pk)
tipo_producto Tipo producto Character varing No Tipo producto = {[A-Z|a-z]}
Nombre del archivo: tallas
Descripción del archivo: registro de tallas (XXS,XS,S,M,L,XL,XXL),(26,28,30,32,34,36….)

campo
id Identificador de la tabla Serial No [00000] * permite un numero entero

auto incrementable*
(pk)
talla Talla producto Integer No [00000] * permite valores enteros*

Sistema LULY SaaS
Página 16
MANUAL TÉCNICO
equivalencia Equivalencia de las Character varing Si Descripción producto = {[A-Z|a-z]}
tallas
Nombre del archivo: colores
Descripción del archivo: registro de colores para productos

campo

auto incrementable*
(pk)
color Color producto Character varing Si Color = {[A-Z|a-z]}
Nombre del archivo: color_producto_talla
Descripción del archivo: registro de productos

campo

auto incrementable*
(pk)
id_color Identificador color Integer Si [00000] * permite un numero entero*
(fk)
id_talla Identificador talla Integer Si [00000] * permite un numero entero*
(fk)
id_prodcuto Identificador producto Integer No [00000] * permite un numero entero*
(fk)
stock_maximo Stock máximo Double Si *permite números fraccionarios*
stock_minimo Stock mínimo Double Si *permite números fraccionarios*
stock_actual Stock actual Double No *permite números fraccionarios*
costo_producto Costo producto Money Si *permite números fraccionarios*
HISTORIA TÉCNICA
Sistema LULY SaaS
Página 17
MANUAL TÉCNICO
Número: HT_04 Nombre: Diseñar el esquema de base de datos
Riesgo en desarrollo: Alto Puntos Reales: 10
Descripción: Como desarrolladores deseamos llevar a cabo el diseño de la base de datos

para el sistema
Observaciones:
• Verificar la normalización de la base de datos
Código: PA_01 Historia técnica: HT_04 Diseñar el esquema de base de datos.
Nombre: Verificar la normalización de la base de datos
Descripción: verificar la correcta normalización de la base de datos
Condiciones de Ejecución: creada la base de datos con sus respectivas entidades y relaciones
• Identificar las entidades y sus relaciones.

• Identificar las reglas de normalización 1FN
• Ver que no haya redundancia de datos
Resultado esperado:
• Normalización adecuada de la base de datos

Sistema LULY SaaS
Página 18
MANUAL TÉCNICO
Historia técnica: HT_04 Diseñar el esquema de base de datos.
Número de Tarea: TI_01. Nombre de Tarea: Diseño del modelo entidad relación
de la base de datos
Descripción: Definir de manera correcta las entidades, atributos y relaciones que formen parte
de la base de datos que permita el manejo de toda la información requerida por el cliente.
• Verificar que no existan relaciones o entidades redundantes en la base de datos

• Verificar que el diseño cumpla con la simbología y notación establecida
Código: PA_01_TI_01 Historia de Usuario: HT_04 Diseñar el esquema de base de datos.
Nombre: Verificar que no existan relaciones o entidades redundantes en la base de dato
Descripción: Se requiere verificar que cada entidad con sus relaciones esté definida una única
vez para evitar redundancia de datos.
Condiciones de Ejecución: Deberá estar creado el modelo entidad relación, a partir de la

información previamente obtenida.
• Revisar en el diagrama entidad relación obtenido que cada entidad este definida una
sola vez.
• Verificar que no se repitan atributos entre entidades.
Resultado esperado: El diagrama entidad relación correctamente definido para proceder a
obtener el modelo lógico
Sistema LULY SaaS
Página 19
MANUAL TÉCNICO
Código: PA_02_TI_01 Historia de Usuario: HT_04 Diseñar el esquema de base de datos.
Nombre: Verificar que el diseño cumpla con la simbología y notación establecida
Descripción: El diagrama ER y el modelo lógico debe cumplir con la simbología y notación
Condiciones de Ejecución: debe estar creado el modelo entidad relación, a partir de la

información previamente obtenida
• Buscar la notación y simbología para los diagramas DER y Lógico.

• Revisar en nuestro diagrama que se cumpla con dicha notación y simbología.
Resultado esperado: Verificar que el diagrama ER cumpla con el estándar de codificación
establecido
10.5 SPRINT 2
En este esprint se detallan las historias de usuario que intervienen en el correcto funcionamiento
del sistema como es el caso de la implementación de la base de datos que fue previamente
diseñada en el sprint 1
10.5.1 HT_05 Implementar el diseño de la base de datos
Se implemento la base de datos basándose en el diseño previamente desarrollado en el esprint 1,

la base de datos esta desarrollada en MySQL.
HISTORIA TÉCNICA
Número: HT_05 Nombre: Implementar el diseño de la base de datos
Descripción: Como desarrolladores deseamos llevar a cabo la implementación de la base

de datos para el sistema
Observaciones:
Sistema LULY SaaS
Página 20
MANUAL TÉCNICO
• Verificar que los tipos de datos de los atributos estén definidos en el gestor de la base
de datos.
• Verificar que cada tabla tenga sus respectivas claves primarias y foráneas de acuerdo
con lo especificado con el modelo lógico
Código: PA_01 Historia técnica: HT_05 Implementar el diseño de la base de datos.
Nombre: Verificar que los tipos de datos de los atributos estén definidos en el gestor de la base
de datos
Descripción: Todos los atributos deben tener definidos un tipo de datos específico
Condiciones de Ejecución: Debe tener realizado el modelo lógico
• Abrir el modelo lógico.

• Listar las entidades y atributos.
• Revisar que cada atributo tenga su tipo de dato
• pasar el modelo lógico al gestor de base de datos
• Ver si todos los campos de las tablas de la base de datos implementados posean un tipo
de datos definidos
Resultado esperado:
• Cada atributo está definido con su tipo de datos en el gestor de BD

Código: PA_01 Historia técnica: HT_05 Implementar el diseño de la base de datos.
Nombre: Verificar que cada tabla tenga sus respectivas claves primarias, foráneas de acuerdo
con lo especificado con el modelo lógico.

Sistema LULY SaaS
Página 21
MANUAL TÉCNICO
Descripción: Al implementar el diseño en el gestor de base de datos verificar que las claves
primarias y foráneas estén definidas en cada tabla.
Condiciones de Ejecución: Debe tener realizado el modelo lógico.
• Abrir el modelo lógico.

• Listar las entidades y atributos.
• Verificar claves primarias y foráneas en cada tabla
Resultado esperado:
• Cada tabla tiene su clave primaria y foránea según el diseño

10.5.2 HT_06 Redactar la documentación
En cualquier nivel de la organización y etapa de desarrollo es necesario documentar los elementos

importantes como recursos, procesos que son necesarios para lograr los objetivos planteados. La
documentación en este sprint se ha dividido en dos tareas de ingeniería como se detalla a
continuación:
HISTORIA TÉCNICA
Número: HT_06 Nombre: Redactar la documentación
Usuario: Desarrollador Sprint Asignado: 2 y 5
Prioridad en Negocio: Baja Puntos Estimados: 30
Riesgo en desarrollo: Baja Puntos Reales: 35
Descripción: Como desarrolladores queremos que todo los relacionado con las técnicas de
gestión y codificación del sistema estén correctamente documentadas.
Observaciones:
• La documentación se realiza en el trascurso del desarrollo

• Verificar que el contenido de la documentación concuerde con lo establecido en cada

iteración, de la planificación.
Sistema LULY SaaS
Página 22
MANUAL TÉCNICO
Código: PA_01 Historia técnica: HT_06 Redactar la documentación
Nombre: Verificar contenido
Descripción: Verificar que el contenido de la documentación concuerde con lo establecido en

cada iteración, de la planificación.
Condiciones de Ejecución: Toda la documentación debe estar actualizada
• Leer la documentación completa de cada una de las tareas que fueron realizadas en cada
sprint.
• Verificar que el contenido tenga coherencia con lo establecido en la planificación.
Resultado esperado:
• El contenido que forma parte de la documentación concuerda con lo establecido en la

planificación.
Historia técnica: HT_06 Redactar la documentación.
Número de Tarea: TI_01. Nombre de Tarea: Formato de documentación
Descripción: Realizar la definición especifica de la introducción, resume, conclusiones y

recomendaciones correspondientes a cada objetivo planteado.
Sistema LULY SaaS
Página 23
MANUAL TÉCNICO
• Verificar que la introducción, el resumen, las conclusiones y recomendaciones se

encuentre acorde con los objetivos planteados y que cumplan con los resultados
esperados.
Código: PA_01_TI_01 Historia técnica: HT_06 Redactar la documentación
Nombre: Verificar formato de documentación
Descripción: Verificar que el contenido de la introducción, resumen, conclusiones y

recomendaciones se encuentren acorde a los objetivos planteados.
• Leer la documentación completa de cada uno de los objetivos que se plantearon

• Verificar el desarrollo respectivo de cada objetivo.
• Determinar la introducción, resumen, conclusiones y recomendaciones.
Resultado esperado:
• Se realizó la introducción, resumen y redacción de las conclusiones y recomendaciones

respectivas con cada objetivo planteado.
Historia técnica: HT_06 Redacción de documentación.
Número de Tarea: TI_02. Nombre de Tarea: Unir toda la documentación.
Descripción: Reunir todas las partes del documento de acuerdo el formato establecido
Sistema LULY SaaS
Página 24
MANUAL TÉCNICO
• Verificar que el documento tenga coherencia en todas las partes del formato
Código: PA_01_TI_02 Historia técnica: HT_06 Redactar la documentación
Nombre: Verificar esquema de documentación
Descripción: Verificar que el documento tenga coherencia en todas las partes del formato
establecido
• Leer la documentación completa de cada uno de los objetivos que se plantearon

• Verificar el desarrollo respectivo de cada objetivo.
• Verificar cada una de las partes del formato del documento
Resultado esperado:
• El documento es coherente y concuerdan cada una de las partes del esquema

10.5.3 HU_01 Registro de usuarios
El ingreso de información de los usuarios en la base de datos del proyecto es vital ya que permite
mantener toda la información necesaria, para esto de es necesario crear un acceso a datos que
permita facilitar el desarrollo. Para esto se han creado tareas de ingeniería así también cada tarea
cuenta con las pruebas de aceptación respectivas como se detalla a continuación:
HISTORIA DE USUARIO
Número: HU_01 Nombre: Registro de usuarios

Sistema LULY SaaS
Página 25
MANUAL TÉCNICO
Descripción: Como desarrolladores deseamos llevar a cabo la implementación de la

funcionalidad de registro de usuarios
Observaciones:
• Verificar que se muestre un mensaje de confirmación o error de registro
Código: PA_01 Historia técnica: HU_01 Registro de usuarios
Nombre: Verificar que se muestre un mensaje de confirmación o error de registro de datos
Descripción: Al ingresar un usuario se debe mostrar un mensaje de corroboración del ingreso

del usuario a la base de datos.
• Solicitar el ingreso de un usuario

• Ingresar los datos del usuario
• Guardar la información ingresada
• Esperar mensaje de conformación
Resultado esperado:
• Se notifica que la información ingresada se guardó con éxito

Número de Tarea: TI_01. Nombre de Tarea: Realizar la función correspondiente

al acceso a datos para el ingreso de usuarios

Sistema LULY SaaS
Página 26
MANUAL TÉCNICO
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita ingresar los
datos de los usuarios en la tabla correspondiente de la base de datos del proyecto.
• Verificar que los datos ingresados a través de los servicios web se encuentre en la tabla
correspondiente de la base de datos.
Código: PA_01_TI_01 Historia de Usuario: HU_01 Registro de usuarios
Nombre: Registro de datos en la base de datos.
Descripción: Verificar que los datos ingresados a través de los servicios web se encuentren en
la tabla correspondiente de la base de datos
• Tener acceso a la base de datos
• El acceso a datos debe estar creado
• Tener las función o funciones creadas
• Tener la conexión con la base de datos.

• Solicitar el ingreso de un usuario
• Ingresar los datos solicitados
• Guardar la información
• Verificar que los campos ingresados se encuentren en la base de datos y tabla
correspondiente
Resultado esperado: Información guardada en la tabla correspondiente de la base de datos

Sistema LULY SaaS
Página 27
MANUAL TÉCNICO
Número de Tarea: TI_02 Nombre de Tarea: Desarrollar la interfaz de usuario para

el ingreso de usuarios
Descripción: Como desarrollador deseo realizar la interfaz que me permita ingresar los datos de
los usuarios en la tabla correspondiente de la base de datos del proyecto.
• Verificar que los datos ingresados a través de la interfaz se encuentren en la tabla

correspondiente de la base de datos.
Código: PA_01_TI_02 Historia de Usuario: HU_01 Registro de usuarios
Nombre: Verificar que los datos ingresados a través de la interfaz se encuentren en la base de
datos
Descripción: Verificar que los datos ingresados a través de la interfaz se encuentren en la tabla
correspondiente de la base de datos y se muestre un mensaje de confirmación o error de registro
Condiciones de Ejecución: Debe estar creado el acceso a datos y el servicio web

correspondiente
• Ir a la opción de registrar usuarios
• Llenar el formulario de registro de usuarios
• Presionar en el botón guardar
• Esperar respuesta
• Verificar la base de datos
Resultado esperado: Información guardada en la tabla correspondiente de la base de datos y se
muestra un mensaje de confirmación o error de registro de datos
Sistema LULY SaaS
Página 28
MANUAL TÉCNICO
10.5.4 HU_02 Consulta de usuarios registrados
Para poder consultar los usuarios registrados se realizó los servicios web necesarios que faciliten
la consulta, se implementó una tarea de ingeniería con la prueba de aceptación respectiva, esta
historia de usuario fue considerada como prioridad alta para el desarrollo del proyecto, a
continuación, se detallan las tares de ingeniería y pruebas de aceptación:
HISTORIA DE USUARIO
Número: HU_02 Nombre: Consulta de usuarios registrados
Descripción: Como desarrolladores deseamos realizar la funcionalidad que permitan

acceder a la información de los usuarios registrados.
Observaciones:
• Verificar si el usuario existe o no en la base de datos y se muestre un mensaje.

• Verificar si los datos de los usuarios registrados son correctos
Código: PA_01 Historia de Usuario: HU_02 Consulta de usuarios registrados
Nombre: Consulta de datos en la base de datos.
Descripción: Verificar si el usuario existe o no en la base de datos y se muestre un mensaje.
Condiciones de Ejecución: Tener el acceso a la base de datos

• En la opción de búsqueda ingresar el id, nombre o apellido.

• Presionar el botón buscar
• Esperar resultados
Sistema LULY SaaS
Página 29
MANUAL TÉCNICO
Resultado esperado: Si el usuario no se encuentra se mostrará un mensaje “El usuario no

existe”
Código: PA_02 Historia de Usuario: HU_02 Consulta de usuarios registrados
Nombre: Registro de datos en la base de datos.
Descripción: Verificar que los datos ingresados del usuario sean correctos


Resultado esperado: Si el usuario existe se mostrarán los datos correspondientes al usuario.
Historia técnica: HU_02 Consulta de usuarios registrados
Número de Tarea: TI_01. Nombre de Tarea: Desarrelolar el acceso a datos

correspondiente a la consulta usuarios
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita consultar la
información de los usuarios en la tabla correspondiente de la base de datos del proyecto.
• Verificar que los datos correspondan al usuario

Sistema LULY SaaS
Página 30
MANUAL TÉCNICO
Código: PA_01_TI_01 Historia de Usuario: HU_02 Consulta de usuarios registrados
Nombre: Consultar información de los usuarios
Descripción: Verificar que los datos sean correctos


Resultado esperado: Se listarán todos los datos del usuario.
Historia técnica: HU_02 Consulta de usuarios registrados
Número de Tarea: TI_02. Nombre de Tarea: desarrolar la interfaz de usuario

correspondiente para consultar los usuarios
Descripción: Como desarrollador deseo realizar la interfaz de usuario que me permita consultar
la información de los usuarios en la tabla correspondiente de la base de datos del proyecto.
• Verificar que la interfaz de usuario corresponda al diseño establecido
Código: PA_01_TI_02 Historia de Usuario: HU_02 Consulta de usuarios registrados

Sistema LULY SaaS
Página 31
MANUAL TÉCNICO
Nombre: Verificar que la interfaz de usuario corresponda al diseño establecido
Descripción: Verificar que los datos se muestren correctamente en el interfaz de usuario para
consultar la información de los usuarios
• Tener el acceso a la base de datos
• El servicio web y acceso a dato debe estar creado
• Deben existir datos ingresados para realizar las pruebas
• Ir a la opción usuarios
• Listar todos los usuarios
Resultado esperado: Se listarán todos los datos del usuario o los usuarios registrados
10.5.5 HU_03 Eliminar usuarios registrados
Para poder eliminar los usuarios registrados se implementó el acceso a datos, el servicio web y el
desarrollo de la interfaz necesaria para cumplir con dicha tarea. Esta historia de usuario está
valorada con prioridad alta y se desarrolló con 20 puntos 10 puntos estimados, esta HU tiene
como propósito eliminar de manera lógica a los usuarios registrados esto con el fin de mantener
la información internamente de ser necesaria.
HISTORIA DE USUARIO
Número: HU_03 Nombre: Eliminar usuarios registrados

eliminar la información de los usuarios registrados.
Sistema LULY SaaS
Página 32
MANUAL TÉCNICO
Observaciones: Se realizará un borrado lógico, no se eliminará la información de la base

de datos
• Verificar si el usuario se eliminó correctamente, mostrar un mensaje de confirmación

o error de eliminación.
Código: PA_01 Historia de Usuario: HU_03 Eliminar usuarios registrados
Nombre: Eliminar los usuarios registrados.
Descripción: verificar si los datos del usuario ingresado se han eliminado correctamente,
mostrar mensaje de confirmación o error
Condiciones de Ejecución: Tener el registro de usuarios en la base de datos


• Presionar el botón eliminar
Resultado esperado: Se mostrará un mensaje que indique que el usuario se ha eliminado
correctamente.
Historia técnica: HU_03 Eliminar usuarios registrados.
Número de Tarea: TI_01. Nombre de Tarea: Desarrollar el acceso a datos para que
permita eliminar usuarios

Sistema LULY SaaS
Página 33
MANUAL TÉCNICO
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita eliminar los
datos de los usuarios registrados.
• Verificar si se muestra el mensaje de eliminación de usuario
Código: PA_01_TI_01 Historia de Usuario: HU_03 Eliminar usuarios registrados
Nombre: Eliminar los usuarios registrados.
Descripción: verificar si se muestra el mensaje de confirmación de eliminación
• Tener el registro de usuarios en la base de datos
• Ejecutar la consola
• Mostrar reporte de usuarios registrados
• Eliminar un usuario
correctamente.
Historia técnica: HU_03 Eliminar usuarios registrados.
Número de Tarea: TI_02. Nombre de Tarea: Desarrollar la interfaz de usuario que

permita eliminar usuarios

Sistema LULY SaaS
Página 34
MANUAL TÉCNICO
Descripción: Como desarrollador deseo realizar la interfaz que me permita eliminar los datos de
los usuarios registrados.
• Verificar si muestra en el formulario el botón de eliminar usuarios
Código: PA_01_TI_02 Historia de Usuario: HU_03 Eliminar usuarios registrados
Nombre: Verificar si se muestra el botón de eliminar usuarios
Descripción: verificar si se muestra el botón para eliminar usuarios
• Obtener un reporte de usuarios registrados
• Presionar en el botón eliminar
correctamente.
10.5.6 HU_04 Autenticación de usuario
Esta historia de usuario tiene como fin verificar la autenticación de usuarios, se verifica si el
usuario y contraseña con correctos, esto permite el control de usuarios que acceden al sistema.
HISTORIA DE USUARIO
Número: HU_04 Nombre: Autenticación de usuario

Sistema LULY SaaS
Página 35
MANUAL TÉCNICO

autenticar usuarios.
Observaciones: Se realizará la autenticación de usuarios
• Verificar si el usuario y contraseña con correctos
Código: PA_01 Historia de Usuario: HU_04 Autenticación de usuario
Nombre: Autenticación de usuario
Descripción: verificar si los datos de autenticación son correctos, mostrar mensaje de

confirmación.

• Presionar en la opción inicio de sesión

• Ingresar el usuario y contraseña
• Presionar en ingresar
• Esperar confirmación
Resultado esperado: Se mostrará un mensaje que indique que el usuario se ha autenticado
correctamente
Historia técnica: HU_04 Autenticación de usuario

Sistema LULY SaaS
Página 36
MANUAL TÉCNICO
Número de Tarea: TI_01. Nombre de Tarea: Realizar el acceso a datos para

autenticar usuarios
Descripción: Como desarrollador deseo realizar la función que me permita autenticar usuarios
• Mostrar un mensaje de autenticación de usuario
Código: PA_01_TI_01 Historia de Usuario: HU_04 Autenticación de usuario
Nombre: Autenticación de usuario
Descripción: verificar si los datos de autenticación son correctos, mostrar mensaje de

confirmación.

• Presionar en la opción inicio de sesión

• Ingresar el usuario y contraseña
• Presionar en ingresar
• Esperar confirmación
correctamente
Historia técnica: HU_04 Autenticación de usuario
Número de Tarea: TI_02 Nombre de Tarea: Realizar la interfaz de usuario para

autenticar usuarios
Sistema LULY SaaS
Página 37
MANUAL TÉCNICO
Descripción: Como desarrollador deseo realizar la interfaz que me permita autenticar usuarios
• Verificar si se muestra el formulario para autenticar usuarios
Código: PA_01_TI_02 Historia de Usuario: HU_04 Autenticación de usuario
Nombre: Verificar si se muestra el formulario para autenticar usuarios
Descripción: verificar si se muestra en el navegador el formulario de autenticación de usuario
• Los servicios web deben estar generados
• Presionar en la opción de iniciar sesión
• Llevar los campos
• Verificar el formulario
• Presionar en autenticar
correctamente y el formulario se mostrará correctamente en la interfaz
10.6 SPRINT 3
Este esprint se desarrollan las historias de usuario 5,6,7,8,9 y 10 que tiene como desarrollo la
implantación de las funcionalidades como el control de sesiones activas para un usuario,
Sistema LULY SaaS
Página 38
MANUAL TÉCNICO
contratación de un servicio, registro y modificación de datos de una empresa, verificación de pago

de una suscripción y notificación de suscripciones por caducar.
10.6.1 HU_05 Control de sesiones activas de un usuario
La HU_05 mantiene el control de sesiones activas de los usuarios que acceden al sistema, para lo
cual es necesario la realización el servicio web que permita el control así también se hace un
control de sesiones, rutas y roles timando en cuenta que debe existir conexión entre la interfaz y
los servicios del backend, se espera un mensaje de confirmación o fallo de conexión dependiendo
del caso.
HISTORIA DE USUARIO
Número: HU_5 Nombre: Control de sesiones activas de un usuario
Descripción: Como desarrolladores deseamos realizar la funcionalidad para el control de

sesiones activas de un usuario.
Observaciones:
• Verificar si se muestra el mensaje de confirmación o error de conexión
Código: PA_01 Historia de Usuario: HU_05 Control de sesiones activas de un

usuario
Nombre: Control de sesiones activas
Descripción: Verificar el mensaje de confirmación o error de conexión a una sesión

Sistema LULY SaaS
Página 39
MANUAL TÉCNICO
• Iniciar sesión ingresando el usuario y contraseña

• Presionar el botón ingresar
• Esperar mensaje de respuesta
Resultado esperado: Se mostrará un mensaje que indique que la conexión ha establecido
exitosamente
Historia técnica: HU_05 Control de sesiones activas de un usuario

controlar las sesiones activas
Descripción: Como desarrollador deseo realizar la función que me permita controlar las sesiones
activas
• Verificar la conexión entre sesiones y rutas.
Código: PA_01_TI_01 Historia de Usuario: HU_05 Control de sesiones activas de un

usuario
Nombre: Conexión entre sesiones y rutas
Descripción: Verificar que exista conexión entre las sesiones y rutas
Condiciones de Ejecución: Tener creado el servicio web

Sistema LULY SaaS
Página 40
MANUAL TÉCNICO

• Verificar en la consola el token
Resultado esperado: Se mostrará la ruta con el token correspondiente a la sesión activa
Historia técnica: HU_05 Control de sesiones activas de un usuario

controlar las sesiones activas
Descripción: Como desarrollador deseo realizar la interfaz que me permita controlar las sesiones
activas
• Verificar la conexión entre roles y rutas
Código: PA_01_TI_02 Historia de Usuario: HU_05 Control de sesiones activas

de un usuario
Nombre: Conexión entre sesiones y rutas
Descripción: Verificar que exista conexión entre los roles y las rutas
Condiciones de Ejecución: Tener creado el servicio web


Sistema LULY SaaS
Página 41
MANUAL TÉCNICO
• Verificar en la consola el token
Resultado esperado: Se mostrará la ruta con el token correspondiente a la sesión activa
10.6.2 HU_06 Contratación de servicio de gestión de inventarios
Esta historia de usuario tiene como fin generar la contratación de un servicio con un plan
correspondiente a dicho servicio, para lo cual se ha realizado los métodos necesarios que permitan
cumplir con el requerimiento planteado, así también se ha realizado la interfaz de usuario para la
contratación de servicios.
HISTORIA DE USUARIO
Nombre: Contratación de servicio de gestión de

Número: HU_6
inventarios
Descripción: Como desarrolladores deseamos realizar la funcionalidad para la contratación

del servicio de inventarios
Observaciones:
• Verificar si se muestra el mensaje de conformación o error de contratación del servicio
Código: PA_01 Historia de Usuario: HU_06 Contratación de servicio de

gestión de inventarios
Nombre: Verificación de mensaje de conformación o error de contratación de servicio

Sistema LULY SaaS
Página 42
MANUAL TÉCNICO
Descripción: Verificar el mensaje de confirmación o error de contratación del servicio
• Tener creado el servicio web
• Tener datos de prueba ingresado
• Ir a la función programada
• Contratar un servicio
• Presionar en la opción contratar
Resultado esperado: Se mostrará un mensaje que indique que la contratación del servicio ha
sido exitosa o fallida
Historia técnica: HU_06 Contratación de servicio de gestión de inventarios
Número de Tarea: TI_01. Nombre de Tarea: Realizar el acceso a datos para la

contratación de servicio de gestión de inventarios
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita contratar el
servicio de inventarios
• Verificar si los servicios contratados se guardan en la base de datos correspondiente
Sistema LULY SaaS
Página 43
MANUAL TÉCNICO
Código: PA_01_TI_01 Historia de Usuario: HU_06 Contratación de servicio de

Nombre: Verificación si los servicios contratados se guardan en la base de datos
Descripción: Verificar si los servicios contratados se guardan en la base de datos

correspondiente
Condiciones de Ejecución: Tener datos ingresados para los servicios y planes

• Realizar la consulta de servicios y planes disponibles desde la consola

• Escoger un plan
Resultado esperado: Se mostrará en la base de datos la información correspondiente al plan
contratado
Historia técnica: HU_06 Contratación de servicio de gestión de inventarios
Número de Tarea: TI_02 Nombre de Tarea: Realizar la interfaz para la

contratación de servicio de gestión de inventarios
Descripción: Como desarrollador deseo realizar la interfaz de usuario que me permita contratar
el servicio de inventarios
• Verificar si los servicios contratados desde la interfaz se guardan en la base de datos

Sistema LULY SaaS
Página 44
MANUAL TÉCNICO
Código: PA_01_TI_02 Historia de Usuario: HU_06 Contratación de servicio de

Nombre: Verificación si los servicios contratados desde la interfaz se guardan en la base de

datos
Descripción: Verificar si los servicios contratados desde la interfaz se guardan en la base de

datos correspondiente
• Tener datos ingresados para los servicios
• Ir a la opción de servicios
• Verificar los servicios existentes
• Presionar en la opción contratar servicio
• Llenar el formulario de contratación
Resultado esperado: Se mostrará en la base de datos la información correspondiente al
servicio contratado
10.6.3 HU_07 Registro de datos de la empresa de un usuario
La historia de usuario cuenta con las tareas y pruebas necesarias que permitan registrar los datos
de la empresa de un usuario, es importante tener un registro de empresa o empresas para poder
contratar un servicio disponible.
HISTORIA DE USUARIO
Nombre: Registro de datos de la empresa de un

Número: HU_7
usuario

Sistema LULY SaaS
Página 45
MANUAL TÉCNICO
Descripción: Como desarrolladores deseamos realizar la funcionalidad para el registro de

datos de la empresa de un usuario
Observaciones:
• Verificar si se muestra el mensaje de conformación de registro de una empresa
Código: PA_01 Historia de Usuario: HU_07 Registro de datos de la empresa

de un usuario
Nombre: Verificación de mensaje de conformación
Descripción: Verificar el mensaje de confirmación o error de registro de una empresa
Condiciones de Ejecución: Tener creado el servicio web y la interfaz de usuario


• Presionar en la opción de agregar nueva empresa
• Llenar el formulario de registro de empresa
• Presionar en guardar
Resultado esperado: Se mostrará un mensaje que indique que el registro de empresa fue
exitoso
Sistema LULY SaaS
Página 46
MANUAL TÉCNICO
Historia técnica: HU_07 Registro de datos de la empresa de un usuario
Número de Tarea: TI_01. Nombre de Tarea: Realizar el acceso a datos para el

registro de datos de la empresa de un usuario
Descripción: Como desarrollador deseo realizar la función que me permita registrar la

información de una empresa
• Verificar que la información se guarde en la base de datos
Código: PA_01_TI_01 Historia de Usuario: HU_07 Registro de datos de la empresa

de un usuario
Nombre: Verificar que la información de guarde en la base de datos
Descripción: Se requiere verificar si se guardó la información del registro de empresa en la base

de datos
• La base de datos debe estar disponible
• El servicio web y el acceso a datos debe estar creado
• Ir a la base de datos y verificar si existen los datos ingresados
Resultado esperado: Se mostrará un mensaje que indique que los datos se guardaron
exitosamente y los datos se mostraran en la base de datos
Sistema LULY SaaS
Página 47
MANUAL TÉCNICO
Historia técnica: HU_07 Registro de datos de la empresa de un usuario
Número de Tarea: TI_02. Nombre de Tarea: Realizar la interfaz para el registro de

Descripción: Como desarrollador deseo realizar la interfaz que me permita registrar la

• Verificar que la información ingresada desde la interfaz se guarde en la base de datos
Código: PA_01_TI_02 Historia de Usuario: HU_07 Registro de datos de la empresa

de un usuario
Nombre: Verificar que la información ingresada de la interfaz se guarde en la base de datos
Descripción: Se requiere verificar si se guardó la información del registro de empresa en la base

de datos y que el formulario de registro corresponda al diseño establecido
• Ir a la opción de empresas
• Presionar en la opción de agregar empresa
Sistema LULY SaaS
Página 48
MANUAL TÉCNICO
10.6.4 HU_08 Modificar los datos de una empresa de un usuario
Es importante contar con los métodos e interfaz de usuario que permitan modificar los datos de
una empresa de un usuario ya que en el registro pueden existir errores en el ingreso de datos, para
lo cual se ha creado la historia de usuario y las tareas de ingeniería necesarias con sus pruebas
respectivamente.
HISTORIA DE USUARIO
Nombre: Modificar los datos de una empresa de un

Número: HU_8
usuario
Descripción: Como desarrolladores deseamos realizar la funcionalidad que me permita

modificar los datos de una empresa de un usuario
Observaciones:
• Modificar los datos de una empresa previamente registrada y verificar que se guarden
los campos modificados
Código: PA_01 Historia de Usuario: HU_08 Modificar los datos de una

empresa de un usuario
Sistema LULY SaaS
Página 49
MANUAL TÉCNICO
Nombre: Modificar los datos de una empresa previamente registrada y verificar que se guarden
Descripción: Los campos modificados deben actualizarse en la base de datos
Condiciones de Ejecución: Debe existir una empresa registrada en la base de datos

• Mostrar las empresas registradas
• Modificar una empresa
Resultado esperado: Se mostrará un mensaje que indique que los campos se han modificado
con éxito y se mostrar los campos actualizados en la base de datos
Historia técnica: HU_08 Modificar los datos de una empresa de un usuario
Número de Tarea: TI_01. Nombre de Tarea: Realizar la interfaz para modificar los
Descripción: Como desarrollador deseo realizar la interfaz que me permita modificar la

• Verificar que la interfaz diseñada se muestre correctamente en el navegador
Sistema LULY SaaS
Página 50
MANUAL TÉCNICO
Código: PA_01_TI_01 Historia de Usuario: HU_08 Modificar los datos de una

Nombre: Verificar que la interfaz diseñada se muestre correctamente en el navegador
Descripción: Se requiere verificar si la interfaz diseñada se muestra correctamente en el

navegador
• Tener acceso a internet
• Tener datos de prueba previamente ingresados
• Iniciar sesión
• En el panel de opciones presionar en empresas
• Presionar en la opción de modificar
• Modificar los campos necesarios
Resultado esperado: Se mostrará la interfaz de usuario en el navegador con todos los datos
de la empresa
Historia técnica: HU_08 Modificar los datos de una empresa de un usuario
Número de Tarea: TI_02 Nombre de Tarea: Realizar el acceso a datos para

modificar los datos de la empresa de un usuario
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita modificar la
Sistema LULY SaaS
Página 51
MANUAL TÉCNICO
• Verificar que los datos se actualicen en la base de datos
Código: PA_01_TI_02 Historia de Usuario: HU_08 Modificar los datos de una

Nombre: Verificar que los datos se actualicen en la base de datos
Descripción: Se requiere verificar que la interfaz diseñada se muestre correctamente en el

navegador y que los datos modificados desde la interfaz se actualicen en la base de datos
• Mostrar las empresas registradas
Resultado esperado: los datos modificados se muestran correctamente en la base de dato
10.6.5 HU_09 Verificación pago de una suscripción de un servicio
Es necesario verificar los pagos realizados por el usuario para poder dar acceso a dicho servicio
contratado, se hace un control de pagos dependiendo el plan que se ha contratado el cual puede
ser mensual o anual.
HISTORIA DE USUARIO
Nombre: Verificación pago de una suscripción de un

Número: HU_9
servicio
Sistema LULY SaaS
Página 52
MANUAL TÉCNICO

verificar el pago de una suscripción
Observaciones:
• Verificar si el pago de una suscripción se realizó correctamente
Código: PA_01 Historia de Usuario: HU_09 Verificación pago de una

suscripción de un servicio
Nombre: Verificar si el pago de una suscripción se realizó correctamente
Descripción: se debe verificar si el pago se muestra en la base de datos
Condiciones de Ejecución: Debe existir servicios y planes registrados

• Acceder al servicio de pagos
• Verificar fecha de ultimo pago
• Revisar la base de datos
Resultado esperado: Se mostrará en la base de datos los pagos que ha realizado un cliente
Historia técnica: HU_09 Verificación pago de una suscripción de un servicio

Sistema LULY SaaS
Página 53
MANUAL TÉCNICO

verificar los pagos
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita verificar los
pagos de una suscripción
• Verificar que los datos se muestren en la base de datos
Código: PA_01_TI_01 Historia de Usuario: HU_09 Verificación pago de una

Nombre: Verificar que los datos ingresados se muestren en la base de datos
Descripción: Se requiere verificar que los datos ingresados en la base de datos
• El acceso y servicio web deben estar creados
• Ingresar los datos de un pago
Resultado esperado: Se mostrarán en la base de datos la información de los pagos de los
usuarios
Sistema LULY SaaS
Página 54
MANUAL TÉCNICO
Historia técnica: HU_09 Verificación pago de una suscripción de un servicio
Número de Tarea: TI_02 Nombre de Tarea: Realizar la interfaz para verificar los
pagos
Descripción: Como desarrollador deseo realizar la interfaz que me permita verificar los pagos
de una suscripción
• Verificar que en la interfaz se muestren los datos correspondientes a los pagos de una
suscripción
Código: PA_01_TI_02 Historia de Usuario: HU_09 Verificación pago de una

Nombre: Verificar que en la interfaz se muestren los datos correspondientes a los pagos

navegador y los campos corresponden a los pagos de una suscripción
• Iniciar sesión
• En el panel de opciones presionar en pagos
• Verificar datos de la interfaz con los de la base de datos
correspondientes a los pagos de las suscripciones
Sistema LULY SaaS
Página 55
MANUAL TÉCNICO
10.6.6 HU_10 Notificación de suscripciones por expirar
Las notificaciones de pagos de suscripciones se lo realizan tomando en cuenta un lapso de 3 días

antes de que dicha suscripción expire, para lo cual se muestra una campanita de notificaciones
que puede ser fácilmente visualizada por el usuario.
HISTORIA DE USUARIO
Número: HU_10 Nombre: Notificación de suscripciones por expirar

notificar la expiración de pagos
Observaciones:
• Verificar que la fecha de expiración se suscripción sea de 3 días antes de la terminación

del contrato.
Código: PA_01 Historia de Usuario: HU_10 Notificación de suscripciones por

expirar
Nombre: Verificar si la fecha de expiración sea de 3 días antes de expirar la suscripción
Descripción: Se debe verificar que la notificación de expiración se muestre 3 días antes de

expirar la suscripción
Condiciones de Ejecución: Debe existir una suscripción registrada

Sistema LULY SaaS
Página 56
MANUAL TÉCNICO
• Ir a la opción de suscripciones
• Ir a la opción de pagos
• Verificar fecha de suscripción
• Revisar las notificaciones
• Verificar fecha de próximo pago
Resultado esperado: Se mostrará una notificación de próximo pago
Historia técnica: HU_10 Notificación de suscripciones por expirar

verificar la expiración de pagos
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita verificar las
notificaciones de suscripciones por expirar
• Verificar en la base de datos las fechas de los próximos pagos
Código: PA_01_TI_01 Historia de Usuario: HU_10 Notificación de suscripciones por

expirar
Nombre: Verificar en la base de datos las fechas de los próximos pagos
Descripción: Se requiere verificar en la base de datos las fechas de los próximos pagos
Sistema LULY SaaS
Página 57
MANUAL TÉCNICO
• Ir a la opción programada
• Verificar las notificaciones
Resultado esperado: Se mostrarán en la base de datos los pagos realizados por el usuario y
las fechas de los próximos pagos
Historia técnica: HU_10 Notificación de suscripciones por expirar
Número de Tarea: TI_02 Nombre de Tarea: Realizar la interfaz para verificar la

expiración de pagos
Descripción: Como desarrollador deseo realizar la interfaz que me permita verificar las
• Verificar que en la interfaz se muestre la notificación en la campanita
Código: PA_01_TI_02 Historia de Usuario: HU_10 Notificación de suscripciones por

expirar
Nombre: Verificar que en la interfaz se muestre la campanita de notificaciones

Sistema LULY SaaS
Página 58
MANUAL TÉCNICO
Descripción: Se requiere verificar si la interfaz diseñada muestra la campanita de notificaciones
• Iniciar sesión
• En el panel de opciones presionar en pagos
• Verificar las notificaciones
Resultado esperado: Se mostrará la interfaz de usuario en el navegador todas las
10.7 SPRINT 4
En este sprint se desarrollaron 7 historia de usuario que fueron 11,12,13,141,5,16 y 17
correspondientes a las funcionalidades de agregación de nuevos planes, registro, modificación,
búsqueda y eliminación de proveedores de materia prima, así también se implementó el registro
y modificación de materia prima, cada una de las historias de usuario cuentas con las tareas y
pruebas de aceptación correspondientes.
10.7.1 HU_11 Agregar nuevos planes a un servicio
La historia de usuarios está diseñada para cumplir con el desarrollo de la funcionalidad que
permita agregar nuevos palanes a un servicio, para lo cual se han desarrollado dos tareas de
ingeniera para el acceso a datos y el desarrollo de la interfaz de usuario, cada tarea cuanta con su
respectiva prueba de aceptación como se muestra a continuación:
HISTORIA DE USUARIO
Número: HU_11 Nombre: Agregar nuevos planes a un servicio

Sistema LULY SaaS
Página 59
MANUAL TÉCNICO
Descripción: Como desarrolladores deseamos realizar la funcionalidad para agregar planes

a un servicio
Observaciones:
• Verificar que se muestre el mensaje de confirmación o error de agregación de planes
Código: PA_01 Historia de Usuario: HU_11 Agregar nuevos planes a un

servicio
Nombre: Verificar que se muestre el mensaje de confirmación o error de agregación de planes
Descripción: Se requiere verificar si se muestra el mensaje de éxito o error al agregar planes a

un servicio
• La interfaz de usuario debe estar diseñada
• Ir a la opción de servicios
• Ir a la opción de planes
• Agregar un nuevo plan
Resultado esperado: Se mostrará un mensaje que indique que se agregaron nuevos planes
para el servicio
Historia técnica: HU_11 Agregar nuevos planes a un servicio

Sistema LULY SaaS
Página 60
MANUAL TÉCNICO

agregar nuevos planes a un servicio
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita agregar
nuevos planes a un servicio
• Verificar que los datos ingresados se guarden correctamente en la base de datos
Código: PA_01_TI_01 Historia de Usuario: HU_11 Agregar nuevos planes a un

servicio
Nombre: Verificar que los datos ingresados se guarden correctamente en la base de datos
Descripción: Verificar que los datos ingresados en consola se guarden correctamente en la base
de datos
• Llenar los campos para agregar un plan
• Guardar los datos ingresados
• Ir a la base de datos y verificar que exista los datos ingresados
Resultado esperado: Se mostrará la información ingresada con respecto a los planes en la
base de datos

Sistema LULY SaaS
Página 61
MANUAL TÉCNICO
Historia técnica: HU_11 Agregar nuevos planes a un servicio
Número de Tarea: TI_02. Nombre de Tarea: Realizar la interfaz de usuario para

agregar nuevos planes a un servicio
Descripción: Como desarrollador deseo realizar la interfaz que me permita agregar nuevos
planes a un servicio
• Verificar que la interfaz de usuario se muestra correctamente en el navegador
Código: PA_01_TI_01 Historia de Usuario: HU_11 Agregar nuevos planes a un

servicio
Nombre: Verificar que la interfaz de usuarios se muestre correctamente en el navegador
Descripción: Verificar que la interfaz diseñada se muestre correctamente en el navegador, y que

los campos ingresados se guarden en la base de datos
• Dirigirse a la opción de servicios
• Presionar en la opción de agregar nuevo plan
• Completar el formulario de ingreso de nuevo plan
• Verificar si los datos se guardaron correctamente en la base de datos
Sistema LULY SaaS
Página 62
MANUAL TÉCNICO
exitosamente, la interfaz se nuestra en el navegador de acuerdo con el diseño establecido y los
datos se mostraran en la base de datos
10.7.2 HU_12 Registro de proveedores de materia prima
Para el registro de proveedores de materia prima se toma en cuenta el tipo de materia prima que
es distribuida por dicho proveedor, para poder tener el registro se ha diseñado la historia de
usuario correspondiente a dicha función, así también se implementó las tareas y pruebas de
aceptación necesarias.
HISTORIA DE USUARIO
Número: HU_12 Nombre: Registro de proveedores de materia prima

realizar el registro de proveedores de materia prima
Observaciones:
• Verificar que se muestre un mensaje cuando se guardan los datos del proveedor
Código: PA_01 Historia de Usuario: HU_12 Registro de proveedores de

materia prima
Descripción: Verificar el mensaje de confirmación o error de registro de proveedores y que los

datos se muestren en la base de datos
Sistema LULY SaaS
Página 63
MANUAL TÉCNICO
• Debe estar creado el acceso a datos
• El servicio web debe estar generado
• Dirigirse a la opción de proveedores
• Presionar la opción de agregar nuevo proveedor
• Llenar el formulario de registro
• Esperar mensaje de confirmación o error
Resultado esperado: Se mostrará un mensaje que indique que el registro del proveedor fue
exitoso
Historia técnica: HU_12 Registro de proveedores de materia prima

registrar proveedores de materia prima
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita registrar
proveedores de materia prima
• Verificar que los datos ingresados se muestren en la base de datos
Código: PA_01_TI_01 Historia de Usuario: HU_12 Registro de proveedores de

materia prima
Sistema LULY SaaS
Página 64
MANUAL TÉCNICO
Nombre: Verificar que los datos ingresados se muestren en la base de datos
Descripción: Se requiere verificar que los datos ingresados se muestren en la base de datos
• El acceso a datos y el servicio web deben estar generados
• Llenar los campos para registrar un proveedor
• Ir a la base de datos y verificar que existan los datos ingresados
Historia técnica: HU_12 Registro de proveedores de materia prima

registrar proveedores de materia prima
Descripción: Como desarrollador deseo realizar la interfaz de usuario que me permita registrar
• Verificar que la interfaz se muestre correctamente en el navegador web

Sistema LULY SaaS
Página 65
MANUAL TÉCNICO
Código: PA_01_TI_02 Historia de Usuario: HU_12 Registro de proveedores de

materia prima
Nombre: Verificar que la interfaz se muestre correctamente en el navegador

navegador y que se muestre un mensaje de que indique que los datos se guardaron con éxito
• La interfaz de usuario debe estar creada
10.7.3 HU_13 Modificar proveedores de materia prima
Para cumplir con la funcionalidad que permite modificar proveedores de materia prima se
desarrolló dos tareas de ingeniería una para el acceso a datos y otra para diseñar la interfaz, cada
tarea de ingeniería cuanta con las respectivas pruebas de aceptación.
HISTORIA DE USUARIO
Número: HU_13 Nombre: Modificar proveedores de materia prima

Sistema LULY SaaS
Página 66
MANUAL TÉCNICO
Descripción: Como desarrolladores deseamos realizar la funcionalidad para modificar los

datos de los proveedores de materia prima
Observaciones:
• Verificar que los nuevos datos se actualicen en la base de datos
Código: PA_01 Historia de Usuario: HU_13 Modificar proveedores de

materia prima
Nombre: Verificación de mensaje de conformación o error de modificación de datos
Descripción: Verificar el mensaje de confirmación o error al modificar los proveedores y que

los datos se muestren en la base de datos
• Debe estar creado el acceso a datos
Resultado esperado: Se mostrará un mensaje que indique que el registro del proveedor fue
exitoso
Sistema LULY SaaS
Página 67
MANUAL TÉCNICO
Historia técnica: HU_13 Modificar proveedores de materia prima

modificar proveedores de materia prima
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita modificar los
datos del proveedor de materia prima
• Verificar que la información de guarde en la base de datos
Código: PA_01_TI_01 Historia de Usuario: HU_13 Modificar proveedores de

materia prima
Nombre: Verificar que los nuevos datos se actualicen en la base de datos
Descripción: Verificar que los datos se actualicen en la base de datos y se muestre un mensaje
de confirmación o error de modificación de los datos
• Tener creado el acceso a datos
• Debe existir al menos un registro de prueba
• Modificar los campos del registro de proveedor
• Ir a la base de datos y verificar que existan los datos ingresados
Resultado esperado: Se mostrará los campos actualizados en la base de datos
Sistema LULY SaaS
Página 68
MANUAL TÉCNICO
Historia técnica: HU_13 Modificar proveedores de materia prima

modificar proveedores de materia prima
Descripción: Como desarrollador deseo realizar la interfaz de usuario que me permita modificar
los datos del proveedor de materia prima
• Verificar que la información de guarde en la base de datos y que la interfaz de usuario

se muestre correctamente en el navegador
Código: PA_01_TI_02 Historia de Usuario: HU_13 Modificar proveedores de

materia prima
Nombre: Verificar que la información de guarde en la base de datos y que la interfaz de usuario
se muestre correctamente en el navegador
Descripción: Se requiere verificar si se guardó la información modificada de los proveedores y

que la interfaz se muestre de acuerdo con el diseño planteado
• Debe existir al menos un registro de proveedor
• Ir a la opción de proveedores
Sistema LULY SaaS
Página 69
MANUAL TÉCNICO
• Presionar en la opción de modificar proveedor

Resultado esperado: Se mostrará un mensaje que indique que los datos se modificaron
10.7.4 HU_14 Buscar proveedores de materia prima
Para poder buscar proveedores de materia prima es necesario tener datos registrados, para esto se
han realizado dos tareas de ingeniera una para el acceso a datos que me permite hacer una consulta
de todos los proveedores existentes en la base de datos, también se ha diseñado la interfaz de
usuarios que permita realizar la búsqueda, cada tarea de ingeniera cuenta con la respectiva prueba
de aceptación como se muestra a continuación:
HISTORIA DE USUARIO
Número: HU_14 Nombre: Buscar proveedores de materia prima
Descripción: Como desarrolladores deseamos realizar la funcionalidad para buscar

Observaciones:
• Verificar si existe el proveedor en la base de datos
Código: PA_01 Historia de Usuario: HU_14 Buscar proveedores de materia

prima
Nombre: Verificar si existe el proveedor en la base de datos

Sistema LULY SaaS
Página 70
MANUAL TÉCNICO
Descripción: Verificar si existe el proveedor en la base de datos y que se muestre un mensaje

de si existe o no el proveedor
• Ingresar la razón social o el nombre del proveedor que desea buscar
• Presionar en la opción de buscar
Resultado esperado: Si el proveedor existe se listarán los datos, si no existe se mostrará un

mensaje que indique que el proveedor no existe en la base de datos
Historia técnica: HU_14 Buscar proveedores de materia prima
Número de Tarea: TI_01. Nombre de Tarea: Realizar el acceso a datos para buscar
proveedores
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita buscar
proveedores
• Verificar si se muestran todos los datos del proveedor

Sistema LULY SaaS
Página 71
MANUAL TÉCNICO
Código: PA_01_TI_01 Historia de Usuario: HU_14 Buscar proveedores de materia

prima
Nombre: Verificar si se muestran todos los datos del proveedor
Descripción: Se requiere verificar que se muestren todos los datos del proveedor
• Listar los proveedores
Resultado esperado: Se mostrarán todos los datos correspondientes al proveedor
Historia técnica: HU_14 Buscar proveedores de materia prima

buscar proveedores
Descripción: Como desarrollador deseo realizar la interfaz que me permita buscar proveedores
• Verificar que la interfaz se muestre correctamente en el navegador y se listen los datos

del proveedor
Sistema LULY SaaS
Página 72
MANUAL TÉCNICO
Código: PA_01_TI_02 Historia de Usuario: HU_14 Buscar proveedores de materia

prima
Nombre: Verificar que la interfaz se muestre correctamente en el navegador y se listen los datos
del proveedor
Descripción: Se requiere verificar que la interfaz el formulario completo con los datos de los
proveedores
• Verificar los datos de los proveedores
Resultado esperado: Se mostrará la interfaz diseñada correctamente en el navegador
10.7.5 HU_15 Eliminar proveedores de materia prima
Para cumplir con esta funcionalidad se hace un borrado lógico es decir los datos se mantienen
internamente, pero en la interfaz de usuario ya no se podrán visualizar, se han desarrollado dos
historias de usuario con las respectivas pruebas de aceptación como se muestra a continuación:
HISTORIA DE USUARIO
Número: HU_15 Nombre: Eliminar proveedores de materia prima

Sistema LULY SaaS
Página 73
MANUAL TÉCNICO
Descripción: Como desarrolladores deseamos realizar la funcionalidad para eliminar

proveedores
Observaciones: Se realizará un borrado lógico, es decir se mantendrán los datos en la base

de datos
• Verificar si se muestra el mensaje de conformación o error de eliminación de proveedor
Código: PA_01 Historia de Usuario: HU_15 Eliminar proveedores de materia

prima
Nombre: Verificación de mensaje de conformación de eliminación de un proveedor
Descripción: Verificar el mensaje de confirmación o error de eliminación de un proveedor


• Presionar en la opción eliminar
Resultado esperado: Se mostrará un mensaje que indique que el proveedor se eliminó con
éxito
Historia técnica: HU_15 Eliminar proveedores de materia prima
Número de Tarea: TI_01. Nombre de Tarea: Realizar el método para eliminar


Sistema LULY SaaS
Página 74
MANUAL TÉCNICO
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita eliminar
• Verificar que la información se elimine correctamente
Código: PA_01_TI_01 Historia de Usuario: HU_15 Eliminar proveedores de materia

prima
Nombre: Verificar que la información se elimine correctamente
Descripción: Se requiere verificar si se eliminó la información del proveedor de materia prima
• Mostrar los proveedores registrados
• Eliminar un registro
Resultado esperado: Se mostrará un mensaje que indique que los datos se eliminaron
correctamente
Historia técnica: HU_15 Eliminar proveedores de materia prima

Sistema LULY SaaS
Página 75
MANUAL TÉCNICO
Número de Tarea: TI_02. Nombre de Tarea: Realizar la interfaz para eliminar

Descripción: Como desarrollador deseo realizar la interfaz de usuario que me permita eliminar
• Verificar que la interfaz se muestre correctamente en el navegador
Código: PA_01_TI_02. Historia de Usuario: HU_15 Eliminar proveedores de materia

prima
Nombre: Verificar que la interfaz se muestre correctamente
Descripción: Se requiere verificar si se eliminó de la interfaz los registros de la materia prima
• La interfaz debe estar desarrollada
• Ir a la opción de materia prima
• Listar los registros
Resultado esperado: Se eliminarán los registros de la interfaz y en la base de datos cambiarán
de estado

Sistema LULY SaaS
Página 76
MANUAL TÉCNICO
10.7.6 HU_16 Registro de materia prima
Es importante para la empresa tener el registro de materia prima ya que permite saber el stock
máximo, mínimo y actual que son necesarios para el desarrollo de un nuevo producto, para lo
cual se ha realizado dos tareas de ingeniería con sus respectivas pruebas de aceptación como se
muestra a continuación:
HISTORIA DE USUARIO
Número: HU_16 Nombre: Registro de materia prima

materia prima
Observaciones:
• Verificar si se muestra el mensaje de conformación de registro de materia prima
Código: PA_01 Historia de Usuario: HU_16 Registro de materia prima
Descripción: Verificar el mensaje de confirmación o error de registro de materia prima


• Presionar en la opción de agregar producto
• Llenar el formulario de registro de nueva materia prima
• Presionar en la opción de variantes
Sistema LULY SaaS
Página 77
MANUAL TÉCNICO
• Llenar le formulario de nueva variante

Resultado esperado: Se mostrará un mensaje que indique que el registro de materia prima fue
exitoso
Historia técnica: HU_16 Registro de materia prima

registro de datos de materia prima
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita el registro de
materia prima
Código: PA_01_TI_01 Historia de Usuario: HU_16 Registro de materia prima
Descripción: Se requiere verificar si se guardó la información del registro de materia prima en

la base de datos
Sistema LULY SaaS
Página 78
MANUAL TÉCNICO
• Llenar el formulario de registro de materia prima
• Llenar el formulario de nueva variante
Historia técnica: HU_16 Registro de materia prima
Número de Tarea: TI_02 Nombre de Tarea: Realizar la interfaz de usuario para el

registro de datos de materia prima
Descripción: Como desarrollador deseo realizar la interfaz de usuario que me permita el registro
de materia prima

navegador
Sistema LULY SaaS
Página 79
MANUAL TÉCNICO
• Ir a la opción de productos
• Agregar nueva materia prima
Resultado esperado: Se mostrará correctamente el formulario de registro de materia prima en
el navegador
10.7.7 HU_17 Modificar materia prima
HISTORIA DE USUARIO
Número: HU_17 Nombre: Modificar materia prima

modificar los datos de materia prima
Observaciones:
• Modificar los datos de materia prima previamente registrados y verificar que se

guarden los campos modificados
Código: PA_01 Historia de Usuario: HU_17 Modificar materia prima

Sistema LULY SaaS
Página 80
MANUAL TÉCNICO
Nombre: Modificar los datos de materia prima previamente registrada y verificar que se guarden
Condiciones de Ejecución: Debe existir materia prima registrada en la base de datos

• Mostrar la materia prima
• Modificar materia prima
Historia técnica: HU_17 Modificar materia prima
Número de Tarea: TI_01. Nombre de Tarea: Realizar la interfaz para modificar

materia prima
Descripción: Como desarrollador deseo realizar la interfaz que me permita modificar materia
prima
Sistema LULY SaaS
Página 81
MANUAL TÉCNICO
Código: PA_01_TI_01 Historia de Usuario: HU_17 Modificar materia prima

navegador
• Iniciar sesión
• En el panel de opciones presionar en productos
de materia prima
Historia técnica: HU_17 Modificar materia prima

modificar los datos de la empresa de un usuario
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita modificar la
información de materia prima
Sistema LULY SaaS
Página 82
MANUAL TÉCNICO
Código: PA_01_TI_02 Historia de Usuario: HU_17 Modificar materia prima

• Mostrar la materia prima registrada
10.8 SPRINT 5
En este sprint se desarrollaron 7 historias de usuario correspondientes a la búsqueda y eliminación
de materia prima, registro, eliminación, modificación, búsqueda y eliminación de productos
terminados, cada una de las historias de usuario cuenta con las tareas y pruebas de aceptación
correspondientes que permitieron un correcto desarrollo de cada una.
10.8.1 HU_18 Buscar materia prima
Para poder buscar materia prima es necesario tener datos registrados, para esto se han realizado
dos tareas de ingeniera una para el acceso a datos que me permite hacer una consulta de toda la
materia prima existentes en la base de datos, también se ha diseñado la interfaz de usuarios que
Sistema LULY SaaS
Página 83
MANUAL TÉCNICO
permita realizar la búsqueda, cada tarea de ingeniera cuenta con la respectiva prueba de
aceptación como se muestra a continuación:
HISTORIA DE USUARIO
Número: HU_18 Nombre: Buscar materia prima
Descripción: Como desarrolladores deseamos realizar la funcionalidad para buscar materia

prima
Observaciones:
• Verificar si existe registros de materia prima en la base de datos
Código: PA_01 Historia de Usuario: HU_18 Buscar materia prima
Nombre: Verificar si existe materia prima en la base de datos
Descripción: Verificar si existe registros de materia prima en la base de datos y que se muestre
un mensaje de si existe o no materia prima registrada
• Ingresar el código o nombre de la materia prima
Sistema LULY SaaS
Página 84
MANUAL TÉCNICO

Resultado esperado: Si la materia prima existe se listarán los datos, si no existe se mostrará
un mensaje que indique que la materia prima no existe en la base de datos
Historia técnica: HU_18 Buscar materia prima
materia prima
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita buscar materia
prima
• Verificar si se muestran todos los datos de la materia prima
Código: PA_01_TI_01 Historia de Usuario: HU_18 Buscar materia prima
Nombre: Verificar si se muestran todos los datos de materia prima
Descripción: Se requiere verificar que se muestren todos los datos de materia prima
Sistema LULY SaaS
Página 85
MANUAL TÉCNICO
• Buscar por código o nombre
Resultado esperado: Se mostrarán todos los datos correspondientes al proveedor
Historia técnica: HU_18 Buscar materia prima

buscar materia prima
Descripción: Como desarrollador deseo realizar la interfaz que me permita buscar materia prima

de la materia prima
Código: PA_01_TI_02 Historia de Usuario: HU_18 Buscar materia prima
de la materia prima
Descripción: Se requiere verificar que la interfaz muestre los datos correspondientes a la materia
prima
Sistema LULY SaaS
Página 86
MANUAL TÉCNICO
Resultado esperado: Se mostrará en la interfaz todos los datos correspondientes a la materia
prima
10.8.2 HU_19 Eliminar materia prima
HISTORIA DE USUARIO
Número: HU_19 Nombre: Eliminar materia prima

materia prima

de datos solo se cambiará el estado de dichos materiales
• Verificar si se muestra el mensaje de conformación o error de eliminación de materia

prima
Sistema LULY SaaS
Página 87
MANUAL TÉCNICO
Código: PA_01 Historia de Usuario: HU_19 Eliminar materia prima
Nombre: Verificación de mensaje de conformación de eliminación de materia prima
Descripción: Verificar el mensaje de confirmación o error de eliminación de materia prima


• Listar materia prima
Resultado esperado: Se mostrará un mensaje que indique que la materia prima se eliminó con
éxito
Historia técnica: HU_19 Eliminar materia prima

materia prima
materia prima
• Verificar que la información se elimine correctamente
Código: PA_01_TI_01 Historia de Usuario: HU_15 Eliminar materia prima

Sistema LULY SaaS
Página 88
MANUAL TÉCNICO
Nombre: Verificar que la información se elimine correctamente
Descripción: Se requiere verificar si se eliminó la información de la materia prima
• Mostrar la materia prima registrada
correctamente
Historia técnica: HU_19 Eliminar materia prima

materia prima
materia prima
• Verificar que el botón de eliminar se muestre correctamente en el navegador
Sistema LULY SaaS
Página 89
MANUAL TÉCNICO
Código: PA_01_TI_02. Historia de Usuario: HU_15 Eliminar materia prima
Descripción: Se requiere verificar si se eliminó la materia prima de la interfaz y en la base de

datos se cambió el estado de dicho registro
• Ir a la opción materia prima
• Presionar el botón Eliminar
• Esperar respuesta y verificar el estado del registro eliminado en la base de datos
Resultado esperado: Se mostrar el botón de eliminar y se borrará el registro de la interfaz, en
la base de datos se cambiará el estado de la materia prima eliminada
10.8.3 HU_20 Registro de productos terminados
Es importante para la empresa tener el registro de productos terminados ya que permite saber el
stock máximo, mínimo y actual que son necesarios para el desarrollo de un nuevo producto, para
lo cual se ha realizado dos tareas de ingeniería con sus respectivas pruebas de aceptación como
se muestra a continuación:
HISTORIA DE USUARIO
Número: HU_20 Nombre: Registro de productos terminados

Sistema LULY SaaS
Página 90
MANUAL TÉCNICO

productos terminados y sus variantes
Observaciones: El registro de variantes hace referencia a los tipos de productos terminados

relacionados con el color y talla
• Verificar si se muestra el mensaje de conformación de registro de productos

terminados
Código: PA_01 Historia de Usuario: HU_20 Registro de productos terminados
Descripción: Verificar el mensaje de confirmación o error de registro de productos terminados


• Presionar en la opción de agregar productos terminados
• Llenar el formulario de registro de productos terminados
• Llenar el formulario de registro de variantes de producto terminado
Resultado esperado: Se mostrará un mensaje que indique que el registro de productos
terminados fue exitoso
Historia técnica: HU_20 Ingresar de productos terminados

Sistema LULY SaaS
Página 91
MANUAL TÉCNICO
Número de Tarea: TI_01. Nombre de Tarea: Realizar el método para el registro de

productos terminados
Código: PA_01_TI_01 Historia de Usuario: HU_20 Registro de productos terminados
Descripción: Se requiere verificar si se guardó la información del registro de productos

terminados en la base de datos
• Llenar el formulario de registro de productos terminados

Sistema LULY SaaS
Página 92
MANUAL TÉCNICO
Historia técnica: HU_20 Registro de productos terminados

registro de productos terminados
de productos terminados

navegador
• Agregar nuevo producto terminado
Resultado esperado: Se mostrará correctamente el formulario de registro de productos
terminados en el navegador y se mostrará el mensaje de datos ingresados correctamente
Sistema LULY SaaS
Página 93
MANUAL TÉCNICO
10.8.4 HU_21 Modificar productos terminados
Para cumplir con la funcionalidad que permite modificar productos terminados se desarrolló dos
tareas de ingeniería una para el acceso a datos y otra para diseñar la interfaz, cada tarea de
ingeniería cuanta con las respectivas pruebas de aceptación.
HISTORIA DE USUARIO
Número: HU_21 Nombre: Modificar productos terminados

modificar los datos de los productos terminado
Observaciones:
• Modificar los datos de los productos terminados previamente registrados y verificar

que se guarden los campos modificados
Código: PA_01 Historia de Usuario: HU_21 Modificar productos terminados
Nombre: Modificar los datos de los productos terminados previamente registrada y verificar
que se guarden los campos modificados
Condiciones de Ejecución: Debe existir materia prima registrada en la base de datos

Sistema LULY SaaS
Página 94
MANUAL TÉCNICO
• Mostrar los productos terminados
• Presionar sobre el producto que desea modificar
• Modificar los datos requeridos del producto terminado
Historia técnica: HU_21 Modificar productos terminados

Descripción: Como desarrollador deseo realizar la interfaz que me permita modificar los
Código: PA_01_TI_01 Historia de Usuario: HU_21 Modificar productos terminados

Sistema LULY SaaS
Página 95
MANUAL TÉCNICO

navegador
• Iniciar sesión
• En el panel de opciones presionar en productos
• Presionar sobre un producto terminado
de materia prima
Historia técnica: HU_21 Modificar productos terminados

modificar los datos de los productos terminados
Sistema LULY SaaS
Página 96
MANUAL TÉCNICO
Código: PA_01_TI_02 Historia de Usuario: HU_21 Modificar productos terminados

• Modificar un registro de productos terminados
• Guardar
10.8.5 HU_22 Buscar productos terminados
Para poder buscar productos terminados es necesario tener datos registrados, para esto se han
realizado dos tareas de ingeniera una para el acceso a datos que me permite hacer una consulta de
todos los productos terminados existentes en la base de datos, también se ha diseñado la interfaz
de usuarios que permita realizar la búsqueda, cada tarea de ingeniera cuenta con la respectiva
prueba de aceptación como se muestra a continuación:
HISTORIA DE USUARIO
Número: HU_22 Nombre: Buscar productos terminados

Sistema LULY SaaS
Página 97
MANUAL TÉCNICO
Descripción: Como desarrolladores deseamos realizar la funcionalidad para buscar

Observaciones:
• Verificar si existe registro de productos terminados y que se muestre un mensaje de si

existe o no el producto terminado
Código: PA_01 Historia de Usuario: HU_22 Buscar productos terminados
Nombre: Verificar si existe el producto terminado en la base de datos
Descripción: Verificar si existe el proveedor en la base de datos y que se muestre un mensaje

de si existe o no el producto terminado
• Ingresar el nombre o código el producto terminado en la opción de buscar
Resultado esperado: Si el producto terminado existe se listarán los datos, si no existe se

mostrará un mensaje que indique que el producto terminado no existe en la base de datos
Historia técnica: HU_22 Buscar productos terminados

Sistema LULY SaaS
Página 98
MANUAL TÉCNICO
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita buscar
• Verificar si se muestran todos los datos del producto terminado
Código: PA_01_TI_01 Historia de Usuario: HU_22 Buscar productos terminados
Nombre: Verificar si se muestran todos los datos del producto terminado
Descripción: Se requiere verificar que se muestren todos los datos del producto terminado y las
variantes existentes para dicho producto
• Listar los productos terminados
Resultado esperado: Se mostrarán todos los datos correspondientes al producto terminado y
las variantes existentes para dicho producto
Sistema LULY SaaS
Página 99
MANUAL TÉCNICO
Historia técnica: HU_22 Buscar productos terminados

buscar productos terminados
Descripción: Como desarrollador deseo realizar la interfaz que me permita buscar productos
terminados

del producto terminado
Código: PA_01_TI_02 Historia de Usuario: HU_22 Buscar productos terminados
del producto terminado
Descripción: Se requiere verificar que la interfaz muestre el listado de todos los productos
terminados con sus variantes
• Buscar por nombre de producto y categoría de producto terminado
• Verificar los datos mostrados en la interfaz con los de la base de datos
Resultado esperado: Se mostrará la interfaz diseñada correctamente en el navegador con los
datos de las variantes correspondientes al producto terminado
Sistema LULY SaaS
Página 100
MANUAL TÉCNICO
10.8.6 HU_23 Eliminar productos terminados
HISTORIA DE USUARIO
Número: HU_23 Nombre: Eliminar productos terminados


de datos solo se cambiará el estado de dichos productos
• Verificar si se muestra el mensaje de conformación o error de eliminación de materia

prima
Código: PA_01 Historia de Usuario: HU_23 Eliminar productos terminados
Nombre: Verificación de mensaje de conformación de eliminación de productos terminados
Descripción: Verificar el mensaje de confirmación o error de eliminación de productos

terminados, se debe cambiar el estado del producto en la base de datos

Sistema LULY SaaS
Página 101
MANUAL TÉCNICO

• Listar los productos terminados
Resultado esperado: Se mostrará un mensaje que indique que el producto se ha eliminado
correctamente
Historia técnica: HU_23 Eliminar productos terminados

eliminar materia prima
• Verificar que la información se elimine correctamente y se cambie el estado en la base

de datos
Código: PA_01_TI_01 Historia de Usuario: HU_23 Eliminar productos terminados
Nombre: Verificar que la información se elimine correctamente y se cambie el estado en la base

de datos

Sistema LULY SaaS
Página 102
MANUAL TÉCNICO
Descripción: Se requiere verificar si se eliminó la información del producto terminado y sus

variantes
• Eliminar un registro de la variante del producto terminado
correctamente
Historia técnica: HU_23 Eliminar productos terminados

• Verificar que el botón de eliminar se muestre correctamente en el navegador y se muestre

un mensaje de eliminación de producto o de variante
Sistema LULY SaaS
Página 103
MANUAL TÉCNICO
Código: PA_01_TI_02. Historia de Usuario: HU_23 Eliminar productos terminados
Nombre: Verificar que la interfaz se muestre correctamente y se muestre el mensaje de

confirmación
Descripción: Se requiere verificar si se eliminó un producto terminado sin variante o una

variante de producto
• Ir a la opción productos
Resultado esperado: Se mostrará un mensaje si se puede o no eliminar el producto o una
variante
10.9 SPRINT 6
Este esprint se desarrolló las ultimas funcionalidades del sistema enfocadas en la implementación
de los reportes de inventarios mismo que son parte esencial para el cliente ya que se tomo en
cuenta como prioridad de desarrollo, así también de desarrollaron las historias de usuario
correspondiente a la funcionalidad de manejo de estantes.
10.9.1 HU_24 Reporte de proveedores
Los reportes de clientes muestran la información general de cada proveedor registrado en el

sistema, así también se verifica que los datos se muestren correctamente en el reporte. Esta
historia de usuario cuanta con las tareas y pruebas de aceptación correspondientes como se
muestra a continuación:
HISTORIA DE USUARIO
Sistema LULY SaaS
Página 104
MANUAL TÉCNICO
Número: HU_24 Nombre: Reportes de proveedores
Descripción: Como desarrolladores deseamos realizar la funcionalidad para obtener los

reportes de proveedores
Observaciones:
• Verificar los datos del reporte de proveedores
Código: PA_01 Historia de Usuario: HU_24 Reportes de proveedores
Nombre: Verificación de datos del reporte
Descripción: Verificar los datos del reporte de proveedores
• Tener creado el servicio web y la interfaz de usuario
• La funcionalidad para buscar proveedores debe estar realizada

• Presionar en la opción de proveedores
• Buscar proveedor por nombre o ruc
• Presionar en el botón buscar
• Verificar reporte
Resultado esperado: Se mostrará un mensaje que indique que se ha generado el reporte y los
datos corresponderán a los proveedores o proveedor

Sistema LULY SaaS
Página 105
MANUAL TÉCNICO
Historia técnica: HU_24 Reportes de proveedores

obtener el reporte de proveedores
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita generar el
reporte de proveedores
• Verificar que el reporte de proveedores se muestre correctamente en el formato

establecido
Código: PA_01_TI_01 Historia de Usuario: HU_24 Reportes de proveedores
Nombre: Verificar que el reporte de clientes guarde toda la información necesaria del proveedor
Descripción: Se requiere verificar que el reporte de proveedores guarde y muestre la

información necesaria
• Deben existir registros de proveedores
Resultado esperado: Se mostrará el reporte de proveedores en el formato establecido
Sistema LULY SaaS
Página 106
MANUAL TÉCNICO
10.9.2 HU_25 Registro de estantes
Es importante para la empresa tener el registro de estantes ya que permite saber el stock máximo,
mínimo que puede contener cada estante, así como conocer donde se encuentran ubicados los
productos terminados y sean fácil de encontrar, para lo cual se ha realizado dos tareas de
ingeniería con sus respectivas pruebas de aceptación como se muestra a continuación:
HISTORIA DE USUARIO
Número: HU_25 Nombre: Registro de estantes

estantes
Observaciones:
• Verificar si se muestra el mensaje de conformación de registro de estantes
Código: PA_01 Historia de Usuario: HU_25 Registro de estantes
Descripción: Verificar el mensaje de confirmación o error de registro de estantes


• Ir a la opción de estantes
Sistema LULY SaaS
Página 107
MANUAL TÉCNICO
• Presionar en la opción de agregar nuevo estante

• Llenar el formulario de registro de estantes
Resultado esperado: Se mostrará un mensaje que indique que el registro de estantes fue
exitoso
Historia técnica: HU_25 Registro de estantes

registro de estantes
estantes
Código: PA_01_TI_01 Historia de Usuario: HU_25 Registro de estantes
Descripción: Se requiere verificar si se guardó la información del registro de estantes en la base

de datos
Sistema LULY SaaS
Página 108
MANUAL TÉCNICO

• Llenar el formulario de registro de estantes
Historia técnica: HU_25 Registro de estantes

registro de estantes
de estantes para almacenar productos
Código: PA_01_TI_02 Historia de Usuario: HU_25 Registro de estantes

navegador
Sistema LULY SaaS
Página 109
MANUAL TÉCNICO
• Agregar nuevo producto estante
Resultado esperado: Se mostrará correctamente el formulario de registro de estantes en el
navegador y se mostrará el mensaje de datos ingresados correctamente
10.9.3 HU_26 Modificar estantes
Para cumplir con la funcionalidad que permite modificar estantes se desarrolló dos tareas de
ingeniería una para el acceso a datos y otra para diseñar la interfaz, cada tarea de ingeniería cuanta
con las respectivas pruebas de aceptación.
HISTORIA DE USUARIO
Número: HU_26 Nombre: Modificar estantes

modificar los estantes
Observaciones:
• Modificar los datos de los estantes previamente registrados y verificar que se guarden
Sistema LULY SaaS
Página 110
MANUAL TÉCNICO
Código: PA_01 Historia de Usuario: HU_26 Modificar estantes
Nombre: Modificar los datos de los estantes previamente registrada y verificar que se guarden
Condiciones de Ejecución: Debe existir estantes registrados en la base de datos

• Ir la opción de estantes
• Mostrar los estantes
• Modificar un registro de estantes
Historia técnica: HU_26 Modificar estantes

estantes
Descripción: Como desarrollador deseo realizar la interfaz que me permita modificar estantes

Sistema LULY SaaS
Página 111
MANUAL TÉCNICO
Código: PA_01_TI_01 Historia de Usuario: HU_26 Modificar estantes

navegador
• Iniciar sesión
• En el panel de opciones presionar estantes
• Listar los estante s
de los estantes
Historia técnica: HU_26 Modificar estantes

modificar los estantes

Sistema LULY SaaS
Página 112
MANUAL TÉCNICO
estantes
Código: PA_01_TI_02 Historia de Usuario: HU_26 Modificar estantes
Descripción: Se requiere verificar que los datos modificados se actualicen en la base de datos
• Mostrar la materia los estantes
10.9.4 HU_27 Buscar estantes
Para poder hacer una búsqueda de estantes es necesario tener datos registrados, para esto se han
realizado dos tareas de ingeniera una para el acceso a datos que me permite hacer una consulta de
todos los estantes existentes en la base de datos, también se ha diseñado la interfaz de usuarios
que permita realizar la búsqueda, cada tarea de ingeniera cuenta con la respectiva prueba de
aceptación como se muestra a continuación:
HISTORIA DE USUARIO
Sistema LULY SaaS
Página 113
MANUAL TÉCNICO
Número: HU_27 Nombre: Buscar estantes
Descripción: Como desarrolladores deseamos realizar la funcionalidad para buscar estantes
Observaciones:
• Verificar si existe registros de estantes en la base de datos
Código: PA_01 Historia de Usuario: HU_27 Buscar estantes
Nombre: Verificar si existe registros de estantes en la base de datos
Descripción: Verificar si existe registros de estantes en la base de datos y que se muestre un

mensaje de si existe o no el estante
• Ingresar el código o nombre del estante
Resultado esperado: Si el estante existe se listarán los datos, si no existe se mostrará un

mensaje que indique que el estante no existe en la base de datos
Sistema LULY SaaS
Página 114
MANUAL TÉCNICO
Historia técnica: HU_27 Buscar estantes
estantes
Descripción: Como desarrollador deseo realizar el acceso a datos que me permita buscar estantes
• Verificar si el estante está disponible
Código: PA_01_TI_01 Historia de Usuario: HU_27 Buscar estantes
Nombre: Verificar si el estante está disponible
Descripción: Se requiere verificar si el estante está disponible
• Buscar por código o nombre del estante
Resultado esperado: Se mostrarán el estado del estante que indique la disponibilidad

Sistema LULY SaaS
Página 115
MANUAL TÉCNICO
Historia técnica: HU_27 Buscar estantes

buscar estantes
Descripción: Como desarrollador deseo realizar la interfaz que me permita buscar estantes
• Verificar que la interfaz se muestre correctamente en el navegador y se liste el estado de

los estantes
Código: PA_01_TI_02 Historia de Usuario: HU_27 Buscar estantes
Nombre: Verificar que la interfaz se muestre correctamente en el navegador y se liste el estado

de los estantes
Descripción: Se requiere verificar que la interfaz muestre los datos correspondientes a los
estantes y se muestre la disponibilidad de cada estante
• Deben existir registros de estantes
Sistema LULY SaaS
Página 116
MANUAL TÉCNICO
Resultado esperado: Se mostrará en la interfaz todos los datos correspondientes a los estantes
y el estado de cada uno de estos que puede ser disponible y no disponible
10.9.5 HU_28 Eliminar estantes
HISTORIA DE USUARIO
Número: HU_28 Nombre: Eliminar estantes

estantes

de datos solo se cambiará el estado de los estantes
• Verificar si se muestra el mensaje de conformación o error de eliminación de estantes
Código: PA_01 Historia de Usuario: HU_28 Eliminar estantes
Nombre: Verificación de mensaje de conformación de eliminación de estantes
Descripción: Verificar el mensaje de confirmación o error de eliminación de estantes

Sistema LULY SaaS
Página 117
MANUAL TÉCNICO

• Listar los estantes
Resultado esperado: Se mostrará un mensaje que indique que el estante se eliminó con éxito
Historia técnica: HU_28 Eliminar estantes

estantes
estantes
• Verificar que la información se elimine correctamente y se cambie el estado del estante
Código: PA_01_TI_01 Historia de Usuario: HU_28 Eliminar estantes
Nombre: Verificar que la información se elimine correctamente y se cambie el estado del estante
Descripción: Se requiere verificar si se eliminó la información del estante y se cambie el estado

en la base de datos
Sistema LULY SaaS
Página 118
MANUAL TÉCNICO

• Mostrar los estantes
correctamente y se cambie el estado del estante en la base de datos
Historia técnica: HU_28 Eliminar estantes

estantes
estantes
• Verificar que el botón de eliminar se muestre correctamente en el navegador
Código: PA_01_TI_02. Historia de Usuario: HU_28 Eliminar estantes
Descripción: Se requiere verificar si se eliminó el estante de la interfaz y en la base de datos se

cambió el estado de dicho registro
Sistema LULY SaaS
Página 119
MANUAL TÉCNICO
• Tener registro de estante
• Ir a la opción estantes
• Listar los registros de los estantes
• Esperar respuesta y verificar el estado del registro eliminado en la base de datos
Resultado esperado: Se mostrar el botón de eliminar y se borrará el registro de la interfaz, en
la base de datos se cambiará el estado del estante eliminado
10.9.6 HU_29 Reportes de inventarios materia prima
Los reportes de inventarios de materia prima muestran la información general de cada materia
prima registrada en el sistema, así también se verifica que los datos se muestren correctamente en
el reporte. Esta historia de usuario cuanta con las tareas y pruebas de aceptación correspondientes
como se muestra a continuación:
HISTORIA DE USUARIO
Número: HU_29 Nombre: Reportes de inventarios materia prima

reportes de materia prima en formato pdf
Observaciones:
Sistema LULY SaaS
Página 120
MANUAL TÉCNICO
• Verificar los datos del reporte de inventario de materia prima
Código: PA_01 Historia de Usuario: HU_29 Reportes de inventarios materia

prima
Nombre: Verificación de datos del reporte en pdf
Descripción: Verificar los datos del reporte en pdf de materia prima
• La funcionalidad para buscar materia prima debe estar realizada

• Presionar en la opción de productos
• Buscar materia prima por categoría
• Presionar en el botón imprimir
• Guardar el reporte en formato pdf
Resultado esperado: Se mostrará un mensaje que indique que se ha generado el reporte pdf y
los datos corresponderán a la materia prima
Historia técnica: HU_28 Reportes de inventarios materia prima

obtener el reporte de inventario de materia prima

Sistema LULY SaaS
Página 121
MANUAL TÉCNICO
reporte de materia prima en formato pdf
• Verificar que el reporte de materia prima se guarde en formato .pdf
Código: PA_01_TI_01 Historia de Usuario: HU_29 Reportes de inventarios materia

prima
Nombre: Verificar que el reporte de materia prima se guarde en formato .pdf
Descripción: Se requiere verificar que el reporte de materia prima se guarde en formato .pdf
• Deben existir registros de materia prima
• Guardar reporte
• Verificar extensión del archivo
Resultado esperado: Se mostrará el reporte con la extensión .pdf
10.9.7 HU_30 Reportes de inventarios productos terminados
Los reportes de inventarios de productos terminados muestran la información general de cada

producto terminado registrado en el sistema, así también se verifica que los datos se muestren
correctamente en el reporte. Esta historia de usuario cuanta con las tareas y pruebas de aceptación
correspondientes como se muestra a continuación:
Sistema LULY SaaS
Página 122
MANUAL TÉCNICO
HISTORIA DE USUARIO
Nombre: Reportes de inventarios productos

Número: HU_30
terminados

reportes de inventarios productos terminados en formato pdf
Observaciones:
• Verificar los datos del reporte de inventarios productos terminados
Código: PA_01 Historia de Usuario: HU_30 Reportes de inventarios

Nombre: Verificación de datos del reporte en pdf
Descripción: Verificar los datos del reporte en pdf de productos terminados
• La funcionalidad para buscar productos terminados debe estar realizada

• Presionar en la opción de productos
• Buscar productos terminados por categoría
• Presionar en el botón imprimir
• Guardar el reporte en formato pdf
Sistema LULY SaaS
Página 123
MANUAL TÉCNICO
Resultado esperado: Se mostrará un mensaje que indique que se ha generado el reporte pdf y
los datos corresponderán a los productos terminados
Historia técnica: HU_30 Reportes de inventarios productos terminados

obtener el reporte de inventario de productos terminados
reporte de materia prima en formato pdf
• Verificar que el reporte de productos terminados se guarde en formato .pdf
Código: PA_01_TI_01 Historia de Usuario: HU_30 Reportes de inventarios

Nombre: Verificar que el reporte de productos terminados se guarde en formato .pdf
Descripción: Se requiere verificar que el reporte de productos terminados se guarde en formato

.pdf
• Deben existir registros de productos terminados
Sistema LULY SaaS
Página 124
MANUAL TÉCNICO
• Guardar reporte
• Verificar extensión del archivo
Resultado esperado: Se mostrará el reporte con la extensión .pdf
10.9.8 HU_31 Reportes de clientes
Los reportes de clientes muestran la información general de cada cliente registrado en el sistema,
así también se verifica que los datos se muestren correctamente en el reporte. Esta historia de
usuario cuanta con las tareas y pruebas de aceptación correspondientes como se muestra a
continuación:
HISTORIA DE USUARIO
Número: HU_31 Nombre: Reportes de clientes

reportes de clientes
Observaciones:
• Verificar los datos del reporte de clientes
Código: PA_01 Historia de Usuario: HU_31 Reportes de clientes
Nombre: Verificación de datos del reporte

Sistema LULY SaaS
Página 125
MANUAL TÉCNICO
Descripción: Verificar los datos del reporte de clientes
• La funcionalidad para buscar clientes debe estar realizada

• Presionar en la opción de clientes
• Buscar cliente por nombre o cédula
• Presionar en el botón buscar
Resultado esperado: Se mostrará un mensaje que indique que se ha generado el reporte y los
datos corresponderán a los clientes o cliente
Historia técnica: HU_31 Reportes de clientes

obtener el reporte de clientes
reporte de clientes
• Verificar que el reporte de clientes se muestre correctamente en el formato establecido
Código: PA_01_TI_01 Historia de Usuario: HU_31 Reportes de clientes

Sistema LULY SaaS
Página 126
MANUAL TÉCNICO
Nombre: Verificar que el reporte de clientes guarde toda la información necesaria del cliente
Descripción: Se requiere verificar que el reporte de clientes guarde y muestre la información

necesaria
• Deben existir registros de clientes
Resultado esperado: Se mostrará el reporte de clientes en el formato establecido
10.10 SPRINT 7
En este sprint se detallan las pruebas que se realizaron al sistema es importante realizar dichas
pruebas ya que esto permite determinar errores en las funcionalidades y de ser el caso que existan
errores se puede dar solución a dichos errores antes de dar por finalizado el desarrollo del proyecto
10.10.1 HU_32 Pruebas del sistema
Para el desarrollo de las pruebas del sistema partimos con la verificación del cumplimiento de la
interfaz de usuario, seguido de conexión entre los módulos así también se verifica que los datos
se guarden correctamente de la base de datos correspondiente en cada módulo.
HISTORIA DE USUARIO
Número: HU_32 Nombre: Pruebas del sistema
Descripción: Como desarrolladores deseamos realizar las pruebas del sistema desarrollado
Sistema LULY SaaS
Página 127
MANUAL TÉCNICO
Observaciones:
• Verificar si la interfaz de usuarios cumple con los requerimientos del usuario

• Verificar si existe conexión en el módulo SaaS
• Verificar si existe conexión con el módulo de inventarios
• Verificar si el servicio local esta funcional
• Verificar si la API está operativa
• Verificar que la base de datos almacene toda la información ingresada
Código: PA_01 Historia de Usuario: HU_32 Pruebas del sistema
Nombre: Verificar si la interfaz de usuario cumple con los requerimientos del usuario
Descripción: Verificar que la interfaz de usuario cumpla con los requerimientos y bosquejos
planteados por el usuario
Condiciones de Ejecución: La interfaz de usuario debe estar diseñada

• Ir a la cada una de las funciones
• Verificar interfaz de cada función
• Verificar requerimientos y bosquejos
Resultado esperado: La interfaz desarrollada cumple con los requerimientos del usuario
Nombre: Verificar si existe conexión en el módulo SaaS

Sistema LULY SaaS
Página 128
MANUAL TÉCNICO
Descripción: Verificar si se establece conexión con el módulo SaaS que permite la contratación
de suscripciones y de más funciones
• La interfaz de usuario debe estar desarrollada
• La API debe estar desarrollada y operativa
• El servidor local debe estar levantado
• Cargar el sistema en el navegador

• Ingresar o registrarse al sistema en el módulo SaaS
• Verificar las funciones de contratación de suscripción
Resultado esperado: Se visualizará en el navegador el sistema web de inventarios LULY
SaaS, se podrán realizar la contratación de suscripciones, el registro de usuarios y demás
funciones correspondientes al módulo
Nombre: Verificar si existe conexión con el módulo de inventarios
Descripción: Verificar que haya conexión al módulo de inventarios, se debe cargar el sistema
completo y deben estar funcionales todos los procesos de inventarios
• La interfaz de usuario debe estar desarrollada
• Los métodos para la gestión de inventarios deben estar desarrollados
• La base de datos debe estar funcional

• Verificar cada una de las funciones correspondientes al módulo de gestión de
inventarios
Sistema LULY SaaS
Página 129
MANUAL TÉCNICO
Resultado esperado: Se obtiene conexión con el módulo de gestión de inventarios y todas las
funcionalidades están operativas
Nombre: Verificar si el servicio local esta funcional
Descripción: Verificar que el servidor local este levantado y no tenga errores
• Tener todos los servicios activos y funcionales
• Ingresar la dirección IP y el puerto en cualquier navegador

• Verificar si el sistema se carga en el navegador
Resultado esperado: El sistema se muestra correctamente en el navegador
Nombre: Verificar si la API está operativa
Descripción: Verificar que los servicios de la API estén funcionales y sin errores
• Tener creados todos los servicios correspondientes al módulo SaaS y de inventarios
• Tener la base de datos funcional y sin errores
• Ejecutar Postman
• Realizar pruebas de consultas a la base de datos
Sistema LULY SaaS
Página 130
MANUAL TÉCNICO
Resultado esperado: Se tiene conexión con la base de datos mediante las pruebas realizas
Nombre: Verificar que la base de datos almacene toda la información ingresada
Descripción: Verificar que la información ingresada desde la interfaz de usuario de almacene

correctamente en la base de datos
• Tener creada la interfaz de usuario
• Tener los servicios de la API activos
• Tener levantado el sistema completo
• Llenar registros de datos para las funcionalidades del módulo SaaS
• Llenar registros de datos para las funcionalidades del módulo de inventarios
• Ir a la base de datos y verificar las tablas que intervienen en el registro de datos para el
módulo SaaS
• Ir a la base de datos y verificar las tablas que intervienen en el registro de información
correspondiente al módulo de inventarios
Resultado esperado: Toda la información ingresada a través de la interfaz se muestra
correctamente almacenada en la base de datos correspondiente a cada módulo

Sistema LULY SaaS
Página 131
MANUAL TÉCNICO
Bibliografía
LÁZARO, E., "Tipos de notación: Camel Case, Pascal Case, Snake Case y Kebab Case |
Neoguias". [en línea]. 2020. [Consulta:24/2/2021]. Disponible en:
https://www.neoguias.com/tipos-notacion-nombres/.
TUBÍO, J.A., "Estándares de programación y buenas prácticas con Laravel". Styde.net [en línea].
2015. [Consulta:24/2/2021]. Disponible en: https://styde.net/estandares-de-programacion-en-
laravel/.
TOASA CHISAGUANO, B.G., “Desarrollo de un sistema web centralizado de registro, consulta

y obtención de certificados de sacramentos eclesiásticos del Vicariato Apostólico de Méndez
empleando el framework Laravel" . [en línea]. 2019. bachelorThesis. S.l.: Escuela Superior
Politécnica de Chimborazo. [Consulta: 26 enero 2023]. Disponible en:
http://dspace.espoch.edu.ec/handle/123456789/12242.

Escuela Superior Politécnica de Chimborazo

Cargado por

Información del documento

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

Escuela Superior Politécnica de Chimborazo

Cargado por

Copyright:

Formatos disponibles

ESCUELA SUPERIOR POLITÉCNICA DE CHIMBORAZO

FACULTAD DE INFORMÁTICA Y ELECTRÓNICA

Desarrollo de un sistema portable para la gestión de inventarios bajo

TRABAJO DE INTEGRACIÓN CURRICULAR

TIPO: Proyecto Técnico

Presentado para optar el grado académico de:

INGENIERO EN SISTEMAS INFORMÁTICOS

AUTORES: LUCERO MIREYA ULCUANGO ABALCO

ALEX LENIN YAGUACHI YAUCÉN

DIRECTORA: Ing. GLADYS LORENA AGIRRE SAILEMA

Riobamba, día de enero de 2023

Lucero Mireya Ulcuango Abalco Alex Lenin Yaguachi Yaucén

FACULTAD DE INFORMÁTICA Y ELECTRÓNICA

CARRERA DE INGENIERÍA EN SISTEMAS INFORMÁTICOS

Ing. / Dr. Nombres y Apellidos _________________ aa-mm-dd

PRESIDENTE DEL TRIBUNAL

Ing. Gladys Lorena Aguirre Sailema _________________ aa-mm-dd

Ing. Jorge Ariel Menéndez Verdecia _________________ aa-mm-dd

MIEMBRO DEL TRIBUNAL

TABLA DE CONTENIDO ........................................................................................................ vi

ÍNDICE DE TABLAS ................................................................................................................ xi

ÍNDICE DE FIGURAS ............................................................................................................ xiii

ÍNDICE DE GRÁFICOS......................................................................................................... xiv

ÍNDICE DE ANEXOS .............................................................................................................. xv

SUMMARY ............................................................................................................................. xvii

1 DIAGNÓSTICO DEL PROBLEMA....................................................................... 19

1.1 Antecedentes .............................................................................................................. 19

1.4.2 Justificación aplicativa .............................................................................................. 22

1.5 Objetivos .................................................................................................................... 24

1.5.2 Objetivos específicos ................................................................................................... 24

2 REVISIÓN DE LITERATURA ............................................................................... 25

2.1 Estudios previos......................................................................................................... 25

2.3 Software como servicio (SaaS) ................................................................................. 27

2.3.2 Ventajas y desventajas de SaaS ................................................................................. 28

2.3.3 Estrategias de pago para software bajo el modelo SaaS ........................................... 28

2.3.4 Tipos de arquitecturas SAAS ..................................................................................... 29

2.3.4.1 Arquitectura multi-tenant (multiinquilino).................................................................. 29

2.3.4.2 Arquitectura single-tenant (un solo inquilino) ............................................................ 30

2.3.4.3 Beneficios de la arquitectura single- tenant y multi-tenant ........................................ 31

2.4 Gestión de inventarios............................................................................................... 32

2.5 Herramientas de desarrollo del sistema .................................................................. 32

2.5.2 Laravel ........................................................................................................................ 33

2.5.3 PHPStomr ................................................................................................................... 33

2.5.4 MySQL ........................................................................................................................ 33

2.5.5 Framework Angular................................................................................................... 33

2.5.6 Modelado de datos (BPMN) ....................................................................................... 34

2.6 Calidad de software................................................................................................... 34

2.6.1.1 Características de la norma ISO/IEC 25010 .............................................................. 34

2.6.2 Portabilidad ................................................................................................................ 35

2.6.2.1 Web responsive ........................................................................................................... 35

2.6.3 Eficiencia en función del tiempo ............................................................................... 36

2.6.3.1 Métricas para medir eficiencia ................................................................................... 36

3.1 Tipo de investigación................................................................................................. 37

3.4 Proceso de gestión de inventarios de la empresa Industria Textil Paoli´s............ 39

3.5.2 Fase de planificación ................................................................................................. 44

3.5.2.2 Estudio de factibilidad ................................................................................................ 45

3.5.2.3 Riesgos ........................................................................................................................ 46

3.5.2.4 Planificación ............................................................................................................... 48

3.5.3 Fase de desarrollo ...................................................................................................... 50

3.5.3.1 Estándar de programación ......................................................................................... 50

3.5.3.2 Arquitectura del sistema ............................................................................................. 51

3.5.3.3 Interfaz de usuario ...................................................................................................... 51

3.5.3.4 Base de datos .............................................................................................................. 53