UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

PROYECTO DE GRADO

SISTEMA WEB DE CONTROL DE COMPRAS, VENTAS E

INVENTARIOS
CASO: “COMERCIAL ARIANA”
PARA OPTAR EL TÍTULO DE LICENCIATURA EN INFORMÁTICA
MENCIÓN INGENIERÍA DE SISTEMAS INFORMÁTICOS

POSTULANTE: EYMI ESCARLET CARRILLO CRUZ

TUTOR METODOLÓGICO: [Link]. FRANZ CUEVAS QUIROZ
ASESOR: [Link]. MOISES MARTIN SILVA CHOQUE

LA PAZ – BOLIVIA
Junio, 2017
 UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.

LICENCIA DE USO

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
 Dedicatoria
A Dios, quien es el dueño de mi vida, por fortalecerme en aquellos momentos de desaliento y
debilidad y por engrandecer mi espíritu con cada obstáculo presentado.
A mi mama que confió en mí en todo momento, por sus enseñanzas, cariño y apoyo
incondicional.
 Agradecimiento

 A Dios, por guiarme en este camino que se llama vida, por ponerme obstáculos y por
enseñarme a superarlos siempre.
 A mi mama Lily Cruz, quien fue y es un pilar fundamental en mi vida, que día a día me hizo
mejor persona, por el cariño, por las enseñanzas que me dio, por el sacrificio de brindarme
educación y por velar siempre que nada me falte.
 A mi tutor [Link]. Franz Cuevas Quiroz, por su aporte académico y colaboración constante
para ayudarme a sacar adelante este proyecto.
 A mi asesor [Link]. Moises Martin Silva Choque, por su enseñanza, por su disposición y su
tiempo, por sus valiosos consejos y correcciones que me ayudaron a concluir mi proyecto.
 A los docentes de mi querida carrera, por compartir sus conocimientos y por formarme
para ser un profesional competitivo.
 A todos mis amigos y amigas por brindarme la ayuda y apoyarme en los momentos más
difíciles.
 A la empresa Comercial Ariana por permitirme ejercer mis conocimientos y ponerlos en
práctica, además de la confianza depositada en mi persona.

¡Muchas gracias a todos, los quiero mucho!

 RESUMEN
En la actualidad los sistemas se han convertido en una pieza fundamental y precisa para el
crecimiento y desarrollo de toda empresa ya sea mediana o pequeña. A medida que va
creciendo la empresa, también crece la cantidad de información que administra, por lo tanto,
las empresas requieren tener el control y seguimiento de sus transacciones diarias de forma
que puedan tomar decisiones estratégicas.

Comercial Ariana está ubicada en la ciudad de La Paz y Santa Cruz, donde su sucursal
principal se encuentra en la ciudad de La Paz, ofrece diversos productos de belleza y cuidado
personal de origen Americano, para niños, mujeres y hombres. Así como muchas empresas
fue creciendo a través del tiempo, así mismo fue incrementándose la cantidad de información
que maneja en sus distintas áreas organizacionales, por lo que surgio la necesidad de
automatizar y centralizar la información sobre sus compras ventas e inventarios.

El desarrollo del proyecto se basó en las fases propuestas por la Metodología de Desarrollo
Agil XP (Extreme Programming – Programación Extrema) el cual fue muy útil al momento
de diseñar las funciones y la interfaz del usuario.

Como herramienta de desarrollo de aplicaciones web se utilizó el framework Laravel en su

versión 5.4 complementado con el gestor de base de datos MySQL. Para el diseño responsivo
(adaptable a dispositivos móviles) se utilizó el framework Bootstrap, acompañado de
Javascript, JQuery y PHP.

La calidad del producto de software fue medido bajo la metodología Web-site QEM (Quality
Evaluation Method – Método de Evaluación de Calidad), el cual está basado en las normas
de la ISO 9126.

Por último, se llegó a desarrollar el sistema web de compras ventas e inventarios a un 100%
cumpliendo todos los objetivos y metas planteadas de manera que se produjo un producto de
calidad que en su desempeño cumple con los requerimientos del cliente.
 SUMMARY
Nowadays systems have become a fundamental and precise piece for the growth and
development of any company, whether medium or small. As the company grows, so does the
amount of information it manages, therefore, companies need to have control and tracking of
their daily transactions so that they can make strategic decisions.
Comercial Ariana is located in the city of La Paz and Santa Cruz, where its main branch is
in the city of La Paz, offers various products of beauty and personal care of American origin,
for children, women and men. As many companies grew over time, so too was the amount
of information they handled in their different organizational areas, so the need arose to
automate and centralize information about their purchases, sales and inventories.
The development of the project was based on the phases proposed by the Agil XP (Extreme
Programming) Development Methodology, which was very useful when designing the
functions and user interface.
As a web application development tool, the Laravel framework was used in its version 5.4,
complemented with the MySQL database manager. For the responsive design (adaptable to
mobile devices) we used the Bootstrap framework, accompanied by Javascript, JQuery and
PHP.
The quality of the software product was measured under the methodology Web-site QEM
(Quality Evaluation Method), which is based on the norms of ISO 9126.
Finally, we developed the web system of purchases, sales and inventories to 100%, fulfilling
all the objectives and goals set forth so that a quality product was produced that, in its
performance, meets the customer's requirements.
 i

ÍNDICE PÁGINA
CAPITULO I ............................................................................................................................... 1

MARCO INTRODUCTORIO ..................................................................................................... 1

1.1. Antecedentes......................................................................................................................... 2

1.1.1 Antecedentes internacionales ...................................................................................... 2

1.1.2 Antecedentes nacionales .............................................................................................. 3

1.2 Planteamiento del problema .................................................................................................. 4

1.3 Definición de objetivos.......................................................................................................... 5

1.3.1 Objetivo general .......................................................................................................... 5

1.3.2 Objetivos específicos ................................................................................................... 5

1.4 Justificación ........................................................................................................................... 5

1.5 Alcances y límites.................................................................................................................. 6

1.5.1 Alcances ...................................................................................................................... 6

1.5.2 Límites ......................................................................................................................... 6

CAPITULO II .............................................................................................................................. 8

MARCO TEORICO .................................................................................................................... 8

2.1 Inventario ............................................................................................................................... 8

2.1.1 Clasificación de inventarios ........................................................................................ 9

2.1.2 Costos asociados a los inventarios............................................................................. 10

2.1.3 Modelos de inventario ............................................................................................... 11

2.1.4 Métodos de valuación de inventarios ........................................................................ 12

2.2 Ventas .................................................................................................................................. 13

2.3 Compra u obtención ............................................................................................................ 13

2.4 Almacén ............................................................................................................................... 13

2.4.1 Espacio Físico ............................................................................................................ 14

 ii

2.4.2 Distribución de Almacén ........................................................................................... 14

2.5 La Empresa “Comercial Ariana” ......................................................................................... 16

2.5.1 Situación actual ......................................................................................................... 16

2.5.2 Misión ........................................................................................................................ 18

2.5.3 Visión ........................................................................................................................ 18

2.6 Ingeniería de software ......................................................................................................... 18

2.7 Metodologías de desarrollo ágil .......................................................................................... 19

2.8 Programación extrema (XP) ................................................................................................ 20

2.8.1 Valores de la metodología XP ................................................................................... 20

2.8.2 Roles en XP ............................................................................................................... 20

2.8.3 Ciclo de vida de XP ................................................................................................... 21

2.8.4 Fases de la metodología XP ...................................................................................... 22

2.8.5 Prácticas de la metodología XP ................................................................................. 28

2.9 Metodología de evaluación de calidad de sitios Web (WEB SITE QEM) .......................... 29

2.9.1 Fase de planificación y programación de la evaluación de calidad ........................... 30

2.9.2 Fase de definición y especificación de requerimientos de calidad ............................ 30

2.9.3 Fase de definición e implementación de la evolución elemental .............................. 32

2.9.4 Fase de definición e implementación de la evaluación global .................................. 34

CAPITULO III .......................................................................................................................... 36

MARCO APLICATIVO ........................................................................................................... 36

3.1 Fase de planificación ........................................................................................................... 36

3.1.1 Clasificación e identificación de roles ....................................................................... 36

3.1.2 Obtención de requerimientos ..................................................................................... 37

3.1.3 Historias de usuario ................................................................................................... 40

3.1.4 Plan de entregas del proyecto (Release Planning) ..................................................... 42

 iii

3.2 Fase de diseño...................................................................................................................... 43

3.2.1 Modelo estructural o de datos .................................................................................... 43

3.3 Fase de desarrollo ................................................................................................................ 45

3.3.1 Primera iteración........................................................................................................ 46

3.3.2 Segunda iteración ...................................................................................................... 51

3.3.3 Tercera iteración ........................................................................................................ 57

3.3.4 Cuarta iteración.......................................................................................................... 64

3.4 Calidad ................................................................................................................................. 69

3.4.1 Mediciones elementales ............................................................................................. 69

3.4.2 Evaluación global ...................................................................................................... 73

3.4.3 Conclusión de la evaluación ...................................................................................... 74

3.5 Seguridad ............................................................................................................................. 74

3.5.1 Seguridad por niveles ................................................................................................ 74

CAPÍTULO IV .......................................................................................................................... 77

CONCLUSIONES Y RECOMENDACIONES ........................................................................ 77

4.1Conclusiones......................................................................................................................... 77

4.2 Recomendaciones ................................................................................................................ 78

Referencias Bibliografías .......................................................................................................... 79

 iv

LISTA DE FIGURAS

FIGURA DESCRIPCIÓN PAGINA

Figura 2.1 Clasificación ABC 10
Figura 2.2 Modelo EOQ con faltante 12
Figura 2.3 Ciclos de desarrollo XP 21
Figura 2.4 Fases de la metodología XP 22
Figura 2.5 Proceso de evaluación y comparación 30
Figura 2.6 Tipos de criterio elemental 32
Figura 3.1 Modelo Entidad Relación E-R 43
Figura 3.2 Modelo físico de la Base de Datos 44
Figura 3.3 Diagrama de Clases 45
Figura 3.4 Diagrama de Hipertexto – Categoría 48
Figura 3.5 Diagrama de Hipertexto – Producto 48
Figura 3.6 Diagrama de Hipertexto – Proveedor 49
Figura 3.7 Modelo de Presentación – Categoría 49
Figura 3.8 Modelo de Presentación – Producto 50
Figura 3.9 Modelo de Presentación – Proveedores 50
Figura 3.10 Diagrama de Hipertexto – Compra 54
Figura 3.11 Diagrama de Hipertexto – Devolución de Compra 54
Figura 3.12 Diagrama de Hipertexto – Devolución de Compra 55
Figura 3.13 Modelo de Presentación – Compra 55
Figura 3.14 Modelo de Presentación – Devolución de Compra 56
Figura 3.15 Modelo de Presentación – Crédito Compra 56
Figura 3.16 Diagrama de Hipertexto – Cliente 60
Figura 3.17 Diagrama de Hipertexto – Ventas 60
Figura 3.18 Diagrama de Hipertexto – Crédito Ventas 61
Figura 3.19 Modelo de Presentación – Cliente 61
Figura 3.20 Modelo de Presentación – Venta 62
Figura 3.21 Modelo de Presentación – Devoluciones de Venta
Figura 3.22 Modelo de Presentación – Crédito Venta 63
Figura 3.24 Diagrama de Hipertexto – Sucursal 66
 v

Figura 3.25 Diagrama de Hipertexto – Almacén 66

Figura 3.26 Diagrama de Hipertexto – Distribución de productos 67
Figura 3.27 Diagrama de Hipertexto – Usuario 67
Figura 3.28 Diagrama de Hipertexto – Reporte de Venta 68
Figura 3.29 Modelo de Presentación – Sucursal 68
Figura 3.30 Modelo de Presentación – Almacén 68
Figura 3.31 Modelo de Presentación – Distribución de Productos 69
Figura 3.32 Autenticación de usuarios 74
 vi

LISTA DE TABLAS

TABLA DESCRIPCIÓN PAGINA

Tabla 2.1 Comparación de las metodologías tradicionales y las ágiles 19
Tabla 2.2 Plantilla para las historias de usuario 23
Tabla 2.3 Plantilla para tareas de ingeniería 24
Tabla 2.4 Plantilla para las tarjetas CRC 26
Tabla 2.5 Plantilla para las pruebas de aceptación 28
Tabla 2.6 Rango de medición 35
Tabla3.1 Identificación de roles 36
Tabla 3.2 Historias de Usuario - Administración de Productos 40
Tabla 3.3 Historias de Usuario - Administración Compras 40
Tabla 3.4 Historias de Usuario - Administración de Ventas 41
Tabla 3.5 Historias de Usuario - Distribución de Productos a Sucursales o 41
Almacén
Tabla 3.6 Resumen de Historia de Usuario 41
Tabla 3.7 Primera Iteración - Historias de Usuario 42
Tabla 3.8 Tarea de Ingeniería - Creación de la Base de Datos tabla 46
Producto
Tabla 3.9 Tarea de Ingeniería - Creación del Modelo, Controlador, Ruta y 46
Request Producto
Tabla 3.10 Tarea de Ingeniería - Diseño de la Vista Producto 47
Tabla 3.11 Tarjeta CRC – Producto 47
Tabla 3.12 Prueba de Aceptación – Producto 51
Tabla 3.13 Segunda Iteración - Historias de Usuario 52
Tabla 3.14 Tarea de Ingeniería - Crear de la Base de Datos tabla Compra 52
Tabla 3.15 Tarea de Ingeniería - Creación del Modelo, Controlador, Ruta y 53
Request Compra
Tabla 3.16 Tarea de Ingeniería - Diseño de la Vista Compra 54
Tabla 3.17 Tarjeta CRC – Compra 54
Tabla 3.18 Prueba de Aceptación – Compras 57
Tabla 3.19 Tercera Iteración - Historias de Usuario 58
 vii

Tabla 3.20 Tarea de Ingeniería - Creación de la Base de Datos tabla Venta 58

Tabla 3.21 Tarea de Ingeniería - Creación del Modelo, Controlador, Ruta y 59
Request Venta
Tabla 3.22 Tarea de Ingeniería - Diseño de la Vista Venta 59
Tabla 3.23 Tarjeta CRC – Venta 60
Tabla 3.24 Prueba de Aceptación – Ventas 64
Tabla 3.25 Cuarta Iteración - Historias de Usuario 65
Tabla 3.26 Tarea de Ingeniería - Creación de la Base de Datos tabla 65
Distribución
Tabla 3.27 Tarea de Ingeniería - Creación del Modelo Controlador, Ruta y 66
Request Distribución
Tabla 3.28 Tarea de Ingeniería - Diseño de la Vista Distribución 66
Tabla 3.29 Tarjeta CRC – Distribución 66
Tabla 3.30 Prueba de Aceptación - Distribución de Productos a Sucursales o 70
Almacén
Tabla 3.31 Resultado del criterio usabilidad 71
Tabla 3.32 Resultado del criterio Funcionabilidad 72
Tabla 3.33 Resultado del criterio Eficiencia 73
Tabla 3.34 Resultado Global 74
CAPITULO I

MARCO INTRODUCTORIO

La creciente necesidad de las pequeñas y medianas empresas, por integrarse al mundo de

hoy, con mayor tecnología y mayor competencia frente a sus rivales, hace que la computación
y sus servicios que se pueden obtener con las tecnologías actuales pueden agregar valor a la
empresa. La gran cantidad de información que manejan las entidades, y al ser un recurso vital
crea la necesidad de automatizar no solamente la información, sino también los procesos de
negocio.

Comercial Ariana está ubicada en la ciudad de La Paz y Santa Cruz, donde su sucursal
principal se encuentra en la ciudad de La Paz, ofrece diversos productos de belleza y cuidado
personal de origen Americano, para niños, mujeres y hombres. Así como muchas empresas fue
creciendo a través del tiempo, así mismo fue incrementándose la cantidad de información que
maneja en sus distintas áreas organizacionales.

La administración en sus distintas áreas organizacionales de la Comercial Ariana depende

de herramientas ofimáticas1 comunes para el manejo de la información, estas soluciones no

1
Ofimáticas: conjunto de aplicaciones y herramientas informáticas que se usan en labores de oficina.
 2

cumplen las necesidades en las áreas de compras y ventas de la empresa por lo que se sigue
realizando la transcripción manual.

Por lo anterior expuesto, la Comercial Ariana decidió implementar un sistema Web que
permita manejar y controlar un mayor volumen de compras de mercadería, ventas de inventarios
y almacenamiento de productos, para poder facilitar las labores de los trabajadores
proporcionara un seguimiento preciso de todas las transacciones que se realizan dentro de la
comercial en tiempo real, proporcionando reportes detallados de ventas que permite a los
administradores ordenar fácilmente la cantidad correcta de productos y a su vez mejorar sus
servicios al cliente reduciendo el tiempo necesario para terminar una transacción.

1.1. Antecedentes

1.1.1 Antecedentes internacionales

A nivel comercial, existen programas de compras, ventas e inventarios de pago, podemos

citar los siguientes:

 Sistema Para Farmacias, Sicar: es un software que facilita el trabajo del control de
Inventarios, Importar/Exportar desde Excel, Lotes y Caducidades, Venta de Anti-bióticos,
Gráficas y Comparativas, Etiquetado de Mercancía (para poner precios a los productos),
Tags / Compatibles (buscador para comparar productos similares), Sincroniza Sucursales,
Monedero Electrónico (para acumular y gastar los puntos que obtienen los clientes),
Facturación Electrónica.
 Inventarios, compras, facturación y punto de venta, ContaPyme: es un aplicación web que
ofrece herramientas para hacer seguimiento a los inventarios, incluyendo control de números
seriales en códigos de barras, aplica promociones especiales para la venta de productos,
otorgar crédito a clientes y genera reportes de productos vendidos por semana o periodo,
productos bajos en inventario, reporte de inventario en cantidad y monto.
 Sistemas de control de inventario y ventas, Compubinario: es un software de punto de venta
para productos y servicios, administra los clientes, proveedores y vendedores, Imprime o
envía por correo los comprobantes de pago y cargos, permite las reservas online, administra
las cobranzas y genera reportes.
 3

También existen pequeños programas gratuitos que hacen el registro de productos, control
del stock y estadísticas de los productos más vendidos, como ser:

 Small Business Inventory Control: Este software ofrece herramientas para hacer
seguimiento a los inventarios, incluyendo control de números seriales en códigos de barras.
 Fakturama: Es un software de software libre diseñado para crear ingresos, notas de entrega,
administrar productos, contactos, documentos, pagos y envíos.
 LecProg Stock Managment: Es una aplicación java que facilita el manejo de inventarios,
permitiendo el registro de ítems y clasificándolos en varias categorías.

1.1.2 Antecedentes nacionales

En gestiones pasadas se han realizado sistemas de control de gestión de información de
ventas, compras e inventarios, los cuales fueron desarrollados según las necesidades de
entidades específicas.

Se identificaron los siguientes proyectos en la universidad Boliviana:

 Sistema web de seguimiento de ventas y cobranzas para la agencia de viajes “Cosmos Travel
and Services S.R.L.” Autor: Luis Alfredo Colmena Vargas, Año 2015, Metodología: XP y
WebML, Universidad: UMSA (Universidad Mayor de San Andres). En el proyecto se diseña
y desarrolla un sistema en plataforma web que permite hacer el control y seguimiento de las
ventas y cobranzas de los servicios ofertados por la agencia de viajes Cosmos Travel and
Services S.R.L.
 Sistema de información de ventas para una empresa de motos usando el framework Laravel,
Autor: Limbert Jhonny Peña Trujillo, Año: 2015, Metodología: UML Universidad: UMSS
(Universidad mayor de San Simón). En dicho proyecto se diseña y desarrolla un sistema de
información de ventas para la empresa El Mundo de las Motos desarrollado en el framework
Laravel, con el fin de reducir el esfuerzo humano y el tiempo de una transacción de venta.
 Sistema de gestion de ventas online para empresas Discograficas Nacionales, Autor:
Anthony Patrick Clurg Castro, Año: 2011, Metodologia: UML, Universidad: UCB
(Universidad Católica Boliviana). En dicho proyecto se diseña y desarrolla un sistema en
plataforma web para realizar ventas online dirigido a las empresas discográficas de Bolivia.
 4

1.2 Planteamiento del problema

La información es parte fundamental de toda empresa para tener un alto nivel de

competitividad y posibilidades de desarrollo, al no saber administrar de manera adecuada y
ordenada la información, no se realiza una adecuada toma de decisiones respecto a las finanzas,
compras, ventas y clientes de la empresa.

Basándonos en varias entrevistas realizadas al personal del área de compras, ventas y

almacén; se pudo detectar lo siguiente:

 Los comprobantes de ventas son transcritas manualmente provocando demoras en atención

al cliente y a veces errores al realizar los cálculos o transcribirlos.
 El seguimiento y control de deudas de los clientes conlleva tiempo, lo cual provoca demora
y recelo ante la posible pérdida de los comprobantes físicos de pago.
 La información sobre las compras de mercadería, ventas de productos e inventarios de cada
sucursal no se encuentra centralizada y el acceso a los documentos físicos provoca demoras,
causando consultas retrasadas a los estados financieros de las ventas de mercadería,
generando así mismo riesgos de pérdida de datos.
 El control manual de ingresos y salidas de productos, genera riesgos de pérdida de
información sobre el inventario y los mismos debido a la gran cantidad de productos en
almacenes.
 El retraso en la elaboración de reportes diarios, de cierres mensuales y gerenciales, afecta a
la toma de decisiones para realizar compras a los proveedores y ventas a los mayoristas.
 Los informes de inventarios son llenados con ayuda de una hoja electrónica y su emisión es
tardía e incorrecta, causando pedidos innecesarios y pérdidas de oportunidad de ventas.

Todo esto ocasiona un control inadecuado de esta información perdiendo la facilidad de

gestión, el acceso a la misma y mejoras para la empresa. Por lo tanto el problema a resolver es
el siguiente:

¿Un sistema informático podrá mejorar la gestión de información de los procesos de

compras de mercadería, ventas de productos y control de inventarios de la empresa Comercial
Ariana?
 5

1.3 Definición de objetivos

1.3.1 Objetivo general

Desarrollar un Sistema Web para mejorar la gestión de información de los procesos de

compras de mercadería, ventas de productos y control de inventarios para la empresa Comercial
Ariana.

1.3.2 Objetivos específicos

 Optimizar el tiempo para registrar una venta y terminar una transacción.

 Generar un registro de deudas y cuentas por cobrar para el eficiente control y seguimiento
de las mismas.
 Consolidar y centralizar la información de compras, ventas y el estado de inventarios para
evitar demoras en el acceso.
 Administrar el control de ingresos y salidas de productos a los diferentes almacenes y
sucursales.
 Generar reportes estratégicos a solicitud de la empresa de tipo gerencial para la toma de
decisiones.
 Detallar la disponibilidad de productos en almacenes y sucursales.

1.4 Justificación

El proyecto beneficiará a la empresa Comercial Ariana, permitiendo controlar y manejar

mayores volúmenes de mercadería, logrando un mejor almacenamiento de los productos. Por
otro lado proporcionará un seguimiento preciso de todas las transacciones que se realizan dentro
de la empresa en tiempo real, proporcionando reportes detallados de ventas que permite a los
administradores ordenar fácilmente la cantidad correcta de productos en el momento adecuado
y a la empresa mejorar sus servicios al cliente reduciendo el tiempo necesario para terminar una
transacción logrando así el incremento de los beneficios económicos de la empresa y facilitando
las labores de los trabajadores enfocándose solamente al servicio prestado.

Comercial Ariana cuenta con las herramientas tecnológicas necesarias para la

implementación del sistema Web. Permitiéndose la integración del seguimiento de la
información de sucursales.
 6

El desarrollo del sistema Web no tendrá costo, ya que se emplearán herramientas de

software libre y código abierto, aprovechando estos recursos para tener un software de calidad.

1.5 Alcances y límites

El sistema a desarrollar brindará información de manera rápida y confiable. También será

flexible en cuanto a su manejo, adaptándose con facilidad a las expectativas del personal de la
empresa.

1.5.1 Alcances

El sistema tiene los siguientes alcances:

 Modulo Sucursal y Almacén: Registro, actualización, consulta y baja de una sucursal,

registro, actualización, consulta y baja de un almacén correspondiente a cada sucursal,
además se debe hacer el seguimiento de mercadería por sucursal o almacén.
 Modulo Producto: Registro, actualización, consulta y baja de un producto, cada producto
debe tener una imagen de referencia y debe pertenecer a una categoría. Registrar, actualizar,
consultar y baja de categoría.
 Módulo de distribución del material, Registro y reportes referentes al movimiento en los
almacenes.
 Módulo gestión de usuarios con sus respectivos roles.
 Modulo compras: registro de compras, devolución de compras, baja de una compra, detalles
de cada compra, consulta de todas las compras, control de stock, registro, actualización,
consulta y eliminación de un proveedor.
 Modulo Ventas: registro de ventas, devolución de ventas, baja de una venta, detalles de cada
venta, consulta de todas las ventas, registro, actualización, consulta y eliminación de un
cliente, comprobante de venta y reportes.
 Módulo de seguimiento de deudas a los clientes y a los proveedores, registró, consulta y
detalles de pago.

1.5.2 Límites

El sistema se limita a las siguientes condiciones:

 El sistema será utilizado únicamente por el personal de la Comercial Ariana.

 7

 Algunas funciones estarán restringidas por el personal autorizado debido a los roles de
acceso.
 El sistema no realizara el control del personal de trabajo.
 El sistema no incluirá un módulo de facturación.
 8

CAPITULO II

MARCO TEORICO

2.1 Inventario

Inventario se refiere a las existencias de un artículo o determinado recurso que está

almacenado y que espera ser usado por la organización. Un sistema de inventario es el conjunto
de políticas y controles que supervisa los niveles de inventario y determina cuáles son los niveles
que deben mantenerse, cuando hay que reabastecer el inventario y de qué tamaño deben ser los
pedidos. (Mongua & Sandoval, 2009)

En el ámbito comercial, el inventario se representa en un esquema de ventas donde se

registran las operaciones que se producen desde que el cliente efectúa un pedido a las
instalaciones hasta que se realiza su entrega:

- Se produce el pedido de uno o varios productos a instalaciones

- Se verifica el pedido en las instalaciones, caso contrario de no existir, se pide
autorización para buscar en almacén
- Se acepta el pedido
- Se procesa la cancelación de dicho pedido
- Se recepciona el pedido por parte del cliente
 9

En el esquema de aprovisionamiento, se realizan las siguientes operaciones que nos

permitirán abastecernos de material de ventas:

- Al notar la falta de algún producto se solicita el abastecimiento al proveedor

- Se recepciona el pedido y se realiza el envío a los centros de venta y almacén
- Se contabiliza la cantidad que ingresó

Comercial Ariana cuenta con un inventario elaborado de manera manual donde se registra
el ingreso y egreso de productos en su almacén, el cual se actualiza con una periodicidad
mensual.

2.1.1 Clasificación de inventarios

La clasificación es una de las mejores medidas de control interno de inventarios, ya que

correctamente aplicada, permitirá mantener el mínimo de capital invertido en stock, entre otros
muchos beneficios.

La clasificación ABC es una metodología de diferenciación de productos de acuerdo a

criterios de importancia, tales como el ‘’costo unitario” y el “volumen anual demandado”.

Los artículos que correspondan a la Zona A son aquellos que requerirán el más alto grado
posible de control. Esta zona corresponde a los ítems que representan una parte importante del
valor total del inventario. Se necesita un suministro constante y en cantidades que equiparen la
proporción de la demanda en ventas.

Los artículos que se encuentren en la Zona B son aquellos que requerirán ser seguidos y
controlados mediante revisiones periódicas por parte de la administración del negocio.

Los artículos que figuren en la Zona C son aquellos que tienen el mayor número de
unidades en el inventario, lo cual hace necesaria la incorporación de una rutina que facilite su
seguimiento en existencias, bastando una evaluación física por lotes. (Monterroso, 2000)

Se prevé que la clasificación ABC se incorpore a las actividades diarias del comercial
en cuanto el sistema esté implementado, procediéndose con la evaluación de la información
recaudada durante una gestión entera de manera que la clasificación pueda realizarse con la
mayor exactitud posible respecto al movimiento predictivo de los artículos, así como su flujo de
entradas y salidas por temporadas.
 10

Figura 2.1: Clasificación ABC

Fuente: (Casañas, 2001)

2.1.2 Costos asociados a los inventarios

La base común de todo inventario es la representación del valor monetario que representa
y que tiene asociado, de ellos emergen costos asociados (López, 2015) al proceso de sostener
las existencias de un inventario y se diferencian según la naturaleza de la empresa.

Consisten en:

a) Costo del producto

Es la suma que se paga al proveedor por el producto recibido, o costo directo de

manufactura si este se produce. Normalmente es igual al precio de adquisición.

b) Costo de ordenar

Este costo consiste en los recursos financieros relativos al proceso de emitir una orden
de pedido (que puede ser desde llamadas telefónicas, correos electrónicos, fax, hasta los gastos
de contactos y reuniones personales).

c) Costo de tenencia o sostenimiento del inventario

Cada ítem o artículo representa un costo de manipulación en los procesos de recepción,

almacenamiento, inspección, despacho y traslado.
 11

Comercial Ariana no cuenta con esta información exacta y precisa, pero una vez
implementado en el sistema, se podrá realizar el costo de tenencia de los artículos.

Estos costos de tenencia tendrán mejor control cuando ya tenga la información necesaria para
poder realizar las operaciones necesarias.

d) Costo de quiebre de stock (costo de inexistencia)

El costo de quiebre de stock se incluyen todos los gastos emergentes de un proceso de

pérdida de ventas e incumplimiento de contratos, que se agrupan en:

- Pérdida de ingresos por ventas

- Gastos generados por incumplimiento de contratos
- Repetido y sustitución

Debe tenerse presente que una necesidad insatisfecha puede generar la pérdida de un
cliente y la pérdida de credibilidad de la empresa; factores difícilmente cuantificables a través
de un sistema informático. Con el sistema ya implantado se pretende optimizar la calidad de
gestión del inventario.

2.1.3 Modelos de inventario

De una revisión a la documentación proporcionada por la administración de la

Comercial, se desprende que el modelo utilizado corresponde al conocido como EOQ
(Economic Order Quantity o Cantidad Económica de Pedido) con faltantes (Nieto, 2015), en el
cual se permite que haya tiempos de espera entre un pedido y otro (pedidos atrasados), de esta
manera se supone que hay un tiempo donde la demanda no se satisface a tiempo y se produce
una escasez (Figura 2.1). Sus características son:

- Se permiten las faltantes

- Se incurre en un costo de Faltante
- La demanda es constante y conocida (Quintero, 2015)
- Existen tanto costos de almacenamiento como costos de pedido
- Los costos se mantienen constantes
 12

Figura 2.2: Modelo EOQ con faltante

Fuente: (Gitman & Nuñez Ramos, 2003 )
2.1.4 Métodos de valuación de inventarios

Los métodos de valuación de inventarios son técnicas utilizadas con el objetivo de

seleccionar y aplicar una base específica para evaluar los inventarios en términos monetarios.
La valuación de inventarios es un proceso vital cuando los precios unitarios de
adquisición han sido diferentes.

Los principales métodos de valuación de inventarios son:

- El Método del Costo Promedio.

- Primeras en Entrar primeras en Salir (PEPS o FIFO).
- Ultimas en Entrar Primeras en Salir (UEPS o LIFO) Derogada por la NIC 2.
a) Costo Promedio Ponderado

El método del costo promedio ponderado, llamado a menudo método del costo promedio
se basa en el costo promedio ponderado del inventario durante el período. Este método pondera
el costo por unidad como el costo unitario promedio durante un periodo, esto es, si el costo de
la unidad baja o sube durante el periodo, se utiliza el promedio de estos costos. El costo
promedio se determina de la manera siguiente: divida el costo de las mercancías disponibles
para la venta (inventario inicial + compras) entre el número de unidades disponibles. (Moreno,
2008)
 13

Ventajas

- De fácil aplicación
- En una economía inflacionaria presenta una utilidad razonable ya que promedia costos
antiguos y actuales.

2.2 Ventas

La venta es el intercambio de servicios y productos. Es a su vez entendida como un

contrato donde el sujeto que actúa como vendedor transmite un derecho, bienes o servicios al
comprador a cambio de una determinada suma de dinero. La venta puede ser tanto un proceso
personal como impersonal donde el comprador puede ser influido por el vendedor. Desde el
punto de vista contable y financiero, la venta es el montón total cobrado por productos o
servicios prestados. En cualquier situación, las ventas son el corazón de cualquier negocio y
actividad fundamental. (Arana, 2014)

La definición que se tomara es que las ventas es un cambio de productos y servicios por
dinero. Desde el punto de vista legal, se trata de la transferencia del derecho de posesión de un
bien a cambio de dinero.

2.3 Compra u obtención

En la función de compra u obtención se distinguen normalmente dos responsabilidades

separadas: Control de producción, que consiste en determinar los tipos y cantidades de
materiales que se quieren. Compras, que consiste en colocar la orden de compra y mantener la
vigilancia necesaria sobre la entrega oportuna del material.

2.4 Almacén

Según (García Cantú, 2008), el almacén es una unidad de servicio en la estructura

orgánica y funcional de una empresa comercial o industrial con objetivos bien definidos de
resguardo, custodia, control y abastecimiento de materiales y productos.

Entre los elementos que forman la estructura del sistema logístico, en las empresas
industriales o comerciales, el almacén es una de las funciones que actúa en las dos etapas del
flujo de materiales: el abastecimiento y la distribución física, constituyendo una de las
actividades importantes para el funcionamiento de la empresa; sin embargo, muchas veces fue
 14

olvidada por considerársele como la bodega o depósito donde se guardaban los materiales que
producción o ventas requería. Estos son algunos de los errores que se deben evitar:

- Zonas de carga y descarga de extensión reducida; se producirá el efecto puzzle: para poner una
mercancía tendremos que mover otra, lo cual supondrá pérdida de tiempo.

- No respetar la clasificación ABC, productos que más salen más cerca de la zona de carga, lo
contrario implicará mayor tiempo para preparar pedidos y como consecuencia pérdida de
tiempo.

- Almacén saturado: la mercancía no estará accesible directamente lo cual implica que para
preparar los pedidos habrá pérdida de tiempo; se produce nuevamente un efecto puzzle, quitar
uno para poner otro. A la hora de recuento también supone una pérdida de tiempo.

- Personal insuficiente: Implica una mala ubicación de la mercancía, desorden.

- Tener los productos sin codificar.

2.4.1 Espacio Físico

El tiempo de permanencia de las mercancías en el área debe ser lo más corta posible,
pues el espacio y el costo de operación depende de la fluidez con que estas se pasan del vehículo
del proveedor al almacén. Todo estancamiento innecesario eleva el costo del producto.

Según (García Cantú, 2008) el espacio necesario para el área de recepción, Almacén,
Despacho depende del volumen máximo de mercancía que se descarga y el tiempo de su
permanencia en ella”. La asignación del espacio físico en un almacén es de vital importancia
para tener una mejor administración y control de lo que se encuentra en él. Se utiliza el método
de Cube-per-Order Index (COI) y la política ABC, para asignar de manera eficiente los espacios
físicos de un almacén, para que el manejo de los productos se haga de manera más fácil y las
pérdidas por daños y obsolescencia sean menores.

2.4.2 Distribución de Almacén

Un almacén debe tener tres áreas principales:

- Recepción.

- Almacenamiento.
 15

- Despacho.

Según (García Cantú, 2008) el tamaño y distribución de estas tres áreas depende del
volumen de operaciones y de la organización de cada empresa en lo particular.

Estas pueden estar completamente separadas e independientes unas de otras, o bien,

dentro de un solo local.

La distribución física es el término empleado para describir las actividades relativas al

movimiento de la cantidad correcta de los productos adecuados al lugar preciso, en el momento
exacto. La calidad del servicio, intrínseca a las operaciones de distribución, es fundamental
desde el punto de vista estratégico, pues constituye para la empresa una importante ventaja
competitiva que lleve a los clientes a su elección aunque el producto sea muy similar o incluso
inferior al de sus competidores.

La distribución en planta de almacén debe estar estructurada de forma que consiga

alcanzar las siguientes metas:

- Un flujo con pocos retrocesos

- Mínimo trabajo de manipulación y transporte

- Mínimos movimientos y desplazamientos inútiles del personal

- Eficiente uso del espacio

- Previsión de una posible expansión

Por otro lado las reglas que deben seguirse cuando se realiza la distribución en planta de
almacenes son:

- Los artículos de más movimiento deben ubicarse cerca de la salida para acortar el
tiempo de desplazamiento

- Los artículos pesados y difíciles de transportar deben localizarse de tal manera que
minimicen su trabajo

- Los espacios altos deben usarse para artículos ligeros y protegidos

- Los materiales inflamables y peligrosos deben situarse en zonas cerradas y protegidas

 16

- Los artículos grandes protegidos o insensibles al agua y al sol pueden almacenarse en

algún anexo, en el exterior del edificio del almacén

2.5 La Empresa “Comercial Ariana”

Comercial Ariana es una entidad privada, con autonomía administrativa y patrimonio

independiente, construida con el pleno inventario de sus activos. Fue fundada en 1980 por el Sr.
Benedicto Morales Herrera en el departamento de La Paz. Actualmente la empresa cuenta con
tres sucursales, dos en la ciudad de La Paz y una en Santa Cruz, ofrece diversos productos de
belleza y cuidado personal de origen Americano, para niños, mujeres y hombres, realizando
ventas por mayor y menor.

La Empresa Ariana es distribuidora de productos de belleza, en las ciudades de

Cochabamba, La Paz y Santa Cruz teniendo como objetivo ser distribuidor principal a nivel
nacional, cuya principal fuente de ingresos se centra en la ciudad de La Paz.

La forma de trabajar de la Comercial Ariana es de la siguiente manera, realiza compras

de productos de belleza y cuidado personal a diferentes empresas del exterior, garantizando así
el stock necesario para cubrir la demanda de sus productos. Las ventas de los productos se
realizan categorizando a la cartera de clientes que cuenta la empresa en distribuidor, mayorista
y a detalle. A los mismos se ofrece el producto a diferentes precios según la categoría que
posean.

En la actualidad la administración de la Comercial depende de herramientas ofimáticas

comunes para el manejo de la información de sus ventas de productos, compras de mercadería
para almacén e inventarios que se maneja en todas sus sucursales, efectivamente estas
soluciones no cumplen las necesidades de la empresa, por tanto se continua llenando de manera
manual, sin un adecuado control de ingresos y salidas de inventario.

2.5.1 Situación actual

Se tuvieron varias reuniones con los responsables de la Comercial Ariana, donde se

observó los procesos cotidianos de la empresa.
 17

a) Ventas

 Las ventas al contado son registradas en el talonario de facturas. En este caso, el producto
sale de inventario y es pagado en su totalidad sin deudas pendientes.
 Las ventas a crédito son registradas en un talonario de recibos. El producto es pagado en
cuotas hasta que se completa el total y seguidamente se hace el registro de la venta en el
talonario de facturas. En este caso el producto sale de inventario, pero el cliente mantiene
una deuda con la empresa.
 En cuanto a las devoluciones de productos se anula el registro de venta y se realiza un nuevo
registro en los talonarios de factura si es venta al contado o recibo si es venta a crédito.
 No se tiene un registro de los productos existentes y la búsqueda es realizada de forma
manual.
 Se cuenta con una lista de precios de los productos, la cual se elabora de manera de forma
manual y se contrasta a simple vista cada vez que se modifica.
 Las ventas en cada sucursal son registradas en un cuaderno y son llevadas mensualmente a
la sucursal principal para hacer las cuentas correspondientes.
 Los precios deben ser definidos por el gerente, quien tiene su propio método de ponderación
de precios, el cual no puede ser traducido en una fórmula o ecuación definida.

b) Compras

 Cada compra está relacionada a un proveedor.

 Cada compra es registrada en un archivo de hoja de cálculo y su precio es procesado según
los datos de la compra si existe devolución se envía un formulario al proveedor y se actualiza
el nuevo saldo.
 En cada compra, la verificación de la existencia del producto es realizada de forma manual
comparándolo con una lista en un documento físico.
 Mientras no se realiza el proceso de obtención de precios, el producto no puede salir a
exposición y ser vendido.
 Los precios finales están registrados en un archivo de hoja de cálculo, la cual es utilizada
como guía de precios.
 18

c) Inventario

 No hay un registro de la entrada de productos, ni tampoco la suma de un restante con una

nueva entrada de productos.
 No se dispone un registro de la cantidad actual de cada producto en el inventario de cada
sucursal.
 La distribución de productos es registrada en un archivo de hoja de cálculo.
 Los productos ingresan primeramente al inventario del establecimiento principal y luego son
distribuidos a las sucursales.

2.5.2 Misión

Somos una Importadora de Cosméticos, orientada a satisfacer todas las necesidades y

expectativas de nuestros clientes, ofreciendo servicios de alta calidad, respaldado por una
moderna tecnología y recursos humanos calificados y comprometidos con el desarrollo de la
industria de la belleza en Bolivia.

2.5.3 Visión

Ser empresa líder en la importación de productos en marcas de calidad para el

mejoramiento de la belleza femenina; con altos valores éticos, que sirvan como modelo al sector
empresarial en nuestro país.

2.6 Ingeniería de software

La ingeniería de software es una disciplina que permite construir soluciones software de

calidad, a partir de distintos componentes que se ocupan de diversos aspectos del problema a
resolver, aplicando una variedad de métodos, herramientas, procedimientos.

 Los métodos de ingeniería de software nos indicaran “como” construir técnicamente el

software. Estos abarcan una serie de actividades tales como: análisis, diseño, codificación,
pruebas y mantenimiento.
 Las herramientas de ingeniería de software son instrumentos automatizados para utilizar en
métodos o procedimientos.
 Los procedimientos de ingeniería de software son combinaciones de herramientas y métodos
para llegar a un producto en particular.
 19

2.7 Metodologías de desarrollo ágil

Las metodologías ágiles surgen por ser las más adecuadas para proyectos donde el
entorno del sistema es muy cambiante y se exige reducir al máximo los tiempos de desarrollo
manteniendo una alta calidad.

Las metodologías ágiles impulsan generalmente una gestión de proyectos que promueve
el trabajo en equipo, la organización y responsabilidad propia, un grupo de buenas prácticas de
ingeniería de software que brindan una entrega rápida de software de alta calidad, y un enfoque
de negocios que alinea el desarrollo con las necesidades del cliente y los objetivos de la
compañía.

Existe una gran variedad de metodologías ágiles cada una tiene sus particularidades,
manejan roles muy peculiares, suponen un conjunto de expertos con habilidades para resolver
desde problemas técnicos hasta los más abstractos y complejos, por lo tanto exigen experiencia.
Definen ciclos, que en algunos casos incluyen varias fases, similares a los procesos de desarrollo
de software tradicionales. Generan documentación indispensable, aunque el proceso para
generarlas es menos rígido. Aunque lo más importante es que están abiertas a modificar
requerimientos, sin tomar el impacto en la arquitectura del sistema.

Una comparación básica entre metodologías ágiles y metodologías tradicionales puede

verse en la Tabla 2.1. Estas diferencias no solo afectan al proceso de desarrollo de software,
sino también al contexto del equipo y a la organización (Rivadeneira , 2012).
Tabla 2.3: Comparación de las metodologías tradicionales y las ágiles

Fuente: (Rivadeneira , 2012)

 20

2.8 Programación extrema (XP)

XP es una metodología ágil centrada en potenciar las relaciones interpersonales como

clave para el éxito en el desarrollo de software, promoviendo el trabajo en equipo,
preocupándose en todo momento del aprendizaje de los desarrolladores y propiciando un buen
clima de trabajo. XP se basa en la realimentación continua entre el cliente y el equipo de
desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones
implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada
para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo
técnico. (Robles Martínez & Ferrer Zarzuela, 2002)

2.8.1 Valores de la metodología XP

XP se basa en cuatro valores, que deben estar presentes en el equipo de desarrollo para
que el proyecto tenga éxito. (Joskowicz, 2011)

 Comunicación: Muchos de los problemas que existen en proyectos de software se deben a

problemas de comunicación entre las personas. La comunicación permanente es
fundamental dado que la documentación es escasa, el diálogo cara a cara entre
desarrolladores, gerentes y el cliente es el medio básico de comunicación.
 Simplicidad: XP apuesta a la sencillez en su máxima expresión, en el diseño, en el código,
en los procesos y demás. La sencillez es esencial para que todos puedan entender el código,
y se trata de mejorar mediante recodificaciones continuas.
 Retroalimentación: La retroalimentación debe funcionar en forma permanente. El cliente
debe brindar retroalimentación de las funciones desarrolladas, de manera de poder tomar sus
comentarios para la próxima iteración y para comprender sus necesidades.
 Coraje: Ante problemas serios en el diseño, o en cualquier otro aspecto, se debe tener el
coraje suficiente como para encarar su solución, sin importar que tan difícil sea. Si es
necesario cambiar completamente parte del código, hay que hacerlo, sin importar cuanto
tiempo se ha invertido previamente en el mismo.

2.8.2 Roles en XP

De acuerdo con la propuesta original de Kent Beck, el denominado “padre” de XP, los
roles involucrados en esta metodología son (Penadés & Letelier , 2004):
 21

 Programador: El programador escribe las pruebas unitarias y produce el código del

sistema.
 Cliente: El cliente escribe las historias de usuario y las pruebas funcionales para validar su
implementación.
 Encargado de pruebas: Ayuda al cliente a escribir las pruebas funcionales.
 Encargado de seguimiento: El encargado de seguimiento proporciona realimentación al
equipo en el proceso XP.
 Entrenador: Es responsable del proceso global.
 Consultor: Es un miembro externo del equipo con un conocimiento específico en algún
tema necesario para el proyecto. Guía al equipo para resolver un problema específico.
 Gestor: Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje
efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.

2.8.3 Ciclo de vida de XP

Las iteraciones son relativamente cortas ya que se piensa que entre más rápido se le
entreguen desarrollos al cliente, más retroalimentación se va a obtener y esto va a representar
una mejor calidad del producto a largo plazo.

Existe una fase de análisis inicial orientada a programar las iteraciones de desarrollo y
cada iteración incluye diseño, codificación y pruebas, fases superpuestas de tal manera que no
se separen en el tiempo. (Ardila Albarracin, 2016)

Figura 2.3: Ciclos de desarrollo XP

Fuente: (Borja López, 2016)
 22

2.8.4 Fases de la metodología XP

XP está clasificada en cuatro fases estructurales: Planificación, Diseño, Desarrollo y

Pruebas, las cuales pueden observarse a continuación:

Figura 2.4: Fases de la metodología XP

Fuente: (Joskowicz, 2011)
a) Planificación del proyecto

En esta fase los clientes escriben las historias de usuario que serán incluidas en la primera
versión. Cada una de estas historias de usuario describirá una funcionalidad que será agregada
al programa. El periodo de tiempo de esta fase puede variar entre unas pocas semanas a unos
pocos meses, dependiendo del conocimiento que posea el equipo de desarrollo con las
tecnologías a utilizar.

Se define también la prioridad de las distintas historias y se acuerda el contenido de la

primera entrega del proyecto. La primera entrega no tardara más de dos meses en darse. La
duración de esta fase de planificación no suele exceder unos pocos días.
 23

Por último, la planificación divide el tiempo en varias iteraciones, de duración variable,

entre una semana y cuatro. Los usuarios deciden que historias se realizarán en cada iteración,
ya que la primera entrega suele contener toda la arquitectura del sistema. Las pruebas
funcionales son creadas por el cliente y se ejecutan al término de cada iteración.

 Historias de usuario: Corresponden a la técnica utilizada para especificar los requisitos del
software. Se trata de formatos en los cuales el cliente describe brevemente las características
que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de
las historias de usuario es muy dinámico y flexible. Cada historia de usuario es lo
suficientemente comprensible y delimitada para que los programadores puedan
implementarla en unas semanas. A efectos de planificación, las historias pueden ser de una
a tres semanas de tiempo de programación (para no superar el tamaño de una iteración).
(Rojas, 2008)
La Plantilla a utilizarse para la elaboración de las historias de usuario se muestra en la tabla
2.2 y cada uno de sus componentes se explica a continuación. (Letelier & Penades, 2006)

Tabla 2.4: Plantilla para las historias de usuario

HISTORIA DE USUARIO
Numero: Permite identificar a una historia Usuario: Persona que utilizará la
de usuario. funcionalidad del sistema descrita en la
historia de usuario.
Nombre historia de usuario: Describe de manera general a una historia de usuario.
Puntos estimados: Número de semanas Iteración asignada: Número de iteración,
que se necesitará para el desarrollo de una en que el cliente desea que se implemente
historia de usuario. una historia de usuario.
Programador responsable: Persona encargada de programar cada historia de usuario.
Descripción: Información detallada de una historia de usuario.
Observaciones: Campo opcional utilizado para aclarar, si es necesario, el requerimiento
descrito de una historia de usuario.
Fuente: (Letelier & Penades, 2006)

 Tareas de ingenierías (Task Card): Una Historias de Usuario se descompone en varias

tareas de ingeniería, las cuales describen las actividades que se realizarán en cada historia de
usuario, así mismo las tareas de ingeniería se vinculan más al desarrollador, ya que permite
tener un acercamiento con el código. (Ferreira Escutia, 2013)
 24

La Plantilla a utilizarse para la elaboración de las tareas de ingeniería se muestra en la tabla

2.3 y cada uno de sus componentes.

Tabla 2.3: Plantilla para tareas de ingeniería

TAREA DE INGENIERÍA
Número de tarea: Permite identificar a Número de historia: Número asignado
una tarea de ingeniería. de la historia correspondiente.
Nombre de tarea: Describe de manera general a una tarea de ingeniería.

Tipo de tarea: Tipo al que corresponde la Puntos estimados: Número de días que
tarea de ingeniería. se necesitará para el desarrollo de una
tarea de ingeniería.
Fecha inicio: Fecha inicial de la creación Fecha fin: Final concluida de la tarea de
de la tarea de ingeniería. ingeniería.
Programador responsable: Persona encargada de programar la tarea de ingeniería.

Descripción: Información detallada de la tarea de ingeniería.

Fuente: Ferreira Escutia, 2013

 Plan de entregas (release planning): Después de tener ya definidas las historias de usuario
es necesario crear un plan de publicaciones, donde se indiquen las historias de usuario que
se crearán para cada versión del programa y las fechas en las que se publicarán estas
versiones. Después de un Release planning tienen que estar claros estos cuatro factores: los
objetivos que se deben cumplir (que son principalmente las historias que se deben desarrollar
en cada versión), el tiempo que tardarán en desarrollarse y publicarse las versiones del
programa, el número de personas que trabajarán en el desarrollo y cómo se evaluará la
calidad del trabajo realizado.
 Iteraciones: Todo proyecto que siga la metodología XP se ha de dividir en iteraciones de
aproximadamente 1 a 3 semanas de duración. Al comienzo de cada iteración los clientes
deben seleccionar las historias de usuario definidas en el "Release planning" que serán
implementadas. También se seleccionan las historias de usuario que no pasaron el test de
aceptación que se realizó al terminar la iteración anterior. Estas historias de usuario son
divididas en tareas de entre 1 y 3 días de duración que se asignarán a los programadores.

Para cada iteración se define un módulo al conjunto de historia de usuario que se van a
implementar, al final de cada iteración se tiene la entrega de un producto, el cual debe
 25

superar las pruebas de aceptación que establece el cliente para dar cumplimiento a los
requisitos las tareas que no se vean cubiertas por el producto deberán ser tomadas en cuenta para
la siguiente iteración.

 Velocidad del proyecto: Es una medida que representa la rapidez con la que se desarrolla
el proyecto; estimarla es muy sencillo, basta con contar el número de historias de usuario
que se pueden implementar en una iteración; de esta forma, se determinara el cupo de
historias que se pueden desarrollar en las distintas iteraciones. Usando la velocidad del
proyecto controlaremos que todas las tareas se puedan desarrollar en el tiempo del que
dispone la iteración. Es conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se
aprecia que no es adecuada hay que negociar con el cliente un nuevo Release Plan.

La velocidad de proyecto se usa para determinar cuántas historias de usuario puede ser
implementada antes de una fecha dada (tiempo), o cuento tiempo es necesario para llevar a
cabo un conjunto de historias (alcance). Cuanto se realiza una planificación por alcance se
divide el número total de semanas entre la velocidad del proyecto para determinar cuántas
iteraciones estarán disponibles.

 Programación en parejas: La metodología X.P. aconseja la programación en parejas pues

incrementa la productividad y la calidad del software desarrollado. El trabajo en pareja
involucra a dos programadores trabajando en el mismo equipo; mientras uno codifica
haciendo hincapié en la calidad de la función o método que está implementando, el otro
analiza si ese método o función es adecuado y está bien diseñado. De esta forma se consigue
un código y diseño con gran calidad
 Reuniones diarias: Es necesario que los desarrolladores se reúnan diariamente y expongan
sus problemas, soluciones e ideas de forma conjunta. Las reuniones tienen que ser fluidas y
todo el mundo tiene que tener voz y voto.
b) Diseño

La Metodología XP hace especial énfasis en los diseños simples y claros. Los conceptos
más importantes de diseño en esta metodología son los siguientes: Simplicidad, Un diseño
simple se implementa más rápidamente que uno complejo.
 26

 Diseños simples: La metodología XP sugiere que se debe realizar diseños simples y

sencillos. Se debe procurar hacerlo todo lo menos complicado posible para conseguir un
diseño fácilmente entendible e implementable que a la larga costará menos tiempo y
esfuerzo desarrollar.
 Glosarios de términos: Usar glosarios de términos y una correcta especificación de los
nombres de métodos y clases ayudará a comprender el diseño y facilitará sus posteriores
ampliaciones y la reutilización del código.
 Riesgos: Si surgen problemas potenciales durante el diseño, XP sugiere utilizar una pareja
de desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese
problema.
 Funcionalidad extra: Nunca se debe añadir funcionalidad extra al programa aunque se
piense que en un futuro será utilizada. Sólo el 10% de la misma es utilizada, lo que implica
que el desarrollo de funcionalidad extra es un desperdicio de tiempo y recursos.
 Tarjetas C.R.C.: Las Tarjetas CRC (Clase-Responsabilidades-Colaboradores), permiten
conocer que clases componen el sistema y cuales interactúan entre sí. Se dividen en tres
secciones: Nombre de la Clase, Responsabilidades y Colaboradores. (Chiluisa Pallo &
Loarte Cajamarca, 2014)

La Plantilla a utilizarse para la elaboración de las Tarjetas CRC se muestra en la Tabla y a

continuación se describen cada uno de los componentes.

Tabla 2.4: Plantilla para las tarjetas CRC

TARJETAS CRC
Nombre de la clase: Nombre de la clase al cual hace referencia la tarjeta.
Responsabilidades: Atributos y Colaboradores: Clases que colaboran
operaciones de la clase. con la clase citada en la tarjeta.
Fuente: Chiluisa Pallo & Loarte Cajamarca, 2014
c) Codificación

La codificación es un proceso que se realiza en forma paralela al diseño. La codificación

debe hacerse ateniendo a estándares de codificación ya creados. Programar bajo estándares
mantiene el código consistente, facilita su comprensión y escalabilidad.
 27

 Cliente siempre presente: Uno de los requerimientos de XP es que el cliente este siempre
presente y disponible. No solamente para solucionar las dudas del grupo de desarrollo,
debería ser parte de este. (Echeverry y Delgado, 2007)
 Codificar primero la prueba: Cuando se crea la primera prueba, se ahorra mucho tiempo
elaborando el código que la haga pasar, siendo menor el tiempo de hacer ambos procesos
que crear el código solamente. (Echeverry y Delgado, 2007)
 No trabajar más de 40 horas semanales: Trabajar horas extras absorbe al espíritu y la
motivación del equipo. Aquellos proyectos que requiera horas extras para acabarse a tiempo
pueden convertirse en un problema en lugar de esto se utilizara las conocidas reuniones
también es una mala idea incorporar nueva gente al proyecto. (Echeverry y Delgado, 2007)

d) Pruebas

Uno de los pilares de la metodología XP es el uso de test para comprobar el

funcionamiento de los códigos que vayamos implementando.

 Pruebas unitarias: Todos los módulos deben de pasar las pruebas unitarias antes de ser
liberados o publicados. Por otra parte, como se mencionó anteriormente, las pruebas deben
ser definidas antes de realizar el código (“Test-Driven Programmming”). Que todo código
liberado pase correctamente metodología XP las pruebas unitarias, es lo que habilita que
funcione la propiedad colectiva del código.
 Detección y corrección de errores: Cuando se encuentra un error (“Bug”), éste debe ser
corregido inmediatamente, y se deben tener precauciones para que errores similares no
vuelvan a ocurrir. Asimismo, se generan nuevas pruebas para verificar que el error haya sido
resuelto.

 Pruebas de aceptación: Según (Chiluisa Pallo & Loarte Cajamarca, 2014) Las Pruebas de
aceptación son de vital importancia para el éxito de una iteración y el comienzo de la
siguiente, con lo cual el cliente puede conocer el avance en el desarrollo del sistema y a los
programadores lo que les resta por hacer. Además permite una retroalimentación para el
desarrollo de las próximas historias de usuarios a ser entregadas. Estas son comúnmente
llamadas pruebas del cliente, por lo que son realizadas por el encargado de verificar si las
historias de usuarios de cada iteración cumplen con la funcionalidad esperada.
 28

La Plantilla a utilizarse para la elaboración de las pruebas de aceptación se muestra en la

Tabla 2.5 y a continuación se definen cada uno de los componentes.

Tabla 2.5: Plantilla para las pruebas de aceptación

PRUEBAS DE ACEPTACION
Código: Nº Único, permite identificar la Nº Historia de usuario: Número único que
prueba de aceptación. identifica a la historia de usuario.
Historia de usuario: Nombre que indica de manera general la descripción de la historia
de usuario.
Condiciones de ejecución: Condiciones previas que deben cumplirse para realizar la
prueba de aceptación.
Entrada/pasos de ejecución: Pasos que siguen los usuarios para probar la
funcionalidad de la historia de usuario.
Resultado esperado: Respuesta del sistema que el cliente espera, después de haber
ejecutado una funcionalidad.
Evaluación de la prueba: Nivel de satisfacción del cliente sobre la respuesta del
sistema. Los niveles son: Aprobada y No Aprobada.
Fuente: Chiluisa Pallo & Loarte Cajamarca, 2014

2.8.5 Prácticas de la metodología XP

Esta Metodología recomienda a seguir las siguientes prácticas:

 Comunicación: Conversación continúa entre el equipo de desarrollo y el cliente, para

implementar cambios lo antes posible.
 Entregas pequeñas: Entrega en versiones operativas.
 Diseño simple: Diseñar lo más posible, pero con la funcionalidad requerida.
 Pruebas: Se realizan pruebas unitarias por parte de los programadores y pruebas de
aceptación por parte del cliente.
 Refactorización (Refactoring): Remover código duplicado para facilitar los posteriores
cambios.
 Programación en parejas: Se realiza para contar con menor tasa de errores, mejor diseño
y mayor satisfacción de los programadores.
 Integración continúa: Cuando un fragmento de código esté listo, puede ser integrado al
sistema.
 29

 Cliente IN-SITU: El Cliente debe estar presente y disponible para el equipo de desarrollo.
 Estándares de programación: Normas definidas por los desarrolladores para tener un
código legible.
 Juego de la planificación: Desde el comienzo del desarrollo se requiere que el grupo y el
cliente tengan una visión general del proyecto. En el transcurso del mismo se realizan
diferentes reuniones, con el fin de organizar las tareas e ideas que surgen tanto por parte del
cliente como del equipo.
 Propiedad colectiva del código: El Código no es conocido por una sola persona del grupo
del trabajo, esto facilita implementar cambios al programa por parte de otros integrantes del
grupo.
 Utilización de metáforas del sistema: Para mejorar el entendimiento de los elementos del
sistema por parte del equipo de desarrollo se acude a la utilización de metáforas, como una
forma de universalizar el lenguaje del sistema.
 Test del cliente: El Cliente con la ayuda de los desarrolladores, propone sus propias pruebas
para validar las mini-versiones.
 40 horas por semana: Se debe de trabajar un máximo de 40 horas por semana.

2.9 Metodología de evaluación de calidad de sitios Web (WEB SITE QEM)

Es una metodología basada en métodos, modelos, principios y herramientas de

Ingeniería de Software útil para la evaluación y comparación cuantitativa de la calidad de
artefactos Web, principalmente en la fase operativa del ciclo de vida. No obstante, se puede
utilizar en fases de exploración y desarrollo, en este caso se debe sincronizar con el modelo de
proceso de desarrollo. Las fases de la metodología que intervienen en el proceso de evaluación
y ordenamiento de calidad son:

 Planificación y Programación de la Evaluación de Calidad

 Definición y Especificación de Requerimientos de Calidad
 Definición e Implementación de la Evaluación Elemental
 Definición e Implementación de la Evaluación Global
 Análisis de Resultados, Conclusión y Documentación
 Validación de Métricas (OLSINA, 2000)
 30

Figura 4.1Proceso de evaluación y comparación Fuente:

Figura 2.4: Proceso de evaluación y comparación
Fuente: (OLSINA, 2000)

2.9.1 Fase de planificación y programación de la evaluación de calidad

La misma contiene actividades y procedimientos de soporte, con el fin de determinar

objetivos estratégicos, tácticos u operativos. Esto permite establecer las principales estrategias
y metas del proceso en un contexto organizacional, permitiendo seleccionar un modelo de
procesamiento de evolución, asignar métodos, agentes, recursos a la actividad.

2.9.2 Fase de definición y especificación de requerimientos de calidad

La misma trata con actividades y modelos para la elicitación, determinación, análisis y
especificación de los requerimientos. A partir de un proceso de medición orientado a metas, y
con el fin de evaluar, comparar, analizar, y mejorar características y atributos de artefactos Web,
los requerimientos deben responder a necesidades y comportamientos de un perfil de usuario y
dominio dados. Los requerimientos definidos están basados en los siguientes atributos:
1. Usabilidad [Link] Ayuda de la Búsqueda
1.1 Comprensibilidad Global del Sitio 1.2.2 Indicador de Última Actualización
1.1.1 Esquema de Organización Global [Link] Global (de todo el sitio Web)
[Link] Mapa del Sitio [Link] Restringido (por subsitio o página)
[Link] Tabla de Contenidos 1.2.3 Directorio de Direcciones
[Link] Índice Alfabético [Link] Directorio E-mail
[Link] Visita guiada [Link] Directorio TE-Fax
1.2 Facilidad de Aprender [Link] Directorio Correo Postal
1.2.1 Calidad de la Ayuda 1.2.4 Facilidad FAQ
[Link] Ayuda Explicatoria Orientada al Ciudadano 1.2.5 Retroalimentación
 31
[Link] Cuestionario [Link] Información del Organismo
[Link] Libro de Invitados [Link].1 Índice de las Dependencias
1.3 Operabilidad [Link].2 Sub-sitios de las Dependencias
1.31 Aspectos Enlace [Link] Información de Trámites de la Entidad
[Link] Vínculos hacia atrás y adelante [Link].1 Índice de Trámites/Gestiones
[Link] Vínculos al Mapa del sitio, índice de [Link].2 Información de los Requisitos de
contenidos Trámites/Gestiones
1.3.2 Tolerancia a errores [Link].3 Formulario para Rellenar/Bajar
[Link] Soporte con mensaje de error [Link].4 Seguimiento de trámites
[Link] Mensaje de error fácil de entender [Link] Información de Presupuesto
1.3.3 Independencias [Link].1 Índice de Proyectos
[Link] Independencia del sistema [Link].2 Descripción de Proyectos
[Link] Independencia de la máquina [Link].3 Participación ciudadana en proyectos
1.4 Grado de Atractivo [Link] Información de Servicios al ciudadano
1.4.1 Aspectos de Estilo 2.3.2 Servicios On-line
[Link] Uniformidad en el Color de Enlaces [Link] Información Aranceles, tarifas
[Link] Uniformidad en el Estilo Global Trámites/Gestiones
[Link] Guía de Estilo Global [Link] Servicio de Páginas Web
1.4.2 Preferencia Estética [Link] Servicio FTP para descarga de leyes y
1.5 Misceláneas formularios
1.5.1 Soporte a Lenguaje Extranjero [Link] Servicio de Grupo de Noticias
1.5.2 Atributo “Qué es lo Nuevo” [Link] Servicio de normativa vigente para
1.5.3 Indicador de Resolución de Pantalla Trámites/Gestiones.
2. Funcionalidad 2.3.3 Redes Sociales
2.1 Aspectos de Búsqueda y Recuperación [Link] Tiene presencia en una red social
2.1.1 Mecanismo de Búsqueda en el Sitio Web [Link] Tiene presencia en más de una red social
[Link] Búsqueda Restringida [Link] Enlaces no Implementados
[Link].1 de Servicios 3.1.2 Errores o Deficiencias Varias
[Link].2 de Trámites [Link] Deficiencias o cualidades ausentes debido a
[Link].3 de Legislación diferentes navegadores (browsers)
[Link] Búsqueda Global [Link] Deficiencias o resultados inesperados
2.1.2 Mecanismos de Recuperación independientes de browsers ([Link]. errores
[Link] Nivel de Personalización de búsqueda imprevistos, deficiencias con marcos
[Link] Nivel de Retroalimentación en la (frames), etc.)
Recuperación [Link] Nodos Destinos (inesperadamente) en
2.2 Aspectos de Navegación y Exploración Construcción
2.2.1 Navegabilidad [Link] Nodos Web Muertos (sin enlaces de retorno)
[Link] Orientación 4. Eficiencia
[Link].1 Indicador del Camino 4.1 Performancia
[Link].2 Etiqueta de la Posición Actual 4.1.1 Páginas de Acceso Rápido
[Link] Promedio de Enlaces por Página 4.1.2 Tamaño de la página
2.2.2 Objetos de Control Navegacional 4.1.3 Tiempo de respuesta de los servicios
[Link] Permanencia y Estabilidad en la Presentación 4.1.4 Tiempo para completar un trámite
de los Controles Contextuales 4.2 Accesibilidad
(Subsitio) 4.2.1 Accesibilidad de Información
[Link].1 Permanencia de los Controles Contextuales [Link] Soporte a Versión sólo Texto
[Link].2 Estabilidad [Link] Legibilidad al desactivar la Propiedad
[Link] Nivel de Desplazamiento Imagen del Browser
[Link].1 Desplazamiento Vertical [Link].1 Imagen con Título
[Link].2 Desplazamiento Horizontal [Link].2 Legibilidad Global
2.2.3 Predicción Navegacional 4.2.2 Accesibilidad de Ventanas
[Link] Enlace con Título (enlace con texto [Link] Número de Vistas considerando Marcos
explicatorio) (frames)
[Link] Calidad de la Frase del Enlace [Link] Versión sin Marcos
2.3 Aspectos del Dominio orientados al Ciudadano
2.3.1 Relevancia de Contenido
 32

2.9.3 Fase de definición e implementación de la evolución elemental

La elección del tipo de criterio de evaluación elemental resulta de importancia en

consideración de los niveles de precisión depende del grado de criticidad de algunos o de todos
los componentes del producto en un proyecto de evaluación. Dos tipos básicos de criterios
elementales son los absolutos y los relativos y dentro de los primeros se pueden descomponer
en criterios son variables continuas y criterios con variables discretas (Olsina, 2000). Como
vemos en la siguiente figura:

Figura 2.6: Tipos de criterio elemental

Fuente: Olsina, 2000
a) Criterio elemental absoluto con variable continúa
 Criterio de variable única: Este es un criterio elemental común, se asume que la variable
X es única y continua, con el fin de determinar el criterio elemental. El primer paso consiste
en definir el rango de valores de interés para la evaluación de la variable continua, el
siguiente paso, consiste en determinar las coordenadas de los puntos más relevantes y su
preferencia de calidad.
 Criterio de variable normalizada: Este es un criterio elemental que se suele utilizar para
evaluar la relación entre dos atributos con criterio absolutos de un mismo sistema definido
por:

Umi=Xi/Xj
 33

Donde Xi= ∑ de puntajes máximos y Xj= ∑ de atributos con puntaje obtenido.

 Criterio de multi-variables continúas: En este tipo de criterio, la variable X es restante de

algunas otras variables y constantes (el valor de X corresponderá una métrica indirecta).
 Criterio de preferencia de calidad directa: Este tipo de criterio es subjetivo y basado en
la experiencia y criterios de los evaluadores. Desde el punto de vista de la precisión y
objetividad, es el peor criterio, debido a que pueden introducir errores de valoración
intencionales e involuntarios.

No obstante, dentro de los requerimientos alguno atributos solo podrán comportarse de un

modo subjetivo, a partir del juicio de evaluadores expertos. Es decir, puede ser difícil y
costoso modelar la descomposición del atributo para determinar la preferencia de calidad.

El criterio para la variable x se mapea en una preferencia trivial cuyas coordenadas con:

CrE(Xi)={(0,0),(100,100)}

b) Criterios elementales absolutos con variables discretas

 Criterio binario: Este criterio es el más simple de los criterios discretos y absolutos. El
criterio para la variable X se mapea en una preferencia elemental cuyas coordenadas son:

CrE(Xi)={(0,0),(1,100)}

Donde un valor de Xi=0 se interpreta como la ausencia del atributo de calidad; en cambio
un valor de Xi=1, se interpreta como la presencia o disponibilidad del mismo.
 Criterio de multi-nivel: Este criterio es una generalización del criterio binario. La variable
discreta puede tomar más de dos valores, cada uno de los cuales se corresponde a una
preferencia de calidad.

CrE(Xi)={(0,0),(1,60),(2,100)}

Donde un valor de Xi=0 se interpreta como la ausencia del atributo de calidad en cambio un
valor de Xi=1, se interpreta como la presencia parcial de la versión solo texto; y finalmente,
un valor Xi=2, se interpreta como la presencia total de la versión solo texto para todo el sitio
web.
 34

 Criterio de multi-nivel definido como subconjunto: Este criterio es uno multi-nivel

definido como un subconjunto de los numero naturales (en una escala estrictamente ordinal).
La variable discreta puede tomar más de dos valores, cada de los cuales se corresponde a un
a preferencia de calidad.

CrE(Xi)={(0,0),(1,60),(2,100)}

En donde el listado de valores para Xi es como sigue: 0= ausencia del atributo; 1= atributo
básico; 2= atributo extendido o avanzado

 Criterio de multi-variable discretas: Este criterio permite agrupar varias variables

discretas y modelas el resultado en una única variable X. De este modo se puede reducir la
cantidad de criterios elementales. Sea el conjunto de variables discretas Di,….,Dm ,
entonces se puede definir una variable compuesta X, también discreta, como función de las
anteriores:

X=F(Di,….Dn) y Xe{Xi…..Xn}

2.9.4 Fase de definición e implementación de la evaluación global

Trata con actividades, modelos y herramientas para determinar los criterios de

agregación de las preferencias de calidad elemental para producir la preferencia global, para
cada sistema seleccionado. Se considera tipos de funciones de agregación para modelar
diferentes relaciones entre atributos y características.

Para caracterizar el sistema a evaluar y comparar se identifican n atributos necesarios,

cuya preferencia o indicador elemental (EI) se debe computar y los valores individuales de
IE1..IEn están normalizados de manera que: 0<=IEi<=100% además que las características
están asociadas a pesos definidos como Pi. En este caso se expresa el indicador o preferencia
global (IG) mediante el uso de una sumatoria:

IP=P1 IE1+……+PnIEn para 0<=IEI<=1

Donde 0<=Pi<=1, para i=1….n y P1+…….+Pn=1

Tanto los puntajes excedentes, como el indicador de calidad global están en uno de los tres
niveles de aceptabilidad.
 35

Tabla 2.6: Rango de medición

Insatisfecho De 0 a 40 %
Marginal De 40 a 60 %
Satisfecho De 60 a 100%

Fuente: Olsina, 2000

 36

CAPITULO III

MARCO APLICATIVO

3.1 Fase de planificación

La fase de planificación es una de las más importantes ya que en esta fase se redactó por
el cliente las historias de usuario, las tareas que se llevaran para la programación de sus
respectivos módulos, el plan de entregas y las iteraciones que tendrá el sistema web. En las
reuniones se definieron el contexto y los límites del sistema, y las prioridades que tienen uno de
otros.

3.1.1 Clasificación e identificación de roles

Se deben identificar a todos los roles que van a interactuar con el sistema, y
posteriormente se los clasifica en clases y subclases de actores, de esta manera se organiza mejor
el acceso a la información del sistema y se tiene mejor control y seguimiento sobre los usuarios,
evitando confusiones sobre las funciones que debe ejecutar cada usuario.

Tabla3.1: Identificación de roles

ROL DESCRIPCIÓN
Administrador Configura los parámetros del sistema, administrando usuarios, roles
del Sistema y la asignación de estos mismos.
 37

Gerente Tiene acceso a los reportes, y configura parámetros del negocio,

administrando proveedores, clientes, categorías, sucursales,
compras, ventas e inventarios.
Encargado de Registra ventas al contado y a crédito, devuelve ventas, visualiza
Ventas los productos disponibles, registra clientes.
Encargado de Registra las compras, devuelve compras, registra proveedor,
Compras registra productos con sus respectivas categorías.
Encargado de Verificación de la existencia de productos, registra distribución de
Almacén mercadería.
3.1.2 Obtención de requerimientos

Se plantea una clasificación de requerimientos en dos tipos: Los funcionales y los no

funcionales. Los requerimientos funcionales definen características sobre el funcionamiento del
sistema, es decir, describen las transformaciones que el sistema realiza sobre las entradas para
producir salidas. Por otro lado, se tienen los requerimientos no funcionales, los cuales
determinan características que de una u otra forma puedan limitar el sistema.

a) Requerimientos funcionales

i) Administración del sistema

Todo sistema debe contar con este módulo, donde el usuario pueda administrar los
ajustes básicos del sistema. El sistema debe:

 R1-1 Administrar usuarios: También permitir la asignación de uno o más roles a un

usuario.
 R1-2 Administrar roles: Encargado de limitar el acceso a los recursos del sistema.

ii) Módulo de ventas

El módulo de ventas requiere que el sistema provea las siguientes opciones:

 R2-1 Administración de las ventas: Las ventas deben registrarse en los dos tipos que
maneja el Comercial.
o A crédito: Realizar el registro correspondiente de la transacción, donde el producto
sale del inventario, aunque no se haya pagado completamente el total del o los
 38

productos. También debe permitir el registro de las deudas y los pagos en cuotas por
parte del cliente.
o Al contado: Autorizar el registro correspondiente de la transacción. El producto sale
de inventario y es pagado en su totalidad.
 R2-2 Relacionar las ventas con los clientes: Toda venta debe estar relacionada con el
registro del cliente, de manera que sea posible contabilizar las compras del cliente de forma
periódica.
 R2-3 Llevar seguimiento de las ventas por sucursal: Listar las ventas realizadas en cada
sucursal en función a periodos de tiempo y tipos de ventas.
 R2-4 Relacionar los usuarios de ventas con las sucursales: Debe relacionar cada registro
de venta con el usuario del vendedor, de manera que se puedan obtener reportes de la
cantidad de ventas realizadas por cada usuario.
 R2-5 Administración de la devolución de productos por venta y cliente: El cliente podrá
realizar la devolución del producto. Modificar y eliminar las ventas relacionadas con dichos
productos devueltos para actualizar los detalles saldos y total.
 R2-6 Administración de clientes: Crear, listar, buscar, modificar y eliminar registros de
clientes.

iii) Módulo de compras

El módulo de compras debe contar con el registro de las transacciones de compra, cada
transacción registra básicamente los siguientes datos: Nro. de transacción, fecha, nombre del
proveedor, tipo de comprobante, numero de comprobante. Además, el sistema debe contar con
las siguientes especificaciones y funciones:

 R3-1 Administración de las compras relacionando a los proveedores: Hacer el registro

correspondiente de cada compra relacionando al proveedor. Para las compras se requiere
seguir los siguientes pasos:
o Verificación de la existencia del material según el comprobante recibido por parte del
proveedor, anotando las cantidades recibidas.
o Hacer el registro de la cantidad de cada producto, el cual debe ser adicionado al stock ya
existente.
 39

Las compras al igual que las ventas deben registrarse en los dos tipos que maneja el Comercial.

o A crédito: Realizar el registro correspondiente de la transacción. También debe permitir

el registro de las deudas y los pagos en cuotas por parte de la empresa con el proveedor.
o Al contado: Autorizar el registro correspondiente de la transacción.
 R3-2 Administración de proveedores: Crear, listar, buscar, modificar y eliminar registros
de los proveedores, y a la vez permitir adicionar uno o más contactos a cada proveedor.
 R3-3 Administración de devolución en compras: Modificar y/o eliminar compras
devueltas y actualizar el detalle saldo, total.

iv) Módulo de inventario

El módulo de inventario debe proveer las siguientes opciones y funciones:

 R4-1 Relación directa del inventario con las compras y ventas: En cada transacción de
compra o venta, el inventario debe incrementar o disminuir en el ítem respectivo.
 R4-2 Distribución de los productos a las sucursales o almacenes: Crear registros de la
distribución de productos a las sucursales o almacenes, desde el establecimiento principal.
Registrar los datos básicos de la transacción, que son: Fecha, sucursal y obviamente los
productos y las cantidades que están siendo derivadas a la sucursal.
 R4-3 Administración de productos: Ingresar productos individualmente al inventario,
también se debe contar con la opción de modificar los campos de los productos, baja de
productos, listar y buscar todos los productos. Cada producto debe tener una imagen
referencial. Además cada producto debe estar asignada a una categoría.
 R4-4 Administración de Almacenes y Sucursal: Crear, listar, buscar, buscar, modificar y
eliminar registros de sucursales y almacenes.
 R4-5 Seguimiento del inventario en cada sucursal y/o almacen: Listar el stock actual en
cada sucursal.
 R4-6 Administrar Categorías y clasificar los productos en categorías: Crear, listar,
buscar, modificar y eliminar registros de las categorías.

b) Requerimientos no funcionales

 La Aplicación Web estará desarrollada bajo el framework de desarrollo PHP Laravel 5.4.
 La Aplicación Web funciona tanto en Firefox, Google Chrome.
 40

 La Aplicación Web debe ser totalmente funcional en los equipos que posea el cliente, debe
ser accesible (amigable) de una interfaz gráfica agradable y de fácil manejo.
 La Aplicación Web debe estar vigilado constantemente por un administrador para que no
haya pérdidas de datos y evitar errores.

3.1.3 Historias de usuario

En esta fase se establecerán prioridades para cada una de las historias de usuario, con el
fin de poder determinar el plan de entregas (Realease planning).A continuación se detallan las
Historias de Usuario más importantes.

Las siguientes historias de usuarios describen la administración de productos y la

clasificación de los productos en las categorías, el cual es un objeto base del sistema y es preciso
definirlo de la forma más clara como específica posible, ya que será consultada por otros objetos;
también interactúa con otros objetos y será el objeto base del estado de los inventarios.

Tabla 3.2: Historias de Usuario - Administración de Productos

HISTORIA DE USUARIO
Numero: 2 Usuario: Gerente, Encargado de Ventas,
Encargado de Compras, Encargado de
Almacén
Nombre historia de usuario: Administración de Productos

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Requerimiento R4-3 Administración de productos. Debe presentar una
interfaz sencilla y fácil de utilizar. La búsqueda será personalizada de acuerdo a las
necesidades del usuario.
Observaciones: Cada producto debe tener una imagen referencial.

La siguiente historia de usuario describe la Administración de las Compras debe contar

con el registro de las transacciones de compra, este se relaciona con varios objetos y afecta
directamente al estado de los inventarios. (Ver tablas 3.5)

Tabla 3.3: Historias de Usuario - Administración Compras

HISTORIA DE USUARIO
Numero: 4 Usuario: Gerente, Encargado de Compras.
Nombre historia de usuario: Administración de Compras
 41

Puntos estimados: 2 Iteración asignada: 2

Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Requerimientos R3-1 Administración de las compras relacionando a los
proveedores, R4-1 Relación directa del inventario con las compras y ventas. También se
debe contar con la opción de listar y buscar registros de compras.
Observaciones: Las búsquedas serán de acuerdo al número de comprobante y proveedor.
Debe presentar una interfaz sencilla y fácil de utilizar.
La siguiente historia de usuario describe la Administración de Ventas, este módulo
interactúa con varios objetos al mismo tiempo y podría crecer de manera considerable al
momento de desarrollarlo, también se comporta como la función de salida de inventarios.

Tabla 3.4: Historias de Usuario - Administración de Ventas

HISTORIA DE USUARIO
Numero: 8 Usuario: Gerente, Encargado de Ventas

Nombre historia de usuario: Administración de Ventas

Puntos estimados: 2 Iteración asignada: 3
Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Requerimientos R2-1 Administración de las ventas, R2-2 Relacionar las
ventas con los clientes, R2-3 Llevar seguimiento de las ventas por sucursal, R2-4
Relacionar los usuarios de ventas con las sucursales, R4-1 Relación directa del
inventario con las compras y ventas.
También se debe contar con la opción de listar y buscar, devolver registros de ventas.

Observaciones: Las búsquedas serán de acuerdo al número de comprobante y cliente.

La baja de una venta será solo un cambio de estado ha Cancelado. Debe presentar una
interfaz sencilla y fácil de utilizar.

La siguiente historia de usuario describe la distribución de mercadería y el stock actual

por sucursal y almacén.

Tabla 3.5: Historias de Usuario - Distribución de Productos a Sucursales o Almacén

HISTORIA DE USUARIO

Numero: 13 Usuario: Gerente y Encargado de

Almacén
Nombre historia de usuario: Distribución de Productos a Sucursales o Almacén
Puntos estimados: 1 Iteración asignada: 4
 42

Programador responsable: Eymi Escarlet Carrillo Cruz

Descripción: Requerimiento R4-2 Distribución de los productos a las sucursales o
almacenes. Debe presentar una interfaz sencilla y fácil de utilizar. La búsqueda será
personalizada de acuerdo a las necesidades del usuario.

La siguiente tabla muestra un resumen de las Historias de Usuario y su implementación:

Tabla 3.6: Resumen de Historia de Usuario

Nº Nombre Puntos Iteración

Estimados Asignada
1 Administración de Categoría 1
2 Administración de Productos 2 1
3 Administración de Proveedores 1
4 Administración de Compras 2
5 Devolución de Compras 2 2
6 Crédito Compra 1
7 Administración de Clientes 1
8 Administración de Ventas 2 3
9 Devolución de Ventas 2
10 Crédito Ventas 1
11 Reportes de Ventas 1
12 Administración de Sucursal y 2
Almacén
13 Distribución de Productos a 1 4
Sucursales o Almacén
14 Seguimiento de inventario por 1
sucursal y/o almacén
15 Administración de Usuarios 1
16 Administración de Roles 1
3.1.4 Plan de entregas del proyecto (Release Planning)

Basándonos en las historias de usuario definidas para el desarrollo del sistema web, se
ha elaborado el siguiente plan de entrega, el cual muestra las historias de usuario que se llevarán
a cabo en cada iteración. Para este plan de entrega se ha tomado en cuenta la prioridad y el
esfuerzo de cada historia de usuario.

En la tabla muestra el plan de entrega del proyecto:

 43

Febrero Marzo Abril Mayo Junio

Nº Semanas/Fases
1 2 3 4 1 2 3 4 5 1 2 3 4 1 2 3 4 1 2 3 4 5
1 Planificación
2 Diseño
3 Desarrollo
4 Pruebas

1ra 2da 3ra 4ta

Iteración Iteración Iteración Iteración Total = 22 semanas
4 semanas 5 semanas 6 semanas 7 semanas

3.2 Fase de diseño

En esta fase se presenta diseños simples como sugiere la metodología XP. Para lograr
una mejor comprensión de la funcionalidad del sistema. El diseño de los modelos está basado
en el lenguaje WebML.

3.2.1 Modelo estructural o de datos

WebML utiliza la notación E-R y Diagrama de Clases, la misma que se plasma en las
siguientes figuras:

Figura 3.1: Modelo Entidad Relación E-R

 44

A continuación, en la figura se puede apreciar el modelo físico de la Base de Datos del Sistema
Web.

Figura 3.2: Modelo físico de la Base de Datos

Por último se mostrara el Diagrama de clases asociado al Sistema Web ver figura:
 45

Figura 3.3: Diagrama de Clases

3.3 Fase de desarrollo

En esta fase se realizara la codificación de cada una de las historias de usuario, trabajando
juntamente con cliente. Permitiendo de esta forma una retroalimentación de lo que el cliente
quiere priorizar en las entregas de la sistema web. Para el desarrollo del sistema web se usaron
las siguientes tecnologías: PHP, Laravel 5.4, MySQL, Bootstrap 4 y libreria JQuery.

A continuación se detallan las iteraciones que se desarrollaron a través de las historias

de usuario.
 46

3.3.1 Primera iteración

En la primera iteración se implementaron los Objetos Base del sistema, estos objetos son
los que serán consultados por otras funciones, procesos e incluso por otros objetos a lo largo del
desarrollo del sistema, es por eso que su implementación es primordial para el desarrollo y
pruebas de otros módulos. Las historias de Usuario de esta iteración son: (ver tabla 3.7)

Tabla 3.7: Primera Iteración - Historias de Usuario

Nro. Historia de Usuario

1 Administración de Categoría
2 Administración de Productos
3 Administración de Proveedores
a) Tareas de ingenieria (Task Card)
A continuación mostramos el conjunto de tareas necesarias para la implementación de la historia
de usuario Nº 2: Administración de Productos.

Tabla 3.8: Tarea de Ingeniería - Creación de la Base de Datos tabla Producto

TAREA DE INGENIERÍA
Número de tarea: 2.1 Número de historia: 2
Nombre de tarea: Creación de la Base de Datos tabla Producto
Tipo de tarea: Desarrollo Puntos estimados: 1
Fecha inicio: 09-02-2017 Fecha fin: 11-02-2017
Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Se necesita crear en la base de datos la tabla Producto para almacenar la
información requerida de cada Producto. Sus datos básicos son IdProducto el cual es
único, nombre no vacío, descripción, marca, stock no vacío, Imagen referencial, Fecha
de Vencimiento, Estado no vacío (nos servirá para dar de baja a un producto) y
IdCategoria el cual será referencial a la tabla categoría.

Tabla 3.9: Tarea de Ingeniería - Creación del Modelo, Controlador, Ruta y Request Producto

TAREA DE INGENIERÍA
Número de tarea: 2.2 Número de historia: 2
Nombre de tarea: Creación del Modelo, Controlador, Ruta y Request Producto
Tipo de tarea: Desarrollo Puntos estimados: 1
Fecha inicio: 12-02-2017 Fecha fin: 15-02-2017
 47

Programador responsable: Eymi Escarlet Carrillo Cruz

Descripción: Se crear el modelo Producto para recibir o enviar la información a la base
de datos, la clase (Controlador) Producto donde se agrupara toda la funcionalidad de los
recursos, este definirá la lógica de las peticiones del usuario (listar, agregar, modificar,
eliminar y buscar), encargándose de realizar las consultas necesarias al Modelo Producto
Y Categoría, de preparar los datos y de llamar a la vista Producto con dichos datos.
También se creara ruta para generar la llamada al Controlador Producto y un request
Producto para validar los datos del formulario, el cual debe ser similar a las restricciones
de la base de datos tabla Producto.

Tabla 3.10: Tarea de Ingeniería - Diseño de la Vista Producto

TAREA DE INGENIERÍA
Número de tarea: 2.3 Número de historia: 2
Nombre de tarea: Diseño de la Vista Producto
Tipo de tarea: Desarrollo Puntos estimados: 1

Fecha inicio: 16-02-2017 Fecha fin: 19-02-2017

Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Se creara partials o formularios para registrar, editar, eliminar y listar el
objeto Producto, Además se debe agregar un buscador por nombre, marca descripción.
Se debe tener un campo en los formularios registrar y editar para subir una imagen y un
seleccionador de Categoría. Su interfaz debe ser sencilla y fácil de utilizar.
b) Tarjeta CRC

A continuación, se mostrarán las tarjetas C.R.C. de la primera iteración.

Tabla 3.11: Tarjeta CRC - Producto

TARJETAS CRC
Nombre de la clase: Producto
Responsabilidades: COLABORADORES:
 Nuevo Producto  Categoría
 Actualizar Producto
 Eliminar Producto
 Listar Producto
 Buscar Producto
c) Diagrama de hipertexto
El siguiente diagrama (ver figura 3.4) corresponde a la historia de usuario Nº 1: Administración
 48

de Categorías. Donde se muestra los componentes que tendrá la página de navegación

Figura 3.4: Diagrama de Hipertexto – Categoría

El siguiente diagrama (ver figura 3.5) corresponde a la historia de usuario Nº 2: Administración
de Productos. Donde se muestra los componentes que tendrá la página de navegación.

Figura 3.5: Diagrama de Hipertexto – Producto

El siguiente diagrama (ver figura 3.6) corresponde a la historia de usuario Nº 3: Administración
de Proveedor. Donde se muestra los componentes que tendrá la página de navegación
 49

Figura 3.6: Diagrama de Hipertexto – Proveedor

d) Modelo de presentación

A continuación se muestran en las Figuras, capturas de pantalla extraídas del Sistema Web.

Figura 3.7: Modelo de Presentación - Categoría

 50

Figura 3.8: Modelo de Presentación – Producto

Figura 3.9: Modelo de Presentación – Proveedores

e) Prueba de aceptación

A continuación se muestra en la tabla 3.12, las pruebas de aceptación:

Tabla 3.12: Prueba de Aceptación – Producto

PRUEBAS DE ACEPTACION
Código: 2 Nº Historia de usuario: 2
Historia de usuario: Producto
 51

Condiciones de ejecución: Servidor ejecutándose, el Gerente o Encargado de

Compras o Almacén deberá estar con sesión iniciada en el sistema.
Entrada/Pasos de ejecución: Seleccionar en el menú de opciones la pestaña Almacén
- Producto. Listar todos los productos. Escribir el nombre o descripción o marca del
producto y luego la opción Buscar (El Encargado de Almacén solo tiene acceso a esta
opción). Seleccionar la opción Nuevo llenar los datos correspondientes (imágenes con
extensión jpeg, jpg, png, bmp) seleccionar la categoría y luego la opción guardar.
Seleccionar la opción Editar del producto a actualizar, actualizar los datos
correspondientes y luego la opción guardar, Seleccionar la opción Eliminar del
producto a eliminar y luego la opción confirmar o cancelar.
Resultado esperado: La información del nuevo producto fue guardado con éxito. La
información actualizada del producto fue guardada con éxito. El producto fue dado de
baja. Lista de productos según el nombre o descripción o marca buscado.
Evaluación de la prueba: Aprobada

3.3.2 Segunda iteración

En esta iteración se pretende implementar las historias de usuario con mayor grado de
prioridad para el cliente (Encargado de compras y Gerente), ya que los mismos son necesarios
para que el cliente de la Comercial pueda ya familiarizarse con el sistema web. Las historias de
usuario que se implementaron en esta iteración son los siguientes (ver tabla 3.13):

Tabla 3.13: Segunda Iteración - Historias de Usuario

Nro. Historia de Usuario

4 Administración de Compras
5 Devolución de Compras
6 Crédito Compra
a) Tareas de ingeniería (Task Card)
A continuación mostramos el conjunto de tareas necesarias para la implementación de la historia
de usuario Nº 4: Administración de Compras.

Tabla 3.14: Tarea de Ingeniería - Crear de la Base de Datos tabla Compra

TAREA DE INGENIERÍA
Número de tarea: 4.1 Número de historia: 4
Nombre de tarea: Creación de la Base de Datos tabla Compra
Tipo de tarea: Desarrollo Puntos estimados: 1
Fecha inicio: 21-02-2017 Fecha fin: 23-02-2017
 52

Programador responsable: Eymi Escarlet Carrillo Cruz

Descripción: Se necesita crear en la base de datos las tablas Compras y Detalle para
almacenar la información requerida de cada compra y su detalle.
Los datos básicos de compra son: IdCompra es único y es el identificador de la tabla,
fecha de emisión de la compra, fecha de recepción de la compra, numero de comprobante
único y no vacío, tipo de comprobante (factura, boleta, ticket) no vacío, estado para
verificar el tipo de compra o si esta cancelado (Activo, Activo Crédito, Cancelado) y
IdProveedor el cual será referencial a la tabla Proveedor.
Los datos básicos de Detalle de compra son: IdDetalle es único y es el identificador de
la tabla, cantidad esperada, cantidad recibida no vacío, precio de compra no vacío, precio
de venta no vacío y IdProducto y Idcompra los cuales hace referencia a las tablas
producto y compra.
Crear disparador para actualizar el stock existente de cada producto comprado, después
de registrar una compra.

Tabla 3.15: Tarea de Ingeniería - Creación del Modelo, Controlador, Ruta y Request Compra

TAREA DE INGENIERÍA
Número de tarea: 4.2 Número de historia: 4
Nombre de tarea: Creación del Modelo, Controlador, Ruta y Request Compra
Tipo de tarea: Desarrollo Puntos estimados: 1
Fecha inicio: 24-02-2017 Fecha fin: 01-03-2017
Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Se crear los modelos Compra, Detalle y Ubicación para recibir o enviar la
información a la base de datos, la clase (Controlador) Compra y en este se trabajara de
forma conjunta con los modelos Proveedor, Almacén, Ubicación, Producto, Compra y
Detalle, para definir la lógica de las peticiones del usuario (listar, agregar y buscar) con
el fin de preparar los datos y de llamar a la vista Compra con los datos. La función agregar,
debe verificar la transacción de la compra y su detalle, de tal manera que no puedan
insertar una sin la otra.
También se creara una ruta para generar la llamada al Controlador Compra y un request
Compra para validar los datos de los formularios, el cual debe ser similar a las
restricciones de la base de datos tablas Compra y Detalle.

Tabla 3.16: Tarea de Ingeniería - Diseño de la Vista Compra

TAREA DE INGENIERÍA
Número de tarea: 4.3 Número de historia: 4
Nombre de tarea: Diseño de la Vista Compra
 53

Tipo de tarea: Desarrollo Puntos estimados: 1

Fecha inicio: 02-03-2017 Fecha fin: 06-03-2017
Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Se creara partials o formularios para registrar el objeto Compra y Detalle.
Formulario registrar, las compras debe tener un seleccionador del objeto Proveedor y
Almacén, los detalles de compra deben tener un seleccionador del objeto Productos y un
botón agregar y eliminar. Formulario listar, cada registro de compra debe tener un botón
llamado detalles para visualizar los detalles de cada compra. Además se debe agregar un
buscador por número de comprobante. Su interfaz debe ser sencilla y fácil de utilizar.
b) Tarjeta CRC

A continuación, se mostrarán las tarjetas C.R.C. de la segunda iteración.

Tabla 3.17: Tarjeta CRC - Compra

TARJETAS CRC
Nombre de la clase: Compra
Responsabilidades: Colaboradores:
 Nueva Compra  Proveedor
 Devolver Compra( Actualizar o  Producto
Eliminar detalle compra)  Detalle Compra
 Eliminar Compra  Ubicación
 Listar Compra  Almacén
 Buscar Compra  Devolución Compra
 Detalles de Compra
 Agrega ítems al inventario
 Calcula total y subtotal de la compra

c) Diagrama de hipertexto
El siguiente diagrama (ver figura 3.10) corresponde a la historia de usuario Nº 4: Administración
de Compras. Donde se muestra los componentes que tendrá la página de navegación.
 54

Figura 3.10: Diagrama de Hipertexto – Compra

El siguiente diagrama (ver figura 3.11) corresponde a la historia de usuario Nº 5: Devolución de
Compras. Donde se muestra los componentes que tendrá la página de navegación

Figura 3.11: Diagrama de Hipertexto – Devolución de Compra

 55

El siguiente diagrama (ver figura 3.12) corresponde a la historia de usuario Nº 6: Devolución de

Compras. Donde se muestra los componentes que tendrá la página de navegación

Figura 3.12: Diagrama de Hipertexto – Devolución de Compra

d) Modelo de presentación

A continuación se muestran en las Figuras, capturas de pantalla extraídas del Sistema Web.

Figura 3.13: Modelo de Presentación – Compra

 56

Figura 3.14: Modelo de Presentación – Devolución de Compra

Figura 3.15: Modelo de Presentación – Crédito Compra

e) Prueba de aceptación

A continuación se muestra la prueba de aceptación.

Tabla 3.18: Prueba de Aceptación – Compras

PRUEBAS DE ACEPTACION
Código: 4 Nº Historia de usuario: 4
Historia de usuario: Compras
Condiciones de ejecución: Servidor ejecutándose, el Gerente o Encargado de Compras
deberá estar con sesión iniciada en el sistema.
 57

Entrada/Pasos de ejecución: Seleccionar en el menú de opciones la pestaña Compras -

Compra. Listar todas las compras. Escribir el número de comprobante de compra y luego
la opción Buscar. Seleccionar la opción Nuevo llenar los datos correspondientes de la
compra (seleccionar el proveedor y almacén) y detalles de compra (seleccionar el producto
luego la opción agregar) y luego la opción guardar. Seleccionar la opción Devolver de una
compra específica a devolver, actualizar la cantidad o eliminar el producto a devolver y luego
la opción guardar. Seleccionar la opción Anular de una compra específica a dar de baja y
luego la opción confirmar o cancelar. Seleccionar la opción Detalles de una compra
específica, para visualizar los detalles de compra.
Resultado esperado: La información de la nueva compra fue guardada con éxito. La
información de la compra a devolver fue actualizada con éxito. La compra fue anulada. Lista
de compras según el número de comprobante buscado. Lista de detalles de la compra.
Evaluación de la prueba: Aprobada

3.3.3 Tercera iteración

En esta iteración se pretende implementar las historias de usuario con mayor grado de
prioridad para el cliente (Encargado de compras y Gerente), ya que los mismos son necesarios
para que el cliente de la Comercial pueda ya familiarizarse con el sistema web. Las historias de
usuario que se implementaron en esta iteración son los siguientes (ver tabla 3.19):

Tabla 3.19: Tercera Iteración - Historias de Usuario

Nro. Historia de Usuario

7 Administración de Clientes
8 Administración de Ventas
9 Devolución de Ventas
10 Crédito Venta
a) Tareas de ingeniería(Task Cards)
A continuación mostramos el conjunto de tareas necesarias para la implementación de la
historia de usuario Nº 8: Administración de Compras.

Tabla 3.20: Tarea de Ingeniería - Creación de la Base de Datos tabla Venta

TAREA DE INGENIERÍA

Número de tarea: 8.1 Número de historia: 8

Nombre de tarea: Creación de la Base de Datos tabla Venta
Tipo de tarea: Desarrollo Puntos estimados: 1
Fecha inicio: 28-03-2017 Fecha fin: 30-02-2017
 58

Programador responsable: Eymi Escarlet Carrillo Cruz

Descripción: Se necesita crear en la base de datos la tabla Venta y Detalle para
almacenar la información requerida de cada venta y su detalle.
Los datos básicos de Venta son: IdVenta el cual es único y es el identificador de la tabla,
fecha y hora de la venta, numero de comprobante único y no vacío, tipo de comprobante
(factura, boleta, ticket) no nulo, total de la venta, estado para verificar el tipo de compra
o si esta cancelado (Activo, Activo Crédito, Cancelado) y IdCliente, IdSucursal y
Usuario el cual será referencial a la tabla Cliente, Sucursal, Usuario.
Los datos básicos de Detalle de venta son: IdDetalle el cual es único y es el identificador
de la tabla, Cantidad no vacío, Precio de venta no vacío, descuento por defecto tiene el
valor 0 y IdProducto y IdVenta los cuales hace referencia a las tablas producto y venta.
Crear disparador para actualizar el stock existente de cada producto, después de registrar
una venta.

Tabla 3.21: Tarea de Ingeniería - Creación del Modelo, Controlador, Ruta y Request Venta

TAREA DE INGENIERÍA

Número de tarea: 8.2 Número de historia: 8

Nombre de tarea: Creación del Modelo, Controlador, Ruta y Request Venta
Tipo de tarea: Desarrollo Puntos estimados: 1
Fecha inicio: 31-03-2017 Fecha fin: 03-04-2017
Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Se crearan los modelos Venta y Detalle para recibir o enviar la información
a la base de datos, la clase (Controlador) Venta y en este se trabajara de forma conjunta
los modelos Cliente, Producto, Venta y Detalle para definir la lógica de las peticiones
del usuario (listar, agregar y buscar) con el fin de preparar los datos y de llamar a la vista
Venta con los datos. La función Agregar debe verificar la transacción de la venta y su
detalle, de tal manera que no puedan insertar una sin la otra.
También se creara una ruta para generar la llamada al Controlador Venta y un request
Venta para validar los datos de los formularios, el cual debe ser igual o similar a las
restricciones de la base de datos tabla Venta y Detalle.

Tabla 3.22: Tarea de Ingeniería - Diseño de la Vista Venta

TAREA DE INGENIERÍA

Número de tarea: 8.3 Número de historia: 8

Nombre de tarea: Diseño de la Vista Venta
Tipo de tarea: Desarrollo Puntos estimados: 1
 59

Fecha inicio: 03-04-2017 FECHA FIN: 06-04-2017

Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Se creara partials o formularios para registrar y listar el objeto Venta y
Detalle. El formulario registrar, las ventas debe tener un seleccionador del objeto
Cliente, los detalles debe tener un seleccionador de productos y un botón agregar(al
agregar debe mostrar los datos del producto: nombre, stock y precio) y para eliminar.
Formulario listar, cada registro de venta debe tener un botón llamado detalles para
visualizar los detalles de cada venta. Además se debe agregar un buscador por número
de comprobante.
Su interfaz debe ser sencilla y fácil de utilizar.
b) Tarjeta CRC

A continuación, se mostrarán las tarjetas C.R.C. de la tercera iteración.

Tabla 3.23: Tarjeta CRC - Venta

TARJETAS CRC
Nombre de la clase: Venta
Responsabilidades: Colaboradores:
 Nueva Venta  Cliente
 Devolver Venta( Actualizar o Eliminar  Producto
detalle venta)  Detalle Venta
 Eliminar Venta  Devolución Venta
 Listar Venta  Usuario
 Buscar Venta  Sucursal
 Detalles de Venta
 Agrega ítems al inventario
 Calcula total y subtotal de la venta
c) Diagrama de hipertexto

El siguiente diagrama (ver figura 3.16) corresponde a la historia de usuario Nº 7: Administración

de Clientes. Donde se muestra los componentes que tendrá la página de navegación.
 60

Figura 3.16: Diagrama de Hipertexto – Cliente

El siguiente diagrama (ver figura 3.17) corresponde a la historia de usuario Nº 8: Administración
de Ventas. Donde se muestra los componentes que tendrá la página de navegación

Figura 3.17: Diagrama de Hipertexto – Ventas

 61

El siguiente diagrama (ver figura 3.18) corresponde a la historia de usuario Nº 10: Crédito
Ventas. Donde se muestra los componentes que tendrá la página de navegación.

Figura 3.18: Diagrama de Hipertexto – Crédito Ventas

d) Modelo de presentación

A continuación se muestran en las Figuras, capturas de pantalla extraídas del Sistema Web.

Figura 3.19: Modelo de Presentación – Cliente

 62

Figura 3.20: Modelo de Presentación – Venta

Figura 3.21: Modelo de Presentación – Devoluciones de Venta

 63

Figura 3.22: Modelo de Presentación – Crédito Venta

e) Prueba de aceptación

A continuación se muestran en las tablas, las pruebas de aceptación.

Tabla 3.24: Prueba de Aceptación - Ventas

PRUEBAS DE ACEPTACION

Código: 8 Nº Historia de usuario: 8

Historia de usuario: Ventas
Condiciones de ejecución: Servidor ejecutándose, el Gerente o Encargado de Ventas
deberán estar con sesión iniciada en el sistema.
Entrada/Pasos de ejecución: Seleccionar en el menú de opciones la pestaña Ventas -
Ventas. Listar todas las ventas. Escribir el número de comprobante de venta y luego la
opción Buscar. Seleccionar la opción Nuevo llenar los datos correspondientes de la venta
(seleccionar el cliente) y detalles de compra (seleccionar el producto luego la opción
agregar) y luego la opción guardar. Seleccionar la opción Devolver de una venta específica
a devolver, actualizar la cantidad o eliminar el producto a devolver y luego la opción
guardar. Seleccionar la opción Anular de una venta específica a dar de baja y luego la
opción confirmar o cancelar. Seleccionar la opción Detalles de una venta específica, para
visualizar los detalles de compra.
Resultado esperado: La información de la nueva venta fue guardada con éxito. La
información de la venta devuelta fue actualizada con éxito. La venta fue anulada. Lista de
venta(s) según el número de comprobante buscado. Lista de detalles de una venta
especifica.
Evaluación de la prueba: Aprobada
 64

3.3.4 Cuarta iteración

En esta iteración se pretende implementar las historias de usuario con mayor grado de prioridad
para el cliente (Encargado de Almacén y Gerente), ya que los mismos son necesarios para que
el cliente de la Comercial pueda ya familiarizarse con el sistema web. Las historias de usuario
que se implementaron en esta iteración son los siguientes (ver tabla 3.25):

Tabla 3.25: Cuarta Iteración - Historias de Usuario

Nro. Historia de Usuario

11 Reportes de Ventas
12 Administración de Sucursal y Almacén
13 Distribución de Productos a Sucursales o Almacén
14 Seguimiento de inventario por sucursal y/o almacén
15 Administración de Usuarios
16 Administración de Roles
a) Tareas de ingeniería (Task Card)

A continuación mostramos el conjunto de tareas necesarias para la implementación de la historia

de usuario Nº 13: Distribución de Productos a Sucursales o Almacén.

Tabla 3.26: Tarea de Ingeniería - Creación de la Base de Datos tabla Distribución

TAREA DE INGENIERÍA
Número de tarea: 13.1 Número de historia: 13

Nombre de tarea: Creación de la Base de Datos y Modelo Distribución

Tipo de tarea: Desarrollo Puntos estimados: 1
Fecha inicio: 05-05-2017 Fecha fin: 07-05-2017
Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Se necesita crear en la base de datos la tabla Distribución para almacenar la
información requerida de cada distribución de productos. Sus datos básicos son:
IdDistribucion el cual es único y es el identificador de la tabla, Fecha de distribución,
cantidad no vacío, IdAlmacen1 y IdProducto los cuales son referenciales a las tablas
Almacén y [Link] disparador para actualizar el stock existente de cada producto
ubicado en almacén, después de distribuir los productos.

Tabla 3.27: Tarea de Ingeniería - Creación del Modelo Controlador, Ruta y Request Distribución

TAREA DE INGENIERÍA
 65

Número de tarea: 13.2 Número de historia: 13

NOMBRE DE TAREA: Creación del Modelo, Controlador, Ruta y Request
Distribución
Tipo de tarea: Desarrollo Puntos estimados: 1

Fecha inicio: 08-05-2017 Fecha fin: 11-05-2017

Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Se creara el modelo Distribución para recibir o enviar la información a la
base de datos, la clase (Controlador) Distribución, el cual trabaja con los modelos
Producto, Almacén y Ubicado para definir la lógica de las peticiones del usuario (listar,
buscar y nueva distribución) con el fin de preparar los datos y de llamar a la vista
Distribución con los datos.
También se creara una ruta para generar la llamada al Controlador Distribución y un
request Distribución para validar los datos de los formularios, el cual debe ser similar a
las restricciones de la base de datos tabla Ubicado.

Tabla 3.28: Tarea de Ingeniería - Diseño de la Vista Distribución

TAREA DE INGENIERÍA
Número de tarea: 13.3 Número de historia: 13

Nombre de tarea: Diseño de la Vista Distribución

Tipo de tarea: Desarrollo Puntos estimados: 1

Fecha inicio: 11-05-2017 Fecha fin: 13-05-2017
Programador responsable: Eymi Escarlet Carrillo Cruz
Descripción: Se creara partials o formularios para agregar (Selector Almacen y Producto)
y listar además se debe agregar un buscador por producto y almacén.
Su interfaz debe ser sencilla y fácil de utilizar.

b) Tarjeta CRC

A continuación, se mostrarán las tarjetas C.R.C. de la cuarta iteración.

Tabla 3.29: Tarjeta CRC - Distribución

TARJETAS CRC
NOMBRE DE LA CLASE: Distribución
RESPONSABILIDADES: COLABORADORES:
 Listar Distribución de productos a almacenes  Producto
 Buscar Distribución de productos  Almacén
 66

 Agregar nueva Distribución de productos  Ubicado

c) Diagrama de hipertexto

El siguiente diagrama (ver figura 3.25) corresponde a la historia de usuario Nº 12:

Administración de Sucursal y Almacén. Donde se muestra los componentes que tendrá la página
de navegación.

Figura 3.24: Diagrama de Hipertexto – Sucursal

Figura 3.25: Diagrama de Hipertexto – Almacen

El siguiente diagrama (ver figura) corresponde a la historia de usuario Nº 13 Distribución de
Productos a Sucursales o Almacén. Donde se muestra los componentes que tendrá la página de
navegación.
 67

Figura 3.26: Diagrama de Hipertexto – Distribución de productos

El siguiente diagrama (ver figura) corresponde a la historia de usuario Nº 15: Administración
de Usuarios. Donde se muestra los componentes que tendrá la página de navegación.

Figura 3.27: Diagrama de Hipertexto – Usuario

d) Modelo de presentación

A continuación se muestran en las Figuras, capturas de pantalla extraídas del Sistema Web.
 68

Figura 3.28: Diagrama de Hipertexto – Reporte de Venta

Figura: 3.29: Modelo de Presentación – Sucursal

Figura 3.30: Modelo de Presentación - Almacén

 69

Figura 3.31: Modelo de Presentación – Distribución de Productos

e) Prueba de aceptación

A continuación se muestran en las tablas, las pruebas de aceptación.

Tabla 3.30: Prueba de Aceptación - Distribución de Productos a Sucursales o Almacén

PRUEBAS DE ACEPTACION
Código: 14 Nº Historia de usuario: 13
Historia de usuario: Distribución de Productos a Almacén
Condiciones de ejecución: Servidor ejecutándose, el Gerente o Encargado de Almacén
deberá estar con sesión iniciada en el sistema.
Entrada/Pasos de ejecución: Seleccionar en el menú de opciones la pestaña Almacén
- Distribución. Listar todas las distribuciones. Escribir el nombre del almacén luego la
opción Buscar. Seleccionar la opción Nuevo llenar los datos correspondientes
(seleccionar los almacenes, el producto y luego la opción agregar) y luego la opción
guardar.
Resultado esperado: La información de la nueva distribución fue guardada con éxito.
Lista de productos según el nombre del almacén buscado .Lista de detalles de la
distribución x.
Evaluación de la prueba: Aprobada
3.4 Calidad

3.4.1 Mediciones elementales

Para la medición de los atributos, se utilizaron los siguientes criterios elementales:

CVN: IE =(X/Y)*100 con X=∑ Puntaje Obtenido; Y=∑ Puntaje Máximo

 70

CB: IE=0 si No existe; IE=1 si Existe

CPD: Sujeto a Objetividad del Observador

CMN: IE=0≈0 Ausente; IE=1≈60 Presencia Parcial; IE=2≈100 Presente

Donde:

CVN: Criterio de Variable Normalizada

CB: Criterio Binario

CPD: Criterio de Preferencia Directa

CMN: Criterio de Multinivel

El proceso de evaluación viene dado por los siguientes informes:

a) Usabilidad

A continuación se describe los cálculos realizados para obtener el criterio de usabilidad:

Tabla 3.31 Resultado del criterio usabilidad

Código Atributo Criterio IEi%

Elemental
1. Usabilidad CVN 91,66
1.1. Comprensibilidad global del sitio CVN 100
1.1.1. Esquema de Organización Global CVN 100
[Link]. Mapa del sitio CB 1≈100
[Link]. Menú de contenidos CB 1≈100
1.1.2. Calidad en el sistema de etiquetado CB 1≈100
1.1.3. Visita guiada orientada al usuario CB 1≈100
Mecanismos de ayuda y CVN
1.2. 100
retroalimentación en línea
1.2.1. Calidad de la ayuda CVN 100
[Link]. Ayuda explicada orientada al usuario CPD 100
[Link]. Ayuda de la búsqueda CMN 2≈100
1.2.2. Indicador de última actualización CVN 100
[Link]. Global CMN 2≈100
 71

[Link] Restringido(pos subsitios o pagina) CMN 2≈100

1.2.3. Directorio de direcciones CB 1≈100
[Link] Directorio email CB 1≈100
[Link] Directorio TE-FAX CB 1≈100
[Link] Directorio correo postal CB 1≈100
1.2.4 Facilidad FAQ CB 0
1.3. Aspectos de interfaces y estéticos CVN 100
Cohesión al agrupar los objetos de CB
1.3.1. 1≈100
control principales
Permanencia y estabilidad en la CB
1.3.2. presentación de los controles 1≈100
principales
[Link]. Permanencia de los controles directos CB 1≈100
[Link]. Permanencia de los controles indirectos CB 1≈100
[Link] Estabilidad CB 1≈100
1.3.3. Aspectos de estilo CMN 2≈100
[Link]. Uniformidad en el color de enlaces CMN 2≈100
[Link]. Uniformidad en el estilo global CMN 2≈100
[Link] Guía del estilo global CMN 2≈100
1.3.4. Preferencia estética CPD 100
1.4 Misceláneas 66.67
1.4.1 Soporte lenguaje extranjero CMN 0
1.4.2 Atributo que es lo nuevo CB 1≈100
1.4.3 Indicador de resolución de pantalla CMN 2≈100
De acuerdo a la compresibilidad del sitio, mecanismos de ayuda para el usuario y aspectos de
la interfaz gráfica del sistema, los niveles de indicador global del criterio Usabilidad tienen
un porcentaje del 91,66 % y está dentro del margen satisfactorio.

b) Funcionalidad

A continuación se describe los cálculos realizados para obtener el criterio de Funcionalidad:

 72

Tabla 3.32 Resultado del criterio Funcionabilidad

Código Atributo Criterio IEi%

Elemental
2. Funcionalidad CVN 94.58
2.1. Aspectos de búsqueda y CVN 90
Recuperación
2.1.1. Mecanismo de búsqueda en el sitio web CMN 2≈100
[Link]. Búsqueda restringida CVN 100
[Link].1 De productos CMN 2≈100
[Link].2 De proveedores CMN 2≈100
[Link].3 De clientes CMN 2≈100
[Link]. Búsqueda global CMN 0
2.1.2. Mecanismos de recuperación CVN 100
[Link]. Nivel de personalización CMN 100
[Link]. Nivel de retroalimentación en la 100
CMN
recuperación
2.2. Aspectos de Navegación y 100
CVN
Exploración
2.2.1. Navegabilidad CVN 100
[Link]. Orientación CVN 100
[Link]. Indicador de camino CB 1≈100
[Link]. Etiqueta de la posición actual CB 1≈100
[Link]. Promedio de enlaces por pagina CMN 2≈100
2.2.2. Objetos de control navegaciones CVN 100
[Link] Nivel de desplazamiento CVN 100
[Link]. Desplazamiento vertical CB 1≈100
[Link]. Desplazamiento horizontal CB 1≈100
2.2.3. Predicción navegacional CVN 100
[Link] Enlace con título (enlace con texto
CMN 2≈100
explicativo)
[Link] Calidad de la fase de enlace CMN 2≈100
2.3. Aspecto del dominio orientación al
CVN 100
usuario
 73

2.3.1. Relevancia de contenido CVN 100

[Link] Registro de ventas y clientes CB 1≈100
[Link] Registro de productos CB 1≈100
[Link] Registro de distribución de productos CB 1≈100
[Link] Registro de compras y proveedores CB 1≈100
El nivel de indicador global del criterio de Funcionabilidad es de 94.58% que de acuerdo al
rango de medición, el sistema se encuentra dentro del margen de satisfactorio.

A continuación se describe los cálculos realizados para obtener el criterio de Eficiencia:

Tabla 3.33: Resultado del criterio Eficiencia

Código Atributo Criterio IEi%

Elemental
4. Eficiencia CVN 90
4.1. Performance CVN 90
4.1.1. Páginas de acceso rápido CPD 90
4.2. Accesibilidad CVN 90
4.2.1 Accesibilidad de información CVN 80
[Link] Soporte versión solo texto CB 1≈100
[Link] Legitimidad al desactivar propiedad CVN 100
imagen Browser
[Link].1 Imagen con titulo CB 1≈100
[Link].2 Legitimidad global CB 1≈100
4.2.2 Accesibilidad de ventanas CMN 2≈100
El nivel de indicador global del criterio de Eficiencia es de 90 % que de acuerdo al rango de
medición, el sistema se encuentra dentro del margen de satisfactorio.

3.4.2 Evaluación global

Se realiza un análisis del resultado, para la evaluación de un resultado global, considerando la

siguiente tabla de medición de aceptabilidad
 74

Rango de Aceptabilidad
porcentaje
Insatisfecho De 0 a 40 %
Marginal De 40 a 60 %
Satisfecho De 60 a 100%
Por lo tanto, considerando la tabla anterior se muestran los resultados de calidad global:

Tabla 3.34: Resultado Global

Nro. Criterio Porcentaje

1 Usabilidad 91,66

2 Funcionalidad 94.58
3 Eficiencia 90

3.4.3 Conclusión de la evaluación

Tras obtener el resultado de calidad global, se establece que el sistema es 92.8 %

aceptable por los usuarios del sistema, lo que en consecuencia representa que el sistema en
cuanto a su calidad es satisfactorio.

3.5 Seguridad

La seguridad del sistema es el conjunto de medidas preventivas que se aplican para

resguardar y proteger la información buscando mantener la confidencialidad, la disponibilidad
y la integridad de la misma.

La importancia de proteger la información es resguardar el funcionamiento adecuado

del sistema, sobretodo en casos de fallo o caídas de la red. Asimismo, la protección de la
información permite evitar pérdidas económicas o documentales provocadas por agentes
externos.

3.5.1 Seguridad por niveles

La seguridad por niveles comprende tres aspectos, la seguridad a nivel de la aplicación,

a nivel de la base de datos y a nivel del servidor.

a) Seguridad a nivel de la aplicación

 75

Este tipo de seguridad comprende las herramientas que se utilizan para evitar el acceso
de agentes no autorizados con fines maliciosos, a continuación se describen estas herramientas.

i) Control de acceso
Los miembros de la directiva tienen que iniciar sesión para el acceso al sistema,
introduciendo un código de usuario y una contraseña que es única para cada integrante.

Figura 3.32: Autenticación de usuarios

De esta manera se restringe el acceso al sistema a personas que no pertenecen a la
directiva. La contraseña de cada usuario se encuentra encriptada con el método bcrypt(), para
garantizar la seguridad y el control de acceso. 103 Ademas se utiliza protección contra ataques
CSRF (Cross - Site Request Forgery), este tipo de ataques fuerzan al navegador web validado
de una victina a enviar una petición a una aplicación web vulnerable, la cual entonces realiza la
acción elegida a través de la victina. Para este fin, Laravel proporciona un método fácil para
proteger el sistema contra peticiones “cross-site” de otros sitios utilizando la función
csrf_token(), se incluye esta línea de código en cada formulario para protegerlo al enviarlo
mediante una petición HTTP.

ii) Acceso por niveles de usuario

Cada integrante de la directiva tiene funciones específicas, de tal manera que al acceder
al sistema (realizando la autenticación previa), autorizando y restringiendo los roles de cada
uno, dependiendo al cargo que cumple en la directiva.

b) Seguridad a nivel de la base de datos

El acceso a la base de datos debe ser protegido, para evitar perdida de información, para este
caso se toman en cuenta los siguientes aspectos:
 76

 Se plantea la realización de copias de seguridad, que consiste en guardar en un medio

extraíble la información del sistema y de la base de datos, como resguardo de cualquier
percance no previsto. Por lo que el administrador encargado del sistema deberá guardar los
datos con fecha y hora copiado, la frecuencia con la que se crearan las copias de seguridad
se determinara con un análisis previo considerando el volumen de datos que se introducen
en la base de datos en un tiempo determinado.
 Para evitar la llamada “SQL Injection” o “Inyección SQL” (que es un método de infiltración
de código intruso, con el objetivo de realizar consultas no deseadas y alterar 104 la base de
datos, sin el consentimiento del usuario), Laravel mediante el ORM de Eloquent, utiliza el
enlace de parámetros PDO, de tal manera que se garantiza que los usuarios malintencionados
no puedan modificar la intención de la consulta.
c) Seguridad a nivel del servidor

Los ataques distribuidos de denegación del servicio (DDoS, por sus siglas en inglés) se han
convertido en uno de los principales tipos de amenazas al que se enfrentan los sectores expuestos
a la red pública de internet. El fin de los ataques DDoS es intentar bloquear sistemas o sitios
web e infiltrarse en ellos mediante la inundación del servidor de origen con solicitudes falsas, a
menudo desde varias ubicaciones y redes, con consecuencias desde la lentitud de carga de
páginas hasta un bloqueo completo del tráfico legitimo al mismo.

El sistema web se encuentra alojado en un hosting de pago llamado Latinoamérica Hosting, que
además de proveer todos los servicios, garantiza la protección contra los ataques DDoS.
 77

CAPÍTULO IV

CONCLUSIONES Y RECOMENDACIONES

4.1Conclusiones

 La implementación del sistema web para la empresa Comercial Ariana, se convierte en una
herramienta que permite manejar y controlar de manera eficiente la gestión de información
de los procesos sobre las compras de mercadería, ventas de inventarios y almacenamiento
de productos.
 El tiempo empleado en atención al cliente fue optimizado, ya que se realiza este proceso de
forma más eficiente y con el mismo se evita errores en cálculos.
 Al automatizar y centralizar la información de los procesos de compras de mercadería,
ventas de productos y control de inventario se tiene una información inmediata y oportuna
para la toma de decisiones, así mismo la implementación de una base de datos para el
almacenamiento produce y genera que la información sea rápida y oportuna evitando así
problemas y errores en el manejo mismo.
 El sistema web desarrollado con funciones específicas, le permite tener al administrador
información sobre sus clientes, y productos, por ejemplo cuales son los productos que mas
se demandan y además quienes son los clientes que mas compran y que productos
 78

adquieren. Así como realizar la planificación de las adquisiciones de los Ítems para el
inventario, es decir el software le proporcionará las respuestas a las siguientes preguntas
Cuándo y Cuánto pedir?
 El sistema web permite al usuario generar reportes de ventas y distribución, logrando
satisfacer la necesidad de información y movimientos de la empresa.
 El usuario pueda acceder al sistema con un determinado privilegio por medio de una
autenticación donde debe registrarse con usuario y contraseña.
 Se visualiza de manera detallada la disponibilidad de productos en almacenes y/o sucursales
en tiempo real.

4.2 Recomendaciones

A partir del presente trabajo se propone las siguientes recomendaciones, con el fin de buscar el
mejoramiento del sistema:

 Cuando se requiera la ampliación y creación de nuevos módulos, ser recomienda primero

revisar la documentación para poder tomar una buena decisión, ya que el sistema presenta
elementos reutilizables que podrían ser utilizados en los módulos nuevos.
 Se recomiendo para trabajos futuros con características similares utilizar algún framework,
que facilite el desarrollo del producto.
 Se recomienda la utilización de herramientas de programación brindadas por PHP, debido a
la interfaz amigable para el desarrollador
 Se recomiendo a la empresa, implementar, utilizar y administrar el sistema de acuerdo las
instrucciones brindadas.
 La revisión periódica por cierto periodo de tiempo es recomendables para eficiencia y un
funcionamiento adecuado del sistema.
 Se recomiendo a la empresa, tener cuidado al momento de asignar ciertos privilegios a los
roles de los usuarios.
 Se recomiendo a la empresa, el cambio periódico de su contraseña para la seguridad de sus
cuentas; sobre todo, verificar la fortaleza de la contraseña.
 79

Referencias Bibliografías

Arana, J. (2014). Desarrollo e implementación de un sistema de gestión de ventas de repuestos

automotrices en el almacén de auto repuestos eléctricos marcos en la parroquia Posorja
cantón Guayaquil, provincia del Guayas. Universidad Estatal Península de Santa Elena
Facultad de Sistemas y Telecomunicaciones Escuela de Informática Carrera de
Informática.

Ardila Albarracin, C. A. (19 de septiembre de 2016). Portal Universidad del Cauca. Obtenido
de [Link]/~cardila/IS_06__002_Resumen_XP.pdf

Casañas, D. J. (2001). Sistemas de Inventario y Técnicas para la Determinación de Tamaños de

Lotes de Producción. Universidad Católica Andrés Bello. Caracas.

Chiluisa Pallo, A. P., & Loarte Cajamarca, B. G. (2014). Desarrollo e Implantación del Sistema
de Control de Inventarios y Gestión de Laboratorios. Quito: Facultad de Ciencias de la
Escuela Politécnica Nacional.

Clurg Castro, A. P. (2011). Sistema de gestion de ventas online para empresas Discograficas
Nacionales. La Paz: Universidad Catolica Boliviana.

Colmena Vargas, L. A. (2015). Sistema Web de Seguimiento de Ventas Y Cobranzas Para La

Agencia De Viajes COSMOS TRAVEL AND SERVICES S.R.L. La Paz: Universidad
Mayor de San Andres.

CompuBinario. (2017). CompuBinario. Obtenido de [Link]

control-de-inventario-y-ventas/

Contapyme. (2016). Contapyme. Obtenido de [Link]

inventarios

Ferreira Escutia, R. (2013). XP Extreme Programming. Obtenido de

[Link]

FERRER J., R. G. (2002). Programación Extrema y Software Libre. Universidad Rey Juan
Carlos y Universidad Politécnica de Madrid.

García Cantú, A. (2008). Almacenes : planeación,organización y control.

 80

Gitman, L., & Nuñez Ramos, E. (2003 ). Principios de administración financiera.

Joskowicz, J. (2011). Reglas y Prácticas en Xtreme Programing. Madrid, España: Vigo.

Letelier, P., & Penades, M. C. (septiembre de 2006). Extreme Programming (XP). Obtenido de
Metodologías Ágiles para el desarrollo del software:
[Link]

Mongua, P., & Sandoval, H. (2009). Propuesta de un modelo de inventario para la mejora del
ciclo logístico de una distribuidora de confites ubicada en la ciudad de barcelona,
estado anzoátegui. Obtenido de
[Link]
NTARIO_PARA_LA_MEJORA_DEL_CICLO_LOG%C3%8DSTICO_DE_UNA

Monterroso, E. (2000). EL GRAFICO ABC COMO TECNICA DE GESTION DE

INVENTARIOS. Obtenido de [Link]

Moreno, W. (2008). Comparación de los métodos de valuación de inventarios en una economía

con alta tasa de inflación.

Nieto, E. D. (5 de Octubre de 2015). Investigacion de operaciones. Obtenido de

[Link]

OLSINA, L. A. (2000). Metodología Cuantitativa para la Evaluación y Comparación de la

Calidad de Sitios Web. La Plata: Facultad de Ciencias Exactas de la UNLP.

Penadés, M., & Letelier, P. (23 de julio de 2015). Métodologías Ágiles para el desarrollo de
software: eXtreme Programming (XP). Obtenido de
[Link]

Peña Trujillo, L. J. (2015). Sistema de información de ventas para una empresa de motos usando
el framework Laravel. Cochabamba: Universidad Mayor de San Simon.

Quintero , P. (5 de octubre de 2015). INVESTIGACION DE OPERACIONES. Obtenido de

[Link]

Rivadeneira , S. G. (2012). METODOLOGÍAS ÁGILES ENFOCADAS AL MODELADO DE.

Universidad Nacional de la Patagonia Austral.
 81

Sicar. (2015). Sicar. Obtenido de [Link]

venta/
DOCUMENTOS