Centro Universitario Regional Multidisciplinario de Matagalpa

UNAN MANAGUA - CUR MATAGALPA

Departamento de Ciencias, Educación y Humanidades

Ingeniería en Sistemas de Información 3er Año

Base Orientadora de la Acción 1

Integrantes:
Byron José Guzmán Duarte
Harold Josué Estrada Picado
Nohemí Azucena Campos Espinoza

Docente: Erick Lanzas

05 / Abril / 2025
1 Índice
1 Descripción de Ámbito.............................................................................................................1
1.1 Conceptualización de la descripción de ámbito..............................................................1
1.2 Descripción de las Actividades de los Procesos Realizados en la Farmacia.................1
1.2.1 Facturación...............................................................................................................1
1.2.2 Inventario..................................................................................................................1
1.2.3 Compra y Abastecimiento........................................................................................2
1.2.4 Control de Productos próximos a vencer................................................................2
1.2.5 Reporte y Análisis.....................................................................................................2
1.2.6 Seguridad y Control de Acceso................................................................................3
2 Descripción de la Aplicación....................................................................................................3
2.1 Módulos de la Aplicación:................................................................................................4
3 Proceso de la Fase de Inicio del Proyecto...............................................................................5
3.1 Acta de Constitución........................................................................................................5
3.2 Cronograma de hitos principales....................................................................................9
3.3 Involucrados claves y sus expectativas..........................................................................10
3.3.1 Involucrados............................................................................................................10
3.3.2 Expectativas............................................................................................................11
3.4 Supuestos del proyecto...................................................................................................13
4 Referencias Bibliográficas.....................................................................................................15
5 Anexos.....................................................................................................................................16
5.1 Diseño de arquitectura MVC con Laravel....................................................................16
5.2 Maquetación inicial de aplicaciones web responsivas usando Blade..........................17
5.3 Configuración del archivo .env......................................................................................21
5.4 Configuración del archivo app.php...............................................................................22
5.5 Migración de la database en Laravel............................................................................23
5.6 Planificación de la estructura de rutas, controladores y modelos...............................24
5.6.1 Configuración de las rutas.....................................................................................24
5.6.2 Creación de los controladores y modelos..............................................................25
6 Estudio de estándares de calidad de software:.....................................................................27
6.1 Desarrollar 3 preguntas por cada criterio de calidad según la ISO 9126...................27
6.1.1 Funcionalidad (adaptabilidad, exactitud, interoperabilidad, cumplimiento y
seguridad)...............................................................................................................................27
 6.1.2 Confiabilidad (madurez, tolerancia a fallas y recuperación)..............................28
6.1.3 Usabilidad (entendible, aprensible y operable)....................................................29
6.1.4 Eficiencia (comportamiento del tiempo y de los recursos)...................................30
6.1.5 Facilidad de recibir mantenimiento (analizable, cambiable, estable, susceptible
de someterse a pruebas).........................................................................................................30
6.1.6 Portabilidad (adaptable, instalable, conformidad y sustituible).........................31
6.2 Plan de aseguramiento de la calidad del software (SQA)............................................33
6.2.1 Introducción............................................................................................................33
6.2.2 Objetivo del plan SQA:..........................................................................................33
6.2.3 Alcance del plan SQA:............................................................................................34
6.2.4 Responsabilidades y autoridades...........................................................................35
6.2.5 Estándares y pautas: agregar descripción y la que utilizamos............................36
6.2.6 Estrategias de Aseguramiento de Calidad:...........................................................38
6.2.7 Herramientas por utilizar:.....................................................................................40
6.2.8 Métricas de calidad:...............................................................................................42
6.2.9 Gestión de Incidencias y Control de cambios.......................................................43
6.2.10 Auditorías y revisiones:..........................................................................................44
6.2.11 Plan de Validación..................................................................................................44
6.2.12 Criterios de aceptación:.........................................................................................45
6.2.13 Documentación soporte..........................................................................................46
6.2.14 Revisión y actualización del plan:.........................................................................47
7 Diseño del Esquema de Base de Datos Multidimensional....................................................48
7.1 Modelado de datos tradicional......................................................................................48
7.2 Identificación de dimensiones y medidas......................................................................53
7.3 Modelado de datos multidimensional............................................................................54
8 Estudio de Herramientas de BI para la integración con la Base de Datos.........................56
9 Planificación de la Extracción, Transformación y Carga de datos (ETL).........................59
10 Diseño Inicial de Visualizaciones de Datos...........................................................................64
10.1 Definición de la razón de nuestro análisis mediante preguntas..................................64
10.2 Fuentes principales de datos..........................................................................................66
10.3 Clasificar los datos que te ayudarán a responder la pregunta objetivo......................66
1 Descripción de Ámbito
1.1 Conceptualización de la descripción de ámbito
Según el Project Management Body of Knowledge (PMBOK, 2024), la descripción
de ámbito define los límites y expectativas de un proyecto. Es un marco detallado que
especifica qué incluye y excluye, permitiendo una planificación estructurada y alineada con
los objetivos del negocio.

1.2 Descripción de las Actividades de los Procesos Realizados en la Farmacia

1.2.1 Facturación
Proceso de emisión de facturas a clientes por la venta de medicamentos y otros
productos farmacéuticos.
Actividades principales:

 Registro de venta en el sistema mediante código de barras o código interno del

producto.
 Calculo automático del total de la compra y aplicación de impuestos si aplica.
 Generación y emisión de la factura con los datos del cliente y la venta.
 Registro de la transacción en el sistema de inventario y facturación.

1.2.2 Inventario
Control y gestión de stock de productos farmacéuticos, asegurando la disponibilidad
y actualización en tiempo real.

Actividades principales:

 Registro de entrada y salida de productos en la base de datos.

 Control de inventario en tiempo real con alertas para productos con stock bajo o
próximos a vencer.
 Generación de reportes de productos en existencia, agotados y de alta rotación.
 Clasificación de medicamentos por categoría, laboratorio y acción
farmacológica.

1
1.2.3 Compra y Abastecimiento
Proceso de adquisición de medicamentos y productos relacionados con proveedores
certificados.

Actividades principales:

 Elaboración de proyecciones de pedidos en función del consumo y stock

disponible.
 Coordinación con proveedores para la compra de productos.
 Registro de compras en el sistema e integración con el inventario.
 Control de facturas y pagos a proveedores.

1.2.4 Control de Productos próximos a vencer

Gestión de medicamentos con fecha de caducidad próxima para evitar pérdidas
económicas.
Actividades principales:

 Identificación de productos cercanos a la fecha de vencimiento.

 Aplicación de estrategias de venta para agilizar la rotación (descuentos,
combos).
 Implementación de políticas de devolución con laboratorios y proveedores.

1.2.5 Reporte y Análisis

Generación de informes para evaluar el desempeño del negocio y mejorar la toma
de decisiones.
Actividades principales:

 Reportes de ventas diarias, semanales y mensuales.

 Análisis de productos más vendidos y menos demandados.
 Evaluación de rotación de inventario y control de stock.
 Comparación de datos históricos para identificar tendencias.

2
1.2.6 Seguridad y Control de Acceso
Protección de la información del negocio, garantizando acceso seguro a datos
críticos.
Actividades principales:

 Asignación de permisos según roles (administrador, vendedor).

 Historial de ventas y auditoría de inventario.
 Protección de datos sensibles de clientes y proveedores.

2 Descripción de la Aplicación
La aplicación web para la farmacia es una plataforma integral de gestión diseñada
para optimizar y automatizar los procesos clave del negocio. Esta solución permite una
administración eficiente del inventario, facturación, compras a proveedores y generación de
reportes estratégicos, garantizando un servicio ágil, seguro y preciso tanto para los
empleados como para los clientes.

Características Principales:

 Interfaz intuitiva y amigable: Diseño accesible y fácil de usar para todos los
niveles de usuarios.
 Facturación automática: Generación de facturas con cálculos de impuestos y
descuentos, con opciones de pago en efectivo, tarjeta o crédito.
 Gestión de inventario en tiempo real: Riesgo y control de stock con alertas de
productos agotados o próximos a vencer.
 Administración de compras y proveedores: Registro de pedidos y
actualización automática del inventario.
 Generación de reportes inteligentes: Análisis de ventas, productos más
vendidos, inventario disponible y tendencias de consumo.
 Seguridad y control de accesos: Perfiles de usuario con permisos
diferenciados, asegurando la protección de los datos sensibles.

3
2.1 Módulos de la Aplicación:
 Módulo de Facturación:
1. Registro de ventas con escaneo de códigos de barras o búsqueda manual.
2. Emisión de facturas electrónicas con desglose de impuestos y descuentos
aplicados.
3. Registro de clientes y opción de compras a crédito.
 Módulo de Inventario:
1. Control de stock en tiempo real con alertas de productos en baja
cantidad.
2. Registro de productos con detalles como fecha de vencimiento, lote y
proveedor.
3. Generación automática de pedidos de reposición.
 Módulo de Compras y Proveedores:
1. Registro de pedidos a proveedores y gestión de compras.
2. Control de recepción de productos y actualización automática del
inventario.
3. Historial de transacciones con proveedores.
 Módulo de reportes y Análisis:
1. Informes de ventas diarias, semanales y mensuales.
2. Identificación de productos más vendidos y tendencias de consumo.
3. Reportes financieros y de inventario para toma de decisiones
estratégicas.
 Módulo de Seguridad y Control de Usuarios:
1. Asignación de roles y permisos para empleados.
2. Registro de actividad para auditoría y control de operaciones.
3. Protección de datos sensibles mediante cifrado y medidas de seguridad
avanzadas.

4
3 Proceso de la Fase de Inicio del Proyecto
3.1 Acta de Constitución
1. Información del Proyecto
1.1. Datos
Empresa / Organización Servifarm
Proyecto Sistema de Facturación
Fecha de preparación 18 de marzo de 2025
Cliente Eveling Loasiga
Patrocinador principal Eveling Loasiga
Project Manager Byron José Guzmán Duarte
Fuente: Elaboración propia

1.2. Patrocinador / Patrocinadores

Nombre Cargo
Eveling Loasiga Dueña de la farmacia
Fuente: Elaboración propia

1.3. Justificación
El presente proyecto surge como una respuesta a la necesidad de mejorar la
eficiencia, precisión y control operativo en la gestión de una farmacia, abordando las
principales problemáticas que afectan su funcionamiento diario. Actualmente, muchas
farmacias enfrentan desafíos como errores en el control de inventario, demoras en la
facturación, ausencia de reportes analíticos para la toma de decisiones y dificultades en la
administración de compras y proveedores. Estas deficiencias pueden generar pérdidas
económicas, desabastecimiento de medicamentos y una experiencia insatisfactoria para
los clientes, impactando negativamente la rentabilidad y competitividad del negocio.

Ante este panorama, la implementación de un sistema web de gestión permitirá

automatizar y optimizar procesos clave, reduciendo errores operativos y mejorando la
administración de la farmacia. La digitalización de las tareas diarias proporcionará
herramientas que garantizarán una atención más ágil y precisa para los clientes,
fortaleciendo su fidelización y satisfacción.

Este desarrollo es de gran importancia y utilidad porque ofrece una solución

tecnológica moderna adaptada a las necesidades del sector farmacéutico. La aplicación

5
permitirá a las farmacias gestionar su inventario en tiempo real, mejorar la facturación,
optimizar la relación con proveedores y acceder a reportes analíticos para una mejor
toma de decisiones. Esto se traduce en una operación más eficiente y rentable, con
reducción de desperdicios y mejor control financiero.

Los beneficios esperados incluyen mayor precisión en la gestión del inventario,

reducción de tiempos en la atención al cliente, optimización de recursos y una
administración más efectiva de compras y ventas. El Principal beneficiario será la
propietaria de la farmacia Lic. Eveling Loasiga y vendedores de la farmacia, quienes
podrán gestionar su negocio de manera más eficiente, así como los empleados, al contar
con procesos automatizados que faciliten su labor diaria. Indirectamente, los clientes
también se verán favorecidos, ya que podrán recibir un servicio más rápido, con acceso
garantizado a los productos que necesitan y con menos errores en la facturación.

Este proyecto representa una oportunidad para modernizar la gestión de

farmacias, mejorando su competitividad y asegurando una operación eficiente y
confiable en beneficio tanto de los administradores como de los clientes.
1.4. Descripción del Producto o Servicios
Se desarrollará un sistema web de gestión para farmacia, el cual estará diseñado
como una plataforma integral que optimiza las operaciones diarias del negocio. Este
sistema incluirá funcionalidades clave como facturación, control de inventario,
administración de compras a proveedores y generación de reportes estratégicos,
permitiendo una gestión eficiente, rápida y segura.

El sistema web de facturación y gestión brindará a la farmacia la capacidad de

automatizar procesos críticos, reducir errores humanos, mantener un control actualizado
del stock y agilizar la atención al cliente. Además, facilitará la toma de decisiones basada
en datos gracias a los reportes generados en tiempo real, mejorando así tanto la
productividad interna como la calidad del servicio ofrecido.
1.5. Entregables Finales
El entregable final será un sistema web completamente funcional para la gestión de la farmacia,

6
compuesto por los siguientes elementos:
1. Plataforma web:
1.1. Módulo de facturación
1.2. Módulo de inventario
1.3. Módulo de Compras y proveedores
1.4. Módulo de reportes
1.5. Módulo de seguridad
2. Base de datos optimizada:
2.1. Diseño estructurado con índices para mejorar la velocidad de consultas
2.2. Registro de movimientos históricos de inventario y ventas
2.3. Integración con el módulo de reportes para análisis de datos en tiempo real.
3. Documentación técnica y manual de usuario:
3.1. Documentación del sistema
3.2. Manual de usuario
4. Administración y Pruebas
4.1. Pruebas de funcionalidad
4.2. Pruebas de carga y rendimiento
4.3. Capacitación de los usuarios
1.6. Requerimientos de alto nivel
1. Funcionalidad básica:
Autentificación de Usuarios al iniciar sesión, gestión de inventarios, registro de
clientes, aplicación de descuentos, generación de reportes de ventas.
2. Seguridad y privacidad:
Cifrado de datos, roles y permisos, cumplimiento de regulaciones de protección
de datos personales.
3. Plataforma y tecnologías:
Plataforma web accesible desde navegadores modernos, autenticación con
Laravel.
4. Requerimientos de desempeño:
Tiempo de respuesta de menos de 5 segundos, bajo consumo de recursos (RAM,
CPU).
5. Interfaz de usuario (UI):
Diseño intuitivo, formularios claros, soporte para dispositivos táctiles.

7
Fuente: Elaboración propia

1.7. Objetivos

Objetivo Indicador de éxito

Reducción de errores en la facturación en un
Automatizar la facturación y manejo de
90% dentro de los primeros 3 meses de
inventarios
implementación.

Encriptación de datos y cumplimiento con

Seguridad de los datos
las regulaciones de protección de datos.

Garantizar accesibilidad en múltiples El sistema es accesible desde PC, Chrome,

dispositivos Edge sin problemas.
Los administradores generan reportes de
Ofrecer un sistema de informes y análisis
ventas e inventarios en menos de 5 minutos y
eficientes
con precisión del 98%.
Reducir el tiempo de espera para los El tiempo promedio de espera en una
clientes transacción es menor a 2 minutos.
El sistema soporta un incremento de al
Garantizar escalabilidad del sistema menos 50% en productos o usuarios sin
afectar el rendimiento.
Fuente: Elaboración propia

1.8. Riesgos iniciales de alto nivel

Riesgos Iniciales de Alto Nivel Descripción
Puede provocar cambios frecuentes en el
Falta de claridad en requisitos alcance y retrasos en la entrega del
proyecto.

Incrementa el riesgo de errores y fallos en

Falta de experiencia en el equipo el desarrollo por desconocimiento de
herramientas.
Puede generar malentendidos entre el
Problemas de comunicación equipo y las partes interesadas, afectando el
progreso del proyecto.
Fuente: Elaboración propia

8
3.2 Cronograma de hitos principales

A continuación, se presenta el cronograma de hitos del proyecto, donde se

indican las principales actividades y entregas previstas, junto con sus respectivas
fechas. Este cronograma permite dar seguimiento al avance del proyecto y asegurar el
cumplimiento de los plazos establecidos.

Fuente: Elaboración propia

9
3.3 Involucrados claves y sus expectativas

En todo proyecto es fundamental identificar a las personas o entidades que

tienen interés o participación directa en su desarrollo. A continuación, se describen los
principales involucrados en el proyecto, así como sus expectativas respecto al sistema
de facturación e inventario para la farmacia “Servifarm”. Esta información permite
alinear los objetivos del equipo de trabajo con las necesidades de cada parte interesada.

3.3.1 Involucrados

Fuente: Elaboración propia

10
3.3.2 Expectativas

1. Byron Guzmán (Líder del Proyecto - Equipo de Desarrollo)

Expectativas:

 Tener información clara sobre los procesos y necesidades de la farmacia

para guiar el desarrollo del sistema.
 Asegurar que la aplicación sea estable, escalable y eficiente.
 Implementar mejoras constantes con retroalimentación de los usuarios.
 Integrar el sistema con otras herramientas si es necesario.
2. Equipo de Desarrollo (Byron Guzmán, Harold Estrada y Nohemí Campos)

Expectativas:

 Recibir especificaciones detalladas sobre los requerimientos del sistema.

 Diseñar una plataforma fácil de usar, rápida y sin errores.
 Garantizar que el sistema pueda crecer y adaptarse a futuras necesidades.
 Implementar herramientas para la seguridad de los datos y control de
accesos.
 Asegurar que el código sea limpio, bien documentado y mantenible para
futuras actualizaciones.
3. Eveling Loasiga (Propietaria Gerente - Representante de la Farmacia)

Expectativas:

 Mantener un inventario preciso y actualizado para evitar pérdidas.

 Acceder a reportes detallados de ventas, inventario y productos próximos a
vencer.
 Contar con un historial de transacciones para auditorías y temas fiscales.
 Garantizar la seguridad de la información financiera de la farmacia.
4. Vendedor (Personal Operativo Farmacéutico)

Expectativas:

 Un sistema rápido y fácil de usar para registrar ventas sin complicaciones.

11
  Acceso a la información del inventario en tiempo real.
 Facilidad para aplicar descuentos y manejar promociones sin errores.
 Alertas automáticas sobre productos agotados o próximos a vencer.
 Contar con un sistema ágil que reduzca errores humanos al ingresar datos de
ventas o productos.
 Disponibilidad de funcionalidades que mejoren la experiencia de atención al
cliente, como recomendaciones de productos basadas en historial de
compras.
5. Consultores Externos (Eveling Loasiga - Legal/Fiscal/Seguridad)

Expectativas:

 Cumplimiento con regulaciones legales y fiscales en la facturación y

operaciones.
 Seguridad en la gestión de datos de clientes y proveedores.
 Acceso a registros claros para auditorías y cumplimiento normativo.
6. Proveedores Externos (Laboratorios y Otros Proveedores de la Farmacia)

Expectativas:

 Que el sistema permita a la farmacia gestionar mejor sus pedidos y evitar

faltantes.
 Acceso a registros claros de compras y pagos por parte de la farmacia.
 Que la farmacia pueda prever la demanda de productos, optimizando los
pedidos.
7. Usuario Final (Clientes/Personal Administrativo)

Expectativas:

 Facturación rápida y eficiente, evitando tiempos de espera prolongados.

 Disponibilidad de productos sin faltantes en la farmacia.
 Aplicación correcta de promociones y descuentos en sus compras.
 Atención más ágil gracias a un proceso optimizado.

12
3.4 Supuestos del proyecto
Como equipo encargado del desarrollo del sistema de facturación e inventario
para la farmacia “Servifarm”, hemos identificado una serie de supuestos que
consideramos fundamentales para llevar a cabo el proyecto de manera exitosa. Estos
están relacionados con la disponibilidad de recursos, la participación del personal, la
estabilidad del entorno, la calidad de la información y la colaboración entre los
involucrados.

El cumplimiento de estos supuestos es clave para asegurar que el proyecto

avance según lo previsto. Si alguno no se cumple, podrían surgir retrasos o ajustes
importantes.

A continuación, se detallan los principales supuestos considerados para este

proyecto:

1. Disponibilidad de recursos
 Contamos con las herramientas, tecnologías y conocimientos necesarios para
desarrollar el sistema.
 La farmacia dispone del equipo básico necesario, como computadoras y
conexión a internet, para usar el sistema correctamente.
 Se ha considerado el tiempo suficiente para diseñar, desarrollar, probar e
implementar el sistema según el cronograma.
 Si se necesita algún recurso adicional durante el proyecto, se podrá obtener
sin causar retrasos importantes.
2. Aceptación y uso del sistema
 El personal de la farmacia está dispuesto a usar el nuevo sistema y a
participar en las capacitaciones para aprender a utilizarlo.
 Con la implementación del sistema, se espera mejorar la organización del
inventario y la facturación, reduciendo errores y ahorrando tiempo.
 El sistema podrá usarse desde cualquier dispositivo que tenga acceso a
internet y un navegador actualizado.
13
  Los usuarios del sistema darán su opinión durante las pruebas para ayudar a
hacer mejoras antes de ponerlo en marcha oficialmente.

3. Estabilidad del entorno

 No se esperan cambios importantes en las leyes o normas que puedan afectar
el funcionamiento del sistema durante su desarrollo.
 La farmacia continuará trabajando de forma normal mientras se cambia al
nuevo sistema.
 No se presentarán situaciones externas graves (como cierres, emergencias o
problemas legales) que frenen el avance del proyecto.

4. Disponibilidad de información
 La farmacia entregará a tiempo la información necesaria sobre productos,
precios e historial de ventas para configurar el sistema.
 Los datos proporcionados serán correctos y estarán actualizados, lo cual es
fundamental para que los reportes y funciones del sistema sean confiables.
 Se tendrá acceso a documentos o ejemplos que muestren cómo se realiza
actualmente la facturación y el control de inventario, para que el sistema se adapte bien
a sus necesidades.

5. Colaboración del equipo

 Habrá una comunicación constante y clara entre el equipo de desarrollo y el
personal de la farmacia durante todo el proyecto.
 La farmacia apoyará en las pruebas del sistema, reportando errores o
sugerencias para mejorar su funcionamiento.
 El equipo de desarrollo trabajará de forma organizada para cumplir con los
tiempos establecidos, salvo situaciones imprevistas fuera de su control.
 Todos los participantes del proyecto colaborarán activamente para lograr los
objetivos propuestos.

14
4 Referencias Bibliográficas
Desarrolladorphp. (2025). Comprendiendo la estructura y arquitectura de Laravel. Obtenido de
https://desarrolladorphp.com/blog/comprendiendo-la-estructura-y-arquitectura-de-laravel
Laravel, R. ((s.f.)). Reliese Laravel Model Generator. Obtenido de GitHub:
https://github.com/reliese/laravel
Xethron. (s.f.). Laravel Migrations Generator. Obtenido de GitHub:
https://github.com/Xethron/migrations-generator

15
5 Anexos
5.1 Diseño de arquitectura MVC con Laravel

La arquitectura de Laravel está basada en el patrón MVC (Modelo-Vista-

Controlador). Este patrón se utiliza para separar el código de la aplicación en diferentes
capas. Esta separación permite una mayor flexibilidad y una mejor capacidad de
mantenimiento. (Desarrolladorphp, 2025)

Fuente especificada no válida.

Fuente: Elaboración propia

16
5.2 Maquetación inicial de aplicaciones web responsivas usando Blade
 Interfaz de Login

Fuente: Elaboración propia

17
  Interfaz de Registro de Usuario

Fuente: Elaboración propia

18
  Interfaz de Reestablecer Contraseña

Fuente: Elaboración propia

19
  Interfaz de Dashboard

Fuente: Elaboración propia

 Interfaz de Gestión de Clientes

Fuente: Elaboración propia

20
Configuración inicial del proyecto
5.3 Configuración del archivo .env

21
Fuente: Elaboración propia

5.4 Configuración del archivo app.php

Fuente: Elaboración propia

22
5.5 Migración de la database en Laravel

Con el objetivo de facilitar la gestión y el versionamiento de la base de datos en el

proyecto, se ha utilizado Laravel Migrations Generator. Esta herramienta permite generar
automáticamente los archivos de migraciones a partir de una base de datos existente,
evitando crear las migraciones de forma manual. Su uso garantiza un mejor control de
cambios, facilita la replicación del esquema en diferentes entornos y permite mantener una
base de datos más ordenada y acorde con las buenas prácticas de desarrollo en Laravel.
(Xethron, s.f.)

23
Fuente: Elaboración propia

5.6 Planificación de la estructura de rutas, controladores y modelos

5.6.1 Configuración de las rutas

24
Fuente: Elaboración propia

5.6.2 Creación de los controladores y modelos

 Comando de la creación de los modelos

25
 Para mejorar la productividad y mantener una estructura coherente en el desarrollo
del sistema, se ha optado por utilizar Reliese Laravel Model Generator. Esta herramienta
permite generar automáticamente modelos Eloquent a partir de la estructura de la base de
datos, lo que facilita la sincronización entre el modelo de datos y el código, reduce errores
manuales y agiliza el desarrollo. Su implementación ahorra tiempo y asegura que los
modelos estén siempre actualizados con las relaciones, claves foráneas y otros elementos
definidos en la base de datos. (Laravel, (s.f.))

Fuente: Elaboración propia

 Comando de la creación de los controladores

Para la creación de los controladores del sistema se utilizó Livewire, permitiendo

desarrollar componentes dinámicos que integran la lógica y la interfaz en un mismo

26
archivo. Esto facilitó la gestión de las funcionalidades del sistema, mejorando la
organización del código y agilizando el desarrollo siguiendo las buenas prácticas de
Laravel.

Fuente: Elaboración propia

6 Estudio de estándares de calidad de software:

6.1 Desarrollar 3 preguntas por cada criterio de calidad según la ISO 9126.

27
6.1.1 Funcionalidad (adaptabilidad, exactitud, interoperabilidad, cumplimiento y
seguridad)
 Adaptabilidad:

1. ¿El sistema permite la configuración de parámetros específicos según las necesidades del
negocio para adaptar la gestión de inventarios?

2. ¿La aplicación es capaz de ajustar su interfaz de usuario para diferentes tamaños de

pantalla manteniendo todas sus funcionalidades?

3. ¿Permite el software personalizar los tipos de reportes de ventas según diferentes

criterios de análisis?

 Exactitud:

1. ¿El sistema calcula correctamente los totales, impuestos y descuentos en las facturas
generadas?

2. ¿Los reportes generados reflejan con precisión los datos almacenados en el sistema sin
discrepancias?

3. ¿Las búsquedas y filtros de productos en el inventario devuelven resultados precisos

según los criterios especificados?

 Interoperabilidad:

1. ¿El sistema puede integrarse con plataformas de pago externas para procesar
transacciones?

2. ¿Existe capacidad para intercambiar datos con sistemas de contabilidad externos?

3. ¿El software puede importar y exportar datos en formatos estándar (CSV, XML, JSON)
para facilitar la interacción con otros sistemas?

 Cumplimiento:

1. ¿La aplicación cumple con los estándares de facturación electrónica requeridos por las
autoridades fiscales?

28
2. ¿El sistema implementa las normativas de protección de datos personales aplicables?

3. ¿Se adhiere el software a los estándares de accesibilidad web para garantizar su uso por
personas con discapacidades?

 Seguridad:

1. ¿El sistema implementa mecanismos de autenticación robustos para prevenir accesos no

autorizados?

2. ¿Existe un sistema de roles y permisos que restrinja el acceso a funcionalidades según el

tipo de usuario?

3. ¿Se implementa el cifrado adecuado para la protección de datos sensibles como

información de clientes y transacciones?

6.1.2 Confiabilidad (madurez, tolerancia a fallas y recuperación)

 Madurez:
1. ¿Con qué frecuencia el sistema presenta fallas durante operaciones críticas como la
facturación o gestión de inventario?
2. ¿El software ha pasado por suficientes ciclos de prueba para identificar y corregir la
mayoría de los defectos?
3. ¿Existe un historial documentado de problemas resueltos que demuestre la
evolución y estabilidad del sistema?
 Tolerancia a fallas:
1. ¿Cómo responde el sistema ante interrupciones inesperadas durante una transacción
de venta?
2. ¿El software puede continuar operando en modo degradado cuando algún
componente falla?
3. ¿Existen mecanismos para prevenir la corrupción de datos durante fallos de energía
o caídas del servidor?
 Recuperación:
1. ¿El sistema realiza copias de seguridad automáticas con qué frecuencia y cómo se
gestionan?
29
 2. ¿Cuánto tiempo toma restaurar el sistema a un estado operativo después de un fallo
crítico?
3. ¿Existe un procedimiento documentado para la recuperación de datos en caso de
pérdida?

6.1.3 Usabilidad (entendible, aprensible y operable)

 Entendible:
1. ¿Los mensajes de error proporcionan información clara sobre la causa y posibles
soluciones?
2. ¿La interfaz utiliza terminología familiar para los usuarios del sector retail/ventas?
3. ¿Los elementos visuales (iconos, botones, etiquetas) comunican claramente su
función?
 Aprensible:
1. ¿Cuánto tiempo necesita un nuevo usuario para aprender a realizar tareas básicas
como registrar una venta?
2. ¿El sistema proporciona tutoriales, ayudas contextuales o guías para facilitar el
aprendizaje?
3. ¿La estructura de navegación es consistente a través de todas las secciones del
software?
 Operable:
1. ¿Las funciones críticas son accesibles con un número mínimo de clics o
interacciones?
2. ¿El sistema proporciona atajos de teclado para usuarios avanzados?
3. ¿La aplicación permite cancelar o deshacer acciones potencialmente riesgosas?

6.1.4 Eficiencia (comportamiento del tiempo y de los recursos)

 Comportamiento del tiempo:
1. ¿Cuánto tiempo toma completar un proceso de facturación estándar de principio a
fin?

30
 2. ¿Los reportes se generan en menos de 5 segundos como indica el requerimiento de
desempeño?
3. ¿El tiempo de respuesta del sistema se mantiene constante bajo diferentes cargas de
trabajo?

 Comportamiento de los recursos:

1. ¿Cuál es el consumo de memoria RAM del sistema durante operaciones intensivas
como la generación de reportes?
2. ¿El software utiliza eficientemente los recursos de CPU durante procesos
concurrentes?
3. ¿Cuánto espacio de almacenamiento requiere el sistema para mantener un historial
de transacciones de 1 año?

6.1.5 Facilidad de recibir mantenimiento (analizable, cambiable, estable, susceptible

de someterse a pruebas)
 Analizable:

1. ¿El código fuente está adecuadamente documentado para facilitar su comprensión?

2. ¿Existen registros (logs) detallados que permitan identificar la causa de problemas?

3. ¿La arquitectura del sistema permite aislar componentes específicos para su análisis?

 Cambiable:

1. ¿Es posible modificar la estructura de las facturas sin afectar otras partes del sistema?

2. ¿Cuánto esfuerzo requiere agregar un nuevo método de pago al sistema?

3. ¿El sistema permite actualizar las reglas de negocio (como descuentos o impuestos) sin
necesidad de recompilar el código?

 Estable:

1. ¿Las modificaciones en un módulo específico afectan el funcionamiento de otros

módulos?

31
2. ¿Existen pruebas de regresión automatizadas para verificar que los cambios no
introducen nuevos problemas?

3. ¿El sistema mantiene integridad referencial en la base de datos después de

actualizaciones?

 Susceptible de someterse a pruebas:

1. ¿Los componentes del sistema pueden ser probados de forma independiente?

2. ¿Existen entornos separados (desarrollo, pruebas, producción) para facilitar la

verificación?

3. ¿Es posible simular condiciones de error o casos límite para probar la robustez del
sistema?

6.1.6 Portabilidad (adaptable, instalable, conformidad y sustituible)

 Adaptable:

1. ¿El sistema puede funcionar en diferentes navegadores web (Chrome, Firefox, Edge,
Safari) sin pérdida de funcionalidad?

2. ¿La aplicación se adapta correctamente a diferentes resoluciones de pantalla?

3. ¿Es posible personalizar la apariencia visual (temas, colores, logos) según la identidad
corporativa del cliente?

 Instalable:

1. ¿Cuánto tiempo y esfuerzo requiere el proceso de instalación del sistema?

2. ¿Existen prerrequisitos técnicos documentados para la instalación?

3. ¿El proceso de instalación puede ser automatizado para minimizar errores?

 Conformidad:

1. ¿El sistema cumple con los estándares de portabilidad relevantes para aplicaciones web?

2. ¿La aplicación sigue las convenciones de diseño y desarrollo propias de Laravel?

32
3. ¿Se han implementado las mejores prácticas de portabilidad para garantizar su
funcionamiento en diferentes entornos?

 Sustituible:

1. ¿El sistema puede reemplazar aplicaciones existentes sin pérdida de datos o

funcionalidad?

2. ¿Existen herramientas o procesos para migrar datos desde sistemas anteriores?

3. ¿Es posible la coexistencia temporal con sistemas anteriores durante una transición
gradual?

33
6.2 Plan de aseguramiento de la calidad del software (SQA)

6.2.1 Introducción

El presente documento establece el Plan de Aseguramiento de la Calidad del

Software (SQA) para el sistema de gestión de inventarios y facturación de “ServiFarm”.
Este plan define los procedimientos, metodologías y estándares que se aplicarán durante
todo el ciclo de vida del desarrollo para garantizar que el producto final cumpla con los
requisitos funcionales y no funcionales establecidos, particularmente los estándares de
calidad según la ISO 9126.

Este sistema busca automatizar procesos críticos de facturación e inventario,

proporcionar seguridad en el manejo de datos, garantizar la accesibilidad multiplataforma,
y ofrecer análisis eficientes, todo mientras mantiene un alto desempeño y escalabilidad.

6.2.2 Objetivo del plan SQA:

Establecer y mantener un marco de trabajo para asegurar que el software

desarrollado cumpla con todos los estándares de calidad definidos por ISO 9126, satisfaga
los requerimientos especificados, y sea confiable y eficiente para su implementación en un
entorno de producción real. Los objetivos específicos incluyen:

- Verificar el cumplimiento de los atributos de calidad: funcionalidad, confiabilidad,

usabilidad, eficiencia, mantenibilidad y portabilidad.
- Minimizar los riesgos de desarrollo mediante la detección temprana de defectos.
- Asegurar la consistencia entre los requerimientos y la implementación.
- Garantizar la seguridad y protección de datos según las regulaciones aplicables.
- Facilitar la trazabilidad entre los requerimientos y las pruebas realizadas.

34
6.2.3 Alcance del plan SQA:

Este plan de SQA abarca todas las fases del ciclo de vida del desarrollo del
software, desde la captura de requisitos hasta la implementación y mantenimiento. Aplica a
todos los componentes del sistema, incluyendo:

- Módulo de autenticación de usuarios

Descripción de cómo se llevarán a cabo cada uno de ellos
- Gestión de inventarios
- Registro de clientes
- Sistema de facturación y descuentos
- Generación de reportes
- Interfaces de usuario
- Base de datos y almacenamiento
- Mecanismos de seguridad y cifrado

El plan establecerá los procesos de verificación y validación para cada fase del
proyecto, asegurando que se cumplan los criterios de calidad definidos.

35
6.2.4 Responsabilidades y autoridades

Equipo Rol Responsabilidades

Responsable de la
planificación, coordinación y
Equipo de
Líder de QA supervisión de todas las
Aseguramiento de
(Byron) actividades de aseguramiento
Calidad
de calidad.
Encargados de diseñar casos
de prueba, ejecutar pruebas y
Analistas de QA (Byron, Harold)
documentar resultados.
Responsables de desarrollar y
Automatizadores de (Byron) mantener scripts para pruebas
Pruebas automatizadas.
Asegura que el diseño cumpla
Arquitecto de Software
con los estándares de calidad
Equipo de Desarrollo (Nohemí)
establecidos.
Responsables de implementar
código que cumpla con los
(Byron, Nohemí, estándares definidos y corregir
Desarrolladores
Harold) defectos identificados.
Supervisa la calidad del código
y facilita las revisiones entre
Líder Técnico (Byron, Nohemí)
pares.

Asegura la disponibilidad de
recursos para las actividades
Gerencia del de calidad y toma decisiones
(Byron, Nohemí)
Proyecto sobre cambios significativos.

Verifica que los

requerimientos sean
(Harold) correctamente implementados
Analista de Negocios
y validados.
Participa en las pruebas de
Interesados
aceptación y proporciona
(Stakeholders) Cliente/Usuario Final
retroalimentación.
Especialista en Evalúa y valida los aspectos de
Seguridad (Byron) seguridad del sistema.
Fuente: Elaboración propia

36
6.2.5 Estándares y pautas: agregar descripción y la que utilizamos

Estándares de calidad:

- ISO 9126: Define un modelo de calidad para productos de software

con seis características principales (funcionalidad, confiabilidad, usabilidad,
eficiencia, mantenibilidad y portabilidad) y sus sub características. Proporciona
métricas y métodos de evaluación para cada característica, permitiendo una
evaluación sistemática y objetiva de la calidad del software.
- ISO/IEC 25010: Evolución del ISO 9126, este estándar amplía el
modelo de calidad con ocho características principales (adecuación funcional,
eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad,
mantenibilidad y portabilidad). Incorpora nuevos aspectos como la compatibilidad y
seguridad como características independientes, reflejando la evolución de las
necesidades del software moderno.

- ISO/IEC 27001: Establece los requisitos para un sistema de gestión

de seguridad de la información (SGSI). Define metodologías para identificar,
evaluar y tratar los riesgos de seguridad, implementar controles de seguridad, y
monitorear y mejorar continuamente la protección de datos. Se utilizará para
garantizar la confidencialidad, integridad y disponibilidad de la información en el
sistema.

Estándares de codificación:

- PSR-12 para código PHP: Conjunto de reglas de estilo de

codificación desarrollado por el PHP Framework Interop Group (PHP-FIG). Define
convenciones para nombrado, indentación, declaración de clases/métodos,
espaciado y otros aspectos sintácticos. Su aplicación garantiza consistencia en el
código, facilitando la mantenibilidad y colaboración entre desarrolladores.

37
 - Convenciones de Laravel: Directrices específicas para desarrollar
aplicaciones con el framework Laravel. Incluyen convenciones de nombrado para
controladores, modelos y migraciones, estructura de directorios, uso de Eloquent
ORM, y patrones recomendados. Su seguimiento asegura que el desarrollo
aproveche las mejores prácticas del framework.

- ESLint para JavaScript: Herramienta de análisis estático que

identifica y reporta patrones problemáticos en código JavaScript. Configurable para
aplicar reglas específicas de estilo, detectar errores potenciales y promover buenas
prácticas. Se utilizará con una configuración personalizada que priorice la
legibilidad y mantenibilidad del código.

- Estándares de accesibilidad WCAG 2.1: Directrices de

Accesibilidad para el Contenido Web que establecen cómo hacer el contenido web
más accesible para personas con discapacidades. Organizadas en tres niveles (A,
AA, AAA), estas pautas abordan aspectos como alternativas textuales,
navegabilidad, legibilidad y compatibilidad. Nuestro desarrollo se orientará al
cumplimiento del nivel AA.

Estándares de documentación:

- IEEE 829: Estándar para la documentación de pruebas de software

que define un conjunto completo de documentos para todas las fases del ciclo de
prueba. Incluye plantillas para plan de pruebas, diseño de pruebas, casos de prueba,
procedimientos de prueba, registro de incidencias y reporte de pruebas. Su
aplicación asegura una documentación completa y estructurada del proceso de
pruebas.

- IEEE 830: Establece prácticas recomendadas para la especificación

de requisitos de software (SRS). Define la estructura y contenido de un documento

38
 de requisitos, incluyendo funcionalidad, interfaces externas, requisitos de
rendimiento, atributos de calidad y restricciones de diseño. Seguiremos este
estándar para documentar requisitos de manera clara, completa y verificable.
- ISO/IEC/IEEE 29148: Evolución y unificación de varios estándares
previos, establece procesos y productos relacionados con la ingeniería de requisitos
para sistemas y productos de software. Define procesos para identificar, analizar,
validar y gestionar requisitos, así como la estructura de diferentes tipos de
documentos de especificación. Su aplicación asegura trazabilidad y gestión eficaz
de requisitos durante todo el ciclo de vida.

Pautas específicas del proyecto:

- Manual de estilo para interfaces de usuario.

- Convenciones para nombramiento de bases de datos.
- Directrices para el versionado de código (GitFlow).
- Guía de revisión de código.

6.2.6 Estrategias de Aseguramiento de Calidad:

6.2.6.1 Tipos de Pruebas:

i. Pruebas Unitarias:
- Objetivo: Verificar el correcto funcionamiento de componentes individuales del
código.
- Herramientas: PHPUnit para PHP, Jest para JavaScript.
- Criterio de éxito: 85% mínimo de cobertura de código.
- Frecuencia: Ejecutadas automáticamente con cada integración de código.
- Responsable: Desarrolladores.

ii. Pruebas de Integración:

- Objetivo: Verificar la correcta interacción entre componentes del sistema.

39
- Enfoques: Pruebas de API, pruebas de integración de base de datos, pruebas de
servicios.
- Herramientas: Postman, PHPUnit con TestCase, Laravel HTTP Tests.
- Criterio de éxito: Todas las integraciones críticas deben funcionar correctamente.
- Frecuencia: Después de completar funcionalidades relacionadas.
- Responsable: Desarrolladores y equipo de QA.

iii. Pruebas de Sistemas:

- Objetivo: Verificar que el sistema completo funcione de acuerdo con los requisitos.
- Enfoques: Pruebas funcionales, pruebas de regresión, pruebas de escenarios end-to-
end.
- Herramientas: Selenium, Cypress.
- Criterio de éxito: El sistema debe cumplir con todos los requisitos funcionales y no
funcionales.
- Frecuencia: Al final de cada iteración/sprint y antes de los lanzamientos.
- Responsable: Equipo de QA.

iv. Pruebas de usabilidad:

- Objetivo: Evaluar la facilidad de uso, aprendizaje y operación del sistema.
- Métodos: Sesiones con usuarios, evaluación heurística, recorridos cognitivos.
- Métricas: Tiempo para completar tareas, tasa de éxito, escala de satisfacción SUS.
- Criterio de éxito: Puntuación SUS Mayor de 70, tiempo para completar tareas
críticas menor a 2 minutos.
- Frecuencia: Después de completar interfaces de usuario significativas.
- Responsable: UX/UI Designers y equipo de QA.

v. Pruebas de seguridad:
- Objetivo: Identificar vulnerabilidades y asegurar la protección de datos.
- Tipos: Análisis de código estático, pruebas de penetración, revisión de
configuración.

40
 - Herramientas: SonarQube, PHP Security Checker.
- Criterio de éxito: Sin vulnerabilidades críticas o altas, cifrado adecuado de datos
sensibles.
- Frecuencia: Antes de cada lanzamiento mayor.
- Responsable: Especialista en seguridad y equipo de QA.
vi. Pruebas de rendimiento:
- Objetivo: Verificar el tiempo de respuesta, el uso de recursos y la escalabilidad.
- Tipos: Pruebas de carga, pruebas de estrés, pruebas de estabilidad.
- Herramientas: JMeter, LoadRunner, New Relic.
- Criterio de éxito: Tiempo de respuesta menor de 5 segundos bajo carga normal,
soporte para incremento del 50% en datos sin degradación.
- Frecuencia: Al finalizar módulos críticos y antes del lanzamiento.
- Responsable: Equipo de QA con soporte de DevOps.

6.2.7 Herramientas por utilizar:

 Gestión y Planificación:

En Scroll, la planificación es flexible, con ciclos de desarrollo cortos y entregas

frecuentes, lo que permite una rápida adaptación a los cambios y una mejora continua del
sistema. Para lograr esto, se utilizan herramientas que facilitan la colaboración, la gestión
de tareas y el control de versiones.

- GitLab: Es una plataforma integral que no solo permite el control de versiones con
Git, sino que también ofrece herramientas de integración continua (CI/CD) y
gestión de proyectos. Con GitLab, se pueden gestionar los cambios en el código,
realizar revisiones colaborativas y automatizar despliegues para garantizar que las
actualizaciones se realicen de manera eficiente y sin interrupciones.

- Tower: Se utiliza como cliente gráfico para Git, facilitando el manejo de ramas,
fusiones y revisión de cambios sin necesidad de utilizar la línea de comandos. Esto

41
 es especialmente útil para optimizar el flujo de trabajo, mejorar la colaboración
entre desarrolladores y minimizar errores al gestionar versiones del código.

 Desarrollo y calidad de código:

- Blade (Laravel): Blade es el motor de plantillas nativo de Laravel, el

cual permite separar la lógica del backend del diseño del frontend de manera
eficiente. Su uso optimiza el desarrollo al permitir la reutilización de componentes,
plantillas anidadas y directivas avanzadas que facilitan la integración con la lógica
del sistema.

- PHPUnit: Framework de pruebas unitarias ampliamente utilizado en

proyectos PHP y Laravel. Se emplea para validar la funcionalidad de cada módulo
del sistema, asegurando que los cambios en el código no afecten negativamente
otras partes del sistema. Con PHPUnit, se pueden escribir pruebas automatizadas
para verificar la lógica de negocio y la integración entre componentes.

- PHPStan: Herramienta de análisis estático para PHP que detecta

posibles errores en el código sin necesidad de ejecutarlo. Esto ayuda a mantener una
base de código robusta y sin errores inesperados, mejorando la estabilidad del
sistema.

 Gestión de Base de Datos:

En Scroll, la gestión de datos es fundamental para garantizar la consistencia y el
rendimiento del sistema. Se emplean herramientas que facilitan la administración de bases
de datos relacionales y optimizan las consultas.

42
 - MySQL/MariaDB: Estos sistemas de bases de datos son los más utilizados con
Laravel, ya que proporcionan un alto rendimiento y escalabilidad. Se utilizan para
almacenar, gestionar y consultar grandes volúmenes de datos de manera eficiente.
Laravel permite interactuar con estas bases de datos a través de migraciones y
consultas optimizadas.
 Pruebas automatizadas:
- Postman/Newman: Pruebas de API.
- Laravel Dusk: Pruebas específicas para Laravel.
 Seguridad: la que usaremos

- PHP Security Checker: Verificación de dependencias.

- SSL Labs: Evaluación de configuración TLS/SSL.

 Monitoreo y análisis:

- New Relic: Monitoreo de rendimiento.

- Sentry: Seguimiento de errores.
- Google Analytics: Análisis de uso.

6.2.8 Métricas de calidad:

Métricas de producto:
- Densidad de defectos: Número de defectos por 400 líneas de código.
- Cobertura de código: Porcentaje de código ejecutado durante pruebas.
- Complejidad ciclomática: Medida de complejidad de los módulos.
- Deuda técnica: Tiempo estimado para resolver problemas técnicos.
- Tiempo de respuesta: Rendimiento del sistema bajo diferentes cargas.

Métricas de proceso:

- Efectividad de eliminación de defectos: % de defectos encontrados antes de

producción.
- Eficiencia de las pruebas: Defectos encontrados por hora de prueba.
- Tiempo medio para corregir defectos: Desde detección hasta resolución.

43
 - Estabilidad de requisitos: Cambios en requisitos a lo largo del tiempo.
- Progreso de pruebas: % de casos de prueba ejecutados vs. Planeados.

Objetivos de calidad medibles

Criterio de
Objetivo Medible Indicador Herramienta
Calidad
Garantizar que todas las
100% de pruebas
funcionalidades clave PHPUnit,
Funcionalidad unitarias exitosas en
estén operativas y sin Laravel Dusk
Laravel.
errores.
Asegurar que el sistema
Tasa de error menor al
pueda operar sin fallos Laravel Log,
Fiabilidad 1% en monitoreo de
críticos durante el 99% Sentry
logs.
del tiempo.
Mejorar la experiencia 90% de usuarios
Pruebas con
del usuario con una completan tareas sin
Usabilidad usuarios,
interfaz intuitiva y asistencia en pruebas
encuestas
accesible. de usuario.
Laravel
Optimizar tiempos de Respuesta del backend
Eficiencia Debugbar,
carga de la aplicación. menor a 200 ms.
Postman
GitHub Issues,
Reducir la cantidad de 80% menos errores
Mantenimiento Laravel
errores en producción. críticos en cada sprint.
Telescope
Garantizar 100% de BrowserStack,
Portabilidad compatibilidad en compatibilidad en Chrome
múltiples dispositivos. pruebas de navegador. DevTools
Fuente: Elaboración propia

6.2.9 Gestión de Incidencias y Control de cambios

 Proceso de gestión de incidencias

1. Detección e informe: Documentación detallada del defecto en Jira.
2. Clasificación y priorización: Basada en impacto y urgencia.

44
 3. Asignación: Al equipo o miembro responsable.
4. Análisis y resolución: Identificación de causa raíz y corrección.
5. Verificación: Pruebas para confirmar la resolución.
6. Cierre: Documentación de la solución y lecciones aprendidas.

 Severidad de defectos
- Crítica: Impide el uso del sistema o compromete datos críticos.
- Alta: Afecta funcionalidad principal sin alternativa viable.
- Media: Afecta funcionalidad con alternativa disponible.
- Baja: Problemas menores que no afectan la funcionalidad principal.
 Control de cambios:
1. Solicitud de cambio: Documentación formal del cambio propuesto.
2. Evaluación de impacto: Análisis de afectación a alcance, tiempo y costo.
3. Aprobación/Rechazo: Por el comité de control de cambios.
4. Implementación: Siguiendo el proceso de desarrollo establecido.
5. Verificación: Pruebas para confirmar el cambio adecuado.
6. Actualización de documentación: Incluyendo trazabilidad de requisitos.

6.2.10 Auditorías y revisiones:

 Revisiones técnicas
- Revisión de arquitectura: Al inicio del proyecto y ante cambios significativos.
- Revisiones de código: Mediante pull requests antes de cada integración.
- Revisión de diseño: Para interfaces críticas y componentes principales.
- Revisión de seguridad: Evaluación de código y configuraciones sensibles.

 Auditorías de calidad:
- Auditoría de proceso: Verificación del cumplimiento de procesos definidos.
- Auditoría de estándares: Evaluación de adherencia a estándares técnicos.
- Auditoría de configuración: Verificación de consistencia en entornos.

45
6.2.11 Plan de Validación.

Enfoque de validación:

- Validación continua durante el desarrollo (shift-left testing).

- Validación basada en riesgos para optimizar recursos.
- Validación en entornos que simulen producción.

Actividades de validación:

- Pruebas de aceptación de usuario (UAT): Verificación con usuarios finales.

- Pruebas piloto: Implementación controlada con usuarios seleccionados.
- Validación de cumplimiento normativo: Revisión legal y de conformidad.
- Validación de experiencia de usuario: Evaluación con principios UX.

Calendario de validación:

- UAT: Al final de cada iteración mayor.

- Prueba piloto: Antes del lanzamiento a producción.
- Validación de cumplimiento: Antes de la finalización del producto.
- Validación UX: Después de completar interfaces principales.
-

6.2.12 Criterios de aceptación:

Criterios generales

- Todos los requisitos funcionales implementados y verificados.

- Cumplimiento de los atributos de calidad según ISO 9126.
- Sin defectos críticos o altos abiertos.
- Documentación completa y actualizada.

Criterios específicos

Funcionalidad 100% de las funciones criticas operativas.

46
 Rendimiento Tiempo de respuesta 5 segundos en el 95% de las transacciones.
Usabilidad Puntuación SUS 70, tareas críticas completables en menos de 2 minutos.
Seguridad Sin vulnerabilidades de vulnerabilidad alta o critica.
Mantenibilidad Cobertura de código 85%, Complejidad ciclo matica 15.
Portabilidad Funcionabilidad completa en navegadores Chrome y Edge.
Fuente: Elaboración propia

Procedimiento de aceptación

1. Ejecución de pruebas de aceptación con usuarios clave.

2. Verificación de indicadores de éxito definidos.
3. Reunión formal de revisión con stakeholders.
4. Firma de documento de aceptación.
5. Autorización para implementación en producción.

6.2.13 Documentación soporte

Documentos técnicos:

- Especificación de requisitos de software.

- Documento de arquitectura y diseño.
- Manual técnico y de implementación.
- Diccionario de datos.
- Documentación de API.

Documentos de pruebas:

- Plan de pruebas maestro.

- Especificaciones de diseño de pruebas.
- Casos de prueba y scripts automatizados.
- Informes de ejecución de pruebas.
- Registro de defectos y resoluciones.

Documentos de usuario:

47
 - Manual de usuario.
- Manual de administración.
- Guías de instalación y configuración.
- Material de capacitación.
- Preguntas frecuentes (FAQ).

Plantillas y procedimientos:

- Plantilla de informe de defectos.

- Procedimiento de control de cambios.
- Checklist de revisión de código.
- Procedimiento de implementación.
- Plan de respuesta a incidentes.

6.2.14 Revisión y actualización del plan:

Proceso de revisión:

- Revisión periódica del plan cada 3 meses.

- Revisión extraordinaria ante cambios significativos en el proyecto.
- Registro de cambios al plan con justificación.

Elementos sujetos a revisión:

- Estrategias de prueba.
- Métricas y objetivos de calidad.
- Herramientas y tecnologías.
- Responsabilidades y roles.
- Cronograma de actividades.

Procedimiento de actualización:

1. Identificación de necesidades de cambio.

2. Evaluación de impacto en el proyecto.

48
 3. Aprobación por el líder de QA y gerente de proyecto.
4. Actualización del documento.
5. Comunicación de cambios a los interesados.
6. Implementación de cambios en procesos.

7 Diseño del Esquema de Base de Datos Multidimensional

7.1 Modelado de datos tradicional

Para el modelado físico de la base de datos tradicional del sistema de ServiFarm, se
utilizó Laragon con MariaDB. Se crearon las siguientes tablas principales:

 Tabla Ventas (tabla central)

Fuente: Elaboración propia

 Tabla Detalles Venta

49
Fuente: Elaboración propia

 Tabla Método de Pago

Fuente: Elaboración propia

 Tabla Cliente

Fuente: Elaboración propia

50
  Tabla Tipo Cliente

Fuente: Elaboración propia

 Tabla Inventario

Fuente: Elaboración propia

 Tabla Proveedor

51
Fuente: Elaboración propia

 Tabla Movimiento de Inventario

Fuente: Elaboración propia

 Tabla Producto

52
Fuente: Elaboración propia

 Tabla Precio Producto

Fuente: Elaboración propia

 Tabla Categoría

53
Fuente: Elaboración propia

 Tabla Laboratorio

Fuente: Elaboración propia

 Tabla Usuario

Fuente: Elaboración propia

 Tabla Rol

54
Fuente: Elaboración propia

7.2 Identificación de dimensiones y medidas

Medidas identificadas (Tabla de Hechos):

 Cantidad de productos vendidos

 Total, de ventas
 Precio unitario
 Stock actual
 Subtotal por producto vendido
 Margen de ganancia por producto (calculado a partir del costo y precio venta)

Dimensiones principales:

1. Producto: Para agrupar y comparar ventas por tipo de medicamento, laboratorio, o

categoría (ej. Analgésicos, antibióticos).
2. Cliente: Para analizar el comportamiento de compra según tipo de cliente (ej.
Frecuente, VIP, nuevo).
3. Tiempo: Para estudiar tendencias de venta según mes, estación, día de la semana o
franja horaria.
4. Usuario: Para conocer el rendimiento de los empleados o responsables de venta.
5. Inventario: Para relacionar ventas con disponibilidad de stock y evitar quiebres.
6. Laboratorio: Para conocer qué proveedores o laboratorios tienen más salida.

55
7.3 Modelado de datos multidimensional

El modelo se organizó como un Data Mart de ventas para ServiFarm, con enfoque
en el análisis de ingresos, comportamiento del cliente, y gestión del inventario.

 Evaluar el rendimiento de productos y categorías.

 Medir la eficacia de promociones o campañas para tipos de clientes específicos.
 Controlar niveles de inventario relacionados con la rotación de productos.
 Tomar decisiones sobre compras y abastecimiento basadas en datos históricos.

En el proyecto se usa el esquema de copo de nieve porque normaliza las

dimensiones, reduciendo redundancia y mejorando la eficiencia del almacenamiento. Esto
facilita consultas optimizadas y mantiene la integridad de los datos, permitiendo un análisis
más preciso en herramientas de BI como Power BI.

Esquema de Copo de Nieve Multidimensional

56
Fuente: Elaboración propia

8 Estudio de Herramientas de BI para la integración con la Base de Datos

57
 Power BI
Se escogió power bi desktop como herramienta principal por sus capacidades de:
 Conexión directa a base de datos MySQL
o Power BI Desktop ofrece conectores nativos para bases de datos MySQL
y MariaDB, permitiendo una extracción eficiente de datos sin requerir
procesos intermedios de transformación. Esta integración directa facilita:
 Actualización automatizada de conjuntos de datos mediante
programación refrescos.
 Consultas SQL personalizadas para extraer solo la información
relevante.
 Optimización del rendimiento gracias a la capacidad de aplicar
filtros en el origen.
 Soporte para modelos híbridos, combinando datos locales con
fuentes en las nubes
 Creación de visualización dinámicas, graficas interactivas y KPIs.
o Una de las mayores fortalezas de Power BI es su capacidad para
transformar datos complejos en representaciones visuales intuitivas.
Entre sus ventajas destacan:
 Bibliotecas extensas de gráficos (Barras, líneas, mapas, gráficos
de dispersión, entre otros.)
 Interactividad Cruzada de los elementos visuales que están
interconectados, permitiendo que la selección de un gráfico filtre
automáticamente a los demás.
 Personalización avanzada permitiendo opciones de formato
condicional, paletas de colores adaptables y herramientas de
jerarquía (drill-down).
 KPIs en tiempo real siendo medidores y tarjetas visuales que
monitoreen métricas críticas con actualización dinámica.

 Generación de dashboards para usuarios de negocios.

58
 o Power BI permite diseñar paneles de control (dashboards) altamente
intuitivos, orientados a usuarios no técnicos. Sus beneficios incluyen:
 Interfaz drag-and-drop para armar informes sin necesidad de
programar.
 Sincronización con Power Bi Service lo cual permite compartir
dashboards en la nube con equipos remotos.
 Alertas Automatizadas basadas en umbrelas predefinidos (ej:
ventas bajas por debajo del objetivo).
 Compatibilidad con dispositivos móviles facilitando el acceso
desde smarphones y tablets.

 Facilidad para aplicar filtros por categoría, ubicación, fechas y horarios.

o La capacidad de segmentar datos de manera granular es uno de los
pilares de Power BI. Entre sus aplicaciones destacan:
 Filtros jerárquicos
 Slicers interactivos
 Filtros avanzados por hora
 Persistencia de filtros

 Uso del lenguaje DAX para medidas personalizadas.

o El Data Analysis Expressions (DAX) es un lenguaje avanzado que
amplía las capacidades analíticas de Power BI mediante:
 Cálculos complejos
 Funciones de integración temporal
 Métricas condicionales
 Optimización de modelos de datos

 Integración con Laravel y MariaDB

59
 La base de datos relacional se montó en MariaDB bajo Laragon. Power BI se
conectó directamente a MariaDB mediante el conector MySQL, con los siguientes
parámetros:
 Servidor: localhost
 Base de datos: servifarm
 Usuario: root
 Puerto: 3306

Fuente: Elaboración propia

60
Fuente: Elaboración propia

9 Planificación de la Extracción, Transformación y Carga de datos (ETL)

 Fuentes de datos

En Servifarm, los datos provienen de varias fuentes dentro del sistema de gestión,
como ventas, inventario, clientes y productos, almacenados en una base de datos relacional
MySQL/MariaDB. Las tablas están normalizadas para asegurar que la información esté
organizada de manera eficiente. Las principales fuentes de datos incluyen:

Ventas: Información sobre las transacciones realizadas, como productos vendidos,

cantidades, precios, fecha y cliente.

Inventario: Datos sobre los productos disponibles en la farmacia, sus cantidades y

ubicaciones.

Clientes: Información sobre los clientes que realizan compras.

Productos: Detalles de los productos (ID, nombre, precio de compra y venta).

Proveedores: Información sobre los proveedores de los productos.

61
  Extracción de datos

La extracción de datos se realiza directamente desde Power BI utilizando el

conector MySQL. Con consultas SQL, obtenemos los datos necesarios de las tablas de
ventas, inventario y clientes, o bien podemos importar tablas completas según sea
necesario.

Consultas SQL:

1. Total de ventas por producto en una fecha específica

Esta consulta calcula cuánto se vendió en total por producto (cantidad × precio), agrupado
por producto:

Fuente: Elaboración propia

2. Total vendido por cliente en un rango de fechas

Esta consulta calcula cuánto ha gastado cada cliente en un periodo:

Fuente: Elaboración propia

62
3. obtener las ventas de un día específico:

Fuente: Elaboración propia

 Transformación de datos

Una vez que los datos son extraídos, usamos Power Query en Power BI para
transformarlos y dejarlos listos para el análisis. Las transformaciones clave incluyen:

 Conversión de formatos de fecha: Aseguramos que todas las fechas estén en un

formato estándar para facilitar los análisis de tiempo.
 Separación de la columna “Fecha_Venta”: Si la columna contiene tanto la fecha
como la hora, la dividimos en varias columnas (Año, Mes, Día, Hora) para un
análisis más preciso.
 Unificación de categorías: Agrupamos categorías de productos que se escriben de
manera diferente, pero son iguales, por ejemplo, "Medicamentos" y
"medicamentos", para evitar inconsistencias.
 Cálculo del Total de Venta: Si el total de la venta no está precalculado, lo
calculamos dentro de Power Query multiplicando la cantidad por el precio de venta
de cada producto.
 Eliminación de registros duplicados y nulos: Se eliminan registros con datos
incompletos o duplicados para mantener la calidad de la información.

63
  Carga de datos

Una vez transformados, los datos se cargan en el modelo de Power BI, utilizando
una estructura de modelo estrella para organizar la información en tablas de hechos y
dimensiones.

Tablas de Hechos:

Hecho_Ventas: Contiene los detalles de cada venta, como el ID de la venta, el total de la

venta, la fecha y los productos vendidos.

Hecho_Inventario: Contiene la información sobre los movimientos de inventario

(entradas y salidas) para gestionar el stock de productos.

Hecho_Clientes: Relaciona los clientes con las ventas realizadas y permite generar
reportes sobre la frecuencia de compra de los clientes, ayudando a identificar patrones de
comportamiento.

Tablas de Dimensiones:

Dim_Categoría: Información sobre las categorías de productos (por ejemplo,

medicamentos, cosméticos, etc.).

Dim_Producto: Detalles de los productos, como su ID, nombre, precio y categoría.

Dim_Laboratorio: Información sobre los laboratorios de los productos farmacéuticos.

Dim_Precio_Producto: Detalles sobre los precios de los productos en diferentes períodos.

Dim_Inventario: Información sobre los productos en stock, su cantidad y ubicación.

Dim_Movimiento: Relaciona los movimientos de productos dentro del inventario

(entradas, salidas).

Dim_Proveedor: Información sobre los proveedores de los productos.

Dim_Usuario: Datos de los usuarios del sistema (por ejemplo, empleados que registran las
ventas).

Dim_Rol: Roles de los usuarios (por ejemplo, cajero, administrador).

64
Dim_Cliente: Información sobre los clientes, como su ID, nombre y contacto.

Dim_Tipo_Cliente: Clasificación de los clientes según su tipo, como VIP, frecuente, etc.

Dim_Ventas: Información detallada sobre las transacciones de ventas, facilitando un

análisis más detallado de las mismas.

Relaciones definidas:

Para que los datos se conecten correctamente en Power BI y puedas realizar análisis
completos, definimos relaciones entre las tablas de hechos y dimensiones:

Hechos_Venta.Producto_ID → Dim_Producto.ID_Producto; Relaciona las ventas con

los productos vendidos.

Hechos_Venta.Cliente_ID → Dim_Cliente.ID_Cliente: Permite identificar qué cliente

realizó cada compra.

Hechos_Venta.ID_Fecha → Dim_Tiempo.ID_Fecha: Relaciona las ventas con el tiempo,

útil para analizar por día, mes, año.

Hechos_Venta.ID_Usuario → Dim_Usuario.ID_Usuario; Asocia las ventas con el

usuario que las realizó (empleado, cajero, etc.).

Hechos_Inventario.ID_Inventario → Dim_Inventario.ID_Inventario: Conecta los

hechos de inventario con los detalles específicos del inventario.

Dim_Inventario.ID_Proveedor → Dim_Proveedor.ID_Proveedor: Relaciona el

inventario con el proveedor del producto.

Dim_Producto.ID_Categoria → Dim_Categoria.ID_Categoria: Asocia los productos

con su categoría correspondiente.

Hechos_Cliente.ID_Fecha → Dim_Tiempo.ID_Fecha: Permite calcular la frecuencia de

compra por cliente en el tiempo.

Hechos_Cliente.ID_Cliente → Dim_Cliente.ID_Cliente: Relaciona los hechos de cliente

con su información detallada.

65
Dim_Cliente.ID_Tipo_Cliente → Dim_Tipo_Cliente.ID_Tipo_Cliente: Permite
clasificar a los clientes según su tipo (VIP, frecuente, etc.).

10 Diseño Inicial de Visualizaciones de Datos

10.1 Definición de la razón de nuestro análisis mediante preguntas

1. Preguntas generales sobre patrones y tendencias:

• ¿Qué patrones se pueden identificar en las ventas de medicamentos en la farmacia?
• ¿Cómo varían las ventas de diferentes tipos de productos farmacéuticos?

2. Distribución de los datos:

• ¿Cómo se distribuyen los precios de los medicamentos?
• ¿Cuál es la distribución de las cantidades vendidas por producto?
• ¿Existen productos con ventas extremadamente altas o bajas que puedan
considerarse valores atípicos?

3. Relaciones entre variables:

• ¿Existe correlación entre el precio de los medicamentos y su volumen de ventas?
• ¿Cómo se relacionan las categorías de medicamentos (por ejemplo, medicamentos
de venta libre, recetados, genéricos) con sus ingresos?
• ¿Hay alguna relación entre las temporadas del año y las ventas de ciertos tipos de
medicamentos?

4. Identificación de segmentos y patrones:

• ¿Se pueden identificar grupos de medicamentos con comportamientos de venta
similares?
• ¿Existen patrones de compra diferentes entre tipos de clientes (por ejemplo, clientes
frecuentes vs. ocasionales)?
• ¿Se pueden identificar segmentos de productos más rentables?

66
 5. Calidad de los datos:
• ¿Hay registros de ventas incompletos o con información faltante?
• ¿Existen duplicados en los registros de ventas?
• ¿Cómo se pueden limpiar y preparar los datos para un análisis más preciso?

6. Preparación para modelado predictivo:

• ¿Qué características son más relevantes para predecir las ventas futuras?
• ¿Qué transformaciones de datos podrían mejorar un modelo predictivo de ventas?

7. Tendencias temporales:
• ¿Cómo evolucionan las ventas a lo largo del tiempo?
• ¿Existen patrones estacionales en las ventas de medicamentos?
• ¿Hay épocas del año con mayores ventas de ciertos tipos de medicamentos?

Pregunta específica:

• ¿Cuáles son los factores que influyen en el rendimiento de ventas de medicamentos,

identificando los productos más rentables y los patrones de comportamiento de
compra de los clientes?

67
10.2 Fuentes principales de datos
Fuente (Tabla o Vista) Uso principal
Registro de información personal y de
Clientes
contacto de los clientes.
Control de ventas y transacciones
Facturas
realizadas.
Registro detallado de productos vendidos
DetalleFactura
en cada factura.
Gestión de inventario y precios de
Productos
productos.
Usuarios Control de acceso y seguridad del sistema.
Información de empresas que suministran
Proveedores
productos.
Registro de adquisiciones hechas a
Compras
proveedores.
Información detallada de los productos
DetalleCompra
comprados.
CategoriaProducto Clasificación de productos por categoría.

Fuente: Elaboración propia

10.3 Clasificar los datos que te ayudarán a responder la pregunta objetivo

Variable / Métrica Cómo ayuda Fuente de datos
Permite identificar a los
Total, de ventas por
clientes más activos y Facturas, Detalle_Factura
cliente
rentables.
Ayuda a conocer la
Producto más vendido demanda y planificar el Detalle_Factura, Productos
inventario.
Permite enfocar
Categorías con más Detalle_Factura,
promociones y estrategias
ventas Categoria_Producto
de marketing.
Evalúa la relación
Frecuencia de compras
comercial con los Compras, Proveedores
por proveedor
proveedores.
Ventas por período Analiza tendencias y
Facturas
(mensual/trimestral) estacionalidad en ventas.
Control de stock disponible
Inventario actual Productos
y reposiciones necesarias.
Monitorea el uso del
Usuarios activos Usuarios
sistema y seguridad.
Fuente: Elaboración propia

68